- Glasgow-haskell-users

RE: updating labelled fields
by Simon Peyton-Jones 10 May '02

10 May '02

| So, as it stands the proposal is to add the following pieces of sugar: | | 1) ({assignments}) becomes \x->x{assignments} | 2) x{as, field =, bs} becomes \y->x{as, field = y, bs} | 3) x{as, field, bs} becomes \f->x{as, field = f (field x), bs} ... | Assuming I can ever get my cvs'd copy of ghc to compile | (sigh), I would be willing to implement this if there are no | objections... Hal, it's fine for you to modify and distribute your copy of GHC, of course, but I'm not yet convinced that Simon and I want to put this change in the mainstream GHC. It's easier to add a feature than to remove it, and GHC already arguably suffers from feature-itis. (Perhaps, though, people will love your change and nag us to put it in. The more people that ask the keener we are to do something.) While you are thinking about implementation, don't forget the type checking part. I recall that correct type checking of Haskell records was a bit harder than it looked. Incidentally, I'm working with Tim Shead on a sort of meta-programming facility (somewhat like a fully-integrated Drift, only typechecked) that would let you generate update functions for each field automatically; that might help towards the same goal. Simon

1 0

RE: module namespaces with "Prelude"
by Simon Marlow 09 May '02

09 May '02

> All in all, dropping all implicit directories from the search > path gets my vote. "me too". I wasn't aware that Hugs did this, and GHCi certainly doesn't. It's reasonable to leave "." in the default search path, but adding an implicit root for an imported module will certainly lead to trouble - after all, we use hierarchical module names because the modules at the leaves of the tree are expected to overlap. Cheers, Simon

3 2

RE: ghci unload
by Simon Marlow 09 May '02

09 May '02

> Hmm, I have noticed a similar problem already... If I fork a thread on > some > loaded code which accesses some MVars, then unload the code > it SegFaults > - > however if I wait for the thread to terminate using another > MVar before > unloading > it works fine... On this basis it seems that you still can't guarantee > that the GC > won't fall over . This sounds like it might just be a bug. Can you boil it down to a small example which repeatably triggers the seg fault? > Is there no way of garbage collecting the object code (maybe using > some kind of finaliser) so that we free it when finished with > - avoiding > the problems > with forked threads as well? Finalizers (in the ForeignPtr sense) don't work well for object code because the pointers from the heap aren't just to closures: they are to info tables too, which aren't tracked by the garbage collector. It would theoretically be possible to build some special support into the garbage collector to reclaim object code when it is finally released, but it would be a lot of work for little benefit: GHCi is really just a development environment, it really isn't intended to be a platform for long-running programs. > As for the space leak... I have now noticed two different > space leaks - > one occurs whether or > not anything is reloaded - and is about 4K every time a > function from a loaded module is called. Are you sure this isn't just GHC's memory allocator claiming a new page? How did you measure this? > The other - on restart is about 100K - the modules being reloaded are > about 60K on disk - > so there appears to be another 30-40K loss. There will be some space allocated for the symbol table for the module, and various other structures. An extra 50% doesn't sound too unreasonable. Cheers, Simon

1 0

Re: ghci unload - profiling
by MR K P SCHUPKE 09 May '02

09 May '02

Just a quick addition to my previous question- using the ghci linker to load object code, I am currently using the following files from the system libraries: HSstd.o HSstd_cbits.o HSlang.o HSlang_cbits.o HSdata.o HStext.o HSnet.o HSconcurrent.o HSutil.o HSutil_cbits.o HSposix.o HSposix_cbits.o However, when tring to profile the code I need to load profiling versions of these objects, but the ghci-linkers loadObject doesn't appear to be able to load the libHSstd_p.a (nor the libHSstd.a) library... how do I get the ghci-linker to link my profiling objects against the profiling versions of the system libraries. Keean.

1 0

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