- Glasgow-haskell-users

RE: ghci unload
by Simon Marlow 09 May '02

09 May '02

> I was wondering if anyone had any suggestions/advice on the > following... I am doing dynamic loading using bits of GHCi and it > all works very nicely. > > occasionally however I want to unload a module and reload > it... this > works fine however I remember from some other post that > the memory from the unload is not reclaimed. This would > explain the slow > memory creap I am seeing. > > So, finally, here's my question: why is it difficault to recover > this memory - is there any way of doing it - remembering that I am > not actually using anything from GHCi apart from the linker The problem, in a nutshell, is that it is difficult to guarantee that there are no references from the heap to objects or info tables in the code object we want to unload. This amounts to providing a hard guarantee that there are no space leaks in your program - we can try hard to make sure we don't have a space leak, but actually *promising* this isn't practical. We considered having the garbage collector flag an error if it found a reference to unloaded code, but decided against it because it would be impossible in general to prevent these kind of bugs. Do you have some measurements on how much memory is being lost over time? I also know of several other ways that GHCi leaks memory during use, so it might not just be the object files. Cheers, Simon

2 1

ghci unload
by Keean Schupke 08 May '02

08 May '02

Hi, I was wondering if anyone had any suggestions/advice on the following... I am doing dynamic loading using bits of GHCi and it all works very nicely. occasionally however I want to unload a module and reload it... this works fine however I remember from some other post that the memory from the unload is not reclaimed. This would explain the slow memory creap I am seeing. So, finally, here's my question: why is it difficault to recover this memory - is there any way of doing it - remembering that I am not actually using anything from GHCi apart from the linker - a typical session might look like. initLinker load [lots of objects...] resolveObjects : load module1 load module2 resolveObjects : unload module1 load module1.1 resolveObjects : etc... Regards, Keean Schupke.

1 0

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