- Glasgow-haskell-users

RE: GHCI and Concurrent Haskell?
by Simon Marlow 15 Aug '02

15 Aug '02

> Is it possible to test code using the concurrency features with GHCI? There's one problem: everything stops when the prompt appears in GHCi. This is because our readline interface isn't thread-friendly. Otherwise, concurrency works fine in GHCi. Cheers, Simon

1 0

GHCI and Concurrent Haskell?
by Seth Kurtzberg 15 Aug '02

15 Aug '02

Is it possible to test code using the concurrency features with GHCI? TIA, -- Seth Kurtzberg M. I. S. Corp seth(a)cql.com 1-480-661-1849 (GMT-7)

1 0

intermediate hc files, where
by Ian Zimmerman 14 Aug '02

14 Aug '02

I want to build ghc-5.02.3 from scratch, where can I find the bootstrap files please? The website says they should be listed among the downloads for the release, but this isn't so. Thanks. -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 EngSoc adopts market economy: cheap is wasteful, efficient is expensive.

1 0

RE: duplicate symbols in a package?
by Simon Marlow 14 Aug '02

14 Aug '02

> GHCi runtime linker: fatal error: I found a duplicate > definition for symbol > r1p_closure > whilst processing object file > /grp/haskell/lib/ghc-5.02.2/HSHaXml.o > This could be caused by: > * Loading two different object files which export the > same symbol > * Specifying the same object file twice on the GHCi > command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > GHCi cannot safely continue in this situation. Exiting > now. Sorry. This bug was fixed in 5.02.3, I believe. Cheers, Simon

1 0

duplicate symbols in a package?
by Malcolm Wallace 14 Aug '02

14 Aug '02

Hi GHC users, I am trying to build a package (HaXml) for ghc that will also work in GHCi. I followed the instructions in the manual, to convert the .a file to a .o: ld -r --whole-archive -o HSHaXml.o libHSHaXml.a and installed, ran ghc-pkg, etc. However, now when I start up GHCi, it throws an error: $ ghci -package HaXml ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package posix ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Loading package HaXml ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol r1p_closure whilst processing object file /grp/haskell/lib/ghc-5.02.2/HSHaXml.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. Indeed, running nm on the HSHaXml.o file shows that there are numerous symbols with multiple definitions. Here are just some of them: r13_closure, r13_entry, r13_info, r13_srt, r19_closure, r19_entry, r19_info, r19_srt, r1B_closure, r1D_closure, r1D_entry, r1D_info, r1D_srt, r1IZ_closure, r1J1_closure, r1J1_entry, r1J1_info, r1J1_srt, r1b_closure, r1b_entry, r1b_info, r1b_srt, r1l_closure, r1l_entry, r1l_info, r1p_closure, r1p_entry, r1p_info, s1JM_entry, s1JM_info, s1JZ_entry, s1JZ_info, s1Le_entry, s1Le_info, Any ideas what these are, and how I can avoid them? Regards, Malcolm

1 0

RE: (not) catching ^C in ghc-built application
by Simon Marlow 13 Aug '02

13 Aug '02

> > For a quick workaround, if you install your own handler > *after* calling > > startupHaskell(), you should be able to override GHC's. > > The thing is, that's what I'm already doing. At least, Haskell is > in charge of the execution, and does quite a lot of things before > calling out to an I/O action written in C, which then sets > the handler. > > My best guess is that the use of signal() is incompatible with the > POSIX sigaction() used by the RTS. That's possible I guess. Could you try using sigaction() instead? Cheers, Simon

5 5

RE: (not) catching ^C in ghc-built application
by Simon Marlow 13 Aug '02

13 Aug '02

> I have a program, written in a mixture of Haskell and C, in which the > C part is supposed to handle a ^C interrupt, accomplished through the > usual signal() call. It works as expected when the Haskell part is > compiled by nhc98. But when it is compiled by ghc, for some reason > the ghc RTS appears to trap the interrupt itself, and halts the > program with the message > prog: interrupted > instead of allowing the newly installed C signal handler to run. > > I have looked through the ghc user manual for some means to > turn off or > divert the RTS signal-handling, but I couldn't find anything relevant. > The nearest thing is Exception.block, which excludes an asynchronous > exception from happening whilst the `block' is in operation, but that > doesn't seem to stop a ^C from interrupting the program, so I guess > that isn't its real purpose. > > So, what should I use instead? It's probably quite naughty of us to install a SIGINT handler without checking whether there was already one installed. The relevant code is in ghc/rts/Signals.c around line 359. If you send me a patch I'll incorporate it. For a quick workaround, if you install your own handler *after* calling startupHaskell(), you should be able to override GHC's. Cheers, Simon

2 1

RE: specializations on float
by Simon Marlow 13 Aug '02

13 Aug '02

> the ghc docs suggest using Doubles instead of Floats because GHC > specializes Double but not float...I want to use floats to > save memory and > to test this claim, i grepped through the libraries for the SPECIALIZE > keyword and find that with the exception of a few complex > routines (which > I don't care about), floats are just as specialized as > doubles...is this > the case, or am I missing something? I think you're right, there are just as many specialisations for Float as for Double. I've updated the docs. Cheers, Simon

1 0

RE: withStorableArray making IORefs
by Simon Marlow 13 Aug '02

13 Aug '02

> I'm guessing it's not safe to use "newIORef" as the function > argument to > withStorableArray, but in a simple case [1], it seems to work okay. I > suppose the danger is if the RTS decides to move the array. Does this > happen IRL? The danger is rather that the array might get freed. A StorableArray contains a ForeignPtr to the array, and the finalizer on the ForeignPtr will free the array after the last use. If you obtain a pointer to the array by nefarious means (ie. 'withStorableArray return' would do it) then the RTS might free the array while you still have a pointer to it. Cheers, Simon

1 0

(not) catching ^C in ghc-built application
by Malcolm Wallace 12 Aug '02

12 Aug '02

Hi ghc users, I have a program, written in a mixture of Haskell and C, in which the C part is supposed to handle a ^C interrupt, accomplished through the usual signal() call. It works as expected when the Haskell part is compiled by nhc98. But when it is compiled by ghc, for some reason the ghc RTS appears to trap the interrupt itself, and halts the program with the message prog: interrupted instead of allowing the newly installed C signal handler to run. I have looked through the ghc user manual for some means to turn off or divert the RTS signal-handling, but I couldn't find anything relevant. The nearest thing is Exception.block, which excludes an asynchronous exception from happening whilst the `block' is in operation, but that doesn't seem to stop a ^C from interrupting the program, so I guess that isn't its real purpose. So, what should I use instead? Regards, Malcolm

2 1