March 2005 - Glasgow-haskell-users

Re: FW: RE: x86_64 port
by Kurt Roeckx 04 Mar '05

04 Mar '05

On Fri, Mar 04, 2005 at 11:13:28AM -0600, John Goerzen wrote: > Do any of you know if this is a known problem? > > ----- Forwarded message from Simon Marlow <simonmar(a)microsoft.com> ----- > > From: Simon Marlow <simonmar(a)microsoft.com> > Date: Fri, 4 Mar 2005 17:03:31 -0000 > To: John Goerzen <jgoerzen(a)complete.org> > Cc: glasgow-haskell-users(a)haskell.org > Subject: RE: x86_64 port > > On 04 March 2005 16:59, John Goerzen wrote: > > > On Fri, Mar 04, 2005 at 04:57:04PM -0000, Simon Marlow wrote: > >> On 04 March 2005 14:04, John Goerzen wrote: > >>>> My amd64 hardware arrived yesterday, shouldn't be too long before > >>>> we have a registerised port of GHC, and possibly a native code > >>>> generator... > >>> > >>> <burns> excellent </burns> > >> > >> Don't hold your breath, I have some bad news. It seems that gcc is > >> still generating incorrect code for register variables (or maybe it's > >> broken again?). > > > > Which version of gcc? > > gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) I have no idea what ghc has too do with gcc, or what the problem exactly is. We have very little problems with gcc for the debian amd64 port. Our default compiler is still 3.3. This builds almost everything without problems, however we build a few mozilla packages with gcc-3.4. All I can tell is that ghc6 seems to be working on debian amd64. It can build itself and things like that. Can someone please give a test case (and show what to do) to see what is wrong? Out current default compiler in debian is: gcc version 3.3.5 (Debian 1:3.3.5-8) The gcc 3.4 version is: gcc version 3.4.4 20050203 (prerelease) (Debian 3.4.3-9) And ghc6 is at version 6.2.2-3. Kurt

1 0

RE: x86_64 port
by Simon Marlow 04 Mar '05

04 Mar '05

On 02 March 2005 14:15, John Goerzen wrote: > Kip Macy <kip.macy <at> gmail.com> writes: > >> I've followed the instructions to the letter. > > Debian has had a working amd64 package of ghc for some time now. It > is built out of the standard source base for it. You can find that > at: > > http://ftp.debian.org/debian/pool/main/g/ghc6 > > You'll want to grab the orig.tar.gz and the diff.gz files. > > If you want to grab an amd64 .deb to try, go to: > > http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ ghc6/ > > Even if you're not running Debian, there are tools available to > convert a .deb to a RPM or tgz package. Or, you can easily unpack a > deb using only ar(1) and tar(1). My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... Cheers, Simon

4 3

RE: GHC 6.4 release candidates available (breakage on x86-64)
by Simon Marlow 04 Mar '05

04 Mar '05

On 02 March 2005 05:08, Brian Strand wrote: > Donald Bruce Stewart wrote: >> bstrand: >> >>> Donald Bruce Stewart wrote: >>> >>>> bstrand: >>>> >>>> >>>>> Simon Marlow wrote: >>>>> >>>>> >>>>>> Just to let you know, there are a number of open bug reports for >>>>>> GHC on the x86_64 platform, which seem to indicate some kind of >>>>>> occasional memory/GC problem. I'm probably not going to be able >>>>>> to track this down until after the 6.4 release, but we'll put >>>>>> out a patch as soon as we have one. >>>>> >>>>> Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via >>>>> Anders' Debian x86-64 ghc, although it doesn't look like a >>>>> memory/GC problem to my untrained eye: >>>>> >>>>> >>>>> ==fptools== make boot - --no-print-directory -r; >>>>> in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat >>>>> ------------------------------------------------------------------------ >>>>> ../../../glafp-utils/mkdependC/mkdependC -f .depend >>>>> -I../../includes -- -O -- cbits/directory.c cbits/rawSystem.c >>>>> /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O >>>>> -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts >>>>> -no-recomp Compat/Directory.hs Compat/RawSystem.hs >>>>> Distribution/Compat/ReadP.hs Distribution/Extension.hs >>>>> Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs >>>>> Distribution/License.hs Distribution/Package.hs >>>>> Distribution/ParseUtils.hs Distribution/Setup.hs >>>>> Distribution/Version.hs System/Directory/Internals.hs <<ghc: >>>>> 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 >>>>> samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 >>>>> elapsed), >>>>> 0.03 GC (0.57 elapsed) :ghc>> >>>>> make all >>>>> rm -f System/Directory/Internals.o; if [ ! -d >>>>> System/Directory/Internals_split ]; then mkdir >>>>> System/Directory/Internals_split; else /usr/bin/find >>>>> System/Directory/Internals_split -name '*.o' -print | xargs rm -f >>>>> __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing >>>>> -I../../../libraries -fglasgow-exts -no-recomp -split-objs -c >>>>> System/Directory/Internals.hs-o System/Directory/Internals.o >>>>> -ohi System/Directory/Internals.hi warning: don't know how to >>>>> split object files on this architecture <<ghc: 76094368 bytes, 11 >>>>> GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in >>>>> use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC >>>>> (1.40 elapsed) :ghc>> ( cd System/Directory/Internals_split; rm >>>>> -f ld.script; touch ld.script; echo "INPUT(" *.o ")" >>ld.script; >>>>> /usr/bin/ld -r -x -o ../Internals.old.script; ); >>>>> /usr/bin/ld:ld.script: file format not recognized; treating as >>>>> linker script /usr/bin/ld:ld.script:1: syntax error >>>>> make[4]: *** [System/Directory/Internals.o] Error 1 >>>>> make[3]: *** [boot] Error 2 >>>>> make[2]: *** [boot] Error 1 >>>>> make[1]: *** [boot] Error 1 >>>>> make[1]: Leaving directory >>>>> `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 >>>> >>>> >>>> Can you try building with SplitObjs=NO ? >>>> >>>> Wolfgang, Ryan - that looks like a splitter problem, no? >>>> >>>> (The splitter is more of a dark art than the evil mangler, I >>>> propose we name it the "diabolical splitter" from now on.) >>>> >>>> -- Don >>> >>> Using SplitObjs=NO gives out many warnings then finally dies with: >>> >>> ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W >>> -optc-Wstrict-prototypes -optc-Wmissing-prototypes >>> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return >>> -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel >>> -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -H64m -O -O2 >>> -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h >>> -#include RtsUtils.h -#include StgRun.h -#includeSchedule.h >>> -#include Printer.h -#include Sanity.h -#include STM.h -#include >>> Storage.h -#include SchedAPI.h -#include Timer.h -#include >>> Itimer.h-#include ProfHeap.h -#include LdvProfile.h -#include >>> Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c StgCRun.c >>> -o StgCRun.o >>> In file included from ../includes/Stg.h:149, >>> from StgCRun.c:67: >>> ../includes/Regs.h:213: warning: call-clobbered register used for >>> global register variable ../includes/Regs.h:342: warning: >>> call-clobbered register used for global register variable >>> /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: >>> suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error >>> 1 >>> make[1]: *** [all] Error 1 >>> make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' >>> make: *** [build] Error 1 >> >> >> Are you building unregisterised? Those messages about global register >> variables (I think) imply that you are not -- and we haven't yet got >> x86_64 (terrible name, I much prefer amd64) registerised. Looks like >> you might even have found the point where registerisation breaks. >> >> Try building unregisterised: >> GhcUnregisterised=YES >> >> just as the .hc bootstrap compiler was built. >> >> -- Don > > Well, I don't know much about how the bootstrap compiler was built (I > just downloaded it from > http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ ghc6/), > but building with GhcUnregisterised=YES and SplitObjs=NO died with: > > ==fptools== make all -wr; > in /home/bstrand/src/ghc-6.4.20050224/libraries/base > ------------------------------------------------------------------------ > ../../ghc/compiler/ghc-inplace -H16m -O -H64m -O -fglasgow-exts -cpp > -Iinclude -"#include" HsBase.h -funbox-strict-fields -ignore-package > base -O -Rghc-timing -fgenerics -fgenerics -c GHC/Base.lhs -o > GHC/Base.o -ohi GHC/Base.hi > ghc-6.4.20050224: internal error: getMBlock: mmap: Invalid argument > Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, > or http://www.sourceforge.net/projects/ghc/ > make[2]: *** [GHC/Base.o] Error 254 > make[1]: *** [all] Error 1 > make[1]: Leaving directory > `/home/bstrand/src/ghc-6.4.20050224/libraries' make: *** [build] > Error 1 You need to remove some leftover .hi-boot and .o-boot files in libraries. These were left in the source distribution by mistake, they won't be there for the final release. Cheers, Simon

1 0

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

04 Mar '05

I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden. Also, as Simon pointed out, there might be multiple modules in scope at the prompt, so how do you resolve the flag settings if they're contradictory? In general, flag settings affect the current source file only. The flag settings at the GHCi prompt are those given on the command line and from :set - it's simple, no worrying about "where did that option come from? I don't want overlapping instances!". Cheers, Simon On 02 March 2005 18:33, Keean Schupke wrote: > Erm, what is the module context of GHCi? I thought ghci > used the context of the loaded module: > > ghci Test.hs > > *Test> > > I though the 'Test' in the prompt indicated you were in the context of > the "Test" module. In which case the pragma at the top of the test > module should be in force? > > Keean. > > Simon Peyton-Jones wrote: > >> 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 >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

ANNOUNCE: The GHC Survey 2005
by Simon Marlow 04 Mar '05

04 Mar '05

Just ahead of the 6.4 release, we've put together a GHC user survey. The idea is to help us get a better understanding of who uses GHC, what for, what aspects of GHC they consider most valuable, and what they would most like to see improved. The survey is anonymous (if you wish), and should take about 5 minutes to complete. We will use the information to help guide what we do in future, and to help justify what to do. Have your say! We'll also be publishing lots of cool stats once we have enough responses. Here's the link: http://www.haskell.org/ghc/survey/start.cgi Many thanks to Tomasz Zielonka for putting together the survey, which is implemented using WASH on GHC (of course). Simon M, on behalf of the GHC Team

1 0

RE: gunfoldl
by Simon Peyton-Jones 03 Mar '05

03 Mar '05

This crash is fixed, in the HEAD and 6.4. It turned out to be a desugaring bug involving existentials etc. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Akos Korosmezey | Sent: 18 February 2005 20:05 | To: GHC-users list | Subject: gunfoldl | | | I wrote a little data structure with quantified constructors: | | module MyModule where | import Data.Generics | import Data.HashTable | | data Item = forall a. (Data a) => Leaf Bool a | | forall a. (Data a) => Branch Bool a Int Int | | deriving (Typeable) | | I want it to make an instance of Data: | | instance Data Item where | gfoldl k z (Leaf b v) = z (Leaf b) `k` v | gfoldl k z (Branch b v a1 a2) = z (\x -> Branch b x a1 a2) `k` v | --gunfoldl k z c = case constrIndex c of | -- 1 -> k z (Leaf undefined | undefined) | toConstr (Leaf _ _) = leafConstr | toConstr (Branch _ _ _ _) = branchConstr | dataTypeOf _ = itemDataType | | itemDataType = mkDataType "Subliminal.Item" [leafConstr, branchConstr] | leafConstr = mkConstr itemDataType "Leaf" [] Prefix | branchConstr = mkConstr itemDataType "Branch" [] Prefix | | But, when I try to compile it with ghc-6.4-20050217: | | ghc -fglasgow-exts -i. -c kicsi.hs | | kicsi.hs:13:4: | Warning: No explicit method nor default method for `gunfold' | In the instance declaration for `Data Item' | ghc-6.4.20050217: panic! (the `impossible' happened, GHC version | 6.4.20050217): | cgPanic | k{v a1vu} | static binds for: | local binds for: | gunfold{v r22q} | SRT labelghc-6.4.20050217: panic! (the `impossible' happened, GHC | version 6.4.20050217): | initC: srt | | Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, | or http://sourceforge.net/projects/ghc/. | | If I uncomment the gunfoldl lines: | | ghc -fglasgow-exts -i. -c kicsi.hs | | kicsi.hs:12:8: `gunfoldl' is not a (visible) method of class `Data' | | Compilation exited abnormally with code 1 at Fri Feb 18 20:55:32 | | Could you please help me? | | Thanks | Akos | -- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ~~~~~~ | Akos Korosmezey Tel: +36-1-439-5936 | Ericsson Telecom Ltd. ETH/GSCD/RUNB Fax: +36-1-437-7576 | P.O.B. 107, H-1300 Budapest, Hungary Home: +36-26-342-687 | mailto:Akos.Korosmezey@ericsson.com Mobile: +36-30-740-7732 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ~~~~~~ | | _______________________________________________ | 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 03 Mar '05

03 Mar '05

There may be many loaded modules... What if they have contradictory flags And in fact GHC doesn't remember in interface files the flag settings with which was compiled. Perhaps it should, but it doesn't at the moment. 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 18:33 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: GHC 6.4 release candidates available | | Erm, what is the module context of GHCi? I thought ghci | used the context of the loaded module: | | ghci Test.hs | | *Test> | | I though the 'Test' in the prompt indicated you were in the context of | the "Test" module. In which case the pragma at the top of the test | module should be in force? | | Keean. | | Simon Peyton-Jones wrote: | | >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 | > | > | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

[ ghc-Feature Requests-1155875 ] Arbitrary function sections
by SourceForge.net 03 Mar '05

03 Mar '05

Feature Requests item #1155875, was opened at 2005-03-03 16:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1155875&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: Dinko Tenev (a0s) Assigned to: Nobody/Anonymous (nobody) Summary: Arbitrary function sections Initial Comment: For operators we have the following shorthand: op :: a -> b -> c (`op` y) === \x -> x `op` y (x `op`) === \y -> x `op` y It would be nice to have a similar facility for functions, e.g.: f :: a -> b -> c -> d -> e f _ y _ t === \x z -> f x y z t f x _ z _ === \y t -> f x y z t f x _ z === \y -> f x y z === \y t -> f x y z t Because "_" is currently not allowed as an identifier in contexts where this facility could possibly be in effect, it seems safe to use it to indicate omitted parameters in function application. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1155875&group_…

1 0

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 03 Mar '05

03 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