- Glasgow-haskell-users

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

26 Nov '02

| I've now written up a slightly more formal proposal for native threads. | (OK, it's only a tiny bit more formal...) | I doubt I have explained everything clearly, please tell me which | points are unclear. And of course please tell me what you like/don't | like about it. Great, thanks. I hope you'll keep it up to date so that by the time the discussion converges it can serve as a specification and rationale. We can put it in CVS too... Simon will think of where! Ultimately it'd be worth integrating with http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi-thread. html Simon | A "native" haskell thread and all foreign imported functions that it | calls are executed in its associated OS thread. This part is ok | A foreign exported | callback that is called from C code executing in that OS thread is | executed in the native haskell thread. This is the bit I don't understand. Is the only scenario you have in mind here native Haskell thread calls C which calls Haskell and you want all that in the same native thread? What about this? native Haskell thread calls C which installs a pointer to a foreign-exported Haskell function in some C data structure Later... some other Haskell thread calls C which waits for an event which calls the callback So the callback was installed by a native thread, but won't be executed by it. Is that ok? Anyway I think it would be worth explaining what is guaranteed a bit more clearly. | If a "green" haskell thread enters a foreign imported function marked | as "safe", all other green threads are blocked. Native haskell threads | continue to run in their own OS threads. No, I don't think so. The reason that 'safe' is cheaper than 'threadsafe' is that the current worker OS thread does not need to release the Big Lock it holds on the Haskell heap, thereby allowing other green threads to run. Instead, it holds the lock, executes the call, and returns. At least I think this is the idea, but it's all jolly slippery. | Other things I'm not sure about: Presumably if a native thread spawns a thread using forkIO, it gets just a green thread? If it used forkNativeThread it gets a distinct native thread. Better say this.

6 8

RE: Template metaprogramming for Haskell article.
by Simon Peyton-Jones 26 Nov '02

26 Nov '02

At the moment you have to build from source to get it, or you can grab a development snapshot binary, from http://haskell.cs.yale.edu/ghc/download.html We're swithering about when to do a full release. Template Haskell is still moving, and making a release takes time. We'll be strongly affected by GHC users on this: if you really want TH and the snapshot route or build-from-source don't work for you, let us know. Simon | -----Original Message----- | From: Immanuel Litzroth [mailto:immanuell@enfocus.be] | Sent: 25 November 2002 12:57 | To: glasgow-haskell-users(a)haskell.org | Subject: Template metaprogramming for Haskell article. | | | I am reading the article template meta-programming for haskell and am | wondering if | 1) this is already implemented in ghc. | 2) if not when this will be released | Thanks in advance | Immanuel | | ******************************************************************** | ******* | His endeavours to improve these conditions by innovations in the | current methods of teaching are fully described in his writings; these | made him unpopular with his brethren in the order and led to his | removals to the monastery of Pomposa near Ferrara, Italy. Here the | same lot seems to have befallen him. | About Guido of Arezzo | | Immanuel Litzroth | Software Development Engineer | Enfocus Software | Kleindokkaai 3-5 | B-9000 Gent | Belgium | Voice: +32 9 269 23 90 | Fax : +32 9 269 16 91 | Email: Immanuell(a)enfocus.be | web : www.enfocus.be | ******************************************************************** | ******* | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: RFC: External library infrastructure
by Simon Marlow 26 Nov '02

26 Nov '02

> I'd like to throw the following into the pot: > > The Hugs and GHC developers work pretty hard to keep the two > compilers compatible. For example, the next Hugs release will ship > with libraries from the same source tree as GHC uses and the same > foreign function interface as GHC and the GHC folk recently gave up > a feature they dearly wanted in the foreign function interface in > the name of portability. > > So as people try to come up with a distribution and build mechanism > that will work for GHC, it would be good to think about how that > same mechanism would work for Hugs too. Absolutely. I didn't mean to sound so GHC-centric. It would be great if the same infrastructure supports multiple compilers/interpreters. > For example, an extension > of GHC's existing package mechanism might work well because it would > be easy for Hugs to extract the pieces it needs and the package > mechanism has little irrelevant stuff. In contrast a variation on > the existing Makefile system would work poorly because the > complexity for the library developer of buying into the > infrastructure far exceeds the complexity of the task (which for > Hugs is overcoming a few minor platform dependencies using autoconf > or the like, building any foreign function interface libraries, and > overcoming a few remaining Hugs-GHC incompatabilities). Could you be more concrete? What extension of the package mechanism did you have in mind? (personally I had in mind a standard autoconf + Makefiles story for the build system, but I'm sure there are better ways). It'll be tricky to balance the requirements of a glorious all-encompassing infrastructure with keeping a low "buy-in" cost (as you put it), but that must be one of the goals or we won't have achieved anything. > We might also want to develop a common testing infrastructure for > libraries which, ideally, would work with all compilers. Right on. I'd like to propose we start from GHC's current testing system. It's a small collection of Python scripts (about 900 lines), and is designed to be compiler-independent, although I haven't used it with anything except GHC yet. Cheers, Simon

4 4

Re: re-opening a closed stdin?
by Albert Lai 26 Nov '02

26 Nov '02

"Simon Marlow" <simonmar(a)microsoft.com> writes: > It is nice, but it introduces too many problems. What happens to any > I/O errors encountered by the lazy I/O? They have to be discarded, > which means you can't effectively use lazy I/O for robust applications > anyway. Damn, I forgot that "file" means file in the real world, not Platonic file! I now agree that it is actually not nice.

1 0

-O doesn't work with gcc-3.2?
by Anatoli Tubman 25 Nov '02

25 Nov '02

ghc fails with this message: Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl %esp, %ebp It works without -O. I'm on stock Mandrake 9.0 system. How do I overcome this? tia -- anatoli

3 3

Re: Template metaprogramming for Haskell article.
by C.Reinke 25 Nov '02

25 Nov '02

> I am reading the article template meta-programming for haskell and am > wondering if > 1) this is already implemented in ghc. > 2) if not when this will be released answered in section 2.1 (GHC) and 3.6.1 (Template Haskell) of the Haskell Communities & Activities Report (November 2002 edition): http://www.haskell.org/communities/11-2002/html/report.html#sect2.1 http://www.haskell.org/communities/11-2002/html/report.html#sect3.6.1 Claus PS. Are there readers of ghc-users who don't read the main haskell list (I didn't want to spam all Haskell-related lists with the announcements, but keep getting the feeling that not everyone is following the main list anymore)?

1 0

RE: re-opening a closed stdin?
by Simon Marlow 25 Nov '02

25 Nov '02

> Simon Marlow wrote: > > > > Simon Marlow: > > > > [Lazy I/O] is nice, but it introduces too many problems. What > > > > happens to any I/O errors encountered by the lazy I/O? > They have to > > > > be discarded, which means you can't effectively use lazy I/O for > > > > robust applications anyway. > > > > > > Surely they are thrown as exceptions which can then be manipulated > > > in pure code using > > > > > > mapExceptions :: (Exception -> Exception) -> (a -> a) > > > > > > and caught in the IO monad using catch? > > > > No, the report clearly states that they are discarded. > > Could you please point out where? I couldn't find it with a > quick look. Section 11.2.1 in the Library Report, last paragraph. > > We could perhaps have our own versions of the lazy I/O > operations which > > throw exceptions, but this in itself is problematic because > these kind > > of exceptions would be asynchronous in nature. If lazy I/O > is allowed > > to raise exceptions, then we have a situation where > evaluating anything > > can raise an I/O exception. In theory this shouldn't be a > problem - we > > all ought to be writing asynchronous-excpetion-safe code anyway to > > protect against StackOverflow, but an I/O exception is > often one that > > you want to handle gracefully and recover from. I feel distinctly > > uncomfortable about I/O exceptions being thrown by pure > code, and even > > more uncomfortable about asynchronous I/O exceptions. > > Is even the following example from the library report (section 11.8.2) > problematic? > > import System > import Char( toUpper ) > > main = do > [f1,f2] <- getArgs > s <- readFile f1 > writeFile f2 (map toUpper s) It depends what you want to happen in the event of a I/O error in the file being read. If you want to reliably clean up, say remove f2 and emit a helpful message, then as Haskell 98 stands you can't do it. If we were to make the lazy I/O raise an exception in the event of an error, then you can do the cleanup, but you have to know which computations can force the lazy I/O and wrap appropriate exception handlers around them. Knowing which computations can force the I/O is problematic. There *is* a reasonable semantics for readFile: read the whole file immediately. You don't have to generate the Haskell String eagerly, just read the whole file into a cache and report any I/O errors. This doesn't work too well for large files, or for using readFile/getContents to write stream processors though. Cheers, Simon

1 0

RE: re-opening a closed stdin?
by Simon Marlow 25 Nov '02

25 Nov '02

> Simon Marlow: > > [Lazy I/O] is nice, but it introduces too many problems. What > > happens to any I/O errors encountered by the lazy I/O? They have to > > be discarded, which means you can't effectively use lazy I/O for > > robust applications anyway. > > Surely they are thrown as exceptions which can then be manipulated > in pure code using > > mapExceptions :: (Exception -> Exception) -> (a -> a) > > and caught in the IO monad using catch? No, the report clearly states that they are discarded. We could perhaps have our own versions of the lazy I/O operations which throw exceptions, but this in itself is problematic because these kind of exceptions would be asynchronous in nature. If lazy I/O is allowed to raise exceptions, then we have a situation where evaluating anything can raise an I/O exception. In theory this shouldn't be a problem - we all ought to be writing asynchronous-excpetion-safe code anyway to protect against StackOverflow, but an I/O exception is often one that you want to handle gracefully and recover from. I feel distinctly uncomfortable about I/O exceptions being thrown by pure code, and even more uncomfortable about asynchronous I/O exceptions. Cheers, Simon

3 2

Template metaprogramming for Haskell article.
by Immanuel Litzroth 25 Nov '02

25 Nov '02

I am reading the article template meta-programming for haskell and am wondering if 1) this is already implemented in ghc. 2) if not when this will be released Thanks in advance Immanuel *************************************************************************** His endeavours to improve these conditions by innovations in the current methods of teaching are fully described in his writings; these made him unpopular with his brethren in the order and led to his removals to the monastery of Pomposa near Ferrara, Italy. Here the same lot seems to have befallen him. About Guido of Arezzo Immanuel Litzroth Software Development Engineer Enfocus Software Kleindokkaai 3-5 B-9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Immanuell(a)enfocus.be web : www.enfocus.be ***************************************************************************

1 0

RE: re-opening a closed stdin?
by Simon Marlow 25 Nov '02

25 Nov '02

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > One reason, I think, is lazy I/O(*). It's to stop you accidentally > > [...] > > > (*) kill it! die! die! > > So you want > main = readFile "/dev/zero" >> return () > to terminate violantly rather than terminate peacefully? :) > > Seriously, I understand that the IO monad is the most intuitive and > robust when it is strict. But sometimes it is also nice if one could > map a file to a lazy string. It is nice, but it introduces too many problems. What happens to any I/O errors encountered by the lazy I/O? They have to be discarded, which means you can't effectively use lazy I/O for robust applications anyway. Cheers, Simon

3 2