- Glasgow-haskell-users

RE: GHC kit for Windows
by Simon Peyton-Jones 04 Feb '04

04 Feb '04

Graham wrote | > I note that the GHC kit for Windows includes some of the (I presume) | > MinGW | > binutil components, but does not include 'ar'. I find that 'ar' is | > needed | > for building HaXml. May I suggest that 'ar' also be included in this | > kit? Sigbjorn says | Adding 'ar' is clearly trivial, but the tools that GHC installers | include aren't meant to be used by the public, only by GHC | to avoid having to rely on external tools when compiling& | linking (e.g., 'gcc' and 'ld' don't work as-is, but need the right | -B setting). I'm not strongly against it, but adding other dev | tools does have potential support costs I'm inclined to agree with Sigbjorn here. Where would we stop? GHC does include some Mingw stuff "in its belly", but you are not supposed to know or care how GHC does its work. You certainly aren't expected to invoke those tools directly. If you want anything more than GHC, I think the best thing is to get Mingw or Cygwin or SFU. Simon

1 0

RE: ghc6.2 on Solaris
by Simon Marlow 03 Feb '04

03 Feb '04

> I have produced, with Simon M's help, an unofficial binary > release of ghc 6.2 on > Solaris. This may be downloaded from > > http://www.informatik.uni-bremen.de/~ger/ghc/ Thanks to George for putting this together. We should be clear that this build is 6.2+patches (a snapshot along the 6.2.x branch). If you encouter bugs using this distribution, please state clearly that it was this distribution and not a plain 6.2 build to avoid confusion. Cheers, Simon

1 0

ghc6.2 on Solaris
by George Russell 03 Feb '04

03 Feb '04

I have produced, with Simon M's help, an unofficial binary release of ghc 6.2 on Solaris. This may be downloaded from http://www.informatik.uni-bremen.de/~ger/ghc/

1 0

RE: Generics and type classes
by Simon Peyton-Jones 02 Feb '04

02 Feb '04

What you ask is not easy. When you ask for everywhere special you ask to apply special to each node of the tree -- and special requires the MyClass dictionary. But the library code for 'gmapT' and 'everywhere' don't know about MyClass. In particular, to do (gmapT special), poor old gmapT has to find a MyClass dictionary to pass to each call to special -- and it has no way to do that. I bet that you could do what you want by replacing the 'instance MyClass ExampleType1' by mkTs for special, so special uses run-time type dispatch to implement the operations in MyClass. I guess that's what Keeane is suggesting. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of MR K P SCHUPKE | Sent: 02 February 2004 11:48 | To: doc(a)drjava.de; glasgow-haskell-users(a)haskell.org | Subject: Re: Generics and type classes | | Because the 'cast' operator used in generics, works on having a concrete | type to cast to. What you need to do is: | | module TypeTest where | | import Data.Generics | | class Data a => MyClass a | | instance MyClass ExampleType1 | instance MyClass ExampleType2 | | special :: ExampleType1 -> ExampleType1 | special = ... | | special2 :: ExampleType2 -> ExampleType2 | special2 = ... | | generic :: MyClass a => a -> a | generic = everywhere (mkT special `extT` special2 ...) | | Regards, | Keean. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Re: Generics and type classes
by MR K P SCHUPKE 02 Feb '04

02 Feb '04

Because the 'cast' operator used in generics, works on having a concrete type to cast to. What you need to do is: module TypeTest where import Data.Generics class Data a => MyClass a instance MyClass ExampleType1 instance MyClass ExampleType2 special :: ExampleType1 -> ExampleType1 special = ... special2 :: ExampleType2 -> ExampleType2 special2 = ... generic :: MyClass a => a -> a generic = everywhere (mkT special `extT` special2 ...) Regards, Keean.

1 0

RE: linking problems after switching from GHC5 to GHC6
by Simon Marlow 02 Feb '04

02 Feb '04

Thanks; looks like I overlooked that patch. One workaround is to use '-lfoo' rather than 'foo.a' (not forgetting to add the lib directory with -L<dir> if necessary). Cheers, Simon > -----Original Message----- > From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Sigbjorn Finne > Sent: 30 January 2004 16:39 > To: glasgow-haskell-users(a)haskell.org > Subject: Re: linking problems after switching from GHC5 to GHC6 > > This is a 6.x bug; I fixed it in HEAD a while back, > > http://haskell.org/pipermail/cvs-ghc/2003-October/018991.html > > but the change wasn't merged for some reason. > > --sigbjorn > > ----- Original Message ----- > From: "Sven Panne" <Sven.Panne(a)aedion.de> > To: "Volker Wysk" <post(a)volker-wysk.de> > Cc: <glasgow-haskell-users(a)haskell.org> > Sent: Friday, January 30, 2004 08:28 > Subject: Re: linking problems after switching from GHC5 to GHC6 > > > > Volker Wysk wrote: > > > I've put together a minimal program which reproduces the > problem. Save > the > > > three attachments in a new directroy and type "make". I'ts just as > > > described earlier. The trivial program compiles with > GHC5, but not GHC6. > [...] > > > > Hmmm, it looks like GHC is reversing the order of files in > the linking > step. > > Mentioning liba.a *before* Main.o in the linking step is a > workaround... > > > > Cheers, > > S. > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

Generics and type classes
by Stefan Reich 31 Jan '04

31 Jan '04

Hi, please consider the following module: module TypeTest where import Data.Generics class Data a => MyClass a where special :: a -> a generic :: MyClass a => a -> a generic = everywhere (mkT special) The general idea is to define traversals about data types not known in advance. The data types must implement a "special" transformation which is then automatically extended to a "generic" transformation. The definition of "generic" is but an example. In reality, there might also be special2 and special3 beside "special", and "generic" might combine the three special transformations in some way. The problem is this - the module doesn't compile. TypeTest.hs:1: Ambiguous type variable `b' in the top-level constraint: `MyClass b' arising from use of `special' at TypeTest.hs:9 I suppose the type of "mkT special" is ambiguous. But how can I change that? No type annotation or combination of type annotations seems to help. Suggestions appreciated, -Stefan

1 0

linking problems after switching from GHC5 to GHC6
by Volker Wysk 31 Jan '04

31 Jan '04

Hello I can't link with a library any longer, after switching from ghc5 to ghc6.2. I've recompiled the library with the new compiler version, so that's not the problem. With GHC5: everything is fine: ~/src/hsunix $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04.2 ~/src/hsunix $ make clean ... ~/src/hsunix $ make build/test0 ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixArgs.o src/lib/HsUnixArgs.hs ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixShell.o src/lib/HsUnixShell.hs ... ar cqs build/libhsunix.a build/HsUnixArgs.o build/HsUnix.o build/HsUnixMisc.o build/HsUnixPaths.o build/HsUnixShell.o build/HsUnixCommands.o build/HsUnixProcErr.o build/hsunix.o ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -ohi build/test0.hi -c -o build/test0.o src/test/test0.hs ghc -o build/test0 build/test0.o -odir build `src/lib/hsunix-config --local --libs` ~/src/hsunix $ src/lib/hsunix-config --local --libs build/libhsunix.a -syslib lang -syslib posix -syslib text -syslib util With GHC6, I get errors about undefined symbols. It are symbols which are defined in the library (libhsunix.a): ~/src/hsunix $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2 ~/src/hsunix $ make clean ... ~/src/hsunix $ make build/test0 ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixArgs.o src/lib/HsUnixArgs.hs ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixShell.o src/lib/HsUnixShell.hs ... ar cqs build/libhsunix.a build/HsUnixArgs.o build/HsUnix.o build/HsUnixMisc.o build/HsUnixPaths.o build/HsUnixShell.o build/HsUnixCommands.o build/HsUnixProcErr.o build/hsunix.o ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -ohi build/test0.hi -c -o build/test0.o src/test/test0.hs ghc -o build/test0 build/test0.o -odir build `src/lib/hsunix-config --local --libs` build/test0.o(.text+0x25): In function `__stginit_Main_': : undefined reference to `__stginit_HsUnix_' build/test0.o(.text+0xec): In function `Main_main_srt': : undefined reference to `HsUnix_mainwrapper_closure' build/test0.o(.text+0x151): In function `Main_main_entry': : undefined reference to `HsUnix_mainwrapper_closure' collect2: ld returned 1 exit status make: *** [build/test0] Error 1 rm build/test0.o Oddly, the problem does not occur when I directly pass the haskell source file to the compiler instead of the object file which is created from it: ~/src/hsunix $ ghc -o build/test0 src/test/test0.hs -odir build `src/lib/hsunix-config --local --libs` `src/lib/hsunix-config --local --cflags` ^^^^^^^^^^^^^^^^^ instead of build/test0.o which is created from it (succeeds) Does anyone have any idea of what's wrong? I find this especially strange, because it works with GHC5. Bye, V.W. -- Volker Wysk <post(a)volker-wysk.de> http://www.volker-wysk.de

3 3

RE: Problem with ghc on Windows ME
by Simon Marlow 30 Jan '04

30 Jan '04

[ file actually attached this time... ] > > In released software, I'm using only system so far, so won't be > > affected negatively. But I still haven't managed to work around the > > "works in win98"/"fails in winXP" problem I mentioned, and have so > > far avoided trying rawSystem because of the version problem. If you > > can offer a workaroung to the version problem, I'll try whether > > rawSystem is any help in my case. > > I've attached a standalone rawSystem implementation that works on both > 6.0.1 and 6.2 on Windows (on Unix it only works with 6.2; if you want > 6.0.1 support for Unix too you'll need an extra .c file). > > I'd be interested to know if this helps with your win98/winXP problem; > at the least it should free you from having to think about > one layer of > quoting. > > > Generally, it'd be great if working code would less often break with > > new releases (oh, and a portable popen2, while we're at it!-). > > We try our best! Remember that patchlevel releases only fix > bugs, never > change interfaces, so working code should never break when moving to a > new patchlevel release. Major releases can change > interfaces. We also > do a great deal of testing on every release, but bugs inevitably creep > in, especially on platforms other than our main development platform > (Linux). Which is why we're grateful for any help we can get from the > community... > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

RE: Problem with ghc on Windows ME
by Simon Marlow 30 Jan '04

30 Jan '04

> In released software, I'm using only system so far, so won't be > affected negatively. But I still haven't managed to work around the > "works in win98"/"fails in winXP" problem I mentioned, and have so > far avoided trying rawSystem because of the version problem. If you > can offer a workaroung to the version problem, I'll try whether > rawSystem is any help in my case. I've attached a standalone rawSystem implementation that works on both 6.0.1 and 6.2 on Windows (on Unix it only works with 6.2; if you want 6.0.1 support for Unix too you'll need an extra .c file). I'd be interested to know if this helps with your win98/winXP problem; at the least it should free you from having to think about one layer of quoting. > Generally, it'd be great if working code would less often break with > new releases (oh, and a portable popen2, while we're at it!-). We try our best! Remember that patchlevel releases only fix bugs, never change interfaces, so working code should never break when moving to a new patchlevel release. Major releases can change interfaces. We also do a great deal of testing on every release, but bugs inevitably creep in, especially on platforms other than our main development platform (Linux). Which is why we're grateful for any help we can get from the community... Cheers, Simon

1 0