- Glasgow-haskell-users

Re: [Haskell-cafe] Re: Bound threads
by Duncan Coutts 03 Mar '05

03 Mar '05

On Thu, 2005-03-03 at 12:12 +0100, Marcin 'Qrczak' Kowalczyk wrote: > I was thinking about integration with gtk/glib event loop. Yes please! Currently GUI libs (gtk2hs, wxHaskell, fltk, etc) cannot use threads in any sensible manner. I think think there are two problems with this. One is that all GUI Haskell threads must be bound to a single OS thread as GUI libs (apart from opengl) are not thread safe. (This is not the same as the current bound thread mechanism which allows to bind a fresh OS thread to new Haskell threads.) The other problem is then once all GUI Haskell threads are running in the same OS thread as the GUI main loop they have to somehow cooperate to share cpu time. This is where the GUI event loop integration comes in. > There are > two ways: either we ask glib to poll using a function supplied by us, > or we perform polling using glib functions instead of raw epoll / poll > / select. The first choice seems better because otherwise callbacks > registered at glib were started from the scheduler and this will not > work, it's even not clear on behalf of which thread they should run. > In this case we must provide a function with an interface of poll(). I tried a hack once where we install ghc rts as an event source in the glib main loop. The idea is that we ask the ghc rts if it has any runnable threads and if so we give it a timeslice. The glib event source API can also use information about file descriptors and timers. This sort of worked. To do it properly would require the rts to have an interface to do this. I was doing it just by importing lots of rts private header files. A crucial point is that all callbacks must happen in the same OS thread that originally started the GUI main loop. Duncan

1 0

Re: 6.4 snapshot installer available
by Mike Thomas 02 Mar '05

02 Mar '05

Hi Sigbjorn. I wrote: > I built CVS head GHC with this package and mucked around a little bit. > The > only problem I've come across so far is that an objectio library >application > I have crashes on take-off when built with this compiler (not necessarily to > do with objectio of course). It does not crash with GHC 6.2.1 Woops. It turns out that I missed a blatantly obvious error message which 6.2.1 did not give: ================================================================ Starting program: c:\data\source\ghc\grass/./objectio/geo.exe grass/./objectio/geo.exe: main.hs:23:8-70: Irrefutable pattern failed for patter n [fileMenuID, mapMenuID, grassDBMenuID] ================================================================ after I shortened a list of ids. Luckily this afternoon I took delivery of a pair of reading glasses which will hopefully help me to avoid such errors in future. Thumbs up for that installer. Cheers Mike Thomas.

1 0

RE: GHC 6.4 release candidates available
by Ralf Lammel 02 Mar '05

02 Mar '05

It also worked in 6.2 Before that I don't remember. It is a very sensible thing to do simply because the mere ghci prompt suggests that we are in the scope of the top-level module. So one would really expect that ghci honors the directives of the top-level module. Ralf > -----Original Message----- > From: Keean Schupke [mailto:k.schupke@imperial.ac.uk] > Sent: Wednesday, March 02, 2005 9:20 AM > To: Simon Peyton-Jones > Cc: Ralf Lammel; glasgow-haskell-users(a)haskell.org > Subject: Re: GHC 6.4 release candidates available > > In the past having: > > {-# OPTIONS -fallow-overlapping-instances #-} > > in a module was enough to get ghci to allow the overlaps. > > so we do: > > ghci Test.hs > > now it does not work (but it did in 6.3), but: > > ghci -fallow-overlapping-instances Test.hs > > does... Even it Test.hs is the top level module. > > Keean. > > Simon Peyton-Jones wrote: > > >Ralf > > > >You have a pragma "-fallow-overlapping-instances" in Test.hs, and indeed > >it is honoured when compiling Test.hs. But it's not taken into account > >when compiling top-level expressions, or, indeed, if you were to import > >Test into another module. > > > >If you say ":set -falllow-overlapping-instances" it'll work fine. > > > >Now, maybe you'd like the flag to attach permanently to the *instance*, > >so that if an instance decl is compiled with > >-fallow-overlapping-instances, then no complaint will ever be issued for > >its overlaps, even if it is imported into a module that doesn't have > >-fallow-overlapping-instances. That would make sense, I think, but it's > >not implemented and never has been. > > > >Simon > > > >| -----Original Message----- > >| From: glasgow-haskell-users-bounces(a)haskell.org > >[mailto:glasgow-haskell-users- > >| bounces(a)haskell.org] On Behalf Of Ralf Lammel > >| Sent: 02 March 2005 08:45 > >| To: glasgow-haskell-users(a)haskell.org > >| Subject: RE: GHC 6.4 release candidates available > >| > >| I think this is an old bug, > >| or at least I have seen it months back. > >| > >| The "overlapping instances" directive does not make it to the > >top-level. > >| See attached sample with the offending session. > >| > >| Thanks for fixing. > >| Ralf > > > >_______________________________________________ > >Glasgow-haskell-users mailing list > >Glasgow-haskell-users(a)haskell.org > >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > >

1 0

RE: GHC 6.4 release candidates available
by Simon Peyton-Jones 02 Mar '05

02 Mar '05

Ah, yes. In 6.2, overlap errors were checked and reported "eagerly" at the instance declaration. So instance C Int a instance C b Bool was rejected. Now it isn't. Instead the program is only rejected if a constraint arises that matches two instance decls, and neither is more specific. For example (C Int Bool) But many constraints are fine e.g. C Int Char However this does have the consequence that the overlapping-instance flag must be on in the module that calls the function rather than the one that defines the instances. It'd be better if the info travelled with the instance decl, but it doesn't (yet). A good feature request. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Keean Schupke | Sent: 02 March 2005 17:20 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: GHC 6.4 release candidates available | | In the past having: | | {-# OPTIONS -fallow-overlapping-instances #-} | | in a module was enough to get ghci to allow the overlaps. | | so we do: | | ghci Test.hs | | now it does not work (but it did in 6.3), but: | | ghci -fallow-overlapping-instances Test.hs | | does... Even it Test.hs is the top level module. | | Keean. | | Simon Peyton-Jones wrote: | | >Ralf | > | >You have a pragma "-fallow-overlapping-instances" in Test.hs, and indeed | >it is honoured when compiling Test.hs. But it's not taken into account | >when compiling top-level expressions, or, indeed, if you were to import | >Test into another module. | > | >If you say ":set -falllow-overlapping-instances" it'll work fine. | > | >Now, maybe you'd like the flag to attach permanently to the *instance*, | >so that if an instance decl is compiled with | >-fallow-overlapping-instances, then no complaint will ever be issued for | >its overlaps, even if it is imported into a module that doesn't have | >-fallow-overlapping-instances. That would make sense, I think, but it's | >not implemented and never has been. | > | >Simon | > | >| -----Original Message----- | >| From: glasgow-haskell-users-bounces(a)haskell.org | >[mailto:glasgow-haskell-users- | >| bounces(a)haskell.org] On Behalf Of Ralf Lammel | >| Sent: 02 March 2005 08:45 | >| To: glasgow-haskell-users(a)haskell.org | >| Subject: RE: GHC 6.4 release candidates available | >| | >| I think this is an old bug, | >| or at least I have seen it months back. | >| | >| The "overlapping instances" directive does not make it to the | >top-level. | >| See attached sample with the offending session. | >| | >| Thanks for fixing. | >| Ralf | > | >_______________________________________________ | >Glasgow-haskell-users mailing list | >Glasgow-haskell-users(a)haskell.org | >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: GHC 6.4 release candidates available
by Simon Peyton-Jones 02 Mar '05

02 Mar '05

Ralf You have a pragma "-fallow-overlapping-instances" in Test.hs, and indeed it is honoured when compiling Test.hs. But it's not taken into account when compiling top-level expressions, or, indeed, if you were to import Test into another module. If you say ":set -falllow-overlapping-instances" it'll work fine. Now, maybe you'd like the flag to attach permanently to the *instance*, so that if an instance decl is compiled with -fallow-overlapping-instances, then no complaint will ever be issued for its overlaps, even if it is imported into a module that doesn't have -fallow-overlapping-instances. That would make sense, I think, but it's not implemented and never has been. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ralf Lammel | Sent: 02 March 2005 08:45 | To: glasgow-haskell-users(a)haskell.org | Subject: RE: GHC 6.4 release candidates available | | I think this is an old bug, | or at least I have seen it months back. | | The "overlapping instances" directive does not make it to the top-level. | See attached sample with the offending session. | | Thanks for fixing. | Ralf

2 1

x86_64 port
by Kip Macy 02 Mar '05

02 Mar '05

Sorry if this is a RTFM type question - but what is the status of the x86_64 port?

3 5

RE: GHC 6.4 release candidates available
by Simon Marlow 02 Mar '05

02 Mar '05

On 02 March 2005 02:10, Benjamin Franksen wrote: > I haven't followed this thread too closely so please excuse me if > this has already been mentioned (or even fixed). > > After I installed the latest binary package (20050228) the > documentation was not correctly linked from the main documentation > page. 'Hierarchical Libraries' on the main page points > to /usr/local/share/ghc-6.4.20050228/html/libraries/index.html, but > in this directory there is no index.html, only subdirectories. The > link named 'Cabal' is also dead: > file:/usr/local/share/ghc-6.4.20050228/html/Cabal/index.html does not > exist). > > This is clearly non-critical, but it would be nice if it could be > fixed in the final version. These should be fixed in last night's snapshot. There were some problems with building the docs, and some of the docs didn't get included in the tarball. Cheers, Simon

1 0

RE: GHC 6.4 release candidates available
by Simon Marlow 02 Mar '05

02 Mar '05

On 01 March 2005 22:34, Ian Lynagh wrote: > The following files in the tarball look like they shouldn't be there > (and should be cleaned by at least distclean): > * ghc/includes/mkGHCConstants (an x86 ELF binary) > * ghc/driver/package.conf.inplace.old > * ghc/driver/package.conf.old > * A large number of ld.script files and the _split directories they > are in > * libraries/{OpenAL,X11,base,network,unix}/config.status > * libraries/config.status These are all fixed now, and a few more besides. > After building, then doing make distclean, I'm additionally left with: > * A ghc/compiler/stage1 directory tree including a number of > .hi-boot-5 and .hi-boot-6 files. > * A ghc/compiler/stage2 directory tree including a number of > .hi-noot and .o-boot files. > * A complete libraries/html directory > * libraries/libraries.txt > * mk/config.h > * mk/config.mk > * mk/stamp-h Mostly fixed. I'm testing the ghc/compiler/stage{1,2,3} cleaning now. mk/config.mk is a slight problem: we need to be able to 'make dist' at the top level after doing make distclean, but the top level makefile needs to include mk/config.mk. > I think you have unswapped the first two lines of > "ghc -v 2>&1 | head -2" but not changed "Reading" back to "Using", so > old hmakes are still broken (old includes the latest release, I > believe). Grumble. Ok, I'll change it to "Using". > Is there an equivalent of this (the no-OpenGL bit): > > $(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO > GhcLibsWithGLUT=NO > > that still works or do I have to do it by hand? Sorry, those flags have gone away. You'll have to use a local patch to libraries/Makefile (just comment out the appropriate SUBDIRS). Cheers, Simon

1 0

seeking array advice
by Ketil Malde 02 Mar '05

02 Mar '05

Hi, I'm about to rework an old program, and I am pondering what data structure to use. Basically, I want to store an index of fixed-length words (q-grams) with positions, i.e. given a word, I can quickly find its position in the data. The data set may be large (gigabytes would be nice), and I also want the option of storing a sparse set of the words in the data (i.e. every other word, every third, etc). I *think* I want to use a Map from words to positions, words packed to fit in Int(32|64|eger) (depending on word size), and positions as Int(32|64). I've used a similar approach with FiniteMaps previously, and it worked nicely, but for smaller data sets. However: Using a 'Map key [pos]' will eat a lot of space for the lists. 'Map key (UArray Int pos)' will be more efficient, but every insertion and deletion will destroy and create a new array -- and I would like the Map to live outside a monad (does there even exist an (IO|ST)Map?) I've considered lists of small(ish -- cache line compatible, probably) arrays. Another possibility is a suffix array, and a Map from words to regions in it. How will a hashtable work in this setting? Any thoughts? -kzm PS: it seems from a recent thread in comp.lang.functional (see <slrnd2autq.3hb.tomasz.zielonka(a)localhost.localdomain>) that array performance has improved in GHC6.4. Impressively so. -- If I haven't seen further, it is by standing in the footprints of giants

1 0

GHC 6.4 release candidates available
by Simon Marlow 02 Mar '05

02 Mar '05

We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Source and Linux binary distributions are avaiable here: http://www.haskell.org/ghc/dist/stable/dist/ Please test if you're able to, and give us feedback. Thanks! Simons & the GHC team

17 31