April 2003 - Glasgow-haskell-users

Re: Derivable type classes
by Christian Maeder 16 Apr '03

16 Apr '03

> The plan would be to automatically derive classes 'Typable' and 'Term' > for every data type, and make TypeReps a bit more efficient and clean. Good, I would appreciate that very much! > is anyone actually using the derivable-type-class stuff? > does anyone mind if they die No, I don't mind Christian

1 0

Derivable type classes
by Simon Peyton-Jones 16 Apr '03

16 Apr '03

Gentle GHC users I'm thinking of removing the "Derivable type classes" stuff from GHC. It's described in a paper that Ralph Hinze and I wrote http://research.microsoft.com/~simonpj/Papers/derive.htm and in the GHC user manual at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-classes. html But it's quite complicated to implement, it's incomplete (needs constructor-name stuff, and better lifting), and it sometimes gives huge types in the intermediate language (because of the encoding into tuples). So the benefit-to-cost ratio seems poor. Instead, I'm planning to implement the "Scrap your boilerplate" ideas for generic programming, described in another paper http://research.microsoft.com/~simonpj/papers/hmap/ The plan would be to automatically derive classes 'Typable' and 'Term' for every data type, and make TypeReps a bit more efficient and clean. Now, I could add the latter without removing the former, but GHC is big and fat enough already. So this message is really to ask is anyone actually using the derivable-type-class stuff? does anyone mind if they die Speak now or forever hold your peace. Simon Just to remind you, derivable type classes let you write definitions like class Eq t where (==), (/=) :: t -> t -> Bool -- generic default method (==){1} Unit Unit = True (==){a + b} (Inl x1) (Inl x2) = x1 == x2 (==){a + b} (Inr y1) (Inr y2) = y1 == y2 (==){a + b} _ _ = False (==){a * b} (x1 :*: y1) (x2 :*: y2) = x1 == x2 && y1 == y2

1 0

SSL & Glasgow Haskell?
by George Russell 14 Apr '03

14 Apr '03

Has anyone written client/server code in Glasgow Haskell that communicates over an SSL connection?

2 1

Say�n glasgow-haskell-users ,Baskuda.Com`da Bebek / Oyuncak Kategorisi A��ld�!
by Baskuda-12397 14 Apr '03

14 Apr '03

1 0

RE: Help Support
by Simon Marlow 14 Apr '03

14 Apr '03

> (A better mailing list for GHC questions is > Glasgow-haskell-users(a)haskell.org) > > I guess you can say > ghci Main.hs < run_main >& /dev/null > > where run_main contains > main A slight refinement: echo main | ghc -v0 Main.hs the -v0 avoids all extraneous output including the banner and the "Skipping Main..." message. Cheers, Simon

1 0

RE: Help Support
by Simon Peyton-Jones 14 Apr '03

14 Apr '03

(A better mailing list for GHC questions is Glasgow-haskell-users(a)haskell.org) I guess you can say ghci Main.hs < run_main >& /dev/null where run_main contains main That way, GHCi will load Main.hs, and then run 'main'. The output redirection would throw away the banner stuff. It'd be better to be able to say ghc --run Main.hs instead. If a lot of people are keen on that we'll probably do it. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of edgar cubides | Sent: 11 April 2003 19:51 | To: haskell(a)haskell.org | | Hi, i'm doing my undergraduate project about a HUGS tool. | | I have right now the following components: | | - A software client/server that is compilable on runHUGS. | | The problem is if i compile this software using GHC, can i run it on line.? | How can i do this? | | I apreciate any documentation about it. | | Thanks for your time. | | _________________________________________________________________ | The new MSN 8: advanced junk mail protection and 2 months FREE* | http://join.msn.com/?page=features/junkmail | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: un/dosifyPath in SysTools.lhs bug?
by Simon Peyton-Jones 14 Apr '03

14 Apr '03

Turns out that I've already updated the documentation; it's just that it hasn't made it into a released version yet. (Update was on 17 Feb 2003.) See the except below. After <command>autoconf</command> run <command>./configure</command> in <filename>fptools/</filename> thus: <Screen> ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc </Screen> This is the point at which you specify that you are building GHC-mingw (see <xref linkend="ghc-mingw">). </para> <para> Both these options are important! It's possible to get into trouble using the wrong C compiler! Furthermore, it's very important that you specify a full mingw path for <command>gcc</command>, not a cygwin path, because GHC (which uses this path to invoke <command>gcc</command>) is a Mingw program and won't understand a cygwin path.. For example, if you say <literal>--with-gcc=/mingw/bin/gcc</literal>, it'll be interpreted as <filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the first time it tries to invoke it. (Worse, the failure does not come with a helpful error message, unfortunately.) </para> | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dominic Cooney | Sent: 14 April 2003 09:38 | To: glasgow-haskell-users(a)haskell.org | | I'm trying to build ghc (the 5.04.3 source tarball) on Windows, but right | after the ghc-inplace is written and is used to build something, ghc fails. | If I cut and paste the command* and run it with -v, it's evident that ghc is | trying to execute /cygdrive/c/mingw/bin/gcc, which is the gcc that I | ./configured --with-gcc. | | But ghc is a mingw executable! So I think runSomething in SysTools.lhs, or | whatever calls it, might have a bug. From the comments of runSomething it is | clear that it expects a 'native' program. Anyway, the problem can be fixed | by changing: | | cmd_line = pgm ++ ... | | to: | | cmd_line = (dosifyPath pgm) ++ ... | | And dosifyPath and undosifyPath (#if defined(mingw32_HOST_OS)) have no | regard for drive letters! Shouldn't they be something like: | | unDosifyPath xs = | case (subst '\\' '/' xs) of | drive : ':' : rest -> "/cygdrive/" ++ (drive : rest) | xs' -> xs' | | dosifyPath stuff | = subst '/' '\\' real_stuff | where | -- fully convince myself that /cygdrive/ prefixes cannot | -- really appear here. | cygdrive_prefix = "/cygdrive/" | | real_stuff | | cygdrive_prefix `isPrefixOf` stuff = | case (dropList cygdrive_prefix stuff) of | drive : rest -> drive : ':' : rest | | otherwise = stuff | | That comment re: cygdrive in dosifyPath is rather ominous... but those | changes at least allow ghc-inplace to start compiling the next thing... | | The build then barfed in rts doing: | | ../../ghc/compiler/ghc-inplace -O2 -package-name rts -O -Rghc-timing -c | Exception.hc -o Exception.o | | Because Exception.hc couldn't #include "Stg.h"; it seems the GHC include | path was specified as a couple of Options instead of a single FileOption, | which meant showOptions didn't dosify it. | | Doing a quick hack in showOptions to peek at Options for the /cygdrive/ | prefix keeps the build going. What I'm wondering is: | | Is anyone building GHC on Windows, and if so, how do you do it? | | Thanks, | | Dominic Cooney | | * The command is: | | ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -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-Wcast-align -optc-I../includes -optc-I. | -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer | -optc-DDLLized -O2 -package-name rts -O -Rghc-timing -hisuf dll_hi -hcsuf | dll_hc -osuf dll_o -c Main.c -o Main.dll_o | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: un/dosifyPath in SysTools.lhs bug?
by Simon Peyton-Jones 14 Apr '03

14 Apr '03

I always configure with --with-gcc=c:/mingw/bin/gcc and everything is fine. I see that the Building Guide suggests --with-gcc=/mingw/bin/gcc which I suspect is plain wrong. Try with the path syntax I use, and see if that helps. Meanwhile I'll modify the building guide. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dominic Cooney | Sent: 14 April 2003 09:38 | To: glasgow-haskell-users(a)haskell.org | | I'm trying to build ghc (the 5.04.3 source tarball) on Windows, but right | after the ghc-inplace is written and is used to build something, ghc fails. | If I cut and paste the command* and run it with -v, it's evident that ghc is | trying to execute /cygdrive/c/mingw/bin/gcc, which is the gcc that I | ./configured --with-gcc. | | But ghc is a mingw executable! So I think runSomething in SysTools.lhs, or | whatever calls it, might have a bug. From the comments of runSomething it is | clear that it expects a 'native' program. Anyway, the problem can be fixed | by changing: | | cmd_line = pgm ++ ... | | to: | | cmd_line = (dosifyPath pgm) ++ ... | | And dosifyPath and undosifyPath (#if defined(mingw32_HOST_OS)) have no | regard for drive letters! Shouldn't they be something like: | | unDosifyPath xs = | case (subst '\\' '/' xs) of | drive : ':' : rest -> "/cygdrive/" ++ (drive : rest) | xs' -> xs' | | dosifyPath stuff | = subst '/' '\\' real_stuff | where | -- fully convince myself that /cygdrive/ prefixes cannot | -- really appear here. | cygdrive_prefix = "/cygdrive/" | | real_stuff | | cygdrive_prefix `isPrefixOf` stuff = | case (dropList cygdrive_prefix stuff) of | drive : rest -> drive : ':' : rest | | otherwise = stuff | | That comment re: cygdrive in dosifyPath is rather ominous... but those | changes at least allow ghc-inplace to start compiling the next thing... | | The build then barfed in rts doing: | | ../../ghc/compiler/ghc-inplace -O2 -package-name rts -O -Rghc-timing -c | Exception.hc -o Exception.o | | Because Exception.hc couldn't #include "Stg.h"; it seems the GHC include | path was specified as a couple of Options instead of a single FileOption, | which meant showOptions didn't dosify it. | | Doing a quick hack in showOptions to peek at Options for the /cygdrive/ | prefix keeps the build going. What I'm wondering is: | | Is anyone building GHC on Windows, and if so, how do you do it? | | Thanks, | | Dominic Cooney | | * The command is: | | ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -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-Wcast-align -optc-I../includes -optc-I. | -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer | -optc-DDLLized -O2 -package-name rts -O -Rghc-timing -hisuf dll_hi -hcsuf | dll_hc -osuf dll_o -c Main.c -o Main.dll_o | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: un/dosifyPath in SysTools.lhs bug?
by Simon Marlow 14 Apr '03

14 Apr '03

> I'm trying to build ghc (the 5.04.3 source tarball) on > Windows, but right > after the ghc-inplace is written and is used to build > something, ghc fails. > If I cut and paste the command* and run it with -v, it's > evident that ghc is > trying to execute /cygdrive/c/mingw/bin/gcc, which is the gcc that I > ./configured --with-gcc. I think we usually use a DOS-style path when specifying --with-gcc, which avoids this problem. I'll let someone more windows-savvy answer your other questions... Cheers, Simon

1 0

un/dosifyPath in SysTools.lhs bug?
by Dominic Cooney 14 Apr '03

14 Apr '03

I'm trying to build ghc (the 5.04.3 source tarball) on Windows, but right after the ghc-inplace is written and is used to build something, ghc fails. If I cut and paste the command* and run it with -v, it's evident that ghc is trying to execute /cygdrive/c/mingw/bin/gcc, which is the gcc that I ./configured --with-gcc. But ghc is a mingw executable! So I think runSomething in SysTools.lhs, or whatever calls it, might have a bug. From the comments of runSomething it is clear that it expects a 'native' program. Anyway, the problem can be fixed by changing: cmd_line = pgm ++ ... to: cmd_line = (dosifyPath pgm) ++ ... And dosifyPath and undosifyPath (#if defined(mingw32_HOST_OS)) have no regard for drive letters! Shouldn't they be something like: unDosifyPath xs = case (subst '\\' '/' xs) of drive : ':' : rest -> "/cygdrive/" ++ (drive : rest) xs' -> xs' dosifyPath stuff = subst '/' '\\' real_stuff where -- fully convince myself that /cygdrive/ prefixes cannot -- really appear here. cygdrive_prefix = "/cygdrive/" real_stuff | cygdrive_prefix `isPrefixOf` stuff = case (dropList cygdrive_prefix stuff) of drive : rest -> drive : ':' : rest | otherwise = stuff That comment re: cygdrive in dosifyPath is rather ominous... but those changes at least allow ghc-inplace to start compiling the next thing... The build then barfed in rts doing: ../../ghc/compiler/ghc-inplace -O2 -package-name rts -O -Rghc-timing -c Exception.hc -o Exception.o Because Exception.hc couldn't #include "Stg.h"; it seems the GHC include path was specified as a couple of Options instead of a single FileOption, which meant showOptions didn't dosify it. Doing a quick hack in showOptions to peek at Options for the /cygdrive/ prefix keeps the build going. What I'm wondering is: Is anyone building GHC on Windows, and if so, how do you do it? Thanks, Dominic Cooney * The command is: ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -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-Wcast-align -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DDLLized -O2 -package-name rts -O -Rghc-timing -hisuf dll_hi -hcsuf dll_hc -osuf dll_o -c Main.c -o Main.dll_o

1 0