September 2002 - Glasgow-haskell-users

GHC for Linux/PPC on Mac?
by Till Mossakowski 13 Sep '02

13 Sep '02

Is there such a thing? planned? I've seen nothing on the download page. Till -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

2 1

Feature request for ghci
by Martin Norbäck 13 Sep '02

13 Sep '02

Assume this situation Test/ Foo.hs <- this is module Test.Foo Bar.hs <- this is module Test.Bar Test.Foo imports Test.Bar If I cd into Test, and do ghci Bar.hs everything is fine, module Test.Bar is loaded. If I do ghci Foo.hs it complains about not being able to find Test.Bar. My request is that ghci looks "up" in the hierarchy and assumes that the user wants too look for modules in .. if the module Test.Foo lies in the file Foo.hs Of course this will not always work, symlinks and other things, but it would be useful. Now I have to do "cd ..; ghci -i. Test.Foo" instead. Regards, Martin -- Martin Norbäck Safelogic AB martin.norback(a)safelogic.se Stena Center 1C +46 (0)31 772 81 70 S-412 92 GÖTEBORG http://www.safelogic.se SWEDEN

2 1

Re: Time out
by George Russell 12 Sep '02

12 Sep '02

Simon M wrote (snipped) > Perhaps we should bite the bullet and have non-interruptible versions of > some of the blocking operations, including throwTo. I would certainly appreciate this! There is a long-standing bug (or at least misfeature) in my events code which means you can't send asynchronous exceptions to threads which use it, because of the difficulty of doing takeMVar/putMVar under these conditions. It would be possible to avoid this currently by putting in several calls to block and unblock to make sure that MVars which are supposed to be normally full really are normally full, but this is apparently costly.

1 0

RE: creating a library from haskell files and a c wrapper in Linux
by Simon Marlow 11 Sep '02

11 Sep '02

> Doesn't work, as in won't compile, or doesn't work as in it > compiles and links > but won't run? Probably doesn't compile. One (big) reason is that -fPIC and GHC will both try to steal the same register on x86. Cheers, Simon

1 0

RE: Time out
by Simon Marlow 11 Sep '02

11 Sep '02

> On Tuesday 10 September 2002 03:58 am, Simon Marlow wrote: > > > With asyncrhonous exceptions as they are implemented > currently, you only > > need one extra thread. If we ever get around to changing > the semantics > > as per the async exceptions paper, then you'll probably need two > > threads. > > How do they differ, precisely? Is it whether throwTo is > synchronous or > asynchronous? I seem to recall that we changed the semantics from > synchronous to asynchronous, late-ish in the game, in order > to stream-line the semantics. I think it was also because we were having trouble implementing some of the combinators in a robust way using the synchronous version. The problem is that with the synchronous semantics, throwTo must be an interruptible operation, which makes it hard to guarantee not to raise exceptions in certain critical regions. > Is there any reason (other than lack of time) > not to bring GHC in line with the paper? I just have a niggling feeling that the asychronous version isn't really the right thing. For one, you can implement the asynchronous version easily in terms of the synchronous version by forking a thread. Also, implementing the asychronous version natively is slightly more tricky. And implementing some combinators (like timeout) require two threads with the async version, but only one with the sync version. Perhaps we should bite the bullet and have non-interruptible versions of some of the blocking operations, including throwTo. Cheers, Simon

1 0

RE: creating a library from haskell files and a c wrapper in Linux
by Simon Marlow 11 Sep '02

11 Sep '02

> Speaking solely from the gcc side, if you can capture all the > compilation > commands, add "-PIC", and then grab the ld flags and change > the options > there, everything should work. This is, obviously, not > terribly convenient > but anything that links as a binary should work as a shared > library as well. > Simon, am I missing something? Yes :-) -fPIC doesn't work for the code generated by GHC. You can make shared libraries without -fPIC, but that also imposes constraints on the code, constraints which the code generated by GHC doesn't satisfy at the moment. I can't remember the exact details, but John Levine's Linker book is a good place to start. Cheers, Simon

2 1

RE: Time out
by Simon Marlow 11 Sep '02

11 Sep '02

> What is the recommended way of implementing the function: > > timeOut :: Int -> IO a -> IO (Maybe a) > > which takes a maximum number of seconds (say), an IO action, > and tries to run the IO action in the specified time. If it > succeeds, it returns just the answer, otherwise it returns > Nothing. > > Do I have to start two threads, one that waits and then > throws an exception, the other that evaluates the IO action? > > Or is there a better way? (I thought of asynchronous > exceptions...) With asyncrhonous exceptions as they are implemented currently, you only need one extra thread. If we ever get around to changing the semantics as per the async exceptions paper, then you'll probably need two threads. Anyway, the way to do it is: - fork off a thread which sleeps for the specified period and then raises an exception in the parent thread - in the parent thread, run the IO action. If it completes, kill the child thread. You are guaranteed by the semantics of killThread that both threads can't kill each other simultaneously. Cheers, Simon

2 1

RE: creating a library from haskell files and a c wrapper in Linux
by Simon Marlow 11 Sep '02

11 Sep '02

> I want to make a library that can be used to link against from C code. > > This library contains Haskell code, and I've made some C code to > interface with the Haskell code, using startupHaskell and > shutDownHaskell. > > I want to make a self-contained library (which will contain > the Haskell > run-time code, the Haskell code, and the C interface code) that I can > link to without having to use ghc to link. I also would like to make > this library dynamic so that I can dlopen it later. > > When I link the .o files with to produce an executable (with gcc) > everything works fine. I get a binary that does what it should. > > I don't see the reason why I shouldn't be able to link dynamically > against the same .o files when they are in a dynamic library. > > And whatever the reason is, how much work do you think it will take to > fix it? And how easy is it? It's not easy, I'm afraid. The ELF dynamic linking mechanism is rather arcane and imposes a very C-like view of things on object files. Last time I looked into this, I concluded that it couldn't be done without sacrificing some of GHC's low-level optimisations (specifically, placing code next to data), and even then it would still be a lot of work. However, I've been surprised before by what dynamic linkers can do, so it might be worth looking into again. Anwyay, take a look through the archives of this list for more details. Cheers, Simon

1 0

RE: creating a library from haskell files and a c wrapper in Linux
by Martin Norbäck 11 Sep '02

11 Sep '02

tis 2002-09-10 klockan 16.39 skrev Simon Marlow: > > > tis 2002-09-10 klockan 16.08 skrev Martin Norbäck: > > > Now I have done the following: > > > > > > # ghc -fglasgow-exts -c Adder.hs > > > # gcc -c -DDLL_IMPORT= -I/usr/lib/ghc-5.04/include dllMain.c > > > # ld -shared -o adder.so Adder.o Adder_stub.o dllMain.o > > > -L/usr/lib/ghc-5.04 -lHSbase -lHSbase_cbits -lHSrts -lHSbase -lgmp > > > # gcc test.c -L. -ladder > > > # env LD_LIBRARY_PATH=. ./a.out > > > > > > and then I get the following: > > > > > > a.out: fatal error: LOOKS_LIKE_GHC_INFO- is incorrectly defined > > > > > > What to do next, I wonder... > > > > Here are the files used so you can test for yourself. Oh, and adder.so > > above should be libadder.so. > > You can't make a dynamic library containing Haskell code on Unix, sorry. What actually is it you're trying to do? I want to make a library that can be used to link against from C code. This library contains Haskell code, and I've made some C code to interface with the Haskell code, using startupHaskell and shutDownHaskell. I want to make a self-contained library (which will contain the Haskell run-time code, the Haskell code, and the C interface code) that I can link to without having to use ghc to link. I also would like to make this library dynamic so that I can dlopen it later. When I link the .o files with to produce an executable (with gcc) everything works fine. I get a binary that does what it should. I don't see the reason why I shouldn't be able to link dynamically against the same .o files when they are in a dynamic library. And whatever the reason is, how much work do you think it will take to fix it? And how easy is it? Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

2 1

RE: Time out
by Simon Marlow 11 Sep '02

11 Sep '02

> > In FFI code you have to be more careful [about killing > threads], however. > > It's clear there's a bunch of bad things could happen here - but not > obvious what does happen. > > Does killing a thread that is calling a C function kill it immediately > (i.e., before the call completes) or wait until the C function > finishes? The thread can only receive an exception while running Haskell code. That means that in an 'unsafe' C call, the thread can't receive an exception until the call returns, but a thread doing a 'safe' C call may receive an exception if the call re-enters Haskell. Either way, you don't have to worry about being killed in the middle of C code, which would be completely impossible to deal safely with. Cheers, Simon

1 0