From marlowsd at gmail.com Mon Dec 1 04:15:07 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 1 04:08:40 2008 Subject: GHCi debugger status In-Reply-To: <49301803.9040003@charter.net> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com> <7EE0915016A84FBCAE3075123F47D2E3@cr3lt><492A9763.8030100@gmail.com> <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt><492AC1F8.1060808@gmail.com> <492AD612.1040303@gmail.com> <44b20d900811240909q1c272f92w4889422276f30d43@mail.gmail.com><4B38ABE7843C4D8C8A1BC76320571745@cr3lt> <492BC369.9010403@gmail.com> <7A9B504362CA4256B62E8D75A3E35518@cr3lt> <492C2135.6060306@gmail.com> <49301803.9040003@charter.net> Message-ID: <4933AB1B.1070709@gmail.com> Isaac Dupree wrote: > Simon Marlow wrote: >> Claus Reinke wrote: >>> Then how about my suggestion for selectively adding lexical scope to >>> breakpoints? I'd like to be able to say >>> >>> :break {names} >>> >>> and have GHCi make the necessary changes to keep {names} available >>> for inspection when it hits that breakpoint. >> >> The only easy way to do that is to recompile the module that contains >> the breakpoint. To do it without recompiling is about as hard as >> doing what I suggested above, because it involves a similar mechanism >> (being able to selectively retain the values of free variables). > > sure, but GHCi recompiling the module maybe takes less than a second, > whereas going and modifying the source-code in an editor takes orders of > magnitude more time! Is there something fundamentally wrong with > recompiling an interpreted module? One problem with recompiling is that you lose any execution context - normally you can set new breakpoints during execution, but recompiling would force you to start the debugging session again. Also any bindings made on the command-line will be lost. However, I agree, recompiling is still better than nothing. Cheers, Simon From simonpj at microsoft.com Mon Dec 1 07:19:47 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 1 07:13:20 2008 Subject: Platforms that GHC supports Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33281448C00@EA-EXMSG-C334.europe.corp.microsoft.com> Friends Lots of the bug reports on the GHC bug tracker are platform-specific. We thought it'd help for us to articulate more clearly what platforms GHC supports, and what we'd like it to support. Look here: http://hackage.haskell.org/trac/ghc/wiki/Platforms What you'll notice is that we (GHC HQ) only guarantee to support a fairly narrow range of "Tier 1" platforms, albeit ones that cover a large fraction of our users. There's a much longer list of "Tier 2" platforms, that we'd love to have working, and know of no reason they can't work, but for which we need your help. We are actively looking for sponsors for Tier 2 platforms. If you think you could help, please let us know. Thanks. Simon & Simon From Christian.Maeder at dfki.de Mon Dec 1 10:57:43 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Dec 1 10:51:19 2008 Subject: gtk2hs and MacPorts Message-ID: <49340977.7000508@dfki.de> Hi, recently (last Friday) I had a chance to use MacPorts to install gtk2hs. (Usually I do not have root permissions to do so.) Actually, I only wanted to install the libraries needed to run a gtk2hs application that I've created on another machine. On that other machine gtk was (painfully) installed using http://developer.imendio.com/projects/gtk-macosx/build-instructions and gtk2hs-0.9.13 was then compiled from source. sudo port install gtk2hs began at some stage to compile ghc-6.10.1 which I aborted, because I thought, gtk2hs would not work with ghc-6.10.1. ("port search ghc" on another mac lists ghc-6.8.3, though.) Therefore I tried to only install the needed libraries for the binary. (libglade2, gtk2, etc.) Finally my binary complained about a missing libgdk-quartz-2.0.0.dylib or libgtk-quartz-2.0.0.dylib and I had no idea how to get it from MacPorts. (Initially I did not even see the difference of the two library names "gtk" vs, "gdk".) I don't know if my binary is linked against too many libraries. Is this possible or is the linker smart enough to avoid this? Below is the list of libraries my binary needs. I've just found http://www.haskell.org/haskellwiki/Gtk2Hs#Mac_OS_X and the list of dependencies: glade3 libglade2 gstreamer gst-plugins-base gtksourceview cairo librsvg gtkglext firefox Which one contains "quartz"? Another problem have been the links lib{jpeg,png,tiff}.dylib. I had to remove them from my DYLD_LIBARRY_PATH in order to avoid an error in ApplicationServices: dyld: Symbol not found: __cg_jpeg_resync_to_restart Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO Are the libraries lib{jpeg,png,tiff}.dylib needed at all for gtk? Cheers Christian otool -L /home/maeder/gtk/inst/lib/libglade-2.0.0.dylib (compatibility version 1.0.0, current version 1.7.0) /home/maeder/gtk/inst/lib/libxml2.2.dylib (compatibility version 9.0.0, current version 9.32.0) /home/maeder/gtk/inst/lib/libgtk-quartz-2.0.0.dylib (compatibility version 1305.0.0, current version 1305.0.0) /home/maeder/gtk/inst/lib/libgdk-quartz-2.0.0.dylib (compatibility version 1305.0.0, current version 1305.0.0) /home/maeder/gtk/inst/lib/libatk-1.0.0.dylib (compatibility version 2210.0.0, current version 2210.1.0) /home/maeder/gtk/inst/lib/libgio-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 1305.0.0, current version 1305.0.0) /home/maeder/gtk/inst/lib/libpangocairo-1.0.0.dylib (compatibility version 2102.0.0, current version 2102.2.0) /home/maeder/gtk/inst/lib/libpango-1.0.0.dylib (compatibility version 2102.0.0, current version 2102.2.0) /home/maeder/gtk/inst/lib/libcairo.2.dylib (compatibility version 20.0.0, current version 20.5.0) /home/maeder/gtk/inst/lib/libgmodule-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libgthread-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libgobject-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libglib-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.1.0) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.9.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) From colin at colina.demon.co.uk Mon Dec 1 11:04:20 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Dec 1 10:57:51 2008 Subject: gtk2hs and MacPorts In-Reply-To: <49340977.7000508@dfki.de> (Christian Maeder's message of "Mon\, 01 Dec 2008 16\:57\:43 +0100") References: <49340977.7000508@dfki.de> Message-ID: >>>>> "Christian" == Christian Maeder writes: Christian> began at some stage to compile ghc-6.10.1 which I Christian> aborted, because I thought, gtk2hs would not work with Christian> ghc-6.10.1. I managed to compile it on Linux with 6.10.1 against contents of darcs repository. Seems to work OK. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Mon Dec 1 11:17:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 1 11:11:38 2008 Subject: Weak pointers and STM In-Reply-To: <20081201045938.GF7014@sliver.repetae.net> References: <20081201045938.GF7014@sliver.repetae.net> Message-ID: <49340E37.6050606@gmail.com> John Meacham wrote: > Are there any caveats to using weak pointers and STM together? in > particular, the two cases I am interested in are > > 1. is using 'deRefWeak' fully safe inside 'unsafeIOtoSTM'? As in, will > it combine arbitrary STM actions with checking if a weak pointer is > still valid atomically? You certainly can't use STM to wait until the result of deRefWeak changes with retry. but that's probably not what you're asking. It's certainly not atomic, in that the result of deRefWeak might be different at different points in the transaction. Hmm, what property is it you want here? > 2. is using an atomically retry safe inside of a finalizer? Will it > introduce any concurrency bottlenecks or can I just consider code run in > a finalizer just like code run in any other thread? Yes. Once running, a finalizer is just like another thread, with one exception: we batch finalizers that start together in a single thread, so if these finalizers need to communicate with each other, a deadlock could ensue. This is fixable without too much difficulty though, so let us know if it is a problem for you. > I just wanted to be sure before I base an integral component of a projects design > on these working properly. I'd be wary about relying on unsafeIOToSTM in any significant way. We know it has some pretty severe drawbacks, for one thing if the transaction is aborted then the IO computation is just discarded, not sent an exception or anything (I think we have a ticket filed for this). Cheers, Simon From p.k.f.holzenspies at utwente.nl Tue Dec 2 07:56:03 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?utf-8?q?H=C3=B6lzenspies?=) Date: Tue Dec 2 07:49:28 2008 Subject: Alex requirement for Setup.lhs Message-ID: <200812021356.03932.p.k.f.holzenspies@utwente.nl> Dear all, Hopefully, you will excuse me for my lack of experience with Cabal. I have seen quite a few e-mails on this list that seem related to this issue, but my specific error, I did not find. Thus: Since installing 6.10.1, I can't perform Setup.(l)hs functions. The error message I get is: Setup.hs: alex is required but it could not be found. The problem is that I get this error also when I try to "runghc Setup.lhs build" alex (is the fact that "runghc Setup.lhs configure" does *not* produce this error significant?). I'm running an OpenSuSE 10.3 installation on which I can only install rpms from standard repositories. In these repositories, there is no binary distribution of alex. How do I install alex from source without requiring alex? Regards, Philip From chak at cse.unsw.edu.au Tue Dec 2 08:44:40 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Dec 2 08:38:06 2008 Subject: Using Data Parallel Haskell Message-ID: <3378F560-5C42-4F99-A5E2-9CFF1C9BF03B@cse.unsw.edu.au> As previously announced, GHC 6.10.1 includes a technology preview of Data Parallel Haskell. However, so far, there was no documentation on how to use it. That is different now: http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Please keep in mind that this is a very preliminary version of the system with limited functionality. However, we are very interested in feedback from interested users. Happy Vectorising! Manuel From john at repetae.net Tue Dec 2 09:24:26 2008 From: john at repetae.net (John Meacham) Date: Tue Dec 2 09:17:50 2008 Subject: Weak pointers and STM In-Reply-To: <49340E37.6050606@gmail.com> References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com> Message-ID: <20081202142426.GB18561@sliver.repetae.net> Well, the actual problem I am trying to solve involves properly reclaiming elements in a circularly linked list (next and prev pointers are TVars). I have a linked list and I need to be able to remove values from the list when all references to the node no longer exist, not counting the linked list references themselves. Using Weak pointers inside the list itself doesn't work, since if an element is collected, you also lose the information needed to stitch up the list. Originally, I had a wacky plan involving weak pointers in the nodes themselves pointing to sentinal nodes, when the sentinal was collected, I then know I can delete the node. The idea was that I can lazily delete entire chains of nodes rather than one by one. I gave up on that idea. (deRefWeak not working in STM was sort of a show stopper, and it was overly complicated) So now I have a scheme whereby I attach a finalizer to a proxy thunk. > data TimeStamp = TimeStamp TS > > data TS = TS { > tsWord :: TVar Word64, > tsPrev :: TVar TS, > tsNext :: TVar TS > } so, the finalizer attached to 'TimeStamp' values simply deletes the value it points to from the linked list. The module interface ensures that only 'TimeStamp' values can escape and each has a finalizer attached. the interface is quite simple: > newTimeStamp :: IO TimeStamp > insertAfter :: TimeStamp -> IO TimeStamp now, the problem is that I want to export insertAfter in the 'STM' monad, not the IO one. however, I am not sure how to pull it off. I cannot ensure the finalizer is only attached once to the node, if I use 'unsafeIOToSTM' then STM retrying could end up created multiple finalized nodes, possibly prematurely deleting the element from the linked list. basically, what would be really nice is if there were something like > registerCommitIO :: IO () -> STM () where all IO actions registered with this function (within an atomically block) are executed exactly once if and only if the atomically block commits. The IO action is not run within the STM block, notably atomically $ do foo; registerCommitIO bar; baz is equivalent to atomically (do foo; baz) >> bar I found I needed the equivalent of 'touchForeignPtr' for arbitrary objects (which I was able to do with the touch# primitive, but > touch :: a -> IO () > touchSTM :: a -> STM () would both be at home in System.Mem.Weak. While I am wishing for things, > unsafePerformSTM :: STM a -> a would be really handy too :) John attached is my module in question, so, my challenge is basically to make insertAfter/insertBefore have STM types and to make the 'Ord' instance not fail with "nested atomically" error when evaluated within an STM block (so I can get rid of compareTimeStamp). {-# OPTIONS_GHC -fglasgow-exts #-} module TimeStamp( TimeStamp(), newTimeStamp, compareTimeStamp, insertAfter, insertBefore ) where import Data.Word import System.IO.Unsafe import Control.Concurrent.STM import System.Mem.Weak import GHC.Prim import GHC.IO import GHC.Conc import Foreign.ForeignPtr data TimeStamp = TimeStamp TS data TS = TS { tsWord :: TVar Word64, tsPrev :: TVar TS, tsNext :: TVar TS } instance Eq TimeStamp where TimeStamp a == TimeStamp b = tsWord a == tsWord b instance Ord TimeStamp where compare x y = unsafePerformIO . atomically $ compareTimeStamp x y {-# NOINLINE theBase #-} theBase :: TS theBase = unsafePerformIO $ newTimeStampSpace newTimeStampSpace :: IO TS newTimeStampSpace = mdo bot <- newTVarIO 0 botNext <- newTVarIO beginningOfTime botPrev <- newTVarIO beginningOfTime let beginningOfTime = TS { tsWord = bot, tsNext = botNext, tsPrev = botPrev } return beginningOfTime newTimeStamp :: IO TimeStamp newTimeStamp = insertAfter (TimeStamp theBase) deleteTimeStamp :: TS -> IO () deleteTimeStamp ts = do atomically $ do tsn <- readTVar (tsNext ts) tsp <- readTVar (tsPrev ts) writeTVar (tsPrev tsn) tsp writeTVar (tsNext tsp) tsn writeTVar (tsWord ts) (error "time stamp was deleted") compareTimeStamp :: TimeStamp -> TimeStamp -> STM Ordering compareTimeStamp t1@(TimeStamp ts1) t2@(TimeStamp ts2) = do bw <- readTVar $ tsWord theBase x <- readTVar (tsWord ts1) y <- readTVar (tsWord ts2) unsafeIOToSTM $ touchTS t1 unsafeIOToSTM $ touchTS t2 return $ compare (x + bw) (y + bw) insertAfter' :: TS -> STM (TS,TimeStamp) insertAfter' ts = do nts <- newTS doInsertAfter nts ts return (nts,TimeStamp nts) insertAfter :: TimeStamp -> IO TimeStamp insertAfter t@(TimeStamp ts) = do (tts,ts) <- atomically $ insertAfter' ts touchTS t addFinalizer ts (deleteTimeStamp tts) return ts insertBefore :: TimeStamp -> IO TimeStamp insertBefore t@(TimeStamp ts) = do (tts,ts) <- atomically $ readTVar (tsPrev ts) >>= insertAfter' touchTS t addFinalizer ts (deleteTimeStamp tts) return ts touchTS :: TimeStamp -> IO () touchTS ts = touchForeignPtr (unsafeCoerce# ts) doInsertAfter :: TS -> TS -> STM () doInsertAfter ts1 ts2 = do v0 <- readTVar (tsWord ts2) let makeRoom j ts = do ts <- readTVar (tsNext ts) wj' <- if tsWord ts /= tsWord ts2 then readTVar (tsWord ts) else return (maxBound + v0) if fromIntegral (wj' - v0) <= j*j then makeRoom (j + 1) ts else relabel (wj' - v0) j relabel _ 1 = return () relabel wj j = do rl ts2 [ ((toInteger wj * k) `div` j) + fromIntegral v0 | k <- [ 1 .. j - 1] ] rl ts [] = return () rl ts (n:ns) = do ts <- readTVar (tsNext ts) writeTVar (tsWord ts) (fromIntegral n) rl ts ns makeRoom 1 ts2 tn <- readTVar (tsNext ts2) wn <- readTVar (tsWord tn) writeTVar (tsNext ts1) tn writeTVar (tsPrev ts1) ts2 writeTVar (tsNext ts2) ts1 writeTVar (tsPrev tn) ts1 bw <- readTVar $ tsWord theBase let avg = a1 `div` 2 + (a2 `div` 2) + (a1 `mod` 2 + a2 `mod` 2) `div` 2 a1 = v0 - bw a2 = if tsWord tn == tsWord theBase then maxBound else wn - bw writeTVar (tsWord ts1) avg showTimeStamp :: TimeStamp -> IO () showTimeStamp (TimeStamp ts) = atomically (f ts) >>= print where f t = do x <- readTVar (tsWord t) tsn <- readTVar (tsNext t) if tsWord tsn == tsWord ts then return [x] else fmap (x:) (f tsn) showTimeStamps :: IO () showTimeStamps = showTimeStamp (TimeStamp theBase) newTS = do w <- newTVar undefined next <- newTVar undefined prev <- newTVar undefined return $ TS w next prev From jason.dusek at gmail.com Tue Dec 2 13:25:49 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Dec 2 13:19:14 2008 Subject: ghci and user private groups Message-ID: <42784f260812021025o42e7d6b9x9678f61d7227bfc@mail.gmail.com> User private groups are not an abnormal configuration, but GHCi has such strict security that they are not allowed! :; 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. *** WARNING: /Users/jsn/tmp is writable by someone else, IGNORING! *** WARNING: /Users/jsn/tmp/.ghci is writable by someone else, IGNORING! Prelude> :q Leaving GHCi. :; cd ../ :; ls -laR tmp/ tmp/: total 4 drwxrwx--- 2 jsn jsn 102 2008-12-02 10:19 . drwxr-x--- 49 jsn jsn 2890 2008-12-02 10:17 .. -rw-rw---- 1 jsn jsn 159 2008-12-02 10:20 .ghci I appreciate what you guys are trying to do, but I at the very least, it should be permitted to use a GHCi that is group readable/writable as long as the group name and user name are the same. It would be preferable, however, to do away with the restriction altogether. -- _jsn From duncan.coutts at worc.ox.ac.uk Tue Dec 2 18:39:45 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Dec 2 18:33:13 2008 Subject: ghci and user private groups In-Reply-To: <42784f260812021025o42e7d6b9x9678f61d7227bfc@mail.gmail.com> References: <42784f260812021025o42e7d6b9x9678f61d7227bfc@mail.gmail.com> Message-ID: <1228261185.10115.208.camel@localhost> On Tue, 2008-12-02 at 10:25 -0800, Jason Dusek wrote: > I appreciate what you guys are trying to do, but I at the very > least, it should be permitted to use a GHCi that is group > readable/writable as long as the group name and user name are > the same. Hmm. That's a convention but it doesn't have any particular semantics in unix security. If it really is only you in that group then why does it need to be group writable? Isn't that the simple workaround? > It would be preferable, however, to do away with the > restriction altogether. I'm not sure they can do away with it completely. The problem of course is that some other user could drop a .ghci file and run arbitrary IO actions as you. Duncan From s.clover at gmail.com Tue Dec 2 21:10:08 2008 From: s.clover at gmail.com (Sterling Clover) Date: Tue Dec 2 21:03:31 2008 Subject: Weak pointers and STM In-Reply-To: <20081202142426.GB18561@sliver.repetae.net> References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com> <20081202142426.GB18561@sliver.repetae.net> Message-ID: > > > basically, what would be really nice is if there were something like > > > registerCommitIO :: IO () -> STM () > > where all IO actions registered with this function (within an atomically > block) are executed exactly once if and only if the atomically block > commits. The IO action is not run within the STM block, notably > > atomically $ do foo; registerCommitIO bar; baz > > is equivalent to > > atomically (do foo; baz) >> bar > This is easy enough to whip up with a monad transformer over STM. I think the AdvSTM implementations [1] are rather complicated and heavyweight, but they give a general picture of how to proceed. A simple ReaderT with a TChan should do the trick quite nicely. [1] http://www.haskell.org/haskellwiki/New_monads/MonadAdvSTM Regards, Sterl. p.s. as for the issue of the Ord instance, I wonder if tsWord needs to be a TVar or if an IVar or IORef would be sufficient? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081202/0f0fdfbf/attachment-0001.htm From jason.dusek at gmail.com Wed Dec 3 01:46:16 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Dec 3 01:39:37 2008 Subject: ghci and user private groups In-Reply-To: <1228261185.10115.208.camel@localhost> References: <42784f260812021025o42e7d6b9x9678f61d7227bfc@mail.gmail.com> <1228261185.10115.208.camel@localhost> Message-ID: <42784f260812022246t4bdf0f2etacd251b37377035@mail.gmail.com> Duncan Coutts wrote: > Jason Dusek wrote: > > I appreciate what you guys are trying to do, but I at the > > very least, it should be permitted to use a GHCi that is > > group readable/writable as long as the group name and user > > name are the same. > > Hmm. That's a convention but it doesn't have any particular > semantics in unix security. It is a common convention, of great practical value. Unfortunately, UNIX security is very much a matter of conventions. > If it really is only you in that group then why does it need > to be group writable? Isn't that the simple workaround? It is not abnormal to have a umask of 00x when using user private groups, the idea being, when you are actually in a public folder with public ownership, the permissions will be set correctly for collaborators. With this umask, all temporary '.ghci' files are created with permissions that are incompatible with GHCi. > I'm not sure they can do away with it completely. The problem > of course is that some other user could drop a .ghci file and > run arbitrary IO actions as you. I appreciate that, in the general case, a malicious person could place '.ghci' files in random places all over the filesystem, hoping someone will be so unlucky as to start a GHCi session there. User private groups do provide a way to avert this danger -- check that the only member of the owning group is the active user -- so there is no need to worry in that specific case. (Or is there? I will think about it for a spell, but I am pretty sure.) -- _jsn From alios at alios.org Wed Dec 3 05:20:07 2008 From: alios at alios.org (Markus Barenhoff) Date: Wed Dec 3 05:13:30 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <492FBCEA.4090406@gmail.com> References: <20081126143015.GA28186@beteigeuze.alios.net> <492E6D11.1090102@gmail.com> <20081127113216.GA92698@beteigeuze.alios.net> <492FBCEA.4090406@gmail.com> Message-ID: <20081203102007.GA58325@beteigeuze.alios.net> On Fri 28.11 09:42, Simon Marlow wrote: > Markus Barenhoff wrote: > >On Thu 27.11 09:49, Simon Marlow wrote: Hi! > >I checked out and translated the head version of ghc today from darcs. > >It compiled fine. When I now try to start the ghci I get the following: > > > >---- snip ---- > >GHCi, version 6.11.20081126: http://www.haskell.org/ghc/ :? for help > >ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for > >626688 bytes at 0x40000000, got 0x801635000. Try specifying an address > >with +RTS -xm -RTS > > (GHC version 6.11.20081126 for x86_64_unknown_freebsd) > > Please report this as a GHC bug: > > http://www.haskell.org/ghc/reportabug > > Abort (core dumped) > >---- snip ---- > > > >If it helps somehow, you can find the core dump here: > >http://www.alios.org/~alios/ghc.core.bz2 > > That's odd, because 6.8.3 is using 0x40000000 on FreeBSD and is working > fine (or is it?). yes, it worked, but I haven't installed anymore - so I'am not sure, where it does maps its stuff into memory. > > Ideally I need to find out what the memory map is for GHCi. I posted some > instructions for doing this on Linux/Xen, maybe you can adapt these to work > on FreeBSD: > > http://www.haskell.org/pipermail/glasgow-haskell-users/2008-November/016091.html > > The bit that needs to change is 'cat /proc//maps' - does FreeBSD have > something similar? > I tried it with the following results: ---- gdb session ---- (gdb) run --interactive -B/usr/local/lib/ghc-6.11.20081126/. Starting program: /usr/local/lib/ghc-6.11.20081126/ghc --interactive -B/usr/local/lib/ghc-6.11.20081126/. (no debugging symbols found)...[New LWP 100250] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x801e01120 (LWP 100250)] [New Thread 0x801e01290 (LWP 100334)] [New Thread 0x801e01400 (LWP 100335)] GHCi, version 6.11.20081126: http://www.haskell.org/ghc/ :? for help ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for 626688 bytes at 0x40000000, got 0x801635000. Try specifying an address with +RTS -xm -RTS (GHC version 6.11.20081126 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. [Switching to Thread 0x801e01120 (LWP 100250)] 0x0000000801bcb1dc in thr_kill () from /lib/libc.so.7 ---- gdb session ---- ---- process virtual memeory ---- # cat /proc/65557/map 0x400000 0x1507000 3126 3539 0xffffff0026bfe270 r-x 2 1 0x4 COW NC vnode /usr/local/lib/ghc-6.11.20081126/ghc 0x1607000 0x179e000 404 0 0xffffff00032e3a90 rw- 1 0 0x2104 COW NNC vnode /usr/local/lib/ghc-6.11.20081126/ghc 0x179e000 0x17a2000 4 0 0xffffff001c260b60 rw- 1 0 0x2104 NCOW NNC default - 0x801607000 0x80162c000 27 0 0xffffff001b143000 r-x 1 0 0x2104 COW NNC vnode /libexec/ld-elf.so.1 0x80162c000 0x801635000 8 0 0xffffff003789d820 rw- 1 0 0x2104 NCOW NNC default - 0x801635000 0x8016ce000 0 0 0xffffff001a0bad00 rwx 1 0 0x4 COW NC vnode /usr/local/lib/ghc-6.11.20081126/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o 0x80172b000 0x801732000 7 0 0xffffff002b24a9c0 rw- 1 0 0x2104 COW NNC vnode /libexec/ld-elf.so.1 0x801732000 0x801738000 5 0 0xffffff0033841820 rw- 1 0 0x2104 NCOW NNC default - 0x801738000 0x801748000 16 0 0xffffff00372d2750 r-x 1 0 0x2104 COW NNC vnode /lib/libthr.so.3 0x801748000 0x801749000 1 0 0xffffff002f555410 r-x 1 0 0x2104 COW NNC vnode /lib/libthr.so.3 0x801749000 0x801849000 4 0 0xffffff00052de270 r-x 218 39 0x4 COW NC vnode /lib/libthr.so.3 0x801849000 0x80184c000 3 0 0xffffff002d7b2b60 rw- 1 0 0x2104 COW NNC vnode /lib/libthr.so.3 0x80184c000 0x80184e000 2 0 0xffffff0030c72410 rw- 1 0 0x2104 NCOW NNC default - 0x80184e000 0x801859000 11 0 0xffffff0001cb29c0 r-x 174 78 0x4 COW NC vnode /lib/libutil.so.7 0x801859000 0x80185a000 1 0 0xffffff002279fb60 r-x 1 0 0x2104 COW NNC vnode /lib/libutil.so.7 0x80185a000 0x801959000 2 0 0xffffff0001cb29c0 r-x 174 78 0x4 COW NC vnode /lib/libutil.so.7 0x801959000 0x80195b000 2 0 0xffffff002f1174e0 rw- 1 0 0x2104 COW NNC vnode /lib/libutil.so.7 0x80195afff 0x80195c000 0 0 0 rw- 0 0 0x0 NCOW NNC none - 0x80195c000 0x801973000 16 0 0xffffff0001c1ec30 r-x 254 48 0x4 COW NC vnode /lib/libm.so.5 0x801973000 0x801974000 1 0 0xffffff0030f9a820 r-x 1 0 0x2104 COW NNC vnode /lib/libm.so.5 0x801974000 0x801a74000 4 0 0xffffff0001c1ec30 r-x 254 48 0x4 COW NC vnode /lib/libm.so.5 0x801a74000 0x801a76000 2 0 0xffffff0032c10270 rw- 1 0 0x2104 COW NNC vnode /lib/libm.so.5 0x801a76000 0x801a79000 3 0 0xffffff000ab1e1a0 r-x 4 2 0x4 COW NC vnode /usr/lib/librt.so.1 0x801a79000 0x801a7a000 1 0 0xffffff003721a750 r-x 1 0 0x2104 COW NNC vnode /usr/lib/librt.so.1 0x801a7a000 0x801b7a000 1 0 0xffffff000ab1e1a0 r-x 4 2 0x4 COW NC vnode /usr/lib/librt.so.1 0x801b7a000 0x801b7b000 1 0 0xffffff0033783d00 rw- 1 0 0x2104 COW NNC vnode /usr/lib/librt.so.1 0x801b7b000 0x801c60000 108 0 0xffffff0001c840d0 r-x 602 192 0x4 COW NC vnode /lib/libc.so.7 0x801c60000 0x801c61000 1 0 0xffffff001b2710d0 r-x 1 0 0x2104 COW NNC vnode /lib/libc.so.7 0x801c61000 0x801d60000 0 0 0xffffff0001c840d0 r-x 602 192 0x4 COW NC vnode /lib/libc.so.7 0x801d60000 0x801d7e000 30 0 0xffffff002277e340 rw- 1 0 0x2104 COW NNC vnode /lib/libc.so.7 0x801d7e000 0x801d94000 6 0 0xffffff0026ca3820 rw- 3 0 0x2104 NCOW NNC default - 0x801e00000 0x801f00000 41 0 0xffffff0026ca3820 rw- 3 0 0x2104 NCOW NNC default - 0x802000000 0x802300000 642 0 0xffffff0026ca3820 rw- 3 0 0x2104 NCOW NNC default - 0x7fffff9de000 0x7fffff9fe000 2 0 0xffffff002612bc30 rw- 1 0 0x2104 NCOW NNC default - 0x7fffffbdf000 0x7fffffbff000 2 0 0xffffff000d2cd8f0 rw- 1 0 0x2104 NCOW NNC default - 0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0 0 0x0 NCOW NNC none - 0x7ffffffe0000 0x800000000000 4 0 0xffffff0033d95680 rwx 1 0 0x2104 NCOW NNC default - ---- process virt. mem ---- > Also you could try doing as the error message suggests, and specify a > different address. e.g. > > ghci +RTS -xm30000000 > ghci +RTS -xm50000000 I tried different locations. mmap() always seems to return a address above 0x80000000, f.e. 0x801635000, where the -xm parameter seems to have no effect. If I sepecify a adress above 0x80000000 I get a message, that it has to be below 2GB. Thnx and regards Markus -------------- 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/20081203/1593f271/attachment.bin From igloo at earth.li Wed Dec 3 15:31:21 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Dec 3 15:24:43 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20081203203121.GA13500@matrix.chaos.earth.li> On Mon, Nov 24, 2008 at 12:28:28PM +0000, Simon Peyton-Jones wrote: > Ah hum. We probably have not compiled GHC 6.8 with 6.2 for some time. Worse, we don't even clearly document what the oldest version is that should bootstrap any given version. > > Ian: could you extend the building guide http://hackage.haskell.org/trac/ghc/wiki/Building (perhaps the "what tools you need" page?) with I've added something to http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites Thanks Ian From igloo at earth.li Wed Dec 3 18:11:13 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Dec 3 18:04:33 2008 Subject: Alex requirement for Setup.lhs In-Reply-To: <200812021356.03932.p.k.f.holzenspies@utwente.nl> References: <200812021356.03932.p.k.f.holzenspies@utwente.nl> Message-ID: <20081203231113.GA29910@matrix.chaos.earth.li> On Tue, Dec 02, 2008 at 01:56:03PM +0100, Philip K.F. H?lzenspies wrote: > > Setup.hs: alex is required but it could not be found. > > The problem is that I get this error also when I try to "runghc Setup.lhs > build" alex If you have downloaded the source tarball then the preprocessed files are included. Cabal may be getting confused by the .x files also being present, so rm src/Scan.x should fix it. You may also need to rm src/Parser.y if you don't have happy. Thanks Ian From marlowsd at gmail.com Thu Dec 4 04:09:06 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 4 04:02:29 2008 Subject: Weak pointers and STM In-Reply-To: <20081202142426.GB18561@sliver.repetae.net> References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com> <20081202142426.GB18561@sliver.repetae.net> Message-ID: <49379E32.8010703@gmail.com> John Meacham wrote: > Well, the actual problem I am trying to solve involves properly > reclaiming elements in a circularly linked list (next and prev pointers > are TVars). I have a linked list and I need to be able to remove values > from the list when all references to the node no longer exist, not > counting the linked list references themselves. > > Using Weak pointers inside the list itself doesn't work, since if an > element is collected, you also lose the information needed to stitch up > the list. > > Originally, I had a wacky plan involving weak pointers in the nodes > themselves pointing to sentinal nodes, when the sentinal was collected, > I then know I can delete the node. The idea was that I can lazily delete > entire chains of nodes rather than one by one. I gave up on that idea. > (deRefWeak not working in STM was sort of a show stopper, and it was > overly complicated) > > So now I have a scheme whereby I attach a finalizer to a proxy thunk. > > >> data TimeStamp = TimeStamp TS >> >> data TS = TS { >> tsWord :: TVar Word64, >> tsPrev :: TVar TS, >> tsNext :: TVar TS >> } > > so, the finalizer attached to 'TimeStamp' values simply deletes the > value it points to from the linked list. What you want here is to attach the finalizer to one of the TVars, probably tsWord. Attaching the finalizer to Timestamp is very risky: the compiler is free to optimise the Timestamp wrapper away, regardless of how much you hide in the module API. For example, consider an operation on Timestamp: once the operation has looked inside the Timestamp wrapper, it no longer holds a pointer to it, so the finalizer might run, even though the operation is still working on the TS. A function that is strict in Timestamp will have a worker that takes the unboxed TS, and might even re-wrap it in a new Timestamp (with no finalizer, of course). You can work around this using touch#, but that's a bit inelegant, and I'm not certain it solves all the problems. This is why we have mkWeakIORef and addMVarFinalizer - they attach finalizers to the primitive objects inside the IORef/MVar respectively, so you can be sure that compiler optimisations aren't going to affect the finalization properties you want. Adding finalizers to arbitrary objects was useful for the memo table application we had in mind when weak pointers were introduced, but for all the other applications I've come across since then, we really want to add finalizers to objects whose lifetimes are under programmer control. Notice how ForeignPtrs attach the finalizer carefully to the MutVar# inside the ForeignPtr, not the ForeignPtr itself. > The module interface ensures > that only 'TimeStamp' values can escape and each has a finalizer > attached. the interface is quite simple: > >> newTimeStamp :: IO TimeStamp >> insertAfter :: TimeStamp -> IO TimeStamp > > now, the problem is that I want to export insertAfter in the 'STM' > monad, not the IO one. however, I am not sure how to pull it off. I > cannot ensure the finalizer is only attached once to the node, if I use > 'unsafeIOToSTM' then STM retrying could end up created multiple finalized > nodes, possibly prematurely deleting the element from the linked list. > > basically, what would be really nice is if there were something like > >> registerCommitIO :: IO () -> STM () Yes, we ought to have this. As others have pointed out, you can do this by adding another monad on top of STM, but you can't really do registerRetry that way. > where all IO actions registered with this function (within an atomically > block) are executed exactly once if and only if the atomically block > commits. The IO action is not run within the STM block, notably > > atomically $ do foo; registerCommitIO bar; baz > > is equivalent to > > atomically (do foo; baz) >> bar > > > I found I needed the equivalent of 'touchForeignPtr' for arbitrary > objects (which I was able to do with the touch# primitive, but > >> touch :: a -> IO () >> touchSTM :: a -> STM () > > would both be at home in System.Mem.Weak. with appropriate caveats, of course! > While I am wishing for things, > >> unsafePerformSTM :: STM a -> a > > would be really handy too :) The trouble with that is that it can lead to nested transactions, and the RTS isn't set up to handle that. It's probably a fair bit of work. > insertAfter :: TimeStamp -> IO TimeStamp > insertAfter t@(TimeStamp ts) = do > (tts,ts) <- atomically $ insertAfter' ts > touchTS t > addFinalizer ts (deleteTimeStamp tts) > return ts ah, I see you're adding the finalizer to the TS, not the Timestamp. Same arguments apply, though. > touchTS :: TimeStamp -> IO () > touchTS ts = touchForeignPtr (unsafeCoerce# ts) *blink* that can't possibly work! Cheers, Simon From barney_stratford at fastmail.fm Thu Dec 4 08:23:33 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Thu Dec 4 08:16:51 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <20081203203121.GA13500@matrix.chaos.earth.li> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <20081203203121.GA13500@matrix.chaos.earth.li> Message-ID: <1228397013.1346.1288235643@webmail.messagingengine.com> I have a workaround for the linker bugs that keep popping up under Mac OS X, and now have a working GHC 6.8. I found that saying -fasm didn't help matters. Instead, on the assumption that the linker gets it wrong and there is in fact nothing wrong with the object file, I applied these two patches: diff -u a/compiler/Makefile b/compiler/Makefile --- a/compiler/Makefile Mon Dec 10 18:11:32 2007 +++ b/compiler/Makefile Wed Nov 26 09:35:12 2008 @@ -753,7 +753,7 @@ $(SED) -e "s@GHC_PATH@$(GHC_PATH)@g" -e "s@TOP_ABS@$(FPTOOLS_TOP_ABS)@g" < $< > $@ $(INPLACE_PROG): $(INPLACE_SRC) - $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ + $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ -optl "-Wl,-read_only_relocs,warning" all :: $(INPLACE_PROG) diff -u a/mk/target.mk b/mk/target.mk --- a/mk/target.mk Mon Dec 10 18:11:31 2007 +++ b/mk/target.mk Thu Nov 27 12:14:02 2008 @@ -231,7 +231,7 @@ ifneq "$(BootingFromHc)" "YES" $(HS_PROG) :: $(OBJS) - $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) + $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) -optl "-Wl,-read_only_relocs,warning" else # see bootstrap.mk $(HS_PROG) :: $(OBJS) Another way to fix these problems would be to mumble something about -segprot __TEXT rwx rwx, but this is definitely a hack. I also had to patch Cabal so it ranlibs the libraries it creates (which is required under Mac OS), and fixed the .hi-boot files in compiler/typecheck. (Shouldn't these be updated automatically?) Without those changes, the typechecker won't typecheck. Oh, the irony! Perhaps someone that knows more about how the build system works could figure out the right way to do these things. Barney. From p.k.f.holzenspies at utwente.nl Thu Dec 4 08:24:32 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Thu Dec 4 08:17:53 2008 Subject: Alex compilation fails on ambiguous type [was: Re: Alex requirement for Setup.lhs] In-Reply-To: <20081203231113.GA29910@matrix.chaos.earth.li> References: <200812021356.03932.p.k.f.holzenspies@utwente.nl> <20081203231113.GA29910@matrix.chaos.earth.li> Message-ID: <200812041424.33268.p.k.f.holzenspies@utwente.nl> On Thursday 04 December 2008 00:11:13 Ian Lynagh wrote: > If you have downloaded the source tarball then the preprocessed files > are included. Cabal may be getting confused by the .x files also being > present, so > rm src/Scan.x > should fix it. You may also need to > rm src/Parser.y > if you don't have happy. Dear Ian, all, Thank you for your tip, Ian. Deleting src/Scan.x did do the trick. However, I get a very strange type error when I try to compile alex 2.2. Maybe someone knows what's going on here: [16 of 16] Compiling Main ( src/Main.hs, dist/build/alex/alex-tmp/Main.o ) src/Main.hs:316:25: Ambiguous type variable `e' in the constraint: `GHC.Exception.Exception e' arising from a use of `throw' at src/Main.hs:316:25-31 Probable fix: add a type signature that fixes these type variable(s) Lines 314 through 316 in src/Main.hs are: r <- Exception.catch (unblock (thing a)) (\e -> do { after a; throw e }) I guess the error in itself makes some sense, because throw can not be resolved without knowing a concrete instance of e. I just don't get why I get this error in a release version of alex; I would imagine other people do not get this error. What am I missing? Regards, Philip From p.k.f.holzenspies at utwente.nl Thu Dec 4 08:39:49 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Thu Dec 4 08:33:09 2008 Subject: Alex compilation fails on ambiguous type [was: Re: Alex requirement for Setup.lhs] In-Reply-To: <200812041424.33268.p.k.f.holzenspies@utwente.nl> References: <200812021356.03932.p.k.f.holzenspies@utwente.nl> <20081203231113.GA29910@matrix.chaos.earth.li> <200812041424.33268.p.k.f.holzenspies@utwente.nl> Message-ID: <200812041439.49530.p.k.f.holzenspies@utwente.nl> On Thursday 04 December 2008 14:24:32 Philip K.F. H?lzenspies wrote: > [16 of 16] Compiling Main ( src/Main.hs, > dist/build/alex/alex-tmp/Main.o ) > > src/Main.hs:316:25: > Ambiguous type variable `e' in the constraint: > `GHC.Exception.Exception e' > arising from a use of `throw' at src/Main.hs:316:25-31 > Probable fix: add a type signature that fixes these type variable(s) > > Lines 314 through 316 in src/Main.hs are: > > r <- Exception.catch > (unblock (thing a)) > (\e -> do { after a; throw e }) > > I guess the error in itself makes some sense, because throw can not be > resolved without knowing a concrete instance of e. I just don't get why I > get this error in a release version of alex; I would imagine other people > do not get this error. What am I missing? Dear Ian, all, Please ignore my previous e-mail. It must have been a remainder from an earlier failed build attempt. I just did a checkout from the alex darcs repository, which built without a hitch. Regards, Philip From jpm at cs.uu.nl Thu Dec 4 08:57:56 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Dec 4 08:51:17 2008 Subject: Type checker loops with type families, overlapping and undecidable instances Message-ID: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> Hello all, Please consider the following code: {-# OPTIONS -Wall #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE OverlappingInstances #-} > {-# LANGUAGE UndecidableInstances #-} > > module Test where > > -- Some view > class Viewable a where > type View a > to :: a -> View a > > -- Structural representations > data Unit = Unit > data a :+: b = L a | R b > > instance Viewable Unit where > type View Unit = Unit > to = id > > instance (Viewable a, Viewable b) => Viewable (a :+: b) where > type View (a :+: b) = a :+: b > to = id > > -- Worker class > class F' a where > f' :: a -> () > > instance F' Unit where > f' Unit = () > > instance (F a, F b) => F' (a :+: b) where > f' (L x) = f x > f' (R x) = f x > > > -- Dispatcher class > class (Viewable a, F' (View a)) => F a where > f :: a -> () > f = f' . to > > instance F Unit where > f = f' > > instance (F a, F b) => F (a :+: b) where > f = f' > > -- All generic instances > instance (Viewable a, F' (View a)) => F a > > > -- A recursive datatype > data Nat = Zero | Succ Nat > > -- Instance of Viewable > instance Viewable Nat where > type View Nat = Unit :+: Nat > to = undefined > > -- Uncommenting the line below causes the typechecker to loop (GHC 6.10.1, > Windows) > --test = f Zero > Is this expected behavior or a bug? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081204/7a63d621/attachment.htm From lennart at augustsson.net Thu Dec 4 09:10:38 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Dec 4 09:05:45 2008 Subject: Type checker loops with type families, overlapping and undecidable instances In-Reply-To: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> References: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> Message-ID: Turning on UndecidableInstances is the same as saying: OK typechcker, you can loop if I make a mistake. I've not looked closely at your code, but if you turn on that flag, looping is probably not a bug. -- Lennart 2008/12/4 Jos? Pedro Magalh?es : > Hello all, > > Please consider the following code: > >> {-# OPTIONS -Wall #-} >> {-# LANGUAGE FlexibleContexts #-} >> {-# LANGUAGE FlexibleInstances #-} >> {-# LANGUAGE TypeOperators #-} >> {-# LANGUAGE TypeFamilies #-} >> {-# LANGUAGE OverlappingInstances #-} >> {-# LANGUAGE UndecidableInstances #-} >> >> module Test where >> >> -- Some view >> class Viewable a where >> type View a >> to :: a -> View a >> >> -- Structural representations >> data Unit = Unit >> data a :+: b = L a | R b >> >> instance Viewable Unit where >> type View Unit = Unit >> to = id >> >> instance (Viewable a, Viewable b) => Viewable (a :+: b) where >> type View (a :+: b) = a :+: b >> to = id >> >> -- Worker class >> class F' a where >> f' :: a -> () >> >> instance F' Unit where >> f' Unit = () >> >> instance (F a, F b) => F' (a :+: b) where >> f' (L x) = f x >> f' (R x) = f x >> >> >> -- Dispatcher class >> class (Viewable a, F' (View a)) => F a where >> f :: a -> () >> f = f' . to >> >> instance F Unit where >> f = f' >> >> instance (F a, F b) => F (a :+: b) where >> f = f' >> >> -- All generic instances >> instance (Viewable a, F' (View a)) => F a >> >> >> -- A recursive datatype >> data Nat = Zero | Succ Nat >> >> -- Instance of Viewable >> instance Viewable Nat where >> type View Nat = Unit :+: Nat >> to = undefined >> >> -- Uncommenting the line below causes the typechecker to loop (GHC 6.10.1, >> Windows) >> --test = f Zero > > > Is this expected behavior or a bug? > > > Thanks, > Pedro > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From jpm at cs.uu.nl Thu Dec 4 09:13:37 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Dec 4 09:06:57 2008 Subject: Type checker loops with type families, overlapping and undecidable instances In-Reply-To: References: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> Message-ID: <52f14b210812040613m48898598kf99daa459e3416ed@mail.gmail.com> Hello Lennart, Yes, but according to the manual ( http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#undecidable-instances), "Termination is ensured by having a fixed-depth recursion stack". So I would expect at least termination, which I'm not getting (but I guess that can be due to the type families). Thanks, Pedro On Thu, Dec 4, 2008 at 15:10, Lennart Augustsson wrote: > Turning on UndecidableInstances is the same as saying: OK typechcker, > you can loop if I make a mistake. > I've not looked closely at your code, but if you turn on that flag, > looping is probably not a bug. > > -- Lennart > > 2008/12/4 Jos? Pedro Magalh?es : > > Hello all, > > > > Please consider the following code: > > > >> {-# OPTIONS -Wall #-} > >> {-# LANGUAGE FlexibleContexts #-} > >> {-# LANGUAGE FlexibleInstances #-} > >> {-# LANGUAGE TypeOperators #-} > >> {-# LANGUAGE TypeFamilies #-} > >> {-# LANGUAGE OverlappingInstances #-} > >> {-# LANGUAGE UndecidableInstances #-} > >> > >> module Test where > >> > >> -- Some view > >> class Viewable a where > >> type View a > >> to :: a -> View a > >> > >> -- Structural representations > >> data Unit = Unit > >> data a :+: b = L a | R b > >> > >> instance Viewable Unit where > >> type View Unit = Unit > >> to = id > >> > >> instance (Viewable a, Viewable b) => Viewable (a :+: b) where > >> type View (a :+: b) = a :+: b > >> to = id > >> > >> -- Worker class > >> class F' a where > >> f' :: a -> () > >> > >> instance F' Unit where > >> f' Unit = () > >> > >> instance (F a, F b) => F' (a :+: b) where > >> f' (L x) = f x > >> f' (R x) = f x > >> > >> > >> -- Dispatcher class > >> class (Viewable a, F' (View a)) => F a where > >> f :: a -> () > >> f = f' . to > >> > >> instance F Unit where > >> f = f' > >> > >> instance (F a, F b) => F (a :+: b) where > >> f = f' > >> > >> -- All generic instances > >> instance (Viewable a, F' (View a)) => F a > >> > >> > >> -- A recursive datatype > >> data Nat = Zero | Succ Nat > >> > >> -- Instance of Viewable > >> instance Viewable Nat where > >> type View Nat = Unit :+: Nat > >> to = undefined > >> > >> -- Uncommenting the line below causes the typechecker to loop (GHC > 6.10.1, > >> Windows) > >> --test = f Zero > > > > > > Is this expected behavior or a bug? > > > > > > Thanks, > > Pedro > > > > _______________________________________________ > > 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/20081204/46b909c1/attachment.htm From Tom.Schrijvers at cs.kuleuven.be Thu Dec 4 09:19:02 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Dec 4 09:13:26 2008 Subject: Type checker loops with type families, overlapping and undecidable instances In-Reply-To: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> References: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> Message-ID: >> -- Uncommenting the line below causes the typechecker to loop (GHC 6.10.1, >> Windows) >> --test = f Zero > > Is this expected behavior or a bug? The call f Zero requires a co-inductive proof of the type class constraint (F Nat): F Nat <=> Vieweable Nat /\ F' (View Nat) <=> True /\ F' (Unit :+: Nat) <=> True /\ F Unit /\ F Nat <=> True /\ True /\ F Nat The type checker does have functionality for such co-inductive proof (generating co-inductive dictionaries), but apparently it's not kicking in here. Probably because of the separate fixedpoint loops for type classes and type families in the checker. -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From wchogg at gmail.com Thu Dec 4 14:06:52 2008 From: wchogg at gmail.com (Creighton Hogg) Date: Thu Dec 4 14:00:10 2008 Subject: hsc2hs problem Message-ID: <814617240812041106maccaa81h2b0760180389e0d4@mail.gmail.com> Hello, Since hsc2hs is distributed with GHC, I thought this might be a decent place to ask. I tried to run hsc2hs on a file that I know worked with my 6.8.3 installation, but now I'm getting the error /usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: HsFFI.h: No such file or directory Thanks, Creighton From wchogg at gmail.com Thu Dec 4 17:57:41 2008 From: wchogg at gmail.com (Creighton Hogg) Date: Thu Dec 4 17:50:59 2008 Subject: hsc2hs problem In-Reply-To: <814617240812041106maccaa81h2b0760180389e0d4@mail.gmail.com> References: <814617240812041106maccaa81h2b0760180389e0d4@mail.gmail.com> Message-ID: <814617240812041457g31747960waba7c5cc26a6ca73@mail.gmail.com> Ah, just to reply to myself the problem was rather simple: hsc2hs couldn't find any of the header files in the ghc/include directory. It was easy enough to fix that, but it was weird that installing ghc didn't take of that for me. Especially since I never had this problem with previous versions. Cheers, Creighton On Thu, Dec 4, 2008 at 1:06 PM, Creighton Hogg wrote: > Hello, > Since hsc2hs is distributed with GHC, I thought this might be a decent > place to ask. I tried to run hsc2hs on a file that I know worked with > my 6.8.3 installation, but now I'm getting the error > /usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: > HsFFI.h: No such file or directory > > Thanks, > Creighton > From petersen at haskell.org Fri Dec 5 03:07:19 2008 From: petersen at haskell.org (Jens Petersen) Date: Fri Dec 5 03:00:35 2008 Subject: ghc-paths Message-ID: <9436bffe0812050007g69de7eava3151514ee915515@mail.gmail.com> Are there any plans to include ghc-paths in ghc itself? Jens From duncan.coutts at worc.ox.ac.uk Fri Dec 5 10:49:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Dec 5 10:42:34 2008 Subject: hsc2hs problem In-Reply-To: <814617240812041106maccaa81h2b0760180389e0d4@mail.gmail.com> References: <814617240812041106maccaa81h2b0760180389e0d4@mail.gmail.com> Message-ID: <1228492151.10115.281.camel@localhost> On Thu, 2008-12-04 at 13:06 -0600, Creighton Hogg wrote: > Hello, > Since hsc2hs is distributed with GHC, I thought this might be a decent > place to ask. I tried to run hsc2hs on a file that I know worked with > my 6.8.3 installation, but now I'm getting the error > /usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: > HsFFI.h: No such file or directory Unfortunately the hsc2hs instance is specific to one ghc version. You've presumably got ghc-6.8.3 and ghc-6.10.1 installed. You're building stuff using ghc-6.8.3 but the hsc2hs from ghc-6.10.1 and so hsc2hs is getting passed the wrong include paths. If you use the hsc2hs from the ghc-6.8.3 installation then it should work. We should look into making it more independent of the ghc version. Duncan From wchogg at gmail.com Fri Dec 5 11:05:39 2008 From: wchogg at gmail.com (Creighton Hogg) Date: Fri Dec 5 10:58:54 2008 Subject: hsc2hs problem In-Reply-To: <1228492151.10115.281.camel@localhost> References: <814617240812041106maccaa81h2b0760180389e0d4@mail.gmail.com> <1228492151.10115.281.camel@localhost> Message-ID: <814617240812050805j7b7d5401q314a25be7302a00e@mail.gmail.com> On Fri, Dec 5, 2008 at 9:49 AM, Duncan Coutts wrote: > On Thu, 2008-12-04 at 13:06 -0600, Creighton Hogg wrote: >> Hello, >> Since hsc2hs is distributed with GHC, I thought this might be a decent >> place to ask. I tried to run hsc2hs on a file that I know worked with >> my 6.8.3 installation, but now I'm getting the error >> /usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: >> HsFFI.h: No such file or directory > > Unfortunately the hsc2hs instance is specific to one ghc version. You've > presumably got ghc-6.8.3 and ghc-6.10.1 installed. You're building stuff > using ghc-6.8.3 but the hsc2hs from ghc-6.10.1 and so hsc2hs is getting > passed the wrong include paths. If you use the hsc2hs from the ghc-6.8.3 > installation then it should work. > > We should look into making it more independent of the ghc version. Funny you'd mention this! I was worried that this was the problem, so I cleaned out all my ghc instances & then reinstalled ghc 6.10.1 from the binaries. I still had the same problem after that. Perhaps something was still lingering? I'm not sure what, though. Cheers, Creighton From p.k.f.holzenspies at utwente.nl Fri Dec 5 11:07:17 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?utf-8?q?H=C3=B6lzenspies?=) Date: Fri Dec 5 11:00:35 2008 Subject: Future kind system, closed type functions and type classes Message-ID: <200812051707.18094.p.k.f.holzenspies@utwente.nl> Dear all, My apologies for the lengthy mail. There is a question at the end about whether all types in (of?) a kind closed under a type function can be concluded to be a member of a type class (i.e. whether kind classes are required for what I want to do). I have been trying to reserect Robert Dockins' TypeNats library [1], by pulling it out of the type classes / functional dependencies space and into the type family space. The current (discontinued) TypeNats has one Very Nice Thing to it; naturals are coded as bits, rather than as plain successors. Length annotations of vectors et al. now have a memory complexity of O(lg N) as opposed to O(N). A na?ve implementation attempt runs into a rather obvious problem: data Z data I n data O n class Natural n where type Pred n toIntegral :: Integral i => n -> i toPred :: Natural n => n -> Pred n toPred _ = undefined instance Natural Z where type Pred Z = Z toIntegral _ = 0 instance Natural (I n) where type Pred (I n) = O n toIntegral n = let i = toIntegral (toPred n) in succ (i+i) instance Natural (O n) where type Pred (O n) = I (Pred n) toIntegral n = let i = toIntegral (toPred n) in i+i This should be interpreted as follows: Z denotes the empty bit string. I denotes a 1 and O denotes a 0. The bits are in reversed order, so 6 is coded as O(I(I Z)). One would expect the instance declaration of O to require a context "Natural n," because of "Pred n" and "toPred n," but the type checker allows for this. As a matter of fact, introducing the context "Natural n" to both the instance declarations of I and O raises the error: Could not deduce (Natural (Pred n)) from the context (Integral a) arising from a use of `natToIntegral' (in the instance declaration of O n) Leaving the context out, this implementation causes stack overflows when evaluating "toIntegral (undefined :: I Z)", because (O Z) is not reduced to Z. The FD solution is to introduce a class that describes the "canonical form" of a bit string (where the canonical form of O Z is Z): class Canonical n cfunctions for Haskell Tom Schrijv | n -> c Since we now have type functions, we can express this in a considerably more comprehensive manner. We can simply write: type family CanonicalNat c type family CanonicalNat_ c type instance CanonicalNat Z = Z type instance CanonicalNat (I n) = I (CanonicalNat n) type instance CanonicalNat (O n) = CanonicalNat_ (O (CanonicalNat n)) type instance CanonicalNat_ (O Z) = Z type instance CanonicalNat_ (O (O n)) = O (O n) type instance CanonicalNat_ (O (I n)) = O (I n) With the type function CanonicalNat, toPred can now be redefined to give a predecessor of a canonical type: toPred :: Natural n => n -> CanonicalNat (Pred n) toPred _ = undefined Unfortunately: Could not deduce (Natural (CanonicalNat_ (O (CanonicalNat n)))) from the context (Integral a) arising from a use of `natToIntegral' Adding a context to the definitions of I and O, viz. data Natural n => I n data Natural n => O n doesn't help very much. I'm no inference expert, but it seems that the problem is that inference goes up, not down (or vice versa, depending on how you interpret these words). Also, adding contexts to the results of type functions is a non-trivial thing [2]). In Schrijvers et al. [3], it is mentioned that work is being undertaken in the direction of closed type functions by using kind declarations. For this example, this would look something like: datakind NatNum = Z | I NatNum | O NatNum and type family CanonicalNat (c :: NatNum) :: NatNum Ideas for a new kind system for GHC is discussed on the wiki [4]. The interaction with type classes section shows this example (for Z/Succ represented Peano numbers): data kind Nat = Zero | Succ Nat class LessThanOrEqual (n1 :: Nat) (n2 :: Nat) instance LessThanOrEqual Zero Zero instance LessThanOrEqual n m => LessThanOrEqual n (Succ m) Aside from the fact that I would imagine that there is a missing case here instance LessThanOrEqual n m => LessThanOrEqual (Succ n) (Succ m) which is non-trivial because of the overlap with the second instance declaration, it is hard for me to see whether a checker with this new kind system could decide that all types in Nat have corresponding instances in LessThanOrEqual. It should be clear how this relates to my case described above; can it now be decided that the result of CanonicalNat will always have an instance of the Natural class? Regards, Philip PS. A possible purpose of a function such as toIntegral is to have a length implementation for fixed-length lists that is more lazy than the length function on a list, but that can be used in exactly the same way. [1] http://www.cs.princeton.edu/~rdockins/dist/typenats-0.2-source.tar.gz [2] http://content.ohsu.edu/cgi-bin/showfile.exe?CISOROOT=/etd&CISOPTR=227&filename=7031321462007_200705.diatchki.iavor.pdf [3] http://research.microsoft.com/~simonpj/papers/assoc-types/ifl2007.pdf [4] http://hackage.haskell.org/trac/ghc/wiki/KindSystem From duncan.coutts at worc.ox.ac.uk Fri Dec 5 15:14:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Dec 5 15:07:40 2008 Subject: hsc2hs problem In-Reply-To: <814617240812050805j7b7d5401q314a25be7302a00e@mail.gmail.com> References: <814617240812041106maccaa81h2b0760180389e0d4@mail.gmail.com> <1228492151.10115.281.camel@localhost> <814617240812050805j7b7d5401q314a25be7302a00e@mail.gmail.com> Message-ID: <1228508060.10115.319.camel@localhost> On Fri, 2008-12-05 at 10:05 -0600, Creighton Hogg wrote: > On Fri, Dec 5, 2008 at 9:49 AM, Duncan Coutts > wrote: > > On Thu, 2008-12-04 at 13:06 -0600, Creighton Hogg wrote: > >> Hello, > >> Since hsc2hs is distributed with GHC, I thought this might be a decent > >> place to ask. I tried to run hsc2hs on a file that I know worked with > >> my 6.8.3 installation, but now I'm getting the error > >> /usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: > >> HsFFI.h: No such file or directory > > > > Unfortunately the hsc2hs instance is specific to one ghc version. You've > > presumably got ghc-6.8.3 and ghc-6.10.1 installed. You're building stuff > > using ghc-6.8.3 but the hsc2hs from ghc-6.10.1 and so hsc2hs is getting > > passed the wrong include paths. If you use the hsc2hs from the ghc-6.8.3 > > installation then it should work. > > > > We should look into making it more independent of the ghc version. > > Funny you'd mention this! I was worried that this was the problem, so > I cleaned out all my ghc instances & then reinstalled ghc 6.10.1 from > the binaries. I still had the same problem after that. Perhaps > something was still lingering? I'm not sure what, though. So it turns out that it does indeed fail by default. The reason nobody else noticed is because they do not run it directly. They run it via Cabal and it passes a load of extra flags, all the include dirs for all the packages a package depends on. This of course includes the base and rts packages. It's the rts package that has the HsFFI.h file. So the problem is that hsc2hs by default uses gcc as it's C compiler but the default template #includes HsFFI.h. These two things are in conflict. I wonder why the default template does include HsFFI.h since it appears that nothing in the template uses anything from it. The hsc2hs tool is supposed to be independent of the haskell implementation. It is supposed to work with hugs and nhc too. Hugs comes with hsc2hs too and it's template-hsc.h also uses HsFFI.h. It's not clear to me how it finds the hugs/include/HsFFI.h file by default. Duncan From tomasz.zielonka at gmail.com Sat Dec 6 14:52:39 2008 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Sat Dec 6 14:45:52 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <45E6FD99.1090802@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> Message-ID: <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> On Thu, Mar 1, 2007 at 5:21 PM, Simon Marlow wrote: > In fact you should think of the non-threaded RTS as deprecated. It isn't > Haskell'-compliant, for one thing (assuming that Haskell' will probably > require non-blocking foreign calls). > > I'm hesitant to actually deprecate it, for a few reasons: the threaded RTS > is so much more complicated, it might have some adverse performance > impliciations, and there are still people who want to run everything in a > single OS thread, for whatever reason. But having multiple variants of the > RTS is a maintenance and testing headache. Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, especially if one of them will be much less used and tested. Best regards Tomasz From twanvl at gmail.com Sat Dec 6 20:22:28 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Sat Dec 6 20:15:30 2008 Subject: Deriving Functor Message-ID: <493B2554.1040109@gmail.com> Hello Ghc people, I have been working on adding support for "derive Functor" to ghc. I have a patch that mostly works, but there are some problems: 1. Ghc reports the correct instance when I use -ddump-deriv:, but that instance is not subsequenctly used. Instead I get a warning like: Warning: No explicit method nor default method for `fmap' In the instance declaration for `Functor (Cont r)' What could be going on here? The full output is attached. 2. As far as I understand the code, there would need to be three traversals of a data type T to derive an instance Functor T: - First to determine whether the deriving should be allowed at all (checkSideConditions) - Then to determine the constraints needed (mk_data_eqn) - Finally to make the body of the instance (gen_Functor_binds) This seems a bit redundant, and currently the code only does the last pass. It would make more sense to report any errors during this pass as well. I don't understand how the constraints are determined in TcDeriv, for instance for the type data T1 a b c = T1 a deriving (Eq) it seems as if Eq constraints are added for all of {a,b,c}, but somehow only a constraint Eq a ends up in the final instance. How does that work? The (experimental) patch was too large to attach, it can be found at http://twan.home.fmf.nl/files/deriv-functor-experimental1.patch.gz By the way: is there any advantage (besides readability) to generating the code "fmap f" instead of "\x -> fmap f x"? Twan -------------- next part -------------- E:\Dev\ghc\ghc-head3\testsuite\tests\ghc-regress\deriving\should_run>e:\dev\ghc\ghc-head3\ghc\stage1-inplace\ghc -c drvrun-functor2.hs -fforce-recomp -ddump-deriv ==================== Derived instances ==================== InstInfo: forall r_aff. GHC.Base.Functor (Main.Cont r_aff) { GHC.Base.fmap f_afU (Main.Cont a1_afW) = Main.Cont (\ b1_afY -> a1_afW (\ b2_ag0 -> b1_afY (f_afU b2_ag0))) } InstInfo: forall r_afj w_afk. GHC.Base.Functor (Main.ReaderWriter r_afj w_afk) { GHC.Base.fmap f_ag4 (Main.RW a1_ag6) = Main.RW (\ b1_ag8 -> case a1_ag6 b1_ag8 of { ((a1_aga, a2_agc)) -> (f_ag4 a1_aga, a2_agc) }) } drvrun-functor2.hs:8:14: Warning: No explicit method nor default method for `fmap' In the instance declaration for `Functor (ReaderWriter r w)' drvrun-functor2.hs:11:14: Warning: No explicit method nor default method for `fmap' In the instance declaration for `Functor (Cont r)' -------------- next part -------------- A non-text attachment was scrubbed... Name: drvrun-functor2.hs Type: text/x-haskell Size: 520 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081207/8124b00d/drvrun-functor2.bin From bulat.ziganshin at gmail.com Sun Dec 7 04:29:34 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Dec 7 04:27:01 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> Message-ID: <167713711.20081207122934@gmail.com> Hello Tomasz, Saturday, December 6, 2008, 10:52:39 PM, you wrote: > Had you deprecated the non-threaded RTS, we would probably have no problems > described in ticket #2848 :-/ > I think you'll have to deprecate it anyway, because it will be more > and more difficult > to maintain two versions of code, especially if one of them will be > much less used and > tested. we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From john at repetae.net Sun Dec 7 06:15:11 2008 From: john at repetae.net (John Meacham) Date: Sun Dec 7 06:08:25 2008 Subject: Weak pointers and STM In-Reply-To: <49379E32.8010703@gmail.com> References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com> <20081202142426.GB18561@sliver.repetae.net> <49379E32.8010703@gmail.com> Message-ID: <20081207111511.GJ18561@sliver.repetae.net> On Thu, Dec 04, 2008 at 09:09:06AM +0000, Simon Marlow wrote: >> So now I have a scheme whereby I attach a finalizer to a proxy thunk. >> >> >>> data TimeStamp = TimeStamp TS >>> >>> data TS = TS { >>> tsWord :: TVar Word64, >>> tsPrev :: TVar TS, >>> tsNext :: TVar TS >>> } >> >> so, the finalizer attached to 'TimeStamp' values simply deletes the >> value it points to from the linked list. > > What you want here is to attach the finalizer to one of the TVars, > probably tsWord. Attaching the finalizer to Timestamp is very risky: the > compiler is free to optimise the Timestamp wrapper away, regardless of > how much you hide in the module API. For example, consider an operation > on Timestamp: once the operation has looked inside the Timestamp wrapper, > it no longer holds a pointer to it, so the finalizer might run, even > though the operation is still working on the TS. A function that is > strict in Timestamp will have a worker that takes the unboxed TS, and > might even re-wrap it in a new Timestamp (with no finalizer, of course). but wouldn't a finalizer attached to any of these TVar's never run since they are all references from the circularly linked list? I am not quite sure where you are advocating adding the finalizer. >> While I am wishing for things, >> >>> unsafePerformSTM :: STM a -> a >> >> would be really handy too :) > > The trouble with that is that it can lead to nested transactions, and the > RTS isn't set up to handle that. It's probably a fair bit of work. Yeah I was thinking that when you came across an usafePerformSTM inside another transaction, you would abort the current transaction, evaluate the unsafePerformSTM (memoizing the result) then retry the original transaction. though.. that doesn't cover every case.. > > insertAfter :: TimeStamp -> IO TimeStamp > > insertAfter t@(TimeStamp ts) = do > > (tts,ts) <- atomically $ insertAfter' ts > > touchTS t > > addFinalizer ts (deleteTimeStamp tts) > > return ts > > ah, I see you're adding the finalizer to the TS, not the Timestamp. Same > arguments apply, though. > > > > touchTS :: TimeStamp -> IO () > > touchTS ts = touchForeignPtr (unsafeCoerce# ts) > > *blink* that can't possibly work! It seems to, but that may just be pure accident. I couldn't seem to find where the data constructor for constructing IO actions from wandered too so just threw that in there as a hack while testing. yeah, it should be a properly wrapped touch#. John -- John Meacham - ?repetae.net?john? From claus.reinke at talk21.com Sun Dec 7 07:12:46 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Dec 7 07:06:00 2008 Subject: Weak pointers and STM References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com><20081202142426.GB18561@sliver.repetae.net> <49379E32.8010703@gmail.com> Message-ID: > Adding finalizers to arbitrary objects was useful for the memo table > application we had in mind when weak pointers were introduced, but for all > the other applications I've come across since then, we really want to add > finalizers to objects whose lifetimes are under programmer control. Notice > how ForeignPtrs attach the finalizer carefully to the MutVar# inside the > ForeignPtr, not the ForeignPtr itself. One application that was effectively killed by GHC's approach to finalizers was GHood (I lost interest when it became apparent that GHC was moving away from giving any kinds of guarantees about finalizers). The idea was that, just as unsafePerformIO gives us a way to instrument the evaluator, so finalizers could have given us a way to instrument garbage collection. Then GHood could not only have shown when which parts of which structure are first observed (how and when structures get unfolded) but also (roughly) when which parts of which structure become unreachable (how and when structures disappear again). That would have made a very nice tool. But it would have needed finalizers on arbitrary objects that are actually guaranteed to be run, preferably promptly, but not early. Given the application, I would have considered wrapping/annotating those objects in some transparent way, not visible to the original program, but forcing the memory manager to keep track of that object even if that means worse code. Only that there are no guarantees whatsoever on these finalizers anymore (there were some back then, but it emerged that they weren't backed up by the implementation). Which also hurts other, table-like, applications: I have an application where I need to keep track of synchronous communication channels, basically: advance each live channel at every step. Now, I would like to attach finalizers to the channels, so that when there are no more threads having references to a channel, the channel gets removed from the tracking table. But without finalizer guarantees, there is no guarantee that the table will not simply keep accumulating more and more of those dynamically created channels.. I, for one, would like to have good support for "adding finalizers to arbitrary objects with useful run guarantees". Actually, it is a bit hard to understand what finalizers without any guarantees (System.Mem.Weak) are supposed to achieve? Claus From chak at cse.unsw.edu.au Sun Dec 7 19:51:34 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Dec 7 19:44:58 2008 Subject: Type checker loops with type families, overlapping and undecidable instances In-Reply-To: <52f14b210812040613m48898598kf99daa459e3416ed@mail.gmail.com> References: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> <52f14b210812040613m48898598kf99daa459e3416ed@mail.gmail.com> Message-ID: <73E09C74-DBCB-4799-A60B-2DFB4105950D@cse.unsw.edu.au> As Lennart wrote, with UndecideableInstances all bets are off. Concerning the fixed-depth recursion stack. It is currently only used for the simplification of class instance declarations, but if improvement rules are involved (either FDs or TFs) that check will not catch all cases anyway. The interaction between solving class constraints and equalities with type families is currently rather ad hoc. We are currently re- designing that interaction and may then make the fixed-depth restriction more broadly applicable. However, as Tom already mentioned, the cycle does not involve type families in your example anyway. Manuel Jos? Pedro Magalh?es: > Hello Lennart, > > Yes, but according to the manual (http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#undecidable-instances > ), "Termination is ensured by having a fixed-depth recursion stack". > So I would expect at least termination, which I'm not getting (but I > guess that can be due to the type families). > > > Thanks, > Pedro > > On Thu, Dec 4, 2008 at 15:10, Lennart Augustsson > wrote: > Turning on UndecidableInstances is the same as saying: OK typechcker, > you can loop if I make a mistake. > I've not looked closely at your code, but if you turn on that flag, > looping is probably not a bug. > > -- Lennart > > 2008/12/4 Jos? Pedro Magalh?es : > > Hello all, > > > > Please consider the following code: > > > >> {-# OPTIONS -Wall #-} > >> {-# LANGUAGE FlexibleContexts #-} > >> {-# LANGUAGE FlexibleInstances #-} > >> {-# LANGUAGE TypeOperators #-} > >> {-# LANGUAGE TypeFamilies #-} > >> {-# LANGUAGE OverlappingInstances #-} > >> {-# LANGUAGE UndecidableInstances #-} > >> > >> module Test where > >> > >> -- Some view > >> class Viewable a where > >> type View a > >> to :: a -> View a > >> > >> -- Structural representations > >> data Unit = Unit > >> data a :+: b = L a | R b > >> > >> instance Viewable Unit where > >> type View Unit = Unit > >> to = id > >> > >> instance (Viewable a, Viewable b) => Viewable (a :+: b) where > >> type View (a :+: b) = a :+: b > >> to = id > >> > >> -- Worker class > >> class F' a where > >> f' :: a -> () > >> > >> instance F' Unit where > >> f' Unit = () > >> > >> instance (F a, F b) => F' (a :+: b) where > >> f' (L x) = f x > >> f' (R x) = f x > >> > >> > >> -- Dispatcher class > >> class (Viewable a, F' (View a)) => F a where > >> f :: a -> () > >> f = f' . to > >> > >> instance F Unit where > >> f = f' > >> > >> instance (F a, F b) => F (a :+: b) where > >> f = f' > >> > >> -- All generic instances > >> instance (Viewable a, F' (View a)) => F a > >> > >> > >> -- A recursive datatype > >> data Nat = Zero | Succ Nat > >> > >> -- Instance of Viewable > >> instance Viewable Nat where > >> type View Nat = Unit :+: Nat > >> to = undefined > >> > >> -- Uncommenting the line below causes the typechecker to loop > (GHC 6.10.1, > >> Windows) > >> --test = f Zero > > > > > > Is this expected behavior or a bug? > > > > > > Thanks, > > Pedro > > > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081208/7b9df5cc/attachment.htm From marlowsd at gmail.com Mon Dec 8 04:59:54 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 8 04:53:06 2008 Subject: Weak pointers and STM In-Reply-To: References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com><20081202142426.GB18561@sliver.repetae.net> <49379E32.8010703@gmail.com> Message-ID: <493CF01A.6030302@gmail.com> Lennart Augustsson wrote: > Finalizers without guarantees, like what ghc implements, are totally > useless. Since there is no guarantee that the finalizer will ever run > attaching one is a no-op. It has bitten me several times. I wish ghc > implemented finalizers according to the ffi spec. We do plan to do that (I'm sure you're aware of bug #1364), however I'm sure you're also aware that GHC's finalizers are more general than the FFI spec requires in that finalizers can be Haskell computations, and it is this that leads to the lack of guarantees. Implementing the FFI-style finalizers requires us to treat C finalizers as a special case, rather than implementing them as foreign calls from Haskell finalizers, which is a bit of a pain. I disagree that finalizers are completely useless. They're just not useful for some of the things you might like them to be useful for, like guaranteed resource reclamation. > -- Lennart (iPhone) Cheers, Simon (MS natural keyboard and 28" LCD screen) > On Dec 7, 2008, at 13:12, "Claus Reinke" wrote: > >>> Adding finalizers to arbitrary objects was useful for the memo table >>> application we had in mind when weak pointers were introduced, but >>> for all the other applications I've come across since then, we really >>> want to add finalizers to objects whose lifetimes are under >>> programmer control. Notice how ForeignPtrs attach the finalizer >>> carefully to the MutVar# inside the ForeignPtr, not the ForeignPtr >>> itself. >> >> One application that was effectively killed by GHC's approach to >> finalizers was GHood (I lost interest when it became apparent that >> GHC was moving away from giving any kinds of guarantees about >> finalizers). The idea was that, just as unsafePerformIO gives us a >> way to instrument the evaluator, so finalizers could have given us a >> way to instrument garbage collection. Then GHood could not only >> have shown when which parts of which structure are first observed >> (how and when structures get unfolded) but also (roughly) when which >> parts of which structure become unreachable (how and when >> structures disappear again). That would have made a very nice tool. >> >> But it would have needed finalizers on arbitrary objects that are >> actually guaranteed to be run, preferably promptly, but not early. >> Given the application, I would have considered wrapping/annotating >> those objects in some transparent way, not visible to the original >> program, but forcing the memory manager to keep track of that object >> even if that means worse code. Only that there are no guarantees >> whatsoever on these finalizers anymore (there were some back then, but >> it emerged that they weren't backed up by the implementation). >> Which also hurts other, table-like, applications: I have an >> application where I need to keep track of synchronous communication >> channels, basically: advance each live channel at every step. Now, I >> would like to attach finalizers to the channels, so that when there >> are no more threads having references to a channel, the channel gets >> removed >> from the tracking table. But without finalizer guarantees, there is no >> guarantee that the table will not simply keep accumulating more and >> more of those dynamically created channels.. >> >> I, for one, would like to have good support for "adding finalizers to >> arbitrary objects with useful run guarantees". Actually, it is a bit hard >> to understand what finalizers without any guarantees (System.Mem.Weak) >> are supposed to achieve? >> >> Claus >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Mon Dec 8 06:53:01 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 8 06:46:14 2008 Subject: Weak pointers and STM In-Reply-To: References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com> <20081202142426.GB18561@sliver.repetae.net> <49379E32.8010703@gmail.com> <493CF01A.6030302@gmail.com> Message-ID: <493D0A9D.6000409@gmail.com> The way to use finalizers is in conjunction with an exception handler that provides an absolute guarantee that the resource will be reclaimed on exit. Note that Java doesn't guarantee to run finalizers on exit either: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#runFinalizersOnExit(boolean) Although in Java it's for different reasons. We can give more guarantees to C finalizers because they're much simpler: - a C finalizer can't synchronise with other Haskell code, including Haskell finalizers. - we don't have to worry about whether a C finalizer refers to other finalizable objects - we don't mind if a C finalizer blocks: that's the programmer's problem. Cheers, Simon Lennart Augustsson wrote: > From a theoretical perspective I'd say that they are completely > useless, because there's no guarantee that the finalizer will ever > run. You might as well throw them away as use them and there would be > the same guarantees. > From a practical perspective they are useful, because they probably > run. So you can use them to reclaim most resources. > > I realize that the situation is complicated in ghc, but it also means > that to get finalizers with guarantees you have to implement them > yourself rather than relying on the ghc runtime system, which can be > quite tedious. > > -- Lennart > > On Mon, Dec 8, 2008 at 9:59 AM, Simon Marlow wrote: >> Lennart Augustsson wrote: >>> Finalizers without guarantees, like what ghc implements, are totally >>> useless. Since there is no guarantee that the finalizer will ever run >>> attaching one is a no-op. It has bitten me several times. I wish ghc >>> implemented finalizers according to the ffi spec. >> We do plan to do that (I'm sure you're aware of bug #1364), however I'm sure >> you're also aware that GHC's finalizers are more general than the FFI spec >> requires in that finalizers can be Haskell computations, and it is this that >> leads to the lack of guarantees. Implementing the FFI-style finalizers >> requires us to treat C finalizers as a special case, rather than >> implementing them as foreign calls from Haskell finalizers, which is a bit >> of a pain. >> >> I disagree that finalizers are completely useless. They're just not useful >> for some of the things you might like them to be useful for, like guaranteed >> resource reclamation. >> >>> -- Lennart (iPhone) >> Cheers, >> Simon (MS natural keyboard and 28" LCD screen) >> >>> On Dec 7, 2008, at 13:12, "Claus Reinke" wrote: >>> >>>>> Adding finalizers to arbitrary objects was useful for the memo table >>>>> application we had in mind when weak pointers were introduced, but for all >>>>> the other applications I've come across since then, we really want to add >>>>> finalizers to objects whose lifetimes are under programmer control. Notice >>>>> how ForeignPtrs attach the finalizer carefully to the MutVar# inside the >>>>> ForeignPtr, not the ForeignPtr itself. >>>> One application that was effectively killed by GHC's approach to >>>> finalizers was GHood (I lost interest when it became apparent that >>>> GHC was moving away from giving any kinds of guarantees about >>>> finalizers). The idea was that, just as unsafePerformIO gives us a >>>> way to instrument the evaluator, so finalizers could have given us a way >>>> to instrument garbage collection. Then GHood could not only >>>> have shown when which parts of which structure are first observed >>>> (how and when structures get unfolded) but also (roughly) when which >>>> parts of which structure become unreachable (how and when >>>> structures disappear again). That would have made a very nice tool. >>>> >>>> But it would have needed finalizers on arbitrary objects that are >>>> actually guaranteed to be run, preferably promptly, but not early. Given >>>> the application, I would have considered wrapping/annotating those objects >>>> in some transparent way, not visible to the original program, but forcing >>>> the memory manager to keep track of that object even if that means worse >>>> code. Only that there are no guarantees whatsoever on these finalizers >>>> anymore (there were some back then, but it emerged that they weren't backed >>>> up by the implementation). >>>> Which also hurts other, table-like, applications: I have an application >>>> where I need to keep track of synchronous communication channels, basically: >>>> advance each live channel at every step. Now, I would like to attach >>>> finalizers to the channels, so that when there are no more threads having >>>> references to a channel, the channel gets removed >>>> from the tracking table. But without finalizer guarantees, there is no >>>> guarantee that the table will not simply keep accumulating more and >>>> more of those dynamically created channels.. >>>> >>>> I, for one, would like to have good support for "adding finalizers to >>>> arbitrary objects with useful run guarantees". Actually, it is a bit hard >>>> to understand what finalizers without any guarantees (System.Mem.Weak) >>>> are supposed to achieve? >>>> >>>> Claus >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users@haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> From bulat.ziganshin at gmail.com Mon Dec 8 07:18:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 8 07:12:12 2008 Subject: Weak pointers and STM In-Reply-To: <493D0A9D.6000409@gmail.com> References: <20081201045938.GF7014@sliver.repetae.net> <49340E37.6050606@gmail.com> <20081202142426.GB18561@sliver.repetae.net> <49379E32.8010703@gmail.com> <493CF01A.6030302@gmail.com> <493D0A9D.6000409@gmail.com> Message-ID: <955643896.20081208151856@gmail.com> Hello Simon, Monday, December 8, 2008, 2:53:01 PM, you wrote: just a detached look: may be provide Haskell finalizers with the same (lack of) warranties? > The way to use finalizers is in conjunction with an exception handler that > provides an absolute guarantee that the resource will be reclaimed on exit. > Note that Java doesn't guarantee to run finalizers on exit either: > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#runFinalizersOnExit(boolean) > Although in Java it's for different reasons. > We can give more guarantees to C finalizers because they're much simpler: > - a C finalizer can't synchronise with other Haskell code, > including Haskell finalizers. > - we don't have to worry about whether a C finalizer refers to > other finalizable objects > - we don't mind if a C finalizer blocks: that's the programmer's problem. > Cheers, > Simon > Lennart Augustsson wrote: >> From a theoretical perspective I'd say that they are completely >> useless, because there's no guarantee that the finalizer will ever >> run. You might as well throw them away as use them and there would be >> the same guarantees. >> From a practical perspective they are useful, because they probably >> run. So you can use them to reclaim most resources. >> >> I realize that the situation is complicated in ghc, but it also means >> that to get finalizers with guarantees you have to implement them >> yourself rather than relying on the ghc runtime system, which can be >> quite tedious. >> >> -- Lennart >> >> On Mon, Dec 8, 2008 at 9:59 AM, Simon Marlow wrote: >>> Lennart Augustsson wrote: >>>> Finalizers without guarantees, like what ghc implements, are totally >>>> useless. Since there is no guarantee that the finalizer will ever run >>>> attaching one is a no-op. It has bitten me several times. I wish ghc >>>> implemented finalizers according to the ffi spec. >>> We do plan to do that (I'm sure you're aware of bug #1364), however I'm sure >>> you're also aware that GHC's finalizers are more general than the FFI spec >>> requires in that finalizers can be Haskell computations, and it is this that >>> leads to the lack of guarantees. Implementing the FFI-style finalizers >>> requires us to treat C finalizers as a special case, rather than >>> implementing them as foreign calls from Haskell finalizers, which is a bit >>> of a pain. >>> >>> I disagree that finalizers are completely useless. They're just not useful >>> for some of the things you might like them to be useful for, like guaranteed >>> resource reclamation. >>> >>>> -- Lennart (iPhone) >>> Cheers, >>> Simon (MS natural keyboard and 28" LCD screen) >>> >>>> On Dec 7, 2008, at 13:12, "Claus Reinke" wrote: >>>> >>>>>> Adding finalizers to arbitrary objects was useful for the memo table >>>>>> application we had in mind when weak pointers were introduced, but for all >>>>>> the other applications I've come across since then, we really want to add >>>>>> finalizers to objects whose lifetimes are under programmer control. Notice >>>>>> how ForeignPtrs attach the finalizer carefully to the MutVar# inside the >>>>>> ForeignPtr, not the ForeignPtr itself. >>>>> One application that was effectively killed by GHC's approach to >>>>> finalizers was GHood (I lost interest when it became apparent that >>>>> GHC was moving away from giving any kinds of guarantees about >>>>> finalizers). The idea was that, just as unsafePerformIO gives us a >>>>> way to instrument the evaluator, so finalizers could have given us a way >>>>> to instrument garbage collection. Then GHood could not only >>>>> have shown when which parts of which structure are first observed >>>>> (how and when structures get unfolded) but also (roughly) when which >>>>> parts of which structure become unreachable (how and when >>>>> structures disappear again). That would have made a very nice tool. >>>>> >>>>> But it would have needed finalizers on arbitrary objects that are >>>>> actually guaranteed to be run, preferably promptly, but not early. Given >>>>> the application, I would have considered wrapping/annotating those objects >>>>> in some transparent way, not visible to the original program, but forcing >>>>> the memory manager to keep track of that object even if that means worse >>>>> code. Only that there are no guarantees whatsoever on these finalizers >>>>> anymore (there were some back then, but it emerged that they weren't backed >>>>> up by the implementation). >>>>> Which also hurts other, table-like, applications: I have an application >>>>> where I need to keep track of synchronous communication channels, basically: >>>>> advance each live channel at every step. Now, I would like to attach >>>>> finalizers to the channels, so that when there are no more threads having >>>>> references to a channel, the channel gets removed >>>>> from the tracking table. But without finalizer guarantees, there is no >>>>> guarantee that the table will not simply keep accumulating more and >>>>> more of those dynamically created channels.. >>>>> >>>>> I, for one, would like to have good support for "adding finalizers to >>>>> arbitrary objects with useful run guarantees". Actually, it is a bit hard >>>>> to understand what finalizers without any guarantees (System.Mem.Weak) >>>>> are supposed to achieve? >>>>> >>>>> Claus >>>>> >>>>> _______________________________________________ >>>>> 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 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From martin.sulzmann.haskell at googlemail.com Mon Dec 8 07:55:50 2008 From: martin.sulzmann.haskell at googlemail.com (Martin Sulzmann) Date: Mon Dec 8 07:48:56 2008 Subject: Type checker loops with type families, overlapping and undecidable instances In-Reply-To: <73E09C74-DBCB-4799-A60B-2DFB4105950D@cse.unsw.edu.au> References: <52f14b210812040557k7085a8f3m44bed3910e1cb91d@mail.gmail.com> <52f14b210812040613m48898598kf99daa459e3416ed@mail.gmail.com> <73E09C74-DBCB-4799-A60B-2DFB4105950D@cse.unsw.edu.au> Message-ID: <4bb51c60812080455m6e4224f7u4531a9685256a214@mail.gmail.com> > The interaction between solving class constraints and equalities with type > families is currently rather ad hoc. > FYI *September 2008* *Unified Type Checking for Type Classes and Type Families*, T. Schrijvers, M. Sulzmann. Presented at the ICFP 2008 poster session (pdf available on Tom's homepage). We propose to encode type class solving as type function solving. Earlier, I suggested the opposite direction. Either way works and leads to a system which can properly deal with any sort of type class and type function interaction plus can be straightforwardly extended to support co-inductive type classes/functions. -Martin We are currently re-designing that interaction and may then make the > fixed-depth restriction more broadly applicable. However, as Tom already > mentioned, the cycle does not involve type families in your example anyway. > > Manuel > > Jos? Pedro Magalh?es: > > Hello Lennart, > > Yes, but according to the manual ( > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#undecidable-instances), > "Termination is ensured by having a fixed-depth recursion stack". So I would > expect at least termination, which I'm not getting (but I guess that can be > due to the type families). > > > Thanks, > Pedro > > On Thu, Dec 4, 2008 at 15:10, Lennart Augustsson wrote: > >> Turning on UndecidableInstances is the same as saying: OK typechcker, >> you can loop if I make a mistake. >> I've not looked closely at your code, but if you turn on that flag, >> looping is probably not a bug. >> >> -- Lennart >> >> 2008/12/4 Jos? Pedro Magalh?es : >> > Hello all, >> > >> > Please consider the following code: >> > >> >> {-# OPTIONS -Wall #-} >> >> {-# LANGUAGE FlexibleContexts #-} >> >> {-# LANGUAGE FlexibleInstances #-} >> >> {-# LANGUAGE TypeOperators #-} >> >> {-# LANGUAGE TypeFamilies #-} >> >> {-# LANGUAGE OverlappingInstances #-} >> >> {-# LANGUAGE UndecidableInstances #-} >> >> >> >> module Test where >> >> >> >> -- Some view >> >> class Viewable a where >> >> type View a >> >> to :: a -> View a >> >> >> >> -- Structural representations >> >> data Unit = Unit >> >> data a :+: b = L a | R b >> >> >> >> instance Viewable Unit where >> >> type View Unit = Unit >> >> to = id >> >> >> >> instance (Viewable a, Viewable b) => Viewable (a :+: b) where >> >> type View (a :+: b) = a :+: b >> >> to = id >> >> >> >> -- Worker class >> >> class F' a where >> >> f' :: a -> () >> >> >> >> instance F' Unit where >> >> f' Unit = () >> >> >> >> instance (F a, F b) => F' (a :+: b) where >> >> f' (L x) = f x >> >> f' (R x) = f x >> >> >> >> >> >> -- Dispatcher class >> >> class (Viewable a, F' (View a)) => F a where >> >> f :: a -> () >> >> f = f' . to >> >> >> >> instance F Unit where >> >> f = f' >> >> >> >> instance (F a, F b) => F (a :+: b) where >> >> f = f' >> >> >> >> -- All generic instances >> >> instance (Viewable a, F' (View a)) => F a >> >> >> >> >> >> -- A recursive datatype >> >> data Nat = Zero | Succ Nat >> >> >> >> -- Instance of Viewable >> >> instance Viewable Nat where >> >> type View Nat = Unit :+: Nat >> >> to = undefined >> >> >> >> -- Uncommenting the line below causes the typechecker to loop (GHC >> 6.10.1, >> >> Windows) >> >> --test = f Zero >> > >> > >> > Is this expected behavior or a bug? >> > >> > >> > Thanks, >> > Pedro >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > 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/20081208/00d85ef2/attachment-0001.htm From marlowsd at gmail.com Mon Dec 8 08:12:58 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 8 08:06:08 2008 Subject: ghc-paths In-Reply-To: <9436bffe0812050007g69de7eava3151514ee915515@mail.gmail.com> References: <9436bffe0812050007g69de7eava3151514ee915515@mail.gmail.com> Message-ID: <493D1D5A.7020207@gmail.com> Jens Petersen wrote: > Are there any plans to include ghc-paths in ghc itself? Not at present. It's more difficult to ship it with GHC than it is to build it post-installation, because it is essentially compiled code that depends on an install-time variable. Various hairbrained schemes were proposed on cvs-ghc a while back, but I'm not aware of any easy solutions to this problem. Cheers, Simon From phunge0 at hotmail.com Mon Dec 8 11:35:47 2008 From: phunge0 at hotmail.com (Brian B) Date: Mon Dec 8 11:28:53 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <167713711.20081207122934@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> Message-ID: Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. Thanks, Brian Bloniarz > Hello Tomasz, > > Saturday, December 6, 2008, 10:52:39 PM, you wrote: > > > Had you deprecated the non-threaded RTS, we would probably have no problems > > described in ticket #2848 :-/ > > > I think you'll have to deprecate it anyway, because it will be more > > and more difficult > > to maintain two versions of code, especially if one of them will be > > much less used and > > tested. > > we may conduct small survey on amount of usage of old RTS (i mean ask > this in haskell-cafe) > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _________________________________________________________________ Connect to the next generation of MSN Messenger? http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081208/6e858884/attachment.htm From haskell at list.mightyreason.com Mon Dec 8 14:16:24 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Dec 8 14:09:33 2008 Subject: Three Recursively defined modules Message-ID: <493D7288.6080900@list.mightyreason.com> Hi, As "hs-boot" is ghc specific method I am asking on this glasgow-haskell-users mailing list first. My hprotoc program converts message definitions into Haskell modules, and mimicking the expected OOP-like namespaces has been successful so far. It is possible to define messages and keys that create recursive modules dependencies, and I have left fixing this to the user. For the examples I have run across this has been possible to do manually. But I can easily write a file which generates three recursively defined modules with keys that I have not been able to fix with hs-boot files. I have created toy versions of the 3 modules and their "key"s which contain the problem. Can anyone see how to use hs-boot files to compile the three modules below? Note: The 3 modules ought to be the same aside from cyclic [a,b,c] replacement: > module A(A(..),akeybc,akeycb) where > > import B(B) > import B(bkeyac) > import C(C) > import C(ckeyab) > > data A = A { name :: String } > > akeybc :: Either B (Maybe C) > akeybc = Right Nothing > > akeycb :: Either C (Maybe B) > akeycb = Right Nothing > > instance Show A where > show a = concat [name a,show bkeyac,show ckeyab] > module B(B(..),bkeyca,bkeyac) where > > import A(A) > import A(akeybc) > import C(C) > import C(ckeyba) > > data B = B { name :: String } > > bkeyca :: Either C (Maybe A) > bkeyca = Right Nothing > > bkeyac :: Either A (Maybe C) > bkeyac = Right Nothing > > instance Show B where > show b = concat [name b,show ckeyba,show akeybc] > module C(C(..),ckeyab,ckeyba) where > > import A(A) > import A(akeycb) > import B(B) > import B(bkeyca) > > data C = C { name :: String } > > ckeyab :: Either A (Maybe B) > ckeyab = Right Nothing > > ckeyba :: Either B (Maybe A) > ckeyba = Right Nothing > > instance Show C where > show c = concat [name c,show akeycb,show bkeyca] It would be disappointing if I had to move the "key"s into separate modules/namespaces to allow for a solution using hs-boot files. Thanks, Chris From isaacdupree at charter.net Mon Dec 8 19:49:30 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Dec 8 19:42:39 2008 Subject: Three Recursively defined modules In-Reply-To: <493D7288.6080900@list.mightyreason.com> References: <493D7288.6080900@list.mightyreason.com> Message-ID: <493DC09A.4090605@charter.net> Chris Kuklewicz wrote: > Can anyone see how to use hs-boot files to compile the three modules below? I tried. I failed. I don't think it's possible if we restrict ourselves to adding {-#SOURCE#-} to the .hs files and adding .hs-boot files. In any case it's not possible in all cases. Which annoys me. > It would be disappointing if I had to move the "key"s into separate modules/namespaces to allow for a solution using hs-boot files. I would suggest that this is actually not bad at all (more modules, more hs-boot files, what's the difference?). Except I realized, then you have orphan Show instances. What a nuisance. -Isaac From hoangta at comp.nus.edu.sg Mon Dec 8 21:27:27 2008 From: hoangta at comp.nus.edu.sg (Hoang Truong) Date: Mon Dec 8 21:20:31 2008 Subject: Parallel forkOS does not work on ubuntu Message-ID: Hello everybody, I am following "A Tutorial on Parallel and Concurrent Programming in Haskell" and I have a problem with making Haskell to use my multi-cores (Core 2 Quad CPU). The Haskel version I used is GHC 6.10.1, for Haskell 98. I compile my below program with command: ghc --make -threaded -debug thread0.hs, and run with: thread0 +RTS -N4 while watching the cpu usage on another terminal (by: mpstat -P ALL 1 100), but the program uses only one core of my Ubuntu Linux. Do any of you know why or has any suggestions? Below is my program: import Control.Concurrent import Control.Concurrent.MVar fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) dowork = putStrLn ("fib 35 = " ++ (show (fib 35))) threadA :: MVar Int -> MVar Int -> MVar Int -> IO () threadA valueToSendMVar valueToReadMVar valueToQuit = do -- some work dowork -- perform rendezvous putMVar valueToSendMVar 30 -- send value v <- takeMVar valueToReadMVar putStrLn ("result, fib 30 = " ++ (show v)) dowork -- notify done putMVar valueToQuit 0 -- send value threadB :: MVar Int -> MVar Int -> MVar Int -> IO () threadB valueToReceiveMVar valueToSendMVar valueToQuit = do -- some work dowork -- perform rendezvous by waiting z <- takeMVar valueToReceiveMVar putMVar valueToSendMVar (fib z) -- continue with other work dowork -- notify done putMVar valueToQuit 0 -- send value main :: IO () main = do aQuitA <- newEmptyMVar aQuitB <- newEmptyMVar aMVar <- newEmptyMVar bMVar <- newEmptyMVar forkOS (threadA aMVar bMVar aQuitA ) forkOS (threadB aMVar bMVar aQuitB ) -- wait for threadA and threadB takeMVar aQuitA takeMVar aQuitB return () Thanks a lot, Hoang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081209/380acfa2/attachment.htm From marlowsd at gmail.com Tue Dec 9 06:26:27 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Dec 9 06:19:34 2008 Subject: Parallel forkOS does not work on ubuntu In-Reply-To: References: Message-ID: <493E55E3.2080103@gmail.com> Hoang Truong wrote: > Hello everybody, > > I am following "A Tutorial on Parallel and Concurrent Programming in > Haskell" and I have a problem with making Haskell to use my multi-cores > (Core 2 Quad CPU). > > The Haskel version I used is GHC 6.10.1, for Haskell 98. I compile my > below program with command: ghc --make -threaded -debug thread0.hs, and > run with: thread0 +RTS -N4 while watching the cpu usage on another > terminal (by: mpstat -P ALL 1 100), but the program uses only one core > of my Ubuntu Linux. > > Do any of you know why or has any suggestions? Below is my program: Why do people still insist on using forkOS? You don't need forkOS unless you need to call C libraries that use thread-local state. Otherwise, it will just reduce your performance compared to forkIO. Admittedly the documentation for forkOS has been misleading in the past, but I think the current version is pretty clear: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AforkOS > import Control.Concurrent > import Control.Concurrent.MVar > > fib :: Int -> Int > fib 0 = 0 > fib 1 = 1 > fib n = fib (n-1) + fib (n-2) > > dowork = > putStrLn ("fib 35 = " ++ (show (fib 35))) Perhaps you were expecting "fib 35" to be repeatedly executed each time you call dowork? Laziness means it only gets evaluated once. Cheers, Simon From hoangta at comp.nus.edu.sg Tue Dec 9 07:47:53 2008 From: hoangta at comp.nus.edu.sg (Hoang Truong) Date: Tue Dec 9 07:40:57 2008 Subject: Parallel forkOS does not work on ubuntu In-Reply-To: <493E55E3.2080103@gmail.com> References: <493E55E3.2080103@gmail.com> Message-ID: Hi Simon, I tried with forkIO and added another dowork functions but the result is the same: only one core is used, three other cores are idle. Do you have any other suggestions? Is there anything I should take care when installing GHC? I also did try the Wombat.hs from the tutorial, but only one core is used and the times are almost the same. seq sum: 119201850 seq time: 20.959932 seconds. par sum: 119201850 par time: 20.959547 seconds. -------- import System.Time import Control.Parallel fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) secDiff :: ClockTime -> ClockTime -> Float secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) = fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1) mkList :: Int -> [Int] mkList n = [1..n-1] relprime :: Int -> Int -> Bool relprime x y = gcd x y == 1 euler :: Int -> Int euler n = length (filter (relprime n) (mkList n)) sumEuler :: Int -> Int sumEuler = sum . (map euler) . mkList sumFibEuler:: Int -> Int -> Int sumFibEuler a b = fib a + sumEuler b parSumFibEuler a b = f `par` (e `pseq` (e+ f)) where f = fib a e = sumEuler b r1 :: Int r1 = sumFibEuler 40 7450 r2 :: Int r2 = parSumFibEuler 40 7450 main :: IO () main = do t0 <- getClockTime pseq r1 (return()) t1 <- getClockTime putStrLn ("seq sum: " ++ show r1) putStrLn ("seq time: " ++ show (secDiff t0 t1) ++ " seconds.") t0 <- getClockTime pseq r2 (return()) t1 <- getClockTime putStrLn ("par sum: " ++ show r2) putStrLn ("par time: " ++ show (secDiff t0 t1) ++ " seconds.") ----- Many thanks, Hoang On Tue, Dec 9, 2008 at 7:26 PM, Simon Marlow wrote: > Hoang Truong wrote: > >> Hello everybody, >> >> I am following "A Tutorial on Parallel and Concurrent Programming in >> Haskell" and I have a problem with making Haskell to use my multi-cores >> (Core 2 Quad CPU). >> The Haskel version I used is GHC 6.10.1, for Haskell 98. I compile my >> below program with command: ghc --make -threaded -debug thread0.hs, and run >> with: thread0 +RTS -N4 while watching the cpu usage on another terminal (by: >> mpstat -P ALL 1 100), but the program uses only one core of my Ubuntu Linux. >> >> Do any of you know why or has any suggestions? Below is my program: >> > > Why do people still insist on using forkOS? You don't need forkOS unless > you need to call C libraries that use thread-local state. Otherwise, it > will just reduce your performance compared to forkIO. Admittedly the > documentation for forkOS has been misleading in the past, but I think the > current version is pretty clear: > > > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AforkOS > > import Control.Concurrent >> import Control.Concurrent.MVar >> >> fib :: Int -> Int >> fib 0 = 0 >> fib 1 = 1 >> fib n = fib (n-1) + fib (n-2) >> >> dowork = >> putStrLn ("fib 35 = " ++ (show (fib 35))) >> > > Perhaps you were expecting "fib 35" to be repeatedly executed each time you > call dowork? Laziness means it only gets evaluated once. > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081209/1382174b/attachment-0001.htm From mailing_list at istitutocolli.org Tue Dec 9 11:26:43 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Tue Dec 9 11:19:54 2008 Subject: ghci linker and circular dependencies: bug or feature? Message-ID: <20081209162643.GG22600@Andrea.Nowhere.net> Hello, this is a followup of this: http://article.gmane.org/gmane.comp.lang.haskell.cafe/48644 which didn't have replays. In order to make the review a bit easier I prepared a minimal test case which, I believe, could prove there's a bug in the ghci linker. I'm not submitting a bug report because I'm not familiar with these problems and, in order not to waste other people's time, I'd rather have some preliminary review. All the code examples can be found here: http://gorgias.mine.nu/ffi-test/ Here a tarball of everything: http://gorgias.mine.nu/ffi-test.tar.gz Take a simple C library like this: #include extern char my_var[]; void my_fun() { fprintf (stderr, "%s\n", my_var); } Since my_var is defined as external, the dynamic library compiled and linked with: gcc -Wall -fPIC -c -o mylib.o mylib.c gcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0 mylib.o would have my_var as undefined. If I write some Haskell bindings (Test.hsc) like this: module Test where import Foreign.C import Foreign #include foreign import ccall unsafe "my_fun" my_cfun :: IO () my_fun :: IO () my_fun = my_cfun I'll need to include a stub.c file to initialize my_var: char my_var[] = "Hello World!!"; And now come my problems: 1. First I have a Cabal problem. If I set: extra-libraries: mylib this will be used also when compiling dist/build/Test_hsc_make, and, since libmylib.so.1.0 has an undefined reference to my_var, which will be initialized only later, by stub.c, the compilation of the bindings will fail with: Configuring mylib-0.1... Preprocessing library mylib-0.1... /tmp/ffi-test/libmylib.so: undefined reference to `my_var' collect2: ld returned 1 exit status linking dist/build/Test_hsc_make.o failed command was: /usr/bin/gcc -L/tmp/ffi-test -lmylib -L/usr/lib/ghc-6.10.1/base-4.0.0.0 [...] I can find a work-around by not setting cabal extra-libraries and instead setting ghc-options: -lmylib But when compiling a test file: import Test main = my_fun I'll need to pass -lmylib to ghc --make. 2. I also have ghci problem. If I try with: ghci test_lib.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. Ok, modules loaded: Main. Prelude Main> main Loading package mylib-0.1 ... linking ... : /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o: unknown symbol `my_fun' ghc: unable to load package `mylib-0.1' Now, I have to remember to pass -lmylib: ghci -lmylib test_lib.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading object (dynamic) mylib ... failed. : user specified .o/.so/.DLL could not be loaded (/tmp/ffi-test/libmylib.so: undefined symbol: my_var) Whilst trying to load: (dynamic) mylib Additional directories searched: (none) Now, the my_var symbol is included in: /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o and indeed: nm --print-arma /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o | grep my_var 0000001c D my_var So I desperately try: ghci /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o -lmylib /tmp/ffi-test/bindings/test_lib.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading object (static) /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o ... done Loading object (dynamic) mylib ... failed. : user specified .o/.so/.DLL could not be loaded (/tmp/ffi-test/libmylib.so: undefined symbol: my_var) Whilst trying to load: (dynamic) mylib Additional directories searched: (none) Is this a bug? An intended behaviour? Is there a way out? What am I missing? Obviously the problem goes away if I link mylib.o with stub.o into libmylib.so.1.0. Thanks for your help. Andrea ps: here you can find a small shell script to automate the proposed test (included in the tarball linked above): http://gorgias.mine.nu/ffi-test/test_dynamic.sh From dons at galois.com Tue Dec 9 15:47:42 2008 From: dons at galois.com (Don Stewart) Date: Tue Dec 9 15:40:41 2008 Subject: Parallel forkOS does not work on ubuntu In-Reply-To: References: Message-ID: <20081209204742.GC5859@scytale.galois.com> hoangta: > Hello everybody, > I am following "A Tutorial on Parallel and Concurrent Programming in > Haskell" and I have a problem with making Haskell to use my multi-cores > (Core 2 Quad CPU). > The Haskel version I used is GHC 6.10.1, for Haskell 98. I compile my > below program with command: ghc --make -threaded -debug thread0.hs, and > run with: thread0 +RTS -N4 while watching the cpu usage on another > terminal (by: mpstat -P ALL 1 100), but the program uses only one core of > my Ubuntu Linux. > Do any of you know why or has any suggestions? Below is my program: > import Control.Concurrent > import Control.Concurrent.MVar > fib :: Int -> Int > fib 0 = 0 > fib 1 = 1 > fib n = fib (n-1) + fib (n-2) > dowork = > putStrLn ("fib 35 = " ++ (show (fib 35))) > threadA :: MVar Int -> MVar Int -> MVar Int -> IO () > threadA valueToSendMVar valueToReadMVar valueToQuit > = do > -- some work > dowork > -- perform rendezvous > putMVar valueToSendMVar 30 -- send value > v <- takeMVar valueToReadMVar > putStrLn ("result, fib 30 = " ++ (show v)) > dowork > -- notify done > putMVar valueToQuit 0 -- send value > threadB :: MVar Int -> MVar Int -> MVar Int -> IO () > threadB valueToReceiveMVar valueToSendMVar valueToQuit > = do > -- some work > dowork > -- perform rendezvous by waiting > z <- takeMVar valueToReceiveMVar > putMVar valueToSendMVar (fib z) > -- continue with other work > dowork > -- notify done > putMVar valueToQuit 0 -- send value > main :: IO () > main > = do > aQuitA <- newEmptyMVar > aQuitB <- newEmptyMVar > aMVar <- newEmptyMVar > bMVar <- newEmptyMVar > forkOS (threadA aMVar bMVar aQuitA ) > forkOS (threadB aMVar bMVar aQuitB ) > -- wait for threadA and threadB > takeMVar aQuitA > takeMVar aQuitB > return () How about, import Control.Parallel import Control.Monad import Text.Printf cutoff = 35 fib' :: Int -> Integer fib' 0 = 0 fib' 1 = 1 fib' n = fib' (n-1) + fib' (n-2) fib :: Int -> Integer fib n | n < cutoff = fib' n | otherwise = r `par` (l `pseq` l + r) where l = fib (n-1) r = fib (n-2) main = forM_ [0..45] $ \i -> printf "n=%d => %d\n" i (fib i) Where: $ ghc -O2 -threaded fib.hs --make Linking fib ... $ time ./fib +RTS -N2 n=0 => 0 n=1 => 1 n=2 => 1 n=3 => 2 n=4 => 3 ... n=43 => 433494437 n=44 => 701408733 n=45 => 1134903170 ./fib 30 +RTS -N2 107.56s user 0.54s system 184% cpu 58.703 tota From hoangta at comp.nus.edu.sg Tue Dec 9 20:27:32 2008 From: hoangta at comp.nus.edu.sg (Hoang Truong) Date: Tue Dec 9 20:20:34 2008 Subject: Parallel forkOS does not work on ubuntu In-Reply-To: <20081209204742.GC5859@scytale.galois.com> References: <20081209204742.GC5859@scytale.galois.com> Message-ID: Thanks Don. Your fib program works well. It uses all four cores of my computer with +RTS -N4. But the Wombat.hs still does not work. It seems tricky to me. Hoang On Wed, Dec 10, 2008 at 4:47 AM, Don Stewart wrote: > hoangta: > > Hello everybody, > > I am following "A Tutorial on Parallel and Concurrent Programming in > > Haskell" and I have a problem with making Haskell to use my > multi-cores > > (Core 2 Quad CPU). > > The Haskel version I used is GHC 6.10.1, for Haskell 98. I compile my > > below program with command: ghc --make -threaded -debug thread0.hs, > and > > run with: thread0 +RTS -N4 while watching the cpu usage on another > > terminal (by: mpstat -P ALL 1 100), but the program uses only one core > of > > my Ubuntu Linux. > > Do any of you know why or has any suggestions? Below is my program: > > > import Control.Concurrent > > import Control.Concurrent.MVar > > fib :: Int -> Int > > fib 0 = 0 > > fib 1 = 1 > > fib n = fib (n-1) + fib (n-2) > > dowork = > > putStrLn ("fib 35 = " ++ (show (fib 35))) > > threadA :: MVar Int -> MVar Int -> MVar Int -> IO () > > threadA valueToSendMVar valueToReadMVar valueToQuit > > = do > > -- some work > > dowork > > -- perform rendezvous > > putMVar valueToSendMVar 30 -- send value > > v <- takeMVar valueToReadMVar > > putStrLn ("result, fib 30 = " ++ (show v)) > > dowork > > -- notify done > > putMVar valueToQuit 0 -- send value > > threadB :: MVar Int -> MVar Int -> MVar Int -> IO () > > threadB valueToReceiveMVar valueToSendMVar valueToQuit > > = do > > -- some work > > dowork > > -- perform rendezvous by waiting > > z <- takeMVar valueToReceiveMVar > > putMVar valueToSendMVar (fib z) > > -- continue with other work > > dowork > > -- notify done > > putMVar valueToQuit 0 -- send value > > main :: IO () > > main > > = do > > aQuitA <- newEmptyMVar > > aQuitB <- newEmptyMVar > > aMVar <- newEmptyMVar > > bMVar <- newEmptyMVar > > forkOS (threadA aMVar bMVar aQuitA ) > > forkOS (threadB aMVar bMVar aQuitB ) > > -- wait for threadA and threadB > > takeMVar aQuitA > > takeMVar aQuitB > > return () > > > > How about, > > import Control.Parallel > import Control.Monad > import Text.Printf > > cutoff = 35 > > fib' :: Int -> Integer > fib' 0 = 0 > fib' 1 = 1 > fib' n = fib' (n-1) + fib' (n-2) > > fib :: Int -> Integer > fib n | n < cutoff = fib' n > | otherwise = r `par` (l `pseq` l + r) > where > l = fib (n-1) > r = fib (n-2) > > main = forM_ [0..45] $ \i -> > printf "n=%d => %d\n" i (fib i) > > Where: > > > $ ghc -O2 -threaded fib.hs --make > Linking fib ... > > $ time ./fib +RTS -N2 > n=0 => 0 > n=1 => 1 > n=2 => 1 > n=3 => 2 > n=4 => 3 > ... > n=43 => 433494437 > n=44 => 701408733 > n=45 => 1134903170 > ./fib 30 +RTS -N2 107.56s user 0.54s system 184% cpu 58.703 tota > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081210/344326fb/attachment.htm From marlowsd at gmail.com Wed Dec 10 07:05:58 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Dec 10 06:59:02 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1228397013.1346.1288235643@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <20081203203121.GA13500@matrix.chaos.earth.li> <1228397013.1346.1288235643@webmail.messagingengine.com> Message-ID: <493FB0A6.5080505@gmail.com> Barney Stratford wrote: > I have a workaround for the linker bugs that keep popping up under Mac > OS X, and now have a working GHC 6.8. I found that saying -fasm didn't > help matters. Instead, on the assumption that the linker gets it wrong > and there is in fact nothing wrong with the object file, I applied these > two patches: > > diff -u a/compiler/Makefile b/compiler/Makefile > --- a/compiler/Makefile Mon Dec 10 18:11:32 2007 > +++ b/compiler/Makefile Wed Nov 26 09:35:12 2008 > @@ -753,7 +753,7 @@ > $(SED) -e "s@GHC_PATH@$(GHC_PATH)@g" -e "s@TOP_ABS@$(FPTOOLS_TOP_ABS)@g" < $< > $@ > > $(INPLACE_PROG): $(INPLACE_SRC) > - $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ > + $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ -optl > "-Wl,-read_only_relocs,warning" > > all :: $(INPLACE_PROG) > > diff -u a/mk/target.mk b/mk/target.mk > --- a/mk/target.mk Mon Dec 10 18:11:31 2007 > +++ b/mk/target.mk Thu Nov 27 12:14:02 2008 > @@ -231,7 +231,7 @@ > > ifneq "$(BootingFromHc)" "YES" > $(HS_PROG) :: $(OBJS) > - $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) > + $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) -optl > "-Wl,-read_only_relocs,warning" > else > # see bootstrap.mk > $(HS_PROG) :: $(OBJS) > > Another way to fix these problems would be to mumble something about > -segprot __TEXT rwx rwx, but this is definitely a hack. > > I also had to patch Cabal so it ranlibs the libraries it creates (which > is required under Mac OS), and fixed the .hi-boot files in > compiler/typecheck. (Shouldn't these be updated automatically?) Without > those changes, the typechecker won't typecheck. Oh, the irony! > > Perhaps someone that knows more about how the build system works could > figure out the right way to do these things. Presumably you'll get the same error when using your new GHC to link any Haskell program? So in fact GHC itself should be adding this option when linking the RTS on this platform. The right place to add this would be in rts/package.conf.in, in extra-ld-opts, with suitable platform-specific #ifdefs. If you can whip up a patch and test it, I'll commit. Cheers, Simon From marlowsd at gmail.com Wed Dec 10 07:17:12 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Dec 10 07:10:18 2008 Subject: ghci linker and circular dependencies: bug or feature? In-Reply-To: <20081209162643.GG22600@Andrea.Nowhere.net> References: <20081209162643.GG22600@Andrea.Nowhere.net> Message-ID: <493FB348.7000500@gmail.com> Andrea Rossato wrote: > Hello, > > this is a followup of this: > > http://article.gmane.org/gmane.comp.lang.haskell.cafe/48644 > > which didn't have replays. In order to make the review a bit easier I > prepared a minimal test case which, I believe, could prove there's a > bug in the ghci linker. I'm not submitting a bug report because I'm > not familiar with these problems and, in order not to waste other > people's time, I'd rather have some preliminary review. > > All the code examples can be found here: > http://gorgias.mine.nu/ffi-test/ > > Here a tarball of everything: > http://gorgias.mine.nu/ffi-test.tar.gz > > Take a simple C library like this: > > #include > extern char my_var[]; > void my_fun() > { > fprintf (stderr, "%s\n", my_var); > } > > > Since my_var is defined as external, the dynamic library compiled > and linked with: > > gcc -Wall -fPIC -c -o mylib.o mylib.c > gcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0 mylib.o > > would have my_var as undefined. > > If I write some Haskell bindings (Test.hsc) like this: > > module Test where > > import Foreign.C > import Foreign > > #include > > foreign import ccall unsafe "my_fun" my_cfun :: IO () > > my_fun :: IO () > my_fun = my_cfun > > I'll need to include a stub.c file to initialize my_var: > > char my_var[] = "Hello World!!"; > > And now come my problems: > > 1. First I have a Cabal problem. If I set: > > extra-libraries: mylib > > this will be used also when compiling dist/build/Test_hsc_make, and, > since libmylib.so.1.0 has an undefined reference to my_var, which will > be initialized only later, by stub.c, the compilation of the bindings > will fail with: > > Configuring mylib-0.1... > Preprocessing library mylib-0.1... > /tmp/ffi-test/libmylib.so: undefined reference to `my_var' > collect2: ld returned 1 exit status > linking dist/build/Test_hsc_make.o failed > command was: /usr/bin/gcc -L/tmp/ffi-test -lmylib -L/usr/lib/ghc-6.10.1/base-4.0.0.0 [...] > > I can find a work-around by not setting cabal extra-libraries and > instead setting > > ghc-options: -lmylib > > But when compiling a test file: > > import Test > main = my_fun > > I'll need to pass -lmylib to ghc --make. > > 2. I also have ghci problem. If I try with: > > ghci test_lib.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. > Ok, modules loaded: Main. > > Prelude Main> main > Loading package mylib-0.1 ... linking ... : /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o: unknown symbol `my_fun' > ghc: unable to load package `mylib-0.1' > > Now, I have to remember to pass -lmylib: > > ghci -lmylib test_lib.hs > > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > > Loading object (dynamic) mylib ... failed. > : user specified .o/.so/.DLL could not be loaded (/tmp/ffi-test/libmylib.so: undefined symbol: my_var) > Whilst trying to load: (dynamic) mylib > Additional directories searched: (none) > > Now, the my_var symbol is included in: > > /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o > > and indeed: > > nm --print-arma /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o | grep my_var > 0000001c D my_var > > So I desperately try: > > ghci /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o -lmylib /tmp/ffi-test/bindings/test_lib.hs > > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > > Loading object (static) /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o ... done > Loading object (dynamic) mylib ... failed. > : user specified .o/.so/.DLL could not be loaded (/tmp/ffi-test/libmylib.so: undefined symbol: my_var) > Whilst trying to load: (dynamic) mylib > Additional directories searched: (none) > > Is this a bug? An intended behaviour? Is there a way out? What am I > missing? It's not a bug - or rather, it's a consequence of the fact that GHC does its own runtime linking. The dynamic library libmylib.so is being linked by the system linker, which has its own symbol table and knows nothing about GHC's linker and its symbol table. The file HSmylib-0.1.o is loaded by GHC's linker, so the my_var symbol is in GHC's symbol table, and hence can't be found by the system linker when loading libmylib.so. Some good news is that we should be able to make this work when we start using shared libraries, because HSmylib will be a shared library and it will be linked by the system linker (what I'm not sure about is how you load mutually recursive shared objects at runtime, but presumably there's a way to do that). Perhaps you could work around the Cabal/hsc2hs problem by making a dummy library containing my_var, and passing it to Cabal using --hsc2hs-option=-ldummy. Cheers, Simon > Obviously the problem goes away if I link mylib.o with stub.o into > libmylib.so.1.0. > > Thanks for your help. > > Andrea > > ps: here you can find a small shell script to automate the proposed > test (included in the tarball linked above): > http://gorgias.mine.nu/ffi-test/test_dynamic.sh > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Malcolm.Wallace at cs.york.ac.uk Wed Dec 10 07:25:21 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Dec 10 07:23:27 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <167713711.20081207122934@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> Message-ID: <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> > > Had you deprecated the non-threaded RTS, we would probably have no > > problems described in ticket #2848 :-/ > > > I think you'll have to deprecate it anyway, because it will be more > > and more difficult to maintain two versions of code, > > we may conduct small survey on amount of usage of old RTS (i mean ask > this in haskell-cafe) For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? Regards, Malcolm From marlowsd at gmail.com Wed Dec 10 08:55:07 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Dec 10 08:48:11 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <20081203102007.GA58325@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> Message-ID: <493FCA3B.70002@gmail.com> Markus Barenhoff wrote: > On Fri 28.11 09:42, Simon Marlow wrote: >> Markus Barenhoff wrote: >>> On Thu 27.11 09:49, Simon Marlow wrote: > > > Hi! > >>> I checked out and translated the head version of ghc today from darcs. >>> It compiled fine. When I now try to start the ghci I get the following: >>> >>> ---- snip ---- >>> GHCi, version 6.11.20081126: http://www.haskell.org/ghc/ :? for help >>> ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for >>> 626688 bytes at 0x40000000, got 0x801635000. Try specifying an address >>> with +RTS -xm -RTS >>> (GHC version 6.11.20081126 for x86_64_unknown_freebsd) >>> Please report this as a GHC bug: >>> http://www.haskell.org/ghc/reportabug >>> Abort (core dumped) >>> ---- snip ---- >>> >>> If it helps somehow, you can find the core dump here: >>> http://www.alios.org/~alios/ghc.core.bz2 >> That's odd, because 6.8.3 is using 0x40000000 on FreeBSD and is working >> fine (or is it?). > > yes, it worked, but I haven't installed anymore - so I'am not sure, where it > does maps its stuff into memory. The memory map shows that there's nothing mapped in at the place we're asking for memory, but still FreeBSD decides to give us memory somewhere else. I checked back in 6.8.3 and it looks like we were using MAP_FIXED - now MAP_FIXED is dangerous, because it will overwrite existing mappings (like the binary itself!), which is why we're not doing that now. I've committed a patch that uses MAP_FIXED on FreeBSD if other attempts to get memory below 2Gb fail. I'd be grateful if you could test it out, the patch is this one, pushed to HEAD today: Wed Dec 10 11:57:51 GMT 2008 Simon Marlow * On FreeBSD, try MAP_FIXED if ordinary mmap() fails to give us suitable memory This appears to be necessary on FreeBSD. It might be necessary on other OSs too, but I'm being cautious because using MAP_FIXED can lead to crashes by overwriting existing mappings, and we have no (easy) way to prevent that. Cheers, Simon From marlowsd at gmail.com Wed Dec 10 09:24:28 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Dec 10 09:17:32 2008 Subject: Parallel forkOS does not work on ubuntu In-Reply-To: References: <493E55E3.2080103@gmail.com> Message-ID: <493FD11C.1050609@gmail.com> Hoang Truong wrote: > Hi Simon, > > I tried with forkIO and added another dowork functions but the result is > the same: only one core is used, three other cores are idle. Do you have > any other suggestions? Is there anything I should take care when > installing GHC? > > I also did try the Wombat.hs from the tutorial, but only one core is > used and the times are almost the same. > > seq sum: 119201850 > seq time: 20.959932 seconds. > par sum: 119201850 > par time: 20.959547 seconds. Your program is suffering from microbenchmarkitis, I'm afraid. There's only one spark, which tickles a bug in the scheduler in 6.10.1 and earlier (but sometimes doesn't happen due to random scheduling behaviour). Even with that fixed, the program uses fib which tickles another bug: when optimised, fib doesn't do any allocation, and GHC's scheduler relies on allocation happening at regular enough intervals. In 6.10.1 we never get to do load-balancing in this example, because fib doesn't ever yield control to the scheduler. In HEAD, where we have work-stealing and don't rely on the scheduler for load-balancing, the load-balancing problem goes away but reveals another problem: the second thread wants to GC, but in order to GC it has to synchronise with the other running threads, but the other thread is running fib and never yields. We can fix this by allowing CPUs to GC independently (which we plan to do), but even then you could still run into the same problem because eventually a global GC will be required. If you really want to see the program running in parallel, turn off -O. Cheers, Simon From bulat.ziganshin at gmail.com Wed Dec 10 10:18:48 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Dec 10 10:12:07 2008 Subject: Parallel forkOS does not work on ubuntu In-Reply-To: <493FD11C.1050609@gmail.com> References: <493E55E3.2080103@gmail.com> <493FD11C.1050609@gmail.com> Message-ID: <1910428156.20081210181848@gmail.com> Hello Simon, Wednesday, December 10, 2008, 5:24:28 PM, you wrote: good explanation of various shortanges on the way to multi-threading. may be it worth a link from GHC Concurrency pages? > Hoang Truong wrote: >> Hi Simon, >> >> I tried with forkIO and added another dowork functions but the result is >> the same: only one core is used, three other cores are idle. Do you have >> any other suggestions? Is there anything I should take care when >> installing GHC? >> >> I also did try the Wombat.hs from the tutorial, but only one core is >> used and the times are almost the same. >> >> seq sum: 119201850 >> seq time: 20.959932 seconds. >> par sum: 119201850 >> par time: 20.959547 seconds. > Your program is suffering from microbenchmarkitis, I'm afraid. There's > only one spark, which tickles a bug in the scheduler in 6.10.1 and earlier > (but sometimes doesn't happen due to random scheduling behaviour). Even > with that fixed, the program uses fib which tickles another bug: when > optimised, fib doesn't do any allocation, and GHC's scheduler relies on > allocation happening at regular enough intervals. > In 6.10.1 we never get to do load-balancing in this example, because fib > doesn't ever yield control to the scheduler. In HEAD, where we have > work-stealing and don't rely on the scheduler for load-balancing, the > load-balancing problem goes away but reveals another problem: the second > thread wants to GC, but in order to GC it has to synchronise with the other > running threads, but the other thread is running fib and never yields. We > can fix this by allowing CPUs to GC independently (which we plan to do), > but even then you could still run into the same problem because eventually > a global GC will be required. If you really want to see the program > running in parallel, turn off -O. > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From hoangta at comp.nus.edu.sg Wed Dec 10 11:20:54 2008 From: hoangta at comp.nus.edu.sg (Hoang Truong) Date: Wed Dec 10 11:13:54 2008 Subject: Parallel forkOS does not work on ubuntu In-Reply-To: <493FD11C.1050609@gmail.com> References: <493E55E3.2080103@gmail.com> <493FD11C.1050609@gmail.com> Message-ID: Thanks Simon for your detail explanation. It does help me as I am new to Haskell. Btw, I did not use -O option. Hoang On Wed, Dec 10, 2008 at 9:24 PM, Simon Marlow wrote: > Hoang Truong wrote: > >> Hi Simon, >> >> I tried with forkIO and added another dowork functions but the result is >> the same: only one core is used, three other cores are idle. Do you have any >> other suggestions? Is there anything I should take care when installing GHC? >> >> I also did try the Wombat.hs from the tutorial, but only one core is used >> and the times are almost the same. >> >> seq sum: 119201850 >> seq time: 20.959932 seconds. >> par sum: 119201850 >> par time: 20.959547 seconds. >> > > Your program is suffering from microbenchmarkitis, I'm afraid. There's > only one spark, which tickles a bug in the scheduler in 6.10.1 and earlier > (but sometimes doesn't happen due to random scheduling behaviour). Even > with that fixed, the program uses fib which tickles another bug: when > optimised, fib doesn't do any allocation, and GHC's scheduler relies on > allocation happening at regular enough intervals. > > In 6.10.1 we never get to do load-balancing in this example, because fib > doesn't ever yield control to the scheduler. In HEAD, where we have > work-stealing and don't rely on the scheduler for load-balancing, the > load-balancing problem goes away but reveals another problem: the second > thread wants to GC, but in order to GC it has to synchronise with the other > running threads, but the other thread is running fib and never yields. We > can fix this by allowing CPUs to GC independently (which we plan to do), but > even then you could still run into the same problem because eventually a > global GC will be required. If you really want to see the program running > in parallel, turn off -O. > > Cheers, > Simon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081210/da4bf3c4/attachment.htm From jgoerzen at complete.org Wed Dec 10 12:12:28 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Dec 10 12:05:29 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> Message-ID: <493FF87C.9080707@complete.org> Brian B wrote: > Hi Bulat, > > My contribution to the survey: I've used forkProcess to daemonize > a ghc program inside the haskell fuse bindings: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse > http://code.haskell.org/hfuse/System/Fuse.hsc > > If removing the non-threaded RTS would break forkProcess entirely, > these bindings would have to do something different. The issue: users > of the FUSE C api will get daemonized using daemon(2); it'd be > nice if GHC fuse programs could behave similarly. I also use forkProcess extensively: in HSH, for instance, which is used by hpodder, twidge, and a host of other tools. Removing the ability to use forkProcess removes the ability to write a Unix shell in Haskell, or to do anything shell-like, or anything even mildly advanced involving piping, file descriptors, and the like. I would see it as a significant regression. The System.Process calls, last I checked (in 6.8.x) were both too buggy to use for complex tasks, and too inadequate for some (though the adequacy has been improving.) -- John From john at repetae.net Wed Dec 10 14:19:59 2008 From: john at repetae.net (John Meacham) Date: Wed Dec 10 14:13:04 2008 Subject: IMCROSS and ghc Message-ID: <20081210191959.GP18561@sliver.repetae.net> I was wondering if anyone has gotten ghc to work with IMCROSS[1]. I'm Cross is a way to build native windows and mac osx apps on linux. quite convinient for making distribution packages for those other platforms or if you want to use linux's toolset during your build. basically, IMCROSS installs a couple new gccs with names like /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get ghc to use said non-native compiler as its back end? It seems that ghc will also need to build the libraries with different #define's as well to reflect the target windows or mac environment. [1] http://www.sandroid.org/imcross/ John -- John Meacham - ?repetae.net?john? From duncan.coutts at worc.ox.ac.uk Wed Dec 10 16:53:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Dec 10 16:46:38 2008 Subject: IMCROSS and ghc In-Reply-To: <20081210191959.GP18561@sliver.repetae.net> References: <20081210191959.GP18561@sliver.repetae.net> Message-ID: <1228946012.10115.531.camel@localhost> On Wed, 2008-12-10 at 11:19 -0800, John Meacham wrote: > I was wondering if anyone has gotten ghc to work with IMCROSS[1]. I'm > Cross is a way to build native windows and mac osx apps on linux. quite > convinient for making distribution packages for those other platforms or > if you want to use linux's toolset during your build. > > basically, IMCROSS installs a couple new gccs with names like > /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get ghc > to use said non-native compiler as its back end? It seems that ghc will > also need to build the libraries with different #define's as well to > reflect the target windows or mac environment. It sounds like you would need to set ghc up as a cross-compiler. I'm told that this there is a fair bit of work required to get ghc to support cross-compilation. I expect Ian or Simon could provide more details on what would need doing if you're interested in pursuing it. Duncan From marlowsd at gmail.com Thu Dec 11 05:03:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 11 04:56:19 2008 Subject: IMCROSS and ghc In-Reply-To: <1228946012.10115.531.camel@localhost> References: <20081210191959.GP18561@sliver.repetae.net> <1228946012.10115.531.camel@localhost> Message-ID: <4940E564.4090803@gmail.com> Duncan Coutts wrote: > On Wed, 2008-12-10 at 11:19 -0800, John Meacham wrote: >> I was wondering if anyone has gotten ghc to work with IMCROSS[1]. I'm >> Cross is a way to build native windows and mac osx apps on linux. quite >> convinient for making distribution packages for those other platforms or >> if you want to use linux's toolset during your build. >> >> basically, IMCROSS installs a couple new gccs with names like >> /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get ghc >> to use said non-native compiler as its back end? It seems that ghc will >> also need to build the libraries with different #define's as well to >> reflect the target windows or mac environment. > > It sounds like you would need to set ghc up as a cross-compiler. I'm > told that this there is a fair bit of work required to get ghc to > support cross-compilation. I expect Ian or Simon could provide more > details on what would need doing if you're interested in pursuing it. Right - the stage 1 compiler has to be a cross-compiler, running on the host system and generating binaries for the target system. Bits of the infrastructure are in place (i.e. we make some attempt to use the right _HOST_ARCH vs. TARGET_ARCH #defines), but we've never actually done real cross-compilation with GHC so I imagine there will be various things to fix. The build system probably assumes that host==target in lots of places. Cheers, Simon From marlowsd at gmail.com Thu Dec 11 05:38:17 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 11 05:31:16 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4940ED99.7030101@gmail.com> Malcolm Wallace wrote: >>> Had you deprecated the non-threaded RTS, we would probably have no >>> problems described in ticket #2848 :-/ >>> I think you'll have to deprecate it anyway, because it will be more >>> and more difficult to maintain two versions of code, >> we may conduct small survey on amount of usage of old RTS (i mean ask >> this in haskell-cafe) > > For the only application I tried, using the threaded RTS imposes a 100% > performance penalty - i.e. computation time doubles, compared to the > non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has > improved since then? This is a guess, but I wonder if this program is concurrent, and does a lot of communication between the main thread and other threads? The main thread is a bound thread, which means that communication between the main thread and any other thread is much more expensive than communication between unbound threads, because it involves full OS-level context switches. In a concurrent program, don't use the main thread to do any real work, do a forkIO and wait for the child to complete. Certainly a 2x performance overhead for the threaded RTS is not something we normally see. There will be an overhead for MVars and STM, but even then I'd consider 2x to be deeply suspicious. For most programs, the overhead should be close to zero. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Thu Dec 11 05:35:43 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Dec 11 05:32:45 2008 Subject: IMCROSS and ghc In-Reply-To: <20081210191959.GP18561@sliver.repetae.net> References: <20081210191959.GP18561@sliver.repetae.net> Message-ID: <20081211103543.57b4dd6f.Malcolm.Wallace@cs.york.ac.uk> > basically, IMCROSS installs a couple new gccs with names like > /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get > ghc to use said non-native compiler as its back end? I don't know about IMCROSS specifically, but earlier this year Sylvain Nahas adapted the build system of nhc98 to allow it to become a cross-compiler. At configure time, you simply give some additional arguments to point to the C cross-compilation toolchain, e.g. ./configure --target=i386-mingw --hostcc=i386-mingw-gcc --hoststrip=... --endian=-DLOW_BYTE_FIRST --ccoption=... --ldoption=... Regards, Malcolm From marlowsd at gmail.com Thu Dec 11 05:41:24 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 11 05:34:23 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> Message-ID: <4940EE54.9030504@gmail.com> Brian B wrote: > Hi Bulat, > > My contribution to the survey: I've used forkProcess to daemonize > a ghc program inside the haskell fuse bindings: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse > http://code.haskell.org/hfuse/System/Fuse.hsc > > If removing the non-threaded RTS would break forkProcess entirely, > these bindings would have to do something different. The issue: users > of the FUSE C api will get daemonized using daemon(2); it'd be > nice if GHC fuse programs could behave similarly. forkProcess should work with the threaded RTS, as long as you don't enable multiple cores with +RTS -N. However, forking is a pretty tricky operation in a multi-threaded environment, and that's where the difficulty comes from. Cheers, Simon > Thanks, > Brian Bloniarz > > > Hello Tomasz, > > > > Saturday, December 6, 2008, 10:52:39 PM, you wrote: > > > > > Had you deprecated the non-threaded RTS, we would probably have no > problems > > > described in ticket #2848 :-/ > > > > > I think you'll have to deprecate it anyway, because it will be more > > > and more difficult > > > to maintain two versions of code, especially if one of them will be > > > much less used and > > > tested. > > > > we may conduct small survey on amount of usage of old RTS (i mean ask > > this in haskell-cafe) > > > > > > -- > > Best regards, > > Bulat mailto:Bulat.Ziganshin@gmail.com > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ------------------------------------------------------------------------ > Connect to the next generation of MSN Messenger Get it now! > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Thu Dec 11 05:53:56 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 11 05:46:55 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <493FF87C.9080707@complete.org> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <493FF87C.9080707@complete.org> Message-ID: <4940F144.5080307@gmail.com> John Goerzen wrote: > Brian B wrote: >> Hi Bulat, >> >> My contribution to the survey: I've used forkProcess to daemonize >> a ghc program inside the haskell fuse bindings: >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse >> http://code.haskell.org/hfuse/System/Fuse.hsc >> >> If removing the non-threaded RTS would break forkProcess entirely, >> these bindings would have to do something different. The issue: users >> of the FUSE C api will get daemonized using daemon(2); it'd be >> nice if GHC fuse programs could behave similarly. > > I also use forkProcess extensively: in HSH, for instance, which is used > by hpodder, twidge, and a host of other tools. Removing the ability to > use forkProcess removes the ability to write a Unix shell in Haskell, or > to do anything shell-like, or anything even mildly advanced involving > piping, file descriptors, and the like. I would see it as a significant > regression. Have you tried those apps with the threaded RTS? I'd be interested to know whether they work as expected. I'm not suggesting we remove the non-threaded RTS, however perhaps there's an argument for making -threaded the default. After all, that's what you get with GHCi by default right now. Maintaining both versions of the RTS is certainly a burden, but I think it's one we have to carry, since there are still reasons to want both. > The System.Process calls, last I checked (in 6.8.x) were both too buggy > to use for complex tasks, and too inadequate for some (though the > adequacy has been improving.) If there's bugginess we need to get it fixed - please report those bugs! Cheers, Simon From jgoerzen at complete.org Thu Dec 11 10:52:16 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Dec 11 10:45:14 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <4940F144.5080307@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <493FF87C.9080707@complete.org> <4940F144.5080307@gmail.com> Message-ID: <49413730.3050906@complete.org> Simon Marlow wrote: > John Goerzen wrote: >> Brian B wrote: >>> Hi Bulat, >>> >>> My contribution to the survey: I've used forkProcess to daemonize >>> a ghc program inside the haskell fuse bindings: >>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse >>> http://code.haskell.org/hfuse/System/Fuse.hsc >>> >>> If removing the non-threaded RTS would break forkProcess entirely, >>> these bindings would have to do something different. The issue: users >>> of the FUSE C api will get daemonized using daemon(2); it'd be >>> nice if GHC fuse programs could behave similarly. >> I also use forkProcess extensively: in HSH, for instance, which is used >> by hpodder, twidge, and a host of other tools. Removing the ability to >> use forkProcess removes the ability to write a Unix shell in Haskell, or >> to do anything shell-like, or anything even mildly advanced involving >> piping, file descriptors, and the like. I would see it as a significant >> regression. > > Have you tried those apps with the threaded RTS? I'd be interested to > know whether they work as expected. I have, and it didn't work well. But it's been awhile, and I can't tell you anymore what version of GHC or what exactly the problem was. I was most certainly 6.8 or older. Once 6.10 hits Debian, I could test again there. But see below... > I'm not suggesting we remove the non-threaded RTS, however perhaps > there's an argument for making -threaded the default. After all, that's > what you get with GHCi by default right now. That's probably an OK solution. I would also add: does the threaded RTS support all platforms? For instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't run there, but GHC does. If you drop the non-threaded RTS, does that mean that GHC doesn't work there at all? >> The System.Process calls, last I checked (in 6.8.x) were both too buggy >> to use for complex tasks, and too inadequate for some (though the >> adequacy has been improving.) > > If there's bugginess we need to get it fixed - please report those bugs! Already done: http://hackage.haskell.org/trac/ghc/ticket/1780 (still open since Nov 2007) There was also a thread here regarding problems with the threaded RTS: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11573.html Not sure if that has been fixed, or was an error on my part, but see your reply at: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11585.html I admit I haven't had the chance to reread that whole thread, so my apologies if this is a red herring. -- John From marlowsd at gmail.com Thu Dec 11 11:49:42 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 11 11:42:41 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <49413730.3050906@complete.org> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <493FF87C.9080707@complete.org> <4940F144.5080307@gmail.com> <49413730.3050906@complete.org> Message-ID: <494144A6.6080701@gmail.com> John Goerzen wrote: > Simon Marlow wrote: >> John Goerzen wrote: >>> Brian B wrote: >>>> Hi Bulat, >>>> >>>> My contribution to the survey: I've used forkProcess to daemonize >>>> a ghc program inside the haskell fuse bindings: >>>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse >>>> http://code.haskell.org/hfuse/System/Fuse.hsc >>>> >>>> If removing the non-threaded RTS would break forkProcess entirely, >>>> these bindings would have to do something different. The issue: users >>>> of the FUSE C api will get daemonized using daemon(2); it'd be >>>> nice if GHC fuse programs could behave similarly. >>> I also use forkProcess extensively: in HSH, for instance, which is used >>> by hpodder, twidge, and a host of other tools. Removing the ability to >>> use forkProcess removes the ability to write a Unix shell in Haskell, or >>> to do anything shell-like, or anything even mildly advanced involving >>> piping, file descriptors, and the like. I would see it as a significant >>> regression. >> Have you tried those apps with the threaded RTS? I'd be interested to >> know whether they work as expected. > > I have, and it didn't work well. But it's been awhile, and I can't tell > you anymore what version of GHC or what exactly the problem was. I was > most certainly 6.8 or older. Once 6.10 hits Debian, I could test again > there. But see below... > >> I'm not suggesting we remove the non-threaded RTS, however perhaps >> there's an argument for making -threaded the default. After all, that's >> what you get with GHCi by default right now. > > That's probably an OK solution. > > I would also add: does the threaded RTS support all platforms? For > instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't > run there, but GHC does. If you drop the non-threaded RTS, does that > mean that GHC doesn't work there at all? If those platforms support threads, there's no reason why the threaded RTS shouldn't work there. Also, GHCi should work on all platforms (even unregisterised) these days, including the FFI if there's support in libffi for that platform. However, if if the threaded RTS doesn't work on a platform for some reason, that doesn't prevent us just falling back to the non-threaded RTS for that platform. Most things will still work. >>> The System.Process calls, last I checked (in 6.8.x) were both too buggy >>> to use for complex tasks, and too inadequate for some (though the >>> adequacy has been improving.) >> If there's bugginess we need to get it fixed - please report those bugs! > > Already done: > > http://hackage.haskell.org/trac/ghc/ticket/1780 > (still open since Nov 2007) That one is closed - fixed in 6.8.3 I think. > There was also a thread here regarding problems with the threaded RTS: > > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11573.html > > Not sure if that has been fixed, or was an error on my part, but see > your reply at: > > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11585.html I did make a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/1185 That should be fixable - I'll put it on the current milestone. Cheers, Simon From jgoerzen at complete.org Thu Dec 11 12:00:08 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Dec 11 11:53:04 2008 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <494144A6.6080701@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <493FF87C.9080707@complete.org> <4940F144.5080307@gmail.com> <49413730.3050906@complete.org> <494144A6.6080701@gmail.com> Message-ID: <49414718.2040309@complete.org> Simon Marlow wrote: >> I would also add: does the threaded RTS support all platforms? For >> instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't >> run there, but GHC does. If you drop the non-threaded RTS, does that >> mean that GHC doesn't work there at all? > > If those platforms support threads, there's no reason why the threaded > RTS shouldn't work there. Also, GHCi should work on all platforms (even > unregisterised) these days, including the FFI if there's support in > libffi for that platform. That's very good to hear. >> http://hackage.haskell.org/trac/ghc/ticket/1780 >> (still open since Nov 2007) > > That one is closed - fixed in 6.8.3 I think. Oops, my mistake. I'll look into it again. >> http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11585.html > > I did make a ticket for that: > > http://hackage.haskell.org/trac/ghc/ticket/1185 #1 way to tell you are a Haskell geek: * milestone changed from _|_ to 6.10.2. Thanks, Simon. -- John From barney_stratford at fastmail.fm Fri Dec 12 04:36:09 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Fri Dec 12 04:29:02 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <493FB0A6.5080505@gmail.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <20081203203121.GA13500@matrix.chaos.earth.li> <1228397013.1346.1288235643@webmail.messagingengine.com> <493FB0A6.5080505@gmail.com> Message-ID: <1229074569.8624.1289676315@webmail.messagingengine.com> > The right place to add this would be in rts/package.conf.in, in extra-ld- > opts, with suitable platform-specific #ifdefs. If you can whip up a > patch and test it, I'll commit. Here's the patch, which now compiles correctly. diff -u a/rts/package.conf.in b/rts/package.conf.in --- a/rts/package.conf.in Mon Dec 10 18:11:32 2007 +++ b/rts/package.conf.in Thu Dec 11 09:36:54 2008 @@ -150,6 +150,10 @@ , "-u", "base_GHCziConc_ensureIOManagerIsRunning_closure" #endif +#ifdef darwin_HOST_OS + , "-read_only_relocs", "warning" +#endif + framework-dirs: #ifdef HAVE_FRAMEWORK_GMP Cheers, Barney. From Malcolm.Wallace at cs.york.ac.uk Fri Dec 12 09:03:34 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Dec 12 08:57:36 2008 Subject: ghci and ghc -threaded [slowdown] In-Reply-To: <4940ED99.7030101@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> <4940ED99.7030101@gmail.com> Message-ID: <20081212140334.4b90d952.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > Malcolm Wallace wrote: > > > > For the only application I tried, using the threaded RTS imposes a > > 100% performance penalty - i.e. computation time doubles, compared > > to the non-threaded RTS. This was with ghc-6.8.2, and maybe the > > overhead has improved since then? > > This is a guess, but I wonder if this program is concurrent, and does > a lot of communication between the main thread and other threads? Exactly so - it hits the worst case behaviour. This was a naive attempt to parallelise an algorithm by shifting some work onto a spare processor. Unfortunately, there is a lot of communication to the main thread, because the work that was shifted elsewhere computes a large data structure in chunks, and passes those chunks back. The main thread then runs OpenGL calls using this data -- and I believe OpenGL calls must run in a bound thread. This all suggests that one consequence of ghc's RTS implementation choices is that it will never be cheap to compute visualization data in parallel with rendering it in OpenGL. That would be a shame. This was exactly the parallelism I was hoping for. Regards, Malcolm From alios at alios.org Fri Dec 12 09:43:45 2008 From: alios at alios.org (Markus Barenhoff) Date: Fri Dec 12 09:36:46 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <493FCA3B.70002@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> Message-ID: <20081212144345.GA90078@beteigeuze.alios.net> On Wed 10.12 13:55, Simon Marlow wrote: Hi! > >>>I checked out and translated the head version of ghc today from darcs. > >>>It compiled fine. When I now try to start the ghci I get the following: > >>> > >>>---- snip ---- > >>>GHCi, version 6.11.20081126: http://www.haskell.org/ghc/ :? for help > >>>ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked > >>>for 626688 bytes at 0x40000000, got 0x801635000. Try specifying an > >>>address with +RTS -xm -RTS > >>> (GHC version 6.11.20081126 for x86_64_unknown_freebsd) > >>> Please report this as a GHC bug: > >>> http://www.haskell.org/ghc/reportabug > >>> Abort (core dumped) > >>>---- snip ---- > >>> > >>>If it helps somehow, you can find the core dump here: > >>>http://www.alios.org/~alios/ghc.core.bz2 > >>That's odd, because 6.8.3 is using 0x40000000 on FreeBSD and is working > >>fine (or is it?). > > > >yes, it worked, but I haven't installed anymore - so I'am not sure, where > >it > >does maps its stuff into memory. > > The memory map shows that there's nothing mapped in at the place we're > asking for memory, but still FreeBSD decides to give us memory somewhere > else. I checked back in 6.8.3 and it looks like we were using MAP_FIXED - > now MAP_FIXED is dangerous, because it will overwrite existing mappings > (like the binary itself!), which is why we're not doing that now. > > I've committed a patch that uses MAP_FIXED on FreeBSD if other attempts to > get memory below 2Gb fail. I'd be grateful if you could test it out, the > patch is this one, pushed to HEAD today: > > Wed Dec 10 11:57:51 GMT 2008 Simon Marlow > * On FreeBSD, try MAP_FIXED if ordinary mmap() fails to give us suitable > memory > This appears to be necessary on FreeBSD. It might be necessary on > other OSs too, but I'm being cautious because using MAP_FIXED can lead > to crashes by overwriting existing mappings, and we have no (easy) way > to prevent that. I've updated my source tree today. But now I've problem while compiling the ghc Here is the the build output: [...] /usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.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 <> gmake[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1 gmake[3]: *** [all] Error 1 gmake[3]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc/compiler' gmake[2]: *** [build.stage.2] Error 2 gmake[2]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc/compiler' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc' gmake: *** [bootstrap2] Error 2 Regards Markus -- Markus Barenhoff - Langemarckstr. 18 - D-48147 M?nster - Germany - Europe - Earth Tel. +49-251-3956651 - Mob. +49-173-7215776 - e-mail: alios@alios.org jabber: alios@jabber.ccc.de - icq: 27998346 -------------- 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/20081212/8798d973/attachment.bin From igloo at earth.li Fri Dec 12 10:50:23 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Dec 12 10:43:16 2008 Subject: ghc-paths In-Reply-To: <493D1D5A.7020207@gmail.com> References: <9436bffe0812050007g69de7eava3151514ee915515@mail.gmail.com> <493D1D5A.7020207@gmail.com> Message-ID: <20081212155023.GA21843@matrix.chaos.earth.li> On Mon, Dec 08, 2008 at 01:12:58PM +0000, Simon Marlow wrote: > Jens Petersen wrote: > >Are there any plans to include ghc-paths in ghc itself? > > Not at present. It's more difficult to ship it with GHC than it is to > build it post-installation, because it is essentially compiled code that > depends on an install-time variable. Various hairbrained schemes were > proposed on cvs-ghc a while back, but I'm not aware of any easy solutions > to this problem. Also, if you're installing with cabal-install then it should be installed for you automatically. Thanks Ian From ben.horsfall at gmail.com Sun Dec 14 20:17:55 2008 From: ben.horsfall at gmail.com (Ben Horsfall) Date: Sun Dec 14 20:10:42 2008 Subject: Type families: module export of instance data constructor Message-ID: I have a type family class Lang term where data Token term :: * : with instance Lang Term where newtype Token Term = T String : I can't work out how to export the type constructor T from the module, unless I make no explict exports from the module at all. Ben From prj at po.cwru.edu Mon Dec 15 00:46:39 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Mon Dec 15 00:39:27 2008 Subject: runghc error with glibc 2.8: unknown symbol `fstat64' Message-ID: I get this error when running a script with runghc, if ghc was built againt glibc 2.8: ghc: /package/host/code.dogmap.org/foreign/ghc-6.10.1+spf+0/prefix/lib/ghc-6.10.1/base-4.0.0.0/HSbase-4.0.0.0.o: unknown symbol `fstat64' ghc: unable to load package `base' With glibc 2.6.1, it works. (At least, ghc 6.8.3 works with glibc 2.6.1. I didn't try ghc 6.10.1 with glibc 2.6.1, but ghc 6.8.3 gives the same error with glibc 2.8, so the ghc version doesn't seem to matter.) The output from "make" when building ghc didn't have any linking errors/warnings related to HSbase, as far as I can see. Has anyone seen anything like this? Any ideas? paul From marlowsd at gmail.com Mon Dec 15 04:26:53 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 15 04:19:43 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <20081212144345.GA90078@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> Message-ID: <494622DD.4060900@gmail.com> Markus Barenhoff wrote: > I've updated my source tree today. > > But now I've problem while compiling the ghc > > Here is the the build output: > > [...] > > /usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0. 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'. Cheers, Simon From marlowsd at gmail.com Mon Dec 15 08:23:51 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 15 08:16:38 2008 Subject: ghci and ghc -threaded [slowdown] In-Reply-To: <20081212140334.4b90d952.Malcolm.Wallace@cs.york.ac.uk> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> <4940ED99.7030101@gmail.com> <20081212140334.4b90d952.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <49465A67.4040705@gmail.com> Malcolm Wallace wrote: > Simon Marlow wrote: > >> Malcolm Wallace wrote: >>> For the only application I tried, using the threaded RTS imposes a >>> 100% performance penalty - i.e. computation time doubles, compared >>> to the non-threaded RTS. This was with ghc-6.8.2, and maybe the >>> overhead has improved since then? >> This is a guess, but I wonder if this program is concurrent, and does >> a lot of communication between the main thread and other threads? > > Exactly so - it hits the worst case behaviour. This was a naive attempt > to parallelise an algorithm by shifting some work onto a spare > processor. Unfortunately, there is a lot of communication to the main > thread, because the work that was shifted elsewhere computes a large > data structure in chunks, and passes those chunks back. The main thread > then runs OpenGL calls using this data -- and I believe OpenGL calls must > run in a bound thread. > > This all suggests that one consequence of ghc's RTS implementation > choices is that it will never be cheap to compute visualization data in > parallel with rendering it in OpenGL. That would be a shame. This was > exactly the parallelism I was hoping for. I'm not sure how we could do any better here. To get parallelism you need to run the OpenGL thread and the worker thread on separate OS threads, which we do. So what aspect of the RTS design is preventing you from getting the parallelism you want? It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. If you still do asynchronous communication and yet don't get good parallelism, then we should look into what's causing that. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Mon Dec 15 08:49:43 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Dec 15 08:47:25 2008 Subject: ghci and ghc -threaded [slowdown] In-Reply-To: <49465A67.4040705@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> <4940ED99.7030101@gmail.com> <20081212140334.4b90d952.Malcolm.Wallace@cs.york.ac.uk> <49465A67.4040705@gmail.com> Message-ID: <20081215134943.0d741b5f.Malcolm.Wallace@cs.york.ac.uk> > It seems that the problem you have is that moving to the multithreaded > runtime imposes an overhead on the communication between your two > threads, when run on a *single CPU*. But performance on a single CPU > is not what you're interested in - you said you wanted parallelism, > and for that you need multiple CPUs, and hence multiple OS threads. Well, I'm interested in getting an absolute speedup. If the threaded performance on a single core is slightly slower than the non-threaded performance on a single core, that would be OK provided that the threaded performance using multiple cores was better than the same non-threaded baseline. However, it doesn't seem to work like that at all. In fact, threaded on multiple cores was _even_slower_ than threaded on a single core! Here are some figures: ghc-6.8.2 -O2 apply MVar strict thr-N2 thr-N1 silicium 7.30 7.95 7.23 15.25 14.71 neghip 4.25 4.43 4.18 6.67 6.48 hydrogen 11.75 10.82 10.99 13.45 12.96 lobster 55.8 51.5 57.6 76.6 74.5 The first three columns are variations of the program using slightly different communications mechanisms, including threads/MVars with the non-threaded RTS. The final two columns are for the MVar mechanism with threaded RTS and either 1 or 2 cores. -N2 is slowest. > I suspect the underlying problem in your program is that the > communication is synchronous. To get good parallelism you'll need to > use asynchronous communication, otherwise even on multiple CPUs > you'll see little parallelism. I tried using Chans instead of MVars, to provide for different speeds of reader/writer, but the timings were even worse. (Add another 15-100%.) When I have time to look at this again (probably in the New Year), I will try some other strategies for communication that vary in their synchronous/asynchronous chunk size, to see if I can pin things down more closely. Regards, Malcolm From marlowsd at gmail.com Mon Dec 15 10:02:14 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 15 09:55:02 2008 Subject: ghci and ghc -threaded [slowdown] In-Reply-To: <20081215134943.0d741b5f.Malcolm.Wallace@cs.york.ac.uk> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> <4940ED99.7030101@gmail.com> <20081212140334.4b90d952.Malcolm.Wallace@cs.york.ac.uk> <49465A67.4040705@gmail.com> <20081215134943.0d741b5f.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <49467176.5070803@gmail.com> Malcolm Wallace wrote: >> It seems that the problem you have is that moving to the multithreaded >> runtime imposes an overhead on the communication between your two >> threads, when run on a *single CPU*. But performance on a single CPU >> is not what you're interested in - you said you wanted parallelism, >> and for that you need multiple CPUs, and hence multiple OS threads. > > Well, I'm interested in getting an absolute speedup. If the threaded > performance on a single core is slightly slower than the non-threaded > performance on a single core, that would be OK provided that the > threaded performance using multiple cores was better than the same > non-threaded baseline. > > However, it doesn't seem to work like that at all. In fact, threaded on > multiple cores was _even_slower_ than threaded on a single core! Entirely possible - unless there's any actual parallelism, running on multiple cores will probably slow things down due to thread migration. > Here are some figures: > > ghc-6.8.2 -O2 > apply MVar strict thr-N2 thr-N1 > silicium 7.30 7.95 7.23 15.25 14.71 > neghip 4.25 4.43 4.18 6.67 6.48 > hydrogen 11.75 10.82 10.99 13.45 12.96 > lobster 55.8 51.5 57.6 76.6 74.5 > > The first three columns are variations of the program using slightly > different communications mechanisms, including threads/MVars with the > non-threaded RTS. The final two columns are for the MVar mechanism > with threaded RTS and either 1 or 2 cores. -N2 is slowest. So you're not getting any parallelism at all, for some reason your program is sequentialised. There could be any number of reasons for this. >> I suspect the underlying problem in your program is that the >> communication is synchronous. To get good parallelism you'll need to >> use asynchronous communication, otherwise even on multiple CPUs >> you'll see little parallelism. > > I tried using Chans instead of MVars, to provide for different speeds of > reader/writer, but the timings were even worse. (Add another 15-100%.) That would seem to indicate that your program is doing a lot of communication - I'd look at trying to reduce that, by increasing task size or whatever. However, the amount of communication is obviously not the only issue, there also seems to be some kind of dependency that sequentialises the program. Are you sure that you're not accidentally communicating thunks, and hence doing all the computation in one of the threads? That's a common pitfall that has caught me more than once. Do you know roughly the amount of parallelism you expect - i.e. the amount of work done by each thread? > When I have time to look at this again (probably in the New Year), I > will try some other strategies for communication that vary in their > synchronous/asynchronous chunk size, to see if I can pin things down > more closely. That would be good. At some point we hope to provide some kind of visualisation to let you see where the parallel performance bottlenecks in your program are; there are various ongoing efforts but nothing useable as yet. Cheers, Simon From dgorin at dc.uba.ar Mon Dec 15 16:10:29 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Mon Dec 15 16:03:23 2008 Subject: length of module name affecting performance?? Message-ID: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> Hi While trying to see if I could make some code run faster I stumbled upon something that looks weird to me: 2x-3x performance loss when a module is renamed to a longer name! Here's what I see with the attached examples: #diff long-modname-ver.hs short-modname-ver.hs 2c2 < import VeryLongModuleName --- > import ShortM #diff VeryLongModuleName.hs ShortM.hs 1c1 < module VeryLongModuleName --- > module ShortM #ghc --make -O2 -Wall long-modname-ver.hs #ghc --make -O2 -Wall short-modname-ver.hs #time -p ./long-modname-ver > /dev/null real 55.90 user 55.17 sys 0.51 #time -p ./short-modname-ver > /dev/null real 22.23 user 21.97 sys 0.10 I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? Thanks Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: files.tgz Type: application/octet-stream Size: 5330 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081215/24727ee0/files-0001.obj -------------- next part -------------- From dons at galois.com Mon Dec 15 16:53:43 2008 From: dons at galois.com (Don Stewart) Date: Mon Dec 15 16:47:43 2008 Subject: length of module name affecting performance?? In-Reply-To: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> Message-ID: <20081215215343.GA31363@scytale.galois.com> dgorin: > Hi > > While trying to see if I could make some code run faster I stumbled > upon something that looks weird to me: 2x-3x performance loss when a > module is renamed to a longer name! > > Here's what I see with the attached examples: > > #diff long-modname-ver.hs short-modname-ver.hs > 2c2 > < import VeryLongModuleName > --- > > import ShortM > > #diff VeryLongModuleName.hs ShortM.hs > 1c1 > < module VeryLongModuleName > --- > > module ShortM > > #ghc --make -O2 -Wall long-modname-ver.hs > > #ghc --make -O2 -Wall short-modname-ver.hs > > #time -p ./long-modname-ver > /dev/null > real 55.90 > user 55.17 > sys 0.51 > > #time -p ./short-modname-ver > /dev/null > real 22.23 > user 21.97 > sys 0.10 > > I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? Wow. Awesome bug! Got lots of discussion at Galois :) I can confirm a difference in running time, we also tested with 6.8.x and 6.10, with similar results. ./short-modname-ver > /dev/null 21.55s user 0.02s system 99% cpu 21.573 total ./long-modname-ver > /dev/null 53.79s user 0.14s system 99% cpu 54.113 total $ diff -a short-modname-ver.hs long-modname-ver.hs 2c2 < import ShortM --- > import VeryLongModuleName $ diff -u ShortM.hs VeryLongModuleName.hs --- ShortM.hs 2008-12-15 12:00:53.000000000 -0800 +++ VeryLongModuleName.hs 2008-12-15 12:39:33.000000000 -0800 @@ -1,4 +1,4 @@ -module ShortM +module VeryLongModuleName where Looking at the core (GHC has a hard time with that huge constant), we don't see anything, but the assembly is surprisingly different! http://galois.com/~dons/tmp/asm.diff The interesting parts are the indirect jumps that appear, and some extra indirection closures are constructed: +VeryLongModuleName_zdsadd_srt: + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_zdsadd_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_zdsadd1_closure + .quad VeryLongModuleName_lvl3_closure +.section .data + .align 8 +VeryLongModuleName_zdsadd1_srt: + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_zdsadd_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_zdsadd1_closure + .quad VeryLongModuleName_lvl3_closure And - movq 24(%rbp),%rbx - addq $40,%rbp - andq $-8,%rbx - jmp *(%rbx) + movq 16(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_right_info So we get some indirection through an info table that we didn't have before. My guess is there's some jump table heuristic/cost function that for some reason includes the size of data in those error strings? The error strings which go over the limit, when they've big strings in them This is a job for Simon^2. -- Don ------------------------------------------------------------------------ Attached below is the asm diffs: --- /tmp/ghc5331_0/ghc5331_0.s 2008-12-15 13:28:36.000000000 -0800 +++ /tmp/ghc5324_0/ghc5324_0.s 2008-12-15 13:28:22.000000000 -0800 @@ -1,13 +1,13 @@ .section .data .align 8 -ShortM_lvl_srt: +VeryLongModuleName_lvl_srt: .quad base_ControlziExceptionziBase_recSelError_closure .data .align 8 -.globl ShortM_lvl_closure -.type ShortM_lvl_closure, @object -ShortM_lvl_closure: - .quad ShortM_lvl_info +.globl VeryLongModuleName_lvl_closure +.type VeryLongModuleName_lvl_closure, @object +VeryLongModuleName_lvl_closure: + .quad VeryLongModuleName_lvl_info .quad 0 .quad 0 .quad 0 @@ -42,12 +42,24 @@ .byte 111 .byte 114 .byte 32 - .byte 83 - .byte 104 - .byte 111 + .byte 86 + .byte 101 .byte 114 - .byte 116 + .byte 121 + .byte 76 + .byte 111 + .byte 110 + .byte 103 .byte 77 + .byte 111 + .byte 100 + .byte 117 + .byte 108 + .byte 101 + .byte 78 + .byte 97 + .byte 109 + .byte 101 .byte 46 .byte 110 .byte 101 @@ -56,13 +68,13 @@ .byte 0 .text .align 8 - .long ShortM_lvl_srt-(ShortM_lvl_info)+0 + .long VeryLongModuleName_lvl_srt-(VeryLongModuleName_lvl_info)+0 .long 0 .quad 0 .quad 4294967318 -.globl ShortM_lvl_info -.type ShortM_lvl_info, @object -ShortM_lvl_info: +.globl VeryLongModuleName_lvl_info +.type VeryLongModuleName_lvl_info, @object +VeryLongModuleName_lvl_info: .L: leaq -16(%rbp),%rax cmpq %r14,%rax @@ -88,14 +100,14 @@ jmp *-16(%r13) .section .data .align 8 -ShortM_lvl1_srt: +VeryLongModuleName_lvl1_srt: .quad base_ControlziExceptionziBase_recSelError_closure .data .align 8 -.globl ShortM_lvl1_closure -.type ShortM_lvl1_closure, @object -ShortM_lvl1_closure: - .quad ShortM_lvl1_info +.globl VeryLongModuleName_lvl1_closure +.type VeryLongModuleName_lvl1_closure, @object +VeryLongModuleName_lvl1_closure: + .quad VeryLongModuleName_lvl1_info .quad 0 .quad 0 .quad 0 @@ -130,12 +142,24 @@ .byte 111 .byte 114 .byte 32 - .byte 83 - .byte 104 - .byte 111 + .byte 86 + .byte 101 .byte 114 - .byte 116 + .byte 121 + .byte 76 + .byte 111 + .byte 110 + .byte 103 .byte 77 + .byte 111 + .byte 100 + .byte 117 + .byte 108 + .byte 101 + .byte 78 + .byte 97 + .byte 109 + .byte 101 .byte 46 .byte 114 .byte 105 @@ -145,13 +169,13 @@ .byte 0 .text .align 8 - .long ShortM_lvl1_srt-(ShortM_lvl1_info)+0 + .long VeryLongModuleName_lvl1_srt-(VeryLongModuleName_lvl1_info)+0 .long 0 .quad 0 .quad 4294967318 -.globl ShortM_lvl1_info -.type ShortM_lvl1_info, @object -ShortM_lvl1_info: +.globl VeryLongModuleName_lvl1_info +.type VeryLongModuleName_lvl1_info, @object +VeryLongModuleName_lvl1_info: .L: leaq -16(%rbp),%rax cmpq %r14,%rax @@ -177,14 +201,14 @@ jmp *-16(%r13) .section .data .align 8 -ShortM_lvl2_srt: +VeryLongModuleName_lvl2_srt: .quad base_ControlziExceptionziBase_recSelError_closure .data .align 8 -.globl ShortM_lvl2_closure -.type ShortM_lvl2_closure, @object -ShortM_lvl2_closure: - .quad ShortM_lvl2_info +.globl VeryLongModuleName_lvl2_closure +.type VeryLongModuleName_lvl2_closure, @object +VeryLongModuleName_lvl2_closure: + .quad VeryLongModuleName_lvl2_info .quad 0 .quad 0 .quad 0 @@ -219,12 +243,24 @@ .byte 111 .byte 114 .byte 32 - .byte 83 - .byte 104 - .byte 111 + .byte 86 + .byte 101 .byte 114 - .byte 116 + .byte 121 + .byte 76 + .byte 111 + .byte 110 + .byte 103 .byte 77 + .byte 111 + .byte 100 + .byte 117 + .byte 108 + .byte 101 + .byte 78 + .byte 97 + .byte 109 + .byte 101 .byte 46 .byte 108 .byte 101 @@ -233,13 +269,13 @@ .byte 0 .text .align 8 - .long ShortM_lvl2_srt-(ShortM_lvl2_info)+0 + .long VeryLongModuleName_lvl2_srt-(VeryLongModuleName_lvl2_info)+0 .long 0 .quad 0 .quad 4294967318 -.globl ShortM_lvl2_info -.type ShortM_lvl2_info, @object -ShortM_lvl2_info: +.globl VeryLongModuleName_lvl2_info +.type VeryLongModuleName_lvl2_info, @object +VeryLongModuleName_lvl2_info: .L: leaq -16(%rbp),%rax cmpq %r14,%rax @@ -265,14 +301,14 @@ jmp *-16(%r13) .section .data .align 8 -ShortM_lvl3_srt: +VeryLongModuleName_lvl3_srt: .quad base_ControlziExceptionziBase_recSelError_closure .data .align 8 -.globl ShortM_lvl3_closure -.type ShortM_lvl3_closure, @object -ShortM_lvl3_closure: - .quad ShortM_lvl3_info +.globl VeryLongModuleName_lvl3_closure +.type VeryLongModuleName_lvl3_closure, @object +VeryLongModuleName_lvl3_closure: + .quad VeryLongModuleName_lvl3_info .quad 0 .quad 0 .quad 0 @@ -307,12 +343,24 @@ .byte 111 .byte 114 .byte 32 - .byte 83 - .byte 104 - .byte 111 + .byte 86 + .byte 101 .byte 114 - .byte 116 + .byte 121 + .byte 76 + .byte 111 + .byte 110 + .byte 103 .byte 77 + .byte 111 + .byte 100 + .byte 117 + .byte 108 + .byte 101 + .byte 78 + .byte 97 + .byte 109 + .byte 101 .byte 46 .byte 118 .byte 97 @@ -320,13 +368,13 @@ .byte 0 .text .align 8 - .long ShortM_lvl3_srt-(ShortM_lvl3_info)+0 + .long VeryLongModuleName_lvl3_srt-(VeryLongModuleName_lvl3_info)+0 .long 0 .quad 0 .quad 4294967318 -.globl ShortM_lvl3_info -.type ShortM_lvl3_info, @object -ShortM_lvl3_info: +.globl VeryLongModuleName_lvl3_info +.type VeryLongModuleName_lvl3_info, @object +VeryLongModuleName_lvl3_info: .L: leaq -16(%rbp),%rax cmpq %r14,%rax @@ -352,10 +400,10 @@ jmp *-16(%r13) .data .align 8 -.globl ShortM_zdWNode_closure -.type ShortM_zdWNode_closure, @object -ShortM_zdWNode_closure: - .quad ShortM_zdWNode_info +.globl VeryLongModuleName_zdWNode_closure +.type VeryLongModuleName_zdWNode_closure, @object +VeryLongModuleName_zdWNode_closure: + .quad VeryLongModuleName_zdWNode_info .text .align 8 .quad 259 @@ -365,7 +413,7 @@ addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq 16(%rbp),%rax movq %rax,-24(%r12) movq 8(%rbp),%rax @@ -424,9 +472,9 @@ .quad 17179869205 .quad 0 .quad 15 -.globl ShortM_zdWNode_info -.type ShortM_zdWNode_info, @object -ShortM_zdWNode_info: +.globl VeryLongModuleName_zdWNode_info +.type VeryLongModuleName_zdWNode_info, @object +VeryLongModuleName_zdWNode_info: .L: leaq -32(%rbp),%rax cmpq %r14,%rax @@ -441,78 +489,96 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_zdWNode_closure,%ebx + movl $VeryLongModuleName_zdWNode_closure,%ebx jmp *-8(%r13) +.section .data + .align 8 +VeryLongModuleName_nodeFor_srt: + .quad VeryLongModuleName_left_closure + .quad VeryLongModuleName_right_closure + .quad VeryLongModuleName_val_closure .data .align 8 -.globl ShortM_nodeFor_closure -.type ShortM_nodeFor_closure, @object -ShortM_nodeFor_closure: - .quad ShortM_nodeFor_info +.globl VeryLongModuleName_nodeFor_closure +.type VeryLongModuleName_nodeFor_closure, @object +VeryLongModuleName_nodeFor_closure: + .quad VeryLongModuleName_nodeFor_info + .quad 0 .text .align 8 - .quad 516 - .quad 34 + .long VeryLongModuleName_nodeFor_srt-(_info)+0 + .long 0 + .quad 66 + .quad 12884901922 _info: .L: - movq 7(%rbx),%rax - cmpq 32(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax jl .L - movq 7(%rbx),%rax - cmpq 32(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax je .L - movq 24(%rbp),%rbx - addq $40,%rbp - andq $-8,%rbx - jmp *(%rbx) + movq 16(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_right_info .L: - movq 8(%rbp),%rbx - addq $40,%rbp - andq $-8,%rbx - jmp *(%rbx) + movq 16(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_left_info .L: movq 16(%rbp),%rbx - addq $40,%rbp + addq $24,%rbp andq $-8,%rbx jmp *(%rbx) .text .align 8 + .long VeryLongModuleName_nodeFor_srt-(_info)+0 + .long 0 .quad 1 - .quad 34 + .quad 30064771106 +_info: +.L: + movq 7(%rbx),%rax + movq %rax,(%rbp) + movq 8(%rbp),%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info +.text + .align 8 + .long VeryLongModuleName_nodeFor_srt-(_info)+0 + .long 0 + .quad 1 + .quad 30064771106 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_Nil_closure+1,%ebx + movl $VeryLongModuleName_Nil_closure+1,%ebx addq $16,%rbp jmp *(%rbp) .L: - movq 6(%rbx),%rax - movq %rax,-16(%rbp) - movq %rbx,-8(%rbp) - movq 14(%rbx),%rax - movq %rax,(%rbp) movq 8(%rbp),%rax - movq 30(%rbx),%rcx - movq %rcx,8(%rbp) + movq %rbx,8(%rbp) movq %rax,%rbx - movq $_info,-24(%rbp) - addq $-24,%rbp + movq $_info,(%rbp) testq $7,%rbx jne _info jmp *(%rbx) .text .align 8 + .long VeryLongModuleName_nodeFor_srt-(VeryLongModuleName_nodeFor_info)+0 + .long 0 .quad 8589934604 .quad 0 - .quad 15 -.globl ShortM_nodeFor_info -.type ShortM_nodeFor_info, @object -ShortM_nodeFor_info: + .quad 30064771087 +.globl VeryLongModuleName_nodeFor_info +.type VeryLongModuleName_nodeFor_info, @object +VeryLongModuleName_nodeFor_info: .L: - leaq -40(%rbp),%rax + leaq -24(%rbp),%rax cmpq %r14,%rax jb .L movq %rsi,-8(%rbp) @@ -523,14 +589,14 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_nodeFor_closure,%ebx + movl $VeryLongModuleName_nodeFor_closure,%ebx jmp *-8(%r13) .data .align 8 -.globl ShortM_isNil_closure -.type ShortM_isNil_closure, @object -ShortM_isNil_closure: - .quad ShortM_isNil_info +.globl VeryLongModuleName_isNil_closure +.type VeryLongModuleName_isNil_closure, @object +VeryLongModuleName_isNil_closure: + .quad VeryLongModuleName_isNil_info .text .align 8 .quad 0 @@ -553,9 +619,9 @@ .quad 4294967301 .quad 0 .quad 15 -.globl ShortM_isNil_info -.type ShortM_isNil_info, @object -ShortM_isNil_info: +.globl VeryLongModuleName_isNil_info +.type VeryLongModuleName_isNil_info, @object +VeryLongModuleName_isNil_info: .L: leaq -8(%rbp),%rax cmpq %r14,%rax @@ -567,28 +633,28 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_isNil_closure,%ebx + movl $VeryLongModuleName_isNil_closure,%ebx jmp *-8(%r13) .data .align 8 -.globl ShortM_empty_closure -.type ShortM_empty_closure, @object -ShortM_empty_closure: - .quad ShortM_Nil_static_info +.globl VeryLongModuleName_empty_closure +.type VeryLongModuleName_empty_closure, @object +VeryLongModuleName_empty_closure: + .quad VeryLongModuleName_Nil_static_info .section .data .align 8 -ShortM_next_srt: - .quad ShortM_lvl_closure +VeryLongModuleName_val_srt: + .quad VeryLongModuleName_lvl3_closure .data .align 8 -.globl ShortM_next_closure -.type ShortM_next_closure, @object -ShortM_next_closure: - .quad ShortM_next_info +.globl VeryLongModuleName_val_closure +.type VeryLongModuleName_val_closure, @object +VeryLongModuleName_val_closure: + .quad VeryLongModuleName_val_info .quad 0 .text .align 8 - .long ShortM_next_srt-(_info)+0 + .long VeryLongModuleName_val_srt-(_info)+0 .long 0 .quad 0 .quad 4294967330 @@ -598,25 +664,33 @@ andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_lvl_closure,%ebx + movl $VeryLongModuleName_lvl3_closure,%ebx addq $8,%rbp andq $-8,%rbx jmp *(%rbx) .L: - movq 22(%rbx),%rbx + addq $16,%r12 + cmpq %r15,%r12 + ja .L + movq $ghczmprim_GHCziTypes_Izh_con_info,-8(%r12) + movq 30(%rbx),%rax + movq %rax,(%r12) + leaq -7(%r12),%rbx addq $8,%rbp - andq $-8,%rbx - jmp *(%rbx) + jmp *(%rbp) +.L: + movq $16,184(%r13) + jmp *-16(%r13) .text .align 8 - .long ShortM_next_srt-(ShortM_next_info)+0 + .long VeryLongModuleName_val_srt-(VeryLongModuleName_val_info)+0 .long 0 .quad 4294967301 .quad 0 .quad 4294967311 -.globl ShortM_next_info -.type ShortM_next_info, @object -ShortM_next_info: +.globl VeryLongModuleName_val_info +.type VeryLongModuleName_val_info, @object +VeryLongModuleName_val_info: .L: leaq -8(%rbp),%rax cmpq %r14,%rax @@ -628,22 +702,22 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_next_closure,%ebx + movl $VeryLongModuleName_val_closure,%ebx jmp *-8(%r13) .section .data .align 8 -ShortM_right_srt: - .quad ShortM_lvl1_closure +VeryLongModuleName_right_srt: + .quad VeryLongModuleName_lvl1_closure .data .align 8 -.globl ShortM_right_closure -.type ShortM_right_closure, @object -ShortM_right_closure: - .quad ShortM_right_info +.globl VeryLongModuleName_right_closure +.type VeryLongModuleName_right_closure, @object +VeryLongModuleName_right_closure: + .quad VeryLongModuleName_right_info .quad 0 .text .align 8 - .long ShortM_right_srt-(_info)+0 + .long VeryLongModuleName_right_srt-(_info)+0 .long 0 .quad 0 .quad 4294967330 @@ -653,7 +727,7 @@ andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_lvl1_closure,%ebx + movl $VeryLongModuleName_lvl1_closure,%ebx addq $8,%rbp andq $-8,%rbx jmp *(%rbx) @@ -664,14 +738,14 @@ jmp *(%rbx) .text .align 8 - .long ShortM_right_srt-(ShortM_right_info)+0 + .long VeryLongModuleName_right_srt-(VeryLongModuleName_right_info)+0 .long 0 .quad 4294967301 .quad 0 .quad 4294967311 -.globl ShortM_right_info -.type ShortM_right_info, @object -ShortM_right_info: +.globl VeryLongModuleName_right_info +.type VeryLongModuleName_right_info, @object +VeryLongModuleName_right_info: .L: leaq -8(%rbp),%rax cmpq %r14,%rax @@ -683,22 +757,22 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_right_closure,%ebx + movl $VeryLongModuleName_right_closure,%ebx jmp *-8(%r13) .section .data .align 8 -ShortM_left_srt: - .quad ShortM_lvl2_closure +VeryLongModuleName_next_srt: + .quad VeryLongModuleName_lvl_closure .data .align 8 -.globl ShortM_left_closure -.type ShortM_left_closure, @object -ShortM_left_closure: - .quad ShortM_left_info +.globl VeryLongModuleName_next_closure +.type VeryLongModuleName_next_closure, @object +VeryLongModuleName_next_closure: + .quad VeryLongModuleName_next_info .quad 0 .text .align 8 - .long ShortM_left_srt-(_info)+0 + .long VeryLongModuleName_next_srt-(_info)+0 .long 0 .quad 0 .quad 4294967330 @@ -708,25 +782,25 @@ andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_lvl2_closure,%ebx + movl $VeryLongModuleName_lvl_closure,%ebx addq $8,%rbp andq $-8,%rbx jmp *(%rbx) .L: - movq 6(%rbx),%rbx + movq 22(%rbx),%rbx addq $8,%rbp andq $-8,%rbx jmp *(%rbx) .text .align 8 - .long ShortM_left_srt-(ShortM_left_info)+0 + .long VeryLongModuleName_next_srt-(VeryLongModuleName_next_info)+0 .long 0 .quad 4294967301 .quad 0 .quad 4294967311 -.globl ShortM_left_info -.type ShortM_left_info, @object -ShortM_left_info: +.globl VeryLongModuleName_next_info +.type VeryLongModuleName_next_info, @object +VeryLongModuleName_next_info: .L: leaq -8(%rbp),%rax cmpq %r14,%rax @@ -738,22 +812,22 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_left_closure,%ebx + movl $VeryLongModuleName_next_closure,%ebx jmp *-8(%r13) .section .data .align 8 -ShortM_val_srt: - .quad ShortM_lvl3_closure +VeryLongModuleName_left_srt: + .quad VeryLongModuleName_lvl2_closure .data .align 8 -.globl ShortM_val_closure -.type ShortM_val_closure, @object -ShortM_val_closure: - .quad ShortM_val_info +.globl VeryLongModuleName_left_closure +.type VeryLongModuleName_left_closure, @object +VeryLongModuleName_left_closure: + .quad VeryLongModuleName_left_info .quad 0 .text .align 8 - .long ShortM_val_srt-(_info)+0 + .long VeryLongModuleName_left_srt-(_info)+0 .long 0 .quad 0 .quad 4294967330 @@ -763,33 +837,25 @@ andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_lvl3_closure,%ebx + movl $VeryLongModuleName_lvl2_closure,%ebx addq $8,%rbp andq $-8,%rbx jmp *(%rbx) .L: - addq $16,%r12 - cmpq %r15,%r12 - ja .L - movq $ghczmprim_GHCziTypes_Izh_con_info,-8(%r12) - movq 30(%rbx),%rax - movq %rax,(%r12) - leaq -7(%r12),%rbx + movq 6(%rbx),%rbx addq $8,%rbp - jmp *(%rbp) -.L: - movq $16,184(%r13) - jmp *-16(%r13) + andq $-8,%rbx + jmp *(%rbx) .text .align 8 - .long ShortM_val_srt-(ShortM_val_info)+0 + .long VeryLongModuleName_left_srt-(VeryLongModuleName_left_info)+0 .long 0 .quad 4294967301 .quad 0 .quad 4294967311 -.globl ShortM_val_info -.type ShortM_val_info, @object -ShortM_val_info: +.globl VeryLongModuleName_left_info +.type VeryLongModuleName_left_info, @object +VeryLongModuleName_left_info: .L: leaq -8(%rbp),%rax cmpq %r14,%rax @@ -801,14 +867,14 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_val_closure,%ebx + movl $VeryLongModuleName_left_closure,%ebx jmp *-8(%r13) .data .align 8 -.globl ShortM_go_closure -.type ShortM_go_closure, @object -ShortM_go_closure: - .quad ShortM_go_info +.globl VeryLongModuleName_go_closure +.type VeryLongModuleName_go_closure, @object +VeryLongModuleName_go_closure: + .quad VeryLongModuleName_go_info .text .align 8 .quad 65 @@ -818,9 +884,9 @@ addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) - movq $ShortM_Nil_closure+1,-24(%r12) - movq $ShortM_Nil_closure+1,-16(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Nil_closure+1,-24(%r12) + movq $VeryLongModuleName_Nil_closure+1,-16(%r12) movq %rbx,-8(%r12) movq 8(%rbp),%rax movq %rax,(%r12) @@ -840,7 +906,7 @@ movq 7(%rbx),%rax movq %rax,8(%rbp) movq $_info,(%rbp) - jmp ShortM_go_info + jmp VeryLongModuleName_go_info .text .align 8 .quad 0 @@ -851,7 +917,7 @@ andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_Nil_closure+1,%ebx + movl $VeryLongModuleName_Nil_closure+1,%ebx addq $8,%rbp jmp *(%rbp) .L: @@ -868,9 +934,9 @@ .quad 4294967301 .quad 0 .quad 15 -.globl ShortM_go_info -.type ShortM_go_info, @object -ShortM_go_info: +.globl VeryLongModuleName_go_info +.type VeryLongModuleName_go_info, @object +VeryLongModuleName_go_info: .L: leaq -16(%rbp),%rax cmpq %r14,%rax @@ -882,37 +948,87 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_go_closure,%ebx + movl $VeryLongModuleName_go_closure,%ebx jmp *-8(%r13) +.section .data + .align 8 +VeryLongModuleName_zdsadd_srt: + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_zdsadd_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_zdsadd1_closure + .quad VeryLongModuleName_lvl3_closure +.section .data + .align 8 +VeryLongModuleName_zdsadd1_srt: + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_zdsadd_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_zdsadd1_closure + .quad VeryLongModuleName_lvl3_closure .data .align 8 -.globl ShortM_zdsadd_closure -.type ShortM_zdsadd_closure, @object -ShortM_zdsadd_closure: - .quad ShortM_zdsadd_info +.globl VeryLongModuleName_zdsadd_closure +.type VeryLongModuleName_zdsadd_closure, @object +VeryLongModuleName_zdsadd_closure: + .quad VeryLongModuleName_zdsadd_info + .quad 0 .text .align 8 -.globl ShortM_zdsadd_slow -.type ShortM_zdsadd_slow, @object -ShortM_zdsadd_slow: +.globl VeryLongModuleName_zdsadd_slow +.type VeryLongModuleName_zdsadd_slow, @object +VeryLongModuleName_zdsadd_slow: .L: movq (%rbp),%rsi movq 8(%rbp),%rdi movq 16(%rbp),%r8 movq 24(%rbp),%r9 addq $32,%rbp - jmp ShortM_zdsadd_info + jmp VeryLongModuleName_zdsadd_info .text .align 8 - .quad 772 + .long VeryLongModuleName_zdsadd_srt-(_info)+24 + .long 0 + .quad 4294967299 + .quad 4294967312 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + addq $40,%r12 + cmpq %r15,%r12 + ja .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 16(%rbx),%rax + movq %rax,-24(%r12) + movq 24(%rbx),%rax + movq %rax,-16(%r12) + movq 32(%rbx),%rax + movq %rax,-8(%r12) + movq 40(%rbx),%rax + movq %rax,(%r12) + leaq -30(%r12),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_right_info +.L: + movq $40,184(%r13) + jmp *-16(%r13) +.text + .align 8 + .quad 644 .quad 34 _info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) - movq 16(%rbp),%rax + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 24(%rbp),%rax movq %rax,-24(%r12) movq %rbx,-16(%r12) movq 8(%rbp),%rax @@ -934,10 +1050,10 @@ addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) - movq 8(%rbp),%rax - movq %rax,-24(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq 16(%rbp),%rax + movq %rax,-24(%r12) + movq 8(%rbp),%rax movq %rax,-16(%r12) movq %rbx,-8(%r12) movq 24(%rbp),%rax @@ -950,8 +1066,10 @@ jmp *-16(%r13) .text .align 8 - .quad 1157 - .quad 34 + .long VeryLongModuleName_zdsadd_srt-(_info)+8 + .long 0 + .quad 1029 + .quad 4294967330 _info: .L: movq %rbx,%rax @@ -961,12 +1079,13 @@ addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) - movq 24(%rbp),%rax - movq %rax,-24(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq 32(%rbp),%rax + movq %rax,-24(%r12) + movq 24(%rbp),%rax movq %rax,-16(%r12) - movq $ShortM_Nil_closure+1,-8(%r12) + movq 16(%rbp),%rax + movq %rax,-8(%r12) movq 40(%rbp),%rax movq %rax,(%r12) leaq -30(%r12),%rbx @@ -979,22 +1098,53 @@ movq 30(%rbx),%r9 movq $_info,16(%rbp) addq $8,%rbp - jmp ShortM_zdsadd_info + jmp VeryLongModuleName_zdsadd_info .L: movq $40,184(%r13) jmp *-16(%r13) .text .align 8 - .quad 644 + .long VeryLongModuleName_zdsadd_srt-(_info)+0 + .long 0 + .quad 4294967299 + .quad 4294967312 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + addq $40,%r12 + cmpq %r15,%r12 + ja .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 16(%rbx),%rax + movq %rax,-24(%r12) + movq 24(%rbx),%rax + movq %rax,-16(%r12) + movq 32(%rbx),%rax + movq %rax,-8(%r12) + movq 40(%rbx),%rax + movq %rax,(%r12) + leaq -30(%r12),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_left_info +.L: + movq $40,184(%r13) + jmp *-16(%r13) +.text + .align 8 + .quad 772 .quad 34 _info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq %rbx,-24(%r12) - movq 24(%rbp),%rax + movq 16(%rbp),%rax movq %rax,-16(%r12) movq 8(%rbp),%rax movq %rax,-8(%r12) @@ -1008,46 +1158,112 @@ jmp *-16(%r13) .text .align 8 - .quad 1029 - .quad 34 + .long VeryLongModuleName_zdsadd_srt-(_info)+0 + .long 0 + .quad 2118 + .quad 133143986210 _info: .L: - movq 7(%rbx),%rax - cmpq 40(%rbp),%rax + addq $48,%r12 + cmpq %r15,%r12 + ja .L + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax jl .L - movq 7(%rbx),%rax - cmpq 40(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax je .L - movq 32(%rbp),%rsi - movq 8(%rbp),%rdi - movq 7(%rbx),%r8 - movq $_info,8(%rbp) - addq $8,%rbp - jmp ShortM_zdsadd1_info + movq $_info,-40(%r12) + movq 40(%rbp),%rax + movq %rax,-24(%r12) + movq 32(%rbp),%rax + movq %rax,-16(%r12) + movq 24(%rbp),%rax + movq %rax,-8(%r12) + movq 48(%rbp),%rax + movq %rax,(%r12) + leaq -40(%r12),%rsi + movq 16(%rbp),%rdi + movq 8(%rbp),%r8 + movq $_info,16(%rbp) + addq $16,%rbp + jmp VeryLongModuleName_zdsadd1_info .L: - movq 24(%rbp),%rsi - movq 8(%rbp),%rdi - movq 7(%rbx),%r8 + movq $48,184(%r13) + jmp *-16(%r13) +.L: + movq $_info,-40(%r12) + movq 40(%rbp),%rax + movq %rax,-24(%r12) + movq 32(%rbp),%rax + movq %rax,-16(%r12) + movq 24(%rbp),%rax + movq %rax,-8(%r12) + movq 48(%rbp),%rax + movq %rax,(%r12) + leaq -40(%r12),%rsi + movq 16(%rbp),%rdi + movq 8(%rbp),%r8 + movq $_info,16(%rbp) + addq $16,%rbp + jmp VeryLongModuleName_zdsadd1_info +.L: + movq $VeryLongModuleName_Node_con_info,-40(%r12) + movq 40(%rbp),%rax + movq %rax,-32(%r12) + movq 32(%rbp),%rax + movq %rax,-24(%r12) + movq 24(%rbp),%rax + movq %rax,-16(%r12) + movq 48(%rbp),%rax + movq %rax,-8(%r12) + leaq -38(%r12),%rsi movq $_info,8(%rbp) addq $8,%rbp - jmp ShortM_zdsadd1_info -.L: - movq 16(%rbp),%rbx - movq $_info,(%rbp) - testq $7,%rbx - jne _info - jmp *(%rbx) + addq $-8,%r12 + jmp VeryLongModuleName_next_info +.text + .align 8 + .long VeryLongModuleName_zdsadd_srt-(_info)+0 + .long 0 + .quad 1029 + .quad 270582939682 +_info: +.L: + addq $40,%r12 + cmpq %r15,%r12 + ja .L + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 32(%rbp),%rax + movq %rax,-24(%r12) + movq 24(%rbp),%rax + movq %rax,-16(%r12) + movq 16(%rbp),%rax + movq %rax,-8(%r12) + movq 40(%rbp),%rax + movq %rax,(%r12) + movq 7(%rbx),%rax + movq %rax,(%rbp) + leaq -30(%r12),%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info +.L: + movq $40,184(%r13) + jmp *-16(%r13) .text .align 8 + .long VeryLongModuleName_zdsadd_srt-(_info)+0 + .long 0 .quad 516 - .quad 34 + .quad 270582939682 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_Nil_closure+1,%ebx + movl $VeryLongModuleName_Nil_closure+1,%ebx addq $40,%rbp jmp *(%rbp) .L: @@ -1061,23 +1277,24 @@ jmp *(%rbx) .text .align 8 - .long ShortM_zdsadd_slow-(ShortM_zdsadd_info)+0 + .long VeryLongModuleName_zdsadd_slow-(VeryLongModuleName_zdsadd_info)+0 .long 0 .quad 517 - .quad 0 + .long VeryLongModuleName_zdsadd_srt-(VeryLongModuleName_zdsadd_info)+0 + .long 0 .quad 21474836480 .quad 0 - .quad 15 -.globl ShortM_zdsadd_info -.type ShortM_zdsadd_info, @object -ShortM_zdsadd_info: + .quad 270582939663 +.globl VeryLongModuleName_zdsadd_info +.type VeryLongModuleName_zdsadd_info, @object +VeryLongModuleName_zdsadd_info: .L: - leaq -40(%rbp),%rax + leaq -48(%rbp),%rax cmpq %r14,%rax jb .L movq %rsi,-24(%rbp) - movq %r8,-16(%rbp) - movq %rdi,-8(%rbp) + movq %rdi,-16(%rbp) + movq %r8,-8(%rbp) movq (%rbp),%rbx movq %r9,(%rbp) movq $_info,-32(%rbp) @@ -1086,7 +1303,7 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_zdsadd_closure,%ebx + movl $VeryLongModuleName_zdsadd_closure,%ebx addq $-32,%rbp movq %rsi,(%rbp) movq %rdi,8(%rbp) @@ -1095,20 +1312,39 @@ jmp *-8(%r13) .data .align 8 -.globl ShortM_zdsadd1_closure -.type ShortM_zdsadd1_closure, @object -ShortM_zdsadd1_closure: - .quad ShortM_zdsadd1_info +.globl VeryLongModuleName_zdsadd1_closure +.type VeryLongModuleName_zdsadd1_closure, @object +VeryLongModuleName_zdsadd1_closure: + .quad VeryLongModuleName_zdsadd1_info + .quad 0 .text .align 8 - .quad 259 + .long VeryLongModuleName_zdsadd1_srt-(_info)+24 + .long 0 + .quad 1 + .quad 4294967313 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq 16(%rbx),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_right_info +.L: + jmp *-16(%r13) +.text + .align 8 + .quad 3846 .quad 34 _info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq 16(%rbp),%rax movq %rax,-24(%r12) movq %rbx,-16(%r12) @@ -1117,84 +1353,150 @@ movq 24(%rbp),%rax movq %rax,(%r12) leaq -30(%r12),%rbx - addq $32,%rbp + addq $56,%rbp jmp *(%rbp) .L: movq $40,184(%r13) jmp *-16(%r13) .text .align 8 - .quad 772 + .quad 7815 .quad 34 _info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) - movq 8(%rbp),%rax + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 24(%rbp),%rax movq %rax,-24(%r12) - movq 16(%rbp),%rax + movq 8(%rbp),%rax movq %rax,-16(%r12) movq %rbx,-8(%r12) movq 32(%rbp),%rax movq %rax,(%r12) leaq -30(%r12),%rbx - addq $40,%rbp + addq $64,%rbp jmp *(%rbp) .L: movq $40,184(%r13) jmp *-16(%r13) .text .align 8 - .quad 1029 - .quad 34 + .long VeryLongModuleName_zdsadd1_srt-(_info)+8 + .long 0 + .quad 4743 + .quad 4294967330 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movq 8(%rbp),%rbx - addq $48,%rbp + movq 40(%rbp),%rbx + addq $64,%rbp andq $-8,%rbx jmp *(%rbx) .L: - movq 32(%rbp),%rax - movq %rax,(%rbp) + movq 48(%rbp),%rax + movq %rax,-8(%rbp) movq 22(%rbx),%rsi movq 14(%rbx),%rdi movq 6(%rbx),%r8 movq 30(%rbx),%r9 - movq $_info,8(%rbp) - jmp ShortM_zdsadd_info + movq $_info,(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_zdsadd_info .text .align 8 - .quad 259 + .long VeryLongModuleName_zdsadd1_srt-(_info)+0 + .long 0 + .quad 1 + .quad 4294967313 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq 16(%rbx),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_left_info +.L: + jmp *-16(%r13) +.text + .align 8 + .quad 7943 .quad 34 _info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq %rbx,-24(%r12) - movq 16(%rbp),%rax - movq %rax,-16(%r12) movq 8(%rbp),%rax + movq %rax,-16(%r12) + movq 16(%rbp),%rax movq %rax,-8(%r12) - movq 24(%rbp),%rax + movq 32(%rbp),%rax movq %rax,(%r12) leaq -30(%r12),%rbx - addq $32,%rbp + addq $64,%rbp jmp *(%rbp) .L: movq $40,184(%r13) jmp *-16(%r13) .text .align 8 + .long VeryLongModuleName_zdsadd1_srt-(_info)+0 + .long 0 + .quad 4615 + .quad 133143986210 +_info: +.L: + addq $24,%r12 + cmpq %r15,%r12 + ja .L + movq 56(%rbp),%rax + cmpq 7(%rbx),%rax + jl .L + movq 56(%rbp),%rax + cmpq 7(%rbx),%rax + je .L + movq $_info,-16(%r12) + movq 40(%rbp),%rax + movq %rax,(%r12) + leaq -16(%r12),%rsi + movq 48(%rbp),%rdi + movq 56(%rbp),%r8 + movq $_info,8(%rbp) + addq $8,%rbp + jmp VeryLongModuleName_zdsadd1_info +.L: + movq $24,184(%r13) + jmp *-16(%r13) +.L: + movq $_info,-16(%r12) + movq 40(%rbp),%rax + movq %rax,(%r12) + leaq -16(%r12),%rsi + movq 48(%rbp),%rdi + movq 56(%rbp),%r8 + movq $_info,(%rbp) + jmp VeryLongModuleName_zdsadd1_info +.L: + movq 40(%rbp),%rsi + movq $_info,(%rbp) + addq $-24,%r12 + jmp VeryLongModuleName_next_info +.text + .align 8 + .long VeryLongModuleName_zdsadd1_srt-(_info)+0 + .long 0 .quad 130 - .quad 34 + .quad 270582939682 _info: .L: movq %rbx,%rax @@ -1214,66 +1516,36 @@ movq %rax,(%r12) leaq -14(%r12),%rsi addq $24,%rbp - jmp ShortM_go_info + jmp VeryLongModuleName_go_info .L: - movq 16(%rbp),%rax - cmpq 30(%rbx),%rax - jl .L - movq 16(%rbp),%rax - cmpq 30(%rbx),%rax - je .L + movq 14(%rbx),%rax + movq %rax,-32(%rbp) movq 22(%rbx),%rax - movq %rax,(%rbp) - movq 14(%rbx),%rsi - movq 8(%rbp),%rdi + movq %rax,-24(%rbp) movq 6(%rbx),%rax - movq %rax,8(%rbp) - movq 16(%rbp),%r8 - movq 30(%rbx),%rax - movq %rax,16(%rbp) - movq $_info,-8(%rbp) - addq $-8,%rbp - jmp ShortM_zdsadd1_info -.L: - movq 22(%rbx),%rax - movq %rax,(%rbp) - movq 6(%rbx),%rsi - movq 8(%rbp),%rdi - movq 14(%rbx),%rax - movq %rax,8(%rbp) - movq 16(%rbp),%r8 + movq %rax,-16(%rbp) movq 30(%rbx),%rax - movq %rax,16(%rbp) - movq $_info,-8(%rbp) - addq $-8,%rbp - jmp ShortM_zdsadd1_info -.L: - movq %rbx,-16(%rbp) - movq 6(%rbx),%rax movq %rax,-8(%rbp) - movq 14(%rbx),%rax - movq %rax,(%rbp) - movq 30(%rbx),%rax - movq %rax,16(%rbp) - movq 22(%rbx),%rbx - movq $_info,-24(%rbp) - addq $-24,%rbp - testq $7,%rbx - jne _info - jmp *(%rbx) + movq %rbx,(%rbp) + movq %rbx,%rsi + movq $_info,-40(%rbp) + addq $-40,%rbp + jmp VeryLongModuleName_val_info .L: movq $40,184(%r13) jmp *-16(%r13) .text .align 8 + .long VeryLongModuleName_zdsadd1_srt-(VeryLongModuleName_zdsadd1_info)+0 + .long 0 .quad 12884901907 .quad 0 - .quad 15 -.globl ShortM_zdsadd1_info -.type ShortM_zdsadd1_info, @object -ShortM_zdsadd1_info: + .quad 270582939663 +.globl VeryLongModuleName_zdsadd1_info +.type VeryLongModuleName_zdsadd1_info, @object +VeryLongModuleName_zdsadd1_info: .L: - leaq -48(%rbp),%rax + leaq -72(%rbp),%rax cmpq %r14,%rax jb .L movq %rdi,-16(%rbp) @@ -1285,14 +1557,42 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_zdsadd1_closure,%ebx + movl $VeryLongModuleName_zdsadd1_closure,%ebx jmp *-8(%r13) +.section .data + .align 8 +VeryLongModuleName_add_srt: + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_zdsadd_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_zdsadd1_closure + .quad VeryLongModuleName_lvl3_closure .data .align 8 -.globl ShortM_add_closure -.type ShortM_add_closure, @object -ShortM_add_closure: - .quad ShortM_add_info +.globl VeryLongModuleName_add_closure +.type VeryLongModuleName_add_closure, @object +VeryLongModuleName_add_closure: + .quad VeryLongModuleName_add_info + .quad 0 +.text + .align 8 + .long VeryLongModuleName_add_srt-(_info)+24 + .long 0 + .quad 1 + .quad 4294967313 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq 16(%rbx),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_right_info +.L: + jmp *-16(%r13) .text .align 8 .quad 1797 @@ -1302,13 +1602,13 @@ addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq 16(%rbp),%rax movq %rax,-24(%r12) movq %rbx,-16(%r12) movq 8(%rbp),%rax movq %rax,-8(%r12) - movq 40(%rbp),%rax + movq 32(%rbp),%rax movq %rax,(%r12) leaq -30(%r12),%rbx addq $48,%rbp @@ -1318,109 +1618,159 @@ jmp *-16(%r13) .text .align 8 - .quad 644 + .quad 3718 .quad 34 _info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) - movq 8(%rbp),%rax - movq %rax,-24(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq 24(%rbp),%rax + movq %rax,-24(%r12) + movq 8(%rbp),%rax movq %rax,-16(%r12) movq %rbx,-8(%r12) - movq 32(%rbp),%rax + movq 40(%rbp),%rax movq %rax,(%r12) leaq -30(%r12),%rbx - addq $40,%rbp + addq $56,%rbp jmp *(%rbp) .L: movq $40,184(%r13) jmp *-16(%r13) .text .align 8 - .quad 2182 - .quad 34 + .long VeryLongModuleName_add_srt-(_info)+8 + .long 0 + .quad 1158 + .quad 4294967330 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movq 8(%rbp),%rbx + movq 48(%rbp),%rbx addq $56,%rbp andq $-8,%rbx jmp *(%rbx) .L: movq 32(%rbp),%rax - movq %rax,8(%rbp) + movq %rax,-8(%rbp) movq 22(%rbx),%rsi movq 14(%rbx),%rdi movq 6(%rbx),%r8 movq 30(%rbx),%r9 - movq $_info,16(%rbp) - addq $8,%rbp - jmp ShortM_zdsadd_info + movq $_info,(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_zdsadd_info +.text + .align 8 + .long VeryLongModuleName_add_srt-(_info)+0 + .long 0 + .quad 1 + .quad 4294967313 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq 16(%rbx),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_left_info +.L: + jmp *-16(%r13) .text .align 8 - .quad 1413 + .quad 3846 .quad 34 _info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq %rbx,-24(%r12) - movq 32(%rbp),%rax - movq %rax,-16(%r12) movq 8(%rbp),%rax + movq %rax,-16(%r12) + movq 16(%rbp),%rax movq %rax,-8(%r12) movq 40(%rbp),%rax movq %rax,(%r12) leaq -30(%r12),%rbx - addq $48,%rbp + addq $56,%rbp jmp *(%rbp) .L: movq $40,184(%r13) jmp *-16(%r13) .text .align 8 - .quad 2054 - .quad 34 + .long VeryLongModuleName_add_srt-(_info)+0 + .long 0 + .quad 2119 + .quad 133143986210 _info: .L: - movq 7(%rbx),%rax - cmpq 48(%rbp),%rax + addq $24,%r12 + cmpq %r15,%r12 + ja .L + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax jl .L - movq 7(%rbx),%rax - cmpq 48(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax je .L - movq 40(%rbp),%rsi - movq 32(%rbp),%rdi - movq 7(%rbx),%r8 + movq $_info,-16(%r12) + movq 56(%rbp),%rax + movq %rax,(%r12) + leaq -16(%r12),%rsi + movq 40(%rbp),%rdi + movq 8(%rbp),%r8 + movq $_info,16(%rbp) + addq $16,%rbp + jmp VeryLongModuleName_zdsadd1_info +.L: + movq $24,184(%r13) + jmp *-16(%r13) +.L: + movq $_info,-16(%r12) + movq 56(%rbp),%rax + movq %rax,(%r12) + leaq -16(%r12),%rsi + movq 40(%rbp),%rdi + movq 8(%rbp),%r8 movq $_info,8(%rbp) addq $8,%rbp - jmp ShortM_zdsadd1_info + jmp VeryLongModuleName_zdsadd1_info .L: - movq 24(%rbp),%rsi - movq 32(%rbp),%rdi - movq 7(%rbx),%r8 + movq 56(%rbp),%rsi movq $_info,8(%rbp) addq $8,%rbp - jmp ShortM_zdsadd1_info + addq $-24,%r12 + jmp VeryLongModuleName_next_info +.text + .align 8 + .long VeryLongModuleName_add_srt-(_info)+0 + .long 0 + .quad 1030 + .quad 270582939682 +_info: .L: - movq 16(%rbp),%rbx - movq $_info,(%rbp) - testq $7,%rbx - jne _info - jmp *(%rbx) + movq 7(%rbx),%rax + movq %rax,(%rbp) + movq 48(%rbp),%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info .text .align 8 + .long VeryLongModuleName_add_srt-(_info)+0 + .long 0 .quad 3 - .quad 34 + .quad 270582939682 _info: .L: movq %rbx,%rax @@ -1429,17 +1779,17 @@ jae .L movq 24(%rbp),%rsi addq $32,%rbp - jmp ShortM_go_info + jmp VeryLongModuleName_go_info .L: - movq %rbx,-16(%rbp) + movq 14(%rbx),%rax + movq %rax,-16(%rbp) movq 22(%rbx),%rax movq %rax,-8(%rbp) movq 6(%rbx),%rax movq %rax,(%rbp) - movq 30(%rbx),%rax - movq %rax,24(%rbp) + movq %rbx,24(%rbp) movq 16(%rbp),%rax - movq 14(%rbx),%rcx + movq 30(%rbx),%rcx movq %rcx,16(%rbp) movq %rax,%rbx movq $_info,-24(%rbp) @@ -1449,15 +1799,17 @@ jmp *(%rbx) .text .align 8 + .long VeryLongModuleName_add_srt-(_info)+0 + .long 0 .quad 1 - .quad 34 + .quad 270582939682 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_Nil_closure+1,%ebx + movl $VeryLongModuleName_Nil_closure+1,%ebx addq $16,%rbp jmp *(%rbp) .L: @@ -1475,14 +1827,16 @@ jmp *(%rbx) .text .align 8 + .long VeryLongModuleName_add_srt-(VeryLongModuleName_add_info)+0 + .long 0 .quad 8589934604 .quad 0 - .quad 15 -.globl ShortM_add_info -.type ShortM_add_info, @object -ShortM_add_info: + .quad 270582939663 +.globl VeryLongModuleName_add_info +.type VeryLongModuleName_add_info, @object +VeryLongModuleName_add_info: .L: - leaq -56(%rbp),%rax + leaq -64(%rbp),%rax cmpq %r14,%rax jb .L movq %rdi,-8(%rbp) @@ -1493,48 +1847,140 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_add_closure,%ebx + movl $VeryLongModuleName_add_closure,%ebx jmp *-8(%r13) -.data +.section .data .align 8 -.globl ShortM_zdssubsumes_closure -.type ShortM_zdssubsumes_closure, @object -ShortM_zdssubsumes_closure: - .quad ShortM_zdssubsumes_info +VeryLongModuleName_zdssubsumes_srt: + .quad VeryLongModuleName_zdssubsumes_closure + .quad VeryLongModuleName_zdssubsumes1_closure + .quad VeryLongModuleName_subsumes_closure + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_lvl3_closure +.section .data + .align 8 +VeryLongModuleName_zdssubsumes1_srt: + .quad VeryLongModuleName_zdssubsumes_closure + .quad VeryLongModuleName_zdssubsumes1_closure + .quad VeryLongModuleName_subsumes_closure + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_lvl3_closure +.section .data + .align 8 +VeryLongModuleName_subsumes_srt: + .quad VeryLongModuleName_zdssubsumes_closure + .quad VeryLongModuleName_zdssubsumes1_closure + .quad VeryLongModuleName_subsumes_closure + .quad VeryLongModuleName_lvl2_closure + .quad VeryLongModuleName_lvl_closure + .quad VeryLongModuleName_lvl1_closure + .quad VeryLongModuleName_lvl3_closure +.data + .align 8 +.globl VeryLongModuleName_zdssubsumes_closure +.type VeryLongModuleName_zdssubsumes_closure, @object +VeryLongModuleName_zdssubsumes_closure: + .quad VeryLongModuleName_zdssubsumes_info + .quad 0 .text .align 8 -.globl ShortM_zdssubsumes_slow -.type ShortM_zdssubsumes_slow, @object -ShortM_zdssubsumes_slow: +.globl VeryLongModuleName_zdssubsumes_slow +.type VeryLongModuleName_zdssubsumes_slow, @object +VeryLongModuleName_zdssubsumes_slow: .L: movq (%rbp),%rsi movq 8(%rbp),%rdi movq 16(%rbp),%r8 movq 24(%rbp),%r9 addq $32,%rbp - jmp ShortM_zdssubsumes_info + jmp VeryLongModuleName_zdssubsumes_info .text .align 8 - .quad 1413 - .quad 34 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+40 + .long 0 + .quad 4294967299 + .quad 4294967312 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + addq $40,%r12 + cmpq %r15,%r12 + ja .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 16(%rbx),%rax + movq %rax,-24(%r12) + movq 24(%rbx),%rax + movq %rax,-16(%r12) + movq 32(%rbx),%rax + movq %rax,-8(%r12) + movq 40(%rbx),%rax + movq %rax,(%r12) + leaq -30(%r12),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_right_info +.L: + movq $40,184(%r13) + jmp *-16(%r13) +.text + .align 8 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+16 + .long 0 + .quad 1925 + .quad 4294967330 +_info: +.L: + movq %rbx,%rsi + movq 8(%rbp),%rdi + addq $48,%rbp + jmp VeryLongModuleName_subsumes_info +.text + .align 8 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+16 + .long 0 + .quad 1029 + .quad 38654705698 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movq 32(%rbp),%rsi - movq 8(%rbp),%rdi - addq $48,%rbp - jmp ShortM_subsumes_info + addq $40,%r12 + cmpq %r15,%r12 + ja .L + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 32(%rbp),%rax + movq %rax,-24(%r12) + movq 24(%rbp),%rax + movq %rax,-16(%r12) + movq 16(%rbp),%rax + movq %rax,-8(%r12) + movq 40(%rbp),%rax + movq %rax,(%r12) + leaq -30(%r12),%rsi + movq $_info,(%rbp) + jmp VeryLongModuleName_right_info .L: movl $ghczmprim_GHCziBool_True_closure+2,%ebx addq $48,%rbp jmp *(%rbp) +.L: + movq $40,184(%r13) + jmp *-16(%r13) .text .align 8 - .quad 1413 - .quad 34 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+0 + .long 0 + .quad 1029 + .quad 158913789986 _info: .L: movq %rbx,%rax @@ -1553,65 +1999,94 @@ movq 6(%rbx),%r9 movq $_info,(%rbp) addq $-8,%rbp - jmp ShortM_zdssubsumes_info + jmp VeryLongModuleName_zdssubsumes_info .text .align 8 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+24 + .long 0 + .quad 130 + .quad 21474836514 +_info: +.L: + movq 16(%rbp),%rax + cmpq 7(%rbx),%rax + jl .L + movq 16(%rbp),%rax + cmpq 7(%rbx),%rax + je .L + movq 8(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_right_info +.L: + movq 8(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_left_info +.L: + movq 8(%rbp),%rbx + addq $24,%rbp + andq $-8,%rbx + jmp *(%rbx) +.text + .align 8 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+24 + .long 0 .quad 65 - .quad 34 + .quad 55834574882 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_Nil_closure+1,%ebx + movl $VeryLongModuleName_Nil_closure+1,%ebx addq $16,%rbp jmp stg_upd_frame_info .L: - movq 8(%rbp),%rax - cmpq 30(%rbx),%rax - jl .L - movq 8(%rbp),%rax - cmpq 30(%rbx),%rax - je .L - movq 14(%rbx),%rbx - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) -.L: - movq 6(%rbx),%rbx - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) -.L: - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) + movq %rbx,(%rbp) + movq %rbx,%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info .text .align 8 - .quad 4294967297 - .quad 20 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+24 + .long 0 + .quad 8589934595 + .quad 55834574864 _info: .L: - leaq -32(%rbp),%rax + leaq -40(%rbp),%rax cmpq %r14,%rax jb .L + addq $40,%r12 + cmpq %r15,%r12 + ja .L movq $stg_upd_frame_info,-16(%rbp) movq %rbx,-8(%rbp) + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 16(%rbx),%rax + movq %rax,-24(%r12) movq 24(%rbx),%rax + movq %rax,-16(%r12) + movq 32(%rbx),%rax + movq %rax,-8(%r12) + movq 40(%rbx),%rax + movq %rax,(%r12) + movq 48(%rbx),%rax movq %rax,-24(%rbp) - movq 16(%rbx),%rbx + leaq -30(%r12),%rsi movq $_info,-32(%rbp) addq $-32,%rbp - testq $7,%rbx - jne _info - jmp *(%rbx) + jmp VeryLongModuleName_left_info .L: + movq $40,184(%r13) jmp *-16(%r13) .text .align 8 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+0 + .long 0 .quad 1029 - .quad 34 + .quad 4294967330 _info: .L: movq %rbx,%rax @@ -1619,61 +2094,118 @@ cmpq $2,%rax jae .L movq 8(%rbp),%rsi - movq 24(%rbp),%rdi - movq 32(%rbp),%r8 - movq 16(%rbp),%r9 + movq 16(%rbp),%rdi + movq 24(%rbp),%r8 + movq 32(%rbp),%r9 addq $40,%rbp - jmp ShortM_zdssubsumes_info + jmp VeryLongModuleName_zdssubsumes_info .L: movl $ghczmprim_GHCziBool_True_closure+2,%ebx addq $48,%rbp jmp *(%rbp) .text .align 8 - .quad 1029 - .quad 34 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+0 + .long 0 + .quad 2118 + .quad 545460846626 _info: .L: - addq $32,%r12 + addq $56,%r12 cmpq %r15,%r12 ja .L - movq 7(%rbx),%rax - cmpq 40(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax jl .L - movq 7(%rbx),%rax - cmpq 40(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax je .L - movq 8(%rbp),%rsi - movq 7(%rbx),%rdi - movq 32(%rbp),%r8 - addq $48,%rbp - addq $-32,%r12 - jmp ShortM_zdssubsumes1_info + movq $_info,-48(%r12) + movq 40(%rbp),%rax + movq %rax,-32(%r12) + movq 32(%rbp),%rax + movq %rax,-24(%r12) + movq 24(%rbp),%rax + movq %rax,-16(%r12) + movq 48(%rbp),%rax + movq %rax,-8(%r12) + movq 16(%rbp),%rsi + movq 8(%rbp),%rdi + leaq -48(%r12),%r8 + addq $56,%rbp + addq $-8,%r12 + jmp VeryLongModuleName_zdssubsumes1_info .L: - movq $32,184(%r13) + movq $56,184(%r13) jmp *-16(%r13) .L: - movq $_info,-24(%r12) + movq $_info,-48(%r12) + movq 40(%rbp),%rax + movq %rax,-32(%r12) + movq 32(%rbp),%rax + movq %rax,-24(%r12) + movq 24(%rbp),%rax + movq %rax,-16(%r12) + movq 48(%rbp),%rax + movq %rax,-8(%r12) + movq 8(%rbp),%rax + movq %rax,(%r12) + movq 16(%rbp),%rsi + movq 8(%rbp),%rdi + leaq -48(%r12),%r8 + movq $_info,8(%rbp) + addq $8,%rbp + jmp VeryLongModuleName_zdssubsumes1_info +.L: + movq $VeryLongModuleName_Node_con_info,-48(%r12) + movq 40(%rbp),%rax + movq %rax,-40(%r12) + movq 32(%rbp),%rax + movq %rax,-32(%r12) + movq 24(%rbp),%rax + movq %rax,-24(%r12) + movq 48(%rbp),%rax + movq %rax,-16(%r12) + leaq -46(%r12),%rsi + movq $_info,8(%rbp) + addq $8,%rbp + addq $-16,%r12 + jmp VeryLongModuleName_next_info +.text + .align 8 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+0 + .long 0 + .quad 1029 + .quad 545460846626 +_info: +.L: + addq $40,%r12 + cmpq %r15,%r12 + ja .L + movq $VeryLongModuleName_Node_con_info,-32(%r12) + movq 32(%rbp),%rax + movq %rax,-24(%r12) + movq 24(%rbp),%rax + movq %rax,-16(%r12) movq 16(%rbp),%rax movq %rax,-8(%r12) - movq 7(%rbx),%rax + movq 40(%rbp),%rax movq %rax,(%r12) - movq 8(%rbp),%rsi - movq 7(%rbx),%rdi - leaq -24(%r12),%r8 - movq $_info,(%rbp) - jmp ShortM_zdssubsumes1_info + movq 7(%rbx),%rax + movq %rax,(%rbp) + leaq -30(%r12),%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info .L: - movq 24(%rbp),%rbx - movq $_info,(%rbp) - addq $-32,%r12 - testq $7,%rbx - jne _info - jmp *(%rbx) + movq $40,184(%r13) + jmp *-16(%r13) .text .align 8 + .long VeryLongModuleName_zdssubsumes_srt-(_info)+0 + .long 0 .quad 516 - .quad 34 + .quad 545460846626 _info: .L: movq %rbx,%rax @@ -1694,23 +2226,24 @@ jmp *(%rbx) .text .align 8 - .long ShortM_zdssubsumes_slow-(ShortM_zdssubsumes_info)+0 + .long VeryLongModuleName_zdssubsumes_slow-(VeryLongModuleName_zdssubsumes_info)+0 .long 0 .quad 1029 - .quad 0 + .long VeryLongModuleName_zdssubsumes_srt-(VeryLongModuleName_zdssubsumes_info)+0 + .long 0 .quad 21474836480 .quad 0 - .quad 15 -.globl ShortM_zdssubsumes_info -.type ShortM_zdssubsumes_info, @object -ShortM_zdssubsumes_info: + .quad 545460846607 +.globl VeryLongModuleName_zdssubsumes_info +.type VeryLongModuleName_zdssubsumes_info, @object +VeryLongModuleName_zdssubsumes_info: .L: leaq -48(%rbp),%rax cmpq %r14,%rax jb .L - movq %r9,-24(%rbp) - movq %rdi,-16(%rbp) - movq %r8,-8(%rbp) + movq %rdi,-24(%rbp) + movq %r8,-16(%rbp) + movq %r9,-8(%rbp) movq %rsi,%rbx movq $_info,-32(%rbp) addq $-32,%rbp @@ -1718,7 +2251,7 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_zdssubsumes_closure,%ebx + movl $VeryLongModuleName_zdssubsumes_closure,%ebx addq $-32,%rbp movq %rsi,(%rbp) movq %rdi,8(%rbp) @@ -1727,32 +2260,67 @@ jmp *-8(%r13) .data .align 8 -.globl ShortM_zdssubsumes1_closure -.type ShortM_zdssubsumes1_closure, @object -ShortM_zdssubsumes1_closure: - .quad ShortM_zdssubsumes1_info +.globl VeryLongModuleName_zdssubsumes1_closure +.type VeryLongModuleName_zdssubsumes1_closure, @object +VeryLongModuleName_zdssubsumes1_closure: + .quad VeryLongModuleName_zdssubsumes1_info + .quad 0 .text .align 8 - .quad 2 - .quad 34 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+40 + .long 0 + .quad 1 + .quad 4294967313 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq 16(%rbx),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_right_info +.L: + jmp *-16(%r13) +.text + .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+16 + .long 0 + .quad 130 + .quad 4294967330 +_info: +.L: + movq %rbx,%rsi + movq 8(%rbp),%rdi + addq $24,%rbp + jmp VeryLongModuleName_subsumes_info +.text + .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+16 + .long 0 + .quad 259 + .quad 38654705698 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movq 16(%rbp),%rsi - movq 8(%rbp),%rdi - addq $24,%rbp - jmp ShortM_subsumes_info + movq 8(%rbp),%rsi + movq $_info,8(%rbp) + addq $8,%rbp + jmp VeryLongModuleName_right_info .L: movl $ghczmprim_GHCziBool_True_closure+2,%ebx - addq $24,%rbp + addq $32,%rbp jmp *(%rbp) .text .align 8 - .quad 2 - .quad 34 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+0 + .long 0 + .quad 259 + .quad 158913789986 _info: .L: movq %rbx,%rax @@ -1760,96 +2328,162 @@ cmpq $2,%rax jae .L movl $ghczmprim_GHCziBool_True_closure+2,%ebx - addq $24,%rbp + addq $32,%rbp jmp *(%rbp) .L: movq 30(%rbx),%rax movq %rax,-8(%rbp) - movq 8(%rbp),%rsi + movq 16(%rbp),%rsi movq 22(%rbx),%rdi movq 14(%rbx),%r8 movq 6(%rbx),%r9 movq $_info,(%rbp) addq $-8,%rbp - jmp ShortM_zdssubsumes_info + jmp VeryLongModuleName_zdssubsumes_info .text .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+24 + .long 0 + .quad 130 + .quad 21474836514 +_info: +.L: + movq 16(%rbp),%rax + cmpq 7(%rbx),%rax + jl .L + movq 16(%rbp),%rax + cmpq 7(%rbx),%rax + je .L + movq 8(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_right_info +.L: + movq 8(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_left_info +.L: + movq 8(%rbp),%rbx + addq $24,%rbp + andq $-8,%rbx + jmp *(%rbx) +.text + .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+24 + .long 0 .quad 65 - .quad 34 + .quad 55834574882 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_Nil_closure+1,%ebx + movl $VeryLongModuleName_Nil_closure+1,%ebx addq $16,%rbp jmp stg_upd_frame_info .L: - movq 8(%rbp),%rax - cmpq 30(%rbx),%rax - jl .L - movq 8(%rbp),%rax - cmpq 30(%rbx),%rax - je .L - movq 14(%rbx),%rbx - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) -.L: - movq 6(%rbx),%rbx - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) -.L: - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) + movq %rbx,(%rbp) + movq %rbx,%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info .text .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+24 + .long 0 .quad 4294967297 - .quad 20 + .quad 55834574868 _info: .L: - leaq -32(%rbp),%rax + leaq -40(%rbp),%rax cmpq %r14,%rax jb .L movq $stg_upd_frame_info,-16(%rbp) movq %rbx,-8(%rbp) movq 24(%rbx),%rax movq %rax,-24(%rbp) - movq 16(%rbx),%rbx + movq 16(%rbx),%rsi movq $_info,-32(%rbp) addq $-32,%rbp - testq $7,%rbx - jne _info - jmp *(%rbx) + jmp VeryLongModuleName_left_info .L: jmp *-16(%r13) .text .align 8 - .quad 1029 - .quad 34 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+0 + .long 0 + .quad 5191 + .quad 4294967330 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movq 32(%rbp),%rsi - movq 16(%rbp),%rdi + movq 8(%rbp),%rax + movq %rax,56(%rbp) + movq 48(%rbp),%rsi + movq 32(%rbp),%rdi movq 24(%rbp),%r8 - movq 8(%rbp),%r9 - addq $40,%rbp - jmp ShortM_zdssubsumes_info + movq 16(%rbp),%r9 + addq $56,%rbp + jmp VeryLongModuleName_zdssubsumes_info +.L: + movl $ghczmprim_GHCziBool_True_closure+2,%ebx + addq $64,%rbp + jmp *(%rbp) +.text + .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+0 + .long 0 + .quad 4167 + .quad 545460846626 +_info: +.L: + addq $32,%r12 + cmpq %r15,%r12 + ja .L + movq 56(%rbp),%rax + cmpq 7(%rbx),%rax + jl .L + movq 56(%rbp),%rax + cmpq 7(%rbx),%rax + je .L + movq $_info,-24(%r12) + movq 40(%rbp),%rax + movq %rax,-8(%r12) + movq 48(%rbp),%rsi + movq 56(%rbp),%rdi + leaq -24(%r12),%r8 + addq $64,%rbp + addq $-8,%r12 + jmp VeryLongModuleName_zdssubsumes1_info +.L: + movq $32,184(%r13) + jmp *-16(%r13) +.L: + movq $_info,-24(%r12) + movq 40(%rbp),%rax + movq %rax,-8(%r12) + movq 56(%rbp),%rax + movq %rax,(%r12) + movq 48(%rbp),%rsi + movq 56(%rbp),%rdi + leaq -24(%r12),%r8 + movq $_info,(%rbp) + jmp VeryLongModuleName_zdssubsumes1_info .L: - movl $ghczmprim_GHCziBool_True_closure+2,%ebx - addq $48,%rbp - jmp *(%rbp) + movq 40(%rbp),%rsi + movq $_info,32(%rbp) + addq $32,%rbp + addq $-32,%r12 + jmp VeryLongModuleName_next_info .text .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(_info)+0 + .long 0 .quad 130 - .quad 34 + .quad 545460846626 _info: .L: movq %rbx,%rax @@ -1860,63 +2494,31 @@ addq $24,%rbp jmp *(%rbp) .L: - addq $32,%r12 - cmpq %r15,%r12 - ja .L - movq 16(%rbp),%rax - cmpq 30(%rbx),%rax - jl .L - movq 16(%rbp),%rax - cmpq 30(%rbx),%rax - je .L - movq 8(%rbp),%rsi - movq 16(%rbp),%rdi - movq 14(%rbx),%r8 - addq $24,%rbp - addq $-32,%r12 - jmp ShortM_zdssubsumes1_info -.L: - movq $32,184(%r13) - jmp *-16(%r13) -.L: - movq $_info,-24(%r12) - movq 6(%rbx),%rax - movq %rax,-8(%r12) - movq 16(%rbp),%rax - movq %rax,(%r12) + movq 30(%rbx),%rax + movq %rax,-32(%rbp) movq 6(%rbx),%rax + movq %rax,-24(%rbp) + movq 14(%rbx),%rax movq %rax,-16(%rbp) movq 22(%rbx),%rax movq %rax,-8(%rbp) - movq 14(%rbx),%rax - movq %rax,(%rbp) - movq 8(%rbp),%rsi - movq 16(%rbp),%rdi - movq 30(%rbx),%rax - movq %rax,16(%rbp) - leaq -24(%r12),%r8 - movq $_info,-24(%rbp) - addq $-24,%rbp - jmp ShortM_zdssubsumes1_info -.L: - movq 14(%rbx),%rax - movq %rax,16(%rbp) - movq 22(%rbx),%rbx - movq $_info,(%rbp) - addq $-32,%r12 - testq $7,%rbx - jne _info - jmp *(%rbx) + movq %rbx,(%rbp) + movq %rbx,%rsi + movq $_info,-40(%rbp) + addq $-40,%rbp + jmp VeryLongModuleName_val_info .text .align 8 + .long VeryLongModuleName_zdssubsumes1_srt-(VeryLongModuleName_zdssubsumes1_info)+0 + .long 0 .quad 12884901906 .quad 0 - .quad 15 -.globl ShortM_zdssubsumes1_info -.type ShortM_zdssubsumes1_info, @object -ShortM_zdssubsumes1_info: + .quad 545460846607 +.globl VeryLongModuleName_zdssubsumes1_info +.type VeryLongModuleName_zdssubsumes1_info, @object +VeryLongModuleName_zdssubsumes1_info: .L: - leaq -48(%rbp),%rax + leaq -64(%rbp),%rax cmpq %r14,%rax jb .L movq %rsi,-16(%rbp) @@ -1928,36 +2530,70 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_zdssubsumes1_closure,%ebx + movl $VeryLongModuleName_zdssubsumes1_closure,%ebx jmp *-8(%r13) .data .align 8 -.globl ShortM_subsumes_closure -.type ShortM_subsumes_closure, @object -ShortM_subsumes_closure: - .quad ShortM_subsumes_info +.globl VeryLongModuleName_subsumes_closure +.type VeryLongModuleName_subsumes_closure, @object +VeryLongModuleName_subsumes_closure: + .quad VeryLongModuleName_subsumes_info + .quad 0 .text .align 8 - .quad 1413 - .quad 34 + .long VeryLongModuleName_subsumes_srt-(_info)+40 + .long 0 + .quad 1 + .quad 4294967313 +_info: +.L: + leaq -16(%rbp),%rax + cmpq %r14,%rax + jb .L + movq $stg_upd_frame_info,-16(%rbp) + movq %rbx,-8(%rbp) + movq 16(%rbx),%rsi + addq $-16,%rbp + jmp VeryLongModuleName_right_info +.L: + jmp *-16(%r13) +.text + .align 8 + .long VeryLongModuleName_subsumes_srt-(_info)+16 + .long 0 + .quad 3974 + .quad 4294967330 +_info: +.L: + movq %rbx,%rsi + movq 8(%rbp),%rdi + addq $56,%rbp + jmp VeryLongModuleName_subsumes_info +.text + .align 8 + .long VeryLongModuleName_subsumes_srt-(_info)+16 + .long 0 + .quad 1926 + .quad 38654705698 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movq 32(%rbp),%rsi - movq 8(%rbp),%rdi - addq $48,%rbp - jmp ShortM_subsumes_info + movq 48(%rbp),%rsi + movq $_info,(%rbp) + jmp VeryLongModuleName_right_info .L: movl $ghczmprim_GHCziBool_True_closure+2,%ebx - addq $48,%rbp + addq $56,%rbp jmp *(%rbp) .text .align 8 - .quad 1413 - .quad 34 + .long VeryLongModuleName_subsumes_srt-(_info)+0 + .long 0 + .quad 1926 + .quad 158913789986 _info: .L: movq %rbx,%rax @@ -1965,7 +2601,7 @@ cmpq $2,%rax jae .L movl $ghczmprim_GHCziBool_True_closure+2,%ebx - addq $48,%rbp + addq $56,%rbp jmp *(%rbp) .L: movq 30(%rbx),%rax @@ -1976,127 +2612,166 @@ movq 6(%rbx),%r9 movq $_info,(%rbp) addq $-8,%rbp - jmp ShortM_zdssubsumes_info + jmp VeryLongModuleName_zdssubsumes_info +.text + .align 8 + .long VeryLongModuleName_subsumes_srt-(_info)+24 + .long 0 + .quad 130 + .quad 21474836514 +_info: +.L: + movq 16(%rbp),%rax + cmpq 7(%rbx),%rax + jl .L + movq 16(%rbp),%rax + cmpq 7(%rbx),%rax + je .L + movq 8(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_right_info +.L: + movq 8(%rbp),%rsi + addq $24,%rbp + jmp VeryLongModuleName_left_info +.L: + movq 8(%rbp),%rbx + addq $24,%rbp + andq $-8,%rbx + jmp *(%rbx) .text .align 8 + .long VeryLongModuleName_subsumes_srt-(_info)+24 + .long 0 .quad 65 - .quad 34 + .quad 55834574882 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L - movl $ShortM_Nil_closure+1,%ebx + movl $VeryLongModuleName_Nil_closure+1,%ebx addq $16,%rbp jmp stg_upd_frame_info .L: - movq 8(%rbp),%rax - cmpq 30(%rbx),%rax - jl .L - movq 8(%rbp),%rax - cmpq 30(%rbx),%rax - je .L - movq 14(%rbx),%rbx - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) -.L: - movq 6(%rbx),%rbx - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) -.L: - addq $16,%rbp - andq $-8,%rbx - jmp *(%rbx) + movq %rbx,(%rbp) + movq %rbx,%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info .text .align 8 + .long VeryLongModuleName_subsumes_srt-(_info)+24 + .long 0 .quad 4294967297 - .quad 20 + .quad 55834574868 _info: .L: - leaq -32(%rbp),%rax + leaq -40(%rbp),%rax cmpq %r14,%rax jb .L movq $stg_upd_frame_info,-16(%rbp) movq %rbx,-8(%rbp) movq 24(%rbx),%rax movq %rax,-24(%rbp) - movq 16(%rbx),%rbx + movq 16(%rbx),%rsi movq $_info,-32(%rbp) addq $-32,%rbp - testq $7,%rbx - jne _info - jmp *(%rbx) + jmp VeryLongModuleName_left_info .L: jmp *-16(%r13) .text .align 8 - .quad 1029 - .quad 34 + .long VeryLongModuleName_subsumes_srt-(_info)+0 + .long 0 + .quad 2182 + .quad 4294967330 _info: .L: movq %rbx,%rax andq $7,%rax cmpq $2,%rax jae .L + movq 16(%rbp),%rax + movq %rax,48(%rbp) movq 8(%rbp),%rsi - movq 24(%rbp),%rdi + movq 40(%rbp),%rdi movq 32(%rbp),%r8 - movq 16(%rbp),%r9 - addq $40,%rbp - jmp ShortM_zdssubsumes_info + movq 24(%rbp),%r9 + addq $48,%rbp + jmp VeryLongModuleName_zdssubsumes_info .L: movl $ghczmprim_GHCziBool_True_closure+2,%ebx - addq $48,%rbp + addq $56,%rbp jmp *(%rbp) .text .align 8 - .quad 1029 - .quad 34 + .long VeryLongModuleName_subsumes_srt-(_info)+0 + .long 0 + .quad 327 + .quad 545460846626 _info: .L: addq $32,%r12 cmpq %r15,%r12 ja .L - movq 7(%rbx),%rax - cmpq 40(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax jl .L - movq 7(%rbx),%rax - cmpq 40(%rbp),%rax + movq 8(%rbp),%rax + cmpq 7(%rbx),%rax je .L - movq 8(%rbp),%rsi - movq 7(%rbx),%rdi - movq 32(%rbp),%r8 - addq $48,%rbp - addq $-32,%r12 - jmp ShortM_zdssubsumes1_info + movq $_info,-24(%r12) + movq 56(%rbp),%rax + movq %rax,-8(%r12) + movq 16(%rbp),%rsi + movq 8(%rbp),%rdi + leaq -24(%r12),%r8 + addq $64,%rbp + addq $-8,%r12 + jmp VeryLongModuleName_zdssubsumes1_info .L: movq $32,184(%r13) jmp *-16(%r13) .L: movq $_info,-24(%r12) - movq 16(%rbp),%rax + movq 56(%rbp),%rax movq %rax,-8(%r12) - movq 7(%rbx),%rax + movq 8(%rbp),%rax movq %rax,(%r12) - movq 8(%rbp),%rsi - movq 7(%rbx),%rdi + movq 16(%rbp),%rsi + movq 8(%rbp),%rdi leaq -24(%r12),%r8 - movq $_info,(%rbp) - jmp ShortM_zdssubsumes1_info + movq $_info,8(%rbp) + addq $8,%rbp + jmp VeryLongModuleName_zdssubsumes1_info .L: - movq 24(%rbp),%rbx - movq $_info,(%rbp) + movq 56(%rbp),%rsi + movq $_info,8(%rbp) + addq $8,%rbp addq $-32,%r12 - testq $7,%rbx - jne _info - jmp *(%rbx) + jmp VeryLongModuleName_next_info .text .align 8 - .quad 516 - .quad 34 + .long VeryLongModuleName_subsumes_srt-(_info)+0 + .long 0 + .quad 134 + .quad 545460846626 +_info: +.L: + movq 7(%rbx),%rax + movq %rax,(%rbp) + movq 48(%rbp),%rsi + movq $_info,-8(%rbp) + addq $-8,%rbp + jmp VeryLongModuleName_val_info +.text + .align 8 + .long VeryLongModuleName_subsumes_srt-(_info)+0 + .long 0 + .quad 69 + .quad 545460846626 _info: .L: movq %rbx,%rax @@ -2104,7 +2779,7 @@ cmpq $2,%rax jae .L movl $ghczmprim_GHCziBool_False_closure+1,%ebx - addq $40,%rbp + addq $48,%rbp jmp *(%rbp) .L: movq 14(%rbx),%rax @@ -2117,8 +2792,10 @@ jmp *(%rbx) .text .align 8 + .long VeryLongModuleName_subsumes_srt-(_info)+0 + .long 0 .quad 1 - .quad 34 + .quad 545460846626 _info: .L: movq %rbx,%rax @@ -2129,31 +2806,34 @@ addq $16,%rbp jmp *(%rbp) .L: + movq 30(%rbx),%rax + movq %rax,-24(%rbp) movq 6(%rbx),%rax movq %rax,-16(%rbp) - movq 22(%rbx),%rax - movq %rax,-8(%rbp) movq 14(%rbx),%rax + movq %rax,-8(%rbp) + movq 22(%rbx),%rax movq %rax,(%rbp) movq 8(%rbp),%rax - movq 30(%rbx),%rcx - movq %rcx,8(%rbp) + movq %rbx,8(%rbp) movq %rax,%rbx - movq $_info,-24(%rbp) - addq $-24,%rbp + movq $_info,-32(%rbp) + addq $-32,%rbp testq $7,%rbx jne _info jmp *(%rbx) .text .align 8 + .long VeryLongModuleName_subsumes_srt-(VeryLongModuleName_subsumes_info)+0 + .long 0 .quad 8589934604 .quad 0 - .quad 15 -.globl ShortM_subsumes_info -.type ShortM_subsumes_info, @object -ShortM_subsumes_info: + .quad 545460846607 +.globl VeryLongModuleName_subsumes_info +.type VeryLongModuleName_subsumes_info, @object +VeryLongModuleName_subsumes_info: .L: - leaq -56(%rbp),%rax + leaq -64(%rbp),%rax cmpq %r14,%rax jb .L movq %rdi,-8(%rbp) @@ -2164,49 +2844,49 @@ jne _info jmp *(%rbx) .L: - movl $ShortM_subsumes_closure,%ebx + movl $VeryLongModuleName_subsumes_closure,%ebx jmp *-8(%r13) .data .align 8 -.globl ShortM_Nil_closure -.type ShortM_Nil_closure, @object -ShortM_Nil_closure: - .quad ShortM_Nil_static_info +.globl VeryLongModuleName_Nil_closure +.type VeryLongModuleName_Nil_closure, @object +VeryLongModuleName_Nil_closure: + .quad VeryLongModuleName_Nil_static_info .data .align 8 -.globl ShortM_Node_closure -.type ShortM_Node_closure, @object -ShortM_Node_closure: - .quad ShortM_Node_info +.globl VeryLongModuleName_Node_closure +.type VeryLongModuleName_Node_closure, @object +VeryLongModuleName_Node_closure: + .quad VeryLongModuleName_Node_info .text .align 8 -.globl ShortM_Node_slow -.type ShortM_Node_slow, @object -ShortM_Node_slow: +.globl VeryLongModuleName_Node_slow +.type VeryLongModuleName_Node_slow, @object +VeryLongModuleName_Node_slow: .L: movq (%rbp),%rsi movq 8(%rbp),%rdi movq 16(%rbp),%r8 movq 24(%rbp),%r9 addq $32,%rbp - jmp ShortM_Node_info + jmp VeryLongModuleName_Node_info .text .align 8 - .long ShortM_Node_slow-(ShortM_Node_info)+0 + .long VeryLongModuleName_Node_slow-(VeryLongModuleName_Node_info)+0 .long 0 .quad 68 .quad 0 .quad 17179869184 .quad 0 .quad 15 -.globl ShortM_Node_info -.type ShortM_Node_info, @object -ShortM_Node_info: +.globl VeryLongModuleName_Node_info +.type VeryLongModuleName_Node_info, @object +VeryLongModuleName_Node_info: .L: addq $40,%r12 cmpq %r15,%r12 ja .L - movq $ShortM_Node_con_info,-32(%r12) + movq $VeryLongModuleName_Node_con_info,-32(%r12) movq %rdi,-24(%r12) movq %r8,-16(%r12) movq %r9,-8(%r12) @@ -2215,7 +2895,7 @@ jmp *(%rbp) .L: movq $40,184(%r13) - movl $ShortM_Node_closure,%ebx + movl $VeryLongModuleName_Node_closure,%ebx addq $-32,%rbp movq %rsi,(%rbp) movq %rdi,8(%rbp) @@ -2230,12 +2910,24 @@ .byte 105 .byte 110 .byte 58 - .byte 83 - .byte 104 - .byte 111 + .byte 86 + .byte 101 .byte 114 - .byte 116 + .byte 121 + .byte 76 + .byte 111 + .byte 110 + .byte 103 .byte 77 + .byte 111 + .byte 100 + .byte 117 + .byte 108 + .byte 101 + .byte 78 + .byte 97 + .byte 109 + .byte 101 .byte 46 .byte 78 .byte 105 @@ -2243,13 +2935,13 @@ .byte 0 .text .align 8 - .long _str-(ShortM_Nil_static_info)+0 + .long _str-(VeryLongModuleName_Nil_static_info)+0 .long 0 .quad 0 .quad 8 -.globl ShortM_Nil_static_info -.type ShortM_Nil_static_info, @object -ShortM_Nil_static_info: +.globl VeryLongModuleName_Nil_static_info +.type VeryLongModuleName_Nil_static_info, @object +VeryLongModuleName_Nil_static_info: .L: incq %rbx jmp *(%rbp) @@ -2261,12 +2953,24 @@ .byte 105 .byte 110 .byte 58 - .byte 83 - .byte 104 - .byte 111 + .byte 86 + .byte 101 .byte 114 - .byte 116 + .byte 121 + .byte 76 + .byte 111 + .byte 110 + .byte 103 .byte 77 + .byte 111 + .byte 100 + .byte 117 + .byte 108 + .byte 101 + .byte 78 + .byte 97 + .byte 109 + .byte 101 .byte 46 .byte 78 .byte 111 @@ -2275,13 +2979,13 @@ .byte 0 .text .align 8 - .long _str-(ShortM_Node_con_info)+0 + .long _str-(VeryLongModuleName_Node_con_info)+0 .long 0 .quad 4294967299 .quad 4294967297 -.globl ShortM_Node_con_info -.type ShortM_Node_con_info, @object -ShortM_Node_con_info: +.globl VeryLongModuleName_Node_con_info +.type VeryLongModuleName_Node_con_info, @object +VeryLongModuleName_Node_con_info: .L: addq $2,%rbx jmp *(%rbp) @@ -2293,12 +2997,24 @@ .byte 105 .byte 110 .byte 58 - .byte 83 - .byte 104 - .byte 111 + .byte 86 + .byte 101 .byte 114 - .byte 116 + .byte 121 + .byte 76 + .byte 111 + .byte 110 + .byte 103 .byte 77 + .byte 111 + .byte 100 + .byte 117 + .byte 108 + .byte 101 + .byte 78 + .byte 97 + .byte 109 + .byte 101 .byte 46 .byte 78 .byte 111 @@ -2307,13 +3023,13 @@ .byte 0 .text .align 8 - .long _str-(ShortM_Node_static_info)+0 + .long _str-(VeryLongModuleName_Node_static_info)+0 .long 0 .quad 4294967299 .quad 4294967303 -.globl ShortM_Node_static_info -.type ShortM_Node_static_info, @object -ShortM_Node_static_info: +.globl VeryLongModuleName_Node_static_info +.type VeryLongModuleName_Node_static_info, @object +VeryLongModuleName_Node_static_info: .L: addq $2,%rbx jmp *(%rbp) @@ -2323,9 +3039,9 @@ .quad 0 .text .align 8 -.globl __stginit_ShortM_ -.type __stginit_ShortM_, @object -__stginit_ShortM_: +.globl __stginit_VeryLongModuleName_ +.type __stginit_VeryLongModuleName_, @object +__stginit_VeryLongModuleName_: .L: cmpq $0,_module_registered jne .L @@ -2338,10 +3054,10 @@ jmp *-8(%rbp) .text .align 8 -.globl __stginit_ShortM -.type __stginit_ShortM, @object -__stginit_ShortM: +.globl __stginit_VeryLongModuleName +.type __stginit_VeryLongModuleName, @object +__stginit_VeryLongModuleName: .L: - jmp __stginit_ShortM_ + jmp __stginit_VeryLongModuleName_ .section .note.GNU-stack,"",@progbits .ident "GHC 6.10.1" From ndmitchell at gmail.com Mon Dec 15 17:08:10 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Dec 15 17:00:52 2008 Subject: length of module name affecting performance?? In-Reply-To: <20081215215343.GA31363@scytale.galois.com> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> Message-ID: <404396ef0812151408g4fee04cn54277992975149c8@mail.gmail.com> Hi >> I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? > > Wow. Awesome bug! Got lots of discussion at Galois :) > > I can confirm a difference in running time, we also tested with 6.8.x and 6.10, > with similar results. Is -O2 implying -fvia-C? If so, could it be the evil mangler? Is there a non-alpha rename difference in the Core? Very cool bug :-) Thanks Neil From dons at galois.com Mon Dec 15 17:49:52 2008 From: dons at galois.com (Don Stewart) Date: Mon Dec 15 17:42:45 2008 Subject: length of module name affecting performance?? In-Reply-To: <20081215215343.GA31363@scytale.galois.com> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> Message-ID: <20081215224952.GB31363@scytale.galois.com> Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? -- Don From dons at galois.com Mon Dec 15 19:43:50 2008 From: dons at galois.com (Don Stewart) Date: Mon Dec 15 19:36:35 2008 Subject: length of module name affecting performance?? In-Reply-To: <20081215224952.GB31363@scytale.galois.com> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> <20081215224952.GB31363@scytale.galois.com> Message-ID: <20081216004350.GA32196@scytale.galois.com> dons: > Running time as a function of module name length, > > http://galois.com/~dons/images/results.png > > 10 is the magic threshold, where indirections start creeping in. > > Codegen cost heuristic fail? Given this, could you open a bug ticket for it, with all the info we have, http://hackage.haskell.org/trac/ghc/newticket?type=bug E.g. the graph, the code, the asm diff. Cheers, Don From lennart at augustsson.net Mon Dec 15 21:00:38 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Dec 15 20:53:20 2008 Subject: length of module name affecting performance?? In-Reply-To: <20081216004350.GA32196@scytale.galois.com> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> <20081215224952.GB31363@scytale.galois.com> <20081216004350.GA32196@scytale.galois.com> Message-ID: That's a truly awesome feature! I'll shorten all my module names to single letters tomorrow. -- Lennart On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart wrote: > dons: >> Running time as a function of module name length, >> >> http://galois.com/~dons/images/results.png >> >> 10 is the magic threshold, where indirections start creeping in. >> >> Codegen cost heuristic fail? > > Given this, could you open a bug ticket for it, with all the info we > have, > > http://hackage.haskell.org/trac/ghc/newticket?type=bug > > E.g. the graph, the code, the asm diff. > > Cheers, > Don > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From sof at galois.com Mon Dec 15 22:26:02 2008 From: sof at galois.com (Sigbjorn Finne) Date: Mon Dec 15 22:18:58 2008 Subject: length of module name affecting performance?? In-Reply-To: References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> <20081215224952.GB31363@scytale.galois.com> <20081216004350.GA32196@scytale.galois.com> Message-ID: <49471FCA.3050107@galois.com> Ditto. Can I claim the [A-Z].* hierarchies as belonging to me? :-) --sigbjorn "putting them up on eBay afterwards...maybe" On 12/15/2008 18:00, Lennart Augustsson wrote: > That's a truly awesome feature! I'll shorten all my module names to > single letters tomorrow. > > -- Lennart > > On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart wrote: > >> dons: >> >>> Running time as a function of module name length, >>> >>> http://galois.com/~dons/images/results.png >>> >>> 10 is the magic threshold, where indirections start creeping in. >>> >>> Codegen cost heuristic fail? >>> >> Given this, could you open a bug ticket for it, with all the info we >> have, >> >> http://hackage.haskell.org/trac/ghc/newticket?type=bug >> >> E.g. the graph, the code, the asm diff. >> >> Cheers, >> Don >> _______________________________________________ >> 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 dgorin at dc.uba.ar Mon Dec 15 22:44:07 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Mon Dec 15 22:36:56 2008 Subject: length of module name affecting performance?? In-Reply-To: <20081216004350.GA32196@scytale.galois.com> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> <20081215224952.GB31363@scytale.galois.com> <20081216004350.GA32196@scytale.galois.com> Message-ID: On Dec 15, 2008, at 10:43 PM, Don Stewart wrote: > dons: >> Running time as a function of module name length, >> >> http://galois.com/~dons/images/results.png >> >> 10 is the magic threshold, where indirections start creeping in. >> >> Codegen cost heuristic fail? > > Given this, could you open a bug ticket for it, with all the info we > have, > > http://hackage.haskell.org/trac/ghc/newticket?type=bug > > E.g. the graph, the code, the asm diff. > > Cheers, > Don done! http://hackage.haskell.org/trac/ghc/ticket/2884 thanks, daniel From marlowsd at gmail.com Tue Dec 16 04:55:04 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Dec 16 04:47:49 2008 Subject: length of module name affecting performance?? In-Reply-To: References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> <20081215224952.GB31363@scytale.galois.com> <20081216004350.GA32196@scytale.galois.com> Message-ID: <49477AF8.7000802@gmail.com> Daniel Gor?n wrote: > On Dec 15, 2008, at 10:43 PM, Don Stewart wrote: > >> dons: >>> Running time as a function of module name length, >>> >>> http://galois.com/~dons/images/results.png >>> >>> 10 is the magic threshold, where indirections start creeping in. >>> >>> Codegen cost heuristic fail? >> >> Given this, could you open a bug ticket for it, with all the info we >> have, >> >> http://hackage.haskell.org/trac/ghc/newticket?type=bug >> >> E.g. the graph, the code, the asm diff. >> >> Cheers, >> Don > > done! http://hackage.haskell.org/trac/ghc/ticket/2884 I followed up on the ticket. Basically the problem is to do with inlining of record selectors: when the module name is too long, none of the record selectors get inlined. Cheers, Simon From haskell at list.mightyreason.com Tue Dec 16 05:00:33 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Dec 16 04:53:17 2008 Subject: length of module name affecting performance?? In-Reply-To: <20081215215343.GA31363@scytale.galois.com> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> Message-ID: <49477C41.9020108@list.mightyreason.com> I suddenly wonder if renaming "Text.ParserCombinators.Parsec.Combinator" would be a performance hack.... -- C From lazyswamp at gmail.com Tue Dec 16 07:08:16 2008 From: lazyswamp at gmail.com (Kwanghoon Choi) Date: Tue Dec 16 07:01:42 2008 Subject: Type signature inside an instance declaration Message-ID: <2d44ccdd0812160408s515b8a0aq64d6fb5f59606ecd@mail.gmail.com> ======================================================================= module Test where class Arg a where pr :: a -> String instance Arg Int where pr _ = "i" instance Arg Char where pr _ = "c" instance Arg a => Arg [a] where pr _ = "[" ++ pr (undefined :: a) ++ "]" -- the type variable 'a' is interpreted as an unbound one. -- (1) pr :: [a] -> String -- (2) pr (_ :: [a]) = "[" ++ pr (undefined :: a) ++ "]" ======================================================================= Dear All, I got some problem when I try to compile the above program. The problem is due to the presence of a type variable 'a' in the body of the last instance declaration. How could I refer to the type variable of Arg [a] in the instance declaration? I tried these options 1) by giving an explicit declaration for pr 2) by giving a type signature to the argument of pr with -XPatternsSignatures The first option gives me back an error : Misplaced type signature: pr :: [a] -> String The type signature must be given where `pr' is declared The second option gives me an error: Test.hs:21:12: Not in scope: type variable `a' Would anybody help me to understand this problem? Thanks in advance. Kwanghoon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081216/563f748c/attachment-0001.htm From Malcolm.Wallace at cs.york.ac.uk Tue Dec 16 07:26:54 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Dec 16 07:22:22 2008 Subject: Type signature inside an instance declaration In-Reply-To: <2d44ccdd0812160408s515b8a0aq64d6fb5f59606ecd@mail.gmail.com> References: <2d44ccdd0812160408s515b8a0aq64d6fb5f59606ecd@mail.gmail.com> Message-ID: <20081216122654.2c389e84.Malcolm.Wallace@cs.york.ac.uk> "Kwanghoon Choi" wrote: > ===================================================================== > instance Arg a => Arg [a] where > pr _ = "[" ++ pr (undefined :: a) ++ "]" > ===================================================================== You want to use `asTypeOf`, with a lazy pattern to name a value of type 'a'. pr xs = "[" ++ pr (undefined `asTypeOf` x) ++ "]" where (x:_) = xs or pr ~(x:_) = "[" ++ pr (undefined `asTypeOf` x) ++ "]" Regards, Malcolm From ndmitchell at gmail.com Tue Dec 16 07:35:47 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Dec 16 07:28:27 2008 Subject: Type signature inside an instance declaration In-Reply-To: <20081216122654.2c389e84.Malcolm.Wallace@cs.york.ac.uk> References: <2d44ccdd0812160408s515b8a0aq64d6fb5f59606ecd@mail.gmail.com> <20081216122654.2c389e84.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0812160435j33b2c3e5u549769af4c9659a6@mail.gmail.com> Hi > You want to use `asTypeOf`, with a lazy pattern to name a value of type 'a'. > > pr xs = "[" ++ pr (undefined `asTypeOf` x) ++ "]" > where (x:_) = xs I prefer: pr xs = "[" ++ pr (undefined `asTypeOf` head x) ++ "]" Or even more simply: pr xs = "[" ++ pr (head x) ++ "]" I do believe there is some GHC extension that can be turned on to refer to variables like you did, but its not standard Haskell. Thanks Neil From nominolo at googlemail.com Tue Dec 16 09:22:15 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Dec 16 09:14:55 2008 Subject: Type signature inside an instance declaration In-Reply-To: <404396ef0812160435j33b2c3e5u549769af4c9659a6@mail.gmail.com> References: <2d44ccdd0812160408s515b8a0aq64d6fb5f59606ecd@mail.gmail.com> <20081216122654.2c389e84.Malcolm.Wallace@cs.york.ac.uk> <404396ef0812160435j33b2c3e5u549769af4c9659a6@mail.gmail.com> Message-ID: <916b84820812160622k6921b643sefd953512efd631a@mail.gmail.com> {-# LANGUAGE ScopedTypeVariables #-} 2008/12/16 Neil Mitchell : > Hi > >> You want to use `asTypeOf`, with a lazy pattern to name a value of type 'a'. >> >> pr xs = "[" ++ pr (undefined `asTypeOf` x) ++ "]" >> where (x:_) = xs > > I prefer: > > pr xs = "[" ++ pr (undefined `asTypeOf` head x) ++ "]" > > Or even more simply: > > pr xs = "[" ++ pr (head x) ++ "]" > > I do believe there is some GHC extension that can be turned on to > refer to variables like you did, but its not standard Haskell. > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Push the envelope. Watch it bend. From lazyswamp at gmail.com Tue Dec 16 10:22:58 2008 From: lazyswamp at gmail.com (Kwanghoon Choi) Date: Tue Dec 16 10:16:10 2008 Subject: Type signature inside an instance declaration In-Reply-To: <916b84820812160622k6921b643sefd953512efd631a@mail.gmail.com> References: <2d44ccdd0812160408s515b8a0aq64d6fb5f59606ecd@mail.gmail.com> <20081216122654.2c389e84.Malcolm.Wallace@cs.york.ac.uk> <404396ef0812160435j33b2c3e5u549769af4c9659a6@mail.gmail.com> <916b84820812160622k6921b643sefd953512efd631a@mail.gmail.com> Message-ID: <2d44ccdd0812160722w302dff09l45cb86c26e65d3a2@mail.gmail.com> Many thanks for your helps. Kwanghoon On Tue, Dec 16, 2008 at 11:22 PM, Thomas Schilling wrote: > {-# LANGUAGE ScopedTypeVariables #-} > > 2008/12/16 Neil Mitchell : > > Hi > > > >> You want to use `asTypeOf`, with a lazy pattern to name a value of type > 'a'. > >> > >> pr xs = "[" ++ pr (undefined `asTypeOf` x) ++ "]" > >> where (x:_) = xs > > > > I prefer: > > > > pr xs = "[" ++ pr (undefined `asTypeOf` head x) ++ "]" > > > > Or even more simply: > > > > pr xs = "[" ++ pr (head x) ++ "]" > > > > I do believe there is some GHC extension that can be turned on to > > refer to variables like you did, but its not standard Haskell. > > > > Thanks > > > > Neil > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > -- > Push the envelope. Watch it bend. > _______________________________________________ > 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/20081217/d8ba6503/attachment.htm From uhollerbach at gmail.com Tue Dec 16 21:54:39 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Tue Dec 16 21:47:18 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1229074569.8624.1289676315@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <20081203203121.GA13500@matrix.chaos.earth.li> <1228397013.1346.1288235643@webmail.messagingengine.com> <493FB0A6.5080505@gmail.com> <1229074569.8624.1289676315@webmail.messagingengine.com> Message-ID: <65d7a7e0812161854g2b1afca0q8ae719e43bd42035@mail.gmail.com> Hello Barney & all, I've been following your messages with some interest, as I too have been trying to build a more-modern ghc on my G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and tried to build 6.8.3; I'm finally at the point where I have something to report, although I'm not sure if it's a success or a failure report... :-/ I applied your patch to package.conf.in (approximately; the relevant section wasn't quite identical), edited rts/Linker.c to add "#define LC_SEGMENT_64 LC_SEGMENT", and hacked up a wrapper script around ar to always ranlib the library being processed; you had mentioned patching cabal, but I decided the wrapper around ar was easier... a hack, but what the hell. After that, "configure && make" ran to completion without errors (although it took a couple of days, since I had all the extralibs). Success! ... or is it? I installed the new compiler into /usr/local, then tested it by trying "ghc -v". Alas, no joy! It died with some dynamic-link error which I've approximately reproduced here: lupus:~/ghc-6.8.3% ghc-6.8.3 -v dyld: relocation error (external relocation for symbol _pthread_mutex_unlock in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap Failure! ... or is it? I thought, how can this be?!? It built itself through stage2, it has to be good! But clearly it isn't... So I tried one last thing: I tried to use the stage1 compiler directly to compile the scheme interpreter I wrote nearly a year ago. That initially failed, too, but for a simple reason, and one I could work around: no readline in ghc 6.8.3. Once I changed the scheme interpreter to not use readline, it compiled, linked, and runs. So... success or failure? I'm really not quite sure... I guess I could try installing the stage1 compiler instead of the stage2 compiler, it seems that it might work. But it would appear that there is still something not entirely right in there. regards, Uwe From sebf at informatik.uni-kiel.de Wed Dec 17 04:54:43 2008 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Wed Dec 17 04:47:43 2008 Subject: unique identifiers as a separate library Message-ID: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> Hello, for a project I am using the libraries Unique, UniqSupply, and UniqFM from the package ghc. It seems odd to have a dependency on a whole compiler only in order to use its (highly efficient and, hence, preferred) implementation of unique identifiers. Would it be possible to put everything concerned with unique identifiers in GHC into a separate package on Hackage? This may also allow me to get a fix for without reinstalling GHC. Cheers, Sebastian From jorge.pelizzoni at gmail.com Wed Dec 17 13:25:26 2008 From: jorge.pelizzoni at gmail.com (Jorge Marques Pelizzoni) Date: Wed Dec 17 13:18:04 2008 Subject: type families and overlapping Message-ID: Hi, While playing with type families in GHC 6.10.1, I guess I bumped into the no-overlap restriction. As I couldn't find any examples on that, I include the following (non-compiling) code so as to check with you if that's really the case: ------------------------------------------- {-# OPTIONS -fglasgow-exts #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE UndecidableInstances #-} module Main where class Expr t where type ExprRslt t :: * eval :: t -> ExprRslt t instance Expr t where type ExprRslt t = t -- overlap? eval = id data Vector a = Vector {width :: !Int, dat :: [a]} data Subscript a = Subscript {vec :: (Vector a), ind :: !Int} instance Expr (Subscript a) where type ExprRslt (Subscript a) = a eval sub = (dat.vec $ sub) !! ind sub ------------------------------------------------ So this means that classes with associated types cannot have default instances at all? If so, could you possibly refer me to any material explaining why? Thanks in advance. Cheers, Jorge. -------------- next part -------------- A non-text attachment was scrubbed... Name: TrimmedDown.hs Type: application/octet-stream Size: 993 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081217/98225a9f/TrimmedDown.obj From dan.doel at gmail.com Wed Dec 17 14:52:49 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Dec 17 14:45:32 2008 Subject: type families and overlapping In-Reply-To: References: Message-ID: <200812171452.50496.dan.doel@gmail.com> On Wednesday 17 December 2008 1:25:26 pm Jorge Marques Pelizzoni wrote: > Hi, > > While playing with type families in GHC 6.10.1, I guess I bumped into > the no-overlap restriction. As I couldn't find any examples on that, I > include the following (non-compiling) code so as to check with you if > that's really the case: > > ------------------------------------------- > {-# OPTIONS -fglasgow-exts #-} > {-# LANGUAGE OverlappingInstances #-} > {-# LANGUAGE UndecidableInstances #-} > > module Main where > > class Expr t where > type ExprRslt t :: * > eval :: t -> ExprRslt t > > instance Expr t where > type ExprRslt t = t -- overlap? > eval = id > > data Vector a = Vector {width :: !Int, dat :: [a]} > data Subscript a = Subscript {vec :: (Vector a), ind :: !Int} > > instance Expr (Subscript a) where > type ExprRslt (Subscript a) = a > eval sub = (dat.vec $ sub) !! ind sub > ------------------------------------------------ > > So this means that classes with associated types cannot have default > instances at all? If so, could you possibly refer me to any material > explaining why? Overlapping instances for type families is unsound in general. Consider if your code were broken into modules. One might only see your "default" instance, and that would allow it to use: ExprRslt (Subscript a) = Subscript a However, when the more specific instance is in scope, ExprRslt (Subscript a) = a Which allows you to treat Subscript a from the first module as a. For instance, if the first module had: foo :: Subscript a -> ExprRslt (Subscript a) foo = eval -- = id Then you can write in the second module: coerce :: Subscript a -> a coerce = foo -- = id Which is bad news. Thus, overlapping instances are disallowed for type families (the only way I can think of at a glance to make overlapping sound is to make instances actually global, and do whole-program compilation. But maybe that wouldn't even work). Hope that helps. -- Dan From marlowsd at gmail.com Thu Dec 18 10:11:33 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 18 10:04:14 2008 Subject: unique identifiers as a separate library In-Reply-To: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> Message-ID: <494A6825.7030107@gmail.com> Sebastian Fischer wrote: > for a project I am using the libraries Unique, UniqSupply, and UniqFM > from the package ghc. It seems odd to have a dependency on a whole > compiler only in order to use its (highly efficient and, hence, > preferred) implementation of unique identifiers. > > Would it be possible to put everything concerned with unique identifiers > in GHC into a separate package on Hackage? > > This may also allow me to get a fix for > without reinstalling GHC. Sure, that would be a useful chunk to separate out from GHC. However, looking at the code I see that our unique supply monad is really not a lazy monad at all: thenUs :: UniqSM a -> (a -> UniqSM b) -> UniqSM b thenUs expr cont us = case (expr us) of { (result, us') -> cont result us' } which is strict, and even the lazy version: lazyThenUs :: UniqSM a -> (a -> UniqSM b) -> UniqSM b lazyThenUs (USM expr) cont = USM (\us -> let (result, us') = expr us in unUSM (cont result) us') doesn't really split the supply, because it will force the left side as soon as the unique on the right side is demanded. Given that our monad is strict, there's no need for it to use mkSplitUniqueSupply, it could just call genSym to create new uniques. I notice there are other parts of the compiler that do make use of the lazy splittable unique supply in their own monads, but I'm not sure if they really need it. Cheers, Simon From sebf at informatik.uni-kiel.de Thu Dec 18 11:58:11 2008 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Thu Dec 18 11:50:52 2008 Subject: unique identifiers as a separate library In-Reply-To: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> Message-ID: <86274BA3-1DD7-43C4-B72D-197860A9A9F5@informatik.uni-kiel.de> On Dec 17, 2008, at 10:54 AM, Sebastian Fischer wrote: > Would it be possible to put everything concerned with unique > identifiers in GHC into a separate package on Hackage? I have wrapped up (a tiny subset of) GHC's uniques into the package `uniqueid` and put it on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uniqueid It only provides type Id hashedId :: Id -> Int type IdSupply initIdSupply :: Char -> IO IdSupply splitIdSupply :: IdSupply -> (IdSupply,IdSupply) idFromSupply :: IdSupply -> Id instance Eq Id instance Ord Id instance Show Id The main difference is due to my fear of depending on the foreign function `genSymZh` which I replaced by a global counting IORef. The other difference is that the Show instance does not rely on GHC's static flags and can hence be used outside of GHC sessions. The code is on github: http://github.com/sebfisch/uniqueid Extensions welcome! Cheers, Sebastian From isaacdupree at charter.net Thu Dec 18 12:55:20 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Dec 18 12:47:56 2008 Subject: unique identifiers as a separate library In-Reply-To: <86274BA3-1DD7-43C4-B72D-197860A9A9F5@informatik.uni-kiel.de> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> <86274BA3-1DD7-43C4-B72D-197860A9A9F5@informatik.uni-kiel.de> Message-ID: <494A8E88.7090308@charter.net> Sebastian Fischer wrote: > On Dec 17, 2008, at 10:54 AM, Sebastian Fischer wrote: > >> Would it be possible to put everything concerned with unique >> identifiers in GHC into a separate package on Hackage? > > > I have wrapped up (a tiny subset of) GHC's uniques into the package > `uniqueid` and put it on Hackage: thanks! > The main difference is due to my fear of depending on the foreign > function `genSymZh` which I replaced by a global counting IORef. which is its own risk. maybe you should NOINLINE it? Potential code criticisms / suggestions for it as a library: Unboxed: so it only works on GHC, even though others have unsafe IO too. In theory, strictness annotations should be able to achieve the same efficiency. "Char" is supposed to represent a Unicode character -- but this code behaves oddly: For 64-bit Int#, it does so. For 32-bit Int#, it assumes Char is within the first 8 bits (ASCII and a little more). If Int# (or Int) can be 30-bit (like Haskell98 permission), its correctness suffers even worse. Is it really even a necessary part of the design? The only way you provide to extract it or depend on its value is indirectly via the "Show" instance. Its presence there is, in any case, at the cost of max. 2^24 (16 million) IDs before problems happen, whereas billions is still not a great limit but at least is somewhat larger. (applications that are long-running or deal with huge amounts of data could be affected) unsafeDupableInterleaveIO: this "Dupable" was safe for GHC to use because GHC is single-threaded. Is it safe in a library setting? I guess likewise, the IORef global variable wouldn't be thread-safe... but this one isn't even safe between separate runs of initIdSupply. On the other hand, thread-safety probably makes it much less efficient (if you can find a way to use atomic int CPU instructions, it might not be too bad, or else per-thread counters... or just declare how unsafe it is) unsafePerformIO: it's not totally necessary here. Its only function is to make IDs generated by different runs of initIdSupply be distinct. So it could, anyway, probably be refactored to only use unsafePerformIO global-ness once per initIdSupply and just use unsafeInterleaveIO within (where currently nextInt is called). -Isaac From ajb at spamcop.net Thu Dec 18 18:39:39 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Dec 18 18:32:19 2008 Subject: unique identifiers as a separate library In-Reply-To: <86274BA3-1DD7-43C4-B72D-197860A9A9F5@informatik.uni-kiel.de> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> <86274BA3-1DD7-43C4-B72D-197860A9A9F5@informatik.uni-kiel.de> Message-ID: <20081218183939.nllqm73tkcgkcc44-nwo@webmail.spamcop.net> G'day all. Quoting Sebastian Fischer : > I have wrapped up (a tiny subset of) GHC's uniques into the package > `uniqueid` and put it on Hackage: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uniqueid First off, thanks for this. > The main difference is due to my fear of depending on the foreign > function `genSymZh` which I replaced by a global counting IORef. Why not depend on this instead? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply Cheers, Andrew Bromage From marlowsd at gmail.com Fri Dec 19 04:24:58 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Dec 19 04:17:34 2008 Subject: unique identifiers as a separate library In-Reply-To: <20081218183939.nllqm73tkcgkcc44-nwo@webmail.spamcop.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> Message-ID: <494B686A.7050800@gmail.com> ajb@spamcop.net wrote: > G'day all. > > Quoting Sebastian Fischer : > >> I have wrapped up (a tiny subset of) GHC's uniques into the package >> `uniqueid` and put it on Hackage: >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uniqueid > > First off, thanks for this. > >> The main difference is due to my fear of depending on the foreign >> function `genSymZh` which I replaced by a global counting IORef. > > Why not depend on this instead? > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply Looking at the code for this, I'm somewhat suspicious that it actually works with GHC: -- The extra argument to ``gen'' is passed because without -- it Hugs spots that the recursive calls are the same but does -- not know that unsafePerformIO is unsafe. where gen _ r = Node { supplyValue = unsafePerformIO (genSym r), supplyLeft = gen False r, supplyRight = gen True r } even if that extra Bool argument is enough to fool Hugs, I wouldn't count on it being enough to fool GHC -O2! You probably want to use unsafeInterleaveIO like we do in GHC's UniqSupply library. Also, I'd replace the MVar with an IORef and use atomicModifyIORef for speed. Cheers, Simon From marlowsd at gmail.com Fri Dec 19 04:28:01 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Dec 19 04:20:36 2008 Subject: unique identifiers as a separate library In-Reply-To: <494A8E88.7090308@charter.net> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> <86274BA3-1DD7-43C4-B72D-197860A9A9F5@informatik.uni-kiel.de> <494A8E88.7090308@charter.net> Message-ID: <494B6921.30900@gmail.com> Isaac Dupree wrote: > Sebastian Fischer wrote: >> On Dec 17, 2008, at 10:54 AM, Sebastian Fischer wrote: >> >>> Would it be possible to put everything concerned with unique >>> identifiers in GHC into a separate package on Hackage? >> >> >> I have wrapped up (a tiny subset of) GHC's uniques into the package >> `uniqueid` and put it on Hackage: > > thanks! > >> The main difference is due to my fear of depending on the foreign >> function `genSymZh` which I replaced by a global counting IORef. > > which is its own risk. maybe you should NOINLINE it? > > Potential code criticisms / suggestions for it as a library: > > Unboxed: so it only works on GHC, even though others have unsafe IO > too. In theory, strictness annotations should be able to achieve the > same efficiency. > > "Char" is supposed to represent a Unicode character -- but this code > behaves oddly: > For 64-bit Int#, it does so. > For 32-bit Int#, it assumes Char is within the first 8 bits (ASCII and a > little more). > If Int# (or Int) can be 30-bit (like Haskell98 permission), its > correctness suffers even worse. > Is it really even a necessary part of the design? The only way you > provide to extract it or depend on its value is indirectly via the > "Show" instance. Its presence there is, in any case, at the cost of > max. 2^24 (16 million) IDs before problems happen, whereas billions is > still not a great limit but at least is somewhat larger. (applications > that are long-running or deal with huge amounts of data could be affected) > > unsafeDupableInterleaveIO: this "Dupable" was safe for GHC to use > because GHC is single-threaded. Is it safe in a library setting? It would be safe if the genSym was atomic - so I recommend using atomicModifyIORef. Cheers, Simon From marlowsd at gmail.com Fri Dec 19 04:30:26 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Dec 19 04:23:03 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <65d7a7e0812161854g2b1afca0q8ae719e43bd42035@mail.gmail.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <20081203203121.GA13500@matrix.chaos.earth.li> <1228397013.1346.1288235643@webmail.messagingengine.com> <493FB0A6.5080505@gmail.com> <1229074569.8624.1289676315@webmail.messagingengine.com> <65d7a7e0812161854g2b1afca0q8ae719e43bd42035@mail.gmail.com> Message-ID: <494B69B2.9090206@gmail.com> Uwe Hollerbach wrote: > Hello Barney & all, I've been following your messages with some > interest, as I too have been trying to build a more-modern ghc on my > G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and > tried to build 6.8.3; I'm finally at the point where I have something > to report, although I'm not sure if it's a success or a failure > report... :-/ > > I applied your patch to package.conf.in (approximately; the relevant > section wasn't quite identical), edited rts/Linker.c to add "#define > LC_SEGMENT_64 LC_SEGMENT", and hacked up a wrapper script around ar to > always ranlib the library being processed; you had mentioned patching > cabal, but I decided the wrapper around ar was easier... a hack, but > what the hell. > > After that, "configure && make" ran to completion without errors > (although it took a couple of days, since I had all the extralibs). > > Success! ... or is it? > > I installed the new compiler into /usr/local, then tested it by trying > "ghc -v". Alas, no joy! It died with some dynamic-link error which > I've approximately reproduced here: > > lupus:~/ghc-6.8.3% ghc-6.8.3 -v > dyld: relocation error (external relocation for symbol _pthread_mutex_unlock > in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap > > Failure! ... or is it? I'd guess that the size of the binary has caused some kind of overflow of a short relocation field. Any experts in MacOS linking around? You might want to try the testsuite with stage1 and see whether the failure shows up anywhere else. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Fri Dec 19 18:00:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Dec 19 17:52:55 2008 Subject: please test: cabal install now less eager to reinstall core packages Message-ID: <1229727625.10115.809.camel@localhost> Claus, Simon, You'll recall the cabal-install problem you noticed recently where it decides it wants to re-install some core library like array or containers or whatever. I'd appreciate it if you could test the darcs version of cabal-install and see if it is behaving better now. It was choosing to re-install packages when the way it had chosen to configure the available version of the package (ie what exact dependencies it'd picked) did not exactly match those of the installed package. I've changed things so that it now picks the installed version when the additional constraints it adds (direct and indirect dependencies) do not conflict with the existing constraints. This means it'll pick the installed instance in many more cases and when it does not that there is a more legitimate reason. It still may have been possible to use the installed version if we had known that information much earlier and made different choices at an earlier stage. I've not yet added support for user supplied install constraints but I plan to shortly (eg --constraint='array installed'). Duncan From dominic.steinitz at blueyonder.co.uk Sun Dec 21 04:37:36 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sun Dec 21 04:41:20 2008 Subject: GADT Strangeness Message-ID: <494E0E60.5000902@blueyonder.co.uk> 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. Can anyone offer an explanation as to what is happening? Dominic. From kyagrd at gmail.com Sun Dec 21 08:34:28 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Sun Dec 21 08:44:59 2008 Subject: Graham Hutton's calculator example for win32 Message-ID: In Graham Hutton's "Programming in Haskell" there is an interactive calculator example using ANSI code to implement the UI on the terminal. This example doesn't work on MS Windows XP or other MS OSes based on NT kernel, since their command line does not support ANSI very well. But, thanks to ansi-terminal on Hackage, I was able to extract minimal code from the package to make a win32 version of the calculator example in Hutton's book. calculatorWin32.lhs and Win32ANSI.hs is an implementation for win32. I extracted the win32 console API bindings for setting cursor positions from ansi-terminal project and put them in Win32ANSI.hs. I had to put this in a separate file because I had an issue with ghci. To run this, I had to compile the console API bindings with ghc first and then run ghci as follows C:\> ghc -c Win32ANSI.hs C:\> ghci calculatorWin32.lhs Without compiling the object code, ghci cannot find the proper link for win32 console API FFI bindings. C:\> ghci calculatorWin32.lhs 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 3] Compiling Parsing ( Parsing.lhs, interpreted ) [2 of 3] Compiling Win32ANSI ( Win32ANSI.hs, interpreted ) During interactive linking, GHCi couldn't find the following symbol: GetConsoleScreenBufferInfo@8 This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org Is this a bug or a natural behavior of ghci? This is strange to me since ghci finds the proper link for the functions in the other C libraries such as getch in conio.h. In addition, I am attaching a patched calculator.lhs which works for Unix/Linux on both GHC 6.8.x and GHC 6.10.1. The one currently on the book homepage only works for GHC 6.8.x but not GHC 6.10.1. This is due to the bug fix of hSetBuffering in GHC 6.10.1. To run these calculator example you will also need Parsing.lhs from the book hompage. http://www.cs.nott.ac.uk/~gmh/Parsing.lhs -- Ahn, Ki Yung -------------- next part -------------- A non-text attachment was scrubbed... Name: calculatorWin32.lhs Type: text/x-literate-haskell Size: 6328 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081221/c570be8f/calculatorWin32.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32ANSI.hs Type: text/x-haskell Size: 8105 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081221/c570be8f/Win32ANSI.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: calculator.lhs Type: text/x-literate-haskell Size: 5984 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081221/c570be8f/calculator.bin From uhollerbach at gmail.com Sun Dec 21 11:27:05 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Sun Dec 21 11:19:30 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <494B69B2.9090206@gmail.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <20081203203121.GA13500@matrix.chaos.earth.li> <1228397013.1346.1288235643@webmail.messagingengine.com> <493FB0A6.5080505@gmail.com> <1229074569.8624.1289676315@webmail.messagingengine.com> <65d7a7e0812161854g2b1afca0q8ae719e43bd42035@mail.gmail.com> <494B69B2.9090206@gmail.com> Message-ID: <65d7a7e0812210827x31234848w16303aa5e9725fe@mail.gmail.com> On 12/19/08, Simon Marlow wrote: >> lupus:~/ghc-6.8.3% ghc-6.8.3 -v >> dyld: relocation error (external relocation for symbol >> _pthread_mutex_unlock >> in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap >> >> Failure! ... or is it? > > I'd guess that the size of the binary has caused some kind of overflow of a > short relocation field. Any experts in MacOS linking around? > > You might want to try the testsuite with stage1 and see whether the failure > shows up anywhere else. > > Cheers, > Simon Thanks, I will try that and see what I can find out. regards, Uwe From iavor.diatchki at gmail.com Sun Dec 21 14:05:56 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Dec 21 13:58:19 2008 Subject: unique identifiers as a separate library In-Reply-To: <494B686A.7050800@gmail.com> 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> Message-ID: <5ab17e790812211105u1a384d7bs9a284dbe10c2d616@mail.gmail.com> Hello, I have made the two changes that Simon suggested and uploaded a new version of the library. By the way, GHC seemed to work correctly even without the extra boolean parameter, perhaps it treats unsafePerformIO specially somehow? A somewhat related question: I ended up using three calls to unsafeInterleaveIO which seems like a bit much. Could I have done it in a different way somehow? This is what I did: gen r = do v <- unsafeInterleaveIO (genSym r) ls <- unsafeInterleaveIO (gen r) rs <- unsafeInterleaveIO (gen r) return (Node v ls rs) Note that a single unsafeInterleaveIO around the whole do block is not quite right (this is what the code in the other package does) because this will increment the name as soon as the generator object is forced, and we want the name to be increment when the name is forced. -Iavor On Fri, Dec 19, 2008 at 1:24 AM, Simon Marlow wrote: >> Why not depend on this instead? >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply > > Looking at the code for this, I'm somewhat suspicious that it actually works > with GHC: > > -- The extra argument to ``gen'' is passed because without > -- it Hugs spots that the recursive calls are the same but does > -- not know that unsafePerformIO is unsafe. > where gen _ r = Node { supplyValue = unsafePerformIO (genSym r), > supplyLeft = gen False r, > supplyRight = gen True r } > > even if that extra Bool argument is enough to fool Hugs, I wouldn't count on > it being enough to fool GHC -O2! You probably want to use > unsafeInterleaveIO like we do in GHC's UniqSupply library. > > Also, I'd replace the MVar with an IORef and use atomicModifyIORef for > speed. > > Cheers, > Simon > From gtener at gmail.com Sun Dec 21 19:47:59 2008 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Sun Dec 21 19:40:22 2008 Subject: Possible Haddock bug affecting GHC docs In-Reply-To: <220e47b40812211644t34a7852nb00f8776f2569c8@mail.gmail.com> References: <220e47b40812211644t34a7852nb00f8776f2569c8@mail.gmail.com> Message-ID: <220e47b40812211647ta642ffck55c33b542956dc8@mail.gmail.com> Hello everyone Please visit these to pages: http://www.haskell.org/ghc/docs/6.8.3/html/libraries/haskell98/CTypes.html -- ver 0.9 http://www.haskell.org/ghc/docs/6.10.1/html/libraries/haskell98/CTypes.html -- ver 2.3.0 They show documentation produced by Haddock. The problem is: on the second page (for GHC 6.10.1) there is no information about exported module: > module CTypes (module Foreign.C.Types) where > import Foreign.C.Types It seems it has something to do with bug fixed by 2.3.0 version of Haddock: (see http://haskell.org/haddock/CHANGES.txt ) > Changed in version 2.3.0: > (...) > * Fix a bug that made hidden modules show up in the contents & index pages > (...) This is really annoying, especially that documentation on page doesn't contain links for source code. I think this should be fixed too. I also checked that information about exported modules appears when there is more thing to export like in Control.Concurrent. I didn't file a Haddock bug since I failed to make minimal example that reproduces the bug. A.hs: > module A (module B) where > > import B B.hs: > module B (one,two) where > > one :: Int > one = 1 > > two :: Int > two = 2 Turns out to generate good documentation. Perhaps there is something more to be done to actually trigger the bug. I attach my testing suite (A.hs, B.hs, Makefile, results). All best Christopher Skrz?tnicki -------------- next part -------------- A non-text attachment was scrubbed... Name: haddock-bug.7z Type: application/octet-stream Size: 4445 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081222/7a658207/haddock-bug.obj From g9ks157k at acme.softbase.org Sun Dec 21 20:23:30 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sun Dec 21 20:15:57 2008 Subject: Type families: module export of instance data constructor In-Reply-To: References: Message-ID: <200812220223.30638.g9ks157k@acme.softbase.org> Am Montag, 15. Dezember 2008 02:17 schrieb Ben Horsfall: > I have a type family > > class Lang term where > data Token term :: * > > with > > instance Lang Term where > newtype Token Term = T String > > I can't work out how to export the type constructor T from the module, > unless I make no explict exports from the module at all. > > > Ben Hello Ben, try Lang (type Token) in the export list. Best wishes, Wolfgang From dons at galois.com Sun Dec 21 22:30:49 2008 From: dons at galois.com (Don Stewart) Date: Sun Dec 21 22:23:06 2008 Subject: [Haskell-cafe] Can I build and install GHC 6.10.1 without previous installed ghc In-Reply-To: <2667F74761A946468605DA9E63434A08692232@CNBEEXC006.nsn-intra.net> References: <2667F74761A946468605DA9E63434A08692232@CNBEEXC006.nsn-intra.net> Message-ID: <20081222033049.GA25985@scytale.galois.com> chunye.wang: > Hi All, > > > I have our own Linux distribution installed in my server. > it is based on RedHat 9.0. Because it is the server, I can > not update it to any other linux distribution > > Here is my situation, I have no machine with any version of ghc > installed. Please use a basic linux binary. http://haskell.org/ghc/download_ghc_6_10_1.html#x86linux Such as "Linux (x86)" -- Don From ben.horsfall at gmail.com Mon Dec 22 00:26:11 2008 From: ben.horsfall at gmail.com (Ben Horsfall) Date: Mon Dec 22 00:18:35 2008 Subject: Type families: module export of instance data constructor In-Reply-To: <200812220223.30638.g9ks157k@acme.softbase.org> References: <200812220223.30638.g9ks157k@acme.softbase.org> Message-ID: Hi Wolfgang, On Mon, Dec 22, 2008 at 12:23 PM, Wolfgang Jeltsch wrote: > Am Montag, 15. Dezember 2008 02:17 schrieb Ben Horsfall: >> I have a type family >> >> class Lang term where >> data Token term :: * >> >> with >> >> instance Lang Term where >> newtype Token Term = T String >> >> I can't work out how to export the type constructor T from the module, >> unless I make no explict exports from the module at all. >> >> >> Ben > > Hello Ben, > > try > > Lang (type Token) > > in the export list. > > Best wishes, > Wolfgang That exports just the name of the associated type from the type class, as far as I can see, and syntax like "Lang (type Token (..))" is not allowed. That would improperly mix the classes and instances, for one thing. But perhaps something similar ought to be permited for associated type instances, as in my example. Something like: module Term (Term (Token Term (T))) is what I'd have in mind. In the meantime, I can step around the issue by making Token a top-level type familiy alongside the Lang class: data family Token term :: * with instance: newtype instance Token Term = T String alongside the instance Lang Term, allowing me to make the module exports I wanted in the usual style: module Term (Term (..), Token (T)) But this is a bit curious. The module might have contained more than one instance of Token, and this syntax mentions the name of the type family and a constructor for an instance of it, but not the type instance Token Term itself (although a constructor will always uniquely determine a type instance). This reminds me to mention that I've had the class and instance declarations in separate modules all along. Also, I'm using GHC 6.10.1. Ben From ben.horsfall at gmail.com Mon Dec 22 01:05:35 2008 From: ben.horsfall at gmail.com (Ben Horsfall) Date: Mon Dec 22 00:58:01 2008 Subject: Type families: module export of instance data constructor In-Reply-To: References: <200812220223.30638.g9ks157k@acme.softbase.org> Message-ID: I'm afraid I'd got into a muddle, and all of this can be ignored. In general, top-level and associated type instances get the same syntactic treatment in module exports, and the problem I had in the first place was due to another mistake. Ben On Mon, Dec 22, 2008 at 4:26 PM, Ben Horsfall wrote: > Hi Wolfgang, > > On Mon, Dec 22, 2008 at 12:23 PM, Wolfgang Jeltsch > wrote: >> Am Montag, 15. Dezember 2008 02:17 schrieb Ben Horsfall: >>> I have a type family >>> >>> class Lang term where >>> data Token term :: * >>> >>> with >>> >>> instance Lang Term where >>> newtype Token Term = T String >>> >>> I can't work out how to export the type constructor T from the module, >>> unless I make no explict exports from the module at all. >>> >>> >>> Ben >> >> Hello Ben, >> >> try >> >> Lang (type Token) >> >> in the export list. >> >> Best wishes, >> Wolfgang > > That exports just the name of the associated type from the type class, > as far as I can see, and syntax like "Lang (type Token (..))" is not > allowed. That would improperly mix the classes and instances, for one > thing. But perhaps something similar ought to be permited for > associated type instances, as in my example. Something like: > > module Term (Term (Token Term (T))) > > is what I'd have in mind. > > In the meantime, I can step around the issue by making Token a > top-level type familiy alongside the Lang class: > > data family Token term :: * > > with instance: > > newtype instance Token Term = T String > > alongside the instance Lang Term, allowing me to make the module > exports I wanted in the usual style: > > module Term (Term (..), Token (T)) > > But this is a bit curious. The module might have contained more than > one instance of Token, and this syntax mentions the name of the type > family and a constructor for an instance of it, but not the type > instance Token Term itself (although a constructor will always > uniquely determine a type instance). > > This reminds me to mention that I've had the class and instance > declarations in separate modules all along. Also, I'm using GHC > 6.10.1. > > > Ben > From marlowsd at gmail.com Mon Dec 22 05:35:35 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 22 05:28:03 2008 Subject: unique identifiers as a separate library In-Reply-To: <5ab17e790812211105u1a384d7bs9a284dbe10c2d616@mail.gmail.com> 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> Message-ID: <494F6D77.8070709@gmail.com> Iavor Diatchki wrote: > Hello, > I have made the two changes that Simon suggested and uploaded a new > version of the library. By the way, GHC seemed to work correctly > even without the extra boolean parameter, perhaps it treats > unsafePerformIO specially somehow? A somewhat related question: I > ended up using three calls to unsafeInterleaveIO which seems like a > bit much. Could I have done it in a different way somehow? This is > what I did: > > gen r = do v <- unsafeInterleaveIO (genSym r) > ls <- unsafeInterleaveIO (gen r) > rs <- unsafeInterleaveIO (gen r) > return (Node v ls rs) I'd probably do it like this: > gen r = unsafeDupableInterleaveIO $ do > v <- unsafeDupableInterleaveIO (genSym r) > ls <- gen r > rs <- gen r > return (Node v ls rs) which is close to the way GHC does it, except that we do indeed call genSym for every node. Calling genSym is cheaper than building the thunk for unsafeDupableInterleaveIO, although if there's an atomicModifyIORef involved that will probably tip the balance the other way. Cheers, Simon From marlowsd at gmail.com Mon Dec 22 05:38:02 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 22 05:30:29 2008 Subject: Possible Haddock bug affecting GHC docs In-Reply-To: <220e47b40812211647ta642ffck55c33b542956dc8@mail.gmail.com> References: <220e47b40812211644t34a7852nb00f8776f2569c8@mail.gmail.com> <220e47b40812211647ta642ffck55c33b542956dc8@mail.gmail.com> Message-ID: <494F6E0A.1090703@gmail.com> Krzysztof Skrz?tnicki wrote: > Hello everyone > > Please visit these to pages: > http://www.haskell.org/ghc/docs/6.8.3/html/libraries/haskell98/CTypes.html > -- ver 0.9 > http://www.haskell.org/ghc/docs/6.10.1/html/libraries/haskell98/CTypes.html > -- ver 2.3.0 > > They show documentation produced by Haddock. This is probably an instance of this bug http://hackage.haskell.org/trac/ghc/ticket/2746 Cheers, Simon From sebf at informatik.uni-kiel.de Mon Dec 22 06:27:40 2008 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Mon Dec 22 06:20:32 2008 Subject: unique identifiers as a separate library In-Reply-To: <494F6D77.8070709@gmail.com> 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> Message-ID: <97FA04AA-B0EF-48FC-A46A-1356FE460432@informatik.uni-kiel.de> Thanks for pointing me at Iavors package. We should not have two different libraries for the same purpose. value-supply-0.2 is about 6-7 times slower than GHC's UniqSupply, but porting Simons suggestion (to use unsafeDupableInterleaveIO) into Iavors code, GHC is "only" about twice as fast. Can we do better? I tried to use SPECIALIZE INLINE pragmas (at new[Enum|Num]Supply for Int) and/or strictness annotations (for the unique value) without significant benefit. I like Iavors more general interface (polymorphic values) and that only demanded identifiers are created. The latter saves half of the names when evaluating > map supplyValue . split I will replace my dependency to ghc with one to value-supply if unsafeDupableInterleaveIO is used instead of unsafeInterleaveIO where it is available. Cheers, Sebastian From iavor.diatchki at gmail.com Mon Dec 22 18:35:50 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Dec 22 18:28:09 2008 Subject: unique identifiers as a separate library In-Reply-To: <97FA04AA-B0EF-48FC-A46A-1356FE460432@informatik.uni-kiel.de> 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> Message-ID: <5ab17e790812221535i1bebc1dfnc4761b0ea59ce0b@mail.gmail.com> Hi, Thanks for the feedback! I have uploaded a new version of value supply with the following changes that should improve performance. - It uses unsafeDupableInterleaveIO to avoid double locking, - Do not create an intermediate list for Enum and Num supples - Specialize code for Int, as this is the most commonly used type for new name generation. These together should make things much faster but I have not had a chance to test that. I looked at the core and it seemed that the specializations were kicking in, so hopefully all is OK :) It would be great if you could let me know if things are still slower than the GHC version, and if so by how much. Also, I made a git-hub repo for the code, in case anyone is interested in contributing: http://github.com/yav/value-supply/tree/master -Iavor On Mon, Dec 22, 2008 at 3:27 AM, Sebastian Fischer wrote: > Thanks for pointing me at Iavors package. We should not have two different > libraries for the same purpose. > > value-supply-0.2 is about 6-7 times slower than GHC's UniqSupply, but > porting Simons suggestion (to use unsafeDupableInterleaveIO) into Iavors > code, GHC is "only" about twice as fast. > > Can we do better? I tried to use SPECIALIZE INLINE pragmas (at > new[Enum|Num]Supply for Int) and/or strictness annotations (for the unique > value) without significant benefit. > > I like Iavors more general interface (polymorphic values) and that only > demanded identifiers are created. The latter saves half of the names when > evaluating > >> map supplyValue . split > > I will replace my dependency to ghc with one to value-supply if > unsafeDupableInterleaveIO is used instead of unsafeInterleaveIO where it is > available. > > Cheers, > Sebastian > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From isaacdupree at charter.net Tue Dec 23 11:30:38 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Dec 23 11:23:09 2008 Subject: unique identifiers as a separate library In-Reply-To: <5ab17e790812221535i1bebc1dfnc4761b0ea59ce0b@mail.gmail.com> 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> Message-ID: <4951122E.9020305@charter.net> 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? I could see changing (unsafe[Dupable]InterleaveIO (genSym r)) to (genSym r), to halve the number of unsafeInterleaveIOs needed if we assume that most of the time a node is evaluated in order to get a value... but it's hard to see a good way to make *fewer* InterleaveIOs than there are genSym'd values. (possible, but hard, and really depends on the relative expenses/risks of locking, of computing the next number, and of using up the "address space" of all possible Ints for example). Maybe the outer InterleaveIO could "strictly" make a few levels of Nodes (with lazy genSym'd values this time) before "interleaving" again, to reduce the amount of interleaving from the non-semantics-changing side. -Isaac From iavor.diatchki at gmail.com Tue Dec 23 16:56:50 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Dec 23 16:49:08 2008 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: <5ab17e790812231356w4ce0ee68n70f863d6f4d33b9@mail.gmail.com> Hi, Sigh. I think that Isaac is quite right. Even though I think that it would be quite rare for multiple threads to share the same name supply in practise, I would really rather have safe code and not have to think about it. So... I have reverted to the non-dupable versions by default. I also added an "unsafeNewIntSupply" that uses that dupable primitives, for those who like living on the edge :) Thanks to Sebastian for the bench marking program! The performance numbers for the current version on hackage (0.4) are as follows: With safe primitives value-supply is about 7 times slower, with the unsafe ones it is about 2 times slower (a bit less actually). Even though this seems like a big difference, the actual time it takes to generate names is very small: I have to generate about 10 million names to get reliable measurements, so I am not sure if the difference matters in practise. If anyone has further ideas, please chime in. -Iavor On Tue, Dec 23, 2008 at 8:30 AM, 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? > > I could see changing (unsafe[Dupable]InterleaveIO (genSym r)) to (genSym r), > to halve the number of unsafeInterleaveIOs needed if we assume that most of > the time a node is evaluated in order to get a value... but it's hard to see > a good way to make *fewer* InterleaveIOs than there are genSym'd values. > (possible, but hard, and really depends on the relative expenses/risks of > locking, of computing the next number, and of using up the "address space" > of all possible Ints for example). Maybe the outer InterleaveIO could > "strictly" make a few levels of Nodes (with lazy genSym'd values this time) > before "interleaving" again, to reduce the amount of interleaving from the > non-semantics-changing side. > > -Isaac > From isaacdupree at charter.net Tue Dec 23 18:22:46 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Dec 23 18:15:13 2008 Subject: unique identifiers as a separate library In-Reply-To: <5ab17e790812231356w4ce0ee68n70f863d6f4d33b9@mail.gmail.com> 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> <5ab17e790812231356w4ce0ee68n70f863d6f4d33b9@mail.gmail.com> Message-ID: <495172C6.1050902@charter.net> Hi again Iavor, A couple performance ideas if you want to test them: unsafeInterleaveIO is cheap until you need to evaluate its result. So how about this, I think it makes there be 1/3 as many "structural" unsafeInterleaveIO's, so if it took "2" amount of time on unsafeInterleaveIO:ing before, it should take "1.33" time on it after this: and just a bit more time/memory to construct Nodes that might not be used. gen r = unsafeInterleaveIO $ do v <- unsafeInterleaveIO (genSym r) n1 <- gen r; n2 <- gen r; n3 <- gen r; n4 <- gen r return (Node v1 (Node v2 n1 n2) (Node v3 n3 n4)) I also feel tempted to apply the static-argument-transformation manually, where gen r = gen' where gen' = unsafeInterleaveIO $ do v <- unsafeInterleaveIO (genSym r) n1 <- gen'; n2 <- gen' --etc. return (Node ...) or similar which I guess is safe because this is only unsafeInterleaveIO, not unsafePerformIO? Dunno if it'd be speed-beneficial though. version 0.4: > genericNewSupply :: b -> (IORef b -> IO a) -> IO (Supply a) > genericNewSupply start genSym = gen =<< newIORef start > where gen r = unsafeInterleaveIO > $ do ls <- gen r > rs <- gen r > return (Node (unsafePerformIO (genSym r)) ls rs) Why unsafePerformIO, was it faster?(i'd guess slower actually, as unsafePerformIO is NOINLINE..) It's considerably less safe than unsafeInterleaveIO! For example, do the static-argument-transformation above, then float out the unsafePerformIO because it's the same expression each time through gen', and suddenly the all the "unique" values are all the same! we can make this value-supply very good ultimately :-) also, I might call "unsafeNewIntSupply" something more specific, like "unthreadsafeNew...", or the more obscure but conventional "dupable" description-word. Did it help specializing that to Int, i.e. why not "unsafeGenericNewSupply"? because I can imagine a simple data that's not an Int, where you'd still want to avoid the thread-safety overhead. Also, your implementation of it could be more efficient: it doesn't need to do locking, so I suggest modifyIORef rather than atomicModifyIORef (Actually you'll have to use readIORef >>= writeIORef >> return, instead, because modifyIORef has a different type than atomicModifyIORef). Possible refactor: All the functions ***GenSym r = atomicModifyIORef r (some expression that doesn't mention r); doing the "[atomic]ModifyIORef r" could be the caller's responsibility instead, and e.g. listGenSym (a:as) = (as,a). in fact, for lists (as you get a incomplete-pattern-match warning there, but you know the list is always infinite, because you made it with "iterate"), you could instead use an infinite-list type, Data.Stream from package "Stream"[*]; as Stream is not a sum type (it only has one possible constructor: Cons), it might even be a bit more efficient! [*] http://hackage.haskell.org/packages/archive/Stream/0.2.6/doc/html/Data-Stream.html thanks for your effort! and especially for measuring the performance timing! -Isaac From iavor.diatchki at gmail.com Tue Dec 23 20:08:29 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Dec 23 20:00:46 2008 Subject: unique identifiers as a separate library In-Reply-To: <495172C6.1050902@charter.net> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@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> <5ab17e790812231356w4ce0ee68n70f863d6f4d33b9@mail.gmail.com> <495172C6.1050902@charter.net> Message-ID: <5ab17e790812231708v43bfcb3do2950285445f11ee3@mail.gmail.com> Hello, Thanks for your comments! On Tue, Dec 23, 2008 at 3:22 PM, Isaac Dupree wrote: > unsafeInterleaveIO is cheap until you need to evaluate its result. So how > about this, I think it makes there be 1/3 as many "structural" > unsafeInterleaveIO's, so if it took "2" amount of time on > unsafeInterleaveIO:ing before, it should take "1.33" time on it after this: > and just a bit more time/memory to construct Nodes that might not be used. > > gen r = unsafeInterleaveIO $ do > v <- unsafeInterleaveIO (genSym r) > n1 <- gen r; n2 <- gen r; n3 <- gen r; n4 <- gen r > return (Node v1 (Node v2 n1 n2) (Node v3 n3 n4)) I played around with that but, for some reason, it did not seem to speed things up, at least for the benchmark that I run. Will have to experiment some more. > version 0.4: >> >> genericNewSupply :: b -> (IORef b -> IO a) -> IO (Supply a) >> genericNewSupply start genSym = gen =<< newIORef start >> where gen r = unsafeInterleaveIO >> $ do ls <- gen r >> rs <- gen r >> return (Node (unsafePerformIO (genSym r)) ls rs) > > Why unsafePerformIO, was it faster?(i'd guess slower actually, as > unsafePerformIO is NOINLINE..) I just tested to see what would happen and forgot to change it back (now I have switched it back). There does not seem to be a significant difference between the two, speed-wise. > Did it help specializing that to Int, i.e. why not > "unsafeGenericNewSupply"? because I can imagine a simple data that's not an > Int, where you'd still want to avoid the thread-safety overhead. Nope, it was just the simplest thing to do. I can add more general "unsafe" versions. > Also, your > implementation of it could be more efficient: it doesn't need to do locking, > so I suggest modifyIORef rather than atomicModifyIORef (Actually you'll have > to use readIORef >>= writeIORef >> return, instead, because modifyIORef has > a different type than atomicModifyIORef). I don't think that that's quite right. I was thinking that it should be OK to use different supplies that share a reference in different threads. So, for example, split the supply and pass each version to a new thread. This should be OK with the dupable primitives because the thunks would be evaluated in different threads. However, we still need the synchronize access to the reference, or we'll get incorrect values. Possible refactor: All the > functions ***GenSym r = atomicModifyIORef r (some expression that doesn't > mention r); doing the "[atomic]ModifyIORef r" could be the caller's > responsibility instead, and e.g. listGenSym (a:as) = (as,a). This is a good idea, the atomicUpdates are duplicated everywhere. I did this, and for some reason it seems to have made things a little slower, but I like the code better, so I think that I will keep it. I am surprised that it affected the speed of execution, perhaps it is just my benchmark that is being unreliable. > in fact, for lists (as you get a incomplete-pattern-match warning there, but > you know the list is always infinite, because you made it with "iterate"), > you could instead use an infinite-list type, Data.Stream from package > "Stream"[*]; as Stream is not a sum type (it only has one possible > constructor: Cons), it might even be a bit more efficient! You are right but the benefit is small enough that I don't think it warrants a dependency on another package. bye, -Iavor From daniil.elovkov at googlemail.com Wed Dec 24 10:44:32 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Wed Dec 24 10:36:47 2008 Subject: FFI imported function names Message-ID: 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 From isaacdupree at charter.net Wed Dec 24 10:46:56 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Dec 24 10:39:28 2008 Subject: unique identifiers as a separate library In-Reply-To: <5ab17e790812231708v43bfcb3do2950285445f11ee3@mail.gmail.com> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@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> <5ab17e790812231356w4ce0ee68n70f863d6f4d33b9@mail.gmail.com> <495172C6.1050902@charter.net> <5ab17e790812231708v43bfcb3do2950285445f11ee3@mail.gmail.com> Message-ID: <49525970.2090609@charter.net> Iavor Diatchki wrote: >> Also, your >> implementation of it could be more efficient: it doesn't need to do locking, >> so I suggest modifyIORef rather than atomicModifyIORef (Actually you'll have >> to use readIORef >>= writeIORef >> return, instead, because modifyIORef has >> a different type than atomicModifyIORef). > > I don't think that that's quite right. I was thinking that it should > be OK to use different supplies that share a reference in different > threads. So, for example, split the supply and pass each version to a > new thread. This should be OK with the dupable primitives because the > thunks would be evaluated in different threads. However, we still > need the synchronize access to the reference, or we'll get incorrect > values. That's true (if you're careful enough about which thread is evaluating the splitting -- the existing split* functions are actually *not* strict enough for this, and they probably shouldn't be either, so an additional warning that the user may have to add some `seq`s or `evaluate`s might be needed). Anyway, if atomicModifyIORef isn't that big of an overhead, then no problem :-) >> in fact, for lists (as you get a incomplete-pattern-match warning there, but >> you know the list is always infinite, because you made it with "iterate"), >> you could instead use an infinite-list type, Data.Stream from package >> "Stream"[*]; as Stream is not a sum type (it only has one possible >> constructor: Cons), it might even be a bit more efficient! > > You are right but the benefit is small enough that I don't think it > warrants a dependency on another package. I'm going to try to argue to convince you that it's entirely appropriate to use Data.Stream :-) From my somewhat mathematical point of view, that is. 1. Data.Stream is a small module that implements a very well-known, practically standard (though under-used), and simple data type. All you really need from it is import Data.Stream(Stream(Cons)), plus (iterate, streamToList) if you're keeping your current interface. It's nothing you should be afraid to depend on, if you're using its concept (which you are). It's much smaller than the 'containers' package, which similarly you don't use but if you needed a Map or something you obviously should. 2. The more compelling argument, that it took me a good night's sleep to think of: Supply is an infinite binary tree. Stream is an infinite unary tree (er, more commonly called infinite "list"). They're both codata. They're both comonads. (although they don't go so far as to depend on category-extras to provide an instance.) The primary function/purpose of Supply is an *efficient* way to turn a Stream into a Supply. I daresay it would, even, be more fundamental to provide interface newSupply :: Stream a -> IO (Supply a) than newSupply :: a -> (a -> a) -> IO (Supply a) (although it might be worth keeping both interfaces? mainly for compatibility, since one's just a Data.Stream.iterate away from the other and your haddocks could say so) In fact, it's terribly annoying to turn a (Stream a) into a (a, a -> a) -- in fact I don't think it can be done in general (you can turn it into a (b, b -> (a, b)) though a-la unfold, with b = Stream a) -- so you should definitely provide the above (Stream a -> IO (Supply a)) interface. (Although if you're cowardly enough about the extra dependency, I guess you could make it the riskier ([a] -> IO (Supply a)), risk being if the user provides a finite list... Sorry for conditionally insulting you; it seems a horribly underhanded thing for me to do :-) Likewise, it would be nice for split :: Supply a -> Stream (Supply a) ...and then you would not even depend on Data.List anymore! (I don't happen to think the arguments that Data.List is better than Stream for definitely-infinite lists are very convincing; except possibly that List will be more up-to-date with respect to stream-fusion optimizations, and even then, value-supply doesn't actually rely on any of those optimizations; it actually does keep around the Stream (or List), or in the case of Num/Enum, it doesn't use one in the first place.) On the other hand, I still want the Stream-based interfaces, but my initial argument isn't even that necessary: consider implementing the current signature: newSupply :: a -> (a -> a) -> IO (Supply a) currently by: newSupply x f = genericNewSupply (iterate f x) listGenSym but we don't need to use a list at all, it could be like: newSupply x f = genericNewSupply x (\a -> (f a, a)) (with atomicallyModifyIORef added as appropriate depending on your refactorings) P.S. more code cleanup, if you didn't notice it: 0.4: > -- XXX: Is the atomic necessary? > import Data.IORef(IORef,newIORef,atomicModifyIORef) yes the atomic is necessary, so you can update the comment to say why? (because multiple threads might be reading from a Supply-structure created from the same newSupply run, and we don't want memory corruption etc.) > import System.IO.Unsafe(unsafePerformIO,unsafeInterleaveIO) > > #if __GLASGOW_HASKELL__ >= 608 > import GHC.IOBase(unsafeDupableInterleaveIO,unsafeDupablePerformIO) > #else > ... > unsafeDupablePerformIO :: IO a -> a > unsafeDupablePerformIO = unsafePerformIO various "PerformIO" variants to delete (I'm absurdly pleased that we implemented this without needing any) -Isaac From daniil.elovkov at googlemail.com Wed Dec 24 11:19:03 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Wed Dec 24 11:11:17 2008 Subject: FFI imported function names In-Reply-To: References: Message-ID: 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 daniil.elovkov at googlemail.com Wed Dec 24 14:01:26 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Wed Dec 24 13:53:40 2008 Subject: building HSQL MySQL on windows (Was: FFI imported function names) Message-ID: 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. 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 > -- Daniil Elovkov From iavor.diatchki at gmail.com Wed Dec 24 15:15:55 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Dec 24 15:08:10 2008 Subject: unique identifiers as a separate library In-Reply-To: <49525970.2090609@charter.net> References: <96D61B18-B5EC-4C40-92B8-3F7E4DA0F043@informatik.uni-kiel.de> <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> <5ab17e790812231356w4ce0ee68n70f863d6f4d33b9@mail.gmail.com> <495172C6.1050902@charter.net> <5ab17e790812231708v43bfcb3do2950285445f11ee3@mail.gmail.com> <49525970.2090609@charter.net> Message-ID: <5ab17e790812241215h262d3cbbl794b853d9b2dd1f@mail.gmail.com> Hi, Thanks for the feedback! Suggestions implemented in your daily value-supply release :) Happy Holidays! -Iavor On Wed, Dec 24, 2008 at 7:46 AM, Isaac Dupree wrote: > Iavor Diatchki wrote: >>> >>> Also, your >>> implementation of it could be more efficient: it doesn't need to do >>> locking, >>> so I suggest modifyIORef rather than atomicModifyIORef (Actually you'll >>> have >>> to use readIORef >>= writeIORef >> return, instead, because modifyIORef >>> has >>> a different type than atomicModifyIORef). >> >> I don't think that that's quite right. I was thinking that it should >> be OK to use different supplies that share a reference in different >> threads. So, for example, split the supply and pass each version to a >> new thread. This should be OK with the dupable primitives because the >> thunks would be evaluated in different threads. However, we still >> need the synchronize access to the reference, or we'll get incorrect >> values. > > That's true (if you're careful enough about which thread is evaluating the > splitting -- the existing split* functions are actually *not* strict enough > for this, and they probably shouldn't be either, so an additional warning > that the user may have to add some `seq`s or `evaluate`s might be needed). > Anyway, if atomicModifyIORef isn't that big of an overhead, then no problem > :-) > >>> in fact, for lists (as you get a incomplete-pattern-match warning there, >>> but >>> you know the list is always infinite, because you made it with >>> "iterate"), >>> you could instead use an infinite-list type, Data.Stream from package >>> "Stream"[*]; as Stream is not a sum type (it only has one possible >>> constructor: Cons), it might even be a bit more efficient! >> >> You are right but the benefit is small enough that I don't think it >> warrants a dependency on another package. > > I'm going to try to argue to convince you that it's entirely appropriate to > use Data.Stream :-) > > From my somewhat mathematical point of view, that is. > > 1. Data.Stream is a small module that implements a very well-known, > practically standard (though under-used), and simple data type. All you > really need from it is import Data.Stream(Stream(Cons)), plus (iterate, > streamToList) if you're keeping your current interface. It's nothing you > should be afraid to depend on, if you're using its concept (which you are). > It's much smaller than the 'containers' package, which similarly you don't > use but if you needed a Map or something you obviously should. > > 2. The more compelling argument, that it took me a good night's sleep to > think of: > > Supply is an infinite binary tree. Stream is an infinite unary tree (er, > more commonly called infinite "list"). They're both codata. They're both > comonads. (although they don't go so far as to depend on category-extras to > provide an instance.) The primary function/purpose of Supply is an > *efficient* way to turn a Stream into a Supply. I daresay it would, even, > be more fundamental to provide interface > newSupply :: Stream a -> IO (Supply a) > than > newSupply :: a -> (a -> a) -> IO (Supply a) > (although it might be worth keeping both interfaces? mainly for > compatibility, since one's just a Data.Stream.iterate away from the other > and your haddocks could say so) > In fact, it's terribly annoying to turn a (Stream a) into a (a, a -> a) -- > in fact I don't think it can be done in general (you can turn it into a (b, > b -> (a, b)) though a-la unfold, with b = Stream a) -- so you should > definitely provide the above (Stream a -> IO (Supply a)) interface. > (Although if you're cowardly enough about the extra dependency, I guess you > could make it the riskier ([a] -> IO (Supply a)), risk being if the user > provides a finite list... Sorry for conditionally insulting you; it seems a > horribly underhanded thing for me to do :-) > > Likewise, it would be nice for > split :: Supply a -> Stream (Supply a) > ...and then you would not even depend on Data.List anymore! > > (I don't happen to think the arguments that Data.List is better than Stream > for definitely-infinite lists are very convincing; except possibly that List > will be more up-to-date with respect to stream-fusion optimizations, and > even then, value-supply doesn't actually rely on any of those optimizations; > it actually does keep around the Stream (or List), or in the case of > Num/Enum, it doesn't use one in the first place.) > > On the other hand, I still want the Stream-based interfaces, but my initial > argument isn't even that necessary: consider implementing the current > signature: > newSupply :: a -> (a -> a) -> IO (Supply a) > currently by: > newSupply x f = genericNewSupply (iterate f x) listGenSym > but we don't need to use a list at all, it could be like: > newSupply x f = genericNewSupply x (\a -> (f a, a)) > (with atomicallyModifyIORef added as appropriate depending on your > refactorings) > > > P.S. more code cleanup, if you didn't notice it: > > 0.4: >> >> -- XXX: Is the atomic necessary? >> import Data.IORef(IORef,newIORef,atomicModifyIORef) > > yes the atomic is necessary, so you can update the comment to say why? > (because multiple threads might be reading from a Supply-structure created > from the same newSupply run, and we don't want memory corruption etc.) > >> import System.IO.Unsafe(unsafePerformIO,unsafeInterleaveIO) >> >> #if __GLASGOW_HASKELL__ >= 608 >> import GHC.IOBase(unsafeDupableInterleaveIO,unsafeDupablePerformIO) >> #else >> ... >> unsafeDupablePerformIO :: IO a -> a >> unsafeDupablePerformIO = unsafePerformIO > > various "PerformIO" variants to delete (I'm absurdly pleased that we > implemented this without needing any) > > -Isaac > From conal at conal.net Fri Dec 26 01:15:12 2008 From: conal at conal.net (Conal Elliott) Date: Fri Dec 26 01:07:23 2008 Subject: black hole detection and concurrency Message-ID: I'm looking for information about black hole detection with ghc. I'm getting "<>" where I don't think there is an actual black hole. I get this message sometimes with the unamb package, which is implemented with unsafePerformIO, concurrency, and killThread, as described in http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice/and http://conal.net/blog/posts/smarter-termination-for-thread-racing/ . Suppose I have a definition 'v = unsafePerformIO ...', and v is used more than once. Evaluation (to whnf) of v is begun and the evaluation thread gets killed before evaluation is complete. Then the second use begins. Will the second evaluation be (incorrectly) flagged as a black hole? I haven't found a simple, reproducible example of incorrect black-hole reporting. My current examples are tied up with the Reactive library. I do have another strange symptom, which is "thread killed" message. I wonder if it's related to the <> message. Code below. Thanks, - Conal import Prelude hiding (catch) import System.IO.Unsafe import Control.Concurrent import Control.Exception -- *** Exception: thread killed main :: IO () main = print $ f (f True) where f v = (v `unamb` True) `seq` v -- | Unambiguous choice operator. Equivalent to the ambiguous choice -- operator, but with arguments restricted to be equal where not bottom, -- so that the choice doesn't matter. See also 'amb'. unamb :: a -> a -> a unamb a b = unsafePerformIO (evaluate a `race` evaluate b) -- | Race two actions against each other in separate threads, and pick -- whichever finishes first. See also 'amb'. race :: IO a -> IO a -> IO a race a b = do v <- newEmptyMVar let t x = x >>= putMVar v withThread (t a) $ withThread (t b) $ takeMVar v where withThread u v = bracket (forkIO u) killThread (const v) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081225/5cf65e19/attachment.htm From s.clover at gmail.com Fri Dec 26 21:09:36 2008 From: s.clover at gmail.com (Sterling Clover) Date: Fri Dec 26 21:01:45 2008 Subject: black hole detection and concurrency In-Reply-To: References: Message-ID: I have a good theory on the latter symptom (the "thread killed" message). Sticking in some traces, as in my appended code, helped me to see what's going on. It seems to be exactly what you describe -- the variable v is permanently bound to the exception it "evaluates" to. Since the right hand True portion of the unamb evaluates more quickly, the spawned threads are killed and the left hand (the v) "evaluates" to "thread killed". This remains the value of its thunk when you access it later. This problem seems sort of innate to a pure unamb utilizing unsafePerformIO and asynchronous exceptions. A clever use of `par` might conceivably help, given that if the par spark fails, the thunk can still be evaluated? Might be a dead end. Here's the code: go = f "f" (f "" True) where f s v = (unamb (s++"f") (s++"g") v True) `seq` v --unamb :: String -> String -> a -> a -> a unamb s s' a b = unsafePerformIO (race s s' (evaluate a) (evaluate b)) --race :: String -> String -> IO a -> IO a -> IO a race s s' a b = do v <- newEmptyMVar let t x = x >>= putMVar v withThread s (t a) $ withThread s' (t b) $ takeMVar v where withThread s u v = bracket (forkIO u) (killNote s) (const $ putStrLn ("in: " ++ s) >> v >>= \x -> putStrLn ("out: " ++ show x ++ " "++ s) >> return x) killNote s tid = throwTo tid (ErrorCall s) And a GHCi session: *Un> go in: ff in: fg in: f in: g out: True fg out: True ff : ff *** Exception: ff Cheers, Sterl. On Dec 26, 2008, at 1:15 AM, Conal Elliott wrote: > I'm looking for information about black hole detection with ghc. > I'm getting "<>" where I don't think there is an actual black > hole. I get this message sometimes with the unamb package, which > is implemented with unsafePerformIO, concurrency, and killThread, > as described in http://conal.net/blog/posts/functional-concurrency- > with-unambiguous-choice/ and http://conal.net/blog/posts/smarter- > termination-for-thread-racing/ . > > Suppose I have a definition 'v = unsafePerformIO ...', and v is > used more than once. Evaluation (to whnf) of v is begun and the > evaluation thread gets killed before evaluation is complete. Then > the second use begins. Will the second evaluation be (incorrectly) > flagged as a black hole? > > I haven't found a simple, reproducible example of incorrect black- > hole reporting. My current examples are tied up with the Reactive > library. I do have another strange symptom, which is "thread > killed" message. I wonder if it's related to the <> > message. Code below. > > Thanks, - Conal > > > import Prelude hiding (catch) > import System.IO.Unsafe > import Control.Concurrent > import Control.Exception > > > -- *** Exception: thread killed > main :: IO () > main = print $ f (f True) where f v = (v `unamb` True) `seq` v > > -- | Unambiguous choice operator. Equivalent to the ambiguous choice > -- operator, but with arguments restricted to be equal where not > bottom, > -- so that the choice doesn't matter. See also 'amb'. > unamb :: a -> a -> a > unamb a b = unsafePerformIO (evaluate a `race` evaluate b) > > -- | Race two actions against each other in separate threads, and pick > -- whichever finishes first. See also 'amb'. > race :: IO a -> IO a -> IO a > race a b = do > v <- newEmptyMVar > let t x = x >>= putMVar v > withThread (t a) $ withThread (t b) $ takeMVar v > where > withThread u v = bracket (forkIO u) killThread (const v) > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From conal at conal.net Sat Dec 27 02:13:31 2008 From: conal at conal.net (Conal Elliott) Date: Sat Dec 27 02:05:38 2008 Subject: Fwd: black hole detection and concurrency In-Reply-To: References: Message-ID: Thanks for the probing, Sterl. I'm afraid I'm stuck here. Without the more effective thread killing (in unamb), Reactive seems to be drowning in uselessly running threads. With "improved" thread killing, I get many of these false black holes, instead of computed values. I don't know whether this problem is solvable on top of ghc's current RTS, as you suggest (clever `par` use), but I don't know. I'm out of my depth here and could sure use help. Thanks, - Conal On Fri, Dec 26, 2008 at 6:09 PM, Sterling Clover wrote: > I have a good theory on the latter symptom (the "thread killed" message). > Sticking in some traces, as in my appended code, helped me to see what's > going on. It seems to be exactly what you describe -- the variable v is > permanently bound to the exception it "evaluates" to. Since the right hand > True portion of the unamb evaluates more quickly, the spawned threads are > killed and the left hand (the v) "evaluates" to "thread killed". This > remains the value of its thunk when you access it later. This problem seems > sort of innate to a pure unamb utilizing unsafePerformIO and asynchronous > exceptions. A clever use of `par` might conceivably help, given that if the > par spark fails, the thunk can still be evaluated? Might be a dead end. > > Here's the code: > > go = f "f" (f "" True) where f s v = (unamb (s++"f") (s++"g") v True) `seq` > v > > --unamb :: String -> String -> a -> a -> a > unamb s s' a b = unsafePerformIO (race s s' (evaluate a) (evaluate b)) > > --race :: String -> String -> IO a -> IO a -> IO a > race s s' a b = do > v <- newEmptyMVar > let t x = x >>= putMVar v > withThread s (t a) $ withThread s' (t b) $ takeMVar v > where > withThread s u v = bracket (forkIO u) (killNote s) (const $ putStrLn > ("in: " ++ s) >> v >>= \x -> putStrLn ("out: " ++ show x ++ " "++ s) >> > return x) > > killNote s tid = throwTo tid (ErrorCall s) > > And a GHCi session: > > *Un> go > in: ff > in: fg > in: f > in: g > out: True fg > out: True ff > : ff > *** Exception: ff > > Cheers, > Sterl. > > > On Dec 26, 2008, at 1:15 AM, Conal Elliott wrote: > > I'm looking for information about black hole detection with ghc. I'm >> getting "<>" where I don't think there is an actual black hole. I get >> this message sometimes with the unamb package, which is implemented with >> unsafePerformIO, concurrency, and killThread, as described in >> http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice/ >> and http://conal.net/blog/posts/smarter-termination-for-thread-racing/ . >> >> Suppose I have a definition 'v = unsafePerformIO ...', and v is used more >> than once. Evaluation (to whnf) of v is begun and the evaluation thread >> gets killed before evaluation is complete. Then the second use begins. >> Will the second evaluation be (incorrectly) flagged as a black hole? >> >> I haven't found a simple, reproducible example of incorrect black-hole >> reporting. My current examples are tied up with the Reactive library. I do >> have another strange symptom, which is "thread killed" message. I wonder if >> it's related to the <> message. Code below. >> >> Thanks, - Conal >> >> >> import Prelude hiding (catch) >> import System.IO.Unsafe >> import Control.Concurrent >> import Control.Exception >> >> >> -- *** Exception: thread killed >> main :: IO () >> main = print $ f (f True) where f v = (v `unamb` True) `seq` v >> >> -- | Unambiguous choice operator. Equivalent to the ambiguous choice >> -- operator, but with arguments restricted to be equal where not bottom, >> -- so that the choice doesn't matter. See also 'amb'. >> unamb :: a -> a -> a >> unamb a b = unsafePerformIO (evaluate a `race` evaluate b) >> >> -- | Race two actions against each other in separate threads, and pick >> -- whichever finishes first. See also 'amb'. >> race :: IO a -> IO a -> IO a >> race a b = do >> v <- newEmptyMVar >> let t x = x >>= putMVar v >> withThread (t a) $ withThread (t b) $ takeMVar v >> where >> withThread u v = bracket (forkIO u) killThread (const v) >> >> _______________________________________________ >> 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/20081226/f1d15abf/attachment.htm From bertram.felgenhauer at googlemail.com Sat Dec 27 09:02:46 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Dec 27 08:54:57 2008 Subject: black hole detection and concurrency In-Reply-To: References: Message-ID: <20081227140245.GA4206@zombie.inf.tu-dresden.de> Sterling Clover wrote: > I have a good theory on the latter symptom (the "thread killed" message). > Sticking in some traces, as in my appended code, helped me to see what's > going on. It seems to be exactly what you describe -- the variable v is > permanently bound to the exception it "evaluates" to. Since the right hand > True portion of the unamb evaluates more quickly, the spawned threads are > killed and the left hand (the v) "evaluates" to "thread killed". This > remains the value of its thunk when you access it later. Thank you for that analysis. It's intriguing. Here's a cut down example: > import Control.Concurrent > import Control.Concurrent.MVar > import Control.Exception > import System.IO.Unsafe > > main :: IO () > main = do > v <- newEmptyMVar > let y = print "a" >> takeMVar v >> print "b" > x = unsafePerformIO $ y `finally` return () > tid <- forkIO $ evaluate x > yield > print "killing" > killThread tid > putMVar v () > yield > print "finally" > print x Output: "a" "killing" "finally" test: thread killed Interestingly, the program works without the `finally` part, suspending the IO action y in the middle: Output without `finally`: "a" "killing" "finally" "b" () The `unamb` operator needs both behaviours: it has to kill its worker threads if it turns out that its value is not yet needed, but it also has to be suspended to allow it to be restarted later. *after some digging in the ghc sources* It may be possible to do the restarting manually: > let y = catchJust threadKilled > (print "a" >> takeMVar v >> print "b") > (\_ -> myThreadId >>= killThread >> y) > threadKilled ThreadKilled = Just () > threadKilled _ = Nothing (for ghc 6.8 use threadKilled (AsyncException ThreadKilled) = Just ()) Output: "a" "killing" "finally" "a" "b" () The key part here is 'myThreadId >>= killThread' which throws an asynchronous exception to the thread itself, causing the update frames to be saved on the heap. Note that 'myThreadId >>= killThread' is not equivalent to 'throw ThreadKilled'; it is a synchronous exception and replaces thunks pointed to by the update frames by another call to the raise primitive - the result being that the exception gets rethrown whenever such a thunk is evaluated. This happens with 'finally' and 'bracket': they use 'throw' for re-throwing the exception. See rts/RaiseAsync.c (raiseAsync() in particular) for the gory details for the first case, and rts/Schedule.c, raiseExceptionHelper() for the second case. In the above code, there is a small window between catching the ThreadKilled exception and throwing it again though, where other exceptions may creep in. The only way I see of fixing that is to use 'block' and 'unblock' directly. Here is an attempt at the 'race' function, using block, catch and unblock. I'm not sure that it's correct. But it seems to work with Sterling's example at least, which triggers a restart. > race :: IO a -> IO a -> IO a > race a b = block $ do > v <- newEmptyMVar > let t x = x >>= putMVar v > ta <- forkIO (t a) > tb <- forkIO (t b) > let cleanup = killThread ta >> killThread tb > unblock (do r <- takeMVar v; cleanup; return r) > `catch` \e -> case e of > ThreadKilled -> do > cleanup > myThreadId >>= killThread > unblock (race a b) > e -> throwIO e Bertram From s.clover at gmail.com Sat Dec 27 12:40:00 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sat Dec 27 12:32:03 2008 Subject: black hole detection and concurrency In-Reply-To: <20081227140245.GA4206@zombie.inf.tu-dresden.de> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> Message-ID: On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote: > > The key part here is 'myThreadId >>= killThread' which throws an > asynchronous exception to the thread itself, causing the update > frames to be saved on the heap. > > Note that 'myThreadId >>= killThread' is not equivalent to > 'throw ThreadKilled'; it is a synchronous exception and replaces > thunks > pointed to by the update frames by another call to the raise > primitive - > the result being that the exception gets rethrown whenever such a > thunk > is evaluated. This happens with 'finally' and 'bracket': they use > 'throw' for re-throwing the exception. > > See rts/RaiseAsync.c (raiseAsync() in particular) for the gory details > for the first case, and rts/Schedule.c, raiseExceptionHelper() for the > second case. > > In the above code, there is a small window between catching the > ThreadKilled exception and throwing it again though, where other > exceptions may creep in. The only way I see of fixing that is to use > 'block' and 'unblock' directly. > That certainly seems to do the trick for the simple example at least. One way to reason about it better would be, instead of folding everything into the race function, to simply modify ghc's bracket function to give us the behavior we'd prefer (speaking of which, I recall there's something in the works for 6.12 or so to improve rethrowing of asynchronous exceptions?) brackAsync before after thing = block (do a <- before r <- catch (unblock (thing a)) (\_ -> after a >> myThreadId >>= killThread >> brackAsync before after thing ) after a return r ) where threadKilled ThreadKilled = Just () threadKilled _ = Nothing This brackAsync just drops in to the previous code where bracket was and appears to perform correctly. Further, if we place a trace after the killThread, we se it gets executed once when the example is read (i.e. a resumption) but it does not get executed if the (`seq` v) is removed from the example So this gives me some hope that this is actually doing what we'd like. I don't doubt it may have further kinks however. Cheers, Sterl. From bertram.felgenhauer at googlemail.com Sat Dec 27 19:26:12 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Dec 27 19:18:14 2008 Subject: black hole detection and concurrency In-Reply-To: <20081227140245.GA4206@zombie.inf.tu-dresden.de> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> Message-ID: <30e962d20812271626k730527e1l3db206cf795c6aef@mail.gmail.com> Hi, Bertram Felgenhauer wrote: [snip] > race :: IO a -> IO a -> IO a Two quick notes on that function: > race a b = block $ do > v <- newEmptyMVar > let t x = x >>= putMVar v Should be let t x = unblock (x >>= putMVar v) Otherwise the computation 'x' not be interruptible unless it explicitely uses 'unblock' or a blocking operation like reading an MVar. > ta <- forkIO (t a) > tb <- forkIO (t b) > let cleanup = killThread ta >> killThread tb > unblock (do r <- takeMVar v; cleanup; return r) > `catch` \e -> case e of > ThreadKilled -> do > cleanup > myThreadId >>= killThread > unblock (race a b) On the other hand, this 'unblock' should have no effect: If we ever return here, it'll be in a different thread, or after another exception handler has enabled exceptions for the current thread. > e -> throwIO e Oops. This should call cleanup as well. (I guess it should be done before the 'case' expression) e -> cleanup >> throwIO e Bertram From bertram.felgenhauer at googlemail.com Sat Dec 27 21:03:05 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Dec 27 20:55:15 2008 Subject: black hole detection and concurrency In-Reply-To: References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> Message-ID: <20081228020305.GA4218@zombie.inf.tu-dresden.de> Sterling Clover wrote: > On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote: >> In the above code, there is a small window between catching the >> ThreadKilled exception and throwing it again though, where other >> exceptions may creep in. The only way I see of fixing that is to use >> 'block' and 'unblock' directly. > > That certainly seems to do the trick for the simple example at least. One > way to reason about it better would be, instead of folding everything into > the race function, to simply modify ghc's bracket function to give us the > behavior we'd prefer (speaking of which, I recall there's something in the > works for 6.12 or so to improve rethrowing of asynchronous exceptions?) > > brackAsync before after thing = > block (do > a <- before > r <- catch > (unblock (thing a)) > (\_ -> after a >> myThreadId >>= killThread >> > brackAsync before after thing ) > after a > return r > ) > where threadKilled ThreadKilled = Just () > threadKilled _ = Nothing This code turns any exception into ThreadKilled further down the stack. (\e -> do after a myThreadId >>= flip throwTo (e :: SomeException) ... might do the trick. My assumption was that anything but 'ThreadKilled' would be a real error. This isn't really true, I guess - thanks to throwTo, any exception could be asynchronous. If an exception is thrown, 'after a' is run again after the computation has resumed. That's why I did the cleanup within the 'catch'. But there's no reason why you couldn't do that as well: brackAsync before after thing = block $ do a <- before catch (unblock (thing a) >>= \r -> after a >> return r) $ \e -> do after a myThreadId >>= flip throwTo (e :: SomeException) brackAsync before after thing ) > This brackAsync just drops in to the previous code where bracket was and > appears to perform correctly. Right. 'race' should also unblock exceptions in the worker threads, withThread u v = brackAsync (forkIO (unblock u)) killThread (const v) but that's an independent change. > Further, if we place a trace after the > killThread, we se it gets executed once when the example is read (i.e. a > resumption) but it does not get executed if the (`seq` v) is removed from > the example So this gives me some hope that this is actually doing what > we'd like. I don't doubt it may have further kinks however. At least the GHC RTS has support for the hard part - unwinding the stack so that computations can be resumed seamlessly. I'm not sure which of the approaches I like better - it seems that we have a choice between turning async exceptions into sync ones or vice versa, and neither choice is strictly superior to the other. Enjoy, Bertram 'race' update: - Bugfix: Previously, only AsyncException-s would be caught. Use 'fromException' to select the ThreadKilled exception. - I tried using a custom 'SuspendException' type, but this resulted in 'test: SuspendException' messages on the console, while ThreadKilled is silently ignored... as documented: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AforkIO (http://tinyurl.com/9t5pxs) - Tweak: Block exceptions while running 'cleanup' to avoid killing threads twice. - Trick: takeMVar is a blocking operation, so exceptions can be delivered while it's waiting - there's no need to use 'unblock' for this. In other words, unblock (takeMVar v) and takeMVar v are essentially equivalent for our purposes. race :: IO a -> IO a -> IO a race a b = block $ do v <- newEmptyMVar let t x = unblock (x >>= putMVar v) ta <- forkIO (t a) tb <- forkIO (t b) let cleanup = killThread ta >> killThread tb (do r <- takeMVar v; cleanup; return r) `catch` \e -> cleanup >> case fromException e of Just ThreadKilled -> do myThreadId >>= killThread unblock (race a b) _ -> throwIO e From bayer at cpw.math.columbia.edu Sun Dec 28 10:29:13 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Sun Dec 28 10:21:16 2008 Subject: ghc -O2 and class dictionaries In-Reply-To: <4940ED99.7030101@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> <4940ED99.7030101@gmail.com> Message-ID: Using "ghc -O2" while tuning a class instance for performance, I obtained a 13% speedup by applying the transformation > instance (Ord a, Num b) ? Sum PSum a b where > empty = empty > insert = insert > union = union > unions = unions > extractMin = extractMin > fromList = fromList > toList = toList > map = map > mapMaybe = mapMaybe and defining the instance functions outside the instance declaration, rather than inside the instance declaration. Conceptually, I understand this as follows: After this transformation, none of the recursive calls have to go through the class dictionary. Is this a transformation that ghc could automatically apply while optimizing? It is clear at compile time that the recursive calls are from this instance. Every 13% helps. (My example is adapting a pairing heap to sums of terms, e.g. to define an algebra from a small category. So far, I can't beat Data.Map, but I'm not done tuning. Other examples might not show the same performance increase from this transformation.) From conal at conal.net Sun Dec 28 12:55:27 2008 From: conal at conal.net (Conal Elliott) Date: Sun Dec 28 12:47:29 2008 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: This is a neat trick indeed! I'd appreciate an explanation of killing one's own thread and then continuing (with a restart in this case). How does the post-kill resumption occur? That is, how does control pass to the tail-recursive call after the self-kill? - Conal 2008/12/28 Peter Verswyvelen > I fail to understand this part of the code: > case fromException e of > Just ThreadKilled -> do > myThreadId >>= killThread > unblock (race a b) > > So the current thread gets killed synchronously, then then the race > function is evaluated again? The latter I don't get. > > > > On Sun, Dec 28, 2008 at 3:03 AM, Bertram Felgenhauer < > bertram.felgenhauer@googlemail.com> wrote: > >> Sterling Clover wrote: >> > On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote: >> >> In the above code, there is a small window between catching the >> >> ThreadKilled exception and throwing it again though, where other >> >> exceptions may creep in. The only way I see of fixing that is to use >> >> 'block' and 'unblock' directly. >> > >> > That certainly seems to do the trick for the simple example at least. >> One >> > way to reason about it better would be, instead of folding everything >> into >> > the race function, to simply modify ghc's bracket function to give us >> the >> > behavior we'd prefer (speaking of which, I recall there's something in >> the >> > works for 6.12 or so to improve rethrowing of asynchronous exceptions?) >> > >> > brackAsync before after thing = >> > block (do >> > a <- before >> > r <- catch >> > (unblock (thing a)) >> > (\_ -> after a >> myThreadId >>= killThread >> >> > brackAsync before after thing ) >> > after a >> > return r >> > ) >> > where threadKilled ThreadKilled = Just () >> > threadKilled _ = Nothing >> >> This code turns any exception into ThreadKilled further down the stack. >> >> (\e -> do >> after a >> myThreadId >>= flip throwTo (e :: SomeException) >> ... >> >> might do the trick. >> >> My assumption was that anything but 'ThreadKilled' would be a >> real error. This isn't really true, I guess - thanks to throwTo, >> any exception could be asynchronous. >> >> If an exception is thrown, 'after a' is run again after the computation >> has resumed. >> >> That's why I did the cleanup within the 'catch'. >> >> But there's no reason why you couldn't do that as well: >> >> brackAsync before after thing = >> block $ do >> a <- before >> catch (unblock (thing a) >>= \r -> after a >> return r) $ >> \e -> do >> after a >> myThreadId >>= flip throwTo (e :: SomeException) >> brackAsync before after thing ) >> >> > This brackAsync just drops in to the previous code where bracket was and >> > appears to perform correctly. >> >> Right. 'race' should also unblock exceptions in the worker threads, >> >> withThread u v = brackAsync (forkIO (unblock u)) killThread (const v) >> >> but that's an independent change. >> >> > Further, if we place a trace after the >> > killThread, we se it gets executed once when the example is read (i.e. a >> > resumption) but it does not get executed if the (`seq` v) is removed >> from >> > the example So this gives me some hope that this is actually doing what >> > we'd like. I don't doubt it may have further kinks however. >> >> At least the GHC RTS has support for the hard part - unwinding the stack >> so that computations can be resumed seamlessly. >> >> I'm not sure which of the approaches I like better - it seems that we >> have a choice between turning async exceptions into sync ones or vice >> versa, and neither choice is strictly superior to the other. >> >> Enjoy, >> >> Bertram >> >> 'race' update: >> - Bugfix: Previously, only AsyncException-s would be caught. >> Use 'fromException' to select the ThreadKilled exception. >> - I tried using a custom 'SuspendException' type, but this resulted in >> 'test: SuspendException' messages on the console, while ThreadKilled >> is silently ignored... as documented: >> >> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AforkIO >> (http://tinyurl.com/9t5pxs) >> - Tweak: Block exceptions while running 'cleanup' to avoid killing >> threads twice. >> - Trick: takeMVar is a blocking operation, so exceptions can be >> delivered while it's waiting - there's no need to use 'unblock' for >> this. In other words, unblock (takeMVar v) and takeMVar v are >> essentially equivalent for our purposes. >> >> race :: IO a -> IO a -> IO a >> race a b = block $ do >> v <- newEmptyMVar >> let t x = unblock (x >>= putMVar v) >> ta <- forkIO (t a) >> tb <- forkIO (t b) >> let cleanup = killThread ta >> killThread tb >> (do r <- takeMVar v; cleanup; return r) `catch` >> \e -> cleanup >> >> case fromException e of >> Just ThreadKilled -> do >> myThreadId >>= killThread >> unblock (race a b) >> _ -> throwIO e >> _______________________________________________ >> 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/20081228/f81e4842/attachment-0001.htm From conal at conal.net Sun Dec 28 19:34:48 2008 From: conal at conal.net (Conal Elliott) Date: Sun Dec 28 19:26:49 2008 Subject: [reactive] Re: black hole detection and concurrency In-Reply-To: <20081228020305.GA4218@zombie.inf.tu-dresden.de> References: <20081227140245.GA4206@zombie.inf.tu-dresden.de> <20081228020305.GA4218@zombie.inf.tu-dresden.de> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: TestRace.hs Type: text/x-haskell Size: 3133 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081228/6fe117f9/TestRace.bin From bertram.felgenhauer at googlemail.com Mon Dec 29 01:26:47 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Dec 29 01:18:54 2008 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: <20081229062647.GA4205@zombie.inf.tu-dresden.de> Peter Verswyvelen wrote: > I fail to understand this part of the code: > case fromException e of > Just ThreadKilled -> do > myThreadId >>= killThread > unblock (race a b) > > So the current thread gets killed synchronously, then then the race function > is evaluated again? The latter I don't get. Let's look at what happens when an asynchronous exception arrives. The current thread gets killed. It gets killed asynchronously; as far as the RTS knows, the exceptionit might happen inside a pure computation which may be accessible to other threads. This means that the RTS has to patch things up so that reentering the corresponding thunks continues the computation - because another thread might need the value later. It does that by traversing the stack and turning update frames into ap nodes on the heap, and linking the entered thunks to those using an indirection (again, see RaiseAsync.c for details). 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. So in the above example, the current thread gets killed. However, the IO action (suspended right before the 'unblock (race a b)') is still accessible through the unsafePerformIO thunk. When another thread enters that thunk, execution resumes at that point. It may also be the same thread if it caught the exception further down the stack and later enters the unsafePerformIO thunk again. I don't understand all the interactions here - I don't know why the code is racy in the parallel RTS. Bertram From simonpj at microsoft.com Mon Dec 29 06:54:54 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 29 06:46:55 2008 Subject: length of module name affecting performance?? In-Reply-To: References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <20081215215343.GA31363@scytale.galois.com> <20081215224952.GB31363@scytale.galois.com> <20081216004350.GA32196@scytale.galois.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33286D93BEC@EA-EXMSG-C334.europe.corp.microsoft.com> | Subject: Re: length of module name affecting performance?? | | That's a truly awesome feature! I'll shorten all my module names to | single letters tomorrow. Awesome indeed :-). Try shortening all your variable names to single letters to, to see if that helps. Oh, and delete all comments. I recall that you and Thomas followed both these precepts rigorously when writing the LML compiler. I well remember trying to understand the lambda lifter, which was a miracle of compact programming: it did a *lot* in a single page of code, but all function definitions were equally impenetrable f x p l g i n = (g l [p], h i (i+p)) What a great bug -- I would never have predicted it, but in retrospect it makes perfect sense. Record selectors had better get fixed. Simon From simonpj at microsoft.com Mon Dec 29 09:20:10 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 29 09:12:11 2008 Subject: black hole detection and concurrency In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C73@EA-EXMSG-C334.europe.corp.microsoft.com> I have not followed the details of this thread, but Simon Marlow will be back in action on 5 Jan and he should know. What I do know is that this is supposed to happen: * If a *synchronous* exception S is raised when evaluating a thunk, the thunk is permanently updated to "throw S". * If an *asynchronous* exception A is raised when evaluating a thunk, the stack is copied into the heap, and the thunk is updated with a new thunk that, when evaluated, will resume evaluation where it left off. But there may be some funny interactions with unsafePerformIO. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 26 December 2008 06:15 To: glasgow-haskell-users@haskell.org Subject: black hole detection and concurrency I'm looking for information about black hole detection with ghc. I'm getting "<>" where I don't think there is an actual black hole. I get this message sometimes with the unamb package, which is implemented with unsafePerformIO, concurrency, and killThread, as described in http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice/ and http://conal.net/blog/posts/smarter-termination-for-thread-racing/ . Suppose I have a definition 'v = unsafePerformIO ...', and v is used more than once. Evaluation (to whnf) of v is begun and the evaluation thread gets killed before evaluation is complete. Then the second use begins. Will the second evaluation be (incorrectly) flagged as a black hole? I haven't found a simple, reproducible example of incorrect black-hole reporting. My current examples are tied up with the Reactive library. I do have another strange symptom, which is "thread killed" message. I wonder if it's related to the <> message. Code below. Thanks, - Conal import Prelude hiding (catch) import System.IO.Unsafe import Control.Concurrent import Control.Exception -- *** Exception: thread killed main :: IO () main = print $ f (f True) where f v = (v `unamb` True) `seq` v -- | Unambiguous choice operator. Equivalent to the ambiguous choice -- operator, but with arguments restricted to be equal where not bottom, -- so that the choice doesn't matter. See also 'amb'. unamb :: a -> a -> a unamb a b = unsafePerformIO (evaluate a `race` evaluate b) -- | Race two actions against each other in separate threads, and pick -- whichever finishes first. See also 'amb'. race :: IO a -> IO a -> IO a race a b = do v <- newEmptyMVar let t x = x >>= putMVar v withThread (t a) $ withThread (t b) $ takeMVar v where withThread u v = bracket (forkIO u) killThread (const v) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081229/dc94d1c1/attachment-0001.htm From simonpj at microsoft.com Mon Dec 29 09:21:34 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 29 09:13:34 2008 Subject: black hole detection and concurrency In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C74@EA-EXMSG-C334.europe.corp.microsoft.com> | I have a good theory on the latter symptom (the "thread killed" | message). Sticking in some traces, as in my appended code, helped me | to see what's going on. It seems to be exactly what you describe -- | the variable v is permanently bound to the exception it "evaluates" | to. Since the right hand True portion of the unamb evaluates more | quickly, the spawned threads are killed and the left hand (the v) | "evaluates" to "thread killed". 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 Simon From simonpj at microsoft.com Mon Dec 29 09:23:38 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 29 09:15:39 2008 Subject: ghc -O2 and class dictionaries In-Reply-To: References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> <4940ED99.7030101@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C76@EA-EXMSG-C334.europe.corp.microsoft.com> Which version of GHC are you using? GHC 6.10 implements automatically precisely the transformation you give below. If the difference shows up in GHC 6.10, could you spare a moment to produce a reproducible test case, and record it in GHC's bug tracker? Thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Dave Bayer | Sent: 28 December 2008 15:29 | To: glasgow-haskell-users@haskell.org | Subject: ghc -O2 and class dictionaries | | Using "ghc -O2" while tuning a class instance for performance, I | obtained a 13% speedup by applying the transformation | | > instance (Ord a, Num b) ? Sum PSum a b where | > empty = empty | > insert = insert | > union = union | > unions = unions | > extractMin = extractMin | > fromList = fromList | > toList = toList | > map = map | > mapMaybe = mapMaybe | | and defining the instance functions outside the instance declaration, | rather than inside the instance declaration. | | Conceptually, I understand this as follows: After this transformation, | none of the recursive calls have to go through the class dictionary. | | Is this a transformation that ghc could automatically apply while | optimizing? It is clear at compile time that the recursive calls are | from this instance. Every 13% helps. | | (My example is adapting a pairing heap to sums of terms, e.g. to | define an algebra from a small category. So far, I can't beat | Data.Map, but I'm not done tuning. Other examples might not show the | same performance increase from this transformation.) | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Mon Dec 29 09:48:32 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 29 09:40:31 2008 Subject: GADT Strangeness In-Reply-To: <494E0E60.5000902@blueyonder.co.uk> References: <494E0E60.5000902@blueyonder.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C86@EA-EXMSG-C334.europe.corp.microsoft.com> | 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. 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. Simon From bertram.felgenhauer at googlemail.com Mon Dec 29 11:07:22 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Dec 29 10:59:35 2008 Subject: black hole detection and concurrency In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C74@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C74@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20081229160722.GA10905@zombie.inf.tu-dresden.de> Simon Peyton-Jones wrote: > | I have a good theory on the latter symptom (the "thread killed" > | message). Sticking in some traces, as in my appended code, helped me > | to see what's going on. It seems to be exactly what you describe -- > | the variable v is permanently bound to the exception it "evaluates" > | to. Since the right hand True portion of the unamb evaluates more > | quickly, the spawned threads are killed and the left hand (the v) > | "evaluates" to "thread killed". > > 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. As I wrote elsewhere in this thread, this should not be a problem without unsafePerformIO. Bertram From phercek at gmail.com Mon Dec 29 14:45:09 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon Dec 29 14:37:16 2008 Subject: ghci debugger :trace command does not always extend trace history Message-ID: 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 [-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 [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> y :1:0: Not in scope: `y' [-1: a.hs:(2,0)-(5,2)] *Main> :back no more logged breakpoints [-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> z 2 [a.hs:5:2] *Main> y :1:0: Not in scope: `y' [a.hs:5:2] *Main> :quit Leaving GHCi. status:0 peter@metod [767] ~/tmp % From isaacdupree at charter.net Mon Dec 29 15:00:52 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Dec 29 14:53:03 2008 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: <49592C74.1080007@charter.net> Simon Peyton-Jones wrote: > 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. Does GHC require any flags to pattern-match against an existential constructor? (does it require type-system complication?) (and what if GADT syntax was used for an ordinary data type? or for an ordinary existential?) but I'd support requiring -XGADTs in any such pattern-match in which XRelaxedPolyRec could make a difference. Somehow it doesn't seem fair for a module to imply that it *doesn't* use GADTs, if it cannot even by type-checked without understanding them. also see http://hackage.haskell.org/trac/ghc/ticket/2004 -Isaac From isaacdupree at charter.net Mon Dec 29 15:32:54 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Dec 29 15:25:05 2008 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: <495933F6.5020407@charter.net> 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.) -Isaac From bayer at cpw.math.columbia.edu Mon Dec 29 17:45:06 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Mon Dec 29 17:37:06 2008 Subject: ghc -O2 and class dictionaries In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33286D93C76@EA-EXMSG-C334.europe.corp.microsoft.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <2bb2bdb40812061152y43679362q1812c781c5953164@mail.gmail.com> <167713711.20081207122934@gmail.com> <20081210122521.2333357d.Malcolm.Wallace@cs.york.ac.uk> <4940ED99.7030101@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33286D93C76@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Yeah, I knew it was fairly unlikely that I was the first to think of this optimization ;-) I just reported the "run-time performance bug" as http://hackage.haskell.org/trac/ghc/ticket/2902 I am using an Intel Core 2 Duo MacBook and GHC 6.10.1, OS X 10.5.6. For the toy example that I submitted, the difference is over a factor of 3x. Thanks, Dave On Dec 29, 2008, at 6:23 AM, Simon Peyton-Jones wrote: > Which version of GHC are you using? GHC 6.10 implements > automatically precisely the transformation you give below. > > If the difference shows up in GHC 6.10, could you spare a moment to > produce a reproducible test case, and record it in GHC's bug tracker? > > Thanks > > Simon From isaacdupree at charter.net Wed Dec 31 23:29:15 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Dec 31 23:21:19 2008 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: <495C469B.1060902@charter.net> Simon Peyton-Jones wrote: > 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. okay, well I made a feature request, anyway, http://hackage.haskell.org/trac/ghc/ticket/2905 -- people, please comment it! (whether you do or don't support it, maybe explaining why/not) -Isaac