From donn at avvanta.com Thu Jan 1 01:44:07 2009 From: donn at avvanta.com (Donn Cave) Date: Thu Jan 1 01:35:59 2009 Subject: pthread mutex error building 6.10 on NetBSD Message-ID: <20090101064407.68F7093C62@mail.avvanta.com> I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into an error, where cabal-bin calls the stage2 ghc in utils/installPackage. pthread_mutex_unlock() is called, evidently from fileLock(), with an invalid mutex. NetBSD's pthread implementation differs from Linux in its intolerance of such things. I have found errors where someone forgets that a mutex was never used and tries to unlock it. I guess you could do that all day long on Linux without noticing anything, but NetBSD aborts the program. In the present case, I don't see anything like that wrong in rts/FileLock.c, though. I'm stumped. So I'm checking, has anyone else built 6.10 on NetBSD? Donn From kili at outback.escape.de Thu Jan 1 05:46:31 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Thu Jan 1 05:41:58 2009 Subject: pthread mutex error building 6.10 on NetBSD In-Reply-To: <20090101064407.68F7093C62@mail.avvanta.com> References: <20090101064407.68F7093C62@mail.avvanta.com> Message-ID: <20090101104631.GA14455@petunia.outback.escape.de> On Wed, Dec 31, 2008 at 10:44:07PM -0800, Donn Cave wrote: > I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into > an error, where cabal-bin calls the stage2 ghc in utils/installPackage. > > pthread_mutex_unlock() is called, evidently from fileLock(), with an > invalid mutex. > > NetBSD's pthread implementation differs from Linux in its intolerance > of such things. I have found errors where someone forgets that a mutex > was never used and tries to unlock it. I guess you could do that all day > long on Linux without noticing anything, but NetBSD aborts the program. > In the present case, I don't see anything like that wrong in rts/FileLock.c, > though. I'm stumped. > > So I'm checking, has anyone else built 6.10 on NetBSD? Only on OpenBSD, and there it builds fine (when bootstrapping from either ghc-6.6 or -6.10). But what's interesting is that in includes/OSThreads.h the return values of pthread_mutex_lock(3) and pthread_mutex_unlock(3) aren't checked except apparently on Linux when building with DEBUG defined. You could either try to build with LOCK_DEBUG defined, so you see exactly when a lock is acquired and released, or try to build with DEBUG defined and that `&& defined(linux_HOST_OS)' removed from OSThreads.h to see what's going wrong. BTW: is there any pthread implementation still in the wild where pthread_mutex_{,un}lock() does NOT indicate a deadlock by EDEADLK? If not, the DEBUG part of OSThreads.h could be used for all systems, not only Linux. Ciao, Kili -- A typo a day, keeps the dictionnary away. -- Miod Vallat From catamorphism at gmail.com Thu Jan 1 17:33:40 2009 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Jan 1 17:25:30 2009 Subject: [Haskell] Haskell profiler In-Reply-To: References: Message-ID: <4683d9370901011433w23fe8b30t5e0e5ac040328511@mail.gmail.com> On 12/29/08, Srinivas Nedunuri wrote: > Could someone tell me what the expected accuracy of the Haskell profiler is? > I get quite widely varying results for the amount of time spent on a given > function across different runs (eg one random example, from 1.5% to 10%). I > even upped the size of the dataset in an attempt to increase the accuracy. [redirecting to ghc-users] I assume you mean the GHC profiler. It's normal when profiling any programs, Haskell or not, for timing numbers to vary. Memory allocation counts, however, should be stable across different runs. > Also a related q: why doesnt't the time spent in putStr show up? > You would have to rebuild your GHC libraries with the -auto-all flag in order to get cost centres attached to library functions (but this may defeat some optimizations). Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's okay to be mean to the evil people who make life unbelievable, but try to be nice to me." -- Nerissa Nields From gwright at comcast.net Fri Jan 2 12:26:33 2009 From: gwright at comcast.net (Gregory Wright) Date: Fri Jan 2 12:18:21 2009 Subject: Preferred gcc for use with ghc Message-ID: Hi, What is the preferred gcc to use with ghc 6.10.1? I'm starting the long and doubtless slow process of putting together a more user friendly (and binary distributable) ghc distribution to be built using MacPorts. The guidance about gcc on the wiki is vague. Is there a best choice? Or at least some versions to be avoided? Best, Greg From dons at galois.com Fri Jan 2 15:03:54 2009 From: dons at galois.com (Don Stewart) Date: Fri Jan 2 14:55:27 2009 Subject: Preferred gcc for use with ghc In-Reply-To: References: Message-ID: <20090102200354.GA3853@scytale.galois.com> gwright: > > Hi, > > What is the preferred gcc to use with ghc 6.10.1? I'm starting > the long and doubtless slow process of putting together a more user > friendly (and binary distributable) ghc distribution to be built using > MacPorts. > The guidance about gcc on the wiki is vague. Is there a best choice? > Or at least some versions to be avoided? I like gcc 4.3.2, but any recent one is probably ok. GCC on the Mac is a bit infamous for not producing as good code as on Linux though, so watch out. From dominic.steinitz at blueyonder.co.uk Sat Jan 3 03:00:31 2009 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jan 3 03:03:28 2009 Subject: GADT Strangeness In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C86@EA-EXMSG-C334.europe.corp.microsoft.com> References: <494E0E60.5000902@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C33286D93C86@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <495F1B1F.6060006@blueyonder.co.uk> Simon Peyton-Jones wrote: > | If I remove -XScopedTypeVariables from this http://hpaste.org/13230 > then | I get the following error message: | | > > Asn1cTestNew.hs:55:27: | > GADT pattern match in non-rigid > context for `INTEGER' | > Solution: add a type signature | > > In the pattern: INTEGER | > In the definition of > `referenceTypeAndValAux2': | > referenceTypeAndValAux2 ns > INTEGER x | > = lhs ns <> text " = > " <> text (show x) <> semi | > Failed, modules loaded: Language.ASN1, > ASNTYPE. | | At the very least the message is unhelpful. It was only > by accident I | decided to put in -XScopedTypeVariables. > > This one had me puzzled for a while too! Here is what's happening. > > You have three mutually recursive functions: referenceTypeAndValAux1 > referenceTypeAndValAux2 cSEQUENCE In Haskell 98, typechecking > mutually recursive functions is done *together*, with each having a > momomorphic type in the other RHSs. That leads to an annoying > problem, that of figuring out how their polymorphic type variables > "match up". As a result, even the type variables in the type > signature look non-rigid. > > The solution is to use -XRelaxedPolyRec, which compiles > mutually-recursive definitions that each have a type signature one by > one. Precisely because of the above infelicity, both -XGADTs and > -XScopedTypeVariables imply -XRelaxedPolyRec. Thanks very much for this. I would never have guessed to use -XRelaxedPolyRec given the error message. Is it worth noting it here http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching or is it something that has always existed with GADTs and I just didn't trip over it? > > This is a nasty corner I agree. GHC requires -XGADTs for you to > *define* a GADT. Perhaps it should also require -XGADTs for you to > *match against* one (as you are doing here). That would avoid this > particular hole. If you think that would be a step forward, do put > forward a Trac feature request, and encourage others to support it. I would vote for this. In fact I was mildly surprised I could use GADTs without specifying -XGADTs. I noticed that Isaac Dupree has already raised a ticket http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16109 so I will add my support to it. Many thanks and a happy new year, Dominic. From Christian.Maeder at dfki.de Sat Jan 3 08:51:27 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Sat Jan 3 08:43:14 2009 Subject: Preferred gcc for use with ghc In-Reply-To: References: Message-ID: <495F6D5F.6000001@dfki.de> gcc version 4.0.1 (Apple Inc. build 5488) worked for me. I think it comes from XCode 3.1 together with @(#)PROGRAM:ld PROJECT:ld64-85.2.1 XCode 3.0 with gcc version 4.0.1 (Apple Inc. build 5465) and @(#)PROGRAM:ld PROJECT:ld64-77 works only on intel macs but not on powerpc macs. HTH Christian Gregory Wright wrote: > > Hi, > > What is the preferred gcc to use with ghc 6.10.1? I'm starting > the long and doubtless slow process of putting together a more user > friendly (and binary distributable) ghc distribution to be built using > MacPorts. > The guidance about gcc on the wiki is vague. Is there a best choice? > Or at least some versions to be avoided? > > Best, > Greg From bertram.felgenhauer at googlemail.com Sat Jan 3 10:48:23 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Jan 3 10:40:13 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> Message-ID: <20090103154822.GA5555@zombie.inf.tu-dresden.de> Conal Elliott wrote: > Thanks very much for these ideas. Peter Verswyvelen suggested running the > example repeatedly to see if it always runs correctly. He found, and I > verified, that the example runs fine with Bertram's last version of unamb > below, *unless* it's compiled with -threaded and run with +RTS -N2. In the > latter case, it locks up after a while. It seems that we've found an RTS bug. If a thread is started with exceptions blocked, then throwTo might never deliver its exception and block forever, as can be seen with the following test program, which locks up after a while (immediately with the non-threaded RTS) import Control.Exception import Control.Concurrent import Control.Monad test n = do t <- block $ forkIO yield yield putStr $ show n ++ ": kill\n" killThread t main = forM_ [1..] test Or, even more convincing: import Control.Exception import GHC.Conc main = do t1 <- block $ forkIO yield t2 <- forkIO $ killThread t1 yield yield threadStatus t1 >>= print threadStatus t2 >>= print prints (fairly reliably, it seems): ThreadFinished ThreadBlocked BlockedOnException (Trac is giving me errors right now. I'm planning to report this later.) > I also tried a version with brackAsync and found that it eventually locks up > even under ghci. When compiled & run multi-threaded, it locks up almost > immediately. > -- This one locks up after a while even in ghci. When compiled -threaded > -- and run +RTS -N2, it locks up almost immediately. > a `race` b = do > v <- newEmptyMVar > let t x = x >>= putMVar v > withThread (t a) $ withThread (t b) $ takeMVar v > where > withThread u v = brackAsync (forkIO u) killThread (const v) At the point the 'forkIO' is run, exceptions are blocked, making the thread basically immortal. Using > withThread u v = brackAsync (forkIO $ unblock u) killThread (const v) we get the same behaviour as with my 'race' - it works for a while, but locks up eventually. I believe that the actual lockup is similar to the test programs above in all cases - what's different is just the probability of triggering it. regards, Bertram From conal at conal.net Sat Jan 3 17:01:26 2009 From: conal at conal.net (Conal Elliott) Date: Sat Jan 3 16:53:15 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20090103154822.GA5555@zombie.inf.tu-dresden.de> Message-ID: Indeed -- many thanks to Bertram, Sterling, Peter & others for the help! I think getting this bug fixed will solve Reactive's mysterious bugs and unblock its progress. - Conal On Sat, Jan 3, 2009 at 1:20 PM, Peter Verswyvelen wrote: > That is very good news! Let's hope it's a bug that is easy enough to > fix, since I guess the RTS is very tricky. > > Thanks for all this effort. It would explain a lot of strange behaviour. > > Cheers, > Peter Verswyvelen > CTO - Anygma.com > > > On Sat, Jan 3, 2009 at 4:48 PM, Bertram Felgenhauer > wrote: > > Conal Elliott wrote: > >> Thanks very much for these ideas. Peter Verswyvelen suggested running > the > >> example repeatedly to see if it always runs correctly. He found, and I > >> verified, that the example runs fine with Bertram's last version of > unamb > >> below, *unless* it's compiled with -threaded and run with +RTS -N2. In > the > >> latter case, it locks up after a while. > > > > It seems that we've found an RTS bug. If a thread is started with > > exceptions blocked, then throwTo might never deliver its exception and > > block forever, as can be seen with the following test program, which > > locks up after a while (immediately with the non-threaded RTS) > > > > import Control.Exception > > import Control.Concurrent > > import Control.Monad > > > > test n = do > > t <- block $ forkIO yield > > yield > > putStr $ show n ++ ": kill\n" > > killThread t > > > > main = forM_ [1..] test > > > > Or, even more convincing: > > > > import Control.Exception > > import GHC.Conc > > > > main = do > > t1 <- block $ forkIO yield > > t2 <- forkIO $ killThread t1 > > yield > > yield > > threadStatus t1 >>= print > > threadStatus t2 >>= print > > > > prints (fairly reliably, it seems): > > > > ThreadFinished > > ThreadBlocked BlockedOnException > > > > (Trac is giving me errors right now. I'm planning to report this later.) > > > >> I also tried a version with brackAsync and found that it eventually > locks up > >> even under ghci. When compiled & run multi-threaded, it locks up almost > >> immediately. > > > >> -- This one locks up after a while even in ghci. When compiled > -threaded > >> -- and run +RTS -N2, it locks up almost immediately. > >> a `race` b = do > >> v <- newEmptyMVar > >> let t x = x >>= putMVar v > >> withThread (t a) $ withThread (t b) $ takeMVar v > >> where > >> withThread u v = brackAsync (forkIO u) killThread (const v) > > > > At the point the 'forkIO' is run, exceptions are blocked, making the > > thread basically immortal. Using > > > >> withThread u v = brackAsync (forkIO $ unblock u) killThread (const v) > > > > we get the same behaviour as with my 'race' - it works for a while, but > > locks up eventually. > > > > I believe that the actual lockup is similar to the test programs above > > in all cases - what's different is just the probability of triggering > > it. > > > > regards, > > > > Bertram > > _______________________________________________ > > Reactive mailing list > > Reactive@haskell.org > > http://www.haskell.org/mailman/listinfo/reactive > > > _______________________________________________ > Reactive mailing list > Reactive@haskell.org > http://www.haskell.org/mailman/listinfo/reactive > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090103/275c9491/attachment-0001.htm From kili at outback.escape.de Sun Jan 4 16:51:20 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Jan 4 16:46:56 2009 Subject: pthread mutex error building 6.10 on NetBSD In-Reply-To: <20090101104631.GA14455@petunia.outback.escape.de> References: <20090101064407.68F7093C62@mail.avvanta.com> <20090101104631.GA14455@petunia.outback.escape.de> Message-ID: <20090104215119.GA21577@petunia.outback.escape.de> Hi, On Thu, Jan 01, 2009 at 11:46:31AM +0100, Matthias Kilian wrote: > > pthread_mutex_unlock() is called, evidently from fileLock(), with an > > invalid mutex. > > > > NetBSD's pthread implementation differs from Linux in its intolerance > > of such things. I have found errors where someone forgets that a mutex > > was never used and tries to unlock it. I guess you could do that all day > > long on Linux without noticing anything, but NetBSD aborts the program. > > In the present case, I don't see anything like that wrong in rts/FileLock.c, > > though. I'm stumped. > > > > So I'm checking, has anyone else built 6.10 on NetBSD? Could you (and anyone else on any operating system using pthreads) please try to build with the patch below? It checks the return values of pthread_mutex_lock() and pthread_mutex_unlock() by default (even if DEBUG isn't defined) and contains some other uncluttering. Seems to work fine here on OpenBSD (for ghc-head), but before I send out a darcs patch, I'd like to see some results on other systems.[1] Of course, the patch won't fix the problem for NetBSD, but it may give some more hints. Ciao, Kili [1] and if you insist in darcs patches, just pull from http://darcs.volkswurst.de/users/kili/ghc-6.10/ghc/ or http://darcs.volkswurst.de/users/kili/ghc/ diff -x _darcs -rNup ../ghc/includes/OSThreads.h ./includes/OSThreads.h --- ../ghc/includes/OSThreads.h Sun Jan 4 22:28:46 2009 +++ ./includes/OSThreads.h Sun Jan 4 22:11:34 2009 @@ -23,6 +23,7 @@ #else #include +#include typedef pthread_cond_t Condition; typedef pthread_mutex_t Mutex; @@ -34,47 +35,26 @@ typedef pthread_key_t ThreadLocalKey; #define INIT_COND_VAR PTHREAD_COND_INITIALIZER #ifdef LOCK_DEBUG +#define LOCK_DEBUG_BELCH(what, mutex) \ + debugBelch("%s(0x%p) %s %d\n", what, mutex, __FILE__, __LINE__) +#else +#define LOCK_DEBUG_BELCH(what, mutex) /* nothing */ +#endif +/* Always check the result of lock and unlock. */ #define ACQUIRE_LOCK(mutex) \ - debugBelch("ACQUIRE_LOCK(0x%p) %s %d\n", mutex,__FILE__,__LINE__); \ - pthread_mutex_lock(mutex) -#define RELEASE_LOCK(mutex) \ - debugBelch("RELEASE_LOCK(0x%p) %s %d\n", mutex,__FILE__,__LINE__); \ - pthread_mutex_unlock(mutex) -#define ASSERT_LOCK_HELD(mutex) /* nothing */ - -#elif defined(DEBUG) && defined(linux_HOST_OS) -#include -/* - * On Linux, we can use extensions to determine whether we already - * hold a lock or not, which is useful for debugging. - */ -#define ACQUIRE_LOCK(mutex) \ + LOCK_DEBUG_BELCH("ACQUIRE_LOCK", mutex); \ if (pthread_mutex_lock(mutex) == EDEADLK) { \ barf("multiple ACQUIRE_LOCK: %s %d", __FILE__,__LINE__); \ } + #define RELEASE_LOCK(mutex) \ + LOCK_DEBUG_BELCH("RELEASE_LOCK", mutex); \ if (pthread_mutex_unlock(mutex) != 0) { \ barf("RELEASE_LOCK: I do not own this lock: %s %d", __FILE__,__LINE__); \ } #define ASSERT_LOCK_HELD(mutex) ASSERT(pthread_mutex_lock(mutex) == EDEADLK) - -#define ASSERT_LOCK_NOTHELD(mutex) \ - if (pthread_mutex_lock(mutex) != EDEADLK) { \ - pthread_mutex_unlock(mutex); \ - } else { \ - ASSERT(0); \ - } - - -#else - -#define ACQUIRE_LOCK(mutex) pthread_mutex_lock(mutex) -#define RELEASE_LOCK(mutex) pthread_mutex_unlock(mutex) -#define ASSERT_LOCK_HELD(mutex) /* nothing */ - -#endif #endif // CMINUSMINUS From ml at isaac.cedarswampstudios.org Sun Jan 4 19:40:38 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Jan 4 19:32:32 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <20081229062647.GA4205@zombie.inf.tu-dresden.de> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20081229062647.GA4205@zombie.inf.tu-dresden.de> Message-ID: <49615706.3090909@isaac.cedarswampstudios.org> therefore mapException is equally buggy! > mapException :: (Exception e1, Exception e2) => (e1 -> e2) -> a -> a > mapException f v = unsafePerformIO (catch (evaluate v) > (\x -> throw (f x))) If it maps an asynchronous exception.. and it's re-thrown as synchronous... the same non-resumability happens! mapException is a particular culprit because of the unsafePerformIO (so you had a good reason to expect resumability, since it's for a pure computation, not in IO) - does anyone use mapException? - is there some reason that we don't have all "throw"s (synch. or asynch.) "patch up" the thunks? (memory leaks or serious inefficiency or something?) if "yes", I don't think mapException can currently be implemented; we'd need some way in its "catch" to detect whether the thrown exception was asynchronous, and *iff* so, throw the new exception asynchronously (if synchronous, rethrow synchronously). Or some equivalent. Or maybe some add some magic to unsafePerformIO (probably a bad idea). -Isaac From la at iki.fi Sun Jan 4 20:05:53 2009 From: la at iki.fi (Lauri Alanko) Date: Sun Jan 4 19:57:33 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <49615706.3090909@isaac.cedarswampstudios.org> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20081229062647.GA4205@zombie.inf.tu-dresden.de> <49615706.3090909@isaac.cedarswampstudios.org> Message-ID: <20090105010553.GA16417@cs.helsinki.fi> On Sun, Jan 04, 2009 at 07:40:38PM -0500, Isaac Dupree wrote: > - does anyone use mapException? I was the one who originally requested it, since it was mentioned in the paper and looked reasonable, but was missing from GHC. My motivation was that it could be used by a pure function to hide the exception behavior of an auxiliary function that it used internally. I can't really claim to have used it very much, though. Lauri From ganesh.sittampalam at credit-suisse.com Mon Jan 5 03:04:29 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Jan 5 02:56:22 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <20090105010553.GA16417@cs.helsinki.fi> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20081229062647.GA4205@zombie.inf.tu-dresden.de> <49615706.3090909@isaac.cedarswampstudios.org> <20090105010553.GA16417@cs.helsinki.fi> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCA88@ELON17P32001A.csfb.cs-group.com> > On Sun, Jan 04, 2009 at 07:40:38PM -0500, Isaac Dupree wrote: > > - does anyone use mapException? > I was the one who originally requested it, since it was mentioned > in the paper and looked reasonable, but was missing from GHC. > My motivation was that it could be used by a pure function to > hide the exception behavior of an auxiliary function that it used > internally. I can't really claim to have used it very much, though. I use it sometimes to provide a pseudo "call-stack" for errors. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Mon Jan 5 03:55:38 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 5 03:47:20 2009 Subject: GADT Strangeness In-Reply-To: <495F1B1F.6060006@blueyonder.co.uk> References: <494E0E60.5000902@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C33286D93C86@EA-EXMSG-C334.europe.corp.microsoft.com> <495F1B1F.6060006@blueyonder.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33286F3D1D8@EA-EXMSG-C334.europe.corp.microsoft.com> | Thanks very much for this. I would never have guessed to use | -XRelaxedPolyRec given the error message. | | Is it worth noting it here | http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching | or is it something that has always existed with GADTs and I just didn't | trip over it? I've added a para. Good idea. | > This is a nasty corner I agree. GHC requires -XGADTs for you to | > *define* a GADT. Perhaps it should also require -XGADTs for you to | > *match against* one (as you are doing here). That would avoid this | > particular hole. If you think that would be a step forward, do put | > forward a Trac feature request, and encourage others to support it. | | I would vote for this. In fact I was mildly surprised I could use GADTs | without specifying -XGADTs. | | I noticed that Isaac Dupree has already raised a ticket | http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16109 so | I will add my support to it. OK. let's see if anyone else comments. Do ping me in a while to action it if I forget. Simon From igloo at earth.li Mon Jan 5 09:29:40 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Jan 5 09:21:18 2009 Subject: black hole detection and concurrency In-Reply-To: <20081229160722.GA10905@zombie.inf.tu-dresden.de> References: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C74@EA-EXMSG-C334.europe.corp.microsoft.com> <20081229160722.GA10905@zombie.inf.tu-dresden.de> Message-ID: <20090105142940.GA7180@matrix.chaos.earth.li> On Mon, Dec 29, 2008 at 05:07:22PM +0100, Bertram Felgenhauer wrote: > Simon Peyton-Jones wrote: > > > > This is odd (to me). The "permanently bound" stuff applies only to > > *synchronous* exceptions, which thread-killing is not. Simon M will > > have more to say when he gets back > > This is true when the exception is raised the first time. However, some > exception handling functions like 'bracket' catch the exception, do > their cleanup, and then throw the exception again. This is done in > onException, and goes through throwIO and eventually raiseIO#. At this > point the originally asynchronous exception has become a synchronous > one. We don't currently have a way to know whether an exception was thrown asynchronously or not, right? Should we actually be throwing data SomeExceptionSync = SomeExceptionSync Bool -- synchronous? SomeException with catch etc ignoring the Bool, but bracket etc handling it appropriately? Thanks Ian From marlowsd at gmail.com Tue Jan 6 04:11:28 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 04:03:15 2009 Subject: black hole detection and concurrency In-Reply-To: <20090105142940.GA7180@matrix.chaos.earth.li> References: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C74@EA-EXMSG-C334.europe.corp.microsoft.com> <20081229160722.GA10905@zombie.inf.tu-dresden.de> <20090105142940.GA7180@matrix.chaos.earth.li> Message-ID: <49632040.8030703@gmail.com> Ian Lynagh wrote: > On Mon, Dec 29, 2008 at 05:07:22PM +0100, Bertram Felgenhauer wrote: >> Simon Peyton-Jones wrote: >>> This is odd (to me). The "permanently bound" stuff applies only to >>> *synchronous* exceptions, which thread-killing is not. Simon M will >>> have more to say when he gets back >> This is true when the exception is raised the first time. However, some >> exception handling functions like 'bracket' catch the exception, do >> their cleanup, and then throw the exception again. This is done in >> onException, and goes through throwIO and eventually raiseIO#. At this >> point the originally asynchronous exception has become a synchronous >> one. > > We don't currently have a way to know whether an exception was thrown > asynchronously or not, right? > > Should we actually be throwing > data SomeExceptionSync = SomeExceptionSync Bool -- synchronous? > SomeException > with catch etc ignoring the Bool, but bracket etc handling it > appropriately? This ticket describes the problem and a possible solution: http://hackage.haskell.org/trac/ghc/ticket/2558 Cheers, Simon From marlowsd at gmail.com Tue Jan 6 08:28:47 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 08:20:30 2009 Subject: building HSQL MySQL on windows (Was: FFI imported function names) In-Reply-To: References: Message-ID: <49635C8F.7090006@gmail.com> Daniil Elovkov wrote: > Ok, enough talking to myself :) > > If anybody ever wants to build hsql-mysql on windows and has the same > problems as I had, here's how it should be done. > > The problem I had seemed to be that libmysql.dll uses stdcall, but > names its functions without @ decoration. Thus, when linking a > Haskell program against it, names with @ cannot be resolved. > > The solution is pretty much a hack. Somebody from the Ruby community > used to run into the same problem, from the same situation -- namely > building ruby mysql bindings. > > Here is the procedure one person suggests > http://rubydotnetproxy.rubyforge.org/mysql_win.html > > It worked perfectly for me. Of course, with some cabal specifics, > which is obviously not described in the above page. > > The solution was to create a def file listing the names which could > not be resolved and creating a .a file based on the dll and this def > file. GHC adds the @N suffix to any foreign function declared with the stdcall calling convention, which I think matches what gcc does. I wonder how it works for C. Cheers, Simon > > 2008/12/24 Daniil Elovkov : >> Mm, actually I didn't change the calling convention ffi imports when I >> thought I did. I tried to do it through defines... >> >> Well, by explicitly saying ccall I get the names without @ >> decoration. And it all links well. But I get segault when I run the >> code, which should mean that calling conventions didn't match. >> >> Actually I found some ramblings on the internet that there's something >> wrong with libmysql.dll and libmysql.lib in this respect, but they >> were from 2004. >> >> Thus the question: how do I link against a lib file in ghc? When I say >> -lmysql on command line it strictly searches for dll and complains if >> it's not found. Adding lib exlpicitly on the cmd line doesn't seem to >> have any effect. >> >> Thanks >> >> >> 2008/12/24 Daniil Elovkov : >>> Hello >>> >>> How is decided whether the name of imported function gets the ending >>> of the form @4 in ghc? >>> >>> I'm having this problem on Windows trying to use HSQL MySQL on windows. >>> >>> I compile HSQL Oracle backend and I get names without that. It's ok. >>> With HSQL MySQL I get names with that stuff. It prevents me from >>> further linking to dll. Supplying in the ghc command-line the "lib" >>> file where names have those marks doesn't have any effect. >>> >>> The linker says that fname@NN cannot be resolved. >>> >>> Can I control that? >>> >>> The ffi calling convention doesn't (and shouldn't as I understand) >>> affect this. The only difference is that in the case of mysql the >>> header file itself where functions are described marks it STDCALL. Is >>> that the reason? >>> >>> Also I changed ffi import line from "hsmysql.h func" to just "func", >>> to no avail. >>> >>> ghc 6.8.2 >>> >>> I'm lost. Please help. >>> >>> -- >>> Daniil Elovkov >>> >> >> >> -- >> Daniil Elovkov >> > > > From marlowsd at gmail.com Tue Jan 6 08:44:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 08:35:52 2009 Subject: unique identifiers as a separate library In-Reply-To: <4951122E.9020305@charter.net> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> <86274BA3-1DD7-43C4-B72D-197860A9A9F5@informatik.uni-kiel.de> <20081218183939.nllqm73tkcgkcc44-nwo@webmail.spamcop.net> <494B686A.7050800@gmail.com> <5ab17e790812211105u1a384d7bs9a284dbe10c2d616@mail.gmail.com> <494F6D77.8070709@gmail.com> <97FA04AA-B0EF-48FC-A46A-1356FE460432@informatik.uni-kiel.de> <5ab17e790812221535i1bebc1dfnc4761b0ea59ce0b@mail.gmail.com> <4951122E.9020305@charter.net> Message-ID: <4963602B.9060001@gmail.com> Isaac Dupree wrote: > Iavor Diatchki wrote: >> - It uses unsafeDupableInterleaveIO to avoid double locking, > > in particular, > >> gen r = unsafeDupableInterleaveIO >> $ do v <- unsafeDupableInterleaveIO (genSym r) >> ls <- gen r >> rs <- gen r >> return (Node v ls rs) > > where is the double locking? We want referential transparency... > > e.g. suppose you use newNumSupply to create a thunk for a Gen; when > evaluated, it will run unsafeDupableInterleaveIO. You send that thunk > off to two different other threads. Then those threads decide to > evaluate it (say, enough to get the first genSym'd value) and happen to > make a race condition, so it becomes two separate IO computations. > Therefore one of them runs atomicModifyIORef, and the other one runs > atomicModifyIORef, and so they get two different values out. > > Node 0 (...) (...) > Node 1 (...) (...) > > when it's suppose to be the very same Gen data structure. > > so, am I right or wrong about what the perils of > unsafeDupableInterleaveIO are? Oops! Yes, you're quite right. Cheers, Simon From marlowsd at gmail.com Tue Jan 6 09:10:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 09:02:12 2009 Subject: ghci debugger :trace command does not always extend trace history In-Reply-To: References: Message-ID: <49636656.9060000@gmail.com> Peter Hercek wrote: > Hi, > > I expected ":trace expr" to always add data to the trace history but it > does not do so for CAFs (which are not reduced yet). > My point is that the command ":trace z" did not add anything to the > trace history and I cannot check why value z is 2, because value of y is > not in the trace history. Is this the expected behavior? If it is, how > can I make ghci to extend the trace history when "forcing" variables? > > Peter. > > Here is the example: > > status:0 peter@metod [765] ~/tmp > % cat a.hs > test :: Int -> Int > test x = > let y = x+1 in > let z = y+1 in > z > status:0 peter@metod [766] ~/tmp > % ghci a.hs > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( a.hs, interpreted ) > Ok, modules loaded: Main. > *Main> :break Main 5 > Breakpoint 0 activated at a.hs:5:2 > *Main> :trace test 0 > Stopped at a.hs:5:2 > _result :: Int = _ > z :: Int = _ > 4 let z = y+1 in > 5 z > 6 > [a.hs:5:2] *Main> :back > Logged breakpoint at a.hs:(2,0)-(5,2) > _result :: Int > 1 test :: Int -> Int > 2 test x = > 3 let y = x+1 in > 4 let z = y+1 in > 5 z > 6 > [-1: a.hs:(2,0)-(5,2)] *Main> :back > no more logged breakpoints ok so far - y and z have not been evaluated. > [-1: a.hs:(2,0)-(5,2)] *Main> :forward > Stopped at a.hs:5:2 > _result :: Int > z :: Int > 4 let z = y+1 in > 5 z > 6 > [a.hs:5:2] *Main> :trace z > 2 this evaluates z. > [a.hs:5:2] *Main> :back > Logged breakpoint at a.hs:(2,0)-(5,2) > _result :: Int > 1 test :: Int -> Int > 2 test x = > 3 let y = x+1 in > 4 let z = y+1 in > 5 z > 6 You are going back in the original context, but I presume you were expecting to go back in the evaluation of z. You can only go back in the context of the current evaluation, however. Try this: *Main> :break 3 Breakpoint 4 activated at trace.hs:3:10-12 *Main> :trace test 0 Stopped at trace.hs:3:10-12 _result :: Int = _ x :: Int = 90 2 test x = 3 let y = x+1 in 4 let z = y+1 in [trace.hs:3:10-12] *Main> :history -1 : test (trace.hs:4:10-12) -2 : test (trace.hs:5:2) -3 : test (trace.hs:(2,0)-(5,2)) [trace.hs:3:10-12] *Main> :back Logged breakpoint at trace.hs:4:10-12 _result :: Int y :: Int 3 let y = x+1 in 4 let z = y+1 in 5 z [-1: trace.hs:4:10-12] *Main> :back Logged breakpoint at trace.hs:5:2 _result :: Int z :: Int 4 let z = y+1 in 5 z 6 Cheers, Simon From marlowsd at gmail.com Tue Jan 6 09:27:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 09:19:36 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20090103154822.GA5555@zombie.inf.tu-dresden.de> Message-ID: <49636A6C.3020201@gmail.com> Conal Elliott wrote: > Indeed -- many thanks to Bertram, Sterling, Peter & others for the > help! I think getting this bug fixed will solve Reactive's mysterious > bugs and unblock its progress. Ok, we can fix the fairly simple bug that a thread created in blocked mode blocks throwTos after the thread has finished. But I'm slightly suspicious of the <> results you were getting - does this bug explain those too? Cheers, Simon From marlowsd at gmail.com Tue Jan 6 09:36:05 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 09:27:46 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <495933F6.5020407@charter.net> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20081229062647.GA4205@zombie.inf.tu-dresden.de> <495933F6.5020407@charter.net> Message-ID: <49636C55.3040401@gmail.com> Isaac Dupree wrote: > Bertram Felgenhauer wrote: >> Now in fact, IO actions are indistinguishable from pure computations by >> the RTS, so this mechanism also makes IO actions resumable, in >> principle, if you can access the corresponding thunk somehow. Normally >> you can't - there is no reference to that thunk - but unsafePerformIO >> gives you that reference. > > I wonder if other things break in the presence of resumable IO > computations... the first thing that comes to mind is, inside a "block" > or "unblock" (which have to initiate, take down and deal with all that > infrastructure -- luckily you only use them inside a separate thread, a > forkIO within the unsafePerformIO... Which admittedly makes things > horribly confusing in its own way. Also does forkIO copy any state? it > copies blocked status now, which the unamb-calling thread might > have...). The state of the thread when entering the computation again, > could be different than it was when the computation was first suspended, > I'm guessing. (At least you need to be careful about what invariants > you assume; I'm not yet sure if it's possible to be careful enough.) There's one other bug in this area that we've known about for a while. In the comments in Exception.cmm: NB. there's a bug in here. If a thread is inside an unsafePerformIO, and inside blockAsyncExceptions# (there is an unblockAsyncExceptions_ret on the stack), and it is blocked in an interruptible operation, and it receives an exception, then the unsafePerformIO thunk will be updated with a stack object containing the unblockAsyncExceptions_ret frame. Later, when someone else evaluates this thunk, the blocked exception state is not restored. this probably isn't affecting reactive, but I thought I'd mention it. Cheers, Simon From marlowsd at gmail.com Tue Jan 6 09:45:41 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 09:37:22 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <49615706.3090909@isaac.cedarswampstudios.org> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20081229062647.GA4205@zombie.inf.tu-dresden.de> <49615706.3090909@isaac.cedarswampstudios.org> Message-ID: <49636E95.1060703@gmail.com> Isaac Dupree wrote: > therefore mapException is equally buggy! > >> mapException :: (Exception e1, Exception e2) => (e1 -> e2) -> a -> a >> mapException f v = unsafePerformIO (catch (evaluate v) >> (\x -> throw (f x))) > > If it maps an asynchronous exception.. and it's re-thrown as > synchronous... the same non-resumability happens! mapException is a > particular culprit because of the unsafePerformIO (so you had a good > reason to expect resumability, since it's for a pure computation, not in > IO) > > - does anyone use mapException? > > - is there some reason that we don't have all "throw"s (synch. or > asynch.) "patch up" the thunks? (memory leaks or serious inefficiency > or something?) In theory you could get a nasty space leak, but it's quite unlikely. When an exception is thrown, instead of just updating each thunk with "raise# DivByZero" for example, we would save the current computation in the heap to be restarted if the thunk was ever evaluated again. If the current computation refers to a large amount of heap data, technically that's a space leak. So one way to work around this would be to do all rethrows using throwTo. In most cases this will have no effect, because the rethrows happen in IO code which normally has no enclosing thunks, but in the case of mapException and unsafePerformIO it will fix (or work around) the problems we have with re-throwing async exceptions. Cheers, Simon From phercek at gmail.com Tue Jan 6 17:30:47 2009 From: phercek at gmail.com (Peter Hercek) Date: Tue Jan 6 17:22:34 2009 Subject: ghci debugger :trace command does not always extend trace history In-Reply-To: <49636656.9060000@gmail.com> References: <49636656.9060000@gmail.com> Message-ID: Hi Simon ... and whoever thinks he/she can help me with the right way of debugging with ghci, Sorry for the long post but I cannot explain more shortly what I would like to be able to do ... and maybe you find my ":find" and ":monitor" commands at the end useful ... and maybe you can propose some other useful user defined commands for ghci which were not mentioned in Claus' tutorial :-) Ok, so it is not a bug because each trace command creates a new context and trace history is context specific. This means my question now is: How can I get access to trace history of a nested trace command which just finished? Here are some explanations so that we understand each other: The top level trace of my old example is ":trace test 0". The nested trace of my old example is ":trace z". I would like to get access to the trace history of the nested trace after the nested trace finishes (e.g. after the command ":trace z" finished by printing the z value). Or the other option would be: How to launch ":trace z" so that a new nested trace is not created but the current trace (the one before launching ":trace z") is extended? I know I can use ":trace" to continue the current trace but this requires that I have some suitable breakpoint later on a place where value z is already forced and before the interesting trace history is not replaced with newer stuff. It may not be trivial to find such a place. Other option would be to place breakpoints on all the interesting places which lead to the computation of the result being forced with ":trace " and investigate the traces in the nested context. The problem here is that it is more work. If I would know the result first then I could focus only on the places which are the probable reason of the wrong value, moreover the lure of ":find" is tempting (I explain ":find" later). Typically the situation is more complicated (there are more options) than my small example. My requests/questions may look strange, but here is reasoning why I think I need the functionality. If you have better approach to debugging please let me know. Maybe there is still some interesting tutorial I did not read about ghc debugging or I just forgot something. When I debug, I typically know what is probably wrong based on the program output. So I place a breakpoint at one logical step before the output. When stopped at the breakpoint I force variables which do not need to stay lazy and from which the program output is printed. Then I can see if some part of the force result/output is unexpected. Then I would like to search the trace history to see values of variables which probably contributed to the wrong value of the force result/output. I hoped that using :trace instead of force would append the trace history. This backward search for a bug means less work since I need to investigate only the path from the dynamic evaluation tree root (the wrong program result) to a given node where the bug is. An ability to access trace history of a value I just forced would save me some program restarts. How much restarts would be saved depends on the trace history depth and my ability not to get lost in the order of lazy calls. If I do not have access to the trace history, the only option is to put a breakpoint at a place where the variable value I wanted to check is available and restart the program so that I can check the value. Since there is no way to print partially applied functions this value based approach is probably the only one working. This is supported by recommendations to use printf debugging. One more reason I would like to learn how to access the trace history of a forced value is that my :monitor commands conflict with ghci trace history. I was able to implement :monitor and :find commands based on Claus' ghci scripting tutorial: :monitor displays value of a given variable at a given location while discarding all the other output. It is a way to do printf debugging solely from ghci without changing source code (i.e. without adding Debug.Trace.trace calls). :monitor (used together with ":x") is not always better than printf debugging because it discards program output too, and cannot add an identifier to scope. But often it is ... at least for me because it separates printf debugging (defined using ":monitor" commands in a script I source with ":.") from the source code. :find finds a variable name in trace history, prints its value, and a location where it was found. The location is needed here because of name conflicts. The value located may not be the right one. Taking static scopes into account could discard a lot of false finds (not all of them). I think that taking static scopes and (maybe more detailed) trace history into account could rule out all false positives. But nobody wants to implement this in a ghci script ... I guess :-) Currently my :monitor command makes holes in trace history, lowering the value of :find command :-( If you are interested you can find :find and :monitor implementations here: http://www.hck.sk/users/peter/pub/.ghci It looks to me that the way tracing is done is unfortunate from the point of view of scripting custom ghci commands. It would be better to have a global trace history which would be activated/deactivated with command like ":trace on/off" and this would modify the behavior of the rest of the ghci commands appropriately. E.g. :continue would behave like :trace (without arguments) when tracing is on. It would be probably interesting to have more tracing buffers (but I did not think about this much). Now, it is done in a cool functional way which means more complicated user defined ghci commands ... unless I'm missing something :-) Thanks, Peter. Simon Marlow wrote: > Peter Hercek wrote: >> Hi, >> >> I expected ":trace expr" to always add data to the trace history but >> it does not do so for CAFs (which are not reduced yet). >> My point is that the command ":trace z" did not add anything to the >> trace history and I cannot check why value z is 2, because value of y >> is not in the trace history. Is this the expected behavior? If it is, >> how can I make ghci to extend the trace history when "forcing" variables? >> >> Peter. >> >> Here is the example: >> >> status:0 peter@metod [765] ~/tmp >> % cat a.hs >> test :: Int -> Int >> test x = >> let y = x+1 in >> let z = y+1 in >> z >> status:0 peter@metod [766] ~/tmp >> % ghci a.hs >> GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help >> Loading package base ... linking ... done. >> [1 of 1] Compiling Main ( a.hs, interpreted ) >> Ok, modules loaded: Main. >> *Main> :break Main 5 >> Breakpoint 0 activated at a.hs:5:2 >> *Main> :trace test 0 >> Stopped at a.hs:5:2 >> _result :: Int = _ >> z :: Int = _ >> 4 let z = y+1 in >> 5 z >> 6 >> [a.hs:5:2] *Main> :back >> Logged breakpoint at a.hs:(2,0)-(5,2) >> _result :: Int >> 1 test :: Int -> Int >> 2 test x = >> 3 let y = x+1 in >> 4 let z = y+1 in >> 5 z >> 6 >> [-1: a.hs:(2,0)-(5,2)] *Main> :back >> no more logged breakpoints > > ok so far - y and z have not been evaluated. > >> [-1: a.hs:(2,0)-(5,2)] *Main> :forward >> Stopped at a.hs:5:2 >> _result :: Int >> z :: Int >> 4 let z = y+1 in >> 5 z >> 6 >> [a.hs:5:2] *Main> :trace z >> 2 > > this evaluates z. > >> [a.hs:5:2] *Main> :back >> Logged breakpoint at a.hs:(2,0)-(5,2) >> _result :: Int >> 1 test :: Int -> Int >> 2 test x = >> 3 let y = x+1 in >> 4 let z = y+1 in >> 5 z >> 6 > > You are going back in the original context, but I presume you were > expecting to go back in the evaluation of z. You can only go back in > the context of the current evaluation, however. > > Try this: > > *Main> :break 3 > Breakpoint 4 activated at trace.hs:3:10-12 > *Main> :trace test 0 > Stopped at trace.hs:3:10-12 > _result :: Int = _ > x :: Int = 90 > 2 test x = > 3 let y = x+1 in > 4 let z = y+1 in > [trace.hs:3:10-12] *Main> :history > -1 : test (trace.hs:4:10-12) > -2 : test (trace.hs:5:2) > -3 : test (trace.hs:(2,0)-(5,2)) > > [trace.hs:3:10-12] *Main> :back > Logged breakpoint at trace.hs:4:10-12 > _result :: Int > y :: Int > 3 let y = x+1 in > 4 let z = y+1 in > 5 z > [-1: trace.hs:4:10-12] *Main> :back > Logged breakpoint at trace.hs:5:2 > _result :: Int > z :: Int > 4 let z = y+1 in > 5 z > 6 > > Cheers, > Simon From conal at conal.net Tue Jan 6 20:06:31 2009 From: conal at conal.net (Conal Elliott) Date: Tue Jan 6 19:58:07 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <49636A6C.3020201@gmail.com> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20090103154822.GA5555@zombie.inf.tu-dresden.de> <49636A6C.3020201@gmail.com> Message-ID: I don't know if the bug would explain <>. My guess is that the black-hole-detection code is incorrectly concluding there is a black hole because a thunk was marked as in the process of being evaluated, then the evaluating thread is killed without unmarking the thunk, and then another thread needs the whnf. This is a fairly naive guess. I don't know this machinery well enough to have confidence. What do you think? - Conal On Tue, Jan 6, 2009 at 6:27 AM, Simon Marlow wrote: > Conal Elliott wrote: > >> Indeed -- many thanks to Bertram, Sterling, Peter & others for the help! >> I think getting this bug fixed will solve Reactive's mysterious bugs and >> unblock its progress. >> > > Ok, we can fix the fairly simple bug that a thread created in blocked mode > blocks throwTos after the thread has finished. But I'm slightly suspicious > of the <> results you were getting - does this bug explain those too? > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090106/f8796e00/attachment.htm From alios at alios.org Wed Jan 7 03:41:43 2009 From: alios at alios.org (Markus Barenhoff) Date: Wed Jan 7 03:33:22 2009 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <494622DD.4060900@gmail.com> References: <20081126143015.GA28186@beteigeuze.alios.net> <492E6D11.1090102@gmail.com> <20081127113216.GA92698@beteigeuze.alios.net> <492FBCEA.4090406@gmail.com> <20081203102007.GA58325@beteigeuze.alios.net> <493FCA3B.70002@gmail.com> <20081212144345.GA90078@beteigeuze.alios.net> <494622DD.4060900@gmail.com> Message-ID: <20090107084143.GA2000@beteigeuze.alios.net> On Mon 15.12 09:26, Simon Marlow wrote: Hello everyone, a happy new year first of all. > 5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package > template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall > -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash > -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls > -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances > -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi > -hcsuf p_hc -osuf p_o -idist-stage2/build -H32m -O -Rghc-timing -O2 -c > nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o -ohi > dist-stage2/build/MachRegs.p_hi > >ghc: panic! (the 'impossible' happened) > > (GHC version 6.11.20081211 for x86_64-unknown-freebsd): > > CoreToStg.myCollectArgs > > (__scc {trivColorable ghc-6.11.20081211:MachRegs !} > > ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0) > > eta_s2Ni{v} [lid] > > > >Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > This is a known problem with the build right now. I'll try to install a > fix this week, but in the meantime you can avoid building profiled > libraries by copying mk/build.mk.sample to mk/build.mk and uncommenting the > line that says 'BuildFlavour = quick'. > Yesterday I updated my sources to the current darcs version. Now the build works again, but there still seems to exist a problem with memory allocation: --- snip --- $ ghci GHCi, version 6.11.20090105: http://www.haskell.org/ghc/ :? for help ghc: mmap 28672 bytes at 0x40099000: Invalid argument ghc: Try specifying an address with +RTS -xm -RTS --- snip --- The ghci does not coredump anymore like it did in my first posting. I also tried specifing different addresses with the -xm switch without success. Here is the memory map just after start: --- snip --- $ cat /proc/19219/map 0x400000 0x14f8000 4213 0 0xffffff0006094d00 r-x 1 0 0x2100 COW NNC vnode /usr/local/haskell/lib/ghc-6.11.20090105/ghc 0x15f7000 0x178a000 251 0 0xffffff000618dd00 rw- 1 0 0x2100 COW NNC vnode /usr/local/haskell/lib/ghc-6.11.20090105/ghc 0x178a000 0x178e000 3 0 0xffffff00370a6dd0 rw- 2 0 0x2100 NCOW NNC default - 0x178e000 0x1800000 1 0 0xffffff00370a6dd0 rwx 2 0 0x2100 NCOW NNC default - 0x8015f7000 0x80161c000 28 0 0xffffff003af6f8f0 r-x 1 0 0x2100 COW NNC vnode /libexec/ld-elf.so.1 0x80161c000 0x801624000 7 0 0xffffff000618da90 rw- 1 0 0x2100 NCOW NNC default - 0x80171b000 0x801722000 7 0 0xffffff0037db6680 rw- 1 0 0x2100 COW NNC vnode /libexec/ld-elf.so.1 0x801722000 0x801728000 6 0 0xffffff00062de680 rw- 1 0 0x2100 NCOW NNC default - 0x801728000 0x801738000 16 0 0xffffff002ed375b0 r-x 1 0 0x2100 COW NNC vnode /lib/libthr.so.3 0x801738000 0x801739000 1 0 0xffffff003a5d2410 r-x 1 0 0x2100 COW NNC vnode /lib/libthr.so.3 0x801739000 0x801839000 4 0 0xffffff0001caa000 r-x 172 41 0x4 COW NC vnode /lib/libthr.so.3 0x801839000 0x80183c000 3 0 0xffffff000621d820 rw- 1 0 0x2100 COW NNC vnode /lib/libthr.so.3 0x80183c000 0x80183e000 2 0 0xffffff0037f9aa90 rw- 1 0 0x2100 NCOW NNC default - 0x80183e000 0x801849000 9 0 0xffffff00015c2c30 r-x 166 74 0x4 COW NC vnode /lib/libutil.so.7 0x801849000 0x80184a000 1 0 0xffffff00061e5680 r-x 1 0 0x2100 COW NNC vnode /lib/libutil.so.7 0x80184a000 0x80194a000 3 0 0xffffff00015c2c30 r-x 166 74 0x4 COW NC vnode /lib/libutil.so.7 0x80194a000 0x80194c000 2 0 0xffffff00061e5820 rw- 1 0 0x2100 COW NNC vnode /lib/libutil.so.7 0x80194c000 0x80194d000 0 0 0 rw- 0 0 0x0 NCOW NNC none - 0x80194d000 0x801965000 17 0 0xffffff00015ee0d0 r-x 204 48 0x4 COW NC vnode /lib/libm.so.5 0x801965000 0x801966000 1 0 0xffffff00061ae000 r-x 1 0 0x2100 COW NNC vnode /lib/libm.so.5 0x801966000 0x801a65000 3 0 0xffffff00015ee0d0 r-x 204 48 0x4 COW NC vnode /lib/libm.so.5 0x801a65000 0x801a67000 2 0 0xffffff003a102750 rw- 1 0 0x2100 COW NNC vnode /lib/libm.so.5 0x801a67000 0x801a6a000 3 0 0xffffff0001cf2680 r-x 8 4 0x4 COW NC vnode /usr/lib/librt.so.1 0x801a6a000 0x801a6b000 1 0 0xffffff000618e000 r-x 1 0 0x2100 COW NNC vnode /usr/lib/librt.so.1 0x801a6b000 0x801b6b000 1 0 0xffffff0001cf2680 r-x 8 4 0x4 COW NC vnode /usr/lib/librt.so.1 0x801b6b000 0x801b6c000 1 0 0xffffff0031604270 rw- 1 0 0x2100 COW NNC vnode /usr/lib/librt.so.1 0x801b6c000 0x801c57000 93 0 0xffffff00015c2270 r-x 512 182 0x4 COW NC vnode /lib/libc.so.7 0x801c57000 0x801c58000 1 0 0xffffff00312f0820 r-x 1 0 0x2100 COW NNC vnode /lib/libc.so.7 0x801c58000 0x801d58000 0 0 0xffffff00015c2270 r-x 512 182 0x4 COW NC vnode /lib/libc.so.7 0x801d58000 0x801d75000 29 0 0xffffff000631e340 rw- 1 0 0x2100 COW NNC vnode /lib/libc.so.7 0x801d75000 0x801d8c000 5 0 0xffffff0006248270 rw- 2 0 0x2100 NCOW NNC default - 0x801e00000 0x801f00000 3 0 0xffffff0006248270 rw- 2 0 0x2100 NCOW NNC default - 0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0 0 0x0 NCOW NNC none - 0x7ffffffe0000 0x800000000000 3 0 0xffffff00061704e0 rwx 1 0 0x2100 NCOW NNC default - --- snip --- Regards Markus -- Markus Barenhoff - M?nster - Germany - Europe - Earth -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 479 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090107/139d0f11/attachment.bin From rwbarton at math.harvard.edu Wed Jan 7 04:02:14 2009 From: rwbarton at math.harvard.edu (Reid Barton) Date: Wed Jan 7 03:53:50 2009 Subject: GADTs and functional dependencies in ghc 6.10.1 Message-ID: <20090107090214.GA9429@rwbarton.mit.edu> Hello all, I think (hope) this question is different from the ones about GADTs recently discussed on this list. The following program compiles under ghc 6.8.2 but not under ghc 6.10.1: > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, GADTs, KindSignatures, ScopedTypeVariables #-} > > class Foo a fa | a -> fa where > n :: a -> Int > > data Bar :: * -> * -> * where > Id :: Bar a a > > baz :: forall a fa b fb. (Foo a fa, Foo b fb) => Bar a b -> Int > baz Id = n (undefined :: a) ghc 6.10.1's error message: /tmp/fundep.hs:10:0: Couldn't match expected type `fb' against inferred type `fa' `fb' is a rigid type variable bound by the type signature for `baz' at /tmp/fundep.hs:9:21 `fa' is a rigid type variable bound by the type signature for `baz' at /tmp/fundep.hs:9:16 When using functional dependencies to combine Foo a fa, arising from a use of `n' at /tmp/fundep.hs:10:9-26 Foo a fb, arising from the type signature for `baz' at /tmp/fundep.hs:10:0-26 When generalising the type(s) for `baz' I find the message about the `Foo a fb' constraint quite confusing. Can anyone explain this error message to me? If I change the type of Id to Id :: Bar a b, then the program compiles. Regards, Reid From simonpj at microsoft.com Wed Jan 7 04:08:06 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jan 7 03:59:42 2009 Subject: GADTs and functional dependencies in ghc 6.10.1 In-Reply-To: <20090107090214.GA9429@rwbarton.mit.edu> References: <20090107090214.GA9429@rwbarton.mit.edu> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33286F3DCF6@EA-EXMSG-C334.europe.corp.microsoft.com> Reid, Ah yes. The interaction of functional dependencies and GADTs is flaky and unpredictable in both 6.8 and 6.10. It's actually rather tricky to get right -- see our ICFP'08 paper. You may have better luck using type families instead of functional dependencies, but even then 6.10 isn't really right. We're working very actively on this topic. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Reid Barton | Sent: 07 January 2009 09:02 | To: glasgow-haskell-users@haskell.org | Subject: GADTs and functional dependencies in ghc 6.10.1 | | Hello all, | | I think (hope) this question is different from the ones about GADTs | recently discussed on this list. The following program compiles under | ghc 6.8.2 but not under ghc 6.10.1: | | > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, GADTs, KindSignatures, | ScopedTypeVariables #-} | > | > class Foo a fa | a -> fa where | > n :: a -> Int | > | > data Bar :: * -> * -> * where | > Id :: Bar a a | > | > baz :: forall a fa b fb. (Foo a fa, Foo b fb) => Bar a b -> Int | > baz Id = n (undefined :: a) | | ghc 6.10.1's error message: | | /tmp/fundep.hs:10:0: | Couldn't match expected type `fb' against inferred type `fa' | `fb' is a rigid type variable bound by | the type signature for `baz' at /tmp/fundep.hs:9:21 | `fa' is a rigid type variable bound by | the type signature for `baz' at /tmp/fundep.hs:9:16 | When using functional dependencies to combine | Foo a fa, arising from a use of `n' at /tmp/fundep.hs:10:9-26 | Foo a fb, | arising from the type signature for `baz' at /tmp/fundep.hs:10:0-26 | When generalising the type(s) for `baz' | | I find the message about the `Foo a fb' constraint quite confusing. | Can anyone explain this error message to me? | | If I change the type of Id to Id :: Bar a b, then the program compiles. | | Regards, | Reid | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Wed Jan 7 10:22:47 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 7 10:14:26 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20090103154822.GA5555@zombie.inf.tu-dresden.de> <49636A6C.3020201@gmail.com> Message-ID: <4964C8C7.2040507@gmail.com> The bugs that we have identified result in deadlocks - the runtime doesn't notice that a thread blocked in throwTo can continue. I can't think of a way that this could lead to bogus <>, but I suppose I wouldn't be too surprised if it were possible. The best way forward is for you to test out a snapshot once these patches have made it into a build. Does that sound reasonable? I've been running your TestRace program for quite a while on 4 processors without any hangs now. Cheers, Simon Conal Elliott wrote: > I don't know if the bug would explain <>. My guess is that the > black-hole-detection code is incorrectly concluding there is a black > hole because a thunk was marked as in the process of being evaluated, > then the evaluating thread is killed without unmarking the thunk, and > then another thread needs the whnf. This is a fairly naive guess. I > don't know this machinery well enough to have confidence. > > What do you think? > > - Conal > > On Tue, Jan 6, 2009 at 6:27 AM, Simon Marlow > wrote: > > Conal Elliott wrote: > > Indeed -- many thanks to Bertram, Sterling, Peter & others for > the help! I think getting this bug fixed will solve Reactive's > mysterious bugs and unblock its progress. > > > Ok, we can fix the fairly simple bug that a thread created in > blocked mode blocks throwTos after the thread has finished. But I'm > slightly suspicious of the <> results you were getting - does > this bug explain those too? > > Cheers, > Simon > > From conal at conal.net Wed Jan 7 22:39:16 2009 From: conal at conal.net (Conal Elliott) Date: Wed Jan 7 22:30:47 2009 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <4964C8C7.2040507@gmail.com> References: <20081228020305.GA4218@zombie.inf.tu-dresden.de> <20090103154822.GA5555@zombie.inf.tu-dresden.de> <49636A6C.3020201@gmail.com> <4964C8C7.2040507@gmail.com> Message-ID: Hi Simon, That's great news. Please let me know when there's a build I can grab, and I'll try it out. Regards, - Conal On Wed, Jan 7, 2009 at 7:22 AM, Simon Marlow wrote: > The bugs that we have identified result in deadlocks - the runtime doesn't > notice that a thread blocked in throwTo can continue. I can't think of a > way that this could lead to bogus <>, but I suppose I wouldn't be too > surprised if it were possible. > > The best way forward is for you to test out a snapshot once these patches > have made it into a build. Does that sound reasonable? I've been running > your TestRace program for quite a while on 4 processors without any hangs > now. > > Cheers, > Simon > > Conal Elliott wrote: > >> I don't know if the bug would explain <>. My guess is that the >> black-hole-detection code is incorrectly concluding there is a black hole >> because a thunk was marked as in the process of being evaluated, then the >> evaluating thread is killed without unmarking the thunk, and then another >> thread needs the whnf. This is a fairly naive guess. I don't know this >> machinery well enough to have confidence. >> >> What do you think? >> >> - Conal >> >> On Tue, Jan 6, 2009 at 6:27 AM, Simon Marlow > marlowsd@gmail.com>> wrote: >> >> Conal Elliott wrote: >> >> Indeed -- many thanks to Bertram, Sterling, Peter & others for >> the help! I think getting this bug fixed will solve Reactive's >> mysterious bugs and unblock its progress. >> >> >> Ok, we can fix the fairly simple bug that a thread created in >> blocked mode blocks throwTos after the thread has finished. But I'm >> slightly suspicious of the <> results you were getting - does >> this bug explain those too? >> >> Cheers, >> Simon >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090107/2caaebcd/attachment-0001.htm From rwbarton at math.harvard.edu Thu Jan 8 00:58:08 2009 From: rwbarton at math.harvard.edu (Reid Barton) Date: Thu Jan 8 00:49:38 2009 Subject: building ghc-6.10.1 against readline Message-ID: <20090108055808.GB9429@rwbarton.mit.edu> Hello all, Here are quick and dirty instructions for building ghc-6.10.1 against readline instead of editline, for anyone who may be interested. 1. Unpack the ghc source and extralibs trees into ~/build/ghc-6.10.1 (Where you put your build tree obviously doesn't matter; I just specify it for clarity.) 2. Download this patch to ~/build: http://mauke.ath.cx/stuff/haskell/ghc-6.10.1-readline.diff 3. Apply the patch by running (from ~/build): patch -p0 < ghc-6.10.1-readline.diff 4. Download the readline package to ~/build/ghc-6.10.1/libraries: http://hackage.haskell.org/packages/archive/readline/1.0.1.0/readline-1.0.1.0.tar.gz 5. Unpack it, and create a symlink (in ~/build/ghc-6.10.1/libraries): ln -s readline-1.0.1.0 readline 6. Now in ~/build/ghc-6.10.1, you can run ./configure, make, etc. Thanks to mauke on #haskell for the patch, which is also appended to this email for posterity. Regards, Reid ----------- ghc-6.10.1-readline.diff diff -ru ghc-6.10.1/compiler/ghc.cabal.in ghc-6.10.1-hax/compiler/ghc.cabal.in --- ghc-6.10.1/compiler/ghc.cabal.in 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/compiler/ghc.cabal.in 2008-11-10 04:17:42.000000000 +0100 @@ -72,7 +72,7 @@ Build-Depends: unix if flag(editline) - Build-Depends: editline + Build-Depends: readline CPP-Options: -DUSE_EDITLINE GHC-Options: -Wall -fno-warn-name-shadowing -fno-warn-orphans diff -ru ghc-6.10.1/compiler/ghci/InteractiveUI.hs ghc-6.10.1-hax/compiler/ghci/InteractiveUI.hs --- ghc-6.10.1/compiler/ghci/InteractiveUI.hs 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/compiler/ghci/InteractiveUI.hs 2008-11-10 04:28:39.000000000 +0100 @@ -66,7 +66,7 @@ #ifdef USE_EDITLINE import Control.Concurrent ( yield ) -- Used in readline loop -import System.Console.Editline.Readline as Readline +import System.Console.Readline as Readline #endif --import SystemExts @@ -327,7 +327,7 @@ Readline.initialize withGhcAppData - (\dir -> Readline.readHistory (dir "ghci_history")) + (\dir -> return True {- Readline.readHistory (dir "ghci_history") -}) (return True) Readline.setAttemptedCompletionFunction (Just completeWord) @@ -367,8 +367,8 @@ #ifdef USE_EDITLINE liftIO $ do - Readline.stifleHistory 100 - withGhcAppData (\dir -> Readline.writeHistory (dir "ghci_history")) + -- Readline.stifleHistory 100 + withGhcAppData (\dir -> return True {- Readline.writeHistory (dir "ghci_history") -}) (return True) Readline.resetTerminal Nothing #endif diff -ru ghc-6.10.1/libraries/Makefile ghc-6.10.1-hax/libraries/Makefile --- ghc-6.10.1/libraries/Makefile 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/libraries/Makefile 2008-11-10 04:12:01.000000000 +0100 @@ -46,7 +46,7 @@ ifeq "$(Windows)" "YES" SUBDIRS += $(wildcard Win32) endif -SUBDIRS += directory process pretty hpc template-haskell editline Cabal random haskell98 +SUBDIRS += directory process pretty hpc template-haskell readline Cabal random haskell98 # Set GhcBootLibs=YES from the command line to work with just the libraries # needed to bootstrap GHC. From marlowsd at gmail.com Thu Jan 8 07:22:51 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jan 8 07:14:26 2009 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <20090107084143.GA2000@beteigeuze.alios.net> References: <20081126143015.GA28186@beteigeuze.alios.net> <492E6D11.1090102@gmail.com> <20081127113216.GA92698@beteigeuze.alios.net> <492FBCEA.4090406@gmail.com> <20081203102007.GA58325@beteigeuze.alios.net> <493FCA3B.70002@gmail.com> <20081212144345.GA90078@beteigeuze.alios.net> <494622DD.4060900@gmail.com> <20090107084143.GA2000@beteigeuze.alios.net> Message-ID: <4965F01B.9070308@gmail.com> Markus Barenhoff wrote: > On Mon 15.12 09:26, Simon Marlow wrote: > > > Hello everyone, > > a happy new year first of all. > >> 5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package >> template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall >> -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash >> -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls >> -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances >> -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi >> -hcsuf p_hc -osuf p_o -idist-stage2/build -H32m -O -Rghc-timing -O2 -c >> nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o -ohi >> dist-stage2/build/MachRegs.p_hi >>> ghc: panic! (the 'impossible' happened) >>> (GHC version 6.11.20081211 for x86_64-unknown-freebsd): >>> CoreToStg.myCollectArgs >>> (__scc {trivColorable ghc-6.11.20081211:MachRegs !} >>> ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0) >>> eta_s2Ni{v} [lid] >>> >>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> This is a known problem with the build right now. I'll try to install a >> fix this week, but in the meantime you can avoid building profiled >> libraries by copying mk/build.mk.sample to mk/build.mk and uncommenting the >> line that says 'BuildFlavour = quick'. >> > > Yesterday I updated my sources to the current darcs version. Now the build works > again, but there still seems to exist a problem with memory allocation: > > --- snip --- > $ ghci > GHCi, version 6.11.20090105: http://www.haskell.org/ghc/ :? for help > ghc: mmap 28672 bytes at 0x40099000: Invalid argument > ghc: Try specifying an address with +RTS -xm -RTS > --- snip --- Could you run ktrace or truss on ghci so we can see the offending call to mmap()? I'm not sure what it is that the OS is complaining about. Cheers, Simon From marlowsd at gmail.com Thu Jan 8 10:55:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jan 8 10:46:56 2009 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <20090108134501.GA80983@beteigeuze.alios.net> References: <492E6D11.1090102@gmail.com> <20081127113216.GA92698@beteigeuze.alios.net> <492FBCEA.4090406@gmail.com> <20081203102007.GA58325@beteigeuze.alios.net> <493FCA3B.70002@gmail.com> <20081212144345.GA90078@beteigeuze.alios.net> <494622DD.4060900@gmail.com> <20090107084143.GA2000@beteigeuze.alios.net> <4965F01B.9070308@gmail.com> <20090108134501.GA80983@beteigeuze.alios.net> Message-ID: <496621E9.6040701@gmail.com> Markus Barenhoff wrote: > On Thu 08.01 12:22, Simon Marlow wrote: >> Markus Barenhoff wrote: >>> On Mon 15.12 09:26, Simon Marlow wrote: >>> Yesterday I updated my sources to the current darcs version. Now the build >>> works >>> again, but there still seems to exist a problem with memory allocation: >>> >>> --- snip --- >>> $ ghci >>> GHCi, version 6.11.20090105: http://www.haskell.org/ghc/ :? for help >>> ghc: mmap 28672 bytes at 0x40099000: Invalid argument >>> ghc: Try specifying an address with +RTS -xm -RTS >>> --- snip --- >> Could you run ktrace or truss on ghci so we can see the offending call to >> mmap()? I'm not sure what it is that the OS is complaining about. >> > > it looks like it is trying to mmap() stdin... > > attached you find the complete trace. > > --- snip --- > ... > 38437: stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0) > 38437: stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0) > 38437: open("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",O_RDONLY,00) = 6 (0x6) > 38437: mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE,6,0x0) = 34382954496 (0x801624000) > 38437: munmap(0x801624000,626688) = 0 (0x0) > 38437: mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED,6,0x0) = 1073741824 (0x40000000) > 38437: close(6) = 0 (0x0) > 38437: mmap(0x40099000,28672,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0,0x0) ERR#22 'Invalid argument' Ah, I think I see the problem. FreeBSD requires the fd argument to be -1 for MAP_ANON, but Linux doesn't care which is why it didn't fail in this way for me. I'll commit a patch as soon as it validates. Cheers, Simon From bulat.ziganshin at gmail.com Thu Jan 8 11:40:06 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 8 11:31:49 2009 Subject: ghc 6.10.2 - when? Message-ID: <629826827.20090108194006@gmail.com> Hello glasgow-haskell-users, are you have any plans of releasing ghc 6.10.2 soon? i ask since there are plans to issue gtk2hs soon, it will be great to have cleaned up 6.10 behind it -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Thu Jan 8 12:02:26 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jan 8 11:54:01 2009 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <496621E9.6040701@gmail.com> References: <492E6D11.1090102@gmail.com> <20081127113216.GA92698@beteigeuze.alios.net> <492FBCEA.4090406@gmail.com> <20081203102007.GA58325@beteigeuze.alios.net> <493FCA3B.70002@gmail.com> <20081212144345.GA90078@beteigeuze.alios.net> <494622DD.4060900@gmail.com> <20090107084143.GA2000@beteigeuze.alios.net> <4965F01B.9070308@gmail.com> <20090108134501.GA80983@beteigeuze.alios.net> <496621E9.6040701@gmail.com> Message-ID: <496631A2.3070305@gmail.com> Simon Marlow wrote: > Markus Barenhoff wrote: >> On Thu 08.01 12:22, Simon Marlow wrote: >>> Markus Barenhoff wrote: >>>> On Mon 15.12 09:26, Simon Marlow wrote: >>>> Yesterday I updated my sources to the current darcs version. Now the >>>> build works >>>> again, but there still seems to exist a problem with memory allocation: >>>> >>>> --- snip --- >>>> $ ghci >>>> GHCi, version 6.11.20090105: http://www.haskell.org/ghc/ :? for help >>>> ghc: mmap 28672 bytes at 0x40099000: Invalid argument >>>> ghc: Try specifying an address with +RTS -xm -RTS >>>> --- snip --- >>> Could you run ktrace or truss on ghci so we can see the offending >>> call to mmap()? I'm not sure what it is that the OS is complaining >>> about. >>> >> >> it looks like it is trying to mmap() stdin... >> >> attached you find the complete trace. >> >> --- snip --- >> ... >> 38437: >> stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ >> mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0) >> 38437: >> stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ >> mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0) >> 38437: >> open("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",O_RDONLY,00) >> = 6 (0x6) >> 38437: >> mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE,6,0x0) >> = 34382954496 (0x801624000) >> 38437: munmap(0x801624000,626688) = 0 (0x0) >> 38437: >> mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED,6,0x0) >> = 1073741824 (0x40000000) >> 38437: close(6) = 0 (0x0) >> 38437: >> mmap(0x40099000,28672,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0,0x0) >> ERR#22 'Invalid argument' > > Ah, I think I see the problem. FreeBSD requires the fd argument to be > -1 for MAP_ANON, but Linux doesn't care which is why it didn't fail in > this way for me. I'll commit a patch as soon as it validates. Patch pushed... I'd be grateful if you could test it - thanks! Simon From dominic.steinitz at blueyonder.co.uk Sat Jan 10 05:23:14 2009 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jan 10 05:25:49 2009 Subject: GADT Strangeness In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33286F3D1D8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <494E0E60.5000902@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C33286D93C86@EA-EXMSG-C334.europe.corp.microsoft.com> <495F1B1F.6060006@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C33286F3D1D8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <49687712.1020903@blueyonder.co.uk> Simon Peyton-Jones wrote: > | Is it worth noting it here > | http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching > | or is it something that has always existed with GADTs and I just didn't > | trip over it? > > I've added a para. Good idea. Thanks very much. I'm slightly embarassed: what I meant was that I would add the paragraph if you thought it was worth doing. > OK. let's see if anyone else comments. Do ping me in a while to action it if I forget. I suppose its priority depends on how many people start to get tripped up. I'm guessing there aren't that many GADT users who don't know (by now at any rate) how to understand the error messages. I'm sure there are plenty of higher priority items. Dominic. From karel.gardas at centrum.cz Sat Jan 10 16:05:31 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat Jan 10 15:57:02 2009 Subject: GHC head Solaris bot failing with HsColour needed but wasn't found. Message-ID: <49690D9B.7060508@centrum.cz> Hello, I've noticed that my GHC head solaris bot is failing with HsColour needed but wasn't found. Set HSCOLOUR_SRCS=NO if you don't want to use it message on stage1 build since Jan 04. Please let me know what I need to install in order to make head build able again. Thanks, Karel From duncan.coutts at worc.ox.ac.uk Sat Jan 10 16:15:25 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 10 16:06:59 2009 Subject: Build system idea In-Reply-To: <5ab17e790809042315n618b9089j667a7aa130ae823d@mail.gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <5ab17e790809040959y48259f0s9d28b771069cac2e@mail.gmail.com> <1220560215.24846.576.camel@localhost> <5ab17e790809042315n618b9089j667a7aa130ae823d@mail.gmail.com> Message-ID: <1231622125.4794.23.camel@localhost> Just cleaning out my inbox and realised I meant to reply to this about 4 months ago :-) On Thu, 2008-09-04 at 23:15 -0700, Iavor Diatchki wrote: > On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts > > Packages are not supposed to expose different APIs with different > flags > > so I don't think that's right. Under that assumption cabal-install > can > > in principle resolve everything fine. I'm not claiming the current > > resolution algorithm is very clever when it comes to picking flags > > (though it should always pick ones that give an overall valid > solution) > > but there is certainly scope for a cleverer one. Also, the user can > > always specify what features they want, which is what systems like > > Gentoo do. > > > > Do you have any specific test cases where the current algorithm is less > > than ideal? It'd be useful to report those for the next time someone > > hacks on the resolver. > > The examples that I was thinking of arise when libraries can provide > conditional functionality, depending on what is already installed on > the system, a kind of "co-dependecy". [...] > > I guess, you could say that we structured the library wrong---perhaps > we should have had a core package that only provides manual parsing > (no external libraries required), and then have a separate packages > for each of the parsers that use a different parsing combinator > library. > > Conceptually, this might be better, but in practice it seems like a > bit of a pain---each parser is a single module, but it would need a > whole separate directory, with a separate cabal file, license, and a > setup script, all of which would be almost copies of each other. Right, I admit it might be handy. Unfortunately we could not translate such packages into other packaging systems because I don't know of any standard native packaging systems that allow such co-dependencies. They have to be translated into multiple packages. If we did support such conditional stuff it would have to be explicit to the package manager because otherwise choices about install order would change the exposed functionality (indeed it might not even be stable / globally solvable). In particular I've no idea what we should do about instances. Where we'd like to provide an instance for a class defined in another package that we do not directly need (except to be able to provide the instance). If we did not have the constraint of wanting to generate native packages then there are various more sophisticated things we could do, but generating native packages is really quite important to our plans for world domination. Duncan From duncan.coutts at worc.ox.ac.uk Sat Jan 10 16:43:07 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 10 16:34:36 2009 Subject: GHC head Solaris bot failing with HsColour needed but wasn't found. In-Reply-To: <49690D9B.7060508@centrum.cz> References: <49690D9B.7060508@centrum.cz> Message-ID: <1231623787.4794.46.camel@localhost> On Sat, 2009-01-10 at 22:05 +0100, Karel Gardas wrote: > Hello, > > I've noticed that my GHC head solaris bot is failing with > > HsColour needed but wasn't found. > Set HSCOLOUR_SRCS=NO if you don't want to use it > > message on stage1 build since Jan 04. Please let me know what I need to > install in order to make head build able again. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hscolour If you've got cabal-install then: $ cabal update $ cabal install hscolour Duncan From igloo at earth.li Sat Jan 10 16:45:22 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jan 10 16:36:58 2009 Subject: GHC head Solaris bot failing with HsColour needed but wasn't found. In-Reply-To: <49690D9B.7060508@centrum.cz> References: <49690D9B.7060508@centrum.cz> Message-ID: <20090110214522.GA19945@matrix.chaos.earth.li> Hi Karel, On Sat, Jan 10, 2009 at 10:05:31PM +0100, Karel Gardas wrote: > > I've noticed that my GHC head solaris bot is failing with > > HsColour needed but wasn't found. > Set HSCOLOUR_SRCS=NO if you don't want to use it Thanks for letting us know. > message on stage1 build since Jan 04. Please let me know what I need to > install in order to make head build able again. Can you please install http://hackage.haskell.org/packages/archive/hscolour/1.10.1/hscolour-1.10.1.tar.gz Let me know if you have any problems. Thanks Ian From karel.gardas at centrum.cz Sat Jan 10 17:13:22 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat Jan 10 17:04:59 2009 Subject: GHC head Solaris bot failing with HsColour needed but wasn't found. In-Reply-To: <1231623787.4794.46.camel@localhost> References: <49690D9B.7060508@centrum.cz> <1231623787.4794.46.camel@localhost> Message-ID: <49691D82.8000407@centrum.cz> Duncan Coutts wrote: > On Sat, 2009-01-10 at 22:05 +0100, Karel Gardas wrote: >> Hello, >> >> I've noticed that my GHC head solaris bot is failing with >> >> HsColour needed but wasn't found. >> Set HSCOLOUR_SRCS=NO if you don't want to use it >> >> message on stage1 build since Jan 04. Please let me know what I need to >> install in order to make head build able again. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hscolour > > If you've got cabal-install then: > > $ cabal update > $ cabal install hscolour Thanks for your quick help. The bot is compiling again. Karel From duncan.coutts at worc.ox.ac.uk Sun Jan 11 09:48:03 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 11 09:39:26 2009 Subject: gcc version to use on sparc/solaris In-Reply-To: <495DE725.3030307@anu.edu.au> References: <495DE725.3030307@anu.edu.au> Message-ID: <1231685283.4794.89.camel@localhost> On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote: > I'm running into some huge compile times that I'm hoping someone will > have some suggestions about. When compiling Parser.hs the intermediate > .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get > through. > > Another attempted compile of GHC 6.8.3 is stuck on > libraries/template-haskell/Language/Haskell/TH/Syntax.hs with a 4MB > intermediate .hc file. Here is what I've discovered... I built four versions of gcc and used them to build ghc-6.8.3. I selected the last point release of the last four major gcc releases: gcc-4.0.4 gcc-4.1.2 gcc-4.2.4 gcc-4.3.2 Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the moment for ghc on sparc/solaris. gcc-4.0.4 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6130 expected passes 281 expected failures 0 unexpected passes 48 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,hpc,threaded1) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) enum01(hpc) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) Some fail in fairly simple ways: cabal01 fails because Solaris tar does not support -C conflicting_flags fails due to a difference in output: -ghc: cannot use `-V' with `--print-libdir' +ghc-6.8.3: cannot use `-V' with `--print-libdir' hClose002 fails with a different error: -Left hClose: invalid argument (Bad file descriptor) +Left hClose: invalid argument (Bad file number) 1861 fails because ghc uses C99 INFINITY macro without using C99 and Solaris header files are more strict about standards than other systems. http://hackage.haskell.org/trac/ghc/ticket/2929 Some look a bit more scary: testblockalloc fails with "out of memory (requested 8388608 bytes)" num012 produces different output: --2147483648 +2147483647 looks like overflow, so definitely something wrong. A number of tests timeout: seward-space-leak(ghci) joao-circular(all) barton-mangler-bug(all) A few tests get bus errors: conc042, conc043, conc044, conc045 ghciprog004 ffi019(all) gcc-4.1.2 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6125 expected passes 281 expected failures 0 unexpected passes 49 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,optc,hpc,threaded1,threaded2) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) The only difference is that enum01(hpc) does not fail and barton-mangler-bug fails in two more ways (optc, threaded2) gcc-4.2.4 ========= This fails 4 tests on the gcc testsuite. This is the version that gives us massive compile times for larger .hc files (8 hours+ for Syntax.hc). I thought that using -fno-unit-at-a-time would help but ghc is already using that so no luck. It does eventually build but takes nearly 2 days. No testsuite results yet. I'm not sure I can be bothered. gcc-4.3.2 ========= This fails 50 tests on the gcc testsuite. Does not work with ghc-6.8.3 at all, presumably due to the evil mangler. This manifests itself as ./configure failing when it tries to compile and run utils/pwd/pwd: checking for path to top of build tree... /tmp/ghc15055_0/ghc15055_0.hc: In function 'sqD_ret': /tmp/ghc15055_0/ghc15055_0.hc:95:0: note: if this code is reached, the program will abort [...] /tmp/ghc15055_0/ghc15055_0.hc: In function '__stginit_Main': /tmp/ghc15055_0/ghc15055_0.hc:750:0: note: if this code is reached, the program will abort configure: error: cannot determine current directory Indeed it does abort: $ utils/pwd/pwd Illegal Instruction (core dumped) Duncan From duncan.coutts at worc.ox.ac.uk Sun Jan 11 09:50:48 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 11 09:42:09 2009 Subject: gcc version to use on sparc/solaris In-Reply-To: <1231685283.4794.89.camel@localhost> References: <495DE725.3030307@anu.edu.au> <1231685283.4794.89.camel@localhost> Message-ID: <1231685448.4794.93.camel@localhost> On Sun, 2009-01-11 at 14:48 +0000, Duncan Coutts wrote: > I built four versions of gcc and used them to build ghc-6.8.3. While on the subject, the annoyances I bumped into while doing this are: discovering a ghc/gcc combination does not work is not obvious. The first symptom is ./configure failing to find the path to top of build tree. Of course I realised this happened to be because we build a Haskell pwd program during configure. It'll confuse other users. It would be nice if after detecting the location and version of ghc, ./configure would explicitly test that ghc to make sure it can compile, link and run a hello world program. Each of these stages can fail. On different occasions I've managed to get all three stages to fail independently so it would be nice if each were checked explicitly. The compile phase can fail if the ghc/gcc combo is bad. The link phase can fail if the ghc cannot find libgmp/libreadline/libwhatever. The run phase can fail if the ghc/gcc combo generated bad code or if the libgmp is not on the runtime linker path but was on the static linker path. It's rather tricky to configure ghc to use libraries from a non-standard location, one that is not on the standard linker link-time or runtime paths. See http://hackage.haskell.org/trac/ghc/ticket/2933 It's tricky to get configure ghc to use gcc from a non-standard location. The ./configure --with-gcc flag works for gcc used at build time but the installed ghc still uses ghc from the $PATH. Duncan From allbery at ece.cmu.edu Sun Jan 11 10:29:40 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Jan 11 10:21:01 2009 Subject: gcc version to use on sparc/solaris In-Reply-To: <1231685283.4794.89.camel@localhost> References: <495DE725.3030307@anu.edu.au> <1231685283.4794.89.camel@localhost> Message-ID: <51BD8F06-C8A9-4C68-9233-757F6D3FC685@ece.cmu.edu> On 2009 Jan 11, at 9:48, Duncan Coutts wrote: > On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote: >> I'm running into some huge compile times that I'm hoping someone will >> have some suggestions about. When compiling Parser.hs the >> intermediate >> .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get >> through. >> > Here is what I've discovered... > > I built four versions of gcc and used them to build ghc-6.8.3. I > selected the last point release of the last four major gcc releases: > gcc-4.0.4 > gcc-4.1.2 > gcc-4.2.4 > gcc-4.3.2 > > Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the > moment for ghc on sparc/solaris. FWIW I've built 6.8.2 with gcc-4.2.2, ti was slow but it built and the testsuite didn't look too horrible. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From duncan.coutts at worc.ox.ac.uk Sun Jan 11 10:59:33 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 11 10:50:57 2009 Subject: gcc version to use on sparc/solaris In-Reply-To: <51BD8F06-C8A9-4C68-9233-757F6D3FC685@ece.cmu.edu> References: <495DE725.3030307@anu.edu.au> <1231685283.4794.89.camel@localhost> <51BD8F06-C8A9-4C68-9233-757F6D3FC685@ece.cmu.edu> Message-ID: <1231689573.4794.106.camel@localhost> On Sun, 2009-01-11 at 10:29 -0500, Brandon S. Allbery KF8NH wrote: > On 2009 Jan 11, at 9:48, Duncan Coutts wrote: > > On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote: > >> I'm running into some huge compile times that I'm hoping someone will > >> have some suggestions about. When compiling Parser.hs the > >> intermediate > >> .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get > >> through. > >> > > Here is what I've discovered... > > > > I built four versions of gcc and used them to build ghc-6.8.3. I > > selected the last point release of the last four major gcc releases: > > gcc-4.0.4 > > gcc-4.1.2 > > gcc-4.2.4 > > gcc-4.3.2 > > > > Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the > > moment for ghc on sparc/solaris. > > FWIW I've built 6.8.2 with gcc-4.2.2, ti was slow but it built and the > testsuite didn't look too horrible. Yes, I built ghc-6.8.3 with gcc-4.2.4 and it builds ok, it just takes two days to do so. So it's not really usable for ghc development. It may be fine for using ghc, but not for hacking ghc. In future it should not matter once we get the -fasm route working. Then we'll only need gcc to build the rts and to assemble things, not to compile massive .hc files. Duncan From karel.gardas at centrum.cz Sun Jan 11 15:15:51 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sun Jan 11 15:07:16 2009 Subject: Solaris/x86 bot failing on stage2 haddock installation. Message-ID: <496A5377.2060108@centrum.cz> Hello, so it seems I'm still not lucky get head compiling well on solaris/x86 bot. This time compilation fails on stage2 at the haddock installation with following message: Installing library in /buildbot/ghc/kgardas/build/utils/haddock/install-inplace/lib/haddock-2.4.2 Installing executable(s) in /buildbot/ghc/kgardas/build/utils/haddock/install-inplace/bin Registering haddock-2.4.2... ghc-pkg: /buildbot/ghc/kgardas/build/ghc/inplace-datadir/package.conf: openFile: does not exist (No such file or directory) make[2]: *** [install-inplace] Error 1 make[2]: Leaving directory `/buildbot/ghc/kgardas/build/utils/haddock' make[1]: *** [with-stage-2] Error 2 make[1]: Leaving directory `/buildbot/ghc/kgardas/build/utils' make: *** [stage2] Error 2 see http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/98/steps/stage2/logs/stdio for more information. Do you have any idea what's going wrong this time? Is it a problem of my bot (shall I install anything else?) or is it GHC's issue? Thanks! Karel From kili at outback.escape.de Sun Jan 11 15:27:37 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Jan 11 15:19:26 2009 Subject: Solaris/x86 bot failing on stage2 haddock installation. In-Reply-To: <496A5377.2060108@centrum.cz> References: <496A5377.2060108@centrum.cz> Message-ID: <20090111202737.GA1176@petunia.outback.escape.de> On Sun, Jan 11, 2009 at 09:15:51PM +0100, Karel Gardas wrote: > ghc-pkg: /buildbot/ghc/kgardas/build/ghc/inplace-datadir/package.conf: > openFile: does not exist (No such file or directory) [...] > Do you have any idea what's going wrong this time? Is it a problem of my > bot (shall I install anything else?) or is it GHC's issue? A fix from Conal Elliott has already been pushed by Ian. The problem is that ghc-pkg now is much more picky when the package db doesn't exist. A similar problem currently occurs when you make install. Ciao, Kili From karel.gardas at centrum.cz Sun Jan 11 16:36:56 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sun Jan 11 16:28:16 2009 Subject: testsuite boot failure [was: Re: Solaris/x86 bot failing on stage2 haddock installation.] In-Reply-To: <20090111202737.GA1176@petunia.outback.escape.de> References: <496A5377.2060108@centrum.cz> <20090111202737.GA1176@petunia.outback.escape.de> Message-ID: <496A6678.3050109@centrum.cz> Matthias Kilian wrote: > On Sun, Jan 11, 2009 at 09:15:51PM +0100, Karel Gardas wrote: >> ghc-pkg: /buildbot/ghc/kgardas/build/ghc/inplace-datadir/package.conf: >> openFile: does not exist (No such file or directory) > [...] >> Do you have any idea what's going wrong this time? Is it a problem of my >> bot (shall I install anything else?) or is it GHC's issue? > > A fix from Conal Elliott has already been pushed by Ian. Indeed! Now compilation aborts on "booting" testsuite with following output: make: Entering directory `/buildbot/ghc/kgardas/build/testsuite' make: *** No rule to make target `boot'. Stop. make: Leaving directory `/buildbot/ghc/kgardas/build/testsuite' more on http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/99/steps/boottestsuite/logs/stdio Thanks, Karel From kili at outback.escape.de Sun Jan 11 17:04:05 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Jan 11 16:56:27 2009 Subject: testsuite boot failure [was: Re: Solaris/x86 bot failing on stage2 haddock installation.] In-Reply-To: <496A6678.3050109@centrum.cz> References: <496A5377.2060108@centrum.cz> <20090111202737.GA1176@petunia.outback.escape.de> <496A6678.3050109@centrum.cz> Message-ID: <20090111220404.GA6686@petunia.outback.escape.de> On Sun, Jan 11, 2009 at 10:36:56PM +0100, Karel Gardas wrote: > > A fix from Conal Elliott has already been pushed by Ian. > > Indeed! Now compilation aborts on "booting" testsuite with following output: > > make: Entering directory `/buildbot/ghc/kgardas/build/testsuite' > make: *** No rule to make target `boot'. Stop. > make: Leaving directory `/buildbot/ghc/kgardas/build/testsuite' This is strange: $ darcs changes --last=1 Sat Jan 10 22:42:04 CET 2009 Ian Lynagh * Add a boot target, and tidy up the Makefile a bit Yet the file in question (testsuite/mk/test.mk) isn't included by testsuite/Makefile nor testsuite/mk/boilerplate.mk. Did I ever complain about how broken the ghc build system is? ;-) Ciao, Kili From marlowsd at gmail.com Mon Jan 12 05:58:41 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 12 05:50:07 2009 Subject: ghci debugger :trace command does not always extend trace history In-Reply-To: References: <49636656.9060000@gmail.com> Message-ID: <496B2261.5050304@gmail.com> I agree with most of what you say - there should be a way to get access to the history after :trace has finished. Perhaps the right way is just to have a single global trace history. Please submit a feature request, with a proposal for the user interface, to the GHC bug tracker: http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Cheers, Simon Peter Hercek wrote: > Hi Simon ... and whoever thinks he/she can help me with the right way of > debugging with ghci, > > Sorry for the long post but I cannot explain more shortly what I would > like to be able to do ... and maybe you find my ":find" and ":monitor" > commands at the end useful ... and maybe you can propose some other > useful user defined commands for ghci which were not mentioned in Claus' > tutorial :-) > > Ok, so it is not a bug because each trace command creates a new context > and trace history is context specific. This means my question now is: > How can I get access to trace history of a nested trace command which > just finished? > Here are some explanations so that we understand each other: > The top level trace of my old example is ":trace test 0". > The nested trace of my old example is ":trace z". > I would like to get access to the trace history of the nested trace > after the nested trace finishes (e.g. after the command ":trace z" > finished by printing the z value). > Or the other option would be: How to launch ":trace z" so that a new > nested trace is not created but the current trace (the one before > launching ":trace z") is extended? > > I know I can use ":trace" to continue the current trace but this > requires that I have some suitable breakpoint later on a place where > value z is already forced and before the interesting trace history is > not replaced with newer stuff. It may not be trivial to find such a place. > Other option would be to place breakpoints on all the interesting places > which lead to the computation of the result being forced with ":trace > " and investigate the traces in the nested context. The problem > here is that it is more work. If I would know the result first then I > could focus only on the places which are the probable reason of the > wrong value, moreover the lure of ":find" is tempting (I explain ":find" > later). Typically the situation is more complicated (there are more > options) than my small example. > > My requests/questions may look strange, but here is reasoning why I > think I need the functionality. If you have better approach to debugging > please let me know. Maybe there is still some interesting tutorial I did > not read about ghc debugging or I just forgot something. > > When I debug, I typically know what is probably wrong based on the > program output. So I place a breakpoint at one logical step before the > output. When stopped at the breakpoint I force variables which do not > need to stay lazy and from which the program output is printed. Then I > can see if some part of the force result/output is unexpected. Then I > would like to search the trace history to see values of variables which > probably contributed to the wrong value of the force result/output. I > hoped that using :trace instead of force would append the trace history. > > This backward search for a bug means less work since I need to > investigate only the path from the dynamic evaluation tree root (the > wrong program result) to a given node where the bug is. An ability to > access trace history of a value I just forced would save me some program > restarts. How much restarts would be saved depends on the trace history > depth and my ability not to get lost in the order of lazy calls. If I do > not have access to the trace history, the only option is to put a > breakpoint at a place where the variable value I wanted to check is > available and restart the program so that I can check the value. > > Since there is no way to print partially applied functions this value > based approach is probably the only one working. This is supported by > recommendations to use printf debugging. > > One more reason I would like to learn how to access the trace history of > a forced value is that my :monitor commands conflict with ghci trace > history. I was able to implement :monitor and :find commands based on > Claus' ghci scripting tutorial: > > :monitor displays value of a given variable at a given location while > discarding all the other output. It is a way to do printf debugging > solely from ghci without changing source code (i.e. without adding > Debug.Trace.trace calls). :monitor (used together with ":x") is not > always better than printf debugging because it discards program output > too, and cannot add an identifier to scope. But often it is ... at least > for me because it separates printf debugging (defined using ":monitor" > commands in a script I source with ":.") from the source code. > > :find finds a variable name in trace history, prints its value, and a > location where it was found. The location is needed here because of name > conflicts. The value located may not be the right one. Taking static > scopes into account could discard a lot of false finds (not all of > them). I think that taking static scopes and (maybe more detailed) trace > history into account could rule out all false positives. But nobody > wants to implement this in a ghci script ... I guess :-) > > Currently my :monitor command makes holes in trace history, lowering the > value of :find command :-( > > If you are interested you can find :find and :monitor implementations > here: http://www.hck.sk/users/peter/pub/.ghci > > It looks to me that the way tracing is done is unfortunate from the > point of view of scripting custom ghci commands. It would be better to > have a global trace history which would be activated/deactivated with > command like ":trace on/off" and this would modify the behavior of the > rest of the ghci commands appropriately. E.g. :continue would behave > like :trace (without arguments) when tracing is on. It would be probably > interesting to have more tracing buffers (but I did not think about this > much). Now, it is done in a cool functional way which means more > complicated user defined ghci commands ... unless I'm missing something :-) > > > Thanks, > Peter. > > > Simon Marlow wrote: >> Peter Hercek wrote: >>> Hi, >>> >>> I expected ":trace expr" to always add data to the trace history but >>> it does not do so for CAFs (which are not reduced yet). >>> My point is that the command ":trace z" did not add anything to the >>> trace history and I cannot check why value z is 2, because value of y >>> is not in the trace history. Is this the expected behavior? If it is, >>> how can I make ghci to extend the trace history when "forcing" >>> variables? >>> >>> Peter. >>> >>> Here is the example: >>> >>> status:0 peter@metod [765] ~/tmp >>> % cat a.hs >>> test :: Int -> Int >>> test x = >>> let y = x+1 in >>> let z = y+1 in >>> z >>> status:0 peter@metod [766] ~/tmp >>> % ghci a.hs >>> GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help >>> Loading package base ... linking ... done. >>> [1 of 1] Compiling Main ( a.hs, interpreted ) >>> Ok, modules loaded: Main. >>> *Main> :break Main 5 >>> Breakpoint 0 activated at a.hs:5:2 >>> *Main> :trace test 0 >>> Stopped at a.hs:5:2 >>> _result :: Int = _ >>> z :: Int = _ >>> 4 let z = y+1 in >>> 5 z >>> 6 >>> [a.hs:5:2] *Main> :back >>> Logged breakpoint at a.hs:(2,0)-(5,2) >>> _result :: Int >>> 1 test :: Int -> Int >>> 2 test x = >>> 3 let y = x+1 in >>> 4 let z = y+1 in >>> 5 z >>> 6 >>> [-1: a.hs:(2,0)-(5,2)] *Main> :back >>> no more logged breakpoints >> >> ok so far - y and z have not been evaluated. >> >>> [-1: a.hs:(2,0)-(5,2)] *Main> :forward >>> Stopped at a.hs:5:2 >>> _result :: Int >>> z :: Int >>> 4 let z = y+1 in >>> 5 z >>> 6 >>> [a.hs:5:2] *Main> :trace z >>> 2 >> >> this evaluates z. >> >>> [a.hs:5:2] *Main> :back >>> Logged breakpoint at a.hs:(2,0)-(5,2) >>> _result :: Int >>> 1 test :: Int -> Int >>> 2 test x = >>> 3 let y = x+1 in >>> 4 let z = y+1 in >>> 5 z >>> 6 >> >> You are going back in the original context, but I presume you were >> expecting to go back in the evaluation of z. You can only go back in >> the context of the current evaluation, however. >> >> Try this: >> >> *Main> :break 3 >> Breakpoint 4 activated at trace.hs:3:10-12 >> *Main> :trace test 0 >> Stopped at trace.hs:3:10-12 >> _result :: Int = _ >> x :: Int = 90 >> 2 test x = >> 3 let y = x+1 in >> 4 let z = y+1 in >> [trace.hs:3:10-12] *Main> :history >> -1 : test (trace.hs:4:10-12) >> -2 : test (trace.hs:5:2) >> -3 : test (trace.hs:(2,0)-(5,2)) >> >> [trace.hs:3:10-12] *Main> :back >> Logged breakpoint at trace.hs:4:10-12 >> _result :: Int >> y :: Int >> 3 let y = x+1 in >> 4 let z = y+1 in >> 5 z >> [-1: trace.hs:4:10-12] *Main> :back >> Logged breakpoint at trace.hs:5:2 >> _result :: Int >> z :: Int >> 4 let z = y+1 in >> 5 z >> 6 >> >> Cheers, >> Simon > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From j.m.m.joosten at hccnet.nl Mon Jan 12 16:54:00 2009 From: j.m.m.joosten at hccnet.nl (Han Joosten) Date: Mon Jan 12 16:45:14 2009 Subject: Differences in pattern matching syntax? Message-ID: <21416338.post@talk.nabble.com> Hi, I have two alternatives to specify a specific function. They both compile ok, but the first one crashes (Stack space overflow) while the second one runs fine. I use GHC 6.10.1 on windowsXP Alternative 1: antecedent :: Rule -> Expression antecedent r = case r of Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module ADLdataDef:) illegal call to antecedent of rule "++show r) else rrant r Sg{} -> antecedent (srsig r) Gc{} -> Tm (grspe r) Fr{} -> frcmp r Alternative 2: antecedent :: Rule -> Expression antecedent r@(Ru AlwaysExpr _ _ _ _ _ _ _ _) = error ("(Module ADLdef:) illegal call to antecedent of rule "++show r) antecedent (Ru _ a _ _ _ _ _ _ _) = a antecedent (Sg _ rule _ _ _ _ _) = antecedent rule antecedent (Gc _ d _ _ _ _ _) = Tm d antecedent (Fr _ _ e _) = e Both alternatives compile, but if i use Alternative 2, then my program runs fine. If I use Alternative 1 instead, I get a stack space overflow. I would think that both alternatives would have the same semantics. So i am surprised that one runs fine, while the other one crashes. Could anyone explain what is going on? Thanks! Han Joosten ---------------------------- Might help, here is the data definition: data Rule = -- Ru c antc p cons cpu expla sgn nr pn Ru { rrsrt :: RuleType -- ^ One of the following: -- | Implication if this is an implication; -- | Equivalence if this is an equivalence; -- | AlwaysExpr if this is an ALWAYS expression. , rrant :: Expression -- ^ Antecedent , rrfps :: FilePos -- ^ Position in the ADL file , rrcon :: Expression -- ^ Consequent , r_cpu :: Expressions -- ^ This is a list of subexpressions, which must be computed. , rrxpl :: String -- ^ Explanation , rrtyp :: (Concept,Concept) -- ^ Sign of this rule , runum :: Int -- ^ Rule number , r_pat :: String -- ^ Name of pattern in which it was defined. } -- Sg p rule expla sgn nr pn signal | Sg { srfps :: FilePos -- ^ position in the ADL file , srsig :: Rule -- ^ the rule to be signalled , srxpl :: String -- ^ explanation , srtyp :: (Concept,Concept) -- ^ type , runum :: Int -- ^ rule number , r_pat :: String -- ^ name of pattern in which it was defined. , srrel :: Declaration -- ^ the signal relation } -- Gc p antc cons cpu _ _ _ | Gc { grfps :: FilePos -- ^ position in the ADL file , grspe :: Morphism -- ^ specific , grgen :: Expression -- ^ generic , r_cpu :: Expressions -- ^ This is a list of subexpressions, which must be computed. , grtyp :: (Concept,Concept) -- ^ declaration , runum :: Int -- ^ rule number , r_pat :: String -- ^ name of pattern in which it was defined. } -- Fr t d expr pn -- represents an automatic computation, such as * or +. | Fr { fraut :: AutType -- ^ the type of automatic computation , frdec :: Declaration -- ^ where the result is to be stored , frcmp :: Expression -- ^ expression to be computed , frpat :: String -- ^ name of pattern in which it was defined. } -- View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax--tp21416338p21416338.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonpj at microsoft.com Tue Jan 13 06:33:43 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jan 13 06:26:30 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <21416338.post@talk.nabble.com> References: <21416338.post@talk.nabble.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> I agree that's odd. Are you using -O? Can you give us a reproducible test case? (The only think I can think is that the line | Gc{} -> Tm (grspe r) will build a thunk for (grspe r), and depending on the context I suppose you might get a lot of those.) Thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Han Joosten | Sent: 12 January 2009 21:54 | To: glasgow-haskell-users@haskell.org | Subject: Differences in pattern matching syntax? | | | Hi, | | I have two alternatives to specify a specific function. They both compile | ok, but the first one crashes (Stack space overflow) while the second one | runs fine. | I use GHC 6.10.1 on windowsXP | | Alternative 1: | antecedent :: Rule -> Expression | antecedent r = case r of | Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module | ADLdataDef:) illegal call to antecedent of rule "++show r) | else | rrant r | Sg{} -> antecedent (srsig r) | Gc{} -> Tm (grspe r) | Fr{} -> frcmp r | | Alternative 2: | antecedent :: Rule -> Expression | antecedent r@(Ru AlwaysExpr _ _ _ _ _ _ _ _) = error ("(Module ADLdef:) | illegal call to antecedent of rule "++show r) | antecedent (Ru _ a _ _ _ _ _ _ _) = a | antecedent (Sg _ rule _ _ _ _ _) = antecedent rule | antecedent (Gc _ d _ _ _ _ _) = Tm d | antecedent (Fr _ _ e _) = e | | Both alternatives compile, but if i use Alternative 2, then my program runs | fine. If I use Alternative 1 instead, I get a stack space overflow. | | I would think that both alternatives would have the same semantics. So i am | surprised that one runs fine, while the other one crashes. | | Could anyone explain what is going on? | Thanks! | | Han Joosten | | ---------------------------- | Might help, here is the data definition: | | data Rule = | -- Ru c antc p cons cpu expla sgn nr pn | Ru { rrsrt :: RuleType -- ^ One of the following: | -- | Implication if this is an | implication; | -- | Equivalence if this is an | equivalence; | -- | AlwaysExpr if this is an | ALWAYS expression. | , rrant :: Expression -- ^ Antecedent | , rrfps :: FilePos -- ^ Position in the ADL file | , rrcon :: Expression -- ^ Consequent | , r_cpu :: Expressions -- ^ This is a list of | subexpressions, which must be computed. | , rrxpl :: String -- ^ Explanation | , rrtyp :: (Concept,Concept) -- ^ Sign of this rule | , runum :: Int -- ^ Rule number | , r_pat :: String -- ^ Name of pattern in which it was | defined. | } | -- Sg p rule expla sgn nr pn signal | | Sg { srfps :: FilePos -- ^ position in the ADL file | , srsig :: Rule -- ^ the rule to be signalled | , srxpl :: String -- ^ explanation | , srtyp :: (Concept,Concept) -- ^ type | , runum :: Int -- ^ rule number | , r_pat :: String -- ^ name of pattern in which it was | defined. | , srrel :: Declaration -- ^ the signal relation | } | -- Gc p antc cons cpu _ _ _ | | Gc { grfps :: FilePos -- ^ position in the ADL file | , grspe :: Morphism -- ^ specific | , grgen :: Expression -- ^ generic | , r_cpu :: Expressions -- ^ This is a list of | subexpressions, which must be computed. | , grtyp :: (Concept,Concept) -- ^ declaration | , runum :: Int -- ^ rule number | , r_pat :: String -- ^ name of pattern in which it was | defined. | } | -- Fr t d expr pn -- represents an automatic computation, such as * or +. | | Fr { fraut :: AutType -- ^ the type of automatic | computation | , frdec :: Declaration -- ^ where the result is to be | stored | , frcmp :: Expression -- ^ expression to be computed | , frpat :: String -- ^ name of pattern in which it was | defined. | } | | -- | View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax-- | tp21416338p21416338.html | Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Tue Jan 13 06:51:14 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jan 13 06:43:03 2009 Subject: [Haskell] type family vs. polymorphism In-Reply-To: <20090112214358.GH1529@cs.uu.nl> References: <20090112214358.GH1529@cs.uu.nl> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C332870D8DED@EA-EXMSG-C334.europe.corp.microsoft.com> [Redirecting to GHC users] Andres, Nice example. It's another instance of a problem that keeps coming up with type families. Details here: http://hackage.haskell.org/trac/ghc/ticket/1897#comment:10 The rest of the ticket gives other examples. It's not clear what the Right Thing to do is. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Andres | Loeh | Sent: 12 January 2009 21:44 | To: haskell@haskell.org | Subject: [Haskell] type family vs. polymorphism | | Hi. | | Here's a strange interaction of type families and higher-rank | polymorphism (tested with both ghc-6.8.3 and ghc-6.10.1): | | {-# LANGUAGE TypeFamilies, EmptyDataDecls, RankNTypes #-} | | data X (a :: *) | type family Y (a :: *) | | -- This works (datatype). | i1 :: (forall a. X a) -> X Bool | i1 x = x | | -- This works too (type family and extra arg). | i2 :: (forall a. a -> Y a) -> Y Bool | i2 x = x True | | -- This doesn't work (type family). | -- i3 :: (forall a. Y a) -> Y Bool | -- i3 x = x | | I would expect i3 to be ok as well. Note that this is a | simplified example and not really useful in its simplified | form. | | Cheers, | Andres | | -- | | Andres Loeh, Universiteit Utrecht | | mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de | http://www.andres-loeh.de | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From studt at fmi.uni-passau.de Tue Jan 13 10:15:51 2009 From: studt at fmi.uni-passau.de (Heiko Studt) Date: Tue Jan 13 10:07:10 2009 Subject: GHCi, version 6.10.1 crashes without message Message-ID: <20090113151549.5F831295BC0@charlie.moehre.org> Hi (and hello everybody), I read the FAQ, I searched down till Nov 2008, but did not find anything. I hope I didn't miss a FAQ or somewhat. (If so, please apologize!) My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core. I used the .msi of the Webpage some two weeks ago. I got some strange program as example and tried out - and my ghci died quitly without any helping message. Here is the original programm: | f x y z = a + b*c + b + fun c | where a = x * y + z | b = c * fun x | c = a * b | fun x = x * x + 1 For testing out in previous of this posting, the following is the very same and had the same problem: | let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c = a * b; fun x = x * x + 1} The query to die was "f 1 2 3". I tried with verbose ghci: | C:\...\ghc-6.10.1\bin>ghci -v | GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help | Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC | version 6.8.3 | Using package config file: C:\...\GHC-61~1.1\package.conf | hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 | wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 | wired-in package integer mapped to integer-0.1.0.0 | wired-in package base mapped to base-4.0.0.0 | wired-in package rts mapped to rts-1.0 | wired-in package haskell98 mapped to haskell98-1.0.1.0 | wired-in package syb mapped to syb-0.1.0.0 | wired-in package template-haskell mapped to template-haskell-2.3.0.0 | wired-in package dph-seq mapped to dph-seq-0.3 | wired-in package dph-par mapped to dph-par-0.3 | Hsc static flags: -static | Loading package ghc-prim ... linking ... done. | Loading package integer ... linking ... done. | Loading package base ... linking ... done. | Prelude> let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; | c = a * b; fun x = x * x + 1} | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | Prelude> f 1 2 3 | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | | C:\...\ghc-6.10.1\bin> I hope I could help finding some strange bug, killing 99% of your problems with Haskell, life and love, although I am very sure this one is only minor... ;-) MFG (With friendly regards) -- Heiko Studt From phercek at gmail.com Tue Jan 13 11:16:39 2009 From: phercek at gmail.com (Peter Hercek) Date: Tue Jan 13 11:08:10 2009 Subject: ghci debugger :trace command does not always extend trace history In-Reply-To: <496B2261.5050304@gmail.com> References: <49636656.9060000@gmail.com> <496B2261.5050304@gmail.com> Message-ID: Simon Marlow wrote: > I agree with most of what you say - there should be a way to get access > to the history after :trace has finished. Perhaps the right way is just > to have a single global trace history. > > Please submit a feature request, with a proposal for the user interface, > to the GHC bug tracker: > > http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Trace history should not be context/resume specific but global: http://hackage.haskell.org/trac/ghc/ticket/2945 Tracing should be controlled by a global flag (it should not be resume context specific): http://hackage.haskell.org/trac/ghc/ticket/2946 If anybody cares about ghci user interface then he/she should comment on the two tickets since they propose ghci UI changes. I doubt there would be complains about the first ticket but the second one may be more controversial. Thanks, Peter. From csmith32 at gmail.com Tue Jan 13 13:31:14 2009 From: csmith32 at gmail.com (Chris Smith) Date: Tue Jan 13 13:22:28 2009 Subject: GHCi, version 6.10.1 crashes without message In-Reply-To: <20090113151549.5F831295BC0@charlie.moehre.org> References: <20090113151549.5F831295BC0@charlie.moehre.org> Message-ID: I reproduced the error on my setup (GHC 6.10.1 on WS2003), and received SEH exception 0xC00000FD, which is STATUS_STACK_OVERFLOW "A new guard page for the stack cannot be created". It looks like something is overflowing the OS stack or improperly bumping the guard page at the end of the allocated stack (which is used to extend the stack on demand). I could not get the crash to occur in GHC 6.8.3 via GHCi on the same system. Instead, evaluation blocks forever with 0% CPU, interruptable with CTRL+C. On Tue, Jan 13, 2009 at 10:15 AM, Heiko Studt wrote: > Hi (and hello everybody), > > I read the FAQ, I searched down till Nov 2008, but did not find anything. > I hope I didn't miss a FAQ or somewhat. (If so, please apologize!) > > My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core. > I used the .msi of the Webpage some two weeks ago. > > I got some strange program as example and tried out - and my ghci died > quitly without any helping message. > > Here is the original programm: > | f x y z = a + b*c + b + fun c > | where a = x * y + z > | b = c * fun x > | c = a * b > | fun x = x * x + 1 > > For testing out in previous of this posting, the following is the very > same and had the same problem: > | let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c > = a * b; fun x = x * x + 1} > > The query to die was "f 1 2 3". > > I tried with verbose ghci: > > | C:\...\ghc-6.10.1\bin>ghci -v > | GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > | Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted > by GHC > | version 6.8.3 > | Using package config file: C:\...\GHC-61~1.1\package.conf > | hiding package base-3.0.3.0 to avoid conflict with later version > base-4.0.0.0 > | wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 > | wired-in package integer mapped to integer-0.1.0.0 > | wired-in package base mapped to base-4.0.0.0 > | wired-in package rts mapped to rts-1.0 > | wired-in package haskell98 mapped to haskell98-1.0.1.0 > | wired-in package syb mapped to syb-0.1.0.0 > | wired-in package template-haskell mapped to template-haskell-2.3.0.0 > | wired-in package dph-seq mapped to dph-seq-0.3 > | wired-in package dph-par mapped to dph-par-0.3 > | Hsc static flags: -static > | Loading package ghc-prim ... linking ... done. > | Loading package integer ... linking ... done. > | Loading package base ... linking ... done. > | Prelude> let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * > fun x; > | c = a * b; fun x = x * x + 1} > | *** Parser: > | *** Desugar: > | *** Simplify: > | *** CorePrep: > | *** ByteCodeGen: > | Prelude> f 1 2 3 > | *** Parser: > | *** Desugar: > | *** Simplify: > | *** CorePrep: > | *** ByteCodeGen: > | > | C:\...\ghc-6.10.1\bin> > > I hope I could help finding some strange bug, killing 99% of your > problems with Haskell, life and love, although I am very sure > this one is only minor... ;-) > > > MFG (With friendly regards) > > -- > Heiko Studt > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090113/ae7262b3/attachment.htm From roma at ro-che.info Tue Jan 13 15:17:24 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue Jan 13 15:08:54 2009 Subject: GHCi, version 6.10.1 crashes without message In-Reply-To: <20090113151549.5F831295BC0@charlie.moehre.org> References: <20090113151549.5F831295BC0@charlie.moehre.org> Message-ID: <20090113201724.GA23592@flit> * Heiko Studt [2009-01-13 16:15:51+0100] > Hi (and hello everybody), > > I read the FAQ, I searched down till Nov 2008, but did not find anything. > I hope I didn't miss a FAQ or somewhat. (If so, please apologize!) > > My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core. > I used the .msi of the Webpage some two weeks ago. > > I got some strange program as example and tried out - and my ghci died > quitly without any helping message. > > Here is the original programm: > | f x y z = a + b*c + b + fun c > | where a = x * y + z > | b = c * fun x > | c = a * b > | fun x = x * x + 1 > > For testing out in previous of this posting, the following is the very > same and had the same problem: > | let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c = a * b; fun x = x * x + 1} > > The query to die was "f 1 2 3". [...] Your program loops for the following reason: to compute f, you need to compute c to compute c, you need to compute b to compute b, you need to compute c again! Haskell cannot solve equations (or, at least, not formulated in this way), so it understands definition of f as the rules to compute things like a, b, c. No wonder evaluation of f never terminates. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From karel.gardas at centrum.cz Tue Jan 13 15:24:08 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue Jan 13 15:15:24 2009 Subject: LambdaVM: build fails on Solaris/x86 Message-ID: <496CF868.4090005@centrum.cz> Hello Brian and All, I'm curious if anyone here attempted building LambdaVM on non-GNU system. I'm using OpenSolaris/x86 and build fails with: == Recursively making `depend' for ways: '' ... PWD = /export/home/karel/vcs/lambdavm/libraries/Cabal ------------------------------------------------------------------------ case '- --no-print-directory -r' in *-[ik]*) x_on_err=0;; *-r*[ik]*) x_on_err=0;; *) x_on_err=1;; esac; \ if [ -n "" ]; then \ echo "doing the loop :-("; \ for i in ; do \ echo "------------------------------------------------------------------------"; \ echo "== gmake way=$i depend;"; \ echo "PWD = /export/home/karel/vcs/lambdavm/libraries/Cabal"; \ echo "------------------------------------------------------------------------"; \ gmake way=$i --no-print-directory - --no-print-directory -r depend ; \ if [ $? -eq 0 ] ; then true; else exit $x_on_err; fi; \ done \ fi /bin/sh: syntax error at line 4: `;' unexpected gmake[2]: *** [depend] Error 2 Failed making boot in Cabal: 1 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/export/home/karel/vcs/lambdavm/libraries' gmake: *** [stage1] Error 2 karel@silence:~/vcs/lambdavm$ The only changes which I made to the build systems are following: karel@silence:~/vcs/lambdavm$ darcs w -u { hunk ./darcs-all 1 -#!/bin/sh +#!/usr/bin/bash set -e hunk ./libraries/Makefile 12 # want the Makefile. MFLAGS += -f Makefile -SUBDIRS = base haskell98 template-haskell readline parsec Cabal +#SUBDIRS = base haskell98 template-haskell readline parsec Cabal +SUBDIRS = base haskell98 template-haskell parsec Cabal ifeq "$(GhcLibsWithUnix)" "YES" SUBDIRS += unix hunk ./mk/target.mk 274 ifneq "$(way)" "i" ifeq "$(way)" "j" define BUILD_LIB -@if [ -e $@ ]; then \ +@if [ -f $@ ]; then \ echo "$(JAR) uf $@ ..."; \ for o in $(LIBOBJS:%.$(osuf)=%); do [ $$o.$(osuf) -nt $@ ] && echo $$o*.$(osuf); done | xargs $(JAR) uf $@; \ else \ hunk ./mk/target.mk 1102 # since these are way-independent all docs TAGS clean distclean mostlyclean maintainer-clean install depend :: @echo "------------------------------------------------------------------------" - @echo "== Recursively making \`$@' for ways: $(WAYS) ..." + @echo "== Recursively making \`$@' for ways: '$(WAYS)' ..." @echo "PWD = $(shell pwd)" @echo "------------------------------------------------------------------------" # Don't rely on -e working, instead we check exit return codes from sub-makes. } the reason is: 1) readline lib is not buildable on my solaris. The issue was already solved in 6.8.x branch IIRC somehow (replacing readline with different lib IIRC) 2) if [ -e $@ ], i.e. `-e' is not supported by Solaris' /bin/sh, -f works fine. My main motivation behind attempting to build it, is to give Haskell a try inside Eclipse IDE. i.e. Eclipse supports kind of Model Driven Architecture and I would like to use Haskell for models processing and transformations. Thanks! Karel From studt at fmi.uni-passau.de Tue Jan 13 15:52:21 2009 From: studt at fmi.uni-passau.de (Heiko Studt) Date: Tue Jan 13 15:43:36 2009 Subject: GHCi, version 6.10.1 crashes without message In-Reply-To: <20090113201724.GA23592@flit> References: <20090113151549.5F831295BC0@charlie.moehre.org> <20090113201724.GA23592@flit> Message-ID: <20090113205220.0830C295BBD@charlie.moehre.org> PPS: Why does your mailinglist not set the Reply-To header? @Roman Cheplyaka: Sorry for double mailing. Am 13.01.2009 schrieb Roman Cheplyaka: > > | f x y z = a + b*c + b + fun c > > | where a = x * y + z > > | b = c * fun x > > | c = a * b > > | fun x = x * x + 1 > > > > The query to die was "f 1 2 3". > Your program loops for the following reason: > to compute f, you need to compute c > to compute c, you need to compute b > to compute b, you need to compute c again! > Haskell cannot solve equations (or, at least, not formulated in this > way), so it understands definition of f as the rules to compute things > like a, b, c. No wonder evaluation of f never terminates. The problem is not it does not terminate. It terminates. GHCi terminates inclusivly (maybe by simpathy? ;-)). As Chris Smith wrote it faults the stack. I tried to get the thing some smaller and therefor to the point, I should have done this before I assume: | let f = c where {c = c} at "f", | let f = f in f kills GHCi immidiatelly. | let f 0 = f 0 in f 0 simply does not terminate (as it should be). MFG (With friendly regards) Heiko Studt PS: Funny way for quitting with two keystroke. ;-) -- Heiko Studt From karel.gardas at centrum.cz Tue Jan 13 15:59:40 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue Jan 13 15:50:53 2009 Subject: LambdaVM: build fails on Solaris/x86 In-Reply-To: <496CF868.4090005@centrum.cz> References: <496CF868.4090005@centrum.cz> Message-ID: <496D00BC.3040402@centrum.cz> Hello, short followup, when I also removed Cabal from libraries/Makefile SUBDIRS, then the build has gone well and I'm able to compile and run simple Haskell testing programs. Great work, indeed! I'm looking forward to seeing LambdaVM merged to the standard GHC. Thanks! Karel Karel Gardas wrote: > Hello Brian and All, > > I'm curious if anyone here attempted building LambdaVM on non-GNU > system. I'm using OpenSolaris/x86 and build fails with: > > == Recursively making `depend' for ways: '' ... > PWD = /export/home/karel/vcs/lambdavm/libraries/Cabal > ------------------------------------------------------------------------ > case '- --no-print-directory -r' in *-[ik]*) x_on_err=0;; *-r*[ik]*) > x_on_err=0;; *) x_on_err=1;; esac; \ > if [ -n "" ]; then \ > echo "doing the loop :-("; \ > for i in ; do \ > echo > "------------------------------------------------------------------------"; > \ > echo "== gmake way=$i depend;"; \ > echo "PWD = /export/home/karel/vcs/lambdavm/libraries/Cabal"; \ > echo > "------------------------------------------------------------------------"; > \ > gmake way=$i --no-print-directory - --no-print-directory -r > depend ; \ > if [ $? -eq 0 ] ; then true; else exit $x_on_err; fi; \ > done \ > fi > /bin/sh: syntax error at line 4: `;' unexpected > gmake[2]: *** [depend] Error 2 > Failed making boot in Cabal: 1 > gmake[1]: *** [boot] Error 1 > gmake[1]: Leaving directory `/export/home/karel/vcs/lambdavm/libraries' > gmake: *** [stage1] Error 2 > karel@silence:~/vcs/lambdavm$ > > > The only changes which I made to the build systems are following: > > karel@silence:~/vcs/lambdavm$ darcs w -u > { > hunk ./darcs-all 1 > -#!/bin/sh > +#!/usr/bin/bash > > set -e > > hunk ./libraries/Makefile 12 > # want the Makefile. > MFLAGS += -f Makefile > > -SUBDIRS = base haskell98 template-haskell readline parsec Cabal > +#SUBDIRS = base haskell98 template-haskell readline parsec Cabal > +SUBDIRS = base haskell98 template-haskell parsec Cabal > > ifeq "$(GhcLibsWithUnix)" "YES" > SUBDIRS += unix > hunk ./mk/target.mk 274 > ifneq "$(way)" "i" > ifeq "$(way)" "j" > define BUILD_LIB > -@if [ -e $@ ]; then \ > +@if [ -f $@ ]; then \ > echo "$(JAR) uf $@ ..."; \ > for o in $(LIBOBJS:%.$(osuf)=%); do [ $$o.$(osuf) -nt $@ ] && echo > $$o*.$(osuf); done | xargs $(JAR) uf $@; \ > else \ > hunk ./mk/target.mk 1102 > # since these are way-independent > all docs TAGS clean distclean mostlyclean maintainer-clean install > depend :: > @echo > "------------------------------------------------------------------------" > - @echo "== Recursively making \`$@' for ways: $(WAYS) ..." > + @echo "== Recursively making \`$@' for ways: '$(WAYS)' ..." > @echo "PWD = $(shell pwd)" > @echo > "------------------------------------------------------------------------" > # Don't rely on -e working, instead we check exit return codes from > sub-makes. > } > > > the reason is: > > 1) readline lib is not buildable on my solaris. The issue was already > solved in 6.8.x branch IIRC somehow (replacing readline with different > lib IIRC) > > 2) if [ -e $@ ], i.e. `-e' is not supported by Solaris' /bin/sh, -f > works fine. > > > My main motivation behind attempting to build it, is to give Haskell a > try inside Eclipse IDE. i.e. Eclipse supports kind of Model Driven > Architecture and I would like to use Haskell for models processing and > transformations. > > Thanks! > Karel > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From han.joosten at atosorigin.com Wed Jan 14 05:31:18 2009 From: han.joosten at atosorigin.com (Han Joosten) Date: Wed Jan 14 05:22:28 2009 Subject: Differences in pattern matching syntax? Message-ID: <21439653.post@talk.nabble.com> Hi, I do not use -O to compile, as far as I know. I use eclipsefp and I use the defaults from it. I will upload my modules as a zip file, so you can reproduce the error. It also contains a README.txt file that explains how to reproduce it. Hope that helps. http://www.nabble.com/file/p21439653/src.zip src.zip Simon Peyton-Jones wrote: > > I agree that's odd. Are you using -O? Can you give us a reproducible > test case? > > (The only think I can think is that the line > | Gc{} -> Tm (grspe r) > will build a thunk for (grspe r), and depending on the context I suppose > you might get a lot of those.) > > Thanks > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Han Joosten > | Sent: 12 January 2009 21:54 > | To: glasgow-haskell-users@haskell.org > | Subject: Differences in pattern matching syntax? > | > | > | Hi, > | > | I have two alternatives to specify a specific function. They both > compile > | ok, but the first one crashes (Stack space overflow) while the second > one > | runs fine. > | I use GHC 6.10.1 on windowsXP > | > | Alternative 1: > | antecedent :: Rule -> Expression > | antecedent r = case r of > | Ru{} -> if (rrsrt r == AlwaysExpr) then error > ("(Module > | ADLdataDef:) illegal call to antecedent of rule "++show r) > | else > | rrant r > | Sg{} -> antecedent (srsig r) > | Gc{} -> Tm (grspe r) > | Fr{} -> frcmp r > | > | Alternative 2: > | antecedent :: Rule -> Expression > | antecedent r@(Ru AlwaysExpr _ _ _ _ _ _ _ _) = error ("(Module > ADLdef:) > | illegal call to antecedent of rule "++show r) > | antecedent (Ru _ a _ _ _ _ _ _ _) = a > | antecedent (Sg _ rule _ _ _ _ _) = antecedent rule > | antecedent (Gc _ d _ _ _ _ _) = Tm d > | antecedent (Fr _ _ e _) = e > | > | Both alternatives compile, but if i use Alternative 2, then my program > runs > | fine. If I use Alternative 1 instead, I get a stack space overflow. > | > | I would think that both alternatives would have the same semantics. So i > am > | surprised that one runs fine, while the other one crashes. > | > | Could anyone explain what is going on? > | Thanks! > | > | Han Joosten > | > | ---------------------------- > | Might help, here is the data definition: > | > | data Rule = > | -- Ru c antc p cons cpu expla sgn nr pn > | Ru { rrsrt :: RuleType -- ^ One of the following: > | -- | Implication if this is > an > | implication; > | -- | Equivalence if this is > an > | equivalence; > | -- | AlwaysExpr if this is > an > | ALWAYS expression. > | , rrant :: Expression -- ^ Antecedent > | , rrfps :: FilePos -- ^ Position in the ADL file > | , rrcon :: Expression -- ^ Consequent > | , r_cpu :: Expressions -- ^ This is a list of > | subexpressions, which must be computed. > | , rrxpl :: String -- ^ Explanation > | , rrtyp :: (Concept,Concept) -- ^ Sign of this rule > | , runum :: Int -- ^ Rule number > | , r_pat :: String -- ^ Name of pattern in which it > was > | defined. > | } > | -- Sg p rule expla sgn nr pn signal > | | Sg { srfps :: FilePos -- ^ position in the ADL file > | , srsig :: Rule -- ^ the rule to be signalled > | , srxpl :: String -- ^ explanation > | , srtyp :: (Concept,Concept) -- ^ type > | , runum :: Int -- ^ rule number > | , r_pat :: String -- ^ name of pattern in which it > was > | defined. > | , srrel :: Declaration -- ^ the signal relation > | } > | -- Gc p antc cons cpu _ _ _ > | | Gc { grfps :: FilePos -- ^ position in the ADL file > | , grspe :: Morphism -- ^ specific > | , grgen :: Expression -- ^ generic > | , r_cpu :: Expressions -- ^ This is a list of > | subexpressions, which must be computed. > | , grtyp :: (Concept,Concept) -- ^ declaration > | , runum :: Int -- ^ rule number > | , r_pat :: String -- ^ name of pattern in which it > was > | defined. > | } > | -- Fr t d expr pn -- represents an automatic computation, such as * > or +. > | | Fr { fraut :: AutType -- ^ the type of automatic > | computation > | , frdec :: Declaration -- ^ where the result is to be > | stored > | , frcmp :: Expression -- ^ expression to be computed > | , frpat :: String -- ^ name of pattern in which it > was > | defined. > | } > | > | -- > | View this message in context: > http://www.nabble.com/Differences-in-pattern-matching-syntax-- > | tp21416338p21416338.html > | Sent from the Haskell - Glasgow-haskell-users mailing list archive at > Nabble.com. > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax--tp21416338p21439653.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From marlowsd at gmail.com Wed Jan 14 07:14:18 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 07:05:43 2009 Subject: HEADS UP: finalizer changes coming in GHC 6.10.2 Message-ID: <496DD71A.9060802@gmail.com> By popular demand, GHC 6.10.2 will support finalizers that are actually guaranteed to run, and run promptly. There aren't any API changes: this happens for finalizers created using newForeignPtr as normal. However, there's a catch. Previously it was possible to call back into Haskell from a finalizer (finalizers are C functions), by using foreign import "wrapper" or foreign export. According to the FFI spec, whether this is allowed or not is "system dependent". In GHC 6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not. The reason being that C finalizers are now executed directly by the GC, when the runtime is not in a position to handle callbacks. You can still have fully-fledged Haskell finalizers if you want: we have Foreign.Concurrent.newForeignPtr for that purpose. But those finalizers are not subject to the same promptness guarantees that you get with C finalizers - they run in a separate thread, and are not guaranteed to be run at program exit. We'll make sure this is documented prominently in the 6.10.2 release notes, but I thought a heads-up would be a good idea right now as it turns out that there are existing libraries (e.g. LLVM) that will be affected. Cheers, Simon From marlowsd at gmail.com Wed Jan 14 08:04:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 07:55:32 2009 Subject: GHCi, version 6.10.1 crashes without message In-Reply-To: <20090113205220.0830C295BBD@charlie.moehre.org> References: <20090113151549.5F831295BC0@charlie.moehre.org> <20090113201724.GA23592@flit> <20090113205220.0830C295BBD@charlie.moehre.org> Message-ID: <496DE2D1.80406@gmail.com> Heiko Studt wrote: > PPS: Why does your mailinglist not set the Reply-To header? > @Roman Cheplyaka: Sorry for double mailing. > > Am 13.01.2009 schrieb Roman Cheplyaka: > >>> | f x y z = a + b*c + b + fun c >>> | where a = x * y + z >>> | b = c * fun x >>> | c = a * b >>> | fun x = x * x + 1 >>> >>> The query to die was "f 1 2 3". > >> Your program loops for the following reason: >> to compute f, you need to compute c >> to compute c, you need to compute b >> to compute b, you need to compute c again! > >> Haskell cannot solve equations (or, at least, not formulated in this >> way), so it understands definition of f as the rules to compute things >> like a, b, c. No wonder evaluation of f never terminates. > > The problem is not it does not terminate. It terminates. GHCi terminates > inclusivly (maybe by simpathy? ;-)). As Chris Smith wrote it faults the > stack. > > I tried to get the thing some smaller and therefor to the point, > I should have done this before I assume: > > | let f = c where {c = c} > > at "f", > > | let f = f in f > > kills GHCi immidiatelly. > > | let f 0 = f 0 in f 0 > > simply does not terminate (as it should be). See http://hackage.haskell.org/trac/ghc/ticket/2783 and http://hackage.haskell.org/trac/ghc/ticket/2786 Cheers, Simon From johan.tibell at gmail.com Wed Jan 14 10:09:10 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Jan 14 10:00:26 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 In-Reply-To: <496DD71A.9060802@gmail.com> References: <496DD71A.9060802@gmail.com> Message-ID: <90889fe70901140709q4c412708oed729c2df0b0fd05@mail.gmail.com> On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote: > By popular demand, GHC 6.10.2 will support finalizers that are actually > guaranteed to run, and run promptly. There aren't any API changes: this > happens for finalizers created using newForeignPtr as normal. Does this effect GC performance even if you don't use finalizers? My knowledge of how finalizers affect GC performance is limited but now and then I stumble on some Java article (e.g. [1]) that claims that they can slow things down. That's no problem if there's no additional cost added to code which doesn't use finalizers. 1. http://java2go.blogspot.com/2007/09/javaone-2007-performance-tips-2-finish.html Cheers, Johan From marlowsd at gmail.com Wed Jan 14 10:35:33 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 10:26:48 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 In-Reply-To: <90889fe70901140709q4c412708oed729c2df0b0fd05@mail.gmail.com> References: <496DD71A.9060802@gmail.com> <90889fe70901140709q4c412708oed729c2df0b0fd05@mail.gmail.com> Message-ID: <496E0645.6070102@gmail.com> Johan Tibell wrote: > On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote: >> By popular demand, GHC 6.10.2 will support finalizers that are actually >> guaranteed to run, and run promptly. There aren't any API changes: this >> happens for finalizers created using newForeignPtr as normal. > > Does this effect GC performance even if you don't use finalizers? > > My knowledge of how finalizers affect GC performance is limited but > now and then I stumble on some Java article (e.g. [1]) that claims > that they can slow things down. That's no problem if there's no > additional cost added to code which doesn't use finalizers. Yes, having lots of finalizers could affect GC performance, but that hasn't changed. There are things we could do to speed it up, if it became a serious bottleneck - for example, we currently look at all the weak pointers on every GC, but we could separate them by generation like we do for threads. Cheers, Simon From marlowsd at gmail.com Wed Jan 14 10:36:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 10:27:40 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 In-Reply-To: <496E0419.3000504@gmail.com> References: <496DD71A.9060802@gmail.com> <496E0419.3000504@gmail.com> Message-ID: <496E0673.30303@gmail.com> Sigbjorn Finne wrote: > Thanks Simon, > > great stuff; I like the introduction of these 'native code finalizers', > they've > been sorely missed at times. > > You don't say, but will there be a dynamic check to catch such re-entries? There is (now) a dynamic check, yes. Cheers, Simon From phercek at gmail.com Thu Jan 15 10:44:49 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Jan 15 10:36:08 2009 Subject: how to load an additional file to ghci Message-ID: Is it possible to load one more module to ghci without unloading the modules I have already loaded? The module I would like to load in addtion is not installed and I do not want it installed. It is also independent of any other modules. There is no dependency from the modules already loaded to the one I would like to add. How to achieve something like "load a module in this file in addition to what I have already loaded and do not modify the the context for expression evaluation (:module) ... just make the exported functions in the file available through fully qualified names". It would be handy for some helper stuff I have which is project independent and too often modified to be installed. Peter. From simonpj at microsoft.com Thu Jan 15 12:00:10 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 15 11:51:18 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <21439653.post@talk.nabble.com> References: <21439653.post@talk.nabble.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> That's a big set of modules, and I don't have eclipsefp. It'd be much easier with a smaller test case. But there may be no bug here. Compiling with -O certainly can give different space behaviour. And as I mentioned, there's one place where it really will generate different code. Try this a) Compile antecedent with -O. Does that make the two behave the same? b) In Alterantive 1 change Gc{} -> Tm (grspe r) to Gc{} -> let x = grspe r in r `seq` Tm r Does that change anything? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Han Joosten | Sent: 14 January 2009 10:31 | To: glasgow-haskell-users@haskell.org | Subject: RE: Differences in pattern matching syntax? | | | Hi, | | I do not use -O to compile, as far as I know. I use eclipsefp and I use the | defaults from it. | I will upload my modules as a zip file, so you can reproduce the error. It | also contains a README.txt file that explains how to reproduce it. | Hope that helps. | http://www.nabble.com/file/p21439653/src.zip src.zip | | | Simon Peyton-Jones wrote: | > | > I agree that's odd. Are you using -O? Can you give us a reproducible | > test case? | > | > (The only think I can think is that the line | > | Gc{} -> Tm (grspe r) | > will build a thunk for (grspe r), and depending on the context I suppose | > you might get a lot of those.) | > | > Thanks | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org | > [mailto:glasgow-haskell-users- | > | bounces@haskell.org] On Behalf Of Han Joosten | > | Sent: 12 January 2009 21:54 | > | To: glasgow-haskell-users@haskell.org | > | Subject: Differences in pattern matching syntax? | > | | > | | > | Hi, | > | | > | I have two alternatives to specify a specific function. They both | > compile | > | ok, but the first one crashes (Stack space overflow) while the second | > one | > | runs fine. | > | I use GHC 6.10.1 on windowsXP | > | | > | Alternative 1: | > | antecedent :: Rule -> Expression | > | antecedent r = case r of | > | Ru{} -> if (rrsrt r == AlwaysExpr) then error | > ("(Module | > | ADLdataDef:) illegal call to antecedent of rule "++show r) | > | else | > | rrant r | > | Sg{} -> antecedent (srsig r) | > | Gc{} -> Tm (grspe r) | > | Fr{} -> frcmp r | > | | > | Alternative 2: | > | antecedent :: Rule -> Expression | > | antecedent r@(Ru AlwaysExpr _ _ _ _ _ _ _ _) = error ("(Module | > ADLdef:) | > | illegal call to antecedent of rule "++show r) | > | antecedent (Ru _ a _ _ _ _ _ _ _) = a | > | antecedent (Sg _ rule _ _ _ _ _) = antecedent rule | > | antecedent (Gc _ d _ _ _ _ _) = Tm d | > | antecedent (Fr _ _ e _) = e | > | | > | Both alternatives compile, but if i use Alternative 2, then my program | > runs | > | fine. If I use Alternative 1 instead, I get a stack space overflow. | > | | > | I would think that both alternatives would have the same semantics. So i | > am | > | surprised that one runs fine, while the other one crashes. | > | | > | Could anyone explain what is going on? | > | Thanks! | > | | > | Han Joosten | > | | > | ---------------------------- | > | Might help, here is the data definition: | > | | > | data Rule = | > | -- Ru c antc p cons cpu expla sgn nr pn | > | Ru { rrsrt :: RuleType -- ^ One of the following: | > | -- | Implication if this is | > an | > | implication; | > | -- | Equivalence if this is | > an | > | equivalence; | > | -- | AlwaysExpr if this is | > an | > | ALWAYS expression. | > | , rrant :: Expression -- ^ Antecedent | > | , rrfps :: FilePos -- ^ Position in the ADL file | > | , rrcon :: Expression -- ^ Consequent | > | , r_cpu :: Expressions -- ^ This is a list of | > | subexpressions, which must be computed. | > | , rrxpl :: String -- ^ Explanation | > | , rrtyp :: (Concept,Concept) -- ^ Sign of this rule | > | , runum :: Int -- ^ Rule number | > | , r_pat :: String -- ^ Name of pattern in which it | > was | > | defined. | > | } | > | -- Sg p rule expla sgn nr pn signal | > | | Sg { srfps :: FilePos -- ^ position in the ADL file | > | , srsig :: Rule -- ^ the rule to be signalled | > | , srxpl :: String -- ^ explanation | > | , srtyp :: (Concept,Concept) -- ^ type | > | , runum :: Int -- ^ rule number | > | , r_pat :: String -- ^ name of pattern in which it | > was | > | defined. | > | , srrel :: Declaration -- ^ the signal relation | > | } | > | -- Gc p antc cons cpu _ _ _ | > | | Gc { grfps :: FilePos -- ^ position in the ADL file | > | , grspe :: Morphism -- ^ specific | > | , grgen :: Expression -- ^ generic | > | , r_cpu :: Expressions -- ^ This is a list of | > | subexpressions, which must be computed. | > | , grtyp :: (Concept,Concept) -- ^ declaration | > | , runum :: Int -- ^ rule number | > | , r_pat :: String -- ^ name of pattern in which it | > was | > | defined. | > | } | > | -- Fr t d expr pn -- represents an automatic computation, such as * | > or +. | > | | Fr { fraut :: AutType -- ^ the type of automatic | > | computation | > | , frdec :: Declaration -- ^ where the result is to be | > | stored | > | , frcmp :: Expression -- ^ expression to be computed | > | , frpat :: String -- ^ name of pattern in which it | > was | > | defined. | > | } | > | | > | -- | > | View this message in context: | > http://www.nabble.com/Differences-in-pattern-matching-syntax-- | > | tp21416338p21416338.html | > | Sent from the Haskell - Glasgow-haskell-users mailing list archive at | > Nabble.com. | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users@haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | | -- | View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax-- | tp21416338p21439653.html | Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From han.joosten at atosorigin.com Thu Jan 15 16:57:12 2009 From: han.joosten at atosorigin.com (Han Joosten) Date: Thu Jan 15 16:48:23 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <21487742.post@talk.nabble.com> I wrote a little wrapper around ghc to see how what parameters were used: ghc --make -odir "C:\prive\eclipseworkspace\ADL trunk\out" -hidir "C:\prive\eclipseworkspace\ADL trunk\out" -o "C:\prive\eclipseworkspace\ADL trunk\bin\ADL" -dcore-lint Main.hs So this is only some paths and -dcore-lint. I remember trying that after I had ran into the bug. I used your hints and this is what happend. I did not use eclipsefp, but compiled directly from the command line. Also, inbetwean builds I deleted all intermediate files, just to make sure that everything was built with the same options. a1) First I compiled everything (with the original alternative 1) again with ghc --make -odir "C:\prive\eclipseworkspace\ADL trunk\out" -hidir "C:\prive\eclipseworkspace\ADL trunk\out" -o "C:\prive\eclipseworkspace\ADL trunk\bin\ADL" -dcore-lint -O Main.hs Then I ran the executable. It didn't mention a stack overflow, but it said: ADL.exe: <> after which it stoped. a2) Now I put the original alternative 2 in place, and compiled everything from scratch : ghc --make -odir "C:\prive\eclipseworkspace\ADL trunk\out" -hidir "C:\prive\eclipseworkspace\ADL trunk\out" -o "C:\prive\eclipseworkspace\ADL trunk\bin\ADL" -dcore-lint -O Main.hs Again I ran the executable, but it terminated as before, doing what I expected it to do. No stack overflow, no loop whatsoever. b) Now I tried the modified alternative 1: antecedent :: Rule -> Expression antecedent r = case r of Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module ADLdataDef:) illegal call to antecedent of rule "++show r) else rrant r Sg{} -> antecedent (srsig r) Gc{} -> let x = grspe r in r `seq` Tm r Fr{} -> frcmp r Compiled again with: ghc --make -odir "C:\prive\eclipseworkspace\ADL trunk\out" -hidir "C:\prive\eclipseworkspace\ADL trunk\out" -o "C:\prive\eclipseworkspace\ADL trunk\bin\ADL" -dcore-lint -O Main.hs it said: ADLdataDef.hs:41:57: Couldn't match expected type `Morphism' against inferred type `Rule' In the first argument of `Tm', namely `r' In the second argument of `seq', namely `Tm r' In the expression: r `seq` Tm r I hardly use any let expressions (shame on me??) and I am not very familiar with them. But I figured out you might have mistaken, so I changed the bit to: antecedent :: Rule -> Expression antecedent r = case r of Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module ADLdataDef:) illegal call to antecedent of rule "++show r) else rrant r Sg{} -> antecedent (srsig r) Gc{} -> let x = grspe r in r `seq` Tm x Fr{} -> frcmp r Compiled again with: ghc --make -odir "C:\prive\eclipseworkspace\ADL trunk\out" -hidir "C:\prive\eclipseworkspace\ADL trunk\out" -o "C:\prive\eclipseworkspace\ADL trunk\bin\ADL" -dcore-lint -O Main.hs Again, it sais ADL.exe: <> My conclusion is until now that I have here two variants of a piece of code that should be semantically equivalent. In the same context (the rest of the program hasn't changed) however, they behave different. Hence I suspect a bug in ghc... 8-(( Since my first posting of this thread, I have been searching around, and I have learnt that there are some pragma's that could be used. Are there any of them that I should have used when using this kind of pattern matching? I might have omitted them. Han Joosten. -- View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax--tp21416338p21487742.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From phercek at gmail.com Thu Jan 15 17:29:42 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Jan 15 17:20:58 2009 Subject: how can I run ghci monad actions from ghci command line Message-ID: Is it possible to run ghci monad actions from ghci command line somehow? For example: I would like to check whether "it" variable is of type Bool and whether it is True using normal Haskell code (i.e. not using ghci commands starting with colon like :type :print). Peter. From daniel.is.fischer at web.de Thu Jan 15 19:24:17 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Jan 15 19:12:43 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <21487742.post@talk.nabble.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> Message-ID: <200901160124.17473.daniel.is.fischer@web.de> Am Donnerstag, 15. Januar 2009 22:57 schrieb Han Joosten: > > I hardly use any let expressions (shame on me??) and I am not very familiar > with them. But I figured out you might have mistaken, so I changed the bit > to: > antecedent :: Rule -> Expression > antecedent r = case r of > Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module > ADLdataDef:) illegal call to antecedent of rule "++show r) > else > rrant r > Sg{} -> antecedent (srsig r) > Gc{} -> let x = grspe r in r `seq` Tm x > Fr{} -> frcmp r > Perhaps you should have replaced both occurrences of 'r' with 'x': Gc{} -> let x = grspe r in x `seq` Tm x (That may or may not make a difference, depends on what your code actually does). Should be worth a try anyway. Also, try compiling with -O2 to see if that makes a difference. From claus.reinke at talk21.com Thu Jan 15 19:29:08 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jan 15 19:20:19 2009 Subject: Differences in pattern matching syntax? References: <21416338.post@talk.nabble.com><638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com><21439653.post@talk.nabble.com><638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> Message-ID: > antecedent :: Rule -> Expression > antecedent r = case r of > .. > Gc{} -> let x = grspe r in r `seq` Tm r >.. This looks wrong. The idea was to replace Tm (grspe r) (where the selection expression is put into Tm unevaluated) with let x = grspe r in x `seq` Tm x ie, bind the selected expression to 'x', then force 'x' to be evaluated before putting it in 'Tm x'. Alternatively, Tm $! (grspe r) should do the same forcing. However, either variant will force evaluation of the selected field as well, not just evaluation of the selection. Consider this small example: data T x = T {field :: x} f (T x) = Just x g tx = Just (field tx) h tx = Just $! (field tx) The three functions 'f', 'g', and 'h' are different, as can be seen (in part) by evaluating *Main> Data.Maybe.isJust $ f (T undefined) True *Main> Data.Maybe.isJust $ g (T undefined) True *Main> Data.Maybe.isJust $ h (T undefined) *** Exception: Prelude.undefined f: passes the 'field' 'x' unchanged g: passes the whole record, wrapped in a selection h: passes the 'field', after evaluating it The extra wrapping in 'g' corresponds to where Simon suspects your difference in memory behaviour comes from (by the time the wrappers get evaluated, there are too many of them to fit on the stack). Neither 'g' nor 'h' are equivalent to 'f', but the equivalent of 'h' (forcing the record selection before putting it in another constructor) might fit your needs better than the equivalent of 'g'. hth, Claus > antecedent :: Rule -> Expression > antecedent r = case r of >.. > Gc{} -> let x = grspe r in r `seq` Tm x >.. This is forcing 'r', not the selection 'x' from 'r'. From simonpj at microsoft.com Fri Jan 16 04:04:17 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 16 03:55:24 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <21487742.post@talk.nabble.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> | I hardly use any let expressions (shame on me??) and I am not very familiar | with them. But I figured out you might have mistaken, so I changed the bit | to: | antecedent :: Rule -> Expression | antecedent r = case r of | Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module | ADLdataDef:) illegal call to antecedent of rule "++show r) | else | rrant r | Sg{} -> antecedent (srsig r) | Gc{} -> let x = grspe r in r `seq` Tm x | Fr{} -> frcmp r Indeed I was wrong, as others saw too. But in any case, I now realise that adding the `seq` makes the function stricter than Alternative 2, which your application presumably doesn't like. (Hence <>, I assume.) Try this instead, which should make it more like Alternative 2: Gc{} -> case r of { GC{ grspe = x } -> Tm x } My guess is that will behave like Alternative 2. Simon From marlowsd at gmail.com Fri Jan 16 05:32:08 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 16 05:23:30 2009 Subject: how to load an additional file to ghci In-Reply-To: References: Message-ID: <49706228.3000504@gmail.com> Peter Hercek wrote: > Is it possible to load one more module to ghci without unloading the > modules I have already loaded? The module I would like to load in > addtion is not installed and I do not want it installed. It is also > independent of any other modules. There is no dependency from the > modules already loaded to the one I would like to add. > > How to achieve something like "load a module in this file in addition to > what I have already loaded and do not modify the the context for > expression evaluation (:module) ... just make the exported functions in > the file available through fully qualified names". :add ? Cheers, Simon From phercek at gmail.com Fri Jan 16 06:50:34 2009 From: phercek at gmail.com (Peter Hercek) Date: Fri Jan 16 06:42:03 2009 Subject: how to load an additional file to ghci In-Reply-To: <49706228.3000504@gmail.com> References: <49706228.3000504@gmail.com> Message-ID: Simon Marlow wrote: > Peter Hercek wrote: >> Is it possible to load one more module to ghci without unloading the >> modules I have already loaded? The module I would like to load in >> addtion is not installed and I do not want it installed. It is also >> independent of any other modules. There is no dependency from the >> modules already loaded to the one I would like to add. > > >> How to achieve something like "load a module in this file in addition >> to what I have already loaded and do not modify the the context for >> expression evaluation (:module) ... just make the exported functions >> in the file available through fully qualified names". > > :add ? Aaaach right that works, I'm ashamed :-D Thanks, Peter. From han.joosten at atosorigin.com Fri Jan 16 07:41:34 2009 From: han.joosten at atosorigin.com (Han Joosten) Date: Fri Jan 16 07:32:39 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <21498536.post@talk.nabble.com> Hi, I tried Simon's : Gc{} -> case r of { GC{ grspe = x } -> Tm x } This still failed with <>, like alternative 1. Then I tried Claus Reinke's suggestion: Gc{} -> Tm $! (grspe r) which had the same result , the <>. However, I was very fortunate to have Bas Joosten look into this with me. He suggested: {- Alternative 3 : -} antecedent :: Rule -> Expression antecedent r = case r of Ru{rrsrt = AlwaysExpr} -> error ("(Module ADLdef:) illegal call to antecedent of rule "++show r) Ru{} -> rrant r Sg{} -> antecedent (srsig r) Gc{} -> Tm (grspe r) Fr{} -> frcmp r We tried this alternative, and... It doesn't loop, as doesn't alternative 2: {- Alternative 2: -} antecedent :: Rule -> Expression antecedent r@(Ru AlwaysExpr _ _ _ _ _ _ _ _) = error ("(Module ADLdef:) illegal call to antecedent of rule "++show r) antecedent (Ru _ a _ _ _ _ _ _ _) = a antecedent (Sg _ rule _ _ _ _ _) = antecedent rule antecedent (Gc _ d _ _ _ _ _) = Tm d antecedent (Fr _ _ e _) = e In my case however, I like the syntax of alternative 3 much more than that of alternative 2. I do not exactly understand why the alternatives 3 and 1 behave differently. It probably has something to do with strictness, but that isn't really my cup of tea. I do wish to express my thanks to Simon, Claus and Daniel Fisher who took the trouble in reacting to my post. Thanks! (And of course Bas for being around at the right time 8-)) {- Alternative 3 : -} antecedent :: Rule -> Expression antecedent r = case r of Ru{rrsrt = AlwaysExpr} -> error ("(Module ADLdef:) illegal call to antecedent of rule "++show r) Ru{} -> rrant r Sg{} -> antecedent (srsig r) Gc{} -> Tm (grspe r) Fr{} -> frcmp r {- Alternative 1: -} antecedent :: Rule -> Expression antecedent r = case r of Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module ADLdataDef:) illegal call to antecedent of rule "++show r) else rrant r Sg{} -> antecedent (srsig r) Gc{} -> Tm (grspe r) Fr{} -> frcmp r This notation is what I was looking for. I still think that -- View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax--tp21416338p21498536.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonpj at microsoft.com Fri Jan 16 11:07:09 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 16 10:58:15 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <21498536.post@talk.nabble.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> <21498536.post@talk.nabble.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> OK once I bit the bullet and looked at the code the bug was obvious. When you pattern match Ru{rrsrt = AlwaysExpr} -> error "blah" GHC uses, well, pattern-matching to see if rrsrt is AlwaysExpr. But when you say Ru{} -> if (rrsrt r == AlwaysExpr) then error "blah" else ... then GHC uses the (==) operation for the data type RuleType (of which AlwaysExpr) is a data constructor. Sadly you have not defined it. You just say instance Eq RuleType That uses the default methods for equality. Its equivalent to instance Eq RuleType where (==) a b = not (a /= b) (/=) a b = not (a == b) So it's not surprising that you get a loop. You probably wanted to use "deriving Eq" on your data type declaration for RuleType, or deriving instance Eq RuleType So, clearly not a bug in GHC; but it would be more felicitous if it gave you a warning about the instance declaration for Eq RuleType. The difficulty is that it's not clear when to warn; it's ok to use default methods, but you must define *either* (==) *or* (/=). Simon From bulat.ziganshin at gmail.com Fri Jan 16 11:23:48 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 16 11:15:04 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> <21498536.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1364836330.20090116192348@gmail.com> Hello Simon, Friday, January 16, 2009, 7:07:09 PM, you wrote: > Sadly you have not defined it. You just say > instance Eq RuleType this is very common error. it would be great to find some way to deal with it (for predefined classes at very least...) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dave at zednenem.com Fri Jan 16 12:04:42 2009 From: dave at zednenem.com (David Menendez) Date: Fri Jan 16 11:55:46 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> <21498536.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <49a77b7a0901160904r20b5f8b8ie000a98b243fade6@mail.gmail.com> On Fri, Jan 16, 2009 at 11:07 AM, Simon Peyton-Jones wrote: > > So, clearly not a bug in GHC; but it would be more felicitous if it gave you a warning about the instance declaration for Eq RuleType. The difficulty is that it's not clear when to warn; it's ok to use default methods, but you must define *either* (==) *or* (/=). Why is (/=) a member of Eq in the first place? Is there any code that defines (/=) and uses the default for (==)? -- Dave Menendez From allbery at ece.cmu.edu Fri Jan 16 20:34:56 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Jan 16 20:26:01 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <1364836330.20090116192348@gmail.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> <21498536.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> <1364836330.20090116192348@gmail.com> Message-ID: On 2009 Jan 16, at 11:23, Bulat Ziganshin wrote: > Friday, January 16, 2009, 7:07:09 PM, you wrote: >> instance Eq RuleType > > this is very common error. it would be great to find some way to deal > with it (for predefined classes at very least...) It wouldn't catch everything, but might it make sense to output a warning on empty instance declarations? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From han.joosten at atosorigin.com Sun Jan 18 13:15:22 2009 From: han.joosten at atosorigin.com (Han Joosten) Date: Sun Jan 18 13:06:20 2009 Subject: Differences in pattern matching syntax? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <21416338.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332870D8DC5@EA-EXMSG-C334.europe.corp.microsoft.com> <21439653.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C3328716B89B@EA-EXMSG-C334.europe.corp.microsoft.com> <21487742.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED0D7@EA-EXMSG-C334.europe.corp.microsoft.com> <21498536.post@talk.nabble.com> <638ABD0A29C8884A91BC5FB5C349B1C332871ED4D1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <21530950.post@talk.nabble.com> Simon, Thank you *VERY* much for your effort to look into this problem. We have been searching for this loop for quite some time, and it caused us a lot of brain damage ;-) When we red your message last friday evening, we have given it a go and it sure was the problem. Looking back, I should have known better, but it shows I am human too, so blundering once in a while... These type of bugs can be hard to catch. We were close, but simply overlooked it. It certainly isn't a bug in ghc, as I suspected earlier this week. Ghc just did its job. However, it would be very helpful if it could give some kind of a clue. Using the -O option, ghc does detect the loop. I believe that in general that isn't trivial at all, but since it does the detection, It would probably be not too hard to give some sort of clue into the right direction. Such a clue could save days in hunting a bug. Anyways, thanks for helping out! A deep bow! Han Joosten -- View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax--tp21416338p21530950.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From twhitehead at gmail.com Mon Jan 19 00:00:00 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Sun Jan 18 23:59:30 2009 Subject: Questions regarding uvector 0.1.0.3 Message-ID: <200901190000.09811.twhitehead@gmail.com> I've been looking at uvector and had some questions (hopefully this is the right mailing list for this, if not, sorry, and please direct me properly). First, is there any design thing deeper than just supporting things like the unit and pair arrays for layering UArr on top of the underlying BUArr? Second, the STG code and the native and via-C assembler generated by ghc 6.8.2 with -O2 for test :: UArr Int -> Int -> Int test = indexU where indexU :: UA e => UArr e -> Int -> e indexU arr n = indexS (streamU arr) n is a loop that simultaneously increments the offset while decrementing the index until it reaches the desired position. If I understand correctly, this indexU definition was used instead of just bring indexU from UArr into scope in order to cancel any possible unstreamU in arr, and this is a big part of the whole streamU/unstreamU magic. It replaces what would other require N^2 rules to avoid a bunch of temporaries with one. I wonder if a rule code be added to change any outstanding "indexS (streamU arr) n" into an UArr indexU after streamU/unstreamU fusion? Such rules for each of these type of functions (i.e., ones that aren't of the form "= unstreamU . ...") would also not be N^2 and would eliminate temporary streams. Thanks! -Tyson PS: Nice code by the way. : ) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090119/94007e0d/attachment-0001.bin From karel.gardas at centrum.cz Wed Jan 21 08:37:54 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Jan 21 08:28:51 2009 Subject: new build system build fails on Solaris/x86 Message-ID: <49772532.6070507@centrum.cz> Hello, I attempt to test new build system on solaris/x86 platform and after applying patch from here: http://hackage.haskell.org/trac/ghc/ticket/2951 I've been able to boot and configure the tree. On the other hand build alone fails with: checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/editline.h usability... no checking editline/editline.h presence... no checking for editline/editline.h... no checking readline/readline.h usability... no checking readline/readline.h presence... no checking for readline/readline.h... no checking for sign of read_history result on error... negative checking for rl_completion_matches... no checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. gmake[1]: *** [libraries/editline/dist-install/package-data.mk] Error 1 gmake: *** [all] Error 2 karel@silence:/tmp/ghc-new-build-system$ Do you have any idea how to proceed or what exactly to install? Thanks, Karel From lennart at augustsson.net Wed Jan 21 10:05:47 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Jan 21 09:56:35 2009 Subject: git Message-ID: What port is git using for getting the ghc repo via http? I'm getting this message behind our thick firewall: fatal: http://darcs.haskell.org/ghc.git/info/refs download error - Failed connect to darcs.haskell.org:1080; Operation now in progress It makes me think port 1080 is involved, and I don't think any access to that port is allowed. If the repo is not totally available on port 80 (or the https port) then it's impossible to get from behind paranoid firewalls. -- Lennart From Christian.Maeder at dfki.de Wed Jan 21 10:09:41 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jan 21 10:00:26 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <49772532.6070507@centrum.cz> References: <49772532.6070507@centrum.cz> Message-ID: <49773AB5.3030603@dfki.de> How did you call gmake? editline is not needed for ghc. When building the libraries with the stage1 compiler I get: ... && touch stamp/configure.library.build-profiling-splitting.editline || touch editline/unbuildable Configuring editline-0.2.1.0... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for tputs in -lncurses... yes checking for el_init... no checking for readline... no checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/local/bin/grep checking for egrep... /usr/local/bin/grep -E checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/editline.h usability... no checking editline/editline.h presence... no checking for editline/editline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking for sign of read_history result on error... negative checking for rl_completion_matches... no checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. if ifBuildable/ifBuildable /export/local2/home/maeder/haskell/ghc-6.10.1/packages editline; then \ cd editline && .... I've no idea what your patch changes. Cheers Christian Karel Gardas wrote: > Hello, > > I attempt to test new build system on solaris/x86 platform and after > applying patch from here: > http://hackage.haskell.org/trac/ghc/ticket/2951 I've been able to boot > and configure the tree. On the other hand build alone fails with: > > checking for unistd.h... yes > checking editline/readline.h usability... no > checking editline/readline.h presence... no > checking for editline/readline.h... no > checking editline/editline.h usability... no > checking editline/editline.h presence... no > checking for editline/editline.h... no > checking readline/readline.h usability... no > checking readline/readline.h presence... no > checking for readline/readline.h... no > checking for sign of read_history result on error... negative > checking for rl_completion_matches... no > checking for completion_matches... no > configure: error: editline not found, so this package cannot be built > See `config.log' for more details. > gmake[1]: *** [libraries/editline/dist-install/package-data.mk] Error 1 > gmake: *** [all] Error 2 > karel@silence:/tmp/ghc-new-build-system$ > > Do you have any idea how to proceed or what exactly to install? > > Thanks, > Karel From karel.gardas at centrum.cz Wed Jan 21 10:15:02 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Jan 21 10:05:55 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <49773AB5.3030603@dfki.de> References: <49772532.6070507@centrum.cz> <49773AB5.3030603@dfki.de> Message-ID: <49773BF6.7000602@centrum.cz> Hello, I need to double check: I'm talking here about new build system. I've invoked simple `gmake'. Also your builds is fine since editline seems to find readline header file which seems to satisfy it while this is not in my case. How have you configure to allow it to find readline? Thanks, Karel Christian Maeder wrote: > How did you call gmake? editline is not needed for ghc. When building > the libraries with the stage1 compiler I get: > > ... > && touch stamp/configure.library.build-profiling-splitting.editline || > touch editline/unbuildable > Configuring editline-0.2.1.0... > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for tputs in -lncurses... yes > checking for el_init... no > checking for readline... no > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... /usr/local/bin/grep > checking for egrep... /usr/local/bin/grep -E > checking for ANSI C header files... no > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking editline/readline.h usability... no > checking editline/readline.h presence... no > checking for editline/readline.h... no > checking editline/editline.h usability... no > checking editline/editline.h presence... no > checking for editline/editline.h... no > checking readline/readline.h usability... yes > checking readline/readline.h presence... yes > checking for readline/readline.h... yes > checking for sign of read_history result on error... negative > checking for rl_completion_matches... no > checking for completion_matches... no > configure: error: editline not found, so this package cannot be built > See `config.log' for more details. > if ifBuildable/ifBuildable > /export/local2/home/maeder/haskell/ghc-6.10.1/packages editline; then \ > cd editline && > .... > > I've no idea what your patch changes. > Cheers Christian > > Karel Gardas wrote: >> Hello, >> >> I attempt to test new build system on solaris/x86 platform and after >> applying patch from here: >> http://hackage.haskell.org/trac/ghc/ticket/2951 I've been able to boot >> and configure the tree. On the other hand build alone fails with: >> >> checking for unistd.h... yes >> checking editline/readline.h usability... no >> checking editline/readline.h presence... no >> checking for editline/readline.h... no >> checking editline/editline.h usability... no >> checking editline/editline.h presence... no >> checking for editline/editline.h... no >> checking readline/readline.h usability... no >> checking readline/readline.h presence... no >> checking for readline/readline.h... no >> checking for sign of read_history result on error... negative >> checking for rl_completion_matches... no >> checking for completion_matches... no >> configure: error: editline not found, so this package cannot be built >> See `config.log' for more details. >> gmake[1]: *** [libraries/editline/dist-install/package-data.mk] Error 1 >> gmake: *** [all] Error 2 >> karel@silence:/tmp/ghc-new-build-system$ >> >> Do you have any idea how to proceed or what exactly to install? >> >> Thanks, >> Karel > > From sof at galois.com Wed Jan 21 10:30:37 2009 From: sof at galois.com (Sigbjorn Finne) Date: Wed Jan 21 10:21:42 2009 Subject: git In-Reply-To: References: Message-ID: <49773F9D.90108@galois.com> 1080 is SOCKS, so there's some defaulting proxy setup kicking in here. Set the 'http_proxy' environment variable to point it at your local proxy server. --sigbjorn On 1/21/2009 07:05, Lennart Augustsson wrote: > What port is git using for getting the ghc repo via http? > > I'm getting this message behind our thick firewall: > > fatal: http://darcs.haskell.org/ghc.git/info/refs download error - > Failed connect to darcs.haskell.org:1080; Operation now in progress > > It makes me think port 1080 is involved, and I don't think any access > to that port is allowed. > If the repo is not totally available on port 80 (or the https port) > then it's impossible to get from behind paranoid firewalls. > > -- Lennart > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From lennart at augustsson.net Wed Jan 21 10:40:35 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Jan 21 10:38:57 2009 Subject: git In-Reply-To: <49773F9D.90108@galois.com> References: <49773F9D.90108@galois.com> Message-ID: I have set the 'http_proxy' environment variable to point at our proxy. Before that it complained about not being able to look up the host name. On Wed, Jan 21, 2009 at 3:30 PM, Sigbjorn Finne wrote: > 1080 is SOCKS, so there's some defaulting proxy setup kicking in here. > Set the 'http_proxy' environment variable to point it at your local proxy > server. > > --sigbjorn > > On 1/21/2009 07:05, Lennart Augustsson wrote: >> >> What port is git using for getting the ghc repo via http? >> >> I'm getting this message behind our thick firewall: >> >> fatal: http://darcs.haskell.org/ghc.git/info/refs download error - >> Failed connect to darcs.haskell.org:1080; Operation now in progress >> >> It makes me think port 1080 is involved, and I don't think any access >> to that port is allowed. >> If the repo is not totally available on port 80 (or the https port) >> then it's impossible to get from behind paranoid firewalls. >> >> -- Lennart >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From karel.gardas at centrum.cz Wed Jan 21 11:14:44 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Jan 21 11:05:38 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <49773E1B.4090600@dfki.de> References: <49772532.6070507@centrum.cz> <49773AB5.3030603@dfki.de> <49773BF6.7000602@centrum.cz> <49773E1B.4090600@dfki.de> Message-ID: <497749F4.804@centrum.cz> Christian Maeder wrote: > Karel Gardas wrote: >> Hello, >> >> I need to double check: I'm talking here about new build system. I've >> invoked simple `gmake'. Also your builds is fine since editline seems to >> find readline header file which seems to satisfy it while this is not in >> my case. > > Although my configure finds readline header files, this is not enough > for editline. Both configure calls fail, but in my case the failure is > correctly handled by the build system via touching editline/unbuildable OK. > >> How have you configure to allow it to find readline? > > It is just a wrong readline.h for libreadline (lying around) and I only > called ./configure I did just as usuall: bash ./boot ./configure --prefix=/tmp/ghc-new-build-system-bin gmake For boot I'm using autoconf-2.62/automake-1.10.1 and GHC 6.8.3 Thanks, Karel From Christian.Maeder at dfki.de Wed Jan 21 11:24:00 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jan 21 11:14:50 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <497749F4.804@centrum.cz> References: <49772532.6070507@centrum.cz> <49773AB5.3030603@dfki.de> <49773BF6.7000602@centrum.cz> <49773E1B.4090600@dfki.de> <497749F4.804@centrum.cz> Message-ID: <49774C20.5090707@dfki.de> Karel Gardas wrote: > bash ./boot I don't know what ./boot does (since I only compile source distros) > ./configure --prefix=/tmp/ghc-new-build-system-bin > gmake this should work with clean sources in the top-level ghc directory > For boot I'm using autoconf-2.62/automake-1.10.1 and GHC 6.8.3 so ./boot calls basically autoreconf? Cheers Christian From igloo at earth.li Wed Jan 21 12:42:26 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 21 12:33:15 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <49774C20.5090707@dfki.de> References: <49772532.6070507@centrum.cz> <49773AB5.3030603@dfki.de> <49773BF6.7000602@centrum.cz> <49773E1B.4090600@dfki.de> <497749F4.804@centrum.cz> <49774C20.5090707@dfki.de> Message-ID: <20090121174226.GB28123@matrix.chaos.earth.li> On Wed, Jan 21, 2009 at 05:24:00PM +0100, Christian Maeder wrote: > > > For boot I'm using autoconf-2.62/automake-1.10.1 and GHC 6.8.3 > > so ./boot calls basically autoreconf? Yes, for the root of the tree, and also for any libraries that need it. In the new build system it also creates little Makefiles for each of the libraries. Thanks Ian From alios at alios.org Thu Jan 8 08:45:01 2009 From: alios at alios.org (Markus Barenhoff) Date: Wed Jan 21 12:34:59 2009 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <4965F01B.9070308@gmail.com> References: <492E6D11.1090102@gmail.com> <20081127113216.GA92698@beteigeuze.alios.net> <492FBCEA.4090406@gmail.com> <20081203102007.GA58325@beteigeuze.alios.net> <493FCA3B.70002@gmail.com> <20081212144345.GA90078@beteigeuze.alios.net> <494622DD.4060900@gmail.com> <20090107084143.GA2000@beteigeuze.alios.net> <4965F01B.9070308@gmail.com> Message-ID: <20090108134501.GA80983@beteigeuze.alios.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 479 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090108/36755079/attachment-0001.bin From igloo at earth.li Wed Jan 21 12:25:04 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 21 12:35:01 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <49772532.6070507@centrum.cz> References: <49772532.6070507@centrum.cz> Message-ID: <20090121172504.GA28123@matrix.chaos.earth.li> Hi Karel, On Wed, Jan 21, 2009 at 02:37:54PM +0100, Karel Gardas wrote: > > I attempt to test new build system on solaris/x86 platform and after Thanks for giving it a try! > configure: error: editline not found, so this package cannot be built > See `config.log' for more details. > gmake[1]: *** [libraries/editline/dist-install/package-data.mk] Error 1 > gmake: *** [all] Error 2 > karel@silence:/tmp/ghc-new-build-system$ > > Do you have any idea how to proceed or what exactly to install? Can you try the attached patch please? It just stops us from attempting to build editline. The plan is to switch to haskelline anyway (which doesn't have any C dependencies), so not being able to build editline isn't a real problem. Thanks Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: noeditline.patch Type: text/x-diff Size: 88921 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090121/daf7f680/noeditline-0001.bin From phercek at gmail.com Wed Jan 21 15:08:25 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed Jan 21 14:59:23 2009 Subject: no breakpoint location for list construction? Message-ID: Hi, Is it correct that there is no breakpoint location at list construction place: line "5 then [x]" ? Notice that :steplocal does not stop there before "[1]" is printed when debugging expression "test 1". Thanks, Peter. status:0 peter@metod [721] ~/tmp % cat b.hs hlp x = [-x] test x = if x >= 0 then [x] else hlp x status:0 peter@metod [722] ~/tmp % ghci b.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package ghciext-0.1 ... linking ... done. [1 of 1] Compiling Main ( b.hs, interpreted ) Ok, modules loaded: Main. *Main> :break 4 Breakpoint 0 activated at b.hs:4:5-10 *Main> test 1 Stopped at b.hs:4:5-10 _result :: [a] = _ 3 test x = 4 if x >= 0 5 then [x] [b.hs:4:5-10] *Main> :steplocal [1] *Main> test (-1) Stopped at b.hs:4:5-10 _result :: [a] = _ 3 test x = 4 if x >= 0 5 then [x] [b.hs:4:5-10] *Main> :steplocal Stopped at b.hs:6:9-13 _result :: [Integer] = _ x :: Integer = -1 5 then [x] 6 else hlp x 7 [b.hs:6:9-13] *Main> :steplocal [1] *Main> :quit Leaving GHCi. status:0 peter@metod [723] ~/tmp % From karel.gardas at centrum.cz Wed Jan 21 15:36:29 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Jan 21 15:27:20 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <20090121172504.GA28123@matrix.chaos.earth.li> References: <49772532.6070507@centrum.cz> <20090121172504.GA28123@matrix.chaos.earth.li> Message-ID: <4977874D.5090204@centrum.cz> Ian Lynagh wrote: > Can you try the attached patch please? > Your patch solves the problem. Now build fails printing: mkdir includes/dist-derivedconstants mkdir includes/dist-derivedconstants/build /usr/local/ghc-6.8.3/bin/ghc -optc-O -optc-DTABLES_NEXT_TO_CODE -optc-Iincludes -optc-Irts -H32m -O -i -iincludes/. -iincludes/dist-derivedconstants/build -iincludes/dist-derivedconstants/build/autogen -Iincludes/dist-derivedconstants/build -Iincludes/dist-derivedconstants/build/autogen -c includes/mkDerivedConstants.c -o includes/dist-derivedconstants/build/mkDerivedConstants.o /usr/local/ghc-6.8.3/bin/ghc -o includes/dist-derivedconstants/build/mkDerivedConstants -H32m -O -i -iincludes/. -iincludes/dist-derivedconstants/build -iincludes/dist-derivedconstants/build/autogen -Iincludes/dist-derivedconstants/build -Iincludes/dist-derivedconstants/build/autogen -odir includes/dist-derivedconstants/build -hidir includes/dist-derivedconstants/build -stubdir includes/dist-derivedconstants/build -hisuf hi -osuf o -hcsuf hc includes/dist-derivedconstants/build/mkDerivedConstants.o inplace/bin/mkdirhier inplace/bin/ cp includes/dist-derivedconstants/build/mkDerivedConstants inplace/bin/mkDerivedConstants ./inplace/bin/mkDerivedConstants >includes/DerivedConstants.h rm -f -rf libffi/build cd libffi && /usr/sfw/bin/gtar -zxf libffi*.tar.gz mv libffi/libffi*/ libffi/build mv: cannot access libffi/libffi*/ gmake[1]: *** [libffi/stamp.ffi.configure] Error 2 gmake: *** [all] Error 2 Thanks, Karel From phercek at gmail.com Thu Jan 22 05:57:47 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Jan 22 05:50:04 2009 Subject: incorrect implementation of :show bindings? Message-ID: Hi, Bindings displayed with ":show bindings" do not correspond to what can be observed by printing values explicitly for example using ":force". Is it supposed to work like that? If yes, why? Notice the value and type reported for variable "test" after it has been redefined in the example at this post end. Thanks, Peter. status:0 peter@dwarf [703] /tmp % ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> let test = 0 Prelude> :show bindings test :: Integer = _ Prelude> :force test test = 0 Prelude> let test = "zero" Prelude> :show bindings test :: Integer = 0 Prelude> :force test test = ['z','e','r','o'] Prelude> :quit Leaving GHCi. status:0 peter@dwarf [704] /tmp % From igloo at earth.li Thu Jan 22 09:49:28 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Jan 22 09:50:10 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <4977874D.5090204@centrum.cz> References: <49772532.6070507@centrum.cz> <20090121172504.GA28123@matrix.chaos.earth.li> <4977874D.5090204@centrum.cz> Message-ID: <20090122144928.GA12608@matrix.chaos.earth.li> On Wed, Jan 21, 2009 at 09:36:29PM +0100, Karel Gardas wrote: > > cd libffi && /usr/sfw/bin/gtar -zxf libffi*.tar.gz > mv libffi/libffi*/ libffi/build > mv: cannot access libffi/libffi*/ > gmake[1]: *** [libffi/stamp.ffi.configure] Error 2 > gmake: *** [all] Error 2 Aha, can you see if the attached patch fixes this please? Thanks Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: libffi.patch Type: text/x-diff Size: 89227 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090122/327fc9f9/libffi-0001.bin From phercek at gmail.com Thu Jan 22 11:20:25 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Jan 22 11:12:40 2009 Subject: a new impossible happened in ghci? Message-ID: Hi, My preliminary search indicated this is new, but still, should I add this to GHC Trac? Maybe I just cannot formulate my query well. See the ghci session log at the end. Peter. status:0 peter@dwarf [715] ~ % ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :def err (\_->return$concat$replicate(read "\"1\"") "a") Prelude> :err ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): Prelude.read: no parse Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug status:0 peter@dwarf [715] ~ % From karel.gardas at centrum.cz Thu Jan 22 13:16:31 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu Jan 22 13:07:41 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <20090122144928.GA12608@matrix.chaos.earth.li> References: <49772532.6070507@centrum.cz> <20090121172504.GA28123@matrix.chaos.earth.li> <4977874D.5090204@centrum.cz> <20090122144928.GA12608@matrix.chaos.earth.li> Message-ID: <4978B7FF.3000507@centrum.cz> Ian Lynagh wrote: > On Wed, Jan 21, 2009 at 09:36:29PM +0100, Karel Gardas wrote: >> cd libffi && /usr/sfw/bin/gtar -zxf libffi*.tar.gz >> mv libffi/libffi*/ libffi/build >> mv: cannot access libffi/libffi*/ >> gmake[1]: *** [libffi/stamp.ffi.configure] Error 2 >> gmake: *** [all] Error 2 > > Aha, can you see if the attached patch fixes this please? > Yes, but here is next error: rm -f -rf libffi/build cd libffi && /usr/sfw/bin/gtar -zxf tarball/libffi*.tar.gz mv libffi/libffi-* libffi/build chmod +x libffi/ln cd libffi && patch -p0 < libffi.dllize-3.0.6.patch Looks like a unified context diff. Hunk #5 failed at line 344. Hunk #6 failed at line 165. Hunk #7 failed at line 33. 3 out of 7 hunks failed: saving rejects to build/include/ffi.h.in.rej The next patch looks like a unified context diff. Hunk #2 failed at line 66. Hunk #3 failed at line 26. 2 out of 3 hunks failed: saving rejects to build/include/ffi_common.h.rej done gmake[1]: *** [libffi/stamp.ffi.configure] Error 1 gmake: *** [all] Error 2 Could you be so kind and review my patch attached to http://hackage.haskell.org/trac/ghc/ticket/2957 and commit it to head and your new build system branch? Thanks, Karel From mnislaih at gmail.com Fri Jan 23 08:33:20 2009 From: mnislaih at gmail.com (Pepe Iborra) Date: Fri Jan 23 08:24:02 2009 Subject: incorrect implementation of :show bindings? In-Reply-To: References: Message-ID: <44b20d900901230533x7e6188d2u3322a926380b4953@mail.gmail.com> Hi Peter, It looks like a bug to me too. I tested it and 6.6 displays the correct behaviour, while 6.8.1 shows the bug. You should open a ticket if you haven't done so yet. Cheers, pepe On Thu, Jan 22, 2009 at 11:57 AM, Peter Hercek wrote: > Hi, > > Bindings displayed with ":show bindings" do not correspond to what can be > observed by printing values explicitly for example using ":force". Is it > supposed to work like that? If yes, why? > > Notice the value and type reported for variable "test" after it has been > redefined in the example at this post end. > > Thanks, > Peter. > > status:0 peter@dwarf [703] /tmp > % ghci > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> let test = 0 > Prelude> :show bindings > test :: Integer = _ > Prelude> :force test > test = 0 > Prelude> let test = "zero" > Prelude> :show bindings > test :: Integer = 0 > Prelude> :force test > test = ['z','e','r','o'] > Prelude> :quit > Leaving GHCi. > status:0 peter@dwarf [704] /tmp > % > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From mechvel at botik.ru Fri Jan 23 08:58:51 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Jan 23 08:51:47 2009 Subject: seg-fault in 6.10.1 Message-ID: <20090123135851.GA19747@scico.botik.ru> Dear GHC team, I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, run the executable, and obtain Segmentation fault. Then, I noted that in a few places the compiler warned about skipping some class member implementations in some instances. I added these implementations, and now it works correct. Are you interested in the bug report on the above part of Segmentation fault ? ----------------- Serge Mechveliani mechvel@botik.ru From phercek at gmail.com Fri Jan 23 11:42:42 2009 From: phercek at gmail.com (Peter Hercek) Date: Fri Jan 23 11:33:40 2009 Subject: incorrect implementation of :show bindings? In-Reply-To: <44b20d900901230533x7e6188d2u3322a926380b4953@mail.gmail.com> References: <44b20d900901230533x7e6188d2u3322a926380b4953@mail.gmail.com> Message-ID: Hi Pepe, Thanks for the confirmation. I added the ticket: http://hackage.haskell.org/trac/ghc/ticket/2976 Peter. Pepe Iborra wrote: > Hi Peter, > > It looks like a bug to me too. > I tested it and 6.6 displays the correct behaviour, while 6.8.1 shows > the bug. You should open a ticket if you haven't done so yet. > > Cheers, > pepe > > On Thu, Jan 22, 2009 at 11:57 AM, Peter Hercek wrote: > >> Hi, >> >> Bindings displayed with ":show bindings" do not correspond to what can be >> observed by printing values explicitly for example using ":force". Is it >> supposed to work like that? If yes, why? >> >> Notice the value and type reported for variable "test" after it has been >> redefined in the example at this post end. >> >> Thanks, >> Peter. >> >> status:0 peter@dwarf [703] /tmp >> % ghci >> GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help >> Loading package ghc-prim ... linking ... done. >> Loading package integer ... linking ... done. >> Loading package base ... linking ... done. >> Prelude> let test = 0 >> Prelude> :show bindings >> test :: Integer = _ >> Prelude> :force test >> test = 0 >> Prelude> let test = "zero" >> Prelude> :show bindings >> test :: Integer = 0 >> Prelude> :force test >> test = ['z','e','r','o'] >> Prelude> :quit >> Leaving GHCi. >> status:0 peter@dwarf [704] /tmp >> % >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> From mad.one at gmail.com Fri Jan 23 17:47:05 2009 From: mad.one at gmail.com (Austin Seipp) Date: Fri Jan 23 17:37:57 2009 Subject: Changes in scoped type variable behavior? Message-ID: <1232750179-sup-464@existential.local> Hi, I've been reading Oleg Kiselyov's "Implicit Configurations" paper and while getting the modulus math code to work I've hit a bit of a problem. The code is attached to this message; the problem is in the normalize function: > normalize :: (Modular s a, Integral a) => a -> M s a > normalize a = M (mod a (modulus (u :: s))) Trying this code gives: > $ ghci implicit-config.hs > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( implicit-config.hs, interpreted > ) > > implicit-config.hs:34:24: > Could not deduce (Modular s a) > from the context (Modular s1 a, Integral a) > arising from a use of `modulus' at implicit-config.hs:34:24-38 > Possible fix: > add (Modular s a) to the context of > the type signature for `normalize' > In the second argument of `mod', namely `(modulus (u :: s))' > In the first argument of `M', namely `(mod a (modulus (u :: s)))' > In the expression: M (mod a (modulus (u :: s))) > Failed, modules loaded: none. > Prelude> The paper uses the following code, which annotates the return of normalize while at the same time binding the 's' type variable for use on the right hand side: > normalize :: (Modular s a, Integral a) ? a ? M s a > normalize a :: M s a = M (mod a (modulus (u :: s))) This code fails with: > $ ghci implicit-config.hs > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( implicit-config.hs, interpreted > ) > > implicit-config.hs:34:0: Parse error in pattern > Failed, modules loaded: none. > Prelude> Even with the ScopedTypeVariables extension - am I missing something? I've also tried the actual literate haskell code from the technical report and it fails with the same error (parse error in pattern.) I'm using Mac OS X 10.6 and GHC 6.10.1. Austin -------------- next part -------------- A non-text attachment was scrubbed... Name: implicit-config.hs Type: application/octet-stream Size: 4091 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090123/4bfa3f61/implicit-config.obj From dave at zednenem.com Fri Jan 23 19:25:20 2009 From: dave at zednenem.com (David Menendez) Date: Fri Jan 23 19:16:01 2009 Subject: Changes in scoped type variable behavior? In-Reply-To: <1232750179-sup-464@existential.local> References: <1232750179-sup-464@existential.local> Message-ID: <49a77b7a0901231625i63b83d4bi391518096220b255@mail.gmail.com> 2009/1/23 Austin Seipp : > > The code is attached to this message; the problem is in the normalize > function: > >> normalize :: (Modular s a, Integral a) => a -> M s a >> normalize a = M (mod a (modulus (u :: s))) "s" isn't scoped over the definition of "normalize" in this definition. You need an explicit "forall". normalize :: forall s a. (Modular s a, Integral a) => a -> M s a normalize a = M (mod a (modulus (u::s))) See section 8.8.6 of the GHC manual. -- Dave Menendez From simonpj at microsoft.com Fri Jan 23 20:15:40 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 23 20:03:53 2009 Subject: seg-fault in 6.10.1 In-Reply-To: <20090123135851.GA19747@scico.botik.ru> References: <20090123135851.GA19747@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328733CC55@EA-EXMSG-C334.europe.corp.microsoft.com> Yes we are. If you aren't using the FFI or unsafe things, you should not get a seg fault. Do help us to reproduce it -- thanks. Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs- | bounces@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 23 January 2009 13:59 | To: glasgow-haskell-bugs@haskell.org | Cc: glasgow-haskell-users@haskell.org | Subject: seg-fault in 6.10.1 | | Dear GHC team, | | I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, | run the executable, and obtain | | Segmentation fault. | | Then, I noted that in a few places the compiler warned about skipping | some class member implementations in some instances. | I added these implementations, and now it works correct. | | Are you interested in the bug report on the above part of | Segmentation fault ? | | ----------------- | Serge Mechveliani | mechvel@botik.ru | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From mechvel at botik.ru Sat Jan 24 03:42:26 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Jan 24 03:35:13 2009 Subject: seg-fault Message-ID: <20090124084226.GA2260@scico.botik.ru> Yesterday, I promised to provide a bug report with Segmentation fault on missing some method implementation. I saved this source copy. Hm ... today I still failed to reproduce this seg-fault situation! I am sorry. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From marlowsd at gmail.com Mon Jan 26 11:49:52 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 26 11:40:30 2009 Subject: how can I run ghci monad actions from ghci command line In-Reply-To: References: Message-ID: <497DE9B0.1070800@gmail.com> Peter Hercek wrote: > Is it possible to run ghci monad actions from ghci command line somehow? > > For example: I would like to check whether "it" variable is of type Bool > and whether it is True using normal Haskell code (i.e. not using ghci > commands starting with colon like :type :print). There's no way to do that right now, although you can play tricks with :define to pipe the output of GHCi commands into Haskell code. Look up Claus Reinke's example macros - they're on one of the wikis somewhere, but I don't seem to be able to find them with Google right now. Cheers, Simon From phercek at gmail.com Mon Jan 26 13:13:06 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Jan 26 13:03:54 2009 Subject: how can I run ghci monad actions from ghci command line In-Reply-To: <497DE9B0.1070800@gmail.com> References: <497DE9B0.1070800@gmail.com> Message-ID: Simon Marlow wrote: > Peter Hercek wrote: >> Is it possible to run ghci monad actions from ghci command line somehow? >> >> For example: I would like to check whether "it" variable is of type >> Bool and whether it is True using normal Haskell code (i.e. not using >> ghci commands starting with colon like :type :print). > > There's no way to do that right now, although you can play tricks with > :define to pipe the output of GHCi commands into Haskell code. Look > up Claus Reinke's example macros - they're on one of the wikis > somewhere, but I don't seem to be able to find them with Google right now. Yes, I know about Claus' tutorial, it was great and I already use his techniques a lot. I even did a small change to ghc source code to try out some stuff for easier debugging. I'm hoping to post about my experience here (maybe in a week or two). What I was searching for in this post was a possibility to write full fledged plugins or something like that. Never mind, I already went through the initial pain of my custom change to ghc so if I ever need something more complicated again I can do my tests directly in the source code. Thanks, Peter. From claus.reinke at talk21.com Mon Jan 26 13:31:47 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Jan 26 13:22:23 2009 Subject: how can I run ghci monad actions from ghci command line References: <497DE9B0.1070800@gmail.com> Message-ID: <3373C72D696649C49FF6C51CEFA0CC1A@cr3lt> >>> Is it possible to run ghci monad actions from ghci command line somehow? >>> >>> For example: I would like to check whether "it" variable is of type >>> Bool and whether it is True using normal Haskell code (i.e. not using >>> ghci commands starting with colon like :type :print). > > What I was searching for in this post was a possibility to write full > fledged plugins or something like that. > Never mind, I already went through the initial pain of my custom change > to ghc so if I ever need something more complicated again I can do my > tests directly in the source code. An intermediate approach between scripting GHCi and modifying GHCi's source would be to use the GHC API. You'd still need to read the source, but your code could be used with any GHC (via the ghc package), not just with your modified sources. I didn't mention this earlier because it doesn't give you direct access to your GHCi session (you'd be running a separate GHC session, for which you could provide GHCi style frontend and debugger functionality, plus your plugins/ modifications), but if you're thinking plugins, the GHC API is probably the way to go. If the necessary functionality is not yet exposed through the API, it probably should be (iirc, GHCi's frontend itself isn't part of the API, but the functionality used by it is, so GHCi is just one of several GHC API clients; don't know how far the debugger features you are interested in are tied to the frontend or available for all GHC API sessions). As usual, there is the design question of what to expose and how, on which GHC HQ would like user input. Nothing is as helpful for that as an actual use case!-) So, yes, please do report on your experiments. Claus From phercek at gmail.com Mon Jan 26 15:01:48 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Jan 26 14:52:36 2009 Subject: how can I run ghci monad actions from ghci command line In-Reply-To: <3373C72D696649C49FF6C51CEFA0CC1A@cr3lt> References: <497DE9B0.1070800@gmail.com> <3373C72D696649C49FF6C51CEFA0CC1A@cr3lt> Message-ID: Claus Reinke wrote: > If the necessary functionality is not yet exposed through > the API, it probably should be (iirc, GHCi's frontend itself > isn't part of the API, but the functionality used by it is, so GHCi > is just one of several GHC API clients; don't know how far the > debugger features you are interested in are tied to the frontend > or available for all GHC API sessions). As usual, there is the design > question of what to expose and how, on which GHC HQ would like user > input. Nothing is as helpful for that as an actual use case!-) So, > yes, please do report on your experiments. Actually, I do not think I want much. I just want to have something significantly better than printf debugging for my application. GHC/GHCi hacking is not my primary goal. Even now I think I'm better off with ghci and my extensions than with printf debugging. It will improve much when 6.10.2 is out (fixing ticket #2740 you helped to pin down). This mostly means adding some ghci commands which automate what I'm doing manually when debugging. Most of my expriments are related to the tickets I filled in: checking whether I can have some cheap workarourd till they are implemented or whether they actually help as much as I hope. That means that for anything more complicated I need access directly to the representation of the same code which is just being debugged. From your response it looks that if I needed something more again I'll just need to create my own version of GHCi driver and reuse the rest through GHC API. If there is some tutorial how to build custom GHCi driver or something else at a higher level (i.e. not the GHC API docs directly), please, let me know. I'll post when I have my first round of enhancements done and will be able at least guess how much they are helping. It may even help GHC team to decide whether to scrap my tickets or implement them :-D Thanks, Peter. From patl at cpan.org Tue Jan 27 15:23:05 2009 From: patl at cpan.org (Patrick LeBoutillier) Date: Tue Jan 27 15:13:35 2009 Subject: Haskell runtime in shared library? Message-ID: Hi, I'm trying to make a shared library containing the Haskell runtime, but no Haskell code per se. This shared library would then dynamically load other shared libraries containing conpiled Haskell code. Here is some pseudo code: In my_program: dlopen('my_haskell_runtime.so', RT_GLOBAL) ; hs_init(...) ; then later, in my_haskell_runtime.so: dlopen('my_haskell_module.so') ; __stginit_MyModule(); I've found some great information about FFI stuff here: http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main and here: http://blog.haskell.cz/pivnik/building-a-shared-library-in-haskell/ but I can't seem to find examples where the runtime is in a different shared object from the Haskell code/module. Is this possible to do something like this using GHC? If so, where can I find more information of how exactly to link my_haskell_runtime.so and my_haskell_module.so? Note: I'm fairy new to FFI (and Haskell in general), so it is possible that my terminology is lacking. Thanks a lot, Patrick -- ===================== Patrick LeBoutillier Rosem?re, Qu?bec, Canada From claus.reinke at talk21.com Wed Jan 28 04:05:26 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jan 28 03:55:58 2009 Subject: how can I run ghci monad actions from ghci command line References: <497DE9B0.1070800@gmail.com> <3373C72D696649C49FF6C51CEFA0CC1A@cr3lt> Message-ID: > manually when debugging. Most of my expriments are related to the > tickets I filled in: checking whether I can have some cheap workarourd > till they are implemented or whether they actually help as much as I hope. > > That means that for anything more complicated I need access directly to > the representation of the same code which is just being debugged. From > your response it looks that if I needed something more again I'll just > need to create my own version of GHCi driver and reuse the rest through > GHC API. If there is some tutorial how to build custom GHCi driver or > something else at a higher level (i.e. not the GHC API docs directly), > please, let me know. No tutorial that I'm aware of, and recent changes to the GHC API mean that some of the example code out there isn't up to date, either. But there is currently a small example of a modified GHCi on hackage (likely to be folded into the main line later). ghci-haskeline This package reimplements ghci using the GHC API and the Haskeline package for line input in command-line programs. Just a copy&modify of some of the GHCi sources, including a Main.hs to call the modified code. Claus From duncan.coutts at worc.ox.ac.uk Wed Jan 28 08:13:02 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 28 08:03:19 2009 Subject: permissions api in directory package is useless (and possibly harmful) Message-ID: <1233148382.26754.103.camel@localhost> All, We need to think about a new better permissions api for the System.Directory module. The current api and also the implementation are at best useless and possibly harmful. I've been trying to debug various permission problems related to installing files with Cabal on Unix and Windows. Half the problems seem to stem from the permissions api and the copying of permissions in copyFile. data Permissions = Permissions { readable :: Bool, writable :: Bool, executable :: Bool, searchable :: Bool } getPermissions :: FilePath -> IO Permissions setPermissions :: FilePath -> Permissions -> IO () These are clearly designed for the unix permissions model, however they do not map onto it very usefully. get/setPermissions only get the user permissions, not the group or other. So for example if I have a file: -rw-rw-rw- 1 duncan users 0 2009-01-28 12:34 foo then setPermissions "foo" (Permissions True False False False) only removes write permissions from me, not from everyone else: -r--rw-rw- 1 duncan users 0 2009-01-28 12:34 foo which cannot be what we wanted. It's also pretty useless for installing files globally. For that we want to say that a file is readable by everyone and only writable by the owner (usually root). It might even be ok to say only readable by everyone and writable by nobody, but we cannot even do that. Combine that with copyFile copying permissions and we can easily lock people out or install world-writable files depending on the umask of the user building the software. On windows getPermissions tells us almost nothing. In particular if it says the file is readable or writable, this is no guarantee that we can read or write the file. getPermissions does not look at permissions. It only consults the old DOS read-only attribute (and the file extension to tell us if a file is executable). Similarly, on windows setPermissions also only sets the read-only attribute. The read-only attribute should really be avoided. It has rather unhelpful semantics. For example moving a file over a read-only file fails, where as if windows permissions (ACLs) are used then it works as expected (same as on POSIX). The read-only attribute is only there for compatibility with heritage software, we should really never set it. There is also an implementation of copyPermissions, it's not actually exposed in System.Directory but it is used by copyFile. It calls stat to get the permissions and chmod to set them. The implementation is the same between unix and windows, on windows it uses the stat and chmod from the msvcrt library. On Unix copyPermissions does work and is probably the right thing for copyFile to do. It's the default behaviour of /bin/cp for example. However it does mean there is no easy efficient way to make a copy of a file where the destination file gets the default permissions, given the umask of the current user. This means that copyFile is not appropriate for installing files, since the user building a package is not necessarily the same as the one installing it and their umasks can and often are different. The unix install program does not copy permissions, instead it sets them explicitly. We have no portable way of doing the same. But we can at least use the System.Posix.Files.setFileMode to do it. One nice thing about copyFile is that it replaces the destination file atomically. However if we have to set the permissions in a second step then we loose this nice property. Ideally we would create the temporary file in the destination directory (exclusively and with permissions such that no other user could write to our file), we'd copy the data over, set the new destination permissions and atomically replace the destination file. The copyPermissions function on windows is useless. It does not copy permissions. The way that msvcrt implements stat and chmod means that the only "permissions" that are copied is the old DOS read-only attribute. Perhaps copying the read-only attribute is the right thing for copyFile to do, it's what the Win32 CopyFile function does, however it's never what I want to do for installing software package files. So, can we craft a useful api for permissions? We should consider what the defaults for copyfile etc should be with respect to permissions. Where those defaults are not helpful can we think of a way to let us do what we want (eg get default or specific permissions instead of copying permissions). Or is it impossible and we just have to use system-specific functions whenever we need something non-standard. In which case we need to make those functions better, they appear to be mostly lacking for the Win32 case. In either case I'm sure the existing permissions api needs to be deprecated with big flashing warnings. Duncan Oh, and while I'm thinking about it: it's not currently possible to open new/exclusive files with specific permissions and the open temp file functions on windows do not ensure the file is writable only by the current user. From johan.tibell at gmail.com Wed Jan 28 08:57:22 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Jan 28 08:47:50 2009 Subject: permissions api in directory package is useless (and possibly harmful) In-Reply-To: <1233148382.26754.103.camel@localhost> References: <1233148382.26754.103.camel@localhost> Message-ID: <90889fe70901280557x4041b1bfo82b9e1522c88f924@mail.gmail.com> On Wed, Jan 28, 2009 at 2:13 PM, Duncan Coutts wrote: > We need to think about a new better permissions api for the > System.Directory module. The current api and also the implementation are > at best useless and possibly harmful. Perhaps there's something we can learn from the rearchitecture of Java's file handling that's happening in NIO 2. They're overhauling how files, directories, file systems, links, and metadata is handled. They address things such as providing both a lowest common denominator layer and platform specific "extensions". See for example http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf starting at slide 17. Cheers, Johan From duncan.coutts at worc.ox.ac.uk Wed Jan 28 09:21:56 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 28 09:12:14 2009 Subject: permissions api in directory package is useless (and possibly harmful) In-Reply-To: <90889fe70901280557x4041b1bfo82b9e1522c88f924@mail.gmail.com> References: <1233148382.26754.103.camel@localhost> <90889fe70901280557x4041b1bfo82b9e1522c88f924@mail.gmail.com> Message-ID: <1233152516.26754.106.camel@localhost> On Wed, 2009-01-28 at 14:57 +0100, Johan Tibell wrote: > On Wed, Jan 28, 2009 at 2:13 PM, Duncan Coutts > wrote: > > We need to think about a new better permissions api for the > > System.Directory module. The current api and also the implementation are > > at best useless and possibly harmful. > > Perhaps there's something we can learn from the rearchitecture of > Java's file handling that's happening in NIO 2. They're overhauling > how files, directories, file systems, links, and metadata is handled. > They address things such as providing both a lowest common denominator > layer and platform specific "extensions". > > See for example > http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf starting at > slide 17. Yes, I'm sure there are some good ideas to consider there. I looked at NIO1 and it's got some fairly sensible stuff. Duncan From phercek at gmail.com Wed Jan 28 10:54:52 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed Jan 28 10:45:29 2009 Subject: how can I run ghci monad actions from ghci command line In-Reply-To: References: <497DE9B0.1070800@gmail.com> <3373C72D696649C49FF6C51CEFA0CC1A@cr3lt> Message-ID: Claus Reinke wrote: > ghci-haskeline > This package reimplements ghci using the GHC API and the > Haskeline package for line input in command-line programs. > > Just a copy&modify of some of the GHCi sources, including a > Main.hs to call the modified code. Thanks for the information. Ok, from the example, it looks like ghci is significantly smaller than the source in ghc-6.10.1/compiler/ghci directory. Hopefully my next changes (if any at all) will not need more than a custom ghci. The test I did needed also ghc change. The type of function GHC.resume changed from: /resume :: GhcMonad m => SingleStep -> m RunResult/ to: /resume :: GhcMonad m => (SrcSpan->Bool) -> SingleStep -> m RunResult/ ... plus the corresponding implementation change. The added argument is a filtering function to limit source spans which can recorded in the trace history. I'll post more when I know how it changes my debugging experience. Peter. From igloo at earth.li Wed Jan 28 12:22:08 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 28 12:12:35 2009 Subject: new build system build fails on Solaris/x86 In-Reply-To: <4978B7FF.3000507@centrum.cz> References: <49772532.6070507@centrum.cz> <20090121172504.GA28123@matrix.chaos.earth.li> <4977874D.5090204@centrum.cz> <20090122144928.GA12608@matrix.chaos.earth.li> <4978B7FF.3000507@centrum.cz> Message-ID: <20090128172208.GA9235@matrix.chaos.earth.li> On Thu, Jan 22, 2009 at 07:16:31PM +0100, Karel Gardas wrote: > > cd libffi && patch -p0 < libffi.dllize-3.0.6.patch > Looks like a unified context diff. > Hunk #5 failed at line 344. > Hunk #6 failed at line 165. > Hunk #7 failed at line 33. > 3 out of 7 hunks failed: saving rejects to build/include/ffi.h.in.rej > The next patch looks like a unified context diff. > Hunk #2 failed at line 66. > Hunk #3 failed at line 26. > 2 out of 3 hunks failed: saving rejects to build/include/ffi_common.h.rej > done > gmake[1]: *** [libffi/stamp.ffi.configure] Error 1 > gmake: *** [all] Error 2 > > > Could you be so kind and review my patch attached to > http://hackage.haskell.org/trac/ghc/ticket/2957 and commit it to head > and your new build system branch? I've pushed a patch that should fix it differently to HEAD and NBS: Fri Jan 23 18:00:15 GMT 2009 Ian Lynagh * Make the libffi patch files portable Solaris's patch can't apply them if the lines beginning "---" aren't preceeded by a "diff -ur foo bar" line. I'll push a patch along the lines of yours to NBS too, because it looks like it's a sensible thing to do anyway. Thanks Ian From simonpj at microsoft.com Wed Jan 28 12:44:30 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jan 28 12:34:59 2009 Subject: [Haskell] type inference & instance extensions In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCB10@ELON17P32001A.csfb.cs-group.com> References: <200901191336.n0JDasH6011965@tecumseh.cs.dartmouth.edu> <16442B752A06A74AB4D9F9A5FF076E4B4DCB10@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C332874A4804@EA-EXMSG-C334.europe.corp.microsoft.com> [Redirecting to GHC users] The <> is a bug. Thank you! I'll Trac it. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] | On Behalf Of Sittampalam, Ganesh | Sent: Monday, January 19, 2009 2:05 PM | To: haskell@haskell.org | Subject: RE: [Haskell] type inference & instance extensions | | Doug McIlroy wrote: | > A fragment of an attempt to make pairs serve as complex numbers, | using | > ghc/hugs extensions: | > | > instance Num a => Num (a,a) where | > (x,y) * (u,v) = (x*u-y*v, x*v+y*u) | > | > Unfortunately, type inference isn't strong enough to cope with | > | > (1,1)*(1,1) | > | > Why shouldn't it be strengthened to do so? | | The problem is that type classes are an "open" system. Although it's | obvious that your instance is the only one in this code that can be | used to type-check (1,1), that doesn't preclude new code adding an | instance that could make it behave differently. | | I had hoped that the code below (GHC 6.10+) would work, but it just | sends GHC into a loop when you actually try to typecheck (1,1). I don't | know if that's a bug in GHC or a misunderstanding on my part of how the | typechecking should work. | | {-# LANGUAGE FlexibleInstances, TypeFamilies #-} | | instance (a~b, Num a) => Num (a, b) where | fromInteger k = (fromInteger k, fromInteger 0) | (x,y) * (u,v) = (x*u-y*v, x*v+y*u) | | PS: Sorry, I didn't mean to say "typecheck (1,1)". I meant to say | "evaluate (1,1)*(1,1)" - I had a suspicion that some kind of infinite | polymorphic recursion through the Num instance is happening and | accidentally turned that thought into a completely different statement. | | | Ganesh | | ======================================================================= | ======= | Please access the attached hyperlink for an important electronic | communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ======================================================================= | ======= | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From philip.weaver at gmail.com Wed Jan 28 17:18:47 2009 From: philip.weaver at gmail.com (Philip Weaver) Date: Wed Jan 28 17:09:13 2009 Subject: the impossible happened, large static list. Message-ID: Hello. I think I've seen other people encounter this problem before, but I wasn't able to find the solution, if there is one. I have a very large static list of type [[Int]]. It is 128 lists of 128 integers each. When I try to load the module that defines this list, I get an error: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This happens on both linux and mac os, both ghc-6.8.3 and ghc-6.10.1, and both GHC and GHCi. Is there anything I can do to avoid this? Thanks! - Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090128/57b4d5c6/attachment.htm From twhitehead at gmail.com Fri Jan 30 00:43:37 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Fri Jan 30 00:34:02 2009 Subject: UVector overallocating for (Word/Int)(8/16/32) Message-ID: <200901300043.37461.twhitehead@gmail.com> I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four, and two times, respectively, as much memory as actually required. That is, newMBU n = ST $ \s1# -> case sizeBU n (undefined::e) of {I# len# -> case newByteArray# len# s1# of {(# s2#, marr# #) -> (# s2#, MBUArr n marr# #) }} sizeBU (I# n#) _ = I# (wORD_SCALE n#) wORD_SCALE n# = scale# *# n# where I# scale# = SIZEOF_HSWORD (sizeBU is a class member, but all the instances for (Word/Int)(8/16/32) are as given above, and SIZEOF_HSWORD is defined as 8 in MachDeps.h on my x86_64) which would seems to always allocate memory assuming an underlying alignment that is always eight bytes. It seems like the readWord(8/16/32)Array# functions may have once operated that way, but, when I dumped the assembler associated with them under ghc 6.8.2 (both native and C), I get readWord8Array leaq 16(%rsi),%rax movzbl (%rax,%rdi,1),%ebx jmp *(%rbp) readWord16Array leaq 16(%rsi),%rax movzwl (%rax,%rdi,2),%ebx jmp *(%rbp) readWord32Array leaq 16(%rsi),%rax movl (%rax,%rdi,4),%ebx jmp *(%rbp) readWord64Array leaq 16(%rsi),%rax movq (%rax,%rdi,8),%rbx jmp *(%rbp) which is using alignments of one, two, four, and eight bytes respectively. I'll attach a patch (which I haven't tested beyond compiling and looking at the generated assembler). Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: allocate.patch Type: text/x-patch Size: 4060 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090130/b3eb3558/allocate-0001.bin From simonpj at microsoft.com Fri Jan 30 03:23:24 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 30 03:13:46 2009 Subject: UVector overallocating for (Word/Int)(8/16/32) In-Reply-To: <200901300043.37461.twhitehead@gmail.com> References: <200901300043.37461.twhitehead@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328C400D30@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks Tyson. Not only for finding the problem, but for fixing it too! We love that. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Tyson Whitehead | Sent: Friday, January 30, 2009 5:44 AM | To: GHC users | Subject: UVector overallocating for (Word/Int)(8/16/32) | | I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four, | and two times, respectively, as much memory as actually required. That is, | | newMBU n = ST $ \s1# -> | case sizeBU n (undefined::e) of {I# len# -> | case newByteArray# len# s1# of {(# s2#, marr# #) -> | (# s2#, MBUArr n marr# #) }} | | sizeBU (I# n#) _ = I# (wORD_SCALE n#) | wORD_SCALE n# = scale# *# n# where I# scale# = SIZEOF_HSWORD | | (sizeBU is a class member, but all the instances for (Word/Int)(8/16/32) are | as given above, and SIZEOF_HSWORD is defined as 8 in MachDeps.h on my x86_64) | | which would seems to always allocate memory assuming an underlying alignment | that is always eight bytes. It seems like the readWord(8/16/32)Array# | functions may have once operated that way, but, when I dumped the assembler | associated with them under ghc 6.8.2 (both native and C), I get | | readWord8Array | leaq 16(%rsi),%rax | movzbl (%rax,%rdi,1),%ebx | jmp *(%rbp) | | readWord16Array | leaq 16(%rsi),%rax | movzwl (%rax,%rdi,2),%ebx | jmp *(%rbp) | | readWord32Array | leaq 16(%rsi),%rax | movl (%rax,%rdi,4),%ebx | jmp *(%rbp) | | readWord64Array | leaq 16(%rsi),%rax | movq (%rax,%rdi,8),%rbx | jmp *(%rbp) | | which is using alignments of one, two, four, and eight bytes respectively. | | I'll attach a patch (which I haven't tested beyond compiling and looking at | the generated assembler). | | Cheers! -Tyson | | From marlowsd at gmail.com Fri Jan 30 04:07:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 30 03:57:45 2009 Subject: UVector overallocating for (Word/Int)(8/16/32) In-Reply-To: <200901300043.37461.twhitehead@gmail.com> References: <200901300043.37461.twhitehead@gmail.com> Message-ID: <4982C347.4000200@gmail.com> This is in uvector, right? Then you should probably forward this to the maintainer, i.e. Don Stewart . Cheers, Simon Tyson Whitehead wrote: > I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four, > and two times, respectively, as much memory as actually required. That is, > > newMBU n = ST $ \s1# -> > case sizeBU n (undefined::e) of {I# len# -> > case newByteArray# len# s1# of {(# s2#, marr# #) -> > (# s2#, MBUArr n marr# #) }} > > sizeBU (I# n#) _ = I# (wORD_SCALE n#) > wORD_SCALE n# = scale# *# n# where I# scale# = SIZEOF_HSWORD > > (sizeBU is a class member, but all the instances for (Word/Int)(8/16/32) are > as given above, and SIZEOF_HSWORD is defined as 8 in MachDeps.h on my x86_64) > > which would seems to always allocate memory assuming an underlying alignment > that is always eight bytes. It seems like the readWord(8/16/32)Array# > functions may have once operated that way, but, when I dumped the assembler > associated with them under ghc 6.8.2 (both native and C), I get > > readWord8Array > leaq 16(%rsi),%rax > movzbl (%rax,%rdi,1),%ebx > jmp *(%rbp) > > readWord16Array > leaq 16(%rsi),%rax > movzwl (%rax,%rdi,2),%ebx > jmp *(%rbp) > > readWord32Array > leaq 16(%rsi),%rax > movl (%rax,%rdi,4),%ebx > jmp *(%rbp) > > readWord64Array > leaq 16(%rsi),%rax > movq (%rax,%rdi,8),%rbx > jmp *(%rbp) > > which is using alignments of one, two, four, and eight bytes respectively. > > I'll attach a patch (which I haven't tested beyond compiling and looking at > the generated assembler). > > Cheers! -Tyson > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Fri Jan 30 04:18:13 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 30 04:08:41 2009 Subject: a new impossible happened in ghci? In-Reply-To: References: Message-ID: <4982C5D5.9040703@gmail.com> Peter Hercek wrote: > Hi, > > My preliminary search indicated this is new, > but still, should I add this to GHC Trac? > Maybe I just cannot formulate my query well. > > See the ghci session log at the end. > > Peter. > > > status:0 peter@dwarf [715] ~ > % ghci > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> :def err (\_->return$concat$replicate(read "\"1\"") "a") > Prelude> :err > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > Prelude.read: no parse > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Fixed: Prelude> :def err (\_->return$concat$replicate(read "\"1\"") "a") Prelude> :err *** Exception: Prelude.read: no parse Cheers, Simon From marlowsd at gmail.com Fri Jan 30 06:25:40 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 30 06:16:08 2009 Subject: Haskell runtime in shared library? In-Reply-To: References: Message-ID: <4982E3B4.8010208@gmail.com> Patrick LeBoutillier wrote: > I'm trying to make a shared library containing the Haskell runtime, > but no Haskell code per se. > This shared library would then dynamically load other shared libraries > containing conpiled Haskell code. > Here is some pseudo code: > > In my_program: > dlopen('my_haskell_runtime.so', RT_GLOBAL) ; > hs_init(...) ; > > then later, in my_haskell_runtime.so: > dlopen('my_haskell_module.so') ; > __stginit_MyModule(); > > > I've found some great information about FFI stuff here: > http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main > and here: > http://blog.haskell.cz/pivnik/building-a-shared-library-in-haskell/ > but I can't seem to find examples where the runtime is in a different > shared object from the Haskell code/module. > > Is this possible to do something like this using GHC? If so, where > can I find more information of how > exactly to link my_haskell_runtime.so and my_haskell_module.so? What you're trying to do is quite experimental and not fully supported right now. In order to put Haskell code in shared objects, you have to build the code in a special way (flags -dynamic -fPIC). The build system has some support for building shared libraries: try configuring with --enable-shared. If this works, you'll get all the libraries built two ways: static and shared. See this ticket for more info: http://hackage.haskell.org/trac/ghc/ticket/1876 Cheers, Simon From marlowsd at gmail.com Fri Jan 30 06:28:59 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 30 06:19:25 2009 Subject: the impossible happened, large static list. In-Reply-To: References: Message-ID: <4982E47B.10609@gmail.com> Philip Weaver wrote: > Hello. I think I've seen other people encounter this problem before, > but I wasn't able to find the solution, if there is one. > > I have a very large static list of type [[Int]]. It is 128 lists of 128 > integers each. When I try to load the module that defines this list, I > get an error: > > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-apple-darwin): > linkBCO: >= 64k insns in BCO > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > This happens on both linux and mac os, both ghc-6.8.3 and ghc-6.10.1, > and both GHC and GHCi. Is there anything I can do to avoid this? Thanks! Sorry for the inconvenience. Splitting the list into two modules should avoid it. Here's the relevant ticket: http://hackage.haskell.org/trac/ghc/ticket/789 Cheers, Simon From twhitehead at gmail.com Fri Jan 30 10:04:21 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Fri Jan 30 09:54:43 2009 Subject: UVector overallocating for (Word/Int)(8/16/32) In-Reply-To: <4982C347.4000200@gmail.com> References: <200901300043.37461.twhitehead@gmail.com> <4982C347.4000200@gmail.com> Message-ID: <200901301004.21124.twhitehead@gmail.com> On Friday 30 January 2009 04:07:19 you wrote: > This is in uvector, right? Then you should probably forward this to the > maintainer, i.e. Don Stewart . Done. Thanks for the follow up. Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090130/6f8a1eb8/attachment.bin From matthijs at stdin.nl Fri Jan 30 14:03:47 2009 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Fri Jan 30 13:54:06 2009 Subject: Core questions Message-ID: <20090130190347.GC30132@katherina.student.utwente.nl> (I've previously sent this mail to haskell-cafe, but I guess this list is more appropriate) Hi all, for my Master's thesis, I'm looking into functional hardware descriptions, and in particular to translate haskell code into VHDL that can be programmed into an FPGA. For this, I'm using the GHC API to load the haskell source and give me (simplified) core representation. I then walk over the core tree and translate it to VHDL. On the whole the GHC API has been very useful to me. It took me some time to get used to all the (deeply) nested (algebraic) types (I didn't have any previous haskell experience when I started a month or so ago), but things are working out by now. However, there are two issues bothering me still. The first is that the Core types (in particular CoreExpr) are not instances of Show. They are instances of Outputable, which allows them to be pretty printed. However, this pretty printing is good to view the structure of the expression that the CoreExpr represents, but doesn't show the structure of the CoreExpr itself. For example, tuple construction is printed simply as (a, b), while the actual core expression is a nested application of two types, and a and b to the GHC.Tuple.(,) function (or datacon?). Also, the exact constructors used are not quite clear, which made it harder to work with the Core language for me. Instead of looking at the structure of the CoreExpr and write the appropriate patterns, I had to resort to a lot of trial and error. I tried deriving show for CoreExpr myself, but that required me to derive Show for a dozen other types and resulted in type errors beyond my understanding. Is there any compelling reason that CoreExprs are not instances of Show? My second question concerns typle construction. Since tuple types are not primitive types, but dependent types defined in various places (GHC.Tuple and Base IIRC), code working with tuples is not fundamentally different from code working with other (user defined) dependent types and thus not trivial to recognize. I've found that there are some predicate functions that can tell me if a type is a tuple type, but I've had no such luck for the actual tuple construction. In particular, when an expression creates a tuple of two Ints (a, b), this is represented in Core as the application of the element types and the element values to the (,) function (or data constructor? Not sure about this, in Core it's just a Var and the isDataConName [IIRC] predicate crashes when run on the Var). For now, I've manually matched the Var's name to GHC.Tuple.(,) and removed all type arguments to get at the actual values in the tuple. This is of course completely non-portable, to tuples with more than two elements, or unboxed tuples, etc. Is there some predicate function that can do this for me in a more portable way? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090130/1f50a8c6/attachment.bin From brian at brianweb.net Fri Jan 30 14:27:24 2009 From: brian at brianweb.net (Brian Alliet) Date: Fri Jan 30 14:17:45 2009 Subject: Core questions In-Reply-To: <20090130190347.GC30132@katherina.student.utwente.nl> References: <20090130190347.GC30132@katherina.student.utwente.nl> Message-ID: <20090130192724.GD9960@charger.brianweb.net> SPJ might be able to give you some better answers, but this should help get you started. On Fri, Jan 30, 2009 at 08:03:47PM +0100, Matthijs Kooijman wrote: > However, there are two issues bothering me still. The first is that the > Core types (in particular CoreExpr) are not instances of Show. They are > instances of Outputable, which allows them to be pretty printed. Making all GHC's datatypes Showable would probably be a nightmare. Not only because of all the instances you'd have to add, but because many of the datatypes have cycles in them (or example, DataCons point back to their TyCon). Even if you got all the "derriving Show"s in there you'd be stuck writing manual instances everywhere cycles appear. In addition, the sheer amount of data GHC carries around in its various data types would make the output pretty incomprehensable. For example, every occurance of an identifier carries around unfolding info, strictness info, arity, specializations, etc. You're probably better off just trying to wrap your head around the pretty printed output and using that. When you need to pull some more details out of a datatype just sticking random pprPanics in is a great debugging aid. > about this, in Core it's just a Var and the isDataConName [IIRC] > predicate crashes when run on the Var). You might be looking for isDataConId :: Id -> Bool, or isDataConId_maybe :: Id -> Maybe DataCon. > For now, I've manually matched the Var's name to GHC.Tuple.(,) and > removed all type arguments to get at the actual values in the tuple. > This is of course completely non-portable, to tuples with more than two > elements, or unboxed tuples, etc. You might find exprIsConApp_maybe :: CoreExpr -> Maybe (DataCon,[CoreExpr]) handy (along with isTupleCon :: DataCon -> Bool on the DataCon). -Brian From matthijs at stdin.nl Fri Jan 30 14:55:05 2009 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Fri Jan 30 14:45:26 2009 Subject: Core questions In-Reply-To: <20090130192724.GD9960@charger.brianweb.net> References: <20090130190347.GC30132@katherina.student.utwente.nl> <20090130192724.GD9960@charger.brianweb.net> Message-ID: <20090130195505.GD30132@katherina.student.utwente.nl> Hi Brian, thanks for the swift response! > Making all GHC's datatypes Showable would probably be a nightmare. Not I guessed as much. Thanks for confirming my suspicions :-) > pretty printed output and using that. When you need to pull some more > details out of a datatype just sticking random pprPanics in is a great > debugging aid. How would I go about this, then? You mean I can then use ppr on random places without needing guid get the output up properly? I think I've simply used "error" for that to the same effect, which does indeed gets the job done (albeit slowly). > You might be looking for isDataConId :: Id -> Bool, or > isDataConId_maybe :: Id -> Maybe DataCon. I didn't find this one yet, thanks. > You might find exprIsConApp_maybe :: CoreExpr -> Maybe (DataCon,[CoreExpr]) > handy (along with isTupleCon :: DataCon -> Bool on the DataCon). That looks exactly like what I need, thanks. I've used isTupleCon before (working from a Type), but didn't find anything to may a CoreExpr to a DataCon. I'll let you know how it goes. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090130/634f1968/attachment.bin From catamorphism at gmail.com Fri Jan 30 16:32:32 2009 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Jan 30 16:22:52 2009 Subject: Core questions In-Reply-To: <20090130190347.GC30132@katherina.student.utwente.nl> References: <20090130190347.GC30132@katherina.student.utwente.nl> Message-ID: <4683d9370901301332p4b561fb1u4f9afa3cae449943@mail.gmail.com> You may find it useful to use External Core (supported in GHC 6.10), which allows GHC to dump its Core representation into a text file with a well-defined format: http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html There is a (relatively) stand-alone library for handling Core programs, under utils/ext-core in the GHC distribution. If you don't find it useful, and have any suggestions as to how it could be improved, I would be interested to know; please CC both me and this list if so. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer." -- Fred Brooks From claus.reinke at talk21.com Fri Jan 30 17:52:00 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Jan 30 17:42:26 2009 Subject: Core questions References: <20090130190347.GC30132@katherina.student.utwente.nl> Message-ID: <1C0F0A008CD145DE84AC9FE2375006FF@cr3lt> >Core types (in particular CoreExpr) are not instances of Show. They are >instances of Outputable, which allows them to be pretty printed. >However, this pretty printing is good to view the structure of the >expression that the CoreExpr represents, but doesn't show the structure >of the CoreExpr itself. Not sure how practical this would be, but to get an idea of the internal structure: if you can derive the SYB classes for the Core types (which would generally be useful if you do lots of traversals), you can easily define a generic show operation, which would give you a lot of control over what kind of output you'd like. There is an example here: http://hackage.haskell.org/trac/ghc/wiki/GhcApiAstTraversals look for the showData code - straighforward base plus lots of exceptions to avoid some ideosyncrasies of GHC's internal representations (in particular, don't try to traverse parts of the structure that haven't been filled yet) example output here http://hackage.haskell.org/packages/archive/ghc-syb/0.1.1/doc/html/GHC-SYB-Utils.html hmm, I need to update that wiki page and the syb-utils package page - the code has moved from there, to the syb and ghc-syb packages, with proper maintainers. In particular, check the use of standalone deriving to get the SYB class instances for GHC API types in package ghc-syb: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-syb Iirc, the syb instances for Core were not included, if that hasn't changed yet, it would be a useful addition (for an old first stab, see the link at the bottom of that wiki page, CoreSynTraverse). Claus From philip.weaver at gmail.com Fri Jan 30 18:43:34 2009 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Jan 30 18:33:53 2009 Subject: the impossible happened, large static list. In-Reply-To: <4982E47B.10609@gmail.com> References: <4982E47B.10609@gmail.com> Message-ID: On Fri, Jan 30, 2009 at 3:28 AM, Simon Marlow wrote: > Philip Weaver wrote: > >> Hello. I think I've seen other people encounter this problem before, but >> I wasn't able to find the solution, if there is one. >> >> I have a very large static list of type [[Int]]. It is 128 lists of 128 >> integers each. When I try to load the module that defines this list, I get >> an error: >> >> ghc: panic! (the 'impossible' happened) >> (GHC version 6.10.1 for i386-apple-darwin): >> linkBCO: >= 64k insns in BCO >> >> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> >> This happens on both linux and mac os, both ghc-6.8.3 and ghc-6.10.1, and >> both GHC and GHCi. Is there anything I can do to avoid this? Thanks! >> > > Sorry for the inconvenience. Splitting the list into two modules should > avoid it. Here's the relevant ticket: > > http://hackage.haskell.org/trac/ghc/ticket/789 > > Cheers, > Simon > Ah, thanks. In this particular case, I was also able to get it to work by binding each list inside the top-level list like this: top_level_list = [ list0, list1, list2, list3, list4, list5 ... list127] list0 = ... list1 = ... list2 = ... ... list127 = ... - Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090130/888caf6c/attachment.htm From dons at galois.com Fri Jan 30 19:24:02 2009 From: dons at galois.com (Don Stewart) Date: Fri Jan 30 19:14:20 2009 Subject: UVector overallocating for (Word/Int)(8/16/32) In-Reply-To: <200901300043.37461.twhitehead@gmail.com> References: <200901300043.37461.twhitehead@gmail.com> Message-ID: <20090131002402.GD22198@scytale.galois.com> Ah ha! Excellent! Much apprciated. twhitehead: > I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four, > and two times, respectively, as much memory as actually required. That is, > > newMBU n = ST $ \s1# -> > case sizeBU n (undefined::e) of {I# len# -> > case newByteArray# len# s1# of {(# s2#, marr# #) -> > (# s2#, MBUArr n marr# #) }} > > sizeBU (I# n#) _ = I# (wORD_SCALE n#) > wORD_SCALE n# = scale# *# n# where I# scale# = SIZEOF_HSWORD > > (sizeBU is a class member, but all the instances for (Word/Int)(8/16/32) are > as given above, and SIZEOF_HSWORD is defined as 8 in MachDeps.h on my x86_64) > > which would seems to always allocate memory assuming an underlying alignment > that is always eight bytes. It seems like the readWord(8/16/32)Array# > functions may have once operated that way, but, when I dumped the assembler > associated with them under ghc 6.8.2 (both native and C), I get > > readWord8Array > leaq 16(%rsi),%rax > movzbl (%rax,%rdi,1),%ebx > jmp *(%rbp) > > readWord16Array > leaq 16(%rsi),%rax > movzwl (%rax,%rdi,2),%ebx > jmp *(%rbp) > > readWord32Array > leaq 16(%rsi),%rax > movl (%rax,%rdi,4),%ebx > jmp *(%rbp) > > readWord64Array > leaq 16(%rsi),%rax > movq (%rax,%rdi,8),%rbx > jmp *(%rbp) > > which is using alignments of one, two, four, and eight bytes respectively. > > I'll attach a patch (which I haven't tested beyond compiling and looking at > the generated assembler). > > Cheers! -Tyson > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dave at zednenem.com Sat Jan 31 23:57:41 2009 From: dave at zednenem.com (David Menendez) Date: Sat Jan 31 23:48:10 2009 Subject: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC Message-ID: <49a77b7a0901312057g79026785mfc539729e9003715@mail.gmail.com> I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 running OS X 10.5.5. From what I can tell, I'm getting a segmentation fault from cabal-bin. This is possibly related to and . cd extensible-exceptions && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp /bin/sh: line 1: 19203 Segmentation fault /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp make[1]: *** [bootstrapping.conf] Error 139 make: *** [stage1] Error 2 -- Dave Menendez