- Glasgow-haskell-users

Re: GHC and the Lazy Functional State Threads Paper
by Thomas Pasch 03 May '01

03 May '01

> So you can fix it for example by using a specialized version of > freezeArr inside accumArray, of type > (Ix i, IArray a e) => STArray s i e -> ST s (a i e) > This will give quite general type of accumArray: arbitrary immutable > array from the IArray class. freezeArr2:: (Ix i, IArray.IArray a e) => STArray s i e -> ST s (a i e) freezeArr2 = MArray.freeze > If the immutable array type used was particularly UArray, it would > be more efficient to use the corresponding STUArray instead of > STArray, so freezing could just copy a memory block (there are magic > specializations in ghc's libraries for such case). But if the element > type was to remain generic, the type would have to be constrained > over STUArray freezeArr3:: (Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e) => (MArray.STUArray s i e) -> ST s (a i e) freezeArr3 = MArray.freeze Is this the way to do it? I wonder a bit if this triggers the optimization if 'a' is of type STUArray. (By the way I still have problems to see where unboxed values are a good thing and were you should better avoid them.) In addition I wonder why there are so many array types. Are both STArray and IOArray really necessary and what's the difference between them? What about DiffArray? I'm still surprised by operations like 'unsafeFreezeArray' and 'freezeArray'. Shouldn't the garbage collector juge if there are still other references to a distinct object? Regards, Thomas

2 1

Linking vs. shared libs on Unix
by Thomas Pasch 02 May '01

02 May '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 172 kBytes (358k unstripped) and the hello example of the GTK+ bindings is as big as 854 kBytes (2.2 MBytes unstripped), 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

RE: catchAllIO
by Simon Marlow 02 May '01

02 May '01

> Dear all, I keep getting problems with expections. In the example > > catchAllIO ( action ) $ \ any -> return "foo" > > is it guaranteed that *no* exception that is raised in `action' > propagates to the outside? Yes. > (This is with ghc-4.08. Should I upgrade? Well, I will upgrade > sometime anyway, but would it help with respect to this problem?) In GHC 5.00, 'catchAllIO' is now called 'Exception.catch', and the IOError and Exception types are now isomorphic. Various other functions in the Exception library have had names changes too. Cheers, Simon

1 0

RE: ghci, -O
by Simon Marlow 02 May '01

02 May '01

> Now, as I see that ghci can load and run the code made by -O, > I wonder what the User's Guide means by saying > "-O does not work with GHCi". Maybe ghci -O ? > could be meaningful? "ghci -O" is exactly the combination that doesn't work. Cheers, Simon

1 0

Exceptions and sockets
by Johannes Waldmann 02 May '01

02 May '01

OK now I upgraded to ghc-5.00 but the situation didn't change. My suspicion is that it's not the fault of `catch'. I think what happens is this: I `Socket.accept' a connection and get a handle. Now, if the connections dies, but I still write to the handle, the whole thing crashes - without throwing an exception. (I checked that the RTS thinks `hIsWritable h' even if `h' does no longer exist in reality.) How could I work around this? SocketPrim? -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

2 1

catchAllIO
by Johannes Waldmann 02 May '01

02 May '01

Dear all, I keep getting problems with expections. In the example catchAllIO ( action ) $ \ any -> return "foo" is it guaranteed that *no* exception that is raised in `action' propagates to the outside? (This is with ghc-4.08. Should I upgrade? Well, I will upgrade sometime anyway, but would it help with respect to this problem?) Regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0

ghci, -O
by S.D.Mechveliani 02 May '01

02 May '01

I fear there is certain misunderstanding about -O usage with ghc-5.00 interactive. Simon Marlow and User's Guide (Section 4.4) say that > -O does not work with ghci. > For technical reason, the bytecode compiler doesn't interact > well with one of the optimization passes > [..] What is a bytecode compiler? The one that prepares a lightly compiled code for the interpreter? What I meant is something like this: to compile ghc -c -O Foo.hs in the batch mode and then run ghci ... Preude> :load Foo ... Foo> sm [1..9999000] I tried this with certain small function Foo.sm, and it works, and runs better than when compied with -Onot. Now, as I see that ghci can load and run the code made by -O, I wonder what the User's Guide means by saying "-O does not work with GHCi". Maybe ghci -O ? could be meaningful? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

: 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