April 2001 - Glasgow-haskell-users

ANNOUNCE: Happy 1.10 released
by Simon Marlow 10 May '01

10 May '01

ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell ----------------------------------------------------------------- I'm pleased to announce version 1.10 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.10 (the previous full release): * bugfixes, and minor performance improvements, * most of the examples work again. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08 or 5.00 recommended), and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to simonmar(a)microsoft.com.

3 3

: RE: haskell.runtime.* ??
by Erik Meijer 30 Apr '01

30 Apr '01

There is a working GHC-to-.Net runtime available at www.mondrian-script.org <http://www.mondrian-script.org/> ; reving the Jva a backend should not be too much of a problem. Erik Message: 1 Subject: RE: haskell.runtime.* ?? Date: Sun, 29 Apr 2001 12:16:24 -0700 From: "Simon Peyton-Jones" < simonpj(a)microsoft.com <mailto:simonpj@microsoft.com> > To: "Kwanghoon Choi" < khchoi(a)ruby.kaist.ac.kr <mailto:khchoi@ruby.kaist.ac.kr> >, < glasgow-haskell-users(a)haskell.org <mailto:glasgow-haskell-users@haskell.org> > I'm afraid that no one ever completed the GHC Haskell->Java story. The idea is that the JVM is the runtime, but of course you need to implement the standard libraries somehow,=20 and all the primitive operations GHC uses. Not a trivial task, but one we are undertaking for .NET. Bottom line: the reason you can't find a runtime is because you are supposed to compile the Java with a Java compiler and run that. But you'll need to do more than that to actually run programs Simon

1 0

Happy 1.10 Windows InstallShield available
by Reuben Thomas 30 Apr '01

30 Apr '01

An InstallShield distribution of Happy 1.10 for Windows is now available from the Happy page (www.haskell.org/happy/)

1 0

RE: memory distribution in ghci
by Simon Marlow 30 Apr '01

30 Apr '01

> > Ah, I see now. You'd like to know how much memory your program is > > using, compared to GHCi itself? Hmm. Unfortunately I > can't see a good > > way to do this I'm afraid. > > In ghci ... +RTS -Mxxxm -RTS > xxx sets the volum bound for > (1) `real' data + > (2) interpreted program + > (3) interfaces of pre-compiled loaded .o modules. > > Please, confirm, whether I understand correct? Yes, that's right. > And many users would like to measure (1) within the ghci loop. > > The statistic like Prelude> List.sort [1..10] > [1,2,3,4,5,6,7,8,9,10] > (0.53 secs, 7109100 bytes) > > includes the number of allocations, which cannot help to detect (1) > (can it?) No, it can't. > This is a user's wish for the future ghci version. > > I do not know, whether it is hard to develop. > If it is hard, personally, I would not suffer much. It's hard, because the three kinds of data you mention above can't easily be separated. It's entirely possible, due to the fact that GHCi is sharing the heap with the running interpreted program, that the data in use by the program could end up pointing to compiler data structures (perhaps because parts of the code are lazilly compiled). Furthermore, having an indication of the memory residency of the interpreted program isn't much of an indication of the residency of a compiled program, which is after all what really matters. If you want speed or memory efficiency, just compile the program. > Another wish: to document the ghci memory management > ------------- > which we are discussing now. > Because GHC could simply give a reference to the manual section. I'll elaborate in the GHCi documentation. > > However, you can always compile the program > > and use profiling... > > Suppose User demonstrates an Haskell application A to the Listener. > Naturally, most of A constitutes its `library' L, and L was > compiled to .o files > (desirably, gathered in the libL.a archive). > > ghci invokes, loads the _interpreted_ demonstration code D, > much smaller than L, but importing items from L. > Naturally, Listener asks something like > "and how much memory needs to compute this matrix?". > > In many other system, the interactive command, say, `:size' > gives immediately some interpreter memory map and the sizes taken > by `code' and `data'. > And you suggest to wait 2 hours to re-compile _everything_ with > profiling. The Listener would not wait. > > >> For, with -O and much in-lining, the interfaces may be very large. > > > You really don't want to use -O with GHCi (in fact, at the > moment you > > can't). > > This may be serious. For example, putStr $ show (sum1 [1..n]) > > will need a constant memory or O(n) memory depending on the -O > possibility. True. But compiling with optimsation takes 2-3 times longer than interpreting - if you're prepared to wait that long, you might as well compile instead. Compiling will give more of a performance boost in general (about 10x) than turning on -O (perhaps 2x). Cheers, Simon

1 0

RE: Shared Libraries
by Simon Marlow 30 Apr '01

30 Apr '01

> In the windows version of ghc, > there seems to be the possiblity to compile > the libraries as shared 'dll's. Is the > same possible for the unix version? > > The question is because I think the ghc > executables are really blown up. A simple > 'Hello, world' has 358 KBytes and the hello > example of the GTK+ bindings is as big as > 2.2 MBytes, although it is link dynamically > against: 358K looks a bit large: is that stripped? I normally see a 150K-ish minimum. Most of that is the runtime system and garbage collector. To answer your question: we don't currently have a way to make shared libraries for Haskell code on Unix boxes. I've made various attempts at this in the past and didn't have much success - take a look back through the glasgow-haskell-{users,bugs} archives for some more info on the topic. BTW, shared libraries aren't that big a deal. You won't see any memory savings unless you've got several Haskell programs running, and there would certainly be a performance hit. Also, there wouldn't be any of the other "hot-swappable" advantages you normally get with shared libraries, because GHC-compiled Haskell libraries tend to have a much more intimate relationship with each other than C libraries. Cheers, Simon

1 0

RE: haskell.runtime.* ??
by Simon Peyton-Jones 29 Apr '01

29 Apr '01

I'm afraid that no one ever completed the GHC Haskell->Java story. The idea is that the JVM is the runtime, but of course you need to implement the standard libraries somehow, and all the primitive operations GHC uses. Not a trivial task, but one we are undertaking for .NET. Bottom line: the reason you can't find a runtime is because you are supposed to compile the Java with a Java compiler and run that. But you'll need to do more than that to actually run programs Simon | -----Original Message----- | From: Kwanghoon Choi [mailto:khchoi@ruby.kaist.ac.kr] | Sent: 25 April 2001 14:13 | To: glasgow-haskell-users(a)haskell.org | Subject: haskell.runtime.* ?? | | | | Hello, | | I managed to restore an option for GHC 5.00 to produce | java output but I realized that I also need some runtime | system to run the java program produced by GHC. I | examined the GHC source tree and the GHC website but in | vain. Where do I get the runtime system? | | Thanks in advance. | | Kwanghoon | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

memory destribution
by S.D.Mechveliani 28 Apr '01

28 Apr '01

Here is another expression of what I wrote recently on the memory destribution. Probbaly, it suffices to have the garbage collection command. For example, Hugs can do Prelude> :gc Garbage collection recovered 240372 cells ... It is clear then, how much the user has for further computation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

memory distribution in ghci
by S.D.Mechveliani 28 Apr '01

28 Apr '01

To my request > [..] > can ghci provide a command measuring the part of heap taken > by interpreted programs, > by interfaces? > (or, at least, their sum) Simon Marlow <simonmar(a)microsoft.com> writes > Ah, I see now. You'd like to know how much memory your program is > using, compared to GHCi itself? Hmm. Unfortunately I can't see a good > way to do this I'm afraid. In ghci ... +RTS -Mxxxm -RTS xxx sets the volum bound for (1) `real' data + (2) interpreted program + (3) interfaces of pre-compiled loaded .o modules. Please, confirm, whether I understand correct? And many users would like to measure (1) within the ghci loop. The statistic like Prelude> List.sort [1..10] [1,2,3,4,5,6,7,8,9,10] (0.53 secs, 7109100 bytes) includes the number of allocations, which cannot help to detect (1) (can it?) This is a user's wish for the future ghci version. I do not know, whether it is hard to develop. If it is hard, personally, I would not suffer much. Because, getting "heap exhausted", one can run ghci once more, with larger xxx, and performing the same computation to detect approximately which part of xxx is taken by the `real' data. But this looks awkward. Another wish: to document the ghci memory management ------------- which we are discussing now. Because GHC could simply give a reference to the manual section. > However, you can always compile the program > and use profiling... Suppose User demonstrates an Haskell application A to the Listener. Naturally, most of A constitutes its `library' L, and L was compiled to .o files (desirably, gathered in the libL.a archive). ghci invokes, loads the _interpreted_ demonstration code D, much smaller than L, but importing items from L. Naturally, Listener asks something like "and how much memory needs to compute this matrix?". In many other system, the interactive command, say, `:size' gives immediately some interpreter memory map and the sizes taken by `code' and `data'. And you suggest to wait 2 hours to re-compile _everything_ with profiling. The Listener would not wait. >> For, with -O and much in-lining, the interfaces may be very large. > You really don't want to use -O with GHCi (in fact, at the moment you > can't). This may be serious. For example, putStr $ show (sum1 [1..n]) will need a constant memory or O(n) memory depending on the -O possibility. The docs on ghc-5.00 say that it joins "the best of the two worlds" - interpreted code calling for the fast code compiled earlier. Generally, I like only scientifically designed `interpreters' and always advised not to spend efforts to .o compilation. But as nobody agrees with me, as the o-compilation fiesta continues, then, why to spend effort in vain? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Shared Libraries
by Thomas Pasch 27 Apr '01

27 Apr '01

Hello, In the windows version of ghc, there seems to be the possiblity to compile the libraries as shared 'dll's. Is the same possible for the unix version? The question is because I think the ghc executables are really blown up. A simple 'Hello, world' has 358 KBytes and the hello example of the GTK+ bindings is as big as 2.2 MBytes, although it is link dynamically against: > ldd hello libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x40025000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40028000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40155000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4018a000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4018d000) libdl.so.2 => /lib/libdl.so.2 (0x401b1000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401b4000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401bc000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401cb000) libm.so.6 => /lib/libm.so.6 (0x402ae000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x402cc000) libc.so.6 => /lib/libc.so.6 (0x402ed000) libpthread.so.0 => /lib/libpthread.so.0 (0x40400000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Best regards, Thomas

1 0

GHC and the Lazy Functional State Threads Paper
by Thomas Pasch 27 Apr '01

27 Apr '01

Hello, to get a better understanding I tried to get the code from 'Lazy Functional State Thread' to work. But I encounter some error messages that I don't fully understand. > module Lfs where > > import PrelGHC > import GlaExts > import ST > import qualified MArray > import qualified Array > > newArr = newSTArray > readArr = readSTArray > writeArr = writeSTArray > -- Error: Ambiguous type variable(s) `ix' in the constraint `Ix ix' > freezeArr = freezeSTArray > > thenST_ a b = a `thenST` \_ -> b > > accumArray bnds f z ivs > = runST > (newArr bnds z `thenST` \a -> > fill a f ivs `thenST_` > freezeArr a) > > fill a f [] = returnST () > fill a f ((i,v):ivs) > = readArr a i `thenST` \x -> > writeArr a i (f x v) `thenST_` > fill a f ivs > > -- in GlaExts: seqST = (>>) > seqST2 = foldr thenST_ (returnST ()) > > accumArray2 bnds f z ivs > = runST > (newArr bnds z `thenST` \a -> > seqST2 (map (update a f) ivs) `thenST_` > freezeArr a) > > update a f (i,v) > = readArr a i `thenST` \x -> > writeArr a i (f x v) > > putString [] = returnST () > -- Error: Couldn't match `ST s a' against `IO ()' > putString (c:cs) = putChar c `thenST_` > putString cs > > -- Error: Couldn't match `ST s a' against `[b]' > putString2 cs = seqST (map putChar cs) > > main = putStrLn "Hello, world" > How to change the code to get it to work? Why is there a different definition of seqST in GlaExts? Best regards, Thomas PS: When I change the definition of the mutable Array to > newArr = MArray.newArray > readArr = MArray.readArray > writeArr = MArray.writeArray > freezeArr = MArray.freeze I get Error in accumArray and accumArray2. I guess this is because of the fact that a STArray is only one possible MArray and there are other possiblities, right?

2 1