- Glasgow-haskell-users

�бz�p�󦨬��u�{�v
by mlpi_uy_rff3d1w＠amazon.com 04 Dec '02

04 Dec '02

1 0

RE: ANNOUNCE: GHC version 5.04.2 released
by Simon Marlow 04 Dec '02

04 Dec '02

> ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 5.04.2 > ============================================================== > > We are pleased to announce a new patchlevel release of the Glasgow > Haskell Compiler (GHC), version 5.04.2. This is a bugfix-only > release. For all the changes since 5.02.3, see the release notes: > > > http://www.haskell.org/ghc/docs/latest/users_guide/release-5-04.html Oops, that URL should be http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.htm l Cheers, Simon

1 0

RE: Native Threads in the RTS
by Simon Marlow 03 Dec '02

03 Dec '02

> | 2. Calling from foreign code into Haskell to a bound foreign import > will > | require some special handling to ensure that a subsequent > call out to > | foreign code will use the same native thread. Why couldn't this > special > | handling select the same Haskell thread instead of creating > a new one? > > This is just an efficiency issue, right? If creating a > Haskell thread > from scratch is very cheap, then it's easier to do that each > time rather > than to try to find the carcass of a completed Haskell > thread. If you > do the latter, you need to get into carcass management. > > But maybe there is more to it than efficiency in your mind? To recap, the suggestion was that a Haskell thread which makes a foreign call, which is turn calls back into Haskell, should use the same Haskell thread for the callback. So the Haskell thread is not a carcass, it is still running, but blocked waiting for the result of the foreign call. I'm not sure I've quite got my head around all the implications of doing this, but it sounds possible. However, I'm not completely convinced it's desirable: the gain seems to be in efficiency only, and a fairly small one (creating threads is quite cheap). I imagine you could demonstrate a performance gain by doing this for an application which does a lot of callbacks, though. The current situation has the advantage of simplicity: * for each 'foreign export' we create a single Haskell thread which lives until completion of the IO action. We can consider a standalone program as a call to 'foreign export main :: IO a' from a simple C wrapper (in fact, that's almost exactly how it works). Cheers, Simon

3 2

RE: :info in ghci
by Simon Marlow 03 Dec '02

03 Dec '02

> Ah...but if the fixity is not explicitly specified (and thus > defaults to > infixl 9), this isn't printed, which is what was catching > me...it seems it > should be (or perhaps say "infixl 9 (default)")? But every variable has a fixity, including normal identifiers... should we report the default fixity for those too? Cheers, Simon

2 1

RE: :info in ghci
by Simon Marlow 03 Dec '02

03 Dec '02

> It already does... but a bug meant it wasn't always reporting it. > > Now fixed in the head. ... and the bug doesn't exist in 5.04.1. Cheers, Simon

2 1

RE: Native Threads in the RTS
by Simon Marlow 03 Dec '02

03 Dec '02

> 2. It seems perfectly reasonable to want to have the Haskell > called-back code throw an exception that is caught by the Haskell code > that called out to foreign code. "Reusing" the Haskell thread is > necessary (though not sufficient) to achieve such behavior. This is a particularly tricky problem, and I prefer to leave it up to the programmer to handle such things. Propagating the exception to the original (Haskell) caller automatically is unlikely to be the right thing to do, because the foreign code will almost certainly want to do some clean up. If the foreign language supports exceptions then it is conceivable that we could turn a Haskell exception into a foreign exception (and vice-versa), but for plain C I think we should leave well alone. Cheers, Simon

1 0

RE: Request: suppress specific warnings at specific places
by Simon Marlow 03 Dec '02

03 Dec '02

> This doesn't seem to work (easily) for me. I want -Wall applied to > all my source, so give it on the command line. Because the OPTIONS > options get prepended, the -Wall seems to win out. :(. I could add > -Wall at the top of all my source files, but that's unappealing. If > GHC provided a way to have a command-line options appear before the > OPTION options in the final list, that would work. That's odd - it works here. OPTIONS pragmas are supposed to override the command line, and indeed in a small example I just tried I can override individual warnings in the OPTIONS pragmas with -Wall on the command line. Cheers, SImon

1 0

RE: Java back end
by Simon Marlow 03 Dec '02

03 Dec '02

> I was wondering, what happened to the Java back end that was going to > produce bytecode - how's it going? Is it now at all > available? I'm having > some difficulty finding it, and it sounded interesting. There's one in ghc/compiler/javaGen, but it hasn't worked for a long time (and never really worked, as far as I can tell). I think Andy Gill <andy(a)galois.com> was responsible for that one, you might want to contact him. Cheers, Simon

1 0

RE: 'accept' does not seem to be thread friendly ..
by Simon Marlow 03 Dec '02

03 Dec '02

> Below is my sample code ; the Net Cats > This does not work, because 'accept' fuction of the > Network module blocks the whole process, unlike > Haskell Standard IO functions which blocks its thread > only. How did you work around with complex networked > applications ? It would be very helpful if you could > give us more detailed advice from your expierience. > > Network.accept does not seem to be thread friendly. > Then how am I going to keep my server from being blocked > by accept? I'm not sure exactly what your program is supposed to be doing, but as far as I can tell it's working fine :-) While the accept is waiting for a connection, the thread doing the accept has taken the MVar, thus blocking the other thread which is also trying to take the MVar. I think this is perhaps not what you had in mind? Cheers, Simon

1 0

Network Programming with Haskell ?
by Ahn Ki-yung 03 Dec '02

03 Dec '02

No select or poll functions in Network module yet ? listenOn and accept isn't enough for network programming. IO multiplexing is needed. It was a wish list. -- Ahn Ki-yung

3 3