December 2002 - Glasgow-haskell-users

Generating unique labels ...
by Reto Kramer 07 Dec '02

07 Dec '02

I'm trying to create a function (using ghc 5.04.2) that returns a unique string label each time it's called (unique w.r.t. the program run). Using the system timer doesn't cut it (too coarse and hence not unique). The challenge is that I'm using Strafunsky to traverse a syntax tree and rewrite expression nodes, so I cannot "thread" a counter all through this existing library, but need some "side-effecting" store that I can update. Any suggestions to such a basic question? - Reto

2 1

Re: ANNOUNCE: GHC version 5.04.2 released
by Sigbjorn Finne 06 Dec '02

06 Dec '02

Hi there, it includes quite a bit more 'stuff' -- profiling libraries + a bunch of tools that's needed by the backend on that platform. To help you out a little bit, I've tar'ed up the profiling libraries separate from the main distribution tar bundle, which shaves off some 10M. Available via http://haskell.org/ghc/dist/5.04.2/ To use, just unpack & go. --sigbjorn ----- Original Message ----- From: "Francis Girard" <francis.girard(a)free.fr> To: "Sigbjorn Finne" <sof(a)galois.com>; <haskell(a)haskell.org> Sent: Thursday, December 05, 2002 20:20 Subject: Re: ANNOUNCE: GHC version 5.04.2 released > Why is the windows .msi file is more than twice as big as the Linux binary > file ? > ~35 Mb / ~16 Mb. > With my slow and unstable french internet connection, 35 Mb is more than I > can afford. > > Thank you > > Francis Girard > Le Conquet > France > > Le 5 Décembre 2002 02:54, Sigbjorn Finne a écrit : > > "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > ====================================================== > > > The (Interactive) Glasgow Haskell Compiler -- version 5.04.2 > > > ====================================================== > > > > ... > > > > > > A Win32 installer is now available via the downloads page > > > > http://haskell.org/ghc/download_ghc_504.html > > > > The installer this time also includes ObjectIO. > > > > --sigbjorn > >

1 0

Chipworks Structural Analysis Reports
by Chipworks 05 Dec '02

05 Dec '02

1 0

CVS access?
by John Meacham 05 Dec '02

05 Dec '02

I sent a message to the address specified to get CVS access so i could integrate DrIFT 2.0 into the standard CVS tree, but I never got a response. who should i send requests too nowadays? John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 1

�б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