May 2002 - Glasgow-haskell-users

RE: building 5.03 from source and illegal buffer size
by Simon Marlow 08 May '02

08 May '02

> I just grabbed 5.03 from cvs and built it. Everything worked > fine, except > when I go to compile using ghc-inplace, it tells me: > > invalid argument > Action: hPutBuf > Handle: {closed} > Reason: illegal buffer size 0 > > It appears able to generate the .hi file, but not the .o. I > ran with -v and attached the transcript. I see you're using 5.02.1 to build with - could you perhaps upgrade to 5.02.3 and try again? Cheers, Simon

1 0

bug in ghc with {| |}
by Hal Daume III 07 May '02

07 May '02

in ghci: NLP.Clustering> let x = 5x {| Int |} *** Exception: typecheck/TcExpr.lhs:168: Non-exhaustive patterns in function tcMonoExpr i have no idea what {| and |} do, but i was messing around with them and typed this in by accident and it raised an exception. fyi. -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

building 5.03 from source and illegal buffer size
by Hal Daume III 07 May '02

07 May '02

Hi all, I just grabbed 5.03 from cvs and built it. Everything worked fine, except when I go to compile using ghc-inplace, it tells me: invalid argument Action: hPutBuf Handle: {closed} Reason: illegal buffer size 0 It appears able to generate the .hi file, but not the .o. I ran with -v and attached the transcript. If anyone has any ideas, please let me know :) (oh, when building i used the build.mk.sample as is and this is on sparc solaris 2.7). Thanks! - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

RE: -fspecialize-all or the like?
by Simon Peyton-Jones 07 May '02

07 May '02

Actually, GHC does automatically specialise for all types at which the function is called in that module, but it doesn't do it across modules. Why not? Because it compiles bottom-up, whereas the specialisation info is really top-down. Have often thought that we could spit out specialisation info into .spec files, and have some separate program to eat up all the .spec files and produce specialisation pragmas for all the modules... but never got around to it. It would produce quite a worthwhile speedup though, if anyone feels inclined to tackle it. (If anyone does, I have a good plan of action in my head.) Simon | -----Original Message----- | From: Simon Marlow [mailto:simonmar@microsoft.com] | Sent: 22 April 2002 10:15 | To: Hal Daume III; GHC Users Mailing List | Subject: RE: -fspecialize-all or the like? | | | | > Is there any way to get your overloaded functions to | > basically behave like | > templates in C++; i.e., by "automatically" inserting {-# SPECIALIZE | > ... #-} for every function, for every instance, for each | type that is | > actually used in the program? | | Short answer: no. Sorry :) | | Simon | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

RE: What's the '0' for in the version number?
by Simon Marlow 06 May '02

06 May '02

> Why is it GHC "5.02.2", "5.03" etc.? Wouldn't it be easier > with "5.2.2", "5.3"? I don't know, probably historical reasons: as far as I can remember, GHC's version numbers always had two digits after the decimal point. For historians, here is the announcement of the first release of GHC (0.06) archived thanks to Google: http://groups.google.com/groups?selm=16945.9203281558%40dcs.glasgow.ac.u k&output=gplain Cheers, Simon

2 1

RE: Weird porting problem with read
by Simon Marlow 06 May '02

06 May '02

> Well, I figured it out myself in the end... it's gcc dodginess :/ > > numberToInt checks the number that's been read against > minBound :: Int. > In the 64-bit STG C code this ends up being: > > _Cak7_=(-9223372036854775808)<=(I_)(R1.p[1]); > > If I were to read the gcc warnings it would say: > > Text/Read/Lex.hc:40: warning: decimal constant is so large that it is > unsigned > > and it seems to make a dodgy optimisation on that basis. > > If I change the constant to -(2^63-1) instead of -2^63 it works, and > without the warning message. Which seems like a compiler bug to me, > since -2^63 is a valid 64-bit signed number. I'll see what the gcc > folks have to say. I've had similar problems before with minInt. I seem to recall that the C standard doesn't guarantee that this constant is representable in the int type: I think it has to do with the fact that the C standard doesn't proscribe 2's complement arithmetic, and in 1's complement you can't fit -2^63 in an int. Cheers, Simon

1 0

Weird porting problem with read
by Matt Chapman 05 May '02

05 May '02

Background: I'm working on porting GHC to IA64. I have the initial unregisterised port mostly working, except for a weird problem related to this innocent bit of code (ghc/compiler/main/CmdLineOpts.hs): opt_HiVersion = read (cProjectVersionInt ++ cProjectPatchLevel) :: Int where: cProjectVersionInt = "503" cProjectPatchLevel = "0" I get... ghc-5.03: panic! (the `impossible' happened, GHC version 5.03): Prelude.read: no parse Possibly of relevance is that cProjectVersionInt is built using unpackCStringList#, whereas cProjectPatchLevel was generated statically. Below I've included an ASCII art depiction of the closure that is passed to read, after evaluation (i.e. I breakpointed after the parse error). It looks feasibly correct to me, although I may be missing something. Does anyone have any hints on where to proceed from here? Matt CmdLineOpts_lvl42_closure IND_STATIC(0x504af380) | IND(0x504af418) | CONSTR(GHC.Base_C_con_info(tag=1), 0x504af3d8, 0x504af400) | | CONSTR(GHC.Base_C#_con_info(tag=0), 0x35#) | _____________________| | IND(0x504b0018) | CONSTR(GHC.Base_C_con_info(tag=1), 0x504affc8, 0x504b0000) | | CONSTR(GHC.Base_C#_con_info(tag=0), 0x30#) | _____________________| | IND(0x504b09f0) | CONSTR(GHC.Base_C_con_info(tag=1), 0x504b09b0, 0x504b09d8) | | CONSTR(GHC.Base_C#_con_info(tag=0), 0x33#) | _____________________| | IND(Config_cProjectPatchLevel_closure) | CONSTR(GHC.Base_C_static_info(tag=1), Config_a_closure, GHC.Base_[]_closure) | | CONSTR(GHC.Base_C#_static_info(tag=0), 0x30#) | __________________________| | CONSTR(GHC.Base_[]_static_info(tag=0))

1 1

What's the '0' for in the version number?
by Ashley Yakeley 04 May '02

04 May '02

Why is it GHC "5.02.2", "5.03" etc.? Wouldn't it be easier with "5.2.2", "5.3"? -- Ashley Yakeley, Seattle WA

1 0

Building GHC 5.02.3 from bootstrap.
by Thomas L. Bevan 03 May '02

03 May '02

Hi all, In spite of all the warnings, I tried to build ghc 5.02.3 from scratch. The first step, > ./distrib/hc-build returned the error >make[1]: *** No rule to make target `Addr.o', needed by `libHSlang.a'. Stop. >make: *** [all] Error 1 I'm actually building on a standard Linux x86 platform. The resaon I want to build from scratch is to incorporate GHC into the portage source tree for the Gentoo distribution, http://www.gentoo.org Tom

1 0

infix type constructors
by Okasaki, C. DR EECS 03 May '02

03 May '02

I'm not sure how long this has been implemented in GHC, but I just noticed that infix type constructors are allowed, as in data a :- b = ... The syntactic asymmetry between type constructors and data contructors has bothered me for a while, so this is a welcome change! However, this syntax seems to be supported for "data" and "newtype" declarations, but not for "type" declarations. For example, type a :- b = ... does not seem to be allowed. Is there a reason for this? Or was it just an oversight? -- Chris

1 0