December 2002 - Glasgow-haskell-users

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

Re: Native Threads in the RTS
by Wolfgang Thaller 03 Dec '02

03 Dec '02

I've postponed writing up a new proposal again... But I'm going to sum up some requirements that I would like to see fulfilled - to make it clearer to others why I'm proposing such strange things... *) It should be possible for Haskell code to arrange that a sequence of calls to a given library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. *) The specification should be implementable in a way that allows a lot of foreign calls to be made with no additional overhead with respect to GHC's current "unsafe" foreign calls. *) The good performance of the existing lightweight "green" threads in GHC should not be sacrificed. Performance should still OK when using the new features with only a few threads (i.e. not more than commonly used from multithreaded C programs). *) The specification shouldn't explicitly require lightweight "green" threads to exist. The specification should be implementable in a simple and obvious way in haskell systems that always use a 1:1 correspondence between Haskell threads and OS threads. *) The specification shouldn't specify which particular OS thread should be used to execute Haskell code. It should be possible to implement it with e.g. a Haskell interpreter running in one OS thread that just uses other OS threads for foreign calls. *) There should be no unexpected blocking. Especially, threadsafe calls should never cause other threads to block. I'm currently stuck thinking about one particular problem that I discovered in my current version of the spec. What happens when an unbound Haskell thread calls a threadsafe foreign function which in turn calls a bound foreign exported function? Well, I think my current proposal says relatively clearly what's supposed to happen, but I discovered it's not as easy to fit that in the current implementation of GHC as I thought... in fact it might be quite difficult. I'll have to do more thinking before I can be sure, though. That's it for today, Regards, Wolfgang

1 0

RE: :info in ghci
by Simon Peyton-Jones 03 Dec '02

03 Dec '02

It already does... but a bug meant it wasn't always reporting it. Now fixed in the head. SImon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 02 December 2002 16:50 | To: GHC Users Mailing List | Subject: :info in ghci | | Any chance :info could also report fixity information, especially for | symbolic identifiers? | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

:info in ghci
by Hal Daume III 03 Dec '02

03 Dec '02

Any chance :info could also report fixity information, especially for symbolic identifiers? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Java back end
by Mark Carroll 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. -- Mark

1 0

help for "Killed"
by Dean Herington 02 Dec '02

02 Dec '02

I have a program that dies, saying simply "Killed". How can I tell what that means? I presume the program is suffering a ThreadKilled exception, and I guess it may be due to stack or heap overflow. (The program is processing a 50MB file.) Profiling, even with -xc, yields no information. Dean

2 1

RE: Native Threads in the RTS
by Simon Peyton-Jones 02 Dec '02

02 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? Simon

1 0