October 2005 - Glasgow-haskell-users

[ ghc-Feature Requests-1333482 ] Supertyping of classes
by SourceForge.net 20 Oct '05

20 Oct '05

Feature Requests item #1333482, was opened at 2005-10-20 11:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1333482&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Supertyping of classes Initial Comment: see "Supertyping Suggestion for Haskell" [url]http://repetae.net/john/recent/out/supertyping.html[/url] example: [code] class Num a <= Group a where (+) :: a -> a -> a negate :: a -> a [/code] apart from multiple inheritance, it could work like this: [code] import Prelude hiding ((+),negate) import qualified Prelude ((+),negate) class Group a where (+) :: a -> a -> a negate :: a -> a instance Num a => Group a where (+) = (Prelude.+) negate = Prelude.negate [/code] - coeus_at_gmx_de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1333482&group_…

1 0

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 20 Oct '05

20 Oct '05

On 20 October 2005 10:35, Simon Marlow wrote: > On 19 October 2005 20:41, Wilhelm B. Kloke wrote: > >> Simon Marlow <simonmar(a)microsoft.com> schrieb: >>> >>> Are you building GHC in a fresh tree now? I'd recommend doing that. >> >> Now I am using a *really* fresh tree. Formerly the compilation of >> Apply.cmm did not render an instructive error message, just >> failed for some sort of memory access exception. Now I have: >> >> ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W >> -optc-Wstrict-prototypes -optc-Wmissing-prototypes >> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return >> -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel >> -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static >> -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h >> -#include RtsUtils.h -#include StgRun.h -#include Schedule.h >> -#include Printer.h -#include Sanity.h -#include STM.h -#include >> Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h >> -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h >> -#include Apply.h -fvia-C -dcmm-lint -c parallel/RBH.c -o >> parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static >> -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h >> -#include RtsUtils.h -#include StgRun.h -#include Schedule.h >> -#include Printer.h -#include Sanity.h -#include STM.h -#include >> Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h >> -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h >> -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o >> ghc-asm: don't know how to mangle assembly language for: >> x86_64-unknown-freebsd > > Uhuh. This means that GHC is attempting to build a registerised > version (which is what happens by default). If you don't plan to > work on registerised support right now, you could set > 'GhcUnregisterised=YES' in mk/build.mk. Incedentally, registerised support should be quite easy, since I've already done it for x86_64-unknown-linux, where the ABI and toolchain are the same AFAIK, so it might just be a case of enabling x86_64-unknown-freebsd in the right places (ghc-asm.lprl for one, I can't remember if there's anywhere else off hand). Cheers, Simon

1 0

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 20 Oct '05

20 Oct '05

On 19 October 2005 20:41, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> >> Are you building GHC in a fresh tree now? I'd recommend doing that. > > Now I am using a *really* fresh tree. Formerly the compilation of > Apply.cmm did not render an instructive error message, just > failed for some sort of memory access exception. Now I have: > > ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W > -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return > -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel > -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static > -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h > -#include RtsUtils.h -#include StgRun.h -#include Schedule.h > -#include Printer.h -#include Sanity.h -#include STM.h -#include > Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h > -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h > -#include Apply.h -fvia-C -dcmm-lint -c parallel/RBH.c -o > parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static > -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h > -#include RtsUtils.h -#include StgRun.h -#include Schedule.h > -#include Printer.h -#include Sanity.h -#include STM.h -#include > Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h > -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h > -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o > ghc-asm: don't know how to mangle assembly language for: > x86_64-unknown-freebsd Uhuh. This means that GHC is attempting to build a registerised version (which is what happens by default). If you don't plan to work on registerised support right now, you could set 'GhcUnregisterised=YES' in mk/build.mk. Cheers, Simon

1 0

Re[2]: cc1plus.exe not included in Win32 distro
by Bulat Ziganshin 20 Oct '05

20 Oct '05

Hello Sigbjorn, Tuesday, October 18, 2005, 3:58:03 AM, you wrote: >> the official Win32 distro does not contain cc1plus.exe, needed to compile CPP files SF> Should GHC binary dists include a C++ compiler? I'd say SF> no, but if there are practical and compelling reasons to do SF> so, it's no big deal to re-include the binary. well, i scanned a number of libs and apps and found that they all include only C sources (not counting wxHaskell, which anyway is distributed in precompiled form). so i'm a bit out of luck: my program contains huge C++ libs. so i need to include in my program and library instructions to install C++ compiler. but this depends on the version of GHC installed. may be you can include such instructions in your distro? something like it: "In order to compile C++ files, you nedd to download ... and then install/unapck it to the $GHC/gcc-lib directory" btw, i just copied cc1plus.exe to this directory from migw32 3.4.2 installation. is that enough? and thank you - installer size was really greatly reduced in this version -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

RE: Help wanted! Win32 and HGL for GHC on Windows
by Simon Peyton-Jones 20 Oct '05

20 Oct '05

| | * The libraries/HGL package works fine on Unix, where it sits on top | | of the libraries/X11 package. But it does not work properly on | | Windows, where it sits on top of libraries/Win32. It is not clear | | whether the problem is with the HGL package or the Win32 package. | | As usual I am unable to find the time to look more carefully at this so | please pass this report on to whomever is dealing with HGL. | | I haven't heard what problems others have found but here is what I just | experienced. | | ...snip... Mike: thanks for giving detailed info about what works and what doesn't with HGL and Win32. So far I have had no volunteers, so I'm afraid HGL may stay broken. If anyone is interested in helping, let me know and I'll fwd Mike's info on to you. Simon

1 0

New 6.4.1 windows installer
by Sigbjorn Finne 19 Oct '05

19 Oct '05

A test installer for a patched version of ghc-6.4.1 for Windows is now available, http://haskell.org/ghc/dist/6.4.1/ghc-6-4-1-bld1.msi Unless I'll hear of any packaging snafus, it'll be hooked up to the GHC web pages tomorrow. Notice that by default this installer will deposit bits in the same directory as the original 6.4.1 installer, so if you treasure the original bits.... The installer includes all 6.4.1 fixes committed as of 2005-10-20T01:00:00+0000. In particular, usage of Cabal from a GHCi-like setting should now work OK. --sigbjorn

1 0

RE: Cross-Compiling with GHC?
by Simon Marlow 19 Oct '05

19 Oct '05

On 18 October 2005 20:17, Rich Fought wrote: > GHC noob here, trying to compile a small app for a Linux/PPC target > from a Linux/x86 host. > > I take it this must be doable, since it is possible to build GHC for > new platforms and GHC itself is written in Haskell. > I'm just trying to find out if anyone has formulated a guide to this > already, before I jump in (and I did try Google > without much luck). I'm afraid building GHC for the target is not an > option. > > My first thought to try is to build an unregisterised GHC on x86 from > scratch and use it to compile my app to C code, > which I can then cross-compile to PPC. Something tells me however > that this C code still may have some x86 specific > stuff in it. This is possible, but far from easy. The kind of cross-compilation we do to port GHC to a new platform isn't full cross compilation - we compile Haskell to C on the host, and then C to object code on the target system. You can do the same to compile your app, but remember that you need all the libraries and the RTS compiled for the target too. Basically GHC is a special case of an app that we cross-compile in this way. If you want to try this, you'd need to proceed something like this: - follow the porting instructions, build the libraries and RTS on the target, but stop before building GHC - put your app in the GHC build tree. Generate unregisterised .hc files on the host, take them to the target and build there. I've ommitted a *lot* of details. This plan works in theory. Alternatively, you could try to make GHC do proper cross-compiling, using a cross-toolchain on the host system. This would have more lasting value, at least. Definitely a fair bit of work though. Cheers, Simon

1 0

Cross-Compiling with GHC?
by Rich Fought 19 Oct '05

19 Oct '05

Hi there - GHC noob here, trying to compile a small app for a Linux/PPC target from a Linux/x86 host. I take it this must be doable, since it is possible to build GHC for new platforms and GHC itself is written in Haskell. I'm just trying to find out if anyone has formulated a guide to this already, before I jump in (and I did try Google without much luck). I'm afraid building GHC for the target is not an option. My first thought to try is to build an unregisterised GHC on x86 from scratch and use it to compile my app to C code, which I can then cross-compile to PPC. Something tells me however that this C code still may have some x86 specific stuff in it. Regards, Rich

2 1

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 18 Oct '05

18 Oct '05

On 17 October 2005 19:19, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> On 15 October 2005 23:10, Wilhelm B. Kloke wrote: >> >>> Don't forget to delete Linker.c (for ghci). The stage on teh host >>> system where the process fails jsut now is >>>> $MAKE -C libraries boot all >>> because >>>> Fake happy is not happy! >> >> You mean on the target system? Can you give more details? > > Yes. Sorry for any confusion. The happy error messages was an easy > one, > because I have a working 32bit happy on the system. > >>> But ghc-inplace seems to work pretty good now on amd64. > > I reached the end of hc-build successfully. Now there is a new > problem. > I tried (as root) make install at this point. This fails with error > messages > related to missing stage2 subdirectories. So I tried At this point you can either do 'make install stage=1', or you can just use the compiler you built to build a clean GHC in another tree, i.e. with ./configure --with-ghc=/path/to/bootstrap/ghc/compiler/ghc-inplace. > gmake stage=2 boot > > This fails with messages > ... > cmm/CmmLex.hs:28: unterminated #if > cmm/CmmLex.hs:20: unterminated #if > <<ghc: 55123864 bytes, 6 GCs, 160600/160600 avg/max bytes residency > (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.41 > elapsed), 0.01 GC (0.05 elapsed) :ghc>> gmake: *** [depend] Fehler 1 > > This error is due to indented preprocessor lines > #else > #endif I've never seen this one before - very odd. You must have Alex in order to process CmmLex.x into CmmLex.hs, or did you copy this from the host tree? I just checked and a copy of CmmLex.hs from my build tree doesn't have any indented preprocessor directives. Cheers, Simon

2 1

GHC 6.4.1 barfs building haskell-src-exts on MingW/WinXP
by Bayley, Alistair 17 Oct '05

17 Oct '05

Hello all, I'm trying to build haskell-src-exts-0.2 with GHC 6.4.1 under MingW on WinXP. It segfaults on the "runhaskell Setup.hs build" command (in the src/haskell-src-exts subdir). Does anyone else get this, or is it just me? sh-2.04$ runhaskell Setup.hs build -v5 Preprocessing library haskell-src-exts-0.2... c:\happy\happy-1.13\bin\happy.exe -agc -oLanguage\Haskell\Hsx\Parser.hs Language\Haskell\Hsx\Parser.ly shift/reduce conflicts: 5 Building haskell-src-exts-0.2... [segfault: instruction at 0 ref'd memory at 0] sh-2.04$ How do I modify the Cabal setup to get GHC -v output (so I can see which module it fails on)? Alistair.

4 3