From duncan.coutts at worc.ox.ac.uk Sat Nov 1 16:57:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 1 16:52:36 2008 Subject: cabal In-Reply-To: <48FD9820.10105@dfki.de> References: <48FC9583.4060404@dfki.de> <1224526539.21116.88.camel@dell.linuxdev.us.dell.com> <48FD9820.10105@dfki.de> Message-ID: <1225573050.8437.150.camel@localhost> On Tue, 2008-10-21 at 10:51 +0200, Christian Maeder wrote: > So network-2.2.0.0 should be linked against base-3 within the binary > dist of ghc-6.10 (or not shipped with ghc-6.10 at all. > > In fact it worked after I've unregistered my global network-2.2.0.0, > first! (but I didn't get much further, see below) network-2.2.0.1 is now on hackage which should resolve the issue. > > Normally cabal-install would use base-3 but in this case it's picking 4 > > because the version that is already installed used 4 so the assumption > > is that since the same version is already installed then it does indeed > > work with base 4. Of course that's not true here because the package has > > changed without the version being bumped. > > Or cabal-install should be smarter (or less smart). Unfortunately it cannot be less smart or it'd try rebuilding haskell98 against base 3. > So why is the version of network not bumped, yet? The maintainer is > libraries@haskell.org. Would it interfere with ghc-6.8? Done, and it works with (at least) ghc-6.6.1, 6.8.2 and 6.10.0.recent. Duncan From dagit at codersbase.com Sat Nov 1 21:15:37 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sat Nov 1 21:10:55 2008 Subject: Control.Exception In-Reply-To: <48EC6D16.3090308@gmail.com> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> Message-ID: On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow wrote: > Johannes Waldmann wrote: >> >> with 6.10, the following does not typecheck: >> >> foo `Control.Exception.catch` \ _ -> return bar >> >> Ambiguous type variable `e' in the constraint: >> `Control.Exception.Exception e' >> >> It is probably bad programming style anyway but what is the workaround? > > As long as you're aware that it is bad programming style. We deliberately > didn't include an easy way to do this, because we want people to think about > why they need to catch *all* exceptions (most of the time it's a bug). Since the above is bad form, what should I be doing? Could someone please provide some examples or point me at the list of exceptions that I can catch? What about catching multiple types of exceptions? Thanks, Jason From sof at galois.com Sat Nov 1 22:09:57 2008 From: sof at galois.com (Sigbjorn Finne) Date: Sat Nov 1 22:05:12 2008 Subject: Control.Exception In-Reply-To: References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> Message-ID: <490D0BF5.2040506@galois.com> (+1) to that request - what is the "best practices" for portable exception handling code that straddles version 6.10, i.e. that compiles with compilers at either side with minimal fuss? I can imagine a couple of alternatives, but would like to hear what others are doing here. thanks --sigbjorn "likes backward code compatibility" On 11/1/2008 18:15, Jason Dagit wrote: > On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow wrote: > >> Johannes Waldmann wrote: >> >>> with 6.10, the following does not typecheck: >>> >>> foo `Control.Exception.catch` \ _ -> return bar >>> >>> Ambiguous type variable `e' in the constraint: >>> `Control.Exception.Exception e' >>> >>> It is probably bad programming style anyway but what is the workaround? >>> >> As long as you're aware that it is bad programming style. We deliberately >> didn't include an easy way to do this, because we want people to think about >> why they need to catch *all* exceptions (most of the time it's a bug). >> > > Since the above is bad form, what should I be doing? Could someone > please provide some examples or point me at the list of exceptions > that I can catch? What about catching multiple types of exceptions? > > Thanks, > Jason > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From nominolo at googlemail.com Sun Nov 2 08:32:15 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Nov 2 08:27:14 2008 Subject: Control.Exception In-Reply-To: <490D0BF5.2040506@galois.com> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490D0BF5.2040506@galois.com> Message-ID: <916b84820811020532r6819c658kc41fb03d92a415bc@mail.gmail.com> I think the best way to get backwards compatibility is to flesh out and use the extensible-exceptions package that Ian started, which models extensible exceptions on top of the old exception mechanism. Alternatively, you can decide not to use extensible exceptions and have your package depend on base-3 instead of base-4. For a library, however, I don't think there's a good solution, since most of the time changing the exception mechanism for the library will make the library incompatible with existing clients. I guess the best way to deal with this is to properly use the package versioning policy and hope that clients specify their dependencies precisely. 2008/11/2 Sigbjorn Finne : > (+1) to that request - what is the "best practices" for portable exception > handling code that straddles version 6.10, i.e. that compiles with compilers > at either side with minimal fuss? I can imagine a couple of alternatives, > but > would like to hear what others are doing here. > > thanks > --sigbjorn "likes backward code compatibility" > > On 11/1/2008 18:15, Jason Dagit wrote: >> >> On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow wrote: >> >>> >>> Johannes Waldmann wrote: >>> >>>> >>>> with 6.10, the following does not typecheck: >>>> >>>> foo `Control.Exception.catch` \ _ -> return bar >>>> >>>> Ambiguous type variable `e' in the constraint: >>>> `Control.Exception.Exception e' >>>> >>>> It is probably bad programming style anyway but what is the workaround? >>>> >>> >>> As long as you're aware that it is bad programming style. We >>> deliberately >>> didn't include an easy way to do this, because we want people to think >>> about >>> why they need to catch *all* exceptions (most of the time it's a bug). >>> >> >> Since the above is bad form, what should I be doing? Could someone >> please provide some examples or point me at the list of exceptions >> that I can catch? What about catching multiple types of exceptions? >> >> Thanks, >> Jason >> _______________________________________________ >> 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 duncan.coutts at worc.ox.ac.uk Sun Nov 2 09:44:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 2 09:39:14 2008 Subject: Control.Exception In-Reply-To: <490D0BF5.2040506@galois.com> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490D0BF5.2040506@galois.com> Message-ID: <1225637052.8437.180.camel@localhost> On Sat, 2008-11-01 at 19:09 -0700, Sigbjorn Finne wrote: > (+1) to that request - what is the "best practices" for portable exception > handling code that straddles version 6.10, i.e. that compiles with compilers > at either side with minimal fuss? I can imagine a couple of > alternatives, but > would like to hear what others are doing here. As far as I know there is no nice easy way to be compatible with both models. There's no subset you can stick to that works with both. In libraries like Cabal and other libs we've done things like: catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a #ifdef BASE4 catchIO = Exception.catch #else catchIO = Exception.catchJust Exception.ioErrors #endif catchExit :: IO a -> (ExitCode -> IO a) -> IO a #ifdef BASE4 catchExit = Exception.catch #else catchExit = ... etc ... #endif The point is, the old catch deals with just one exception type, while the new one works with various kinds of specific exception types. So you'd need one of these ifdefs for each type of exception you're catching. The other alternative is to just keep using the base 3 exceptions for a while and switch next time your lib makes a major api change. If you need to switch to base 4 for other reasons you can use the Control.OldExceptions if you don't want to switch to the new exceptions at the same time. I don't know much about the extensible-exceptions package, I'll let someone else explain about that. I was initially rather annoyed that the api has changed to much that it was not possible to make code work nicely without using cpp. On the other hand, the new exceptions api is a good deal nicer to use and is much more easily extensible. The old dynamic exceptions stuff was horrible. We used it in gtk2hs to implement the detailed exceptions that glib/gtk throws, but it constantly confused users. The new api also encourages you not to do silly things like catching all exceptions, known and unknown like the previous api did. This is important now that we have things like ^C being exceptions. Duncan From prj at po.cwru.edu Sun Nov 2 20:37:46 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Sun Nov 2 20:32:48 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <20081029132236.GA11358@matrix.chaos.earth.li> (Ian Lynagh's message of "Wed\, 29 Oct 2008 13\:22\:36 +0000") References: <20081008200939.GA5675@matrix.chaos.earth.li> <20081023150059.GA11516@matrix.chaos.earth.li> <20081029132236.GA11358@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > I thought all your problems boiled down to binaries not being able to > find libgmp.so at runtime? So I think this should fix them all. Yes, but then I wouldn't be able to find and fix the commands that are missing SRC_HC_OPTS. :) So I'm holding off on that for now. Below is a patch for the ones I've found so far. With those changes, and without setting LD_LIBRARY_PATH, the build stops here: Preprocessing library hpc-0.5.0.2... dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory running dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make failed command was: dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make >dist-bootstrapping/build/Trace/Hpc/Reflect.hs My BUILD_FLAGS includes --ghc-option=-optl... and --ld-option=... flags which would take care of it, if they were being used, so apparently they're not. libraries/hpc/Trace/Hpc/Reflect.hsc produces libraries/hpc/dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make.c, which is compiled and linked to make libraries/hpc/dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make. Is there anything I can add to the cabal-bin command line to inject linker flags into that link command? --- libraries/Makefile 2008-10-07 15:30:24.000000000 -0400 +++ libraries/Makefile 2008-10-31 11:58:25.000000000 -0400 @@ -131,21 +131,21 @@ cabal-bin: cabal-bin.hs -mkdir bootstrapping - $(GHC) $(BOOTSTRAPPING_FLAGS) --make cabal-bin -o cabal-bin + $(GHC) $(BOOTSTRAPPING_FLAGS) $(SRC_HC_OPTS) --make cabal-bin -o cabal-bin bootstrapping.conf: cabal-bin echo "[]" > $@.tmp -cd filepath && $(CABAL) clean --distpref=dist-bootstrapping cd filepath && $(CABAL) configure --distpref=dist-bootstrapping --with-compiler=$(GHC) --with-hc-pkg=$(GHC_PKG) --package-db=$(HERE_ABS)/$@.tmp - cd filepath && $(CABAL) build --distpref=dist-bootstrapping + cd filepath && $(CABAL) build --distpref=dist-bootstrapping $(BUILD_FLAGS) cd filepath && $(CABAL) install --distpref=dist-bootstrapping --inplace -cd Cabal && $(CABAL) clean --distpref=dist-bootstrapping cd Cabal && $(CABAL) configure --distpref=dist-bootstrapping --with-compiler=$(GHC) --with-hc-pkg=$(GHC_PKG) --package-db=$(HERE_ABS)/$@.tmp - cd Cabal && $(CABAL) build --distpref=dist-bootstrapping + cd Cabal && $(CABAL) build --distpref=dist-bootstrapping $(BUILD_FLAGS) cd Cabal && $(CABAL) install --distpref=dist-bootstrapping --inplace -cd hpc && $(CABAL) clean --distpref=dist-bootstrapping cd hpc && $(CABAL) configure --distpref=dist-bootstrapping --with-compiler=$(GHC) --with-hc-pkg=$(GHC_PKG) --package-db=$(HERE_ABS)/$@.tmp - cd hpc && $(CABAL) build --distpref=dist-bootstrapping + cd hpc && $(CABAL) build --distpref=dist-bootstrapping $(BUILD_FLAGS) cd hpc && $(CABAL) install --distpref=dist-bootstrapping --inplace mv $@.tmp $@ @@ -154,9 +154,9 @@ mkdir ifBuildable $(CP) ifBuildable.hs ifBuildable/ ifeq "$(stage)" "2" - cd ifBuildable && ../$(HC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && ../$(HC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable else - cd ifBuildable && $(GHC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && $(GHC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable endif .PHONY: all build configure From p.k.f.holzenspies at utwente.nl Mon Nov 3 06:29:04 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?utf-8?q?H=C3=B6lzenspies?=) Date: Mon Nov 3 06:24:03 2008 Subject: No atomic read on MVar? Message-ID: <200811031229.04742.p.k.f.holzenspies@utwente.nl> Dear GHCers, I ran face first into an assumption I had made on MVar operations (in Control.Concurrent); I had assumed there to be an atomic read (i.e. non-destructive read, as opposed to destructive consume/take). The following program illustrates what I had in mind. testAtomic :: IO () testAtomic = do var <- newMVar 0 putStrLn("Fork") forkIO (putMVar var 1 >> putStrLn "X") yield r1 <- readMVar var putStrLn("1") r2 <- takeMVar var putStrLn("2") r3 <- takeMVar var putStrLn("Result: " ++ show [r1,r2,r3]) If readMVar had been atomic, the result would be program termination with a result of [0,0,1] being output. However, readMVar simply combines takeMVar and putMVar, so the reading of r1 blocks after the takeMVar, because upon taking the MVar, the blocked thread wakes up, puts 1 in var and prints X. readMVar does not terminate for r1 (i.e. "1" is never printed). I have now implemented my variable as a pair of MVars, one of which serves as a lock on the other. Both for performance reasons and for deadlock analysis, I would really like an atomic read on MVars, though. Does it exist? If not, why not? Regards, Philip From marlowsd at gmail.com Mon Nov 3 07:34:29 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 3 07:29:30 2008 Subject: could ghci debugger search for free variables better? In-Reply-To: References: <4901C456.3060008@gmail.com> Message-ID: <490EEFD5.3090900@gmail.com> Peter Hercek wrote: > Simon Marlow wrote: >> We thought about this when working on the debugger, and the problem is >> that to make the debugger retain all the variables that are in scope >> rather than just free in the expression adds a lot of overhead, and it >> fundamentally changes the structure of the generated code: everything >> becomes recursive, for one thing. Well, perhaps you could omit all >> the recursive references (except the ones that are also free?), but >> there would still be a lot of overhead due to having to retain all >> those extra references. >> >> It also risks creating serious space leaks, by retaining references to >> things that the program would normally discard. >> >> Fortunately it's usually easy to work around the limitation, just by >> adding extra references to your code, e.g. in a let expression that >> isn't used. > > Yes, Pepe pointed this to me too along with the "Step inside > GHCi debugger" paper in monad reader. The problem is that > I mostly can find out what is wrong when I look at values of > some important variables when some important place in my code > is hit. Using the trick with const function to manually add > references is not that much better than simple "printf > debugging" (adding Debug.Trace.trace calls to the code). > Tracing the execution history is nice too but it provides > much more than what is needed and obscures the important parts. > > OK, It is frustrating that I find "printf debugging" often more > productive than ghci debugger. > > I see that it is not a good idea to keep references to all the > variables in scope but maybe few improvements are possible: > > 1) As there is :steplocal, there should be also :tracelocal. > It would keep history of evaluations within given function > then when user asks for a variable it would be searched > first in the selected expression and if not found in the > expressions from the tracelocal history. If the result > would be printed from tracelocal history it should be indicated > so in the output. This would avoid the tedious task of > searching the trace history manually and moreover it would > limit the history to the interesting parts (so hopefully > the depth of 50 would be enough). The results from the > tracelocal history may not be from the expected scope > sometimes but the same problem is with "printf debugging". Good suggestion - please submit it via the bugtracker, http://hackage.haskell.org/trac/ghc/newticket?type=feature+request > 2) I noticed only now that I do not know how to script > breakpoints. I tried > :set stop if myFreeVar == 666 then :list else :continue > ... and it did not work. My goal was to create a conditional > breakpoint. I also wanted to use it instead of "printf > debugging" using something like > :set stop { :force myFreeVar; :continue } > Ideally it should be possible to attach > different script for each breakpoint and the functions > for controlling debugger should be available in the > Haskell. I would expect this is already partially possible > now (using :set stop) and possibly some functions from > ghci api which correspond to ghci commands (like :set etc.). > But I do not know how, any pointers from experienced ghci > debugger users? I think you want :cmd. e.g. :set stop :cmd if myFreeVar == 666 then return ":list" else return ":continue" > Ghci debugger did not know some functions in my code which > I would expect it to know; e.g. field selection functions > from a record which is not exported from the module but > which are available withing module. Is this expected? > (I did not have any *.hi *.o files around when ghci did run > the code.) It could be a bug, if you could figure out how to reproduce it and submit a bug report that would be great. > Och and sometimes it did not recognize a free variable in > the selected expression. The code looked like > let myFn x = x `div` getDivisor state > 100 in > if myFn xxx then ... > the expression "myFn xxx" was selected while browsing trace > history but xxx was not recognized, but when I browsed into > myFn definition in the trace log the x (which represented > the same value) was recognized. Is this expected? Again, please submit a bug report. The debugger is supposed to give you access to all of the free variables of the current expression. Cheers, Simon From marlowsd at gmail.com Mon Nov 3 07:40:45 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 3 07:35:46 2008 Subject: Dilemma: DiffArray non-performance vs STArray non-readability In-Reply-To: References: Message-ID: <490EF14D.7080100@gmail.com> Claus Reinke wrote: > I keep wanting to use DiffArray as the natural functional solution to > single-threaded array use. But everytime I try, I get smacked over > the head with the actual performance figures. Sometimes, even plain > arrays are faster in a loop doing array updates, in spite of all the > copying involved. And when copying on update dominates the runtime, > using IntMap tends to be faster - the "indirections" are the wrong way > round, but don't pile up, just that array lookups aren't quite constant > time. > > But when I really need to avoid the updates, and need constant > time lookup, I'm stuck: DiffArray tends to slow everything down > (I vaguely recall locks and threads being at the heart of this, but > I haven't checked the code recently), so my only option seems to > be to transform my nice functional code into not-nice sequential code > and use STArray. > > Is there any way out of this dilemma? What do other Ghc users use? > > If locks really are the issue, perhaps using STM instead of MVars > in the DiffArray implementation could help. As long as my array uses are > single-threaded, STM optimism might be able to avoid > waiting/scheduler issues? Or am I on the wrong track? It needs to be thread-safe, but I imagine that using atomicModifyIORef rather than STM or MVars is the way to get good performance here. > PS Btw, I thought the DiffArray performance issue was ancient, > but I can't find a ticket for it, nor does the haddock page for > Data.Array.Diff mention this little hickup. Should I add a ticket? I see there is one now, thanks. Cheers, Simon From marlowsd at gmail.com Mon Nov 3 08:24:32 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 3 08:19:33 2008 Subject: Control.Exception In-Reply-To: References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> Message-ID: <490EFB90.7080104@gmail.com> Jason Dagit wrote: > On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow wrote: >> Johannes Waldmann wrote: >>> with 6.10, the following does not typecheck: >>> >>> foo `Control.Exception.catch` \ _ -> return bar >>> >>> Ambiguous type variable `e' in the constraint: >>> `Control.Exception.Exception e' >>> >>> It is probably bad programming style anyway but what is the workaround? >> As long as you're aware that it is bad programming style. We deliberately >> didn't include an easy way to do this, because we want people to think about >> why they need to catch *all* exceptions (most of the time it's a bug). > > Since the above is bad form, what should I be doing? Could someone > please provide some examples or point me at the list of exceptions > that I can catch? What about catching multiple types of exceptions? Let's distinguish two kinds of exception handling: 1. Cleaning up. If you want to catch errors in order to clean up - release resources, remove temporary files, that sort of thing - then use bracket or finally. Behind the scenes, these catch all exceptions, but crucially they re-throw the exception after cleaning up, and they do the right block/unblock stuff for asynchronous exceptions. 2. Recovery. You want to catch certain kinds of exception in order to recover and do something else, e.g. when calling getEnv. In that case, I recommend using try or tryJust. tryJust (guard . isDoesNotExistError) $ getEnv "HOME" it's good practice to separate the filter (the kinds of exception you're catching) from the code to handle them, and that's what tryJust does. There's some subtelty here to do with whether you need to be in "blocked" mode to handle the exception or not: if you're handling an exception you expect to be thrown asynchronously, then you probably want to use catch instead of try, because then the handler will run in blocked mode. But be careful not to tail-call out of the handler, because then the thread will stay in blocked mode, which will lead to strange problems later. A bit more background is here: http://hackage.haskell.org/trac/ghc/ticket/2558 (hmm, perhaps exception handlers should be STM transactions. Then you wouldn't be able to accidentally tail-call out of the exception handler back into IO code, but you would be able to re-throw exceptions. Just a thought.) As for the kinds of exception you can catch, nowadays you can catch any type that is an instance of Exception. A good place to start is the list of instances of Exception in the docs: http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Control-Exception.html#t%3AException although that only contains types defined by the base package. Others have commented on the backwards-compat issues, I don't have anything to add there. Cheers, Simon From marlowsd at gmail.com Mon Nov 3 08:27:30 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 3 08:22:31 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: References: <20081008200939.GA5675@matrix.chaos.earth.li> <20081023150059.GA11516@matrix.chaos.earth.li> <20081029132236.GA11358@matrix.chaos.earth.li> Message-ID: <490EFC42.3070007@gmail.com> Paul Jarc wrote: > Ian Lynagh wrote: >> I thought all your problems boiled down to binaries not being able to >> find libgmp.so at runtime? So I think this should fix them all. > > Yes, but then I wouldn't be able to find and fix the commands that are > missing SRC_HC_OPTS. :) So I'm holding off on that for now. Below is > a patch for the ones I've found so far. With those changes, and > without setting LD_LIBRARY_PATH, the build stops here: Technically speaking, we should pass $(HC_OPTS) to any Haskell compilations. That includes $(SRC_HC_OPTS), but also a bunch of other things. Cheers, Simon From marlowsd at gmail.com Mon Nov 3 08:43:11 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 3 08:38:12 2008 Subject: No atomic read on MVar? In-Reply-To: <200811031229.04742.p.k.f.holzenspies@utwente.nl> References: <200811031229.04742.p.k.f.holzenspies@utwente.nl> Message-ID: <490EFFEF.7080208@gmail.com> Philip K.F. H?lzenspies wrote: > > I ran face first into an assumption I had made on MVar operations (in > Control.Concurrent); I had assumed there to be an atomic read (i.e. > non-destructive read, as opposed to destructive consume/take). The following > program illustrates what I had in mind. > > testAtomic :: IO () > testAtomic = do > var <- newMVar 0 > putStrLn("Fork") > forkIO (putMVar var 1 >> putStrLn "X") > yield > r1 <- readMVar var > putStrLn("1") > r2 <- takeMVar var > putStrLn("2") > r3 <- takeMVar var > putStrLn("Result: " ++ show [r1,r2,r3]) > > If readMVar had been atomic, the result would be program termination with a > result of [0,0,1] being output. However, readMVar simply combines takeMVar > and putMVar, so the reading of r1 blocks after the takeMVar, because upon > taking the MVar, the blocked thread wakes up, puts 1 in var and prints X. > readMVar does not terminate for r1 (i.e. "1" is never printed). > > I have now implemented my variable as a pair of MVars, one of which serves as > a lock on the other. Both for performance reasons and for deadlock analysis, > I would really like an atomic read on MVars, though. Does it exist? If not, > why not? It would be slightly annoying to implement, because it needs changes in putMVar too: if there are blocked readMVars, then putMVar would have to wake them all up. Right now an MVar can only have one type of blocked thread attached to it at a time, either takeMVars or putMVars, and putMVar only has to wake a single thread. Perhaps you should be using STM? I suppose the answer to "why doesn't atomic readMVar exist" is that MVar is intended to be a basic low-level synchronisation abstraction, on which you can build larger abstractions (which you have indeed done). On other other hand, we're always interested in getting good value out of the building blocks, so when there are useful operations we can add without adding distributed complexity, that's often a good idea. I'm not sure that atomic readMVar falls into this category, though. Cheers, Simon From dagit at codersbase.com Mon Nov 3 10:34:49 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Nov 3 10:29:44 2008 Subject: Control.Exception In-Reply-To: <490EFB90.7080104@gmail.com> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> Message-ID: On Mon, Nov 3, 2008 at 6:24 AM, Simon Marlow wrote: > Jason Dagit wrote: >> >> On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow wrote: >>> >>> Johannes Waldmann wrote: >>>> >>>> with 6.10, the following does not typecheck: >>>> >>>> foo `Control.Exception.catch` \ _ -> return bar >>>> >>>> Ambiguous type variable `e' in the constraint: >>>> `Control.Exception.Exception e' >>>> >>>> It is probably bad programming style anyway but what is the workaround? >>> >>> As long as you're aware that it is bad programming style. We >>> deliberately >>> didn't include an easy way to do this, because we want people to think >>> about >>> why they need to catch *all* exceptions (most of the time it's a bug). >> >> Since the above is bad form, what should I be doing? Could someone >> please provide some examples or point me at the list of exceptions >> that I can catch? What about catching multiple types of exceptions? > > Let's distinguish two kinds of exception handling: Thanks. This helps a lot. Mind if I put it somewhere, such as on the wiki? > As for the kinds of exception you can catch, nowadays you can catch any type > that is an instance of Exception. A good place to start is the list of > instances of Exception in the docs: > > http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Control-Exception.html#t%3AException > > although that only contains types defined by the base package. > > Others have commented on the backwards-compat issues, I don't have anything > to add there. Ah, but I had one more question that I don't think anyone has answered yet. That is, how to deal with multiple types of exceptions. Suppose, as a concrete example, that I was looking out for both ExitCode and PatternMatchFail exceptions. Maybe I'm being naive, but it seems like I'm in that situation again where I have to catch all and then check if fromException succeeds on either PatternMatchFile or ExitCode types. And then throw if it both give Nothing? Thanks! Jason From aslatter at gmail.com Mon Nov 3 11:05:17 2008 From: aslatter at gmail.com (Antoine Latter) Date: Mon Nov 3 11:00:13 2008 Subject: Control.Exception In-Reply-To: References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> Message-ID: <694519c50811030805u51c9ebegf17133a971fb7586@mail.gmail.com> On Mon, Nov 3, 2008 at 9:34 AM, Jason Dagit wrote: > > Ah, but I had one more question that I don't think anyone has answered > yet. That is, how to deal with multiple types of exceptions. > Suppose, as a concrete example, that I was looking out for both > ExitCode and PatternMatchFail exceptions. Maybe I'm being naive, but > it seems like I'm in that situation again where I have to catch all > and then check if fromException succeeds on either PatternMatchFile or > ExitCode types. And then throw if it both give Nothing? > I haven't tried this, so it may not work: >>>> data MyException = MyArithException ArithException | MyIOException IOException deriving Typeable instance Exception MyExcpetion where toException (MyArithException e) = toException e toException (MyIOExcpetion e) = toException e fromException se = case fromException se of Just e -> Just $ MyArithException e Nothing -> case fromException se of Just e -> Just $ MyIOException e _ -> Nothing <<<<< Then anyone can catch your exceptions by catching the ArithException or IOException as normal, and you can catch IOExceptions and ArithExceptions into your own custom type. -Antoine From sof at galois.com Mon Nov 3 12:26:54 2008 From: sof at galois.com (Sigbjorn Finne) Date: Mon Nov 3 12:21:54 2008 Subject: Control.Exception In-Reply-To: References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> Message-ID: <490F345E.5090601@galois.com> On 11/3/2008 07:34, Jason Dagit wrote: > .... > > Ah, but I had one more question that I don't think anyone has answered > yet. That is, how to deal with multiple types of exceptions. > Suppose, as a concrete example, that I was looking out for both > ExitCode and PatternMatchFail exceptions. Maybe I'm being naive, but > it seems like I'm in that situation again where I have to catch all > and then check if fromException succeeds on either PatternMatchFile or > ExitCode types. And then throw if it both give Nothing? > > One way to do this now is to use Control.Exception.catches: catches :: IO a -> [Handler a] -> IO a data Handler a where Handler :: forall a e. (Exception e) => (e -> IO a) -> Handler a --sigbjorn From duncan.coutts at worc.ox.ac.uk Mon Nov 3 12:53:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 3 12:48:20 2008 Subject: Control.Exception In-Reply-To: <490F345E.5090601@galois.com> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> <490F345E.5090601@galois.com> Message-ID: <1225734800.8437.232.camel@localhost> On Mon, 2008-11-03 at 09:26 -0800, Sigbjorn Finne wrote: > On 11/3/2008 07:34, Jason Dagit wrote: > > .... > > > > Ah, but I had one more question that I don't think anyone has answered > > yet. That is, how to deal with multiple types of exceptions. > > Suppose, as a concrete example, that I was looking out for both > > ExitCode and PatternMatchFail exceptions. Maybe I'm being naive, but > > it seems like I'm in that situation again where I have to catch all > > and then check if fromException succeeds on either PatternMatchFile or > > ExitCode types. And then throw if it both give Nothing? > > > > > One way to do this now is to use Control.Exception.catches: > > catches :: IO a -> [Handler a] -> IO a > data Handler a where > Handler :: forall a e. (Exception e) => (e -> IO a) -> Handler a ie: action `catches` [ \(e :: ExitCode) -> ... , \(e :: PatternMatchFail) -> ... ] or just by using multiple catch clauses: action `catch` (\(e :: ExitCode) -> ...) `catch` (\(e :: PatternMatchFail) -> ...) Duncan From phercek at gmail.com Mon Nov 3 16:24:51 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon Nov 3 16:20:04 2008 Subject: could ghci debugger search for free variables better? In-Reply-To: <490EEFD5.3090900@gmail.com> References: <4901C456.3060008@gmail.com> <490EEFD5.3090900@gmail.com> Message-ID: <490F6C23.5000309@gmail.com> Simon Marlow wrote: > Peter Hercek wrote: <---cut---> >> I see that it is not a good idea to keep references to all the >> variables in scope but maybe few improvements are possible: >> >> 1) As there is :steplocal, there should be also :tracelocal. >> It would keep history of evaluations within given function >> then when user asks for a variable it would be searched >> first in the selected expression and if not found in the >> expressions from the tracelocal history. If the result >> would be printed from tracelocal history it should be indicated >> so in the output. This would avoid the tedious task of >> searching the trace history manually and moreover it would >> limit the history to the interesting parts (so hopefully >> the depth of 50 would be enough). The results from the >> tracelocal history may not be from the expected scope >> sometimes but the same problem is with "printf debugging". > > Good suggestion - please submit it via the bugtracker, > > http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Here it is: http://hackage.haskell.org/trac/ghc/ticket/2737 >> 2) I noticed only now that I do not know how to script >> breakpoints. I tried >> :set stop if myFreeVar == 666 then :list else :continue >> ... and it did not work. My goal was to create a conditional >> breakpoint. I also wanted to use it instead of "printf >> debugging" using something like >> :set stop { :force myFreeVar; :continue } >> Ideally it should be possible to attach >> different script for each breakpoint and the functions >> for controlling debugger should be available in the >> Haskell. I would expect this is already partially possible >> now (using :set stop) and possibly some functions from >> ghci api which correspond to ghci commands (like :set etc.). >> But I do not know how, any pointers from experienced ghci >> debugger users? > > I think you want :cmd. e.g. > > :set stop :cmd if myFreeVar == 666 then return ":list" else return > ":continue" Yes! That works good enough, and I can set a different script for each breakpoint with ":set stop N "! Thanks. The only thing I still miss here is a way to suppress the default output when a breakpoint (which has a script attached?) is hit. As for as the rest of the message. Those are possible bugs. If I can reduce them to few tens of lines of a test, I'll post the bug reports. I use Archlinux and the last (non-testing) version of ghc there is ghc-6.8.2. Do you accept bug reports against it or do you need them against 6.10.1rc1 only? Thanks for help, Peter. >> Ghci debugger did not know some functions in my code which >> I would expect it to know; e.g. field selection functions >> from a record which is not exported from the module but >> which are available withing module. Is this expected? >> (I did not have any *.hi *.o files around when ghci did run >> the code.) > > It could be a bug, if you could figure out how to reproduce it and > submit a bug report that would be great. > >> Och and sometimes it did not recognize a free variable in >> the selected expression. The code looked like >> let myFn x = x `div` getDivisor state > 100 in >> if myFn xxx then ... >> the expression "myFn xxx" was selected while browsing trace >> history but xxx was not recognized, but when I browsed into >> myFn definition in the trace log the x (which represented >> the same value) was recognized. Is this expected? > > Again, please submit a bug report. The debugger is supposed to give you > access to all of the free variables of the current expression. > > Cheers, > Simon From dave at zednenem.com Mon Nov 3 17:40:50 2008 From: dave at zednenem.com (David Menendez) Date: Mon Nov 3 17:35:45 2008 Subject: Control.Exception In-Reply-To: <1225734800.8437.232.camel@localhost> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> <490F345E.5090601@galois.com> <1225734800.8437.232.camel@localhost> Message-ID: <49a77b7a0811031440o64f63ce2ie978abd811d5495b@mail.gmail.com> On Mon, Nov 3, 2008 at 12:53 PM, Duncan Coutts wrote: > On Mon, 2008-11-03 at 09:26 -0800, Sigbjorn Finne wrote: >> One way to do this now is to use Control.Exception.catches: >> >> catches :: IO a -> [Handler a] -> IO a >> data Handler a where >> Handler :: forall a e. (Exception e) => (e -> IO a) -> Handler a > > ie: > > action > `catches` > [ \(e :: ExitCode) -> ... > , \(e :: PatternMatchFail) -> ... > ] > > or just by using multiple catch clauses: > > action > `catch` (\(e :: ExitCode) -> ...) > `catch` (\(e :: PatternMatchFail) -> ...) I don't think those are equivalent. In the second case, the PatternMatchFail handler scopes over the ExitCode handler. -- Dave Menendez From dave at zednenem.com Mon Nov 3 17:51:33 2008 From: dave at zednenem.com (David Menendez) Date: Mon Nov 3 17:46:28 2008 Subject: No atomic read on MVar? In-Reply-To: <200811031229.04742.p.k.f.holzenspies@utwente.nl> References: <200811031229.04742.p.k.f.holzenspies@utwente.nl> Message-ID: <49a77b7a0811031451n45fc1a56v2362bdd5fd59031c@mail.gmail.com> On Mon, Nov 3, 2008 at 6:29 AM, Philip K.F. H?lzenspies wrote: > > I have now implemented my variable as a pair of MVars, one of which serves as > a lock on the other. Both for performance reasons and for deadlock analysis, > I would really like an atomic read on MVars, though. Does it exist? If not, > why not? Have you considered using STM? All the operations on TMVars are atomic. -- Dave Menendez From shelarcy at gmail.com Mon Nov 3 19:27:13 2008 From: shelarcy at gmail.com (shelarcy) Date: Mon Nov 3 19:22:11 2008 Subject: Control.Exception In-Reply-To: <49a77b7a0811031440o64f63ce2ie978abd811d5495b@mail.gmail.com> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> <490F345E.5090601@galois.com> <1225734800.8437.232.camel@localhost> <49a77b7a0811031440o64f63ce2ie978abd811d5495b@mail.gmail.com> Message-ID: On Tue, 04 Nov 2008 07:40:50 +0900, David Menendez wrote: >> ie: >> >> action >> `catches` >> [ \(e :: ExitCode) -> ... >> , \(e :: PatternMatchFail) -> ... >> ] >> >> or just by using multiple catch clauses: >> >> action >> `catch` (\(e :: ExitCode) -> ...) >> `catch` (\(e :: PatternMatchFail) -> ...) > > I don't think those are equivalent. In the second case, the > PatternMatchFail handler scopes over the ExitCode handler. I think Duncan forgot to write parens. According to Ian's example, here is an equivalent code. (action `catch` (\(e :: ExitCode) -> ...)) `catch` (\(e :: PatternMatchFail) -> ...) http://www.haskell.org/pipermail/libraries/2008-July/010095.html Best Regards, -- shelarcy http://page.freett.com/shelarcy/ From dave at zednenem.com Mon Nov 3 22:08:25 2008 From: dave at zednenem.com (David Menendez) Date: Mon Nov 3 22:03:20 2008 Subject: Control.Exception In-Reply-To: References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> <490F345E.5090601@galois.com> <1225734800.8437.232.camel@localhost> <49a77b7a0811031440o64f63ce2ie978abd811d5495b@mail.gmail.com> Message-ID: <49a77b7a0811031908x43dceb94l562a457f9e9fabe0@mail.gmail.com> On Mon, Nov 3, 2008 at 7:27 PM, shelarcy wrote: > On Tue, 04 Nov 2008 07:40:50 +0900, David Menendez wrote: >>> ie: >>> >>> action >>> `catches` >>> [ \(e :: ExitCode) -> ... >>> , \(e :: PatternMatchFail) -> ... >>> ] >>> >>> or just by using multiple catch clauses: >>> >>> action >>> `catch` (\(e :: ExitCode) -> ...) >>> `catch` (\(e :: PatternMatchFail) -> ...) >> >> I don't think those are equivalent. In the second case, the >> PatternMatchFail handler scopes over the ExitCode handler. > > I think Duncan forgot to write parens. According to Ian's example, > here is an equivalent code. > > (action > `catch` (\(e :: ExitCode) -> ...)) > `catch` (\(e :: PatternMatchFail) -> ...) > > http://www.haskell.org/pipermail/libraries/2008-July/010095.html That's equivalent to the code without the parentheses, but it isn't equivalent to the code using "catches". Assume we have exitCodeHandler :: ExitCode -> IO () and pattternMatchHandler :: PatternMatchFail -> IO (), 1. action `catches` [ Handler exitCodeHandler, Handler patternMatchHandler ] 2. (action `catch` exitCodeHandler) `catch` patternMatchHandler Let's further assume that "action" throws an ExitCode exception and "exitCodeHandler" throws a PatternMatchFail exception. In example 1, the PatternMatchFail exception thrown by "exitCodeHandler" is not caught by "patternMatchHandler", but it in example 2 it is caught. In other words, patternMatchHandler is active during the evaluation of exitCodeHandler in example 2, but not in example 1. -- Dave Menendez From marlowsd at gmail.com Tue Nov 4 03:56:21 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 4 03:51:19 2008 Subject: could ghci debugger search for free variables better? In-Reply-To: <490F6C23.5000309@gmail.com> References: <4901C456.3060008@gmail.com> <490EEFD5.3090900@gmail.com> <490F6C23.5000309@gmail.com> Message-ID: <49100E35.2070403@gmail.com> Peter Hercek wrote: > As for as the rest of the message. Those are possible bugs. > If I can reduce them to few tens of lines of a test, I'll > post the bug reports. I use Archlinux and the last (non-testing) > version of ghc there is ghc-6.8.2. Do you accept bug reports > against it or do you need them against 6.10.1rc1 only? Bug reports against 6.8.2 are fine, but if you can test against 6.10.1 that's even better (it might weed out bugs that have been already fixed and thus save us some time). Cheers, Simon From arnarbi at gmail.com Tue Nov 4 04:51:09 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Tue Nov 4 04:46:03 2008 Subject: No atomic read on MVar? In-Reply-To: <49a77b7a0811031451n45fc1a56v2362bdd5fd59031c@mail.gmail.com> References: <200811031229.04742.p.k.f.holzenspies@utwente.nl> <49a77b7a0811031451n45fc1a56v2362bdd5fd59031c@mail.gmail.com> Message-ID: <28012bc60811040151n53008cd7x84ff2ffbb79181ed@mail.gmail.com> On Mon, Nov 3, 2008 at 23:51, David Menendez wrote: > On Mon, Nov 3, 2008 at 6:29 AM, Philip K.F. H?lzenspies > wrote: >> >> I have now implemented my variable as a pair of MVars, one of which serves as >> a lock on the other. Both for performance reasons and for deadlock analysis, >> I would really like an atomic read on MVars, though. Does it exist? If not, >> why not? > > Have you considered using STM? All the operations on TMVars are atomic. I will second this. At the very least, if you only need atomic read/write operations you can use TMVars and make aliases that compose with atomically: takeMVar = atomically . takeTMVar putMVar = atomically . putTMVar etc. cheers, Arnar From marlowsd at gmail.com Tue Nov 4 05:47:13 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 4 05:42:11 2008 Subject: Control.Exception In-Reply-To: References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> Message-ID: <49102831.5030406@gmail.com> Jason Dagit wrote: > On Mon, Nov 3, 2008 at 6:24 AM, Simon Marlow wrote: >> Jason Dagit wrote: >>> On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow wrote: >>>> Johannes Waldmann wrote: >>>>> with 6.10, the following does not typecheck: >>>>> >>>>> foo `Control.Exception.catch` \ _ -> return bar >>>>> >>>>> Ambiguous type variable `e' in the constraint: >>>>> `Control.Exception.Exception e' >>>>> >>>>> It is probably bad programming style anyway but what is the workaround? >>>> As long as you're aware that it is bad programming style. We >>>> deliberately >>>> didn't include an easy way to do this, because we want people to think >>>> about >>>> why they need to catch *all* exceptions (most of the time it's a bug). >>> Since the above is bad form, what should I be doing? Could someone >>> please provide some examples or point me at the list of exceptions >>> that I can catch? What about catching multiple types of exceptions? >> Let's distinguish two kinds of exception handling: > > Thanks. This helps a lot. Mind if I put it somewhere, such as on the wiki? A good description of how to deal with exceptions would be great to have in the Haddock documentation for Control.Exception - would you (or someone else) like to write and submit a patch? Or failing that, just putting it on the wiki would be useful too. Cheers, Simon From haskell at list.mightyreason.com Tue Nov 4 05:57:58 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Nov 4 05:53:08 2008 Subject: No atomic read on MVar? In-Reply-To: <28012bc60811040151n53008cd7x84ff2ffbb79181ed@mail.gmail.com> References: <200811031229.04742.p.k.f.holzenspies@utwente.nl> <49a77b7a0811031451n45fc1a56v2362bdd5fd59031c@mail.gmail.com> <28012bc60811040151n53008cd7x84ff2ffbb79181ed@mail.gmail.com> Message-ID: <49102AB6.9090008@list.mightyreason.com> It is true that STM's TMVars (which are TVar (Maybe _)) allow atomic readTMVar. They are not a great replacement for MVars for serious performance reasons. MVars have "wake one" semantics: There can be many threads stopped and waiting on a particular MVar to be filled/emptied. These are actually in a FIFO queue. Filling or emptying it will cause the next thread in the FIFO queue to run, and leave the others to sleep. [1] TVars (and TMVars, and all STM threads) have "wake all" semantics: All threads which are stopped after a "retry" that are monitoring a particular TVar will be woken when the TVar is changed by the next STM commit. This will cause the "thundering herd" problem that plagued big Apache web servers with the original multi-process model [2]. To understand MVars and Simon's comments on the atomic read proposal I went and read the code in [3] to see it first hand. The putMVar# and tryPutMVar# operations, when a take operation is blocked, will perform the take operation and then wake the blocked thread. The takeMVar# and tryTakeMVar# do the reverse. So adding an atomicRead# operation would mean that on filling the MVar that all the atomicRead# that are waiting might need to be woken (or perhaps just those at the front of the FIFO). This is a fairly large change. The desire to atomically read an MVar could be expressed by (1) Use STM and lose the "wake one" performance (2) Use an (MVar ()) guarding the (MVar a) (3) Use an (MVar ()) guarding an (IORef a) Where (3) has a performance advantage to (2) and (3) is safe when only the right operations are exposed. I started looking at this with the opinion that "readMVar" and "withMVar" should have atomic semantics, i.e. edit PrimOps.cmm to add these operations. Now I am leaning to taking (3) and packaging this as a new module that exposes the safe operations. Cheers, Chris [1] http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html#v%3AtakeMVar [2] http://www.google.co.uk/search?q="thundering+herd"+apache [3] http://darcs.haskell.org/ghc/rts/PrimOps.cmm From shelarcy at gmail.com Tue Nov 4 06:21:15 2008 From: shelarcy at gmail.com (shelarcy) Date: Tue Nov 4 06:16:13 2008 Subject: Control.Exception In-Reply-To: <1225795318.8437.248.camel@localhost> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> <490F345E.5090601@galois.com> <1225734800.8437.232.camel@localhost> <49a77b7a0811031440o64f63ce2ie978abd811d5495b@mail.gmail.com> <1225795318.8437.248.camel@localhost> Message-ID: On Tue, 04 Nov 2008 19:41:58 +0900, Duncan Coutts wrote: >> >> action >> >> `catches` >> >> [ \(e :: ExitCode) -> ... >> >> , \(e :: PatternMatchFail) -> ... >> >> ] >> >> >> >> or just by using multiple catch clauses: >> >> >> >> action >> >> `catch` (\(e :: ExitCode) -> ...) >> >> `catch` (\(e :: PatternMatchFail) -> ...) >> > >> > I don't think those are equivalent. In the second case, the >> > PatternMatchFail handler scopes over the ExitCode handler. >> >> I think Duncan forgot to write parens. According to Ian's example, >> here is an equivalent code. >> >> (action >> `catch` (\(e :: ExitCode) -> ...)) >> `catch` (\(e :: PatternMatchFail) -> ...) > > David is right. If the exit code handler throws a pattern match > exception then the code behaves differently than the `catches` version. I see. I misunderstood the problem. Thanks, -- shelarcy http://page.freett.com/shelarcy/ From phercek at gmail.com Tue Nov 4 08:43:13 2008 From: phercek at gmail.com (Peter Hercek) Date: Tue Nov 4 08:38:18 2008 Subject: could ghci debugger search for free variables better? In-Reply-To: <49100E35.2070403@gmail.com> References: <4901C456.3060008@gmail.com> <490EEFD5.3090900@gmail.com> <490F6C23.5000309@gmail.com> <49100E35.2070403@gmail.com> Message-ID: <49105171.4060409@gmail.com> Simon Marlow wrote: > Peter Hercek wrote: > >> As for as the rest of the message. Those are possible bugs. >> If I can reduce them to few tens of lines of a test, I'll >> post the bug reports. I use Archlinux and the last (non-testing) >> version of ghc there is ghc-6.8.2. Do you accept bug reports >> against it or do you need them against 6.10.1rc1 only? > > Bug reports against 6.8.2 are fine, but if you can test against 6.10.1 > that's even better (it might weed out bugs that have been already fixed > and thus save us some time). Here it is (against 6.8.2): http://hackage.haskell.org/trac/ghc/ticket/2740 Peter. From dagit at codersbase.com Tue Nov 4 12:51:28 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Nov 4 12:46:20 2008 Subject: Control.Exception In-Reply-To: <49102831.5030406@gmail.com> References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> <49102831.5030406@gmail.com> Message-ID: On Tue, Nov 4, 2008 at 2:47 AM, Simon Marlow wrote: > Jason Dagit wrote: >> Thanks. This helps a lot. Mind if I put it somewhere, such as on the >> wiki? > > A good description of how to deal with exceptions would be great to have in > the Haddock documentation for Control.Exception - would you (or someone > else) like to write and submit a patch? Or failing that, just putting it on > the wiki would be useful too. I don't mind submitting a patch. What is the URL of the repo I should download? Thanks! Jason From igloo at earth.li Tue Nov 4 13:11:06 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 4 13:06:00 2008 Subject: ANNOUNCE: GHC version 6.10.1 Message-ID: <20081104181106.GA20684@matrix.chaos.earth.li> ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Some new language features have been implemented: * Record syntax: wild-card patterns, punning, and field disambiguation * Generalised quasi-quotes * Generalised list comprehensions * View patterns * Type families have been completely re-implemented * Now comes with Haddock 2, which supports all GHC extensions * Parallel garbage collection * Base provides extensible exceptions * The GHC API is easier to use * External core (output only) now works again * Data Parallel Haskell (DPH) comes as part of GHC The full release notes are here: http://haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug From kolmodin at dtek.chalmers.se Tue Nov 4 14:28:45 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Tue Nov 4 14:27:54 2008 Subject: ANNOUNCE: GHC version 6.10.1 In-Reply-To: <20081104181106.GA20684@matrix.chaos.earth.li> References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: <4910A26D.1040909@dtek.chalmers.se> Hello fellow GHC users, Ian Lynagh wrote: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 > ============================================================== [snip] > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ Gentoo Linux users can get it from the gentoo-haskell overlay[1]. If you're not familiar with this overlay (a gold mine for haskell hackers using gentoo), you can easily use layman[2] to get access. Make sure you have darcs installed, as it is a requirement for our overlay. Once layman is set up, add the overlay with: $ layman -a haskell Note that ghc-6.10.1 still is masked by keyword, and you need to unmask it first. If you're not familiar with how to do this, here's a quick guide: # make sure /etc/portage exists $ [[ -d /etc/portage ]] || mkdir /etc/portage # accept ghc being ~arch $ echo "dev-lang/ghc" >> /etc/portage/package.keywords # ghc requires the very latest libedit package $ echo "dev-libs/libedit" >> /etc/portage/package.keywords You may then install ghc-6.10.1 by saying: # this requires that you already have an older ghc version installed $ USE="ghcbootstrap -binary" emerge ghc The USE flags are required as we don't just yet provide the required binaries to bootstrap ghc. The command above requires that you already have a ghc version installed to bootstrap with. This version will be replaced with ghc-6.10.1 once the installation finishes. GHC binaries will follow shortly, which will shorten the procedure to: $ emerge ghc The packages from extralibs will also be available from the overlay. If you run into trouble, reply to the ml, or find us in #gentoo-haskell at freenode. Cheers, Lennart Kolmodin -- using his Gentoo Linux Developer hat [1] http://code.haskell.org/gentoo/gentoo-haskell/ [2] http://www.gentoo.org/proj/en/overlays/userguide.xml From dagit at codersbase.com Tue Nov 4 16:32:02 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Nov 4 16:26:54 2008 Subject: ANNOUNCE: GHC version 6.10.1 In-Reply-To: <20081104181106.GA20684@matrix.chaos.earth.li> References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh wrote: > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed from a pkg). I would like to add ghc-6.10.1 to my system. I tried to do this with RC1 of 6.10, but I found that it uninstalled my ghc-6.8.3. What will I need to do to get both 6.8.3 and 6.10.1? Thank you! Jason From chak at cse.unsw.edu.au Tue Nov 4 19:26:20 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Nov 4 19:21:15 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: Jason Dagit: > On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh wrote: >> >> How to get it >> ~~~~~~~~~~~~~ >> >> The easy way is to go to the web page, which should be self- >> explanatory: >> >> http://www.haskell.org/ghc/ >> >> We supply binary builds in the native package format for many >> platforms, and the source distribution is available from the same >> place. >> >> Packages will appear as they are built - if the package for your >> system isn't available yet, please try again later. > > I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed > from a pkg). I would like to add ghc-6.10.1 to my system. I tried to > do this with RC1 of 6.10, but I found that it uninstalled my > ghc-6.8.3. > > What will I need to do to get both 6.8.3 and 6.10.1? Are you sure it does deinstall the 6.8 compiler? Or does it just overwrite the symbolic links in /usr/bin? To check, have a look at /Library/Frameworks/GHC.framework/Versions After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. And while we are at it...a BIG FAT WARNING: If you installed the 6.10.200081007 pre-release installer package, uninstall that *before* installing the 6.10.1 package. For reasons, I don't understand, the installer otherwise half removes the old package, but doesn't seem to install the new one. Can a Mac expert shed any light on that behaviour? If you tried installing 6.10.1 before reading that, just remove the partial installation you are left with, and install again. Manuel From igloo at earth.li Tue Nov 4 20:16:52 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 4 20:11:48 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: <20081105011652.GA27308@matrix.chaos.earth.li> On Wed, Nov 05, 2008 at 11:26:20AM +1100, Manuel M T Chakravarty wrote: > Jason Dagit: > > > >What will I need to do to get both 6.8.3 and 6.10.1? > > Are you sure it does deinstall the 6.8 compiler? It definitely deinstalls it for me; I've just confirmed it. Here's what I saw with a 6.9 OS X installer a while ago: If I start off with 6.8.3 installed: $ ls -l /Library/Frameworks/GHC.framework/Versions/ total 8 drwxrwxr-x 4 root admin 136 Jun 18 03:10 608 lrwxr-xr-x 1 root admin 3 Aug 29 12:57 Current -> 608 then while my GHC-6.9.20080828-i386.pkg is installing I see: $ ls -l /Library/Frameworks/GHC.framework/Versions/ total 8 drwxrwxr-x 4 root admin 136 Aug 29 12:58 609 lrwxr-xr-x 1 root admin 3 Aug 29 12:57 Current -> 608 (i.e. 608 has disappeared, but it isn't the whole GHC.framework that's been removed because the Current link is still there) and then when the installer has finished: $ ls -l /Library/Frameworks/GHC.framework/Versions/ total 8 drwxrwxr-x 4 root admin 136 Aug 29 12:58 609 lrwxr-xr-x 1 root admin 3 Aug 29 12:57 Current -> 608 Thanks IAn From dagit at codersbase.com Tue Nov 4 20:26:54 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Nov 4 20:21:47 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty wrote: > Jason Dagit: >> >> On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh wrote: >>> >>> How to get it >>> ~~~~~~~~~~~~~ >>> >>> The easy way is to go to the web page, which should be self-explanatory: >>> >>> http://www.haskell.org/ghc/ >>> >>> We supply binary builds in the native package format for many >>> platforms, and the source distribution is available from the same >>> place. >>> >>> Packages will appear as they are built - if the package for your >>> system isn't available yet, please try again later. >> >> I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed >> from a pkg). I would like to add ghc-6.10.1 to my system. I tried to >> do this with RC1 of 6.10, but I found that it uninstalled my >> ghc-6.8.3. >> >> What will I need to do to get both 6.8.3 and 6.10.1? > > Are you sure it does deinstall the 6.8 compiler? Or does it just overwrite > the symbolic links in /usr/bin? To check, have a look at > > /Library/Frameworks/GHC.framework/Versions > > After installing 6.10, there should be a 608/ and a 610/ directory. This > certainly happens on my Mac and I am not aware of an option to change that > behaviour. I haven't tried the 6.10.1 install, but after using the 6.8.3 pkg followed by the 6.10 RC1 pkg, followed by the 6.8.3 pkg, I have just 608 in the directory you mention. I guess I should try the 6.10.1 install. If I have to reinstall 6.8.3 again, not the end of the world for me. > And while we are at it...a BIG FAT WARNING: > > If you installed the 6.10.200081007 pre-release installer package, > uninstall that *before* installing the 6.10.1 package. Okay thanks. Although, I don't think that will be a problem for me given the directories I can see. Thanks, Jason From allbery at ece.cmu.edu Tue Nov 4 21:02:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 4 20:57:08 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: On 2008 Nov 4, at 20:26, Jason Dagit wrote: > On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty > wrote: >> Jason Dagit: >>> I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed >>> from a pkg). I would like to add ghc-6.10.1 to my system. I tried >>> to >>> do this with RC1 of 6.10, but I found that it uninstalled my >>> ghc-6.8.3. >>> >>> What will I need to do to get both 6.8.3 and 6.10.1? >> >> Are you sure it does deinstall the 6.8 compiler? Or does it just >> overwrite >> the symbolic links in /usr/bin? To check, have a look at >> >> /Library/Frameworks/GHC.framework/Versions >> >> After installing 6.10, there should be a 608/ and a 610/ >> directory. This >> certainly happens on my Mac and I am not aware of an option to >> change that >> behaviour. > > I haven't tried the 6.10.1 install, but after using the 6.8.3 pkg > followed by the 6.10 RC1 pkg, followed by the 6.8.3 pkg, I have just > 608 in the directory you mention. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From marlowsd at gmail.com Wed Nov 5 04:01:57 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 5 03:56:57 2008 Subject: Control.Exception In-Reply-To: References: <48EB5D21.6040408@imn.htwk-leipzig.de> <48EC6D16.3090308@gmail.com> <490EFB90.7080104@gmail.com> <49102831.5030406@gmail.com> Message-ID: <49116105.6000003@gmail.com> Jason Dagit wrote: > On Tue, Nov 4, 2008 at 2:47 AM, Simon Marlow wrote: >> Jason Dagit wrote: > >>> Thanks. This helps a lot. Mind if I put it somewhere, such as on the >>> wiki? >> A good description of how to deal with exceptions would be great to have in >> the Haddock documentation for Control.Exception - would you (or someone >> else) like to write and submit a patch? Or failing that, just putting it on >> the wiki would be useful too. > > I don't mind submitting a patch. What is the URL of the repo I should download? http://darcs.haskell.org/packages/base and the file is Control/Exception.hs. Cheers, Simon From Christian.Maeder at dfki.de Wed Nov 5 08:16:39 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Nov 5 08:11:31 2008 Subject: extra libraries vs. cabal libraries (ghc-6.10.1) Message-ID: <49119CB7.4060606@dfki.de> Hi, the documentation of extra libraries is listed under share/doc/ghc/libraries/ 1. Is it possible to add cabal packages in the same way? How? 2. It would be nice if the cabal-install (i.e. the binary cabal) came with ghc. Currently zlib, HTTP and cabal-install have to be (awkwardly) installed via Setup before being able to "cabal install". Cheers Christian From igloo at earth.li Wed Nov 5 08:37:45 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 5 08:32:46 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: <20081105133745.GA3649@matrix.chaos.earth.li> On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: > On 2008 Nov 4, at 20:26, Jason Dagit wrote: > >On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty > > wrote: > >> > >>Are you sure it does deinstall the 6.8 compiler? > >> > >>After installing 6.10, there should be a 608/ and a 610/ > >>directory. This > >>certainly happens on my Mac and I am not aware of an option to > >>change that > >>behaviour. > > I expect if you used the OSX installer then /Library/Receipts is > screwing you (it wipes the old files listed in the .bom file). Try > finding and removing the receipt directory and bom file before > installing. The only file I can see that looks relevant is /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom Wouldn't removing it make uninstall impossible? In fact, if you did manage to get 2 versions installed, how would /Library/Frameworks/GHC.framework/Tools/Uninstaller know which version to uninstall? Wouldn't it only know how to uninstall the version it came with? I'd suggest that the overlapping file "Uninstaller" could be why the older version gets removed, but that wouldn't explain why Manuel can install both at once. Thanks Ian From chak at cse.unsw.edu.au Wed Nov 5 20:36:20 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Nov 5 20:31:14 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: <20081105133745.GA3649@matrix.chaos.earth.li> References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> Message-ID: Ian Lynagh: > On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH > wrote: >> On 2008 Nov 4, at 20:26, Jason Dagit wrote: >>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty >>> wrote: >>>> >>>> Are you sure it does deinstall the 6.8 compiler? >>>> >>>> After installing 6.10, there should be a 608/ and a 610/ >>>> directory. This >>>> certainly happens on my Mac and I am not aware of an option to >>>> change that >>>> behaviour. >> >> I expect if you used the OSX installer then /Library/Receipts is >> screwing you (it wipes the old files listed in the .bom file). Try >> finding and removing the receipt directory and bom file before >> installing. > > The only file I can see that looks relevant is > /Library/Receipts/boms/ > org.haskell.glasgowHaskellCompiler.ghc.pkg.bom > > Wouldn't removing it make uninstall impossible? > > In fact, if you did manage to get 2 versions installed, how would > /Library/Frameworks/GHC.framework/Tools/Uninstaller > know which version to uninstall? Wouldn't it only know how to > uninstall > the version it came with? I'd suggest that the overlapping file > "Uninstaller" could be why the older version gets removed, but that > wouldn't explain why Manuel can install both at once. A current limitation of the MacOS package system is that it does not support uninstalling of packages; cf http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ /apple_ref/doc/uid/10000145i-CH6-DontLinkElementID_29 This is not a big drama on MacOS, as MacOS encourages the distribution of software packages as "bundles": http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html This essentially means that instead of sprinkling files all over the file system (as is common in other OSes), MacOS applications and frameworks (Mac-speak for libraries) are kept in a single directory. Uninstalling then means doing an rm -rf on that directory. Unfortunately, some applications (including GHC and Apple's Xcode IDE) can't be entirely contained in a single directory. In the case of GHC, we want symlinks in /usr/bin. The established way of uninstalling such applications is by supplying an Uninstaller script, just as I did for GHC. (Apple does the same for Xcode.) The purpose of the Uninstaller script is too completely remove GHC.framework from a machine - not just to remove one version. In fact, if more than one version of GHC is installed, the Uninstaller will refuse to run and require the manual removal of all versions, but the current (easily achieved by a "rm -rf /Library/Frameworks/ GHC.framework/Versions/"). The main feature of the Uninstaller script is to get rid of all symlinks pointing into GHC.framework. The framework itself is just deleted by a "rm -rf" as expected. (It also removes the above mentioned receipt file.) So, to directly answer the above questions: * The package manger (which uses the receipts) can't uninstall and the uninstaller script doesn't need the receipt. So, even after deleteing the receibt, you can still uninstall. * The Uninstaller can uninstall any version (at least as long as no symlinks are put into new directories outside of the bundle that the Uninstaller doesn't know about). Manuel From duncan.coutts at worc.ox.ac.uk Thu Nov 6 04:36:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 6 04:30:53 2008 Subject: extra libraries vs. cabal libraries (ghc-6.10.1) In-Reply-To: <49119CB7.4060606@dfki.de> References: <49119CB7.4060606@dfki.de> Message-ID: <1225964162.8437.313.camel@localhost> On Wed, 2008-11-05 at 14:16 +0100, Christian Maeder wrote: > Hi, > > the documentation of extra libraries is listed under > share/doc/ghc/libraries/ > > 1. Is it possible to add cabal packages in the same way? How? It is certainly possible to generate documentation but there is no support for automatically updating a central haddock contents page. If you'd like to work on that it's ticket: http://hackage.haskell.org/trac/hackage/ticket/206 > 2. It would be nice if the cabal-install (i.e. the binary cabal) came > with ghc. Currently zlib, HTTP and cabal-install have to be (awkwardly) > installed via Setup before being able to "cabal install". That is part of the purpose of the Haskell Platform. Duncan From marlowsd at gmail.com Thu Nov 6 07:35:53 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 6 07:30:44 2008 Subject: GHC blog Message-ID: <4912E4A9.3060502@gmail.com> I finally got around to creating a GHC blog: http://ghcmutterings.wordpress.com/ This is for all things related to GHC, particularly people working on GHC to blog about what they're up to. If you want a write-bit, sign up for a wordpress account if you don't already have one (http://wordpress.com/), tell me your account name, and blog away! I've asked the planet.haskell.org admins to add us, so we should be on the planet soon. Cheers, Simon From p.k.f.holzenspies at utwente.nl Thu Nov 6 13:09:39 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Thu Nov 6 13:04:29 2008 Subject: No atomic read on MVar? In-Reply-To: <28012bc60811040151n53008cd7x84ff2ffbb79181ed@mail.gmail.com> References: <200811031229.04742.p.k.f.holzenspies@utwente.nl> <49a77b7a0811031451n45fc1a56v2362bdd5fd59031c@mail.gmail.com> <28012bc60811040151n53008cd7x84ff2ffbb79181ed@mail.gmail.com> Message-ID: <200811061909.39949.p.k.f.holzenspies@utwente.nl> L.S., First off, obviously, many thanks for all these usefull replies. A special thanks to Chris. Your e-mail was very insightfull and instructive. I did, in the end, decide to do my own queuing and scheduling using MVar () signaling, guarding MVar a things. I want to avoid IORefs, because for my application, I will later try to move on to distributed memory. Using MVars (or variations thereof, but at least variables with mutexed inter-thread behaviour) should help me when I start distributing threads over processors with segmented memories. Considering that I'm not very well versed in cmm, I can not fully appreciate the implementation impact of having atomic reads. They just seem intuitive. I see them somewhat like the isEmptyMVar, but I see there is a difficulty due to blocking. Essentially, instead of having one single suspended-readers queue - as is currently the case, from what I've understood - there could be a queue for readers (non-destructive and atomic) and for takers (destructive). Whenever something is putMVar'ed into an empty MVar, the read queue is processed first (all waiting threads are handed the newly produced value and woken up), after which the first of the take-queue is woken up and given the value, leaving the MVar empty again. When discussing efficiency in the context of this suggestion, please also consider the memory and concurrency sides of things. Surely, there will be more concurrency (more threads are woken up, because readMVars are queued with higher priority and always awoken), but I have a lingering suspicion that there may also be more sharing (because readMVars are clumped together). I would have to see profiling data on this sharing business, but I imagine quite a few cases where "a value" is good enough and it need not necessarily be "the value that should be in the MVar considering the exact order of arrival of threads at the mutex." My two cents ;) Regards, Philip From camior at gmail.com Thu Nov 6 16:14:49 2008 From: camior at gmail.com (David Sankel) Date: Thu Nov 6 16:09:36 2008 Subject: [Haskell-cafe] ghc-6.11 + OpenGL/GLUT crashes on WinXP In-Reply-To: References: Message-ID: With ghc 6.10.1, the patches aren't necessary for the lasted releases of the bindings. I've put a walkthrough on my blog for the process of getting `freeglut+GLUT binding+GL binding+ghc 6.10.1` up and running. http://netsuperbrain.com/blog/ David On Tue, Oct 28, 2008 at 10:48 AM, David Sankel wrote: > My setup worked: > > - Windows XP. > - ghc-6.11.20081024 > - freeglut 2.4.0 > - darcs version of GLUT (with patched glutGetProcAddress [attached]) > - darcs version of OpenGL > > Getting freeglut going with ghc on windows is a bit involved. I could write > a walkthrough if there's enough interest. > > David > > 2008/10/25 Conal Elliott > >> I'm getting crashes from ghc-6.10.0.20081007 and ghc-6.11.20081024 when >> doing a very simple GLUT program (below) with OpenGL-2.2.1.1 and >> GLUT-2.1.1.2 (the latest from Hackage), running on WinXP. It works fine on >> ghc-6.9.20080622 . >> >> I'd appreciate hearing about other attempts with these versions on Windows >> systems. >> >> Thanks, - Conal >> >> >> import Graphics.UI.GLUT >> >> main :: IO () >> main = do putStrLn "Initializing" >> getArgsAndInitialize >> return () >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081106/e135f858/attachment.htm From conal at conal.net Thu Nov 6 16:46:39 2008 From: conal at conal.net (Conal Elliott) Date: Thu Nov 6 16:41:26 2008 Subject: trouble compiling OpenGL package with ghc 6.10.1 (undefined GLUT_BITMAP_8_BY_13 etc) Message-ID: While building the GLUT package (GLUT-2.1.1.2) with ghc 6.10.1, I get the following errors. I recently compiled this same version successfully in ghc-6.11.20081103. Any idea what's gone wrong? [20 of 21] Compiling Graphics.UI.GLUT.Begin ( Graphics/UI/GLUT/Begin.hs, dist/build/Graphics/UI/GLUT/Begin.o ) [21 of 21] Compiling Graphics.UI.GLUT ( Graphics/UI/GLUT.hs, dist/build/Graphics/UI/GLUT.o ) cbits/HsGLUT.c: In function `hs_GLUT_marshalBitmapFont': cbits/HsGLUT.c:26:0: error: `GLUT_BITMAP_8_BY_13' undeclared (first use in this function) cbits/HsGLUT.c:26:0: error: (Each undeclared identifier is reported only once cbits/HsGLUT.c:26:0: error: for each function it appears in.) cbits/HsGLUT.c:27:0: error: `GLUT_BITMAP_9_BY_15' undeclared (first use in this function) cbits/HsGLUT.c:28:0: error: `GLUT_BITMAP_TIMES_ROMAN_10' undeclared (first use in this function) cbits/HsGLUT.c:29:0: error: `GLUT_BITMAP_TIMES_ROMAN_24' undeclared (first use in this function) cbits/HsGLUT.c:30:0: error: `GLUT_BITMAP_HELVETICA_10' undeclared (first use in this function) cbits/HsGLUT.c:31:0: error: `GLUT_BITMAP_HELVETICA_12' undeclared (first use in this function) cbits/HsGLUT.c:32:0: error: `GLUT_BITMAP_HELVETICA_18' undeclared (first use in this function) cbits/HsGLUT.c: In function `hs_GLUT_marshalStrokeFont': cbits/HsGLUT.c:41:0: error: `GLUT_STROKE_ROMAN' undeclared (first use in this function) cbits/HsGLUT.c:42:0: error: `GLUT_STROKE_MONO_ROMAN' undeclared (first use in this function) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081106/884286b9/attachment.htm From conal at conal.net Thu Nov 6 16:57:12 2008 From: conal at conal.net (Conal Elliott) Date: Thu Nov 6 16:51:57 2008 Subject: trouble compiling OpenGL package with ghc 6.10.1 (undefined GLUT_BITMAP_8_BY_13 etc) In-Reply-To: References: Message-ID: Hm. This problem seems to have gone away on its own. Never mind.... - Conal On Thu, Nov 6, 2008 at 1:46 PM, Conal Elliott wrote: > While building the GLUT package (GLUT-2.1.1.2) with ghc 6.10.1, I get the > following errors. I recently compiled this same version successfully in > ghc-6.11.20081103. > > Any idea what's gone wrong? > > [20 of 21] Compiling Graphics.UI.GLUT.Begin ( > Graphics/UI/GLUT/Begin.hs, dist/build/Graphics/UI/GLUT/Begin.o ) > [21 of 21] Compiling Graphics.UI.GLUT ( Graphics/UI/GLUT.hs, > dist/build/Graphics/UI/GLUT.o ) > cbits/HsGLUT.c: In function `hs_GLUT_marshalBitmapFont': > cbits/HsGLUT.c:26:0: > error: `GLUT_BITMAP_8_BY_13' undeclared (first use in this > function) > cbits/HsGLUT.c:26:0: > error: (Each undeclared identifier is reported only once > cbits/HsGLUT.c:26:0: error: for each function it appears in.) > cbits/HsGLUT.c:27:0: > error: `GLUT_BITMAP_9_BY_15' undeclared (first use in this > function) > cbits/HsGLUT.c:28:0: > error: `GLUT_BITMAP_TIMES_ROMAN_10' undeclared (first use in this > function) > cbits/HsGLUT.c:29:0: > error: `GLUT_BITMAP_TIMES_ROMAN_24' undeclared (first use in this > function) > cbits/HsGLUT.c:30:0: > error: `GLUT_BITMAP_HELVETICA_10' undeclared (first use in this > function) > cbits/HsGLUT.c:31:0: > error: `GLUT_BITMAP_HELVETICA_12' undeclared (first use in this > function) > cbits/HsGLUT.c:32:0: > error: `GLUT_BITMAP_HELVETICA_18' undeclared (first use in this > function) > cbits/HsGLUT.c: In function `hs_GLUT_marshalStrokeFont': > cbits/HsGLUT.c:41:0: > error: `GLUT_STROKE_ROMAN' undeclared (first use in this function) > cbits/HsGLUT.c:42:0: > error: `GLUT_STROKE_MONO_ROMAN' undeclared (first use in this > function) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081106/8f69947f/attachment.htm From duncan.coutts at worc.ox.ac.uk Thu Nov 6 20:06:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 6 20:01:45 2008 Subject: GHC blog In-Reply-To: <4912E4A9.3060502@gmail.com> References: <4912E4A9.3060502@gmail.com> Message-ID: <1226020017.8437.328.camel@localhost> On Thu, 2008-11-06 at 12:35 +0000, Simon Marlow wrote: > I finally got around to creating a GHC blog: > > http://ghcmutterings.wordpress.com/ > > This is for all things related to GHC, particularly people working on GHC > to blog about what they're up to. If you want a write-bit, sign up for a > wordpress account if you don't already have one (http://wordpress.com/), > tell me your account name, and blog away! > > I've asked the planet.haskell.org admins to add us, so we should be on the > planet soon. Yay! Duncan From p.k.f.holzenspies at utwente.nl Fri Nov 7 06:13:04 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?utf-8?q?H=C3=B6lzenspies?=) Date: Fri Nov 7 06:07:51 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? Message-ID: <200811071213.05230.p.k.f.holzenspies@utwente.nl> Dear Ian, all, After the announcement, I downloaded and installed the final release of 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, but I had generally assumed it to be an RC-phenomenon. Which bug? Well... It seems editline has some incompatibility with my terminal. Maybe, I should configure something differently, but any and all of the control characters I type and work for all readline based (and all custom line-readers I have come across), but not for the new ghci. Most annoying is the fact that backspace doesn't work (instead, the control sequence ^? is printed and pressing enter results in "lexical error at character '\DEL'"). However, arrow keys (left ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, ^e, ^a) also give similar errors. It is striking that the lexer does recognize them as the correct characters (printed error messages doe say \DEL, \EOT, \ENQ, etc). I'm using xterm (X.Org 6.8.99.903(229)) on an OpenSuSE 10.3 system and the default termcap settings. Any clues? Is this bug known? Regards, Philip From duncan.coutts at worc.ox.ac.uk Fri Nov 7 07:36:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 7 07:30:55 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <200811071213.05230.p.k.f.holzenspies@utwente.nl> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> Message-ID: <1226061367.8437.335.camel@localhost> On Fri, 2008-11-07 at 12:13 +0100, Philip K.F. H?lzenspies wrote: > It seems editline has some incompatibility with my terminal. Maybe, I should > configure something differently, but any and all of the control characters I > type and work for all readline based (and all custom line-readers I have come > across), but not for the new ghci. Most annoying is the fact that backspace > doesn't work (instead, the control sequence ^? is printed and pressing enter > results in "lexical error at character '\DEL'"). However, arrow keys (left > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, > ^e, ^a) also give similar errors. It is striking that the lexer does > recognize them as the correct characters (printed error messages doe say > \DEL, \EOT, \ENQ, etc). I get some working and some non-working. Eg backspace, del, home, end work, but the ctl-left/ctl-right to jump words does not. Does anyone know how libedit is supposed to be configured? readline uses /etc/inputrc but libedit either does not or doesn't understand all of it. /me wonders if it was really necessary to switch from readline Duncan From jeff.polakow at db.com Fri Nov 7 11:33:33 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Fri Nov 7 11:28:21 2008 Subject: ghc bug? Message-ID: Hello, This compiles fine: foo :: forall b. (b -> String, Int) foo = (const "hi", 0) bar :: (forall b. b -> String, Int) bar = (const "hi", 0) but changing the definition of bar to: bar = foo causes a type error. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081107/b80a602b/attachment.htm From judah.jacobson at gmail.com Fri Nov 7 12:09:50 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 7 12:04:33 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <200811071213.05230.p.k.f.holzenspies@utwente.nl> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> Message-ID: <6d74b0d20811070909h7b397d3bn896c5549e6d34987@mail.gmail.com> On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. H?lzenspies wrote: > Dear Ian, all, > > After the announcement, I downloaded and installed the final release of > 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, > but I had generally assumed it to be an RC-phenomenon. Which bug? Well... > > It seems editline has some incompatibility with my terminal. Maybe, I should > configure something differently, but any and all of the control characters I > type and work for all readline based (and all custom line-readers I have come > across), but not for the new ghci. Most annoying is the fact that backspace > doesn't work (instead, the control sequence ^? is printed and pressing enter > results in "lexical error at character '\DEL'"). However, arrow keys (left > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, > ^e, ^a) also give similar errors. It is striking that the lexer does > recognize them as the correct characters (printed error messages doe say > \DEL, \EOT, \ENQ, etc). > > I'm using xterm (X.Org 6.8.99.903(229)) on an OpenSuSE 10.3 system and the > default termcap settings. Any clues? Is this bug known? > If the arrow keys don't work, it's a good sign that ghc just wasn't built with editline support. To build againt editline, you will probably need to install the libedit-devel package. Hope that helps, -Judah From judah.jacobson at gmail.com Fri Nov 7 12:14:07 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 7 12:08:52 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1226061367.8437.335.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> Message-ID: <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts wrote: > > I get some working and some non-working. Eg backspace, del, home, end > work, but the ctl-left/ctl-right to jump words does not. > > Does anyone know how libedit is supposed to be configured? readline > uses /etc/inputrc but libedit either does not or doesn't understand all > of it. > > /me wonders if it was really necessary to switch from readline > > Duncan You can configure libedit with a ~/.editrc file. http://www.manpagez.com/man/5/editrc/ -Judah From duncan.coutts at worc.ox.ac.uk Fri Nov 7 13:09:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 7 13:03:55 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> Message-ID: <1226081346.8437.370.camel@localhost> On Fri, 2008-11-07 at 09:14 -0800, Judah Jacobson wrote: > On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts > wrote: > > > > I get some working and some non-working. Eg backspace, del, home, end > > work, but the ctl-left/ctl-right to jump words does not. > > > > Does anyone know how libedit is supposed to be configured? readline > > uses /etc/inputrc but libedit either does not or doesn't understand all > > of it. > > > > /me wonders if it was really necessary to switch from readline > > > > Duncan > > You can configure libedit with a ~/.editrc file. > > http://www.manpagez.com/man/5/editrc/ Thanks Judah. To save everyone else having to read the man page and working out through trial and error what the key escape codes are, add the following to your ~/.editrc file. # mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving bind "\e[1;5D" vi-prev-word bind "\e[1;5C" vi-next-word (though from reading the readline /etc/inputrc it suggests that "\e[5C" and "\e[5D" might be right on some systems) It's unfortunate that editline does not seem to support any global /etc/editrc file which would enable distros to make it do the right thing by default like they do for readline. Duncan From dons at galois.com Fri Nov 7 16:02:39 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 7 15:57:27 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1226061367.8437.335.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> Message-ID: <20081107210239.GH5063@scytale.galois.com> duncan.coutts: > On Fri, 2008-11-07 at 12:13 +0100, Philip K.F. H?lzenspies wrote: > > > It seems editline has some incompatibility with my terminal. Maybe, I should > > configure something differently, but any and all of the control characters I > > type and work for all readline based (and all custom line-readers I have come > > across), but not for the new ghci. Most annoying is the fact that backspace > > doesn't work (instead, the control sequence ^? is printed and pressing enter > > results in "lexical error at character '\DEL'"). However, arrow keys (left > > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, > > ^e, ^a) also give similar errors. It is striking that the lexer does > > recognize them as the correct characters (printed error messages doe say > > \DEL, \EOT, \ENQ, etc). > > I get some working and some non-working. Eg backspace, del, home, end > work, but the ctl-left/ctl-right to jump words does not. > > Does anyone know how libedit is supposed to be configured? readline > uses /etc/inputrc but libedit either does not or doesn't understand all > of it. > > /me wonders if it was really necessary to switch from readline I'll note that it is all working find on Arch. The behaviour is indistinguishable to readline. Perhaps the editline package is correctly configured here? -- Don From jeff.polakow at db.com Fri Nov 7 16:52:14 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Fri Nov 7 16:47:04 2008 Subject: ghc bug? In-Reply-To: <6CC5162B-81DC-4763-8430-6B8BA2389BC5@swierstra.net> Message-ID: Hello, > You will be even more surpised to find out that: > > bar = (fst foo, snd foo) > > is considered correct. Does this hint give you any insight? > This tells me that GHC definitely has a bug, or at at best an infelicity. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081107/33031df6/attachment.htm From dons at galois.com Fri Nov 7 18:35:58 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 7 18:30:45 2008 Subject: ghc bug? In-Reply-To: References: <6CC5162B-81DC-4763-8430-6B8BA2389BC5@swierstra.net> Message-ID: <20081107233558.GB5979@scytale.galois.com> jeff.polakow: > Hello, > > You will be even more surpised to find out that: > > > > bar = (fst foo, snd foo) > > > > is considered correct. Does this hint give you any insight? > > > This tells me that GHC definitely has a bug, or at at best an infelicity. > Hey Jeff, File a bug here as guest/guest: http://hackage.haskell.org/trac/ghc/newticket?type=bug Cheers, Don From duncan.coutts at worc.ox.ac.uk Fri Nov 7 18:56:23 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 7 18:51:08 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <20081107210239.GH5063@scytale.galois.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <20081107210239.GH5063@scytale.galois.com> Message-ID: <1226102183.8437.402.camel@localhost> On Fri, 2008-11-07 at 13:02 -0800, Don Stewart wrote: > > Does anyone know how libedit is supposed to be configured? readline > > uses /etc/inputrc but libedit either does not or doesn't understand all > > of it. > > > > /me wonders if it was really necessary to switch from readline > > I'll note that it is all working find on Arch. > The behaviour is indistinguishable to readline. > > Perhaps the editline package is correctly configured here? Does the arch editline package include a config file? /etc/something? Duncan From dons at galois.com Fri Nov 7 19:38:04 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 7 19:32:49 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1226102183.8437.402.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <20081107210239.GH5063@scytale.galois.com> <1226102183.8437.402.camel@localhost> Message-ID: <20081108003804.GI5979@scytale.galois.com> duncan.coutts: > On Fri, 2008-11-07 at 13:02 -0800, Don Stewart wrote: > > > > Does anyone know how libedit is supposed to be configured? readline > > > uses /etc/inputrc but libedit either does not or doesn't understand all > > > of it. > > > > > > /me wonders if it was really necessary to switch from readline > > > > I'll note that it is all working find on Arch. > > The behaviour is indistinguishable to readline. > > > > Perhaps the editline package is correctly configured here? > > Does the arch editline package include a config file? /etc/something? > Hmm... I don't see anything weird configuration-wise, http://www.archlinux.org/packages/extra/x86_64/libedit/ Chasing up the maintainer... -- Don From alexander.dunlap at gmail.com Fri Nov 7 23:38:45 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Fri Nov 7 23:33:27 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <200811071213.05230.p.k.f.holzenspies@utwente.nl> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> Message-ID: <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. H?lzenspies wrote: > Dear Ian, all, > > After the announcement, I downloaded and installed the final release of > 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, > but I had generally assumed it to be an RC-phenomenon. Which bug? Well... > > It seems editline has some incompatibility with my terminal. Maybe, I should > configure something differently, but any and all of the control characters I > type and work for all readline based (and all custom line-readers I have come > across), but not for the new ghci. Most annoying is the fact that backspace > doesn't work (instead, the control sequence ^? is printed and pressing enter > results in "lexical error at character '\DEL'"). However, arrow keys (left > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, > ^e, ^a) also give similar errors. It is striking that the lexer does > recognize them as the correct characters (printed error messages doe say > \DEL, \EOT, \ENQ, etc). > > I'm using xterm (X.Org 6.8.99.903(229)) on an OpenSuSE 10.3 system and the > default termcap settings. Any clues? Is this bug known? > > Regards, > Philip > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Hi all, I apologize if this is off-topic, but I'm having a similar (but distinct) problem: editline thinks that my delete key is a tilde key. When I type , it inserts a tilde. The tilde then acts completely like a tilde (i.e. GHCi interprets it as a tilde). I have been unable to find an answer by googling. Does anyone else have/know how to fix this problem? Thanks, Alex From wchogg at gmail.com Sat Nov 8 11:32:38 2008 From: wchogg at gmail.com (Creighton Hogg) Date: Sat Nov 8 11:27:18 2008 Subject: What causes <>? Message-ID: <814617240811080832m7444f4d5o8acbc6f1cfbe4c26@mail.gmail.com> Hello, So I'm trying to debug an issue that is causing GHC to emit the <> warning. I was hoping to get more information about what exactly that tells me about the kind of problem, other than the obvious interpretation that I appear to be getting into some kind of infinite loop. What is GHC detecting when it emits that warning? Thanks, Creighton From kr.angelov at gmail.com Sat Nov 8 11:47:38 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Sat Nov 8 11:42:18 2008 Subject: What causes <>? In-Reply-To: <814617240811080832m7444f4d5o8acbc6f1cfbe4c26@mail.gmail.com> References: <814617240811080832m7444f4d5o8acbc6f1cfbe4c26@mail.gmail.com> Message-ID: Hi Creighton, This means that the interpreter have detected that your program run into infinite loop. There are many possibilities but one of them (the most often for me) is to have something like: let x = f x because of the lazy evaluation this is possible but leads to infinite loop. It is different from: x := f x that you usually do in imperative languages. Sometimes I also forget to give a new name for x and it results in this kind of infinite loop. Regards, Krasimir On Sat, Nov 8, 2008 at 5:32 PM, Creighton Hogg wrote: > Hello, > So I'm trying to debug an issue that is causing GHC to emit the > <> warning. I was hoping to get more information about what > exactly that tells me about the kind of problem, other than the > obvious interpretation that I appear to be getting into some kind of > infinite loop. What is GHC detecting when it emits that warning? > > Thanks, > Creighton > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From byorgey at seas.upenn.edu Sat Nov 8 12:37:18 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Nov 8 12:31:57 2008 Subject: What causes <>? In-Reply-To: <814617240811080832m7444f4d5o8acbc6f1cfbe4c26@mail.gmail.com> References: <814617240811080832m7444f4d5o8acbc6f1cfbe4c26@mail.gmail.com> Message-ID: <20081108173718.GA10507@seas.upenn.edu> On Sat, Nov 08, 2008 at 10:32:38AM -0600, Creighton Hogg wrote: > Hello, > So I'm trying to debug an issue that is causing GHC to emit the > <> warning. I was hoping to get more information about what > exactly that tells me about the kind of problem, other than the > obvious interpretation that I appear to be getting into some kind of > infinite loop. What is GHC detecting when it emits that warning? In particular, I think when a thunk is being evaluated, it is marked in some way; if during evaluation an already-marked thunk is encountered, a loop exception is raised, since it means that thunk depends on itself. (I'm hand-waving slightly since I don't actually know the details.) Obviously this cannot catch all infinite loops, but it does catch simple ones where no useful work of evaluation can actually take place. -Brent From igloo at earth.li Sat Nov 8 12:43:18 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 8 12:37:59 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <200811071213.05230.p.k.f.holzenspies@utwente.nl> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> Message-ID: <20081108174318.GA22534@matrix.chaos.earth.li> Hi Philip, On Fri, Nov 07, 2008 at 12:13:04PM +0100, Philip K.F. H?lzenspies wrote: > > After the announcement, I downloaded and installed the final release of > 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, > but I had generally assumed it to be an RC-phenomenon. For future reference, the RCs are built in exactly the same way as the releases. So if there's a bug of any kind in an RC, and it's not reported, then the chances are it'll be in the release too. Thanks Ian From antti-juhani at kaijanaho.fi Sat Nov 8 12:50:41 2008 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Sat Nov 8 12:45:22 2008 Subject: What causes <>? In-Reply-To: <814617240811080832m7444f4d5o8acbc6f1cfbe4c26@mail.gmail.com> References: <814617240811080832m7444f4d5o8acbc6f1cfbe4c26@mail.gmail.com> Message-ID: <20081108175041.GA5086@kukkaseppele.kaijanaho.fi> On Sat, Nov 08, 2008 at 10:32:38AM -0600, Creighton Hogg wrote: > So I'm trying to debug an issue that is causing GHC to emit the > <> warning. I was hoping to get more information about what > exactly that tells me about the kind of problem, other than the > obvious interpretation that I appear to be getting into some kind of > infinite loop. What is GHC detecting when it emits that warning? It basically means that you have - somewhere in your program - a recursive definition (of something that's not a function) that refers to itself without going through a data constructor. A safe recursive definition would be let x = Foo (x+1) However, if you leave out the constructor, let x = x + 1 you get a <> (or a deadlock). The reason is, when the value of the definition is demanded, it is computed up to the topmost data constructor (formally, up to "weak head normal form", WHNF). Any recursive reference to that value below that constructor is safe, but if the value itself is needed to compute itself before a constructor is reached, bad things (namely, either <> or a deadlock) happen. The way GHC sometimes detects these situation is that when it starts demanding the value of a variable[1], it first binds that variable to a special tag called a "blackhole". If the evaluation reaches a data constructor without incident, the blackhole is overwritten with that constructor. If, however, evaluation happens to demand the value of a variable that's blackholed, GHC immediately knows that the wrong kind of recursion has happened. Thus, my second example will bomb, since the addition operator finds a blackhole at "x". Of course, in real programs the recursion can be very indirect, and finding the culprit can be hard. [1] More accurately, read "thunk" for "variable" in that paragraph. -- Antti-Juhani Kaijanaho, Jyv?skyl?, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ From judah.jacobson at gmail.com Sat Nov 8 15:33:57 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Nov 8 15:28:37 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> Message-ID: <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> On Fri, Nov 7, 2008 at 8:38 PM, Alexander Dunlap wrote: > On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. H?lzenspies > wrote: > > Hi all, > > I apologize if this is off-topic, but I'm having a similar (but > distinct) problem: editline thinks that my delete key is a tilde key. > When I type , it inserts a tilde. The tilde then acts > completely like a tilde (i.e. GHCi interprets it as a tilde). I have > been unable to find an answer by googling. Does anyone else have/know > how to fix this problem? First, just to make sure: do the arrow keys work or is all editing functionality broken? If it's the latter, then ghc probably wasn't built with libedit and you need the libedit-devel package. Assuming that's not the issue, and you don't get the same problem with readline-based programs, then it sounds like editline doesn't know about the key binding for DELETE on your system. The simplest fix is to edit the ~/.editrc file. For example: Running "ghc -e getLine", then pressing DELETE followed by RETURN, I see: $ ghc -e getLine ^[[3~ "\ESC[3~" This tells me the key sequence for the DELETE key in my terminal, so I add the following line to my ~/.editrc file (http://www.manpagez.com/man/5/editrc/): bind "\e[3~" ed-delete-next-char Hope that helps, -Judah From alexander.dunlap at gmail.com Sat Nov 8 17:35:05 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Nov 8 17:29:43 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> Message-ID: <57526e770811081435o5e35b8c2i662878a2e72d4c1e@mail.gmail.com> On Sat, Nov 8, 2008 at 12:33 PM, Judah Jacobson wrote: > On Fri, Nov 7, 2008 at 8:38 PM, Alexander Dunlap > wrote: >> On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. H?lzenspies >> wrote: >> >> Hi all, >> >> I apologize if this is off-topic, but I'm having a similar (but >> distinct) problem: editline thinks that my delete key is a tilde key. >> When I type , it inserts a tilde. The tilde then acts >> completely like a tilde (i.e. GHCi interprets it as a tilde). I have >> been unable to find an answer by googling. Does anyone else have/know >> how to fix this problem? > > First, just to make sure: do the arrow keys work or is all editing > functionality broken? If it's the latter, then ghc probably wasn't > built with libedit and you need the libedit-devel package. > > Assuming that's not the issue, and you don't get the same problem with > readline-based programs, then it sounds like editline doesn't know > about the key binding for DELETE on your system. The simplest fix is > to edit the ~/.editrc file. For example: > > Running "ghc -e getLine", then pressing DELETE followed by RETURN, I see: > > $ ghc -e getLine > ^[[3~ > "\ESC[3~" > > This tells me the key sequence for the DELETE key in my terminal, so I > add the following line to my ~/.editrc file > (http://www.manpagez.com/man/5/editrc/): > > bind "\e[3~" ed-delete-next-char > > > Hope that helps, > -Judah > Your latter instructions were exactly what I needed. Thank you very much! Alex From igloo at earth.li Sat Nov 8 20:49:43 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 8 20:44:23 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> Message-ID: <20081109014943.GA32495@matrix.chaos.earth.li> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > > bind "\e[3~" ed-delete-next-char It's a shame this doesn't just work out of the box in an xterm, on Debian at least. Perhaps we should consider switching to haskeline? Do we know anything about how portable and complete that is? Thanks Ian From igloo at earth.li Sat Nov 8 20:53:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 8 20:48:02 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <20081109014943.GA32495@matrix.chaos.earth.li> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> Message-ID: <20081109015324.GB32495@matrix.chaos.earth.li> On Sun, Nov 09, 2008 at 01:49:43AM +0000, Ian Lynagh wrote: > On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > > > > bind "\e[3~" ed-delete-next-char > > It's a shame this doesn't just work out of the box in an xterm, on Oh, the other thing I meant to say is that it seems to behaves unexpectedly too. If I type "abc" and press delete, then the "c" is deleted and the cursor is left on (on, not after) the "b". I'd expect the "c" to remain, and the cursor to stay after the "c". Thanks Ian From reiner.pope at gmail.com Sat Nov 8 21:40:28 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Sat Nov 8 21:35:07 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <20081109015324.GB32495@matrix.chaos.earth.li> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <20081109015324.GB32495@matrix.chaos.earth.li> Message-ID: <4cf038ee0811081840ge6c68c7t2a43982b8e821d75@mail.gmail.com> On Sun, Nov 9, 2008 at 12:53 PM, Ian Lynagh wrote: > On Sun, Nov 09, 2008 at 01:49:43AM +0000, Ian Lynagh wrote: >> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: >> > >> > bind "\e[3~" ed-delete-next-char >> >> It's a shame this doesn't just work out of the box in an xterm, on > > Oh, the other thing I meant to say is that it seems to behaves > unexpectedly too. If I type "abc" and press delete, then the "c" is > deleted and the cursor is left on (on, not after) the "b". I'd expect > the "c" to remain, and the cursor to stay after the "c". > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Hi, I'm not sure if this is Emacs' fault, but when I run GHCi through Emacs, entered text is printed to stdout or stderr immediately after Enter is pressed; when this is done after a file is loaded, "^J" is appended. For example >GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help >Loading package ghc-prim ... linking ... done. >Loading package integer ... linking ... done. >Loading package base ... linking ... done. >Prelude> :t id >:t id >id :: a -> a >Prelude> :l Pair.hs >:l Pair.hs >[1 of 1] Compiling Pair ( Pair.hs, interpreted ) >Ok, modules loaded: Pair. >*Pair> :t id >:t id^Jid :: a -> a >*Pair> Note that this happens even without haskell-mode, using just M-x shell. I'm using Ubuntu 8.10, GHC 6.10.1. I symlinked libedit.so.0 to libedit.so.2 as Simon Marlow suggested. It works fine in gnome-terminal, but not in Emacs. Cheers, Reiner From rohan.drape at gmail.com Sat Nov 8 22:13:03 2008 From: rohan.drape at gmail.com (Rohan Drape) Date: Sat Nov 8 22:09:42 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <20081109015324.GB32495@matrix.chaos.earth.li> <4cf038ee0811081840ge6c68c7t2a43982b8e821d75@mail.gmail.com> Message-ID: On 2008-11-09, Reiner Pope wrote: > I'm not sure if this is Emacs' fault, but when I run GHCi through > Emacs, entered text is printed to stdout or stderr immediately after > Enter is pressed; when this is done after a file is loaded, "^J" is > appended. Also here, and there is a further problem with long lines. Emacs sends text to processes in packets of at most 255 characters. In between these ghci now gets a ^D character sequence inserted into the text. This did not happen previously (ie. with 6.8.2). I've edited the emacs mode I use to split long strings into packets before requesting emacs sends them, which has 'solved' the problem here. However it seems unlikely that emacs is doing anything too odd? Regards, Rohan (I doubt this affects many people, the emacs mode I use collapses a region written without layout into a single long line and sends that to ghci for evaluation.) From allbery at ece.cmu.edu Sat Nov 8 22:35:32 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Nov 8 22:30:18 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <20081109015324.GB32495@matrix.chaos.earth.li> <4cf038ee0811081840ge6c68c7t2a43982b8e821d75@mail.gmail.com> Message-ID: <507FE217-D559-4C1A-8CD8-68EA49AC8EA4@ece.cmu.edu> On 2008 Nov 8, at 22:13, Rohan Drape wrote: > Emacs sends text to processes in packets of at most 255 characters. > In between these ghci now gets a ^D character sequence inserted into > the text. This did not happen previously (ie. with 6.8.2). This sounds like a bug: either editline or ghci assumes that when it successfully reads data which lacks a line terminator than it has seen an EOF, so inserts a ^D. But if it received the data at the maximum tty buffer size (255) then there is no trigger character. (This is easy enough to work around: special-case reads of length 255. But in reality, this means something is Doing It Wrong.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From marco-oweber at gmx.de Sun Nov 9 07:45:36 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Nov 9 07:40:15 2008 Subject: Making ghc utilize multiple cpus ? Message-ID: <20081109124536.GB28909@gmx.de> Hi, haskell differs from other languages that it's easy to write parallel programs. So have there been any thoughts about making the ghc compiler compile modules in parallel utilizing multiple cpus yet? Of course you can use Makefiles for that or maybe cabal can be taught to do this. But restarting ghc multiple times wastes resources.. Sincerly Marc Weber From waldmann at imn.htwk-leipzig.de Sun Nov 9 08:55:25 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sun Nov 9 08:54:46 2008 Subject: Making ghc utilize multiple cpus ? References: <20081109124536.GB28909@gmx.de> Message-ID: http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/12926 From duncan.coutts at worc.ox.ac.uk Sun Nov 9 09:42:28 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 9 09:37:09 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <20081109014943.GA32495@matrix.chaos.earth.li> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> Message-ID: <1226241748.11938.34.camel@localhost> On Sun, 2008-11-09 at 01:49 +0000, Ian Lynagh wrote: > On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > > > > bind "\e[3~" ed-delete-next-char > > It's a shame this doesn't just work out of the box in an xterm, on > Debian at least. Perhaps we should consider switching to haskeline? Do > we know anything about how portable and complete that is? If we're considering that I think we should consider bringing back readline as an option and let the people who have problems with gpl code configure in editline support instead. Note that haskeline has a lot of dependencies and requires TemplateHaskell and many other language extensions. Duncan From claus.reinke at talk21.com Sun Nov 9 09:59:55 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Nov 9 09:54:41 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminalincompatibility? References: <200811071213.05230.p.k.f.holzenspies@utwente.nl><57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com><6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com><20081109014943.GA32495@matrix.chaos.earth.li> <1226241748.11938.34.camel@localhost> Message-ID: <04BF4CFEB9BF4DC58B15403905E0BE26@cr3lt> >> It's a shame this doesn't just work out of the box in an xterm, on >> Debian at least. Perhaps we should consider switching to haskeline? Do >> we know anything about how portable and complete that is? If a haskell-based solution could be made to work, that would be great - if you think that editline somehow less nice than readline, consider us poor windows users: we have neither! > Note that haskeline has a lot of dependencies and requires > TemplateHaskell and many other language extensions. Talking about dependencies of cabal packages: - some packages depend on everything and the kitchen-sink, following the "ah, great, here's another package I should use" idea of what it means to provide a modern haskell package. It would be nice if package authors would consider separate minimal and extended dependencies, the former sufficient to enable the package functionality, the latter enabled by a flag, and only needed for testing frameworks, parser re-generation, convenience, performance, .. - since Duncan has put in the work for making meta-packages possible for the Haskell Platform anyway, couldn't that be used to group typical dependencies together (eg, ghc corelibs, old extralibs, haskell platform, testing, ..), to make those dependency lists on hackage somewhat easier to comprehend? Probably, hackage/cabal could offer some support for reducing detailed dependencies to standard dependency groups. Claus From duncan.coutts at worc.ox.ac.uk Sun Nov 9 10:38:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 9 10:33:24 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminalincompatibility? In-Reply-To: <04BF4CFEB9BF4DC58B15403905E0BE26@cr3lt> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <1226241748.11938.34.camel@localhost> <04BF4CFEB9BF4DC58B15403905E0BE26@cr3lt> Message-ID: <1226245124.11938.38.camel@localhost> On Sun, 2008-11-09 at 14:59 +0000, Claus Reinke wrote: > Talking about dependencies of cabal packages: > > - some packages depend on everything and the kitchen-sink, > following the "ah, great, here's another package I should use" > idea of what it means to provide a modern haskell package. > > It would be nice if package authors would consider separate minimal > and extended dependencies, the former sufficient to enable the package > functionality, the latter enabled by a flag, and only needed for testing > frameworks, parser re-generation, convenience, performance, .. That's fine so long as it does not change the external api of a package. > - since Duncan has put in the work for making meta-packages possible > for the Haskell Platform anyway, couldn't that be used to group typical > dependencies together (eg, ghc corelibs, old extralibs, haskell platform, > testing, ..), to make those dependency lists on hackage somewhat > easier to comprehend? > > Probably, hackage/cabal could offer some support for reducing > detailed dependencies to standard dependency groups. Yes, it'd be useful to see what are the "non-standard" deps, ie those outside of the core libs or the platform libs. Duncan From judah.jacobson at gmail.com Sun Nov 9 12:10:10 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Nov 9 12:04:49 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1226241748.11938.34.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <1226241748.11938.34.camel@localhost> Message-ID: <6d74b0d20811090910m2e7d9324o83aa38258ef00130@mail.gmail.com> On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts wrote: > On Sun, 2008-11-09 at 01:49 +0000, Ian Lynagh wrote: >> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: >> > >> > bind "\e[3~" ed-delete-next-char >> >> It's a shame this doesn't just work out of the box in an xterm, on >> Debian at least. Perhaps we should consider switching to haskeline? Do >> we know anything about how portable and complete that is? > > If we're considering that I think we should consider bringing back > readline as an option and let the people who have problems with gpl code > configure in editline support instead. > > Note that haskeline has a lot of dependencies and requires > TemplateHaskell and many other language extensions. I'm also somewhat wary of switching to haskeline in ghc-6.10. I think these issues could be resolved in time for 6.12, though: 1) Completeness: IMHO as the package author, haskeline already has enough features and cross-platform compatibility to warrant its use by ghci. (The full feature-list is at http://trac.haskell.org/haskeline/ .) 2) Language extensions: Since ghci is only ever built in stage 2 (and never by the bootstrapping compiler), the language extensions should not be an issue. The only exception is TemplateHaskell, as Duncan mentioned, since it cannot be used by a stage 1 compiler. But TH is limited to one function in one module and could be easily replaced either by hard-coding the generated code or by using syb. (Some other extensions may also no longer be necessary: I haven't checked recently). 3) Dependencies: Outside of ghc's bootlibs, haskeline depends on mtl and stm (which are extralibs), terminfo (which is only used on POSIX), and utf8-string. - utf8-string should not be needed when unicode text I/O is implemented for ghc-6.12, as mentioned in http://hackage.haskell.org/trac/ghc/wiki/Status/October08 - terminfo is a lightweight binding to a foreign library (ncurses, really) and could either be added to the bootlibs (my preference) or folded into the haskeline package. - stm: I don't see why this couldn't also be a bootlib, although if necessary I can investigate using MVar-based concurrency instead. - mtl: haskeline uses MonadTrans and MonadIO from that package, which ghc reimplements internally. I'm not sure of the right thing to do here. -Judah From dons at galois.com Sun Nov 9 14:03:57 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 9 13:58:41 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <6d74b0d20811090910m2e7d9324o83aa38258ef00130@mail.gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <1226241748.11938.34.camel@localhost> <6d74b0d20811090910m2e7d9324o83aa38258ef00130@mail.gmail.com> Message-ID: <20081109190357.GJ19817@scytale.galois.com> judah.jacobson: > On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts > wrote: > > On Sun, 2008-11-09 at 01:49 +0000, Ian Lynagh wrote: > >> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > >> > > >> > bind "\e[3~" ed-delete-next-char > >> > >> It's a shame this doesn't just work out of the box in an xterm, on > >> Debian at least. Perhaps we should consider switching to haskeline? Do > >> we know anything about how portable and complete that is? > > > > If we're considering that I think we should consider bringing back > > readline as an option and let the people who have problems with gpl code > > configure in editline support instead. > > > > Note that haskeline has a lot of dependencies and requires > > TemplateHaskell and many other language extensions. > > I'm also somewhat wary of switching to haskeline in ghc-6.10. I think > these issues could be resolved in time for 6.12, though: haskeline needs /way/ too many extensions for a simple console reader... From kyagrd at gmail.com Mon Nov 10 00:16:09 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Mon Nov 10 00:29:43 2008 Subject: How to getCh on MS Windows command line? Message-ID: What I mean by getCh is the non-buffered non-echoed version of getChar, which Hugs used to provided as an extension but not any more. Is there any way to have a non-buffered non-echoed single character input function on MS Windows command line using only the libraries in the MS Windows distribution packages of either GHC or Hugs? The reason to why this is important for me is because I am translating Graham Hutton's "Programming in Haskell" into Korean (soon to be published), which illustrates interactive programming with the example of a calculator that responds instantly for every keystroke of numbers and arithmetic operations running on text mode. It is very important to consider the readers who only have access to MS Windows systems, because Korean OS market share is completely skewed towards MS Windows for very embarrassing reasons that I do not even want to mention. And, isn't GHC developed in MSR anyway? :-) I remember that this is an old problem for both of the two most widely used Haskell implementation, Hugs and GHC. In ghc 6.8 getChar had a bit strange behavior. As far as I remember it always worked as if it were NoBuffering. Fortunately, in the recently released ghc 6.10, this has been fixed. We now actually have to set the buffering mode to NoBuffering with hSetBufferring to get the non-buffered behavior of getChar. But, it still isn't working on MS Windows. In Hugs, hSetBuffering neither works on Unix terminal nor on MS Windows command line. Surprisingly, it works in WinHugs. However, I cannot use WinHugs for my purpose because the interactive calculator example in the book also uses beep characters and ANSI codes which do not work in WinHugs. Thanks for any hacks or suggestions, -- Ahn, Ki Yung From bulat.ziganshin at gmail.com Mon Nov 10 01:55:42 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 10 01:50:39 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: References: Message-ID: <1726166656.20081110095542@gmail.com> ??o ?, ???, ???? ?, ??, ???9 ?, ?u ??? > ?? I ?? ? ??h ? ?e ?????? ????? ???n ? ???? > ??h ?? ?? ? ???? ? ? ????n ?t ?t ?y ??. ? ??s ?r ? ? ?? ??????r = ??M ??.????) ???h ???n ??? ??l ??? ???.h ??? ???h ? IO ?? ? ???????? ??n ?????g ?t ??? ? ?e ????. i ????? ???? ?? i ?d ??? ?u ?? ?? ?? ???? ? ?s ?? ?? ?? ???? ?t i ??t ???r ???s ? ??e ?? ?'s ?t ?? ?? ? ???l ?? ??? ???, ?t ?????? ??x ??e ?d ???l ??/?c ??e -- ?? ???? ??t ??????.?????????m From Christian.Maeder at dfki.de Mon Nov 10 07:24:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Nov 10 07:19:19 2008 Subject: editline in ghc-6.10.1 under Solaris Message-ID: <4918280C.3000607@dfki.de> Hallo Judah, I've build http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz and it was linked against libcurses: -bash-3.1$ ldd /usr/local/lib/libedit.so.0 libcurses.so.1 => /lib/libcurses.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/local/lang/lib/gcc/i386-pc-solaris2.10/4.2.2/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2 When building ghc-6.10.1 your configure script prefers ncurses over curses, therefore I get an additional dependency for ghc: libncurses.so.5 => /usr/local/lib/libncurses.so.5 For (the usual) dynamic linking just "-ledit" is enough, only for static linking "-lcurses" or "-lncurses" is needed, otherwise "term.o" is the "Undefined symbol". (By chance, I've only libncurses.a and no libcurses.a for static linking.) I'm not sure which dependency to prefer. configure of libedit-20080712-2.1 prefers curses over ncurses. Cheers Christian P.S. While relinking the stage2 compiler I'll noticed that also haddock depends on libedit which I think should be avoided (by splitting the ghc package)! Which other ghc-6.10.1 binaries depend on libedit? P.P.S My PC binary distribution is here: http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.10.1-i386-unknown-solaris2.tar.bz2 I did not succeed to build ghc-6.10.1 for a Sparc http://hackage.haskell.org/trac/ghc/ticket/2692 From marlowsd at gmail.com Mon Nov 10 09:09:00 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 10 09:03:43 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: <1726166656.20081110095542@gmail.com> References: <1726166656.20081110095542@gmail.com> Message-ID: <4918407C.9090104@gmail.com> Bulat Ziganshin wrote: > ??o ?, > > ???, ???? ?, ??, ???9 ?, ?u ??? Please stick to English on this list, thanks. Simon From marlowsd at gmail.com Mon Nov 10 09:11:58 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 10 09:06:35 2008 Subject: How to getCh on MS Windows command line? In-Reply-To: References: Message-ID: <4918412E.6070303@gmail.com> Ahn, Ki Yung wrote: > What I mean by getCh is the non-buffered non-echoed version of getChar, > which Hugs used to provided as an extension but not any more. > > Is there any way to have a non-buffered non-echoed single character > input function on MS Windows command line using only the libraries in > the MS Windows distribution packages of either GHC or Hugs? > > The reason to why this is important for me is because I am translating > Graham Hutton's "Programming in Haskell" into Korean (soon to be > published), which illustrates interactive programming with the example > of a calculator that responds instantly for every keystroke of numbers > and arithmetic operations running on text mode. It is very important to > consider the readers who only have access to MS Windows systems, because > Korean OS market share is completely skewed towards MS Windows for very > embarrassing reasons that I do not even want to mention. And, isn't GHC > developed in MSR anyway? :-) > > > I remember that this is an old problem for both of the two most widely > used Haskell implementation, Hugs and GHC. > > In ghc 6.8 getChar had a bit strange behavior. As far as I remember it > always worked as if it were NoBuffering. Fortunately, in the recently > released ghc 6.10, this has been fixed. We now actually have to set the > buffering mode to NoBuffering with hSetBufferring to get the > non-buffered behavior of getChar. But, it still isn't working on MS > Windows. Here's the ticket: http://hackage.haskell.org/trac/ghc/ticket/2189 This needs somebody familiar with the intricacies of Windows Consoles to fix. Any takers? Cheers, Simon From Alistair.Bayley at invesco.com Mon Nov 10 09:27:25 2008 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Mon Nov 10 09:22:19 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: <4918407C.9090104@gmail.com> References: <1726166656.20081110095542@gmail.com> <4918407C.9090104@gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E96AE@GBLONXMB02.corp.amvescap.net> > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Simon Marlow > > Bulat Ziganshin wrote: > > ??o ?, > > > > ???, ???? ?, ??, ???9 ?, ?u ??? > > Please stick to English on this list, thanks. > > Simon Actualy it was english, it's just that the encoding was wrong. In Outlook I manually changed the encoding to US-ASCII, and got the message below. I'm not sure why other 8-bit encoding options failed (like Western Europen (ISO). Alistair Hello Ki, Monday, November 10, 2008, 8:16:09 AM, you wrote: > What I mean by getCh is the non-buffered non-echoed version of getChar, > which Hugs used to provided as an extension but not any more. 1. works for me in ghc: getHiddenChar = liftM (chr.fromEnum) c_getch foreign import ccall unsafe "conio.h getch" c_getch :: IO CInt 2. setBufferingMode stdin NoBuffering not tested 3. use interact. i definitely remember that i had effect you need this way. probably it was with some hugs version, but i don't remeber details 4. these days it's not very hard to install free VMWare Player, get preinstalled linux image and install hugs/ghc there -- Best regards, Bulat ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From matti.niemenmaa+news at iki.fi Mon Nov 10 12:48:04 2008 From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa) Date: Mon Nov 10 12:42:51 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E96AE@GBLONXMB02.corp.amvescap.net> References: <1726166656.20081110095542@gmail.com> <4918407C.9090104@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E96AE@GBLONXMB02.corp.amvescap.net> Message-ID: Bulat Ziganshin wrote: > 1. works for me in ghc: > > getHiddenChar = liftM (chr.fromEnum) c_getch > foreign import ccall unsafe "conio.h getch" > c_getch :: IO CInt Depending on your use case, that's an okay workaround. (And probably suitable for the OP as well.) But unfortunately conio doesn't mix well with ordinary IO. For one, it always reads from the console and not stdin, so redirecting stdin won't work. Another problem is illustrated in the following: main = do a <- getChar b <- getHiddenChar c <- getChar print a print b print c Type a, then press enter, then b. The result (including the echoed input): a 'a' 'b' '\n' I don't know where that '\n' came from but it certainly shouldn't be there. Yet another example: type abcd, then press enter, giving: abcd 'a' '\r' 'b' The fact that newlines are reported as '\r' and not '\n' is easy enough to deal with, but I wonder why getch chose to give '\r' and not 'b'? From judah.jacobson at gmail.com Mon Nov 10 13:39:42 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Nov 10 13:34:18 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <20081109190357.GJ19817@scytale.galois.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <1226241748.11938.34.camel@localhost> <6d74b0d20811090910m2e7d9324o83aa38258ef00130@mail.gmail.com> <20081109190357.GJ19817@scytale.galois.com> Message-ID: <6d74b0d20811101039g16d7e331j14d164a74c8ed431@mail.gmail.com> On Sun, Nov 9, 2008 at 11:03 AM, Don Stewart wrote: > judah.jacobson: >> > >> > Note that haskeline has a lot of dependencies and requires >> > TemplateHaskell and many other language extensions. >> >> I'm also somewhat wary of switching to haskeline in ghc-6.10. I think >> these issues could be resolved in time for 6.12, though: > > haskeline needs /way/ too many extensions for a simple console reader... Well, even though the external API of a line reader may look simple, under the hood there can be a lot going on, both in the user interface (e.g. user preferences, multiple key bindings, history recall/search, undo/redo, tab completion) and backend (e.g. redraw efficiently, cross-platform compatibility). Using a stack of monad transformers to encapsulate the state and settings helped make the code much more modular, understandable and concise, but also required several type extensions to work the way I wanted (MultiParamTypeClasses, OverlappingInstances, FlexibleContexts, etc.). I felt the tradeoff was worth it when originally writing the code, but patches or suggestions are, of course, welcome :-) (Incidentally, the .cabal file in haskeline-3.2 erroneously lists GADTs and FunDeps which are not actually required; those extensions will be removed for the next release.) Best, -Judah From jeff.polakow at db.com Mon Nov 10 14:39:18 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Mon Nov 10 14:33:56 2008 Subject: impredicative type checking Message-ID: Hello, I filed the following bug report: This produces a type error: foo :: forall b. (b -> String, Int) foo = (const "hi", 0) bar :: (forall b. b -> String, Int) bar = foo But the types are equivalent. The ticket was closed with a comment that the types are not equivalent. However, I don't see how they are not equivalent (in the presence of impredicative polymorphism) since I can write derivations for both forall b. (b -> String /\ Int) |- (forall b. b -> String) /\ Int and (forall b. b -> String) /\ Int |- forall b. (b -> String /\ Int) in intuitionistic logic. The counter example given on the bug tracker is: foo :: forall b. (b -> String, Int) foo = undefined x :: (String, String) x = case foo of (f, _) -> (f 'a', f True) which fails to type check where the other type signature would allow it to check. However, with impredicative polymorphism, this should type check. Perhaps it is too much to ask the inference engine to infer the type of f above. However, in the original code sample, there is no type inference necessary; it is just necessary to check if the two types unify, which they should given the standard interpretation of forall. Am I missing something here? -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081110/f3d0c25c/attachment.htm From igloo at earth.li Mon Nov 10 16:35:20 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Nov 10 16:29:54 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <6d74b0d20811101039g16d7e331j14d164a74c8ed431@mail.gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <57526e770811072038k6d1aac51g7c16c0b84ad93077@mail.gmail.com> <6d74b0d20811081233u8261b75t942aadbb16d11e55@mail.gmail.com> <20081109014943.GA32495@matrix.chaos.earth.li> <1226241748.11938.34.camel@localhost> <6d74b0d20811090910m2e7d9324o83aa38258ef00130@mail.gmail.com> <20081109190357.GJ19817@scytale.galois.com> <6d74b0d20811101039g16d7e331j14d164a74c8ed431@mail.gmail.com> Message-ID: <20081110213520.GA28043@matrix.chaos.earth.li> On Mon, Nov 10, 2008 at 10:39:42AM -0800, Judah Jacobson wrote: > On Sun, Nov 9, 2008 at 11:03 AM, Don Stewart wrote: > > judah.jacobson: > >> > > >> > Note that haskeline has a lot of dependencies and requires > >> > TemplateHaskell and many other language extensions. > >> > >> I'm also somewhat wary of switching to haskeline in ghc-6.10. I think > >> these issues could be resolved in time for 6.12, though: > > > > haskeline needs /way/ too many extensions for a simple console reader... > > Well, even though the external API of a line reader may look simple, > under the hood there can be a lot going on I don't think extensions are an issue for ghci, except for TH (which you say can be replaced). They doesn't even cause extra problems for bootstrapping with other Haskell impls, as it's stage >= 2 only. Extra package dependencies are a pain, but aren't the end of the world. The big thing, in my opinion, is portability - not in the sense of the code compiling, but in the sense of "will the arrow keys Just Work if I run ghci in, say, an rxvt on a Solaris machine"? Although it seems like editline fails this anyway, even for the common case of xterm/Linux. Haskell code would also cause fewer build system headaches than linking to a C library. Thanks Ian From kyagrd at gmail.com Mon Nov 10 20:04:11 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Mon Nov 10 19:58:35 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: References: <1726166656.20081110095542@gmail.com> <4918407C.9090104@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E96AE@GBLONXMB02.corp.amvescap.net> Message-ID: <4918DA0B.2040003@gmail.com> Matti Niemenmaa ? ?: > Bulat Ziganshin wrote: >> 1. works for me in ghc: >> >> getHiddenChar = liftM (chr.fromEnum) c_getch >> foreign import ccall unsafe "conio.h getch" >> c_getch :: IO CInt Thanks to Bulat, Bayley, and Matti for suggestions and discussions. At least for my purpose of running the particular example I had "conio.h getch" is good enough because the entire example only depends on the getCh for its input. I defined getCh as follows and it seems to works OK on windows cmd. \begin{code} {-# LANGUAGE ForeignFunctionInterface#-} import Monad import Char import Foreign.C getCh = liftM (chr . fromEnum) c_getch foreign import ccall "conio.h getch" c_getch :: IO CInt \end{code} Just want to make a comment that this "conio.h getch" will only work on windows cmd but not on linux terminals. Both on ghc 6.8.2 and ghc 6.10.1 throws an error when I try to do getCh kyagrd@kyagrd:~/MyDoc$ ghci-6.8.2 Main GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Main. *Main> getCh *** Exception: Prelude.chr: bad argument I hope we can have more portable way of handling command line buffering in the future releases GHC. Thanks, for you all again. > Depending on your use case, that's an okay workaround. (And probably suitable > for the OP as well.) > > But unfortunately conio doesn't mix well with ordinary IO. For one, it always > reads from the console and not stdin, so redirecting stdin won't work. Another > problem is illustrated in the following: > > main = do > a <- getChar > b <- getHiddenChar > c <- getChar > print a > print b > print c > > Type a, then press enter, then b. The result (including the echoed input): > > a > 'a' > 'b' > '\n' > > I don't know where that '\n' came from but it certainly shouldn't be there. > > Yet another example: type abcd, then press enter, giving: > > abcd > 'a' > '\r' > 'b' > > The fact that newlines are reported as '\r' and not '\n' is easy enough to deal > with, but I wonder why getch chose to give '\r' and not 'b'? From bulat.ziganshin at gmail.com Tue Nov 11 05:50:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 11 05:45:06 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: <4918DA0B.2040003@gmail.com> References: <1726166656.20081110095542@gmail.com> <4918407C.9090104@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E96AE@GBLONXMB02.corp.amvescap.net> <4918DA0B.2040003@gmail.com> Message-ID: <1561013709.20081111135021@gmail.com> Hello Ki, Tuesday, November 11, 2008, 4:04:11 AM, you wrote: i have also linux getCh if you need it, although afaik it's not perfect and actually you should use something inside Unix package -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From haskell at list.mightyreason.com Tue Nov 11 05:50:51 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Nov 11 05:45:24 2008 Subject: impredicative type checking In-Reply-To: References: Message-ID: <4919638B.5070000@list.mightyreason.com> Jeff Polakow wrote: > > Hello, > > I filed the following bug report: > > This produces a type error: > > foo :: forall b. (b -> String, Int) > foo = (const "hi", 0) > > bar :: (forall b. b -> String, Int) > bar = foo > > But the types are equivalent. Once you cross the forall the type of b becomes fixed. case foo of (f,i) -> {- Here f is monomorphic :: b -> String -} case bar of (f,i) -> {- Here f is still polymorphic :: forall b. b -> String -} Think of how you would seal these with a newtype: newtype Foo = forall a. Foo (a -> String, Int) newtype F = forall a. F (a -> String) type Bar = (F,Int) From haskell at list.mightyreason.com Tue Nov 11 05:55:43 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Nov 11 05:50:16 2008 Subject: GHC on powerpc (OS X): segmentation fault Message-ID: <491964AF.5080607@list.mightyreason.com> I am having trouble compiling GHC using mac ports on powerpc OS X (10.5.5) (using XCode 3.1). I have also opened a ticket at http://trac.macports.org/ticket/17184 which has the full build log attached. The build starts with > nice port -c upgrade ghc > ---> Staging gmp into destroot > ---> Packaging tgz archive for gmp 4.2.4_0 > ---> Deactivating gmp 4.2.3_0 > ---> Installing gmp 4.2.4_0 > ---> Activating gmp 4.2.4_0 > ---> Cleaning gmp > ---> Fetching ghc > ---> Attempting to fetch ghc-6.10.1-src.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.10.1-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.8.2-darwin-ppc-leopard-bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ > ---> Verifying checksum(s) for ghc > ---> Extracting ghc > ---> Applying patches to ghc > ---> Configuring ghc > ---> Building ghc with target all > Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1 && env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 > Command output: /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c parallel/GranSim.c -o parallel/GranSim.o Eventually the build fails with > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c sm/Sweep.c -o sm/Sweep.o > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o > make[1]: *** [Apply.o] Segmentation fault > make: *** [stage1] Error 2 Does anyone have a clue how to proceed? From jules at jellybean.co.uk Tue Nov 11 06:16:31 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Nov 11 06:11:05 2008 Subject: impredicative type checking In-Reply-To: References: Message-ID: <4919698F.9080302@jellybean.co.uk> Jeff Polakow wrote: > However, I don't see > how they are not equivalent (in the presence of impredicative > polymorphism) since I can write > derivations for both > > forall b. (b -> String /\ Int) |- (forall b. b -> String) /\ Int > > and > > (forall b. b -> String) /\ Int |- forall b. (b -> String /\ Int) > > in intuitionistic logic. (Side-stepping your main point, rather, which I think Chris K answered correctly) This is a non-sequitur. The fact that A |- B and B |- A does not make them the same type. It makes them isomorphic types. I can prove (A \/ B) /\ C -| |- (A /\ C) \/ (B /\ C) but that doesn't mean "(Either a b,c)" and "Either (a,c) (b,c)" are the same haskell type. It does mean they are isomorphic types, neglecting bottoms. But isomorphic types are not the same type, for the type checker! Jules From Christian.Maeder at dfki.de Tue Nov 11 06:20:20 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Nov 11 06:14:50 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <491964AF.5080607@list.mightyreason.com> References: <491964AF.5080607@list.mightyreason.com> Message-ID: <49196A74.3030009@dfki.de> I can offer a Tiger PPC built that works for me: http://www.dfki.de/sks/hets/intel-mac/ghcs/ghc-6.10.1-i386-apple-darwin.tar.bz2 (linked against /opt/local/lib/libgmp.dylib) Cheers Christian Chris Kuklewicz wrote: > I am having trouble compiling GHC using mac ports on powerpc OS X > (10.5.5) (using XCode 3.1). > > I have also opened a ticket at http://trac.macports.org/ticket/17184 > which has the full build log attached. > > The build starts with > >> nice port -c upgrade ghc >> ---> Staging gmp into destroot >> ---> Packaging tgz archive for gmp 4.2.4_0 >> ---> Deactivating gmp 4.2.3_0 >> ---> Installing gmp 4.2.4_0 >> ---> Activating gmp 4.2.4_0 >> ---> Cleaning gmp >> ---> Fetching ghc >> ---> Attempting to fetch ghc-6.10.1-src.tar.bz2 from >> http://haskell.org/ghc/dist/stable/dist/ >> ---> Attempting to fetch ghc-6.10.1-src-extralibs.tar.bz2 from >> http://haskell.org/ghc/dist/stable/dist/ >> ---> Attempting to fetch >> ghc-6.8.2-darwin-ppc-leopard-bootstrap.tar.bz2 from >> http://haskell.org/ghc/dist/6.8.2/ >> ---> Verifying checksum(s) for ghc >> ---> Extracting ghc >> ---> Applying patches to ghc >> ---> Configuring ghc >> ---> Building ghc with target all >> Error: Target org.macports.build returned: shell command "cd >> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1 >> && env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 >> Command output: >> /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc >> -optc-O -optc-I/opt/local/include -optc-Wall -optc-W >> -optc-Wstrict-prototypes -optc-Wmissing-prototypes >> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return >> -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism >> -optc-DCOMPILING_RTS -optc-fomit-frame-pointer >> -optc-I/opt/local/include -optc-I../gmp/gmpbuild >> -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O >> -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. >> -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static >> -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. >> -dcmm-lint -c parallel/GranSim.c -o parallel/Gr > anSim.o > > > Eventually the build fails with > >> /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc >> -optc-O -optc-I/opt/local/include -optc-Wall -optc-W >> -optc-Wstrict-prototypes -optc-Wmissing-prototypes >> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return >> -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism >> -optc-DCOMPILING_RTS -optc-fomit-frame-pointer >> -optc-I/opt/local/include -optc-I../gmp/gmpbuild >> -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O >> -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. >> -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static >> -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. >> -dcmm-lint -c sm/Sweep.c -o sm/Sweep.o > >> /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc >> -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes >> -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static >> -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. >> -dcmm-lint -c Apply.cmm -o Apply.o > >> make[1]: *** [Apply.o] Segmentation fault > >> make: *** [stage1] Error 2 > > Does anyone have a clue how to proceed? From haskell at list.mightyreason.com Tue Nov 11 06:50:48 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Nov 11 06:45:20 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <49196A74.3030009@dfki.de> References: <491964AF.5080607@list.mightyreason.com> <49196A74.3030009@dfki.de> Message-ID: <49197198.8000500@list.mightyreason.com> Christian Maeder wrote: > I can offer a Tiger PPC built that works for me: > http://www.dfki.de/sks/hets/intel-mac/ghcs/ghc-6.10.1-i386-apple-darwin.tar.bz2 > (linked against /opt/local/lib/libgmp.dylib) > > Cheers Christian > But the filename says "-i386-" so I suspect it is not a powerpc build. Regards, Chris From Christian.Maeder at dfki.de Tue Nov 11 07:19:25 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Nov 11 07:13:53 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <49197198.8000500@list.mightyreason.com> References: <491964AF.5080607@list.mightyreason.com> <49196A74.3030009@dfki.de> <49197198.8000500@list.mightyreason.com> Message-ID: <4919784D.3090601@dfki.de> Chris Kuklewicz wrote: > Christian Maeder wrote: >> I can offer a Tiger PPC built that works for me: >> (linked against /opt/local/lib/libgmp.dylib) >> > > But the filename says "-i386-" so I suspect it is not a powerpc build. Sorry, the link is: http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 Christian From dermiste at gmail.com Tue Nov 11 12:38:02 2008 From: dermiste at gmail.com (dermiste) Date: Tue Nov 11 12:32:33 2008 Subject: Linking error during stage2 Message-ID: Hi, I've successfully built GHC-6.10.1 from 6.6.1 on OpenBSD 4.4, and would like now to generate a hc-file-bundle to build it without pre-existing GHC. I followed the instructions in [1], but I'm stuck with this error : [....] gmake[2]: Leaving directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/ghc' gmake[1]: Leaving directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/compiler' gmake -C utils with-stage-2 gmake[1]: Entering directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils' gmake -C installPackage with-stage-2 gmake[2]: Entering directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils/installPackage' /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/cabal-bin /usr/local/bin/ghc /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref dist-install \ --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \ --with-compiler=/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/ghc/stage2-inplace/ghc --with-hc-pkg=/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils/ghc-pkg/install-inplace/bin/ghc-pkg --package-db /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/stage3.package.conf \ --libsubdir='$pkgid' --with-gcc=gcc --with-ld=/usr/bin/ld --hsc2hs-option=-I/usr/local/include --configure-option='--with-gmp-includes=/usr/local/include' --configure-option='--with-gmp-libraries=/usr/local/lib' --configure-option=--with-cc=gcc --with-hsc2hs=/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils/hsc2hs/install-inplace/bin/hsc2hs \ --constraint="Cabal == 1.6.0.1" Configuring installPackage-1.0... /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/cabal-bin /usr/local/bin/ghc /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/bootstrapping.conf build --distpref dist-install --ghc-option=-H32m --ghc-option=-O --ghc-option=-fvia-C --ghc-option=-Rghc-timing --ghc-option=-keep-hc-file --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... Linking dist-install/build/installPackage/installPackage ... /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(Semaphore.o)(.text+0xac): In function `unixzm2zi3zi1zi0_SystemziPosixziSemaphore_zdwa_info': : undefined reference to `sem_trywait' {... five more like that ...} /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(Semaphore.o)(.text+0x17a4): In function `s29I_info': : undefined reference to `sem_unlink' collect2: ld returned 1 exit status <> Obviously, the linker skips entirely /usr/lib/libpthread.a, as all the symbols defined in are into it. But its behaviour is slightly inconsistent, as I had no problem building the stage2 commenting SplitObjs in mk/build.mk some more data : I'm compiling this with the aforementioned GHC-6.10.1 bootstrapped from GHC-6.6.1. Clues anyone ? [1] http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform -- Vincent Gross "So, the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." -- Jerome Simeon & Phil Wadler From kili at outback.escape.de Tue Nov 11 17:07:15 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Nov 11 17:04:35 2008 Subject: Linking error during stage2 In-Reply-To: References: Message-ID: <20081111220715.GD4554@petunia.outback.escape.de> On Tue, Nov 11, 2008 at 06:38:02PM +0100, dermiste wrote: > I've successfully built GHC-6.10.1 from 6.6.1 on OpenBSD 4.4, and > would like now to generate a hc-file-bundle to build it without > pre-existing GHC. I followed the instructions in [1], but I'm stuck > with this error : > Linking dist-install/build/installPackage/installPackage ... > /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(Semaphore.o)(.text+0xac): > In function `unixzm2zi3zi1zi0_SystemziPosixziSemaphore_zdwa_info': > : undefined reference to `sem_trywait' [...] > Obviously, the linker skips entirely /usr/lib/libpthread.a, as all the > symbols defined in are into it. A quick hack I used for my work on ghc-6.8: just disable System.Posix.Semaphore. --- libraries/unix/System/Posix.hs.orig Sat May 3 19:25:32 2008 +++ libraries/unix/System/Posix.hs Sun May 18 14:37:13 2008 @@ -26,7 +26,6 @@ module System.Posix ( module System.Posix.Time, module System.Posix.User, module System.Posix.Resource, - module System.Posix.Semaphore, module System.Posix.SharedMem ) where @@ -43,7 +42,6 @@ import System.Posix.Terminal import System.Posix.Time import System.Posix.User import System.Posix.Resource -import System.Posix.Semaphore import System.Posix.SharedMem {- TODO --- libraries/unix/unix.cabal.orig Sat May 3 19:25:32 2008 +++ libraries/unix/unix.cabal Sun May 18 13:44:08 2008 @@ -32,7 +32,6 @@ exposed-modules: System.Posix.User System.Posix.Signals System.Posix.Signals.Exts - System.Posix.Semaphore System.Posix.SharedMem extra-source-files: configure.ac configure It's not a proper solution, but it may help for getting the build a little bit farther (and OpenBSD doesn't support sem_open(3) anyway). Ciao, Kili -- It's a Barrier Of Entry issue: if you can't figure out which floppy to boot from, go run Gentoo. -- Matthew Jenove on tech@openbsd.org From conal at conal.net Tue Nov 11 19:41:31 2008 From: conal at conal.net (Conal Elliott) Date: Tue Nov 11 19:36:01 2008 Subject: problem with echo prompting in ghci (visible in emacs) Message-ID: ghci echoes all of my input in emacs, when run via haskell-mode or via "M-x shell", which then confuses various useful haskell-mode features. I built it from sources. At the time I didn't have libedit-dev, so today I installed libedit-dev (version 2.11~20080614 on ubuntu), did a clean make & install, and I get exactly the same behavior. Does anyone have experience in getting through this problem? Willing to help me out? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081111/fed2abff/attachment.htm From sanzhiyan at gmail.com Tue Nov 11 20:00:47 2008 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Tue Nov 11 19:55:17 2008 Subject: problem with echo prompting in ghci (visible in emacs) Message-ID: <8625cd9c0811111700q1db4e3e8j9622e39660a0c041@mail.gmail.com> I get the same behaviour, and when I open ghci in xterm and press Ctrl-D it also echoes ^D before quitting, which is similar to the problem with haskell-mode which seems to don't like the echoing of ^J from ghci when one uses commands like C-u C-c C-t (which should copy the inferred type from the ghci buffer and insert it in the current file). I'm using the ghc package from archlinux testing repository, which is built with libedit 20080712_2.11. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081112/2de959b2/attachment-0001.htm From jason.dusek at gmail.com Tue Nov 11 20:04:25 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Nov 11 19:58:54 2008 Subject: how is Linux GHC formed? Message-ID: <42784f260811111704y4a7086b5g6eaecfe049046b25@mail.gmail.com> How was the Linux binary for GHC created? I am looking at ways to compile Haskell binaries for Linux that work across distros. So far, I have been using `-static -optl-static` but today there was a weird hiccup with IO -- the Gentoo built binary worked fine on Gentoo but caught SIGPIPE intermittently on Ubuntu -- and so it's back to the drawing board. The GHC linux binary seems to work on all the Linii without discrimination, so I'd like to know what the procedure is for producing it, and what I can take away from that to put in my Cabal file. -- _jsn From reiner.pope at gmail.com Tue Nov 11 20:55:22 2008 From: reiner.pope at gmail.com (Reiner Pope) Date: Tue Nov 11 20:49:51 2008 Subject: problem with echo prompting in ghci (visible in emacs) In-Reply-To: <8625cd9c0811111700q1db4e3e8j9622e39660a0c041@mail.gmail.com> References: <8625cd9c0811111700q1db4e3e8j9622e39660a0c041@mail.gmail.com> Message-ID: <4cf038ee0811111755r580b8211m8bcf6a81bf0852b0@mail.gmail.com> 2008/11/12 Andrea Vezzosi : > I get the same behaviour, and when I open ghci in xterm and press Ctrl-D it > also echoes ^D before quitting, which is similar to the problem with > haskell-mode which seems to don't like the echoing of ^J from ghci when one > uses commands like C-u C-c C-t (which should copy the inferred type from the > ghci buffer and insert it in the current file). > > I'm using the ghc package from archlinux testing repository, which is built > with libedit 20080712_2.11. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > I also get the same, see http://www.haskell.org/pipermail/glasgow-haskell-users/2008-November/015939.html I don't have a solution, although I put a quick hack in my haskell-mode code so that C-u C-c C-t works. Reiner From magicloud.magiclouds at gmail.com Tue Nov 11 22:42:59 2008 From: magicloud.magiclouds at gmail.com (Magicloud) Date: Tue Nov 11 22:37:40 2008 Subject: ANNOUNCE: GHC version 6.10.1 In-Reply-To: <20081104181106.GA20684@matrix.chaos.earth.li> References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: <491A50C3.4090507@gmail.com> Hi, It is a few days after the release. But why the darcs repos of 6.10 is still changing? Ian Lynagh wrote: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 > ============================================================== > > The GHC Team is pleased to announce a new major release of GHC. There > have been a number of significant changes since the last major release, > including: > > * Some new language features have been implemented: > * Record syntax: wild-card patterns, punning, and field disambiguation > * Generalised quasi-quotes > * Generalised list comprehensions > * View patterns > > * Type families have been completely re-implemented > > * Now comes with Haddock 2, which supports all GHC extensions > > * Parallel garbage collection > > * Base provides extensible exceptions > > * The GHC API is easier to use > > * External core (output only) now works again > > * Data Parallel Haskell (DPH) comes as part of GHC > > The full release notes are here: > > http://haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language; the > current language version is Haskell 98, agreed in December 1998 and > revised December 2002. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://hackage.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://hackage.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://hackage.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://hackage.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From kyagrd at gmail.com Tue Nov 11 23:15:02 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Tue Nov 11 23:09:52 2008 Subject: [Haskell-cafe] How to getCh on MS Windows command line? In-Reply-To: <1561013709.20081111135021@gmail.com> References: <1726166656.20081110095542@gmail.com> <4918407C.9090104@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E96AE@GBLONXMB02.corp.amvescap.net> <4918DA0B.2040003@gmail.com> <1561013709.20081111135021@gmail.com> Message-ID: Bulat Ziganshin wrote: > Hello Ki, > > Tuesday, November 11, 2008, 4:04:11 AM, you wrote: > > i have also linux getCh if you need it, although afaik it's not > perfect and actually you should use something inside Unix package On Unix it is not a problem. We can just use the hSetBuffering and hSetEcho functions in the System.IO module to get no buffering and no echoing the behavior. -- Ahn, Ki Yung From james.swaine at gmail.com Tue Nov 11 23:23:40 2008 From: james.swaine at gmail.com (James Swaine) Date: Tue Nov 11 23:18:08 2008 Subject: libedit.so.0 Message-ID: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> I can't seem to get the latest source bundle to build (running on Red Hat). I run the configure script, then make on the source tree root, and ghc gives an error to the effect of 'could not load shared object file or library libedit.so.0'. I don't have root permissions on this machine so I can't install editline on this machine, but I downloaded the source, built in my local directory, then tried: -Setting the LD_LIBRARY_PATH environment variable to include the directory path to the libedit.so.0 library I just built. -Hand editing the makefile in ghc's 'libraries' directory to add an -L[librarydir] flag to the ghc invocation that was failing. Neither of these things worked - is there an easy way to tell the configure script that it needs to probe additional directories for these shared libraries? Thanks all! -James Swaine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081111/ce4979f4/attachment.htm From Christian.Maeder at dfki.de Wed Nov 12 04:59:32 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Nov 12 04:54:01 2008 Subject: libedit.so.0 In-Reply-To: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> References: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> Message-ID: <491AA904.5050303@dfki.de> James Swaine wrote: > I can't seem to get the latest source bundle to build (running on Red > Hat). I run the configure script, then make on the source tree root, > and ghc gives an error to the effect of 'could not load shared object > file or library libedit.so.0'. I don't have root permissions on this > machine so I can't install editline on this machine, but I downloaded > the source, built in my local directory, then tried: > > -Setting the LD_LIBRARY_PATH environment variable to include the > directory path to the libedit.so.0 library I just built. Set LIBRARY_PATH and CPATH to your local lib resp. include directory when building. (LD_LIBRARY_PATH is used at runtime) Cheers Christian > -Hand editing the makefile in ghc's 'libraries' directory to add an > -L[librarydir] flag to the ghc invocation that was failing. > > Neither of these things worked - is there an easy way to tell the > configure script that it needs to probe additional directories for these > shared libraries? > > Thanks all! > -James Swaine > > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Wed Nov 12 07:02:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 12 06:57:05 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <491964AF.5080607@list.mightyreason.com> References: <491964AF.5080607@list.mightyreason.com> Message-ID: <491AC5DA.6020400@gmail.com> Chris Kuklewicz wrote: >> /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc >> -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes >> -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static >> -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. >> -dcmm-lint -c Apply.cmm -o Apply.o > >> make[1]: *** [Apply.o] Segmentation fault > >> make: *** [stage1] Error 2 > > Does anyone have a clue how to proceed? Perhaps this is the same as http://hackage.haskell.org/trac/ghc/ticket/2380 but others have managed to compile GHC on PPC/OSX. In general we don't have anyone actively working on fixing bugs in the PPC port at the moment, I'd love it if someone could step up and help us keep this platform fully-supported. Here are the current PPC-specific bugs: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&architecture=powerpc&order=priority Cheers, Simon From marlowsd at gmail.com Wed Nov 12 07:08:24 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 12 07:02:55 2008 Subject: how is Linux GHC formed? In-Reply-To: <42784f260811111704y4a7086b5g6eaecfe049046b25@mail.gmail.com> References: <42784f260811111704y4a7086b5g6eaecfe049046b25@mail.gmail.com> Message-ID: <491AC738.9050003@gmail.com> Jason Dusek wrote: > How was the Linux binary for GHC created? I am looking at ways > to compile Haskell binaries for Linux that work across > distros. So far, I have been using `-static -optl-static` but > today there was a weird hiccup with IO -- the Gentoo built > binary worked fine on Gentoo but caught SIGPIPE intermittently > on Ubuntu -- and so it's back to the drawing board. > > The GHC linux binary seems to work on all the Linii without > discrimination, so I'd like to know what the procedure is for > producing it, and what I can take away from that to put in my > Cabal file. We just do a normal build, on Fedora 9 boxen. If it works across other distros, it's probably just good luck! Cheers, Simon From haskell at list.mightyreason.com Wed Nov 12 07:11:13 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Nov 12 07:05:42 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <491AC5DA.6020400@gmail.com> References: <491964AF.5080607@list.mightyreason.com> <491AC5DA.6020400@gmail.com> Message-ID: <491AC7E1.3050905@list.mightyreason.com> I was using macports' binary ghc-6.8.2 so I also suspect this is the same as #2380. Thankfully Christian Maeder's powerpc build is working for me. I have rebuilt all my software and the packages they depend on. I will update the macports error to point at the ghc trac error. The compilation times for ghc itself are quote long on my hardware, as I learned when trying and failing to get the early 6.8.x series to work on powerpc. Thus I won't be stepping up to do the same for ghc-6.10.1 unless I find myself with a much less bust life. PS: I must say that ghc-6.10.1 appears to run much faster than ghc-6.8.3 on my G4 laptop. Thanks :) -- Chris Simon Marlow wrote: > Chris Kuklewicz wrote: > >>> /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc >>> -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes >>> -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static >>> -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. >>> -dcmm-lint -c Apply.cmm -o Apply.o >> >>> make[1]: *** [Apply.o] Segmentation fault >> >>> make: *** [stage1] Error 2 >> >> Does anyone have a clue how to proceed? > > Perhaps this is the same as > > http://hackage.haskell.org/trac/ghc/ticket/2380 > > but others have managed to compile GHC on PPC/OSX. > > In general we don't have anyone actively working on fixing bugs in the > PPC port at the moment, I'd love it if someone could step up and help us > keep this platform fully-supported. Here are the current PPC-specific > bugs: > > http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&architecture=powerpc&order=priority > > > Cheers, > Simon > From marlowsd at gmail.com Wed Nov 12 07:50:24 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 12 07:44:55 2008 Subject: ANNOUNCE: GHC version 6.10.1 In-Reply-To: <491A50C3.4090507@gmail.com> References: <20081104181106.GA20684@matrix.chaos.earth.li> <491A50C3.4090507@gmail.com> Message-ID: <491AD110.60306@gmail.com> Magicloud wrote: > Hi, > It is a few days after the release. But why the darcs repos of 6.10 > is still changing? The 6.10 repo is a branch. We tagged the 6.10.1 release, and we're now working towards a 6.10.2 release. Cheers, Simon From igloo at earth.li Wed Nov 12 08:22:51 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 12 08:17:20 2008 Subject: how is Linux GHC formed? In-Reply-To: <42784f260811111704y4a7086b5g6eaecfe049046b25@mail.gmail.com> References: <42784f260811111704y4a7086b5g6eaecfe049046b25@mail.gmail.com> Message-ID: <20081112132251.GA18219@matrix.chaos.earth.li> On Tue, Nov 11, 2008 at 05:04:25PM -0800, Jason Dusek wrote: > How was the Linux binary for GHC created? I am looking at ways > to compile Haskell binaries for Linux that work across > distros. So far, I have been using `-static -optl-static` but > today there was a weird hiccup with IO -- the Gentoo built > binary worked fine on Gentoo but caught SIGPIPE intermittently > on Ubuntu -- and so it's back to the drawing board. > > The GHC linux binary seems to work on all the Linii without > discrimination, so I'd like to know what the procedure is for > producing it, and what I can take away from that to put in my > Cabal file. The only special thing we do is to put "BeConservative = YES" in mk/build.mk when compiling GHC. This means that we don't try to use clock_gettime in the RTS. Thanks Ian From jeff.polakow at db.com Wed Nov 12 10:53:01 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Wed Nov 12 10:47:34 2008 Subject: inconsistent type checking behavior In-Reply-To: <4919698F.9080302@jellybean.co.uk> Message-ID: Hello, Thinking about this more, I have changed my mind about what should type check, but I still think GHC's behavior is inconsistent... > (Side-stepping your main point, rather, which I think Chris K answered > correctly) > Chris explained that the types are not equivalent to GHC by showing a context for which GHC's type checker differentiates the two types. My point was that GHC is arguably wrong (but perhaps pragmatically correct). The example Chris used assumes predicative polymorphism, but GHC supposedly has impredicative polymorphism and under impredicative polymorphism, I don't think there is a Haskell context which can differentiate the two types. But this is a bit of a distraction from the point I am trying to make which is... GHC's type checker seems to have a bug or, at least, an infelicity. Here is a description of the strange behavior which led me to this conclusion. Note that all of the following is in GHC 6.10.1 with -XImpredicativeTypes. GHC's type checker accepts the following code: b :: String -> forall b. b -> Int b = \x y -> 0 f :: forall b. String -> b -> Int f = \x y -> 0 GHC's also accepts the following code (I think this is wrong, see below): b :: String -> forall b. b -> Int b = \x y -> 0 f :: forall b. String -> b -> Int f = b Now, if we switch to an analogous, though slightly more complicated type, GHC's type checker accepts the following code: bar :: (forall b. b -> String, Int) bar = (const "hi", 0) foo :: forall b.(b -> String, Int) foo = (const "hi", 0) however GHC's type checker rejects the following code (I now think this is correct): bar :: (forall b. b -> String, Int) bar = (const "hi", 0) foo :: forall b.(b -> String, Int) foo = bar with the error : Couldn't match expected type `b -> String' against inferred type `forall b1. b1 -> String' and yet GHC accepts the following code: bar :: (forall b. b -> String, Int) bar = (const "hi", 0) foo :: forall b.(b -> String, Int) foo = (fst bar, snd bar) which is just the eta-expansion of the previous code. This behavior seems inconsistent to me. I don't see any reason why the (f = b) should be different than (foo = bar). In fact, thinking more carefully about the types, I think that (f = b) should not type and the eta expansion (f = \x -> b x) should be required. > This is a non-sequitur. > On the contrary, this is the crux of the matter; derivations are type checking. To figure out what should type check we need to look at what is derivable. > The fact that A |- B and B |- A does not make them the same type. It > makes them isomorphic types. > True, the derivations are isomorphic, and in a language with explicit type-lambdas and type-applications, there would be two different but isomorphic terms for the two types. However, since Haskell leaves type-lambdas and type-applications implicit, the exact same Haskell term can have both types (as shown above). So it is not so crazy to think that (f = b) and (foo = bar) might type check. Furthermore, it is by looking at the typing derivation system that I've come the conclusion that (f = b) should not type check. In order to type check (f = b) we have to derive the following (assuming no explicit terms for type-lambdas and type-applications): b :: String -> forall a. a -> Int |- b :: forall b . String -> b -> Int which can't be done, whereas b :: String -> forall a. a -> Int |- \x -> b x :: forall b . String -> b -> Int can be derived. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081112/e5015f85/attachment.htm From allbery at ece.cmu.edu Wed Nov 12 11:55:20 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Nov 12 11:49:53 2008 Subject: inconsistent type checking behavior In-Reply-To: References: Message-ID: <0AB26B7E-44C5-4E17-847E-DD8520BF9365@ece.cmu.edu> On 2008 Nov 12, at 10:53, Jeff Polakow wrote: > Now, if we switch to an analogous, though slightly more complicated > type, GHC's type checker accepts the following code: > > bar :: (forall b. b -> String, Int) > bar = (const "hi", 0) > foo :: forall b.(b -> String, Int) > foo = (const "hi", 0) > > however GHC's type checker rejects the following code (I now think > this is correct): > > bar :: (forall b. b -> String, Int) > bar = (const "hi", 0) > foo :: forall b.(b -> String, Int) > foo = bar > > with the error : > > Couldn't match expected type `b -> String' > against inferred type `forall b1. b1 -> String' > > and yet GHC accepts the following code: > > bar :: (forall b. b -> String, Int) > bar = (const "hi", 0) > foo :: forall b.(b -> String, Int) > foo = (fst bar, snd bar) > > which is just the eta-expansion of the previous code. > > This behavior seems inconsistent to me. I don't see any reason why > the (f = b) should be different than (foo = bar). In fact, thinking > more carefully about the types, I think that (f = b) should not type > and the eta expansion (f = \x -> b x) should be required. Seems right to me: symbolically it may be an eta-expansion, but practically GHC's tuples are actually types, so the latter is a new tuple with a different type from the former. (GHC's handling of tuples is often infelicitous.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081112/6b1e878d/attachment-0001.htm From gwright at comcast.net Wed Nov 12 12:16:12 2008 From: gwright at comcast.net (Gregory Wright) Date: Wed Nov 12 12:10:41 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <4919784D.3090601@dfki.de> References: <491964AF.5080607@list.mightyreason.com> <49196A74.3030009@dfki.de> <49197198.8000500@list.mightyreason.com> <4919784D.3090601@dfki.de> Message-ID: Hi Chrisitian, On Nov 11, 2008, at 7:19 AM, Christian Maeder wrote: > Chris Kuklewicz wrote: >> Christian Maeder wrote: >>> I can offer a Tiger PPC built that works for me: >>> (linked against /opt/local/lib/libgmp.dylib) >>> >> >> But the filename says "-i386-" so I suspect it is not a powerpc >> build. > > Sorry, the link is: > > http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 > > Christian I'll try using your binary compiler as a bootstrap compiler for the macports' ppc builds. Should have something ready for testing in a day or two. Greg From james.swaine at gmail.com Wed Nov 12 12:28:29 2008 From: james.swaine at gmail.com (James Swaine) Date: Wed Nov 12 12:23:08 2008 Subject: libedit.so.0 In-Reply-To: <491AA904.5050303@dfki.de> References: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> <491AA904.5050303@dfki.de> Message-ID: <5195fdde0811120928s7b4dff61w669eddffd6dbc9ad@mail.gmail.com> That didn't work. My editline build is in the directory /home/jswaine/libedit, with the actual library being in /home/jswaine/libedit/lib and the includes being in /home/jswaine/libedit/include. So when I invoked the configure script, I did it like so: /.configure LIBRARY_PATH=$LIBRARY_PATH$:/home/jswaine/libedit/lib CPATH=CPATH$:/home/jswaine/libedit/include But still for some reason I get the same error. Am I doing this correctly? Thanks! -James On Wed, Nov 12, 2008 at 3:59 AM, Christian Maeder wrote: > James Swaine wrote: > > I can't seem to get the latest source bundle to build (running on Red > > Hat). I run the configure script, then make on the source tree root, > > and ghc gives an error to the effect of 'could not load shared object > > file or library libedit.so.0'. I don't have root permissions on this > > machine so I can't install editline on this machine, but I downloaded > > the source, built in my local directory, then tried: > > > > -Setting the LD_LIBRARY_PATH environment variable to include the > > directory path to the libedit.so.0 library I just built. > > Set LIBRARY_PATH and CPATH to your local lib resp. include directory > when building. (LD_LIBRARY_PATH is used at runtime) > > Cheers Christian > > > -Hand editing the makefile in ghc's 'libraries' directory to add an > > -L[librarydir] flag to the ghc invocation that was failing. > > > > Neither of these things worked - is there an easy way to tell the > > configure script that it needs to probe additional directories for these > > shared libraries? > > > > Thanks all! > > -James Swaine > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20081112/6f6d3344/attachment.htm From Christian.Maeder at dfki.de Wed Nov 12 12:35:03 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Nov 12 12:29:30 2008 Subject: libedit.so.0 In-Reply-To: <5195fdde0811120928s7b4dff61w669eddffd6dbc9ad@mail.gmail.com> References: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> <491AA904.5050303@dfki.de> <5195fdde0811120928s7b4dff61w669eddffd6dbc9ad@mail.gmail.com> Message-ID: <491B13C7.1080701@dfki.de> James Swaine wrote: > That didn't work. My editline build is in the directory > /home/jswaine/libedit, with the actual library being in > /home/jswaine/libedit/lib and the includes being in > /home/jswaine/libedit/include. So when I invoked the configure script, > I did it like so: > > /.configure LIBRARY_PATH=$LIBRARY_PATH$:/home/jswaine/libedit/lib > CPATH=CPATH$:/home/jswaine/libedit/include > > But still for some reason I get the same error. Am I doing this correctly? use export: export LIBRARY_PATH=/home/jswaine/libedit/lib export CPATH=/home/jswaine/libedit/include ./configure make (and but your own path first) Cheers Christian From gwright at comcast.net Wed Nov 12 12:42:00 2008 From: gwright at comcast.net (Gregory Wright) Date: Wed Nov 12 12:36:27 2008 Subject: Notes on building 6.10.1 References: Message-ID: <828C40D9-5BF7-4EB4-9A83-C5B21B63240D@comcast.net> Hi, When building 6.10.1 under Macports, I noticed that hpc now requires that hsc2hs be present on the system (it does not use the hsc2hs built in place with the new ghc). Previous versions did not require hsc2hs to be present; the compiler could be bootstrapped from just the ghc compiler and ghc-pkg. The hpc library is the only one that requires the external hsc2hs. Is this new dependency intentional, or is this a build system bug? This problem escaped detection initially because cabal will use any hsc2hs on the path even if the --with-compiler flag is set. (--with-compiler forces a particular compiler and packaging program, but not hsc2hs.) This is just asking for trouble. For the moment, it's fixed in the Macports build by hacking hpc's Makefile to specify --with-hsc2hs. Should cabal produce and error or a warning if hsc2hs is not found in the same directory as the compiler? I suggest an error by default, but not if --with- hsc2hs is given explicitly. Best Wishes, Greg From james.swaine at gmail.com Wed Nov 12 12:47:38 2008 From: james.swaine at gmail.com (James Swaine) Date: Wed Nov 12 12:42:04 2008 Subject: libedit.so.0 In-Reply-To: <491B13C7.1080701@dfki.de> References: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> <491AA904.5050303@dfki.de> <5195fdde0811120928s7b4dff61w669eddffd6dbc9ad@mail.gmail.com> <491B13C7.1080701@dfki.de> Message-ID: <5195fdde0811120947s6fea554cl4c2a5704722d16f1@mail.gmail.com> That still didn't do anything. Here's the exact error text I'm getting: error while loading shared libraries: libedit.so.0: cannot open shared object file: No such file or directory make[1]: *** [cabal-bin] Error 127 make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' make: *** [stage1] Error 2 Thanks, James On Wed, Nov 12, 2008 at 11:35 AM, Christian Maeder wrote: > James Swaine wrote: > > That didn't work. My editline build is in the directory > > /home/jswaine/libedit, with the actual library being in > > /home/jswaine/libedit/lib and the includes being in > > /home/jswaine/libedit/include. So when I invoked the configure script, > > I did it like so: > > > > /.configure LIBRARY_PATH=$LIBRARY_PATH$:/home/jswaine/libedit/lib > > CPATH=CPATH$:/home/jswaine/libedit/include > > > > But still for some reason I get the same error. Am I doing this > correctly? > > use export: > > export LIBRARY_PATH=/home/jswaine/libedit/lib > export CPATH=/home/jswaine/libedit/include > ./configure > make > > (and but your own path first) > > Cheers Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081112/2d956550/attachment.htm From Christian.Maeder at dfki.de Wed Nov 12 13:01:57 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Nov 12 12:56:24 2008 Subject: libedit.so.0 In-Reply-To: <5195fdde0811120947s6fea554cl4c2a5704722d16f1@mail.gmail.com> References: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> <491AA904.5050303@dfki.de> <5195fdde0811120928s7b4dff61w669eddffd6dbc9ad@mail.gmail.com> <491B13C7.1080701@dfki.de> <5195fdde0811120947s6fea554cl4c2a5704722d16f1@mail.gmail.com> Message-ID: <491B1A15.2090606@dfki.de> James Swaine wrote: > That still didn't do anything. Here's the exact error text I'm getting: > > error while loading shared libraries: libedit.so.0: cannot open shared > object file: No such file or directory > make[1]: *** [cabal-bin] Error 127 > make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' > make: *** [stage1] Error 2 > use export: > and export LD_LIBRARY_PATH=/home/jswaine/libedit/lib Are you sure /home/jswaine/libedit/lib/libedit.so.0 is a valid file? C. From james.swaine at gmail.com Wed Nov 12 13:08:11 2008 From: james.swaine at gmail.com (James Swaine) Date: Wed Nov 12 13:02:38 2008 Subject: libedit.so.0 In-Reply-To: <491B1A15.2090606@dfki.de> References: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> <491AA904.5050303@dfki.de> <5195fdde0811120928s7b4dff61w669eddffd6dbc9ad@mail.gmail.com> <491B13C7.1080701@dfki.de> <5195fdde0811120947s6fea554cl4c2a5704722d16f1@mail.gmail.com> <491B1A15.2090606@dfki.de> Message-ID: <5195fdde0811121008q410303d6t15d5e4d998a340f6@mail.gmail.com> Aha! That *seems* to have fixed the problem with libedit.so.0. Now ghc is complaining about something else: grep: packages: No such file or directory make -C libraries boot make[1]: Entering directory `/home/jswaine/ghc/ghc-6.10.1/libraries' mkdir bootstrapping mkdir: cannot create directory `bootstrapping': File exists make[1]: [cabal-bin] Error 1 (ignored) /home/jswaine/ghc/ghc-6.10.1/ghc/ghc -Wall -DCABAL_VERSION=1,6,0,1 -odir /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -hidir /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -i/home/jswaine/ghc/ghc-6.10.1/libraries/Cabal -i/home/jswaine/ghc/ghc-6.10.1/libraries/filepath -i/home/jswaine/ghc/ghc-6.10.1/libraries/hpc --make cabal-bin -o cabal-bin ghc: missing -B option make[1]: *** [cabal-bin] Error 1 make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' make: *** [stage1] Error 2 Thanks! -James On Wed, Nov 12, 2008 at 12:01 PM, Christian Maeder wrote: > James Swaine wrote: > > That still didn't do anything. Here's the exact error text I'm getting: > > > > error while loading shared libraries: libedit.so.0: cannot open shared > > object file: No such file or directory > > make[1]: *** [cabal-bin] Error 127 > > make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' > > make: *** [stage1] Error 2 > > use export: > > > > and > export LD_LIBRARY_PATH=/home/jswaine/libedit/lib > > Are you sure /home/jswaine/libedit/lib/libedit.so.0 is a valid file? > > C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081112/32729233/attachment-0001.htm From jason.dusek at gmail.com Wed Nov 12 14:35:17 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Nov 12 14:29:44 2008 Subject: how is Linux GHC formed? In-Reply-To: <491AC738.9050003@gmail.com> References: <42784f260811111704y4a7086b5g6eaecfe049046b25@mail.gmail.com> <491AC738.9050003@gmail.com> Message-ID: <42784f260811121135u640a9786v886a5fa69c3bbb8d@mail.gmail.com> Simon Marlow wrote: > We just do a normal build, on Fedora 9 boxen. If it works > across other distros, it's probably just good luck! With GHC, my luck has been good. I've found that `optl-static` actually causes problems, so I've removed it and things work without it. -- _jsn From igloo at earth.li Wed Nov 12 16:46:28 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 12 16:40:54 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <4919784D.3090601@dfki.de> References: <491964AF.5080607@list.mightyreason.com> <49196A74.3030009@dfki.de> <49197198.8000500@list.mightyreason.com> <4919784D.3090601@dfki.de> Message-ID: <20081112214628.GA7896@matrix.chaos.earth.li> On Tue, Nov 11, 2008 at 01:19:25PM +0100, Christian Maeder wrote: > http://www.dfki.de/sks/hets/intel-mac/ghcs/ghc-6.10.1-i386-apple-darwin.tar.bz2 > > http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 Thanks Christian, I've put these up on the 6.10.1 download page. Thanks Ian From igloo at earth.li Wed Nov 12 17:52:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 12 17:47:14 2008 Subject: Notes on building 6.10.1 In-Reply-To: <828C40D9-5BF7-4EB4-9A83-C5B21B63240D@comcast.net> References: <828C40D9-5BF7-4EB4-9A83-C5B21B63240D@comcast.net> Message-ID: <20081112225241.GA21437@matrix.chaos.earth.li> On Wed, Nov 12, 2008 at 12:42:00PM -0500, Gregory Wright wrote: > > The hpc library is the only one that requires the external hsc2hs. Is > this new dependency > intentional, or is this a build system bug? I don't think that the build dep is necessary, but with the current filesystem layout it's a pain to avoid. We would need to, with the bootstrapping compiler: Build libraries/{filepath,Cabal,cabal-bin} Build utils/hsc2hs Build libraries/hpc Build compiler (stage 1) We plan to rewrite the build system for 6.12 anyway, so I think we should take care of this then. It probably makes sense to merge (some of?) "utils" and "libraries" into "packages". As far as 6.10 is concerned, we install hsc2hs with ghc by default, so I think it is reasonable to depend on it. Thanks Ian From jgmorris at cecs.pdx.edu Wed Nov 12 19:29:34 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Wed Nov 12 19:24:02 2008 Subject: Newbish building question Message-ID: <6cf91caa0811121629x7ba93f85pabeed4e6cd353d1c@mail.gmail.com> Hello, I've been attempting to add some minor instrumentation to my pet copy of GHC 6.10.1. In particular, I'd like to add some code to extendInstEnv in compiler/types/InstEnv.lhs. First, I tried importing Debug.Trace into the InstEnv module, and changing the extendInstEnv function to trace "foobar". This built file, although was not tremendously useful. Next, I tried the following modification: extendInstEnv :: InstEnv -> Instance -> InstEnv extendInstEnv inst_env ins_item@(Instance { is_cls = cls_nm, is_tcs = mb_tcs }) = trace (showSDocDebug (ppr ins_item)) (addToUFM_C add inst_env cls_nm (ClsIE [ins_item] ins_tyvar)) where add (ClsIE cur_insts cur_tyvar) _ = ClsIE (ins_item : cur_insts) (ins_tyvar || cur_tyvar) ins_tyvar = not (any isJust mb_tcs) This produced the following error message: home/garrett/code/ghc-6.10.1/ghc/stage1-inplace/ghc -package-name base-4.0.0.0-hide-all-packages -no-user-package-conf -split-objs -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-include -optPdist/build/autogen/cabal_macros.h -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1.0.0 -package integer-0.1.0.0 -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XCPP -idist/build -H32m -O -O2 -Rghc-timing -XGenerics -Wall -fno-warn-deprecated-flags -c Data/Maybe.hs -o dist/build/Data/Maybe.o -ohi dist/build/Data/Maybe.hi dist/build/GHC/Base.hi Dict fun GHC.Base.$f9: Interface file inconsistency: home-package module `base:GHC.Base' is needed, but is not listed in the dependencies of the interfaces directly imported by the module being compiled Cannot continue after interface file error <> I'm not sure what to do from here - showSDocDebug comes from Outputable, which was already imported by InstEnv, so it didn't seem like I should have to change anything in the build.. /g -- I am in here From Christian.Maeder at dfki.de Thu Nov 13 03:32:41 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Nov 13 03:27:08 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <20081112214628.GA7896@matrix.chaos.earth.li> References: <491964AF.5080607@list.mightyreason.com> <49196A74.3030009@dfki.de> <49197198.8000500@list.mightyreason.com> <4919784D.3090601@dfki.de> <20081112214628.GA7896@matrix.chaos.earth.li> Message-ID: <491BE629.202@dfki.de> Ian Lynagh wrote: > On Tue, Nov 11, 2008 at 01:19:25PM +0100, Christian Maeder wrote: > >> http://www.dfki.de/sks/hets/intel-mac/ghcs/ghc-6.10.1-i386-apple-darwin.tar.bz2 >> >> http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 > > Thanks Christian, I've put these up on the 6.10.1 download page. http://haskell.org/ghc/download_ghc_6_10_1.html#macosxintel http://haskell.org/ghc/download_ghc_6_10_1.html#macosxppc libreadline.5.2.dylib is no longer needed, since ghc uses libedit.2.dylib (which uses libncurses.5.dylib, that should be also under /usr/lib/) Cheers C. From nominolo at googlemail.com Thu Nov 13 05:51:03 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Nov 13 05:45:28 2008 Subject: Newbish building question In-Reply-To: <6cf91caa0811121629x7ba93f85pabeed4e6cd353d1c@mail.gmail.com> References: <6cf91caa0811121629x7ba93f85pabeed4e6cd353d1c@mail.gmail.com> Message-ID: <916b84820811130251s2673f78bic7d348b086f0fb22@mail.gmail.com> 2008/11/13 J. Garrett Morris : > (addToUFM_C add inst_env > cls_nm (ClsIE [ins_item] ins_tyvar)) Did you try make distclean and building again? This often fixes things, it could also be that extendInstEnv was inlined somewhere, though that should not lead to the error, either. No idea what else could have happened. -- Push the envelope. Watch it bend. From marlowsd at gmail.com Thu Nov 13 11:37:19 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 13 11:31:49 2008 Subject: Linking error during stage2 In-Reply-To: References: Message-ID: <491C57BF.3030309@gmail.com> dermiste wrote: > Hi, > > I've successfully built GHC-6.10.1 from 6.6.1 on OpenBSD 4.4, and > would like now to generate a hc-file-bundle to build it without > pre-existing GHC. I followed the instructions in [1], but I'm stuck > with this error : Bootstrapping from HC files isn't supported in 6.10.1, it was last supported in 6.6.1. We aim to have it working again for 6.12. Sorry for the inconvenience! Cheers, Simon From marlowsd at gmail.com Thu Nov 13 11:44:19 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 13 11:38:47 2008 Subject: Newbish building question In-Reply-To: <6cf91caa0811121629x7ba93f85pabeed4e6cd353d1c@mail.gmail.com> References: <6cf91caa0811121629x7ba93f85pabeed4e6cd353d1c@mail.gmail.com> Message-ID: <491C5963.1090001@gmail.com> J. Garrett Morris wrote: > Hello, > > I've been attempting to add some minor instrumentation to my pet copy > of GHC 6.10.1. In particular, I'd like to add some code to > extendInstEnv in compiler/types/InstEnv.lhs. > > First, I tried importing Debug.Trace into the InstEnv module, and > changing the extendInstEnv function to trace "foobar". This built > file, although was not tremendously useful. > > Next, I tried the following modification: > > extendInstEnv :: InstEnv -> Instance -> InstEnv > extendInstEnv inst_env ins_item@(Instance { is_cls = cls_nm, is_tcs = mb_tcs }) > = trace (showSDocDebug (ppr ins_item)) (addToUFM_C add inst_env > cls_nm (ClsIE [ins_item] ins_tyvar)) > where > add (ClsIE cur_insts cur_tyvar) _ = ClsIE (ins_item : cur_insts) > (ins_tyvar || cur_tyvar) > ins_tyvar = not (any isJust mb_tcs) > > This produced the following error message: > > home/garrett/code/ghc-6.10.1/ghc/stage1-inplace/ghc -package-name > base-4.0.0.0-hide-all-packages -no-user-package-conf -split-objs -i > -idist/build -i. -idist/build/autogen -Idist/build/autogen > -Idist/build -Iinclude -optP-include > -optPdist/build/autogen/cabal_macros.h -#include "HsBase.h" -odir > dist/build -hidir dist/build -stubdir dist/build -package > ghc-prim-0.1.0.0 -package integer-0.1.0.0 -package rts-1.0 -O > -package-name base -XMagicHash -XExistentialQuantification > -XRank2Types -XScopedTypeVariables -XUnboxedTuples > -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable > -XGeneralizedNewtypeDeriving -XFlexibleInstances -XPatternSignatures > -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XCPP > -idist/build -H32m -O -O2 -Rghc-timing -XGenerics -Wall > -fno-warn-deprecated-flags -c Data/Maybe.hs -o dist/build/Data/Maybe.o > -ohi dist/build/Data/Maybe.hi > dist/build/GHC/Base.hi > Dict fun GHC.Base.$f9: > Interface file inconsistency: > home-package module `base:GHC.Base' is needed, > but is not listed in the dependencies of the interfaces directly > imported by the module being compiled > Cannot continue after interface file error > < samples), 31M in use, 0.01 INIT (0.02 elapsed), 0.06 MUT (0.14 > elapsed), 0.03 GC (0.04 elapsed) :ghc>> This is rather strange. It looks like an error when compiling Data.Maybe in the base package. I'm not sure why that would need to be recompiled at all, and the error itself is strange. Anyway, when modifying GHC you only need to say 'make' in compiler/, not at the top-level, that is unless you really want to recompile libraries, in which case you should probably 'make clean' in libraries/, then 'make boot' and 'make'. Cheers, Simon From gwright at comcast.net Thu Nov 13 13:04:32 2008 From: gwright at comcast.net (Gregory Wright) Date: Thu Nov 13 12:59:00 2008 Subject: Notes on building 6.10.1 In-Reply-To: <20081112225241.GA21437@matrix.chaos.earth.li> References: <828C40D9-5BF7-4EB4-9A83-C5B21B63240D@comcast.net> <20081112225241.GA21437@matrix.chaos.earth.li> Message-ID: Hi Ian, On Nov 12, 2008, at 5:52 PM, Ian Lynagh wrote: > On Wed, Nov 12, 2008 at 12:42:00PM -0500, Gregory Wright wrote: >> >> The hpc library is the only one that requires the external hsc2hs. >> Is >> this new dependency >> intentional, or is this a build system bug? > > I don't think that the build dep is necessary, but with the current > filesystem layout it's a pain to avoid. We would need to, with the > bootstrapping compiler: > > Build libraries/{filepath,Cabal,cabal-bin} > Build utils/hsc2hs > Build libraries/hpc > Build compiler (stage 1) > > We plan to rewrite the build system for 6.12 anyway, so I think we > should take care of this then. It probably makes sense to merge (some > of?) "utils" and "libraries" into "packages". > > As far as 6.10 is concerned, we install hsc2hs with ghc by default, > so I > think it is reasonable to depend on it. > OK. I'll file a placeholder bug report so this doesn't get forgotten. I understand the reason for leaving it as is for now, but hope that we avoid creeping dependence on more tools. BTW, now that ghc distributes its own version of haddock, could that version be renamed to avoid the obvious namespace clash? Macports will rename ghc's haddock to haddock-ghc so it doesn't conflict with the one installed from hackage. Or is there a better plan? Best Wishes, Greg > From duncan.coutts at worc.ox.ac.uk Thu Nov 13 18:23:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 13 18:18:51 2008 Subject: Notes on building 6.10.1 In-Reply-To: <110695DF-8306-4B3D-80D8-DCDDA47BFE02@antiope.com> References: <110695DF-8306-4B3D-80D8-DCDDA47BFE02@antiope.com> Message-ID: <1226618590.17214.364.camel@localhost> On Wed, 2008-11-12 at 12:39 -0500, Gregory Wright wrote: > Should cabal produce and error or a warning if hsc2hs is not found in > the same directory as the compiler? I suggest an error by default, > but not if --with-hsc2hs is given explicitly. I don't think so. In principle hsc2hs is not tied to ghc, it just happens to be shipped with it. The versions do not need to match up (much). It's in the same category as other pre-processors like c2hs. For the ghc build system, either it really does need an external hsc2hs in which case it should detect it in the top level configure script or it can use the one it ships with in which case it should be using the --with-hsc2hs flag. Duncan From james.swaine at gmail.com Fri Nov 14 01:41:10 2008 From: james.swaine at gmail.com (James Swaine) Date: Fri Nov 14 01:35:32 2008 Subject: more libedit.so.0 issues Message-ID: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> We've had unbelievable problems getting past this ridiculous 'unable to load object file or shared library libedit.so.0' error when attempting to build the 6.10.1 source tree. We initially just built editline in a user directory and attempted to manipulate environment variables to help the linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but this did no good. We then just installed the editline package so it's available globally and the libraries (specifically libedit.so.0) live in /usr/local/lib, so it should be found with no problem. Not so for ghc - same error. We're running this on Red Hat. I'm part of a research group at Northwestern University that is exploring the use of ghc and associated libraries for some upcoming projects. It's a shame that this is so difficult to even compile/install, and nobody seems to be able to figure out what's wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081114/abaf3764/attachment.htm From dons at galois.com Fri Nov 14 02:00:47 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 14 01:55:10 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> Message-ID: <20081114070047.GA7966@scytale.galois.com> james.swaine: > We've had unbelievable problems getting past this ridiculous 'unable to > load object file or shared library libedit.so.0' error when attempting to > build the 6.10.1 source tree. We initially just built editline in a user > directory and attempted to manipulate environment variables to help the > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but this > did no good. > > We then just installed the editline package so it's available globally and > the libraries (specifically libedit.so.0) live in /usr/local/lib, so it > should be found with no problem. Not so for ghc - same error. We're > running this on Red Hat. What does ldd say? It should say something like this (on Arch Linux): $ ldd /usr/lib/ghc-6.10.0/ghc linux-vdso.so.1 => (0x00007fffb09fe000) libedit.so.0 => /usr/lib/libedit.so.0 (0x00007f6aa8479000) libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f6aa820f000) libutil.so.1 => /lib/libutil.so.1 (0x00007f6aa800c000) libdl.so.2 => /lib/libdl.so.2 (0x00007f6aa7e08000) libm.so.6 => /lib/libm.so.6 (0x00007f6aa7b85000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f6aa7943000) librt.so.1 => /lib/librt.so.1 (0x00007f6aa773b000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6aa7520000) libc.so.6 => /lib/libc.so.6 (0x00007f6aa71cc000) /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) For example, let's you know if the system linker can see libedit (and the other C libraries GHC uses) > I'm part of a research group at Northwestern University that is exploring > the use of ghc and associated libraries for some upcoming projects. It's > a shame that this is so difficult to even compile/install, and nobody > seems to be able to figure out what's wrong. Do you have the option of using a distro package? Has GHC 6.10.x been packaged for your distro yet? Do you have the option of using GHC 6.8.x for now, or is there some feature in 6.10.x you expect to depend on? -- Don From bit at mutantlemon.com Fri Nov 14 07:04:22 2008 From: bit at mutantlemon.com (Bit Connor) Date: Fri Nov 14 06:58:44 2008 Subject: Trouble with ghc on linux x86_64 Message-ID: <6205bd290811140404o441d0455q74e22caf821a60cc@mail.gmail.com> The system is a xen virtual machine: Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux With GHC version 6.8.2, ghci gives the error: $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7f10a29e56d0 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted GHC version 6.10.1 gives a similar error: $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted These same 2 results happen on 2 different distros that I've tried. With both GHC versions, compiling haskell programs sometimes works, but sometimes hangs during the linking stage. The results are the same using the distro provided packages and with the binaries from the ghc website. I also actually managed to compile ghc version 6.10.1 using ghc 6.8.2, but not completely, "make" got froze during haddock generation for ghc-6.10.1. There was however a "ghc" binary that was produced in the directory ghc/dist-stage2/build/ghc/ghc. Running this binary as --interactive gave the exact same 6.10.1 error above. Any ideas? Thanks, Bit From marlowsd at gmail.com Fri Nov 14 08:31:30 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 14 08:25:56 2008 Subject: libedit.so.0 In-Reply-To: <5195fdde0811121008q410303d6t15d5e4d998a340f6@mail.gmail.com> References: <5195fdde0811112023mae65185l104c6a008a79f20c@mail.gmail.com> <491AA904.5050303@dfki.de> <5195fdde0811120928s7b4dff61w669eddffd6dbc9ad@mail.gmail.com> <491B13C7.1080701@dfki.de> <5195fdde0811120947s6fea554cl4c2a5704722d16f1@mail.gmail.com> <491B1A15.2090606@dfki.de> <5195fdde0811121008q410303d6t15d5e4d998a340f6@mail.gmail.com> Message-ID: <491D7DB2.7020008@gmail.com> James Swaine wrote: > Aha! That *seems* to have fixed the problem with libedit.so.0. Now ghc > is complaining about something else: > > grep: packages: No such file or directory > make -C libraries boot > make[1]: Entering directory `/home/jswaine/ghc/ghc-6.10.1/libraries' > mkdir bootstrapping > mkdir: cannot create directory `bootstrapping': File exists > make[1]: [cabal-bin] Error 1 (ignored) > /home/jswaine/ghc/ghc-6.10.1/ghc/ghc -Wall -DCABAL_VERSION=1,6,0,1 -odir > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -hidir > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping > -i/home/jswaine/ghc/ghc-6.10.1/libraries/Cabal > -i/home/jswaine/ghc/ghc-6.10.1/libraries/filepath > -i/home/jswaine/ghc/ghc-6.10.1/libraries/hpc --make cabal-bin -o cabal-bin > ghc: missing -B option > make[1]: *** [cabal-bin] Error 1 > make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' > make: *** [stage1] Error 2 This is a highly mysterious error. Did you clean the tree before rebuilding? Always a good idea to do a 'make distclean' if you're not sure what state your build tree is in. If you get this from a clean build, then please put up a complete log of the build somewhere and we'll try to diagnose. Cheers, Simon From marlowsd at gmail.com Fri Nov 14 08:36:06 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 14 08:30:32 2008 Subject: Trouble with ghc on linux x86_64 In-Reply-To: <6205bd290811140404o441d0455q74e22caf821a60cc@mail.gmail.com> References: <6205bd290811140404o441d0455q74e22caf821a60cc@mail.gmail.com> Message-ID: <491D7EC6.5090309@gmail.com> Bit Connor wrote: > The system is a xen virtual machine: > Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212 > AuthenticAMD GNU/Linux > > With GHC version 6.8.2, ghci gives the error: > > $ ghci > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: > (noname) = 0x7f10a29e56d0 > > (GHC version 6.8.2 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Aborted Yes, this is a known bug. Xen doesn't respect the MAP_32BIT flag to mmap(), which GHC on x86_64 relies on. http://hackage.haskell.org/trac/ghc/ticket/2512 > GHC version 6.10.1 gives a similar error: > > $ ghci > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > ghc: internal error: mmap() returned memory outside 2Gb > (GHC version 6.10.1 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Aborted > > These same 2 results happen on 2 different distros that I've tried. > With both GHC versions, compiling haskell programs sometimes works, > but sometimes hangs during the linking stage. Compiling and running executables should work fine, only GHCi is affected by the above bug. Could you try -v when linking and see what stage is hanging? Cheers, Simon From zepedro.correia at gmail.com Fri Nov 14 09:32:52 2008 From: zepedro.correia at gmail.com (=?ISO-8859-1?Q?Jos=E9_Pedro_Correia?=) Date: Fri Nov 14 09:32:45 2008 Subject: Bug in GHC6.10.1? In-Reply-To: <82d614550811140621l68a4c702h362802a16d7a23c7@mail.gmail.com> References: <82d614550811140621l68a4c702h362802a16d7a23c7@mail.gmail.com> Message-ID: <82d614550811140632w10e19052paade55ab42df2e61@mail.gmail.com> Hello I was wondering if there is a bug in GHC 6.10.1 regarding number precision. As an example, in GHCi with: > 3.0 * 0.2 I get: 0.6000000000000001 Although: > 2.0 * 0.2 0.4 I have GHC 6.10.1 on Mac OS X 10.5. Is this a known bug or should I report it? Best regards Z? Pedro From neil.mitchell.2 at credit-suisse.com Fri Nov 14 09:43:45 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Fri Nov 14 09:41:27 2008 Subject: Bug in GHC6.10.1? In-Reply-To: <82d614550811140632w10e19052paade55ab42df2e61@mail.gmail.com> References: <82d614550811140621l68a4c702h362802a16d7a23c7@mail.gmail.com> <82d614550811140632w10e19052paade55ab42df2e61@mail.gmail.com> Message-ID: Hi, Floating point numbers are just inaccurate, so the results you see aren't too surprisingly. Interestingly enough, using Hugs, I get the right answer in both cases - so its possible it's a bug, but unlikely. If you do want exact floating point manipulation then use rational numbers instead, for example: > 3.0 * 0.2 :: Rational 3%5 Which should be read as a fraction, 3/5, which is the right answer. Thanks Neil > -----Original Message----- > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Jos? Pedro Correia > Sent: 14 November 2008 2:33 pm > To: glasgow-haskell-users@haskell.org > Subject: Re: Bug in GHC6.10.1? > > Hello > > I was wondering if there is a bug in GHC 6.10.1 regarding > number precision. > > As an example, in GHCi with: > > 3.0 * 0.2 > > I get: > 0.6000000000000001 > > Although: > > 2.0 * 0.2 > 0.4 > > I have GHC 6.10.1 on Mac OS X 10.5. > > Is this a known bug or should I report it? > > Best regards > Z? Pedro > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From bulat.ziganshin at gmail.com Fri Nov 14 09:47:35 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Nov 14 09:42:10 2008 Subject: Bug in GHC6.10.1? In-Reply-To: <82d614550811140632w10e19052paade55ab42df2e61@mail.gmail.com> References: <82d614550811140621l68a4c702h362802a16d7a23c7@mail.gmail.com> <82d614550811140632w10e19052paade55ab42df2e61@mail.gmail.com> Message-ID: <1378624565.20081114174735@gmail.com> Hello Jos?, Friday, November 14, 2008, 5:32:52 PM, you wrote: > 0.6000000000000001 computers store floating-point numbers in binary form, and it's imposiible to represent 3/5 in binary form exactly for the same reasons as impossibility to represent 1/3 exactly in decimal form (sorry for awkward english) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bit at mutantlemon.com Fri Nov 14 10:21:35 2008 From: bit at mutantlemon.com (Bit Connor) Date: Fri Nov 14 10:15:57 2008 Subject: Trouble with ghc on linux x86_64 In-Reply-To: <491D7EC6.5090309@gmail.com> References: <6205bd290811140404o441d0455q74e22caf821a60cc@mail.gmail.com> <491D7EC6.5090309@gmail.com> Message-ID: <6205bd290811140721n6e5b88a0la36ee46ea51d4ffc@mail.gmail.com> On Fri, Nov 14, 2008 at 5:36 AM, Simon Marlow wrote: > Compiling and running executables should work fine, only GHCi is affected by > the above bug. Could you try -v when linking and see what stage is hanging? Here is an example with a standard cabal Setup.lhs file. It outputs the following and then hangs. When I look at "top" then there is an "ld" process taking up almost zero cpu, but hundreds of MB of memory. $ ghc -v --make Setup.lhs Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib/ghc-6.8.2/package.conf wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Setup.lhs Created temporary directory: /tmp/ghc3404_0 *** Literate pre-processor: /usr/lib/ghc-6.8.2/unlit -h Setup.lhs Setup.lhs /tmp/ghc3404_0/ghc3404_0.lpp Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Wed Dec 26 03:40:53 PST 2007 ms_mod = main:Main, ms_imps = [Distribution.Simple] ms_srcimps = [] }] compile: input file /tmp/ghc3404_0/ghc3404_0.lpp *** Checking old interface for main:Main: [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 8 *** Simplify: Result size = 6 Result size = 6 *** Tidy Core: Result size = 6 writeBinIface: 1 Names writeBinIface: 17 dict entries *** CorePrep: Result size = 6 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -I. -c /tmp/ghc3404_0/ghc3404_0.s -o Setup.o *** Deleting temp files: Deleting: /tmp/ghc3404_0/ghc3404_0.s Upsweep completely successful. *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Fri Nov 14 07:13:35 PST 2008) main:Main [DotO Setup.o] Linking Setup ... *** Linker: gcc -v -o Setup Setup.o -L/usr/lib/ghc-6.8.2/lib/Cabal-1.2.3.0 -L/usr/lib/ghc-6.8.2/lib/containers-0.1.0.1 -L/usr/lib/ghc-6.8.2/lib/array-0.1.0.0 -L/usr/lib/ghc-6.8.2/lib/process-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/unix-2.3.0.0 -L/usr/lib/ghc-6.8.2/lib/directory-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/filepath-1.1.0.0 -L/usr/lib/ghc-6.8.2/lib/old-time-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/old-locale-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/pretty-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/base-3.0.1.0 -L/usr/lib/ghc-6.8.2 -lHSCabal-1.2.3.0 -lHScontainers-0.1.0.1 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -lutil -ldl -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSpretty-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.2.3 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib/ld-linux-x86-64.so.2 -o Setup -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/ghc-6.8.2/lib/Cabal-1.2.3.0 -L/usr/lib/ghc-6.8.2/lib/containers-0.1.0.1 -L/usr/lib/ghc-6.8.2/lib/array-0.1.0.0 -L/usr/lib/ghc-6.8.2/lib/process-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/unix-2.3.0.0 -L/usr/lib/ghc-6.8.2/lib/directory-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/filepath-1.1.0.0 -L/usr/lib/ghc-6.8.2/lib/old-time-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/old-locale-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/pretty-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/base-3.0.1.0 -L/usr/lib/ghc-6.8.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../.. Setup.o -lHSCabal-1.2.3.0 -lHScontainers-0.1.0.1 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -lutil -ldl -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSpretty-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib/crtn.o From duncan.coutts at worc.ox.ac.uk Fri Nov 14 10:34:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 14 10:29:08 2008 Subject: Bug in GHC6.10.1? In-Reply-To: References: <82d614550811140621l68a4c702h362802a16d7a23c7@mail.gmail.com> <82d614550811140632w10e19052paade55ab42df2e61@mail.gmail.com> Message-ID: <1226676886.17214.389.camel@localhost> On Fri, 2008-11-14 at 14:43 +0000, Mitchell, Neil wrote: > Hi, > > Floating point numbers are just inaccurate, so the results you see > aren't too surprisingly. > > Interestingly enough, using Hugs, I get the right answer in both cases > - so its possible it's a bug, but unlikely. Hugs probably just rounds more. hugs: 0.6 irb: 0.6 ghci: 0.6000000000000001 python: 0.60000000000000009 ocaml: 0.600000000000000089 Duncan From rk at trie.org Fri Nov 14 11:07:35 2008 From: rk at trie.org (Rahul Kapoor) Date: Fri Nov 14 11:01:56 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 Message-ID: I cannot get GHC to work on a fresh ubuntu hardy machine: On installing using the package manager I get an error when running ghci: "R_X86_64_32S relocation out of range:" - similar to http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is FreeBSD specific. I decided to install the binary distribution: after which running ghci fails with error: GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I Added issues #2779 to Trac for the second case. Are there any possible work arounds for these problems? Rahul From james.swaine at gmail.com Fri Nov 14 11:18:50 2008 From: james.swaine at gmail.com (James Swaine) Date: Fri Nov 14 11:13:12 2008 Subject: more libedit.so.0 issues In-Reply-To: <20081114070047.GA7966@scytale.galois.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> Message-ID: <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> it says: libedit.so.0 => not found libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x00000039e2200000) libutil.so.1 => /lib64/libutil.so.1 (0x00000039dba00000) libdl.so.2 => /lib64/libdl.so.2 (0x00000039cfc00000) libm.so.6 => /lib64/libm.so.6 (0x00000039cf800000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000039d5800000) librt.so.1 => /lib64/librt.so.1 (0x00000039d3800000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039d0000000) libc.so.6 => /lib64/libc.so.6 (0x00000039cf400000) /lib64/ld-linux-x86-64.so.2 (0x00000039cec00000) i noticed that my PATH variable doesn't include /usr/local/lib, do you think this might be the problem? -james On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart wrote: > james.swaine: > > We've had unbelievable problems getting past this ridiculous 'unable > to > > load object file or shared library libedit.so.0' error when attempting > to > > build the 6.10.1 source tree. We initially just built editline in a > user > > directory and attempted to manipulate environment variables to help > the > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but > this > > did no good. > > > > We then just installed the editline package so it's available globally > and > > the libraries (specifically libedit.so.0) live in /usr/local/lib, so > it > > should be found with no problem. Not so for ghc - same error. We're > > running this on Red Hat. > > What does ldd say? > > It should say something like this (on Arch Linux): > > $ ldd /usr/lib/ghc-6.10.0/ghc > linux-vdso.so.1 => (0x00007fffb09fe000) > libedit.so.0 => /usr/lib/libedit.so.0 (0x00007f6aa8479000) > libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f6aa820f000) > libutil.so.1 => /lib/libutil.so.1 (0x00007f6aa800c000) > libdl.so.2 => /lib/libdl.so.2 (0x00007f6aa7e08000) > libm.so.6 => /lib/libm.so.6 (0x00007f6aa7b85000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f6aa7943000) > librt.so.1 => /lib/librt.so.1 (0x00007f6aa773b000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6aa7520000) > libc.so.6 => /lib/libc.so.6 (0x00007f6aa71cc000) > /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) > > For example, let's you know if the system linker can see libedit (and the > other > C libraries GHC uses) > > > I'm part of a research group at Northwestern University that is > exploring > > the use of ghc and associated libraries for some upcoming projects. > It's > > a shame that this is so difficult to even compile/install, and nobody > > seems to be able to figure out what's wrong. > > Do you have the option of using a distro package? Has GHC 6.10.x been > packaged for > your distro yet? Do you have the option of using GHC 6.8.x for now, or is > there some > feature in 6.10.x you expect to depend on? > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081114/e36f8a42/attachment.htm From james.swaine at gmail.com Fri Nov 14 11:24:44 2008 From: james.swaine at gmail.com (James Swaine) Date: Fri Nov 14 11:19:06 2008 Subject: more libedit.so.0 issues In-Reply-To: <20081114070047.GA7966@scytale.galois.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> Message-ID: <5195fdde0811140824k7ee10642p2dc587052d98e76b@mail.gmail.com> there wouldn't be any issue with using the 6.8.x binaries. we'd ideally like to be working with the latest source tree (we're planning on tweaking the source, specifically in the parallel and concurrency libraries). but the distro we're using to compile the sources is the 6.10 for 64-bit Linux (the one that expects the libedit.so.0 as opposed to libedit.so.2). so maybe we should drop back to 6.8 and use the Red Hat-specific distro? -james On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart wrote: > james.swaine: > > We've had unbelievable problems getting past this ridiculous 'unable > to > > load object file or shared library libedit.so.0' error when attempting > to > > build the 6.10.1 source tree. We initially just built editline in a > user > > directory and attempted to manipulate environment variables to help > the > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but > this > > did no good. > > > > We then just installed the editline package so it's available globally > and > > the libraries (specifically libedit.so.0) live in /usr/local/lib, so > it > > should be found with no problem. Not so for ghc - same error. We're > > running this on Red Hat. > > What does ldd say? > > It should say something like this (on Arch Linux): > > $ ldd /usr/lib/ghc-6.10.0/ghc > linux-vdso.so.1 => (0x00007fffb09fe000) > libedit.so.0 => /usr/lib/libedit.so.0 (0x00007f6aa8479000) > libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f6aa820f000) > libutil.so.1 => /lib/libutil.so.1 (0x00007f6aa800c000) > libdl.so.2 => /lib/libdl.so.2 (0x00007f6aa7e08000) > libm.so.6 => /lib/libm.so.6 (0x00007f6aa7b85000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f6aa7943000) > librt.so.1 => /lib/librt.so.1 (0x00007f6aa773b000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6aa7520000) > libc.so.6 => /lib/libc.so.6 (0x00007f6aa71cc000) > /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) > > For example, let's you know if the system linker can see libedit (and the > other > C libraries GHC uses) > > > I'm part of a research group at Northwestern University that is > exploring > > the use of ghc and associated libraries for some upcoming projects. > It's > > a shame that this is so difficult to even compile/install, and nobody > > seems to be able to figure out what's wrong. > > Do you have the option of using a distro package? Has GHC 6.10.x been > packaged for > your distro yet? Do you have the option of using GHC 6.8.x for now, or is > there some > feature in 6.10.x you expect to depend on? > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081114/55d6789c/attachment-0001.htm From marlowsd at gmail.com Fri Nov 14 11:30:41 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 14 11:25:05 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: References: Message-ID: <491DA7B1.4090604@gmail.com> Rahul Kapoor wrote: > I cannot get GHC to work on a fresh ubuntu hardy machine: > > On installing using the package manager I get an error when > running ghci: > > "R_X86_64_32S relocation out of range:" - similar to > http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is > FreeBSD specific. > > I decided to install the binary distribution: after which running > ghci fails with error: > > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > ghc: internal error: mmap() returned memory outside 2Gb > (GHC version 6.10.1 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Aborted > > > I Added issues #2779 to Trac for the second case. > > Are there any possible work arounds for these problems? Are you running under Xen by any chance? http://hackage.haskell.org/trac/ghc/ticket/2512 Cheers, Simon From rk at trie.org Fri Nov 14 11:39:09 2008 From: rk at trie.org (Rahul Kapoor) Date: Fri Nov 14 11:33:29 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: <491DA7B1.4090604@gmail.com> References: <491DA7B1.4090604@gmail.com> Message-ID: > Are you running under Xen by any chance? Yes I am. This is on a SliceHost instance. Is there a tentative release date for 6.10.2? Rahul From marlowsd at gmail.com Fri Nov 14 12:01:38 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 14 11:56:04 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: References: <491DA7B1.4090604@gmail.com> Message-ID: <491DAEF2.9070300@gmail.com> Rahul Kapoor wrote: >> Are you running under Xen by any chance? > Yes I am. This is on a SliceHost instance. > > Is there a tentative release date for 6.10.2? About 3 months after the 6.10.1 release was the tentative plan. Is anyone with access to a Xen instance able to work on this bug? It would need a hack similar to the one required for http://hackage.haskell.org/trac/ghc/ticket/2063 namely picking an area of the address space to try to mmap() from. (of course, ideally the Xen folks would fix their kernel to respect MAP_32BIT...) Cheers, Simon From rk at trie.org Fri Nov 14 12:09:17 2008 From: rk at trie.org (Rahul Kapoor) Date: Fri Nov 14 12:03:38 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: <491DAEF2.9070300@gmail.com> References: <491DA7B1.4090604@gmail.com> <491DAEF2.9070300@gmail.com> Message-ID: > Is anyone with access to a Xen instance able to work on this bug? I can setup an login for a GHC developer on my Zen instance, if that would help. From judah.jacobson at gmail.com Fri Nov 14 12:28:27 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 14 12:22:48 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> Message-ID: <6d74b0d20811140928o119822d7w2e0e73dffeb573fe@mail.gmail.com> 2008/11/13 James Swaine : > We've had unbelievable problems getting past this ridiculous 'unable to load > object file or shared library libedit.so.0' error when attempting to build > the 6.10.1 source tree. We initially just built editline in a user > directory and attempted to manipulate environment variables to help the > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but this > did no good. > I'm not sure whether this will fix your problem, but if you want to build ghc using a libedit in a nonstandard location, there's an easier solution than setting all of those environmental variables: just configure ghc with (for example) ./configure --with-editline-includes=/opt/local/include --with-editline-libraries=/opt/local/lib -Judah From james.swaine at gmail.com Fri Nov 14 12:46:08 2008 From: james.swaine at gmail.com (James Swaine) Date: Fri Nov 14 12:40:29 2008 Subject: more libedit.so.0 issues In-Reply-To: <6d74b0d20811140928o119822d7w2e0e73dffeb573fe@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <6d74b0d20811140928o119822d7w2e0e73dffeb573fe@mail.gmail.com> Message-ID: <5195fdde0811140946x51def31bna1bfed3ae21624d6@mail.gmail.com> that didn't fix the problem - i still get the same error message. the configure script help should be updated though to show that these two options are available. thanks, james On Fri, Nov 14, 2008 at 11:28 AM, Judah Jacobson wrote: > 2008/11/13 James Swaine : > > We've had unbelievable problems getting past this ridiculous 'unable to > load > > object file or shared library libedit.so.0' error when attempting to > build > > the 6.10.1 source tree. We initially just built editline in a user > > directory and attempted to manipulate environment variables to help the > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but this > > did no good. > > > > I'm not sure whether this will fix your problem, but if you want to > build ghc using a libedit in a nonstandard location, there's an easier > solution than setting all of those environmental variables: just > configure ghc with (for example) > > ./configure --with-editline-includes=/opt/local/include > --with-editline-libraries=/opt/local/lib > > -Judah > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081114/b66d7b83/attachment.htm From dons at galois.com Fri Nov 14 12:57:06 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 14 12:51:27 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811140946x51def31bna1bfed3ae21624d6@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <6d74b0d20811140928o119822d7w2e0e73dffeb573fe@mail.gmail.com> <5195fdde0811140946x51def31bna1bfed3ae21624d6@mail.gmail.com> Message-ID: <20081114175706.GE9750@scytale.galois.com> This is a straight forward ld.so path problem, by the sounds of it. Are you sure you're setting ld environment search paths correctly? -- Don james.swaine: > that didn't fix the problem - i still get the same error message. the > configure script help should be updated though to show that these two > options are available. > > thanks, > james > > On Fri, Nov 14, 2008 at 11:28 AM, Judah Jacobson > <[1]judah.jacobson@gmail.com> wrote: > > 2008/11/13 James Swaine <[2]james.swaine@gmail.com>: > > We've had unbelievable problems getting past this ridiculous 'unable > to load > > object file or shared library libedit.so.0' error when attempting to > build > > the 6.10.1 source tree. We initially just built editline in a user > > directory and attempted to manipulate environment variables to help > the > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but > this > > did no good. > > > > I'm not sure whether this will fix your problem, but if you want to > build ghc using a libedit in a nonstandard location, there's an easier > solution than setting all of those environmental variables: just > configure ghc with (for example) > > ./configure --with-editline-includes=/opt/local/include > --with-editline-libraries=/opt/local/lib > -Judah > > References > > Visible links > 1. mailto:judah.jacobson@gmail.com > 2. mailto:james.swaine@gmail.com > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dons at galois.com Fri Nov 14 13:02:15 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 14 12:56:38 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> Message-ID: <20081114180215.GF9750@scytale.galois.com> Is your LD_LIBRARY_PATH environment variable exported, and set to include the path to the lib dir that libedit lives in? e.g. $ echo $LD_LIBRARY_PATH /home/dons/lib Allows the system linker to find things in my home dir. james.swaine: > it says: > > libedit.so.0 => not found > libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x00000039e2200000) > libutil.so.1 => /lib64/libutil.so.1 (0x00000039dba00000) > libdl.so.2 => /lib64/libdl.so.2 (0x00000039cfc00000) > libm.so.6 => /lib64/libm.so.6 (0x00000039cf800000) > libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000039d5800000) > librt.so.1 => /lib64/librt.so.1 (0x00000039d3800000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039d0000000) > libc.so.6 => /lib64/libc.so.6 (0x00000039cf400000) > /lib64/ld-linux-x86-64.so.2 (0x00000039cec00000) > > i noticed that my PATH variable doesn't include /usr/local/lib, do you > think this might be the problem? > -james > > On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart <[1]dons@galois.com> wrote: > > james.swaine: > > We've had unbelievable problems getting past this ridiculous > 'unable to > > load object file or shared library libedit.so.0' error when > attempting to > > build the 6.10.1 source tree. We initially just built editline in > a user > > directory and attempted to manipulate environment variables to help > the > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - > but this > > did no good. > > > > We then just installed the editline package so it's available > globally and > > the libraries (specifically libedit.so.0) live in /usr/local/lib, > so it > > should be found with no problem. Not so for ghc - same error. > We're > > running this on Red Hat. > > What does ldd say? > > It should say something like this (on Arch Linux): > > $ ldd /usr/lib/ghc-6.10.0/ghc > linux-vdso.so.1 => (0x00007fffb09fe000) > libedit.so.0 => /usr/lib/libedit.so.0 (0x00007f6aa8479000) > libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f6aa820f000) > libutil.so.1 => /lib/libutil.so.1 (0x00007f6aa800c000) > libdl.so.2 => /lib/libdl.so.2 (0x00007f6aa7e08000) > libm.so.6 => /lib/libm.so.6 (0x00007f6aa7b85000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f6aa7943000) > librt.so.1 => /lib/librt.so.1 (0x00007f6aa773b000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6aa7520000) > libc.so.6 => /lib/libc.so.6 (0x00007f6aa71cc000) > /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) > > For example, let's you know if the system linker can see libedit (and > the other > C libraries GHC uses) > > I'm part of a research group at Northwestern University that is > exploring > > the use of ghc and associated libraries for some upcoming projects. > It's > > a shame that this is so difficult to even compile/install, and > nobody > > seems to be able to figure out what's wrong. > > Do you have the option of using a distro package? Has GHC 6.10.x been > packaged for > your distro yet? Do you have the option of using GHC 6.8.x for now, or > is there some > feature in 6.10.x you expect to depend on? > -- Don > > References > > Visible links > 1. mailto:dons@galois.com From james.swaine at gmail.com Fri Nov 14 13:09:07 2008 From: james.swaine at gmail.com (James Swaine) Date: Fri Nov 14 13:03:28 2008 Subject: more libedit.so.0 issues In-Reply-To: <20081114180215.GF9750@scytale.galois.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> <20081114180215.GF9750@scytale.galois.com> Message-ID: <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> we tried that, but then we got this error: grep: packages: No such file or directory make -C libraries boot make[1]: Entering directory `/home/jswaine/ghc/ghc-6.10.1/ > > libraries' > mkdir bootstrapping > mkdir: cannot create directory `bootstrapping': File exists > make[1]: [cabal-bin] Error 1 (ignored) > /home/jswaine/ghc/ghc-6.10.1/ghc/ghc -Wall -DCABAL_VERSION=1,6,0,1 -odir > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -hidir > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping > -i/home/jswaine/ghc/ghc-6.10.1/libraries/Cabal > -i/home/jswaine/ghc/ghc-6.10.1/libraries/filepath > -i/home/jswaine/ghc/ghc-6.10.1/libraries/hpc --make cabal-bin -o cabal-bin > ghc: missing -B option > make[1]: *** [cabal-bin] Error 1 > make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' > make: *** [stage1] Error 2 which still looks to me like it's somewhat related to linking (the assumption was that -B is used for this sort of thing - linking to libraries in unusual directories). but this option isn't listed in the ghc flag reference. that was when we decided to just install the editline package so it would be where it normally is (/usr/local/lib), but that got us back to the original error message. ugh. -james On Fri, Nov 14, 2008 at 12:02 PM, Don Stewart wrote: > Is your LD_LIBRARY_PATH environment variable exported, and set to > include the path to the lib dir that libedit lives in? > > e.g. > $ echo $LD_LIBRARY_PATH > /home/dons/lib > > Allows the system linker to find things in my home dir. > > james.swaine: > > it says: > > > > libedit.so.0 => not found > > libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x00000039e2200000) > > libutil.so.1 => /lib64/libutil.so.1 (0x00000039dba00000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00000039cfc00000) > > libm.so.6 => /lib64/libm.so.6 (0x00000039cf800000) > > libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000039d5800000) > > librt.so.1 => /lib64/librt.so.1 (0x00000039d3800000) > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039d0000000) > > libc.so.6 => /lib64/libc.so.6 (0x00000039cf400000) > > /lib64/ld-linux-x86-64.so.2 (0x00000039cec00000) > > > > i noticed that my PATH variable doesn't include /usr/local/lib, do you > > think this might be the problem? > > -james > > > > On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart <[1]dons@galois.com> > wrote: > > > > james.swaine: > > > We've had unbelievable problems getting past this ridiculous > > 'unable to > > > load object file or shared library libedit.so.0' error when > > attempting to > > > build the 6.10.1 source tree. We initially just built editline > in > > a user > > > directory and attempted to manipulate environment variables to > help > > the > > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) > - > > but this > > > did no good. > > > > > > We then just installed the editline package so it's available > > globally and > > > the libraries (specifically libedit.so.0) live in > /usr/local/lib, > > so it > > > should be found with no problem. Not so for ghc - same error. > > We're > > > running this on Red Hat. > > > > What does ldd say? > > > > It should say something like this (on Arch Linux): > > > > $ ldd /usr/lib/ghc-6.10.0/ghc > > linux-vdso.so.1 => (0x00007fffb09fe000) > > libedit.so.0 => /usr/lib/libedit.so.0 > (0x00007f6aa8479000) > > libncursesw.so.5 => /lib/libncursesw.so.5 > (0x00007f6aa820f000) > > libutil.so.1 => /lib/libutil.so.1 (0x00007f6aa800c000) > > libdl.so.2 => /lib/libdl.so.2 (0x00007f6aa7e08000) > > libm.so.6 => /lib/libm.so.6 (0x00007f6aa7b85000) > > libgmp.so.3 => /usr/lib/libgmp.so.3 > (0x00007f6aa7943000) > > librt.so.1 => /lib/librt.so.1 (0x00007f6aa773b000) > > libpthread.so.0 => /lib/libpthread.so.0 > (0x00007f6aa7520000) > > libc.so.6 => /lib/libc.so.6 (0x00007f6aa71cc000) > > /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) > > > > For example, let's you know if the system linker can see libedit > (and > > the other > > C libraries GHC uses) > > > I'm part of a research group at Northwestern University that is > > exploring > > > the use of ghc and associated libraries for some upcoming > projects. > > It's > > > a shame that this is so difficult to even compile/install, and > > nobody > > > seems to be able to figure out what's wrong. > > > > Do you have the option of using a distro package? Has GHC 6.10.x > been > > packaged for > > your distro yet? Do you have the option of using GHC 6.8.x for now, > or > > is there some > > feature in 6.10.x you expect to depend on? > > -- Don > > > > References > > > > Visible links > > 1. mailto:dons@galois.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081114/fec8a18b/attachment.htm From dons at galois.com Fri Nov 14 13:13:27 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 14 13:07:47 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> <20081114180215.GF9750@scytale.galois.com> <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> Message-ID: <20081114181327.GH9750@scytale.galois.com> It sounds like your tree is mucked up somehow. The process should be quite simple: * download the ghc binary release for your platform (e.g. x86_64/linux) * set LD_LIBRARY_PATH to include the directory of any non-standard dynamic libraries. And you are done. Can you try this? Since this is working for all the other x86_64 users, I suspect you may have just missed a step in the process (perhaps setting the wrong environment variable?). As Simon Marlow said, if your source build is failing, you should post the full logs online of the build process, so we can see which libraries or tools are missing from your development environment, such that the build fails. -- Don james.swaine: > we tried that, but then we got this error: > > grep: packages: No such file or directory > make -C libraries boot > make[1]: Entering directory `/home/jswaine/ghc/ghc-6.10.1/ > > libraries' > mkdir bootstrapping > mkdir: cannot create directory `bootstrapping': File exists > make[1]: [cabal-bin] Error 1 (ignored) > /home/jswaine/ghc/ghc-6.10.1/ghc/ghc -Wall -DCABAL_VERSION=1,6,0,1 -odir > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -hidir > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping > -i/home/jswaine/ghc/ghc-6.10.1/libraries/Cabal > -i/home/jswaine/ghc/ghc-6.10.1/libraries/filepath > -i/home/jswaine/ghc/ghc-6.10.1/libraries/hpc --make cabal-bin -o > cabal-bin > ghc: missing -B option > make[1]: *** [cabal-bin] Error 1 > make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' > make: *** [stage1] Error 2 > > which still looks to me like it's somewhat related to linking (the > assumption was that -B is used for this sort of thing - linking to > libraries in unusual directories). but this option isn't listed in the > ghc flag reference. that was when we decided to just install the editline > package so it would be where it normally is (/usr/local/lib), but that got > us back to the original error message. ugh. > > -james > > On Fri, Nov 14, 2008 at 12:02 PM, Don Stewart <[1]dons@galois.com> wrote: > > Is your LD_LIBRARY_PATH environment variable exported, and set to > include the path to the lib dir that libedit lives in? > > e.g. > $ echo $LD_LIBRARY_PATH > /home/dons/lib > > Allows the system linker to find things in my home dir. > > james.swaine: > > it says: > > > > libedit.so.0 => not found > > libncurses.so.5 => /usr/lib64/libncurses.so.5 > (0x00000039e2200000) > > libutil.so.1 => /lib64/libutil.so.1 (0x00000039dba00000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00000039cfc00000) > > libm.so.6 => /lib64/libm.so.6 (0x00000039cf800000) > > libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000039d5800000) > > librt.so.1 => /lib64/librt.so.1 (0x00000039d3800000) > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039d0000000) > > libc.so.6 => /lib64/libc.so.6 (0x00000039cf400000) > > /lib64/ld-linux-x86-64.so.2 (0x00000039cec00000) > > > > i noticed that my PATH variable doesn't include /usr/local/lib, do > you > > think this might be the problem? > > -james > > > > On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart > <[1][2]dons@galois.com> wrote: > > > > james.swaine: > > > We've had unbelievable problems getting past this ridiculous > > 'unable to > > > load object file or shared library libedit.so.0' error when > > attempting to > > > build the 6.10.1 source tree. We initially just built > editline in > > a user > > > directory and attempted to manipulate environment variables > to help > > the > > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and > CPATH) - > > but this > > > did no good. > > > > > > We then just installed the editline package so it's > available > > globally and > > > the libraries (specifically libedit.so.0) live in > /usr/local/lib, > > so it > > > should be found with no problem. Not so for ghc - same > error. > > We're > > > running this on Red Hat. > > > > What does ldd say? > > > > It should say something like this (on Arch Linux): > > > > $ ldd /usr/lib/ghc-6.10.0/ghc > > linux-vdso.so.1 => (0x00007fffb09fe000) > > libedit.so.0 => /usr/lib/libedit.so.0 > (0x00007f6aa8479000) > > libncursesw.so.5 => /lib/libncursesw.so.5 > (0x00007f6aa820f000) > > libutil.so.1 => /lib/libutil.so.1 > (0x00007f6aa800c000) > > libdl.so.2 => /lib/libdl.so.2 > (0x00007f6aa7e08000) > > libm.so.6 => /lib/libm.so.6 (0x00007f6aa7b85000) > > libgmp.so.3 => /usr/lib/libgmp.so.3 > (0x00007f6aa7943000) > > librt.so.1 => /lib/librt.so.1 > (0x00007f6aa773b000) > > libpthread.so.0 => /lib/libpthread.so.0 > (0x00007f6aa7520000) > > libc.so.6 => /lib/libc.so.6 (0x00007f6aa71cc000) > > /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) > > > > For example, let's you know if the system linker can see libedit > (and > > the other > > C libraries GHC uses) > > > I'm part of a research group at Northwestern University that > is > > exploring > > > the use of ghc and associated libraries for some upcoming > projects. > > It's > > > a shame that this is so difficult to even compile/install, > and > > nobody > > > seems to be able to figure out what's wrong. > > > > Do you have the option of using a distro package? Has GHC 6.10.x > been > > packaged for > > your distro yet? Do you have the option of using GHC 6.8.x for > now, or > > is there some > > feature in 6.10.x you expect to depend on? > > -- Don > > > > References > > > > Visible links > > 1. mailto:[3]dons@galois.com > > References > > Visible links > 1. mailto:dons@galois.com > 2. mailto:dons@galois.com > 3. mailto:dons@galois.com From duncan.coutts at worc.ox.ac.uk Fri Nov 14 13:22:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 14 13:16:27 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> <20081114180215.GF9750@scytale.galois.com> <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> Message-ID: <1226686924.17214.418.camel@localhost> On Fri, 2008-11-14 at 12:09 -0600, James Swaine wrote: > we tried that, but then we got this error: > ghc: missing -B option > which still looks to me like it's somewhat related to linking (the > assumption was that -B is used for this sort of thing - linking to > libraries in unusual directories). The ghc -B option is not related to linking. The ghc program is actually a shell script that calls the real ghc program with the -B flag to tell ghc where to look for it's libraries and other config files. For example my /usr/local/bin/ghc-6.8.2 is: #!/bin/sh GHCBIN=/usr/local/lib64/ghc-6.8.2/ghc-6.8.2 TOPDIROPT=-B/usr/local/lib64/ghc-6.8.2 exec $GHCBIN $TOPDIROPT ${1+"$@"} > but this option isn't listed in the ghc flag reference. It's internal. > that was when we decided to just install the editline package so it > would be where it normally is (/usr/local/lib), but that got us back > to the original error message. ugh. I think what that did was add an extra error that you hit before this one. On fixing that error you got back to this original error. So it looks to me like your bootstrapping ghc is messed up. If it's not getting the -B option then perhaps the ghc shell script is messed up. Does your bootstrapping compiler work at all for other things? Duncan From james.swaine at gmail.com Fri Nov 14 13:22:29 2008 From: james.swaine at gmail.com (James Swaine) Date: Fri Nov 14 13:16:51 2008 Subject: more libedit.so.0 issues In-Reply-To: <20081114181327.GH9750@scytale.galois.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> <20081114180215.GF9750@scytale.galois.com> <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> <20081114181327.GH9750@scytale.galois.com> Message-ID: <5195fdde0811141022y311c513k6409376cccc7e667@mail.gmail.com> we tried it exactly as you describe below (twice). after it failed the first time, we deleted everything, redownloaded, and tried again. but i know the process works - i've done it successfully on two other machines (though this is the only red hat machine i've ever attempted this on). are there any flags i need to pass to enable verbose logging, or does the build process always log everything? also - where do these log files go, and where should i post them? thanks for you help. -james On Fri, Nov 14, 2008 at 12:13 PM, Don Stewart wrote: > It sounds like your tree is mucked up somehow. > > The process should be quite simple: > > * download the ghc binary release for your platform (e.g. x86_64/linux) > * set LD_LIBRARY_PATH to include the directory of any non-standard > dynamic libraries. > > And you are done. > > Can you try this? > > Since this is working for all the other x86_64 users, I suspect you may > have just missed a step in the process (perhaps setting the wrong > environment variable?). > > As Simon Marlow said, if your source build is failing, you should post > the full logs online of the build process, so we can see which libraries > or tools are missing from your development environment, such that the > build fails. > > -- Don > > james.swaine: > > we tried that, but then we got this error: > > > > grep: packages: No such file or directory > > make -C libraries boot > > make[1]: Entering directory `/home/jswaine/ghc/ghc-6.10.1/ > > > > libraries' > > mkdir bootstrapping > > mkdir: cannot create directory `bootstrapping': File exists > > make[1]: [cabal-bin] Error 1 (ignored) > > /home/jswaine/ghc/ghc-6.10.1/ghc/ghc -Wall -DCABAL_VERSION=1,6,0,1 > -odir > > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -hidir > > /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping > > -i/home/jswaine/ghc/ghc-6.10.1/libraries/Cabal > > -i/home/jswaine/ghc/ghc-6.10.1/libraries/filepath > > -i/home/jswaine/ghc/ghc-6.10.1/libraries/hpc --make cabal-bin -o > > cabal-bin > > ghc: missing -B option > > make[1]: *** [cabal-bin] Error 1 > > make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' > > make: *** [stage1] Error 2 > > > > which still looks to me like it's somewhat related to linking (the > > assumption was that -B is used for this sort of thing - linking to > > libraries in unusual directories). but this option isn't listed in > the > > ghc flag reference. that was when we decided to just install the > editline > > package so it would be where it normally is (/usr/local/lib), but that > got > > us back to the original error message. ugh. > > > > -james > > > > On Fri, Nov 14, 2008 at 12:02 PM, Don Stewart <[1]dons@galois.com> > wrote: > > > > Is your LD_LIBRARY_PATH environment variable exported, and set to > > include the path to the lib dir that libedit lives in? > > > > e.g. > > $ echo $LD_LIBRARY_PATH > > /home/dons/lib > > > > Allows the system linker to find things in my home dir. > > > > james.swaine: > > > it says: > > > > > > libedit.so.0 => not found > > > libncurses.so.5 => /usr/lib64/libncurses.so.5 > > (0x00000039e2200000) > > > libutil.so.1 => /lib64/libutil.so.1 (0x00000039dba00000) > > > libdl.so.2 => /lib64/libdl.so.2 (0x00000039cfc00000) > > > libm.so.6 => /lib64/libm.so.6 (0x00000039cf800000) > > > libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000039d5800000) > > > librt.so.1 => /lib64/librt.so.1 (0x00000039d3800000) > > > libpthread.so.0 => /lib64/libpthread.so.0 > (0x00000039d0000000) > > > libc.so.6 => /lib64/libc.so.6 (0x00000039cf400000) > > > /lib64/ld-linux-x86-64.so.2 (0x00000039cec00000) > > > > > > i noticed that my PATH variable doesn't include /usr/local/lib, > do > > you > > > think this might be the problem? > > > -james > > > > > > On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart > > <[1][2]dons@galois.com> wrote: > > > > > > james.swaine: > > > > We've had unbelievable problems getting past this > ridiculous > > > 'unable to > > > > load object file or shared library libedit.so.0' error > when > > > attempting to > > > > build the 6.10.1 source tree. We initially just built > > editline in > > > a user > > > > directory and attempted to manipulate environment > variables > > to help > > > the > > > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and > > CPATH) - > > > but this > > > > did no good. > > > > > > > > We then just installed the editline package so it's > > available > > > globally and > > > > the libraries (specifically libedit.so.0) live in > > /usr/local/lib, > > > so it > > > > should be found with no problem. Not so for ghc - same > > error. > > > We're > > > > running this on Red Hat. > > > > > > What does ldd say? > > > > > > It should say something like this (on Arch Linux): > > > > > > $ ldd /usr/lib/ghc-6.10.0/ghc > > > linux-vdso.so.1 => (0x00007fffb09fe000) > > > libedit.so.0 => /usr/lib/libedit.so.0 > > (0x00007f6aa8479000) > > > libncursesw.so.5 => /lib/libncursesw.so.5 > > (0x00007f6aa820f000) > > > libutil.so.1 => /lib/libutil.so.1 > > (0x00007f6aa800c000) > > > libdl.so.2 => /lib/libdl.so.2 > > (0x00007f6aa7e08000) > > > libm.so.6 => /lib/libm.so.6 > (0x00007f6aa7b85000) > > > libgmp.so.3 => /usr/lib/libgmp.so.3 > > (0x00007f6aa7943000) > > > librt.so.1 => /lib/librt.so.1 > > (0x00007f6aa773b000) > > > libpthread.so.0 => /lib/libpthread.so.0 > > (0x00007f6aa7520000) > > > libc.so.6 => /lib/libc.so.6 > (0x00007f6aa71cc000) > > > /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) > > > > > > For example, let's you know if the system linker can see > libedit > > (and > > > the other > > > C libraries GHC uses) > > > > I'm part of a research group at Northwestern University > that > > is > > > exploring > > > > the use of ghc and associated libraries for some > upcoming > > projects. > > > It's > > > > a shame that this is so difficult to even > compile/install, > > and > > > nobody > > > > seems to be able to figure out what's wrong. > > > > > > Do you have the option of using a distro package? Has GHC > 6.10.x > > been > > > packaged for > > > your distro yet? Do you have the option of using GHC 6.8.x > for > > now, or > > > is there some > > > feature in 6.10.x you expect to depend on? > > > -- Don > > > > > > References > > > > > > Visible links > > > 1. mailto:[3]dons@galois.com > > > > References > > > > Visible links > > 1. mailto:dons@galois.com > > 2. mailto:dons@galois.com > > 3. mailto:dons@galois.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081114/a19de21c/attachment-0001.htm From allbery at ece.cmu.edu Fri Nov 14 14:19:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Nov 14 14:13:28 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> <20081114180215.GF9750@scytale.galois.com> <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> Message-ID: <1A4C4BC8-50B3-4662-944E-D77C441EE272@ece.cmu.edu> On 2008 Nov 14, at 13:09, James Swaine wrote: > /home/jswaine/ghc/ghc-6.10.1/ghc/ghc -Wall -DCABAL_VERSION=1,6,0,1 - > odir /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -hidir / > home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -i/home/jswaine/ > ghc/ghc-6.10.1/libraries/Cabal -i/home/jswaine/ghc/ghc-6.10.1/ > libraries/filepath -i/home/jswaine/ghc/ghc-6.10.1/libraries/hpc -- > make cabal-bin -o cabal-bin > ghc: missing -B option > which still looks to me like it's somewhat related to linking (the > assumption was that -B is used for this sort of thing - linking The -B option to ghc tells it where the GHC base directory is. (The ghc in the public bin directory is a shell script which runs the real ghc passing -B to point to its base directory.) If you see that error, something is *very* wrong with your build tree. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081114/055a4010/attachment.htm From colin at colina.demon.co.uk Sat Nov 15 07:10:12 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Nov 15 07:04:32 2008 Subject: Linking to Haskell code from an external program Message-ID: I am trying to call a Haskell function from an Eiffel program, using C as an intermediary. For starters, I compiled and ran a variation of the program shown in http://haskell.org/haskellwiki/Calling_Haskell_from_C, to make sure I had the C-code right. I then attempted to move it into Eiffel. I can compile the C code OK, but I'm running into problems with linking. I solved most of the problems by adding the -v flag to the call to ghc which I used to link the original (haskell + c only) program, and cut-and-paste the linker options from their into the Eiffel configuration file. This isn't really satisfactory - I would like some automatic way to determine what the flags should be. The remaining problem has me stumped. I am getting the following messages: big_file_C4_c.c:(.text+0x9f4f): undefined reference to `__stginit_Fib' /home/colin/fib/Fib_stub.o: In function `stginit_export_Fib_zdffibonaccizuhszuaQO': Fib_stub.c:(.text+0x5): undefined reference to `Fib_zdffibonaccizuhszuaQO_closure' /home/colin/fib/Fib_stub.o: In function `fibonacci_hs': Fib_stub.c:(.text+0x32): undefined reference to `Fib_zdffibonaccizuhszuaQO_closure' The Haskell code looks like this: >{-# LANGUAGE ForeignFunctionInterface #-} > > module Fib where > > import Foreign.C.Types > import CString > > fibonacci :: Int -> String > fibonacci n = show (fibs !! n) > where fibs = 0 : 1 : zipWith (+) fibs (tail fibs) > > fibonacci_hs :: CInt -> IO CString > fibonacci_hs = newCString . fibonacci . fromIntegral > > foreign export ccall fibonacci_hs :: CInt -> IO CString And the C code (in an Eiffel wrapper) looks like this: haskell_fib (n: INTEGER): POINTER is -- String representation of `n'th Fibonacci number as a string external "C inline use ,%"HsFFI.h%"" alias "[ #ifdef __GLASGOW_HASKELL__ #include "Fib_stub.h" extern void __stginit_Fib ( void ); #endif int argc; char *argv[0]; argc = 0; hs_init(&argc, &argv); #ifdef __GLASGOW_HASKELL__ hs_add_root(__stginit_Fib); #endif return (fibonacci_hs($n)); hs_exit(); ]" end I can't find any mention of the word "fibonacci" in the output from the ghc run, and I don't know where this _closure stuff is coming from. Can you help? -- Colin Adams Preston Lancashire From colin at colina.demon.co.uk Sat Nov 15 08:16:27 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Nov 15 08:10:46 2008 Subject: Linking to Haskell code from an external program In-Reply-To: (Colin Paul Adams's message of "Sat\, 15 Nov 2008 12\:10\:12 +0000") References: Message-ID: Embarassing - I simply forgot to include Fib.o in the link. So it links now (program crashes, but I can try to sort that out). I'm still intereted in knowing how to automatically get the list of required libraries. >>>>> "Colin" == Colin Paul Adams writes: Colin> I am trying to call a Haskell function from an Eiffel Colin> program, using C as an intermediary. Colin> For starters, I compiled and ran a variation of the program Colin> shown in Colin> http://haskell.org/haskellwiki/Calling_Haskell_from_C, to Colin> make sure I had the C-code right. Colin> I then attempted to move it into Eiffel. I can compile the Colin> C code OK, but I'm running into problems with linking. Colin> I solved most of the problems by adding the -v flag to the Colin> call to ghc which I used to link the original (haskell + c Colin> only) program, and cut-and-paste the linker options from Colin> their into the Eiffel configuration file. This isn't really Colin> satisfactory - I would like some automatic way to determine Colin> what the flags should be. Colin> The remaining problem has me stumped. I am getting the Colin> following messages: Colin> big_file_C4_c.c:(.text+0x9f4f): undefined reference to Colin> `__stginit_Fib' /home/colin/fib/Fib_stub.o: In function Colin> `stginit_export_Fib_zdffibonaccizuhszuaQO': Colin> Fib_stub.c:(.text+0x5): undefined reference to Colin> `Fib_zdffibonaccizuhszuaQO_closure' Colin> /home/colin/fib/Fib_stub.o: In function `fibonacci_hs': Colin> Fib_stub.c:(.text+0x32): undefined reference to Colin> `Fib_zdffibonaccizuhszuaQO_closure' Colin> The Haskell code looks like this: >> {-# LANGUAGE ForeignFunctionInterface #-} >> >> module Fib where >> >> import Foreign.C.Types import CString >> >> fibonacci :: Int -> String fibonacci n = show (fibs !! n) where >> fibs = 0 : 1 : zipWith (+) fibs (tail fibs) >> >> fibonacci_hs :: CInt -> IO CString fibonacci_hs = newCString >> . fibonacci . fromIntegral >> >> foreign export ccall fibonacci_hs :: CInt -> IO CString Colin> And the C code (in an Eiffel wrapper) looks like this: Colin> haskell_fib (n: INTEGER): POINTER is -- String Colin> representation of `n'th Fibonacci number as a string Colin> external "C inline use ,%"HsFFI.h%"" alias "[ Colin> #ifdef __GLASGOW_HASKELL__ #include "Fib_stub.h" extern Colin> void __stginit_Fib ( void ); #endif Colin> int argc; char *argv[0]; argc = 0; Colin> hs_init(&argc, &argv); #ifdef __GLASGOW_HASKELL__ Colin> hs_add_root(__stginit_Fib); #endif return Colin> (fibonacci_hs($n)); hs_exit(); ]" end Colin> I can't find any mention of the word "fibonacci" in the Colin> output from the ghc run, and I don't know where this Colin> _closure stuff is coming from. Can you help? -- Colin Colin> Adams Preston Lancashire Colin> _______________________________________________ Colin> Glasgow-haskell-users mailing list Colin> Glasgow-haskell-users@haskell.org Colin> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Colin Adams Preston Lancashire From colin at colina.demon.co.uk Sat Nov 15 12:31:12 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Nov 15 12:25:33 2008 Subject: Crash in garbage collector Message-ID: I managed to get calling a Haskell function from an Eiffel program working with one Eiffel compiler, but when I compiled the program with a different Eiffel compiler, and ran it, I get a crash, apparently in the GHC garbage collector: (gdb) backtrace #0 0x0000000000452fc0 in evacuate () #1 0x000000000043b7f8 in scavenge_static () #2 0x0000000000439ea4 in GarbageCollect () #3 0x00000000004351df in scheduleDoGC () #4 0x00000000004353da in exitScheduler () #5 0x00000000004345a2 in hs_exit_ () #6 0x000000000041900c in T21f3 (C=0x1971f80, a1=7) at fib1.c:1200 #7 0x00000000004191a8 in T21c10 () at fib1.c:1000 #8 0x0000000000419356 in main (argc=, argv=) at fib1.c:11616 Can you suggest how I should go about investigating this problem further? -- Colin Adams Preston Lancashire From jwlato at gmail.com Sat Nov 15 17:07:33 2008 From: jwlato at gmail.com (John Lato) Date: Sat Nov 15 17:01:51 2008 Subject: cross module optimization issues Message-ID: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> Hello, I have a problem with a package I'm working on, and I don't have any idea how to sort out the current problem. One part of my package is in one monolithic module, without an export list, which works fine. However, when I've started to separate out certain functions into another module, and added an export list to one of the modules, which dramatically decreases performance. The memory behavior (as shown by -hT) is also quite different, with substantial memory usage by "FUN_2_0". Are there any suggestions as to how I could improve this? Thanks, John From dons at galois.com Sat Nov 15 17:09:56 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 15 17:04:13 2008 Subject: cross module optimization issues In-Reply-To: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> Message-ID: <20081115220956.GT15077@scytale.galois.com> jwlato: > Hello, > > I have a problem with a package I'm working on, and I don't have any > idea how to sort out the current problem. > > One part of my package is in one monolithic module, without an export > list, which works fine. However, when I've started to separate out > certain functions into another module, and added an export list to one > of the modules, which dramatically decreases performance. The memory > behavior (as shown by -hT) is also quite different, with substantial > memory usage by "FUN_2_0". Are there any suggestions as to how I > could improve this? > Are you compiling with aggressive cross-module optimisations on (e.g. -O2)? You may have to add explicit inlining pragmas (check the Core output), to ensure key functions are exported in their entirety. -- Don From conal at conal.net Sun Nov 16 01:33:40 2008 From: conal at conal.net (Conal Elliott) Date: Sun Nov 16 01:27:56 2008 Subject: "A lazy (~) pattern cannot bind existential type variables"? Message-ID: What is the reasoning behind the ghc restriction that "A lazy (~) pattern cannot bind existential type variables"? This error came up for me in the following code: -- | Add a continuation. data WithCont h b c = forall a. WC (h b a) (a -> c) instance Functor (WithCont h b) where fmap g ~(WC f k) = WC f (fmap g k) The error message: A lazy (~) pattern cannot bind existential type variables `a' is a rigid type variable bound by the constructor `WC' at Data/Zip/FoldL.hs:66:11 In the pattern: ~(WC f k) I also tried this variation: instance Functor (WithCont h b) where fmap g wc = WC f (fmap g k) where WC f k = wc and got this message: My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors. Instead, use a case-expression, or do-notation, to unpack the constructor. In the binding group for WC f k In a pattern binding: WC f k = wc I can work around these limitations by using a lambda: instance Functor (WithCont h b) where fmap g = \ (WC f k) -> WC f (fmap g k) which I believe is equivalent. Please correct me if I'm wrong here. For infix definitions like (<*>), however, this work-around is less pleasant. For instance, (<*>) = \ (WC hf hk) (WC xf xk) -> WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) instead of the prettier but forbidden ~(WC hf hk) <*> ~(WC xf xk) = WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) If you're curious what these definitions are about, see http://conal.net/blog/posts/enhancing-a-zip/ . Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081115/d65c53af/attachment-0001.htm From igloo at earth.li Sun Nov 16 09:41:44 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 16 09:36:00 2008 Subject: GHC on powerpc (OS X): segmentation fault In-Reply-To: <491BE629.202@dfki.de> References: <491964AF.5080607@list.mightyreason.com> <49196A74.3030009@dfki.de> <49197198.8000500@list.mightyreason.com> <4919784D.3090601@dfki.de> <20081112214628.GA7896@matrix.chaos.earth.li> <491BE629.202@dfki.de> Message-ID: <20081116144144.GA9795@matrix.chaos.earth.li> On Thu, Nov 13, 2008 at 09:32:41AM +0100, Christian Maeder wrote: > > libreadline.5.2.dylib is no longer needed, since ghc uses > libedit.2.dylib (which uses libncurses.5.dylib, that should be also > under /usr/lib/) Whoops, thanks. Now fixed. Thanks Ian From conal at conal.net Sun Nov 16 11:06:35 2008 From: conal at conal.net (Conal Elliott) Date: Sun Nov 16 11:00:53 2008 Subject: "A lazy (~) pattern cannot bind existential type variables"? In-Reply-To: <2f9b2d30811160218p54a3b210xdbb53c4ffd539650@mail.gmail.com> References: <2f9b2d30811160218p54a3b210xdbb53c4ffd539650@mail.gmail.com> Message-ID: > > > data HasShow = forall a. Show a => HasShow a > > weird ~(HasShow x) = HasShow x > > Now, what Show context is referred to by the result of "weird undefined"? > I'd expect bottom, just as with matching ~(x,y) against bottom. The lambda is not the same as the "where" clause. Let's desugar a few > of the code snippets you gave me: [...] > Thanks. I get it now, and I see that the only version that makes it through the type-checker is the one that defeats laziness and therefore generally breaks these nice morphism properties. That algebraic failure seems reason enough to try fixing ghc. - Conal On Sun, Nov 16, 2008 at 2:18 AM, Ryan Ingram wrote: > > My brain just exploded. > > Best compiler error message ever. > > I think that existential quantification with lazy matches can do some > crazy things to the type system. > > > lazyPair ~(a,b) = (a,b). > > So, lazyPair undefined = (undefined, undefined); it makes any pair > "more defined". But what does this do when you have an existential > context? > > > data HasShow = forall a. Show a => HasShow a > > weird ~(HasShow x) = HasShow x > > Now, what Show context is referred to by the result of "weird undefined"? > > > useShow (HasShow x) = show x > > broken = useShow (weird undefined) > > It's likely that there is a way to solve this; you need to force the > pattern match to take place anywhere that the existential type gets > applied (in the System F sense). But I think that doing so is a lot > more difficult for the compiler author, and it's an edge case in the > language. > > The lambda is not the same as the "where" clause. Let's desugar a few > of the code snippets you gave me: > > > fmap g ~(WC f k) = WC f (fmap g k) > => fmap = \g wc -> let (WC f k) = wc in WC f (fmap g k) > > > fmap g wc = WC f (fmap g k) > > where WC f k = wc > => fmap = \g wc -> let (WC f k) = wc in WC f (fmap g k) > (same as above) > > > fmap g = \ (WC f k) -> WC f (fmap g k) > => fmap = \g wc -> case wc of (WC f k) -> WC f (fmap g k) > (i.e. the same as not using a lazy pattern at all) > > I'll think about this and see if I can come up with a workaround. I'm > not sure it's possible in GHC. > > -- ryan > > > On Sat, Nov 15, 2008 at 10:33 PM, Conal Elliott wrote: > > What is the reasoning behind the ghc restriction that "A lazy (~) pattern > > cannot bind existential type variables"? > > > > This error came up for me in the following code: > > > > -- | Add a continuation. > > data WithCont h b c = forall a. WC (h b a) (a -> c) > > > > instance Functor (WithCont h b) where > > fmap g ~(WC f k) = WC f (fmap g k) > > > > The error message: > > > > A lazy (~) pattern cannot bind existential type variables > > `a' is a rigid type variable bound by > > the constructor `WC' at Data/Zip/FoldL.hs:66:11 > > In the pattern: ~(WC f k) > > > > I also tried this variation: > > > > instance Functor (WithCont h b) where > > fmap g wc = WC f (fmap g k) > > where WC f k = wc > > > > and got this message: > > > > My brain just exploded. > > I can't handle pattern bindings for existentially-quantified > > constructors. > > Instead, use a case-expression, or do-notation, to unpack the > > constructor. > > In the binding group for > > WC f k > > In a pattern binding: WC f k = wc > > > > I can work around these limitations by using a lambda: > > > > instance Functor (WithCont h b) where > > fmap g = \ (WC f k) -> WC f (fmap g k) > > > > which I believe is equivalent. Please correct me if I'm wrong here. > > > > For infix definitions like (<*>), however, this work-around is less > > pleasant. > > For instance, > > > > (<*>) = \ (WC hf hk) (WC xf xk) -> > > WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) > > > > instead of the prettier but forbidden > > > > ~(WC hf hk) <*> ~(WC xf xk) = > > WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) > > > > > > If you're curious what these definitions are about, see > > http://conal.net/blog/posts/enhancing-a-zip/ . > > > > Thanks, - Conal > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081116/f24e6cf3/attachment.htm From colin at colina.demon.co.uk Sun Nov 16 13:08:18 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 16 13:02:35 2008 Subject: RPM for 6.10.1 on Fedora? Message-ID: I have 6.8.2 installed here (Fedora 9 x86_64). Doing a yum update says no update available. Does this mean I have yum wrongly configured, or is it just the case that the 6.10.1 roms haven't been built yet? -- Colin Adams Preston Lancashire From igloo at earth.li Sun Nov 16 13:14:30 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 16 13:08:45 2008 Subject: Crash in garbage collector In-Reply-To: References: Message-ID: <20081116181430.GA10839@matrix.chaos.earth.li> On Sat, Nov 15, 2008 at 05:31:12PM +0000, Colin Paul Adams wrote: > > Can you suggest how I should go about investigating this problem further? Try linking with -debug, and running with +RTS -DS. That might reveal the problem, and if not you should get more useful info from gdb. Thanks Ian From colin at colina.demon.co.uk Sun Nov 16 13:49:20 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 16 13:43:36 2008 Subject: Crash in garbage collector In-Reply-To: <20081116181430.GA10839@matrix.chaos.earth.li> (Ian Lynagh's message of "Sun\, 16 Nov 2008 18\:14\:30 +0000") References: <20081116181430.GA10839@matrix.chaos.earth.li> Message-ID: >>>>> "Ian" == Ian Lynagh writes: Ian> On Sat, Nov 15, 2008 at 05:31:12PM +0000, Colin Paul Adams wrote: >> > Can you suggest how I should go about investigating this problem >> further? Ian> Try linking with -debug, and running with +RTS -DS. That Ian> might reveal the problem, and if not you should get more Ian> useful info from gdb. I added the -debug link flag. Add I added +RTS and -DS as command-line arguments in the call to hs_init() (I presume that's what you meant me to do). I can't notice any difference. Where should I be looking for the information? -- Colin Adams Preston Lancashire From judah.jacobson at gmail.com Sun Nov 16 14:06:16 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Nov 16 14:00:30 2008 Subject: editline in ghc-6.10.1 under Solaris In-Reply-To: <4918280C.3000607@dfki.de> References: <4918280C.3000607@dfki.de> Message-ID: <6d74b0d20811161106m7d43ef12v353b73d15a852ede@mail.gmail.com> On Mon, Nov 10, 2008 at 4:24 AM, Christian Maeder wrote: > Hallo Judah, > > I've build > http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz > and it was linked against libcurses: > > -bash-3.1$ ldd /usr/local/lib/libedit.so.0 > libcurses.so.1 => /lib/libcurses.so.1 > libc.so.1 => /lib/libc.so.1 > libgcc_s.so.1 => > /usr/local/lang/lib/gcc/i386-pc-solaris2.10/4.2.2/libgcc_s.so.1 > libm.so.2 => /lib/libm.so.2 > > When building ghc-6.10.1 your configure script prefers ncurses over > curses, therefore I get an additional dependency for ghc: > > libncurses.so.5 => /usr/local/lib/libncurses.so.5 > > For (the usual) dynamic linking just "-ledit" is enough, only for static > linking "-lcurses" or "-lncurses" is needed, otherwise "term.o" is the > "Undefined symbol". > > (By chance, I've only libncurses.a and no libcurses.a for static linking.) > > I'm not sure which dependency to prefer. configure of > libedit-20080712-2.1 prefers curses over ncurses. > > Cheers Christian > Christian, I've updated the repo at http://code.haskell.org/editline/ with a fix. The editline package now behaves the same way as libedit (preferring to link against curses over ncurses). Can you please verify whether that works for you? Thanks, -Judah From igloo at earth.li Sun Nov 16 14:19:47 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 16 14:14:03 2008 Subject: Crash in garbage collector In-Reply-To: References: <20081116181430.GA10839@matrix.chaos.earth.li> Message-ID: <20081116191947.GA5556@matrix.chaos.earth.li> On Sun, Nov 16, 2008 at 06:49:20PM +0000, Colin Paul Adams wrote: > > I added the -debug link flag. > > Add I added +RTS and -DS as command-line arguments in the call to > hs_init() (I presume that's what you meant me to do). Yes, that sounds like it should work. > I can't notice any difference. Where should I be looking for the information? If you were lucky it would abort with an assertion failure. Anyway, gdb should now have debugging symbols to work with. Thanks Ian From colin at colina.demon.co.uk Sun Nov 16 14:34:26 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 16 14:28:42 2008 Subject: Crash in garbage collector In-Reply-To: <20081116191947.GA5556@matrix.chaos.earth.li> (Ian Lynagh's message of "Sun\, 16 Nov 2008 19\:19\:47 +0000") References: <20081116181430.GA10839@matrix.chaos.earth.li> <20081116191947.GA5556@matrix.chaos.earth.li> Message-ID: >>>>> "Ian" == Ian Lynagh writes: Ian> If you were lucky it would abort with an assertion Ian> failure. Anyway, gdb should now have debugging symbols to Ian> work with. It already did (I passed the -g option to gcc). I guess I will need to install the GHC source to get file listings. That sounds like hard work. I think I'll wait for 6.10.1 . -- Colin Adams Preston Lancashire From igloo at earth.li Sun Nov 16 15:05:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 16 14:59:50 2008 Subject: extra libraries vs. cabal libraries (ghc-6.10.1) In-Reply-To: <49119CB7.4060606@dfki.de> References: <49119CB7.4060606@dfki.de> Message-ID: <20081116200536.GA26797@matrix.chaos.earth.li> On Wed, Nov 05, 2008 at 02:16:39PM +0100, Christian Maeder wrote: > > the documentation of extra libraries is listed under > share/doc/ghc/libraries/ > > 1. Is it possible to add cabal packages in the same way? How? If you do cd share/doc/ghc/libraries sh gen_contents_index then the contents and index pages will be regenerated, using */*.haddock Unfortunately, this was broken in the 6.10.1 release, but you can get a fixed script from the HEAD or 6.10 branch (in the libraries directory). Thanks Ian From conal at conal.net Sun Nov 16 23:54:39 2008 From: conal at conal.net (Conal Elliott) Date: Sun Nov 16 23:48:53 2008 Subject: problem with echo prompting in ghci (visible in emacs) In-Reply-To: References: Message-ID: I'm still looking for a solution to this problem. I've heard from a few people who are affected also, but not any solution. Barring a solution to ghci's behavior, does someone have an emacs-based workaround? - Conal On Tue, Nov 11, 2008 at 4:41 PM, Conal Elliott wrote: > ghci echoes all of my input in emacs, when run via haskell-mode or via "M-x > shell", which then confuses various useful haskell-mode features. I built > it from sources. At the time I didn't have libedit-dev, so today I > installed libedit-dev (version 2.11~20080614 on ubuntu), did a clean make & > install, and I get exactly the same behavior. > > Does anyone have experience in getting through this problem? Willing to > help me out? > > Thanks, > > - Conal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081116/b673c826/attachment.htm From judah.jacobson at gmail.com Mon Nov 17 01:31:38 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Nov 17 01:25:51 2008 Subject: problem with echo prompting in ghci (visible in emacs) In-Reply-To: References: Message-ID: <6d74b0d20811162231x4aad6a5ch51ab24c795d7354b@mail.gmail.com> 2008/11/16 Conal Elliott : > I'm still looking for a solution to this problem. I've heard from a few > people who are affected also, but not any solution. > > Barring a solution to ghci's behavior, does someone have an emacs-based > workaround? > > - Conal > > On Tue, Nov 11, 2008 at 4:41 PM, Conal Elliott wrote: >> >> ghci echoes all of my input in emacs, when run via haskell-mode or via >> "M-x shell", which then confuses various useful haskell-mode features. I >> built it from sources. At the time I didn't have libedit-dev, so today I >> installed libedit-dev (version 2.11~20080614 on ubuntu), did a clean make & >> install, and I get exactly the same behavior. >> >> Does anyone have experience in getting through this problem? Willing to >> help me out? >> >> Thanks, >> >> - Conal >> > Hi Conal, The problem is that eshell tells subprocesses that they're running in a terminal (e.g., when queried via hIsTerminalDevice), but always echos user input itself regardless of the tty's ECHO attribute. This confuses libedit, which assumes that if it's connected to a terminal then it can turn off echoing in order to run its own rich line editor. In "M-x shell", you can work around this issue by starting ghci with, for example, "cat | ghci" to prevent ghci and libedit from trying to run as if in a terminal. Probably something similar could be done for haskell-mode; I'm not familiar enough with emacs to fix it myself. Incidentally, googling revealed that zsh has a similar issue: http://www.zsh.org/mla/users/2001/msg00014.html (section 3.10) Hope that helps, -Judah From marlowsd at gmail.com Mon Nov 17 07:28:08 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 17 07:22:25 2008 Subject: Linking to Haskell code from an external program In-Reply-To: References: Message-ID: <49216358.9060806@gmail.com> Colin Paul Adams wrote: > Embarassing - I simply forgot to include Fib.o in the link. > So it links now (program crashes, but I can try to sort that out). > > I'm still intereted in knowing how to automatically get the list of > required libraries. >>>>>> "Colin" == Colin Paul Adams writes: > > Colin> I am trying to call a Haskell function from an Eiffel > Colin> program, using C as an intermediary. > > Colin> For starters, I compiled and ran a variation of the program > Colin> shown in > Colin> http://haskell.org/haskellwiki/Calling_Haskell_from_C, to > Colin> make sure I had the C-code right. > > Colin> I then attempted to move it into Eiffel. I can compile the > Colin> C code OK, but I'm running into problems with linking. > > Colin> I solved most of the problems by adding the -v flag to the > Colin> call to ghc which I used to link the original (haskell + c > Colin> only) program, and cut-and-paste the linker options from > Colin> their into the Eiffel configuration file. This isn't really > Colin> satisfactory - I would like some automatic way to determine > Colin> what the flags should be. The only other way I can think of is to construct the arguments yourself by querying the package database, e.g. "ghc-pkg field ld-options rts", but you'll have to combine the information from several different fields of the packages you use, and basically reproduce what GHC does to construct the ld command line. Cheers, Simon From marlowsd at gmail.com Mon Nov 17 08:00:27 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 17 07:54:42 2008 Subject: Crash in garbage collector In-Reply-To: References: <20081116181430.GA10839@matrix.chaos.earth.li> <20081116191947.GA5556@matrix.chaos.earth.li> Message-ID: <49216AEB.7080703@gmail.com> Colin Paul Adams wrote: >>>>>> "Ian" == Ian Lynagh writes: > > Ian> If you were lucky it would abort with an assertion > Ian> failure. Anyway, gdb should now have debugging symbols to > Ian> work with. > > It already did (I passed the -g option to gcc). > > I guess I will need to install the GHC source to get file > listings. That sounds like hard work. I think I'll wait for 6.10.1 . If you're calling a Haskell library from C, the problem might be that you forgot hs_add_root(), or that your hs_add_root() isn't pointing to the right module (it should point to the module that transitively imports all the other modules in your library). You can use multiple hs_add_root() calls if necessary. Cheers, Simon From marlowsd at gmail.com Mon Nov 17 10:03:53 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 17 09:58:10 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: References: Message-ID: <492187D9.9000401@gmail.com> Rahul Kapoor wrote: > I cannot get GHC to work on a fresh ubuntu hardy machine: > > On installing using the package manager I get an error when > running ghci: > > "R_X86_64_32S relocation out of range:" - similar to > http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is > FreeBSD specific. > > I decided to install the binary distribution: after which running > ghci fails with error: > > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > ghc: internal error: mmap() returned memory outside 2Gb > (GHC version 6.10.1 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Aborted > > > I Added issues #2779 to Trac for the second case. > > Are there any possible work arounds for these problems? I've made a speculative fix. If you're able to test it, that would be very helpful: http://hackage.haskell.org/trac/ghc/ticket/2063 Cheers, Simon From marlowsd at gmail.com Mon Nov 17 10:47:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 17 10:41:33 2008 Subject: more libedit.so.0 issues In-Reply-To: <5195fdde0811141022y311c513k6409376cccc7e667@mail.gmail.com> References: <5195fdde0811132241o67b099d5ndf25721c10586a18@mail.gmail.com> <20081114070047.GA7966@scytale.galois.com> <5195fdde0811140818n412b1921t336d0d16c985176e@mail.gmail.com> <20081114180215.GF9750@scytale.galois.com> <5195fdde0811141009g45f4ed2en41eacac1cab3373e@mail.gmail.com> <20081114181327.GH9750@scytale.galois.com> <5195fdde0811141022y311c513k6409376cccc7e667@mail.gmail.com> Message-ID: <49219204.3050909@gmail.com> James Swaine wrote: > we tried it exactly as you describe below (twice). after it failed the > first time, we deleted everything, redownloaded, and tried again. but i > know the process works - i've done it successfully on two other machines > (though this is the only red hat machine i've ever attempted this on). > > are there any flags i need to pass to enable verbose logging, or does > the build process always log everything? also - where do these log > files go, and where should i post them? Do something like this: (./configure && make) 2>&1 | tee buid-log Then post your build-log wherever you like, and send us a pointer to it. Or just gzip it and send it to me or Igloo by email. Cheers, Simon From conal at conal.net Mon Nov 17 10:56:28 2008 From: conal at conal.net (Conal Elliott) Date: Mon Nov 17 10:50:43 2008 Subject: problem with echo prompting in ghci (visible in emacs) In-Reply-To: <6d74b0d20811162231x4aad6a5ch51ab24c795d7354b@mail.gmail.com> References: <6d74b0d20811162231x4aad6a5ch51ab24c795d7354b@mail.gmail.com> Message-ID: Thanks very much, Judah! Given this info, there's a fairly easy emacs haskell-mode work-around. I made a shell script "ghci-no-tty" in my ~/bin that contains # So ghci+readline won't echo input cat | /usr/local/bin/ghci $* and used "M-x customize-group" with the "haskell" group to set the "Haskell Program Name" variable to "/home/conal/bin/ghci-no-tty" (must be full path). Now there's no more input echoing, and commands like automatic signature insertion ("\C-c\C-t") work again. Hooray! - Conal On Sun, Nov 16, 2008 at 10:31 PM, Judah Jacobson wrote: > 2008/11/16 Conal Elliott : > > I'm still looking for a solution to this problem. I've heard from a few > > people who are affected also, but not any solution. > > > > Barring a solution to ghci's behavior, does someone have an emacs-based > > workaround? > > > > - Conal > > > > On Tue, Nov 11, 2008 at 4:41 PM, Conal Elliott wrote: > >> > >> ghci echoes all of my input in emacs, when run via haskell-mode or via > >> "M-x shell", which then confuses various useful haskell-mode features. > I > >> built it from sources. At the time I didn't have libedit-dev, so today > I > >> installed libedit-dev (version 2.11~20080614 on ubuntu), did a clean > make & > >> install, and I get exactly the same behavior. > >> > >> Does anyone have experience in getting through this problem? Willing to > >> help me out? > >> > >> Thanks, > >> > >> - Conal > >> > > > > Hi Conal, > > The problem is that eshell tells subprocesses that they're running in > a terminal (e.g., when queried via hIsTerminalDevice), but always > echos user input itself regardless of the tty's ECHO attribute. This > confuses libedit, which assumes that if it's connected to a terminal > then it can turn off echoing in order to run its own rich line editor. > > In "M-x shell", you can work around this issue by starting ghci with, > for example, "cat | ghci" to prevent ghci and libedit from trying to > run as if in a terminal. Probably something similar could be done for > haskell-mode; I'm not familiar enough with emacs to fix it myself. > > Incidentally, googling revealed that zsh has a similar issue: > http://www.zsh.org/mla/users/2001/msg00014.html (section 3.10) > > Hope that helps, > -Judah > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081117/d617968a/attachment-0001.htm From dominic.steinitz at blueyonder.co.uk Tue Nov 18 02:16:54 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Tue Nov 18 02:22:41 2008 Subject: 6.10.1 Bug? Message-ID: <49226BE6.2050101@blueyonder.co.uk> According to the hackage page, the Haskell Cryptography Library has a build failure. I couldn't find a bug reference when I searched for milestone 6.10.1 on trac. Should I report it? Has it been fixed? Thanks, Dominic. http://hackage.haskell.org/packages/archive/Crypto/4.1.0/logs/failure/ghc-6.10 > [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug From kyagrd at gmail.com Tue Nov 18 02:37:18 2008 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Tue Nov 18 02:31:51 2008 Subject: Cannot escape from a black hole in ghci 6.10.1 Message-ID: Dear GHC users I have both GHC 6.8.2 (debian unstable package) and GHC 6.8.10 (binary distribution from ghc homepage) installed. I was able to escape from a black hole in ghci 6.8.2 with Ctrl-C. For example, GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> let x = x + x Prelude> x ^CInterrupted. Prelude> x *** Exception: stack overflow Prelude> Interestingly, you will get a stack overflow when you try to escape from the black home for the second time. In ghci 6.10.1, I am not able to escape from a black hole with Ctrl-C. GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> let x = x + x Prelude> x ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C ... (doesn't work) You can't escape from the black hole and ghci will start eating up your memory unless kill the ghci process. Now the black hole behaves like a real black hole :-) Is this a ticketed bug, or should we make a new ticket? -- Ahn, Ki Yung From dominic.steinitz at blueyonder.co.uk Tue Nov 18 03:08:54 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Tue Nov 18 03:14:35 2008 Subject: 6.10.1 Bug? In-Reply-To: <49226BE6.2050101@blueyonder.co.uk> References: <49226BE6.2050101@blueyonder.co.uk> Message-ID: <49227816.7020806@blueyonder.co.uk> Dominic Steinitz wrote: > According to the hackage page, the Haskell Cryptography Library has a > build failure. I couldn't find a bug reference when I searched for > milestone 6.10.1 on trac. Should I report it? Has it been fixed? > > Thanks, Dominic. > > http://hackage.haskell.org/packages/archive/Crypto/4.1.0/logs/failure/ghc-6.10 > >> [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o ) >> ghc: panic! (the 'impossible' happened) >> (GHC version 6.10.1 for i386-unknown-linux): >> RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph >> >> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > I found it. It was filed under milestone 6.10.2 (clearly I don't understand milestones). http://hackage.haskell.org/trac/ghc/ticket/2753 It seems a bit vague on what's happening. Is it going to be fixed? Has it been fixed? Thanks, Dominic. From kazu at iij.ad.jp Tue Nov 18 04:00:25 2008 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue Nov 18 03:54:38 2008 Subject: Unicode's greek lambda Message-ID: <20081118.180025.234710170.kazu@iij.ad.jp> Hello, When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter "greek lambda" cannot be used. Are there any technical reasons to not accept it? Regards, --Kazu From Malcolm.Wallace at cs.york.ac.uk Tue Nov 18 05:30:01 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 18 05:28:28 2008 Subject: Unicode's greek lambda In-Reply-To: <20081118.180025.234710170.kazu@iij.ad.jp> References: <20081118.180025.234710170.kazu@iij.ad.jp> Message-ID: <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> > When the -XUnicodeSyntax option is specified, GHC accepts some Unicode > characters including left/right arrows. Unfortunately, the letter > "greek lambda" cannot be used. Are there any technical reasons to not > accept it? The "greek lambda" is a normal lower-case alphabetic character - it can be used in identifier names. Regards, Malcolm From bulat.ziganshin at gmail.com Tue Nov 18 05:34:25 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Nov 18 05:29:17 2008 Subject: Unicode's greek lambda In-Reply-To: <20081118.180025.234710170.kazu@iij.ad.jp> References: <20081118.180025.234710170.kazu@iij.ad.jp> Message-ID: <1872522364.20081118133425@gmail.com> Hello Kazu, Tuesday, November 18, 2008, 12:00:25 PM, you wrote: > characters including left/right arrows. Unfortunately, the letter > "greek lambda" cannot be used. Are there any technical reasons to not > accept it? i think it is accepted as usual letter - reason is that greeks can use it in their identifiers :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jwlato at gmail.com Tue Nov 18 05:57:15 2008 From: jwlato at gmail.com (John Lato) Date: Tue Nov 18 05:51:23 2008 Subject: cross module optimization issues In-Reply-To: <20081115220956.GT15077@scytale.galois.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> Message-ID: <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> On Sat, Nov 15, 2008 at 10:09 PM, Don Stewart wrote: > jwlato: >> Hello, >> >> I have a problem with a package I'm working on, and I don't have any >> idea how to sort out the current problem. >> >> One part of my package is in one monolithic module, without an export >> list, which works fine. However, when I've started to separate out >> certain functions into another module, and added an export list to one >> of the modules, which dramatically decreases performance. The memory >> behavior (as shown by -hT) is also quite different, with substantial >> memory usage by "FUN_2_0". Are there any suggestions as to how I >> could improve this? >> > > Are you compiling with aggressive cross-module optimisations on (e.g. > -O2)? You may have to add explicit inlining pragmas (check the Core > output), to ensure key functions are exported in their entirety. > Thanks for the reply. I'm compiling with -O2 -Wall. After looking at the Core output, I think I've found the key difference. A function that is bound in a "where" statement is different between the monolithic and split sources. I have no idea why, though. I'll experiment with a few different things to see if I can get this resolved. John From marlowsd at gmail.com Tue Nov 18 06:06:30 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 18 06:00:43 2008 Subject: Trouble with ghc on linux x86_64 In-Reply-To: <6205bd290811140721n6e5b88a0la36ee46ea51d4ffc@mail.gmail.com> References: <6205bd290811140404o441d0455q74e22caf821a60cc@mail.gmail.com> <491D7EC6.5090309@gmail.com> <6205bd290811140721n6e5b88a0la36ee46ea51d4ffc@mail.gmail.com> Message-ID: <4922A1B6.6050705@gmail.com> Bit Connor wrote: > On Fri, Nov 14, 2008 at 5:36 AM, Simon Marlow wrote: >> Compiling and running executables should work fine, only GHCi is affected by >> the above bug. Could you try -v when linking and see what stage is hanging? > > Here is an example with a standard cabal Setup.lhs file. It outputs > the following and then hangs. When I look at "top" then there is an > "ld" process taking up almost zero cpu, but hundreds of MB of memory. Since it seems to be hanging in the linker, and this is a Xen instance, perhaps you're running out of memory and swapping? BTW, I've checked in a potential fix for the mmap() problem you reported earlier, see http://hackage.haskell.org/trac/ghc/ticket/2063 Cheers, Simon From marlowsd at gmail.com Tue Nov 18 06:09:24 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 18 06:03:37 2008 Subject: Cannot escape from a black hole in ghci 6.10.1 In-Reply-To: References: Message-ID: <4922A264.30900@gmail.com> Ahn, Ki Yung wrote: > Dear GHC users > > I have both GHC 6.8.2 (debian unstable package) and > GHC 6.8.10 (binary distribution from ghc homepage) installed. > > I was able to escape from a black hole in ghci 6.8.2 with Ctrl-C. > For example, > > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> let x = x + x > Prelude> x > ^CInterrupted. > Prelude> x > *** Exception: stack overflow > Prelude> > > Interestingly, you will get a stack overflow when you try to escape from > the black home for the second time. > > In ghci 6.10.1, I am not able to escape from a black hole with Ctrl-C. > > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> let x = x + x > Prelude> x > ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C ... (doesn't work) > > You can't escape from the black hole and ghci will start > eating up your memory unless kill the ghci process. > Now the black hole behaves like a real black hole :-) > > Is this a ticketed bug, or should we make a new ticket? Yes, this is the same bug as #2783 (fixed yesterday) and probably also #2780 (I still have to test the fix against that program). It'll be fixed in 6.10.2. Cheers, Simon From marlowsd at gmail.com Tue Nov 18 06:10:06 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 18 06:04:18 2008 Subject: 6.10.1 Bug? In-Reply-To: <49227816.7020806@blueyonder.co.uk> References: <49226BE6.2050101@blueyonder.co.uk> <49227816.7020806@blueyonder.co.uk> Message-ID: <4922A28E.7030102@gmail.com> Dominic Steinitz wrote: > Dominic Steinitz wrote: >> According to the hackage page, the Haskell Cryptography Library has a >> build failure. I couldn't find a bug reference when I searched for >> milestone 6.10.1 on trac. Should I report it? Has it been fixed? >> >> Thanks, Dominic. >> >> http://hackage.haskell.org/packages/archive/Crypto/4.1.0/logs/failure/ghc-6.10 >> >>> [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o ) >>> ghc: panic! (the 'impossible' happened) >>> (GHC version 6.10.1 for i386-unknown-linux): >>> RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph >>> >>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> > > I found it. It was filed under milestone 6.10.2 (clearly I don't > understand milestones). > > http://hackage.haskell.org/trac/ghc/ticket/2753 > > It seems a bit vague on what's happening. Is it going to be fixed? Has > it been fixed? We'll do something for 6.10.2, yes. Cheers, Simon From ross at soi.city.ac.uk Tue Nov 18 06:51:15 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 18 06:45:28 2008 Subject: Unicode's greek lambda In-Reply-To: <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20081118115115.GA5102@soi.city.ac.uk> On Tue, Nov 18, 2008 at 10:30:01AM +0000, Malcolm Wallace wrote: > > When the -XUnicodeSyntax option is specified, GHC accepts some Unicode > > characters including left/right arrows. Unfortunately, the letter > > "greek lambda" cannot be used. Are there any technical reasons to not > > accept it? > > The "greek lambda" is a normal lower-case alphabetic character - it can > be used in identifier names. But it could be a reserved word synonymous with \. After all, \ can occur in operator symbols, but the operator \ is reserved. From rk at trie.org Tue Nov 18 08:15:59 2008 From: rk at trie.org (Rahul Kapoor) Date: Tue Nov 18 08:10:08 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: <492187D9.9000401@gmail.com> References: <492187D9.9000401@gmail.com> Message-ID: > I've made a speculative fix. If you're able to test it, that would be very > helpful: I imagine, I need to download the nightly snapshot and build it. HEAD or STABLE? Rahul From nominolo at googlemail.com Tue Nov 18 08:58:25 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Nov 18 08:52:33 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: References: <492187D9.9000401@gmail.com> Message-ID: <916b84820811180558j3d4625e0u1ca9e76b19dd44e0@mail.gmail.com> HEAD 2008/11/18 Rahul Kapoor : >> I've made a speculative fix. If you're able to test it, that would be very >> helpful: > I imagine, I need to download the nightly snapshot and build it. > HEAD or STABLE? > > Rahul > _______________________________________________ > 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 igloo at earth.li Tue Nov 18 12:04:49 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 18 11:58:58 2008 Subject: 6.10.1 Bug? In-Reply-To: <49227816.7020806@blueyonder.co.uk> References: <49226BE6.2050101@blueyonder.co.uk> <49227816.7020806@blueyonder.co.uk> Message-ID: <20081118170449.GA22578@matrix.chaos.earth.li> On Tue, Nov 18, 2008 at 08:08:54AM +0000, Dominic Steinitz wrote: > > I found it. It was filed under milestone 6.10.2 (clearly I don't > understand milestones). The "milestone" is when we hope it will be fixed. The "version" is which version it is broken in (although if it's broken in multiple versions then only one will be listed). Thanks Ian From duncan.coutts at worc.ox.ac.uk Tue Nov 18 15:58:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 18 15:52:01 2008 Subject: Unicode's greek lambda In-Reply-To: <20081118115115.GA5102@soi.city.ac.uk> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> Message-ID: <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> On Tue, 2008-11-18 at 11:51 +0000, Ross Paterson wrote: > On Tue, Nov 18, 2008 at 10:30:01AM +0000, Malcolm Wallace wrote: > > > When the -XUnicodeSyntax option is specified, GHC accepts some Unicode > > > characters including left/right arrows. Unfortunately, the letter > > > "greek lambda" cannot be used. Are there any technical reasons to not > > > accept it? > > > > The "greek lambda" is a normal lower-case alphabetic character - it can > > be used in identifier names. > > But it could be a reserved word synonymous with \. After all, \ can > occur in operator symbols, but the operator \ is reserved. Presumably that would let you do (\ x -> ...) but not (\x -> ) since the "\x" would run together and lexically it would be one identifier. Duncan From donn at avvanta.com Tue Nov 18 16:31:46 2008 From: donn at avvanta.com (Donn Cave) Date: Tue Nov 18 16:25:57 2008 Subject: Unicode's greek lambda Message-ID: <20081118213146.F3D11F394E@mail.avvanta.com> Quoth Duncan Coutts : | On Tue, 2008-11-18 at 11:51 +0000, Ross Paterson wrote: |> But it could be a reserved word synonymous with \. After all, \ can |> occur in operator symbols, but the operator \ is reserved. | | Presumably that would let you do (\ x -> ...) but not (\x -> ) since the | "\x" would run together and lexically it would be one identifier. Good, that's clearly the right way to do it anyway! Donn From dagit at codersbase.com Tue Nov 18 16:41:50 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Nov 18 16:35:57 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> Message-ID: On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty wrote: > Ian Lynagh: > > On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: >> >>> On 2008 Nov 4, at 20:26, Jason Dagit wrote: >>> >>>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty >>>> wrote: >>>> >>>>> >>>>> Are you sure it does deinstall the 6.8 compiler? >>>>> >>>>> After installing 6.10, there should be a 608/ and a 610/ >>>>> directory. This >>>>> certainly happens on my Mac and I am not aware of an option to >>>>> change that >>>>> behaviour. >>>>> >>>> >>> I expect if you used the OSX installer then /Library/Receipts is >>> screwing you (it wipes the old files listed in the .bom file). Try >>> finding and removing the receipt directory and bom file before >>> installing. >>> >> >> The only file I can see that looks relevant is >> /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom >> >> Wouldn't removing it make uninstall impossible? >> >> In fact, if you did manage to get 2 versions installed, how would >> /Library/Frameworks/GHC.framework/Tools/Uninstaller >> know which version to uninstall? Wouldn't it only know how to uninstall >> the version it came with? I'd suggest that the overlapping file >> "Uninstaller" could be why the older version gets removed, but that >> wouldn't explain why Manuel can install both at once. >> > > A current limitation of the MacOS package system is that it does not > support uninstalling of packages; cf > > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ > /apple_ref/doc/uid/10000145i-CH6-DontLinkElementID_29 > > This is not a big drama on MacOS, as MacOS encourages the distribution of > software packages as "bundles": > > > http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html > > This essentially means that instead of sprinkling files all over the file > system (as is common in other OSes), MacOS applications and frameworks > (Mac-speak for libraries) are kept in a single directory. Uninstalling then > means doing an rm -rf on that directory. > > Unfortunately, some applications (including GHC and Apple's Xcode IDE) > can't be entirely contained in a single directory. In the case of GHC, we > want symlinks in /usr/bin. The established way of uninstalling such > applications is by supplying an Uninstaller script, just as I did for GHC. > (Apple does the same for Xcode.) > > The purpose of the Uninstaller script is too completely remove > GHC.framework from a machine - not just to remove one version. In fact, if > more than one version of GHC is installed, the Uninstaller will refuse to > run and require the manual removal of all versions, but the current (easily > achieved by a "rm -rf > /Library/Frameworks/GHC.framework/Versions/"). The main feature of > the Uninstaller script is to get rid of all symlinks pointing into > GHC.framework. The framework itself is just deleted by a "rm -rf" as > expected. (It also removes the above mentioned receipt file.) > > So, to directly answer the above questions: > * The package manger (which uses the receipts) can't uninstall and the > uninstaller script doesn't need the receipt. So, even after deleteing the > receibt, you can still uninstall. > * The Uninstaller can uninstall any version (at least as long as no > symlinks are put into new directories outside of the bundle that the > Uninstaller doesn't know about). Is there an update on this thread? I would still like to have my cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the installer hasn't been updated and if I try again I will lose my copy of 6.8.3. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081118/14235092/attachment.htm From kazu at iij.ad.jp Tue Nov 18 20:53:22 2008 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue Nov 18 20:47:36 2008 Subject: Unicode's greek lambda In-Reply-To: <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> References: <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> Message-ID: <20081119.105322.114244789.kazu@iij.ad.jp> Hello, First of all, thank you for those who replied kindly. > > > > When the -XUnicodeSyntax option is specified, GHC accepts some Unicode > > > > characters including left/right arrows. Unfortunately, the letter > > > > "greek lambda" cannot be used. Are there any technical reasons to not > > > > accept it? > > > > > > The "greek lambda" is a normal lower-case alphabetic character - it can > > > be used in identifier names. OK. I understand. > > But it could be a reserved word synonymous with \. After all, \ can > > occur in operator symbols, but the operator \ is reserved. > > Presumably that would let you do (\ x -> ...) but not (\x -> ) since the > "\x" would run together and lexically it would be one identifier. If we reserve the greek lambda as special like '\', the lexer can separate x into two tokens: and 'x', I guess. Some people may want to use the greek lambda in identifiers. And some would want to use the greek lambda as an alternative of '\'. So, how about providing a new option to make the greek lambda special? P.S. I want to type the examples in "Programming in Haskell" as is. --Kazu From allbery at ece.cmu.edu Tue Nov 18 20:57:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 18 20:51:23 2008 Subject: Unicode's greek lambda In-Reply-To: <20081119.105322.114244789.kazu@iij.ad.jp> References: <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <20081119.105322.114244789.kazu@iij.ad.jp> Message-ID: <67817EB0-C1F7-456B-9DB3-3C45B4079A2A@ece.cmu.edu> On 2008 Nov 18, at 20:53, Kazu Yamamoto (????) wrote: > If we reserve the greek lambda as special like '\', the lexer can > separate x into two tokens: and 'x', I guess. Not without redefining it as a symbol instead of a lowercase letter, which won't be done as previously discussed. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From kazu at iij.ad.jp Tue Nov 18 21:26:04 2008 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue Nov 18 21:20:15 2008 Subject: Unicode's greek lambda In-Reply-To: <67817EB0-C1F7-456B-9DB3-3C45B4079A2A@ece.cmu.edu> References: <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <20081119.105322.114244789.kazu@iij.ad.jp> <67817EB0-C1F7-456B-9DB3-3C45B4079A2A@ece.cmu.edu> Message-ID: <20081119.112604.60541941.kazu@iij.ad.jp> Hello, > > If we reserve the greek lambda as special like '\', the lexer can > > separate x into two tokens: and 'x', I guess. > > Not without redefining it as a symbol instead of a lowercase letter, > which won't be done as previously discussed. OK. Fine with me since this topic was previously discussed. --Kazu From chak at cse.unsw.edu.au Wed Nov 19 04:28:05 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Nov 19 04:22:22 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> Message-ID: <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> Jason Dagit: > On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty > wrote: > Ian Lynagh: > > On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH > wrote: > On 2008 Nov 4, at 20:26, Jason Dagit wrote: > On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty > wrote: > > Are you sure it does deinstall the 6.8 compiler? > > After installing 6.10, there should be a 608/ and a 610/ > directory. This > certainly happens on my Mac and I am not aware of an option to > change that > behaviour. > > I expect if you used the OSX installer then /Library/Receipts is > screwing you (it wipes the old files listed in the .bom file). Try > finding and removing the receipt directory and bom file before > installing. > > The only file I can see that looks relevant is > /Library/Receipts/boms/ > org.haskell.glasgowHaskellCompiler.ghc.pkg.bom > > Wouldn't removing it make uninstall impossible? > > In fact, if you did manage to get 2 versions installed, how would > /Library/Frameworks/GHC.framework/Tools/Uninstaller > know which version to uninstall? Wouldn't it only know how to > uninstall > the version it came with? I'd suggest that the overlapping file > "Uninstaller" could be why the older version gets removed, but that > wouldn't explain why Manuel can install both at once. > > A current limitation of the MacOS package system is that it does not > support uninstalling of packages; cf > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ > /apple_ref/doc/uid/10000145i-CH6-DontLinkElementID_29 > > This is not a big drama on MacOS, as MacOS encourages the > distribution of software packages as "bundles": > > http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html > > This essentially means that instead of sprinkling files all over the > file system (as is common in other OSes), MacOS applications and > frameworks (Mac-speak for libraries) are kept in a single > directory. Uninstalling then means doing an rm -rf on that directory. > > Unfortunately, some applications (including GHC and Apple's Xcode > IDE) can't be entirely contained in a single directory. In the case > of GHC, we want symlinks in /usr/bin. The established way of > uninstalling such applications is by supplying an Uninstaller > script, just as I did for GHC. (Apple does the same for Xcode.) > > The purpose of the Uninstaller script is too completely remove > GHC.framework from a machine - not just to remove one version. In > fact, if more than one version of GHC is installed, the Uninstaller > will refuse to run and require the manual removal of all versions, > but the current (easily achieved by a "rm -rf /Library/Frameworks/ > GHC.framework/Versions/"). The main feature of the > Uninstaller script is to get rid of all symlinks pointing into > GHC.framework. The framework itself is just deleted by a "rm -rf" > as expected. (It also removes the above mentioned receipt file.) > > So, to directly answer the above questions: > * The package manger (which uses the receipts) can't uninstall and > the uninstaller script doesn't need the receipt. So, even after > deleteing the receibt, you can still uninstall. > * The Uninstaller can uninstall any version (at least as long as no > symlinks are put into new directories outside of the bundle that the > Uninstaller doesn't know about). > > Is there an update on this thread? I would still like to have my > cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I > know the installer hasn't been updated and if I try again I will > lose my copy of 6.8.3. Sorry, but for the moment, my (rather limited knowledge) of the MacOS packaging system is exhausted, and currently I don't have the time to search the web or experiment to try to learn more. It would be helpful to have the input of somebody who has more experience with MacOS packages. Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081119/3c5e6659/attachment.htm From michal.palka at poczta.fm Wed Nov 19 07:04:19 2008 From: michal.palka at poczta.fm (=?UTF-8?Q?Micha=C5=82_Pa=C5=82ka?=) Date: Wed Nov 19 06:59:10 2008 Subject: Unicode's greek lambda In-Reply-To: <20081118.180025.234710170.kazu@iij.ad.jp> References: <20081118.180025.234710170.kazu@iij.ad.jp> Message-ID: <1227096259.4724.134.camel@localhost> Hi, Perhaps it would be possible to convince your text editor to display '\' as, let's say, bold lambda? Of course it would need to know which '\' mean lambdas. Best, Micha? On Tue, 2008-11-18 at 18:00 +0900, Kazu Yamamoto wrote: > Hello, > > When the -XUnicodeSyntax option is specified, GHC accepts some Unicode > characters including left/right arrows. Unfortunately, the letter > "greek lambda" cannot be used. Are there any technical reasons to not > accept it? > > Regards, > > --Kazu > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From mechvel at botik.ru Wed Nov 19 07:46:18 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Nov 19 07:40:37 2008 Subject: language features in 6.10.1 Message-ID: <20081119124618.GA22769@scico.botik.ru> The GHC team writes > The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 > [..] > There have been a number of significant changes since the last > major release, including: > > * Some new language features have been implemented: > * Record syntax: wild-card patterns, punning, and field disambiguation > * Generalised quasi-quotes > * Generalised list comprehensions > * View patterns > > [..] Please, where and in what chapters these 4 language features are documented? Thank you in advance for help, ----------------- Serge Mechveliani mechvel@botik.ru From marlowsd at gmail.com Wed Nov 19 08:21:49 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 19 08:15:58 2008 Subject: Unicode's greek lambda In-Reply-To: <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> Message-ID: <492412ED.4070206@gmail.com> Duncan Coutts wrote: > On Tue, 2008-11-18 at 11:51 +0000, Ross Paterson wrote: >> On Tue, Nov 18, 2008 at 10:30:01AM +0000, Malcolm Wallace wrote: >>>> When the -XUnicodeSyntax option is specified, GHC accepts some Unicode >>>> characters including left/right arrows. Unfortunately, the letter >>>> "greek lambda" cannot be used. Are there any technical reasons to not >>>> accept it? >>> The "greek lambda" is a normal lower-case alphabetic character - it can >>> be used in identifier names. >> But it could be a reserved word synonymous with \. After all, \ can >> occur in operator symbols, but the operator \ is reserved. > > Presumably that would let you do (\ x -> ...) but not (\x -> ) since the > "\x" would run together and lexically it would be one identifier. Exactly. Here's the relevant patch: Tue Jan 16 16:11:00 GMT 2007 Simon Marlow * Remove special lambda unicode character, it didn't work anyway Since lambda is a lower-case letter, it's debatable whether we want to steal it to mean lambda in Haskell source. However if we did, then we would probably want to make it a "special" symbol, not just a reserved symbol, otherwise writing \x->... (using unicode characters of course) wouldn't work, because \x would be treated as a single identifier, you'd need a space. Cheers, Simon From marlowsd at gmail.com Wed Nov 19 08:23:14 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 19 08:17:22 2008 Subject: language features in 6.10.1 In-Reply-To: <20081119124618.GA22769@scico.botik.ru> References: <20081119124618.GA22769@scico.botik.ru> Message-ID: <49241342.6070300@gmail.com> Serge D. Mechveliani wrote: > The GHC team writes > >> The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 >> [..] >> There have been a number of significant changes since the last >> major release, including: >> >> * Some new language features have been implemented: >> * Record syntax: wild-card patterns, punning, and field disambiguation >> * Generalised quasi-quotes >> * Generalised list comprehensions >> * View patterns >> >> [..] > > Please, where and in what chapters these 4 language features are > documented? > Thank you in advance for help, Direct links to the docs are in the release notes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-10-1.html Cheers, Simon From dot at dotat.at Wed Nov 19 10:01:23 2008 From: dot at dotat.at (Tony Finch) Date: Wed Nov 19 09:55:29 2008 Subject: Unicode's greek lambda In-Reply-To: <492412ED.4070206@gmail.com> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> Message-ID: On Wed, 19 Nov 2008, Simon Marlow wrote: > > Tue Jan 16 16:11:00 GMT 2007 Simon Marlow > * Remove special lambda unicode character, it didn't work anyway > Since lambda is a lower-case letter, it's debatable whether we want to > steal it to mean lambda in Haskell source. However if we did, then we > would probably want to make it a "special" symbol, not just a reserved > symbol, otherwise writing \x->... (using unicode characters of course) > wouldn't work, because \x would be treated as a single identifier, > you'd need a space. There are a number of mathematical lambdas in Unicode (distinct from teh Greek lambdas), but they are not in the basic multilingual plane and they are presumably not very easy to type :-) Tony. -- f.anthony.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: NORTHWESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN VIKING AND SOUTH UTSIRE. VERY ROUGH, OCCASIONALLY HIGH. RAIN THEN SHOWERS, WINTRY LATER IN VIKING AND NORTH UTSIRE. MODERATE OR GOOD, OCCASIONALLY POOR. From simonpj at microsoft.com Wed Nov 19 11:17:09 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 19 11:11:17 2008 Subject: cross module optimization issues In-Reply-To: <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> | I'm compiling with -O2 -Wall. After looking at the Core output, I | think I've found the key difference. A function that is bound in a | "where" statement is different between the monolithic and split | sources. I have no idea why, though. I'll experiment with a few | different things to see if I can get this resolved. In general, splitting code across modules should not make programs less efficient -- as Don says, GHC does quite aggressive cross-module inlining. There is one exception, though. If a non-exported non-recursive function is called exactly once, then it is inlined *regardless of size*, because doing so does not cause code duplication. But if it's exported and is large, then its inlining is not exposed -- and even if it were it might not be inlined, because doing so duplicates its code an unknown number of times. You can change the threshold for (a) exposing and (b) using an inlining, with flags -funfolding-creation-threshold and -funfolding-use-threshold respectively. If you find there's something else going on then I'm all ears. Simon From bayer at cpw.math.columbia.edu Wed Nov 19 11:40:39 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Wed Nov 19 11:34:44 2008 Subject: GHC 6.10.1 type puzzler Message-ID: Here is an example illustrating a type problem I've having with GHC 6.10.1: > module Main where > > newtype Box a = B a > > make :: a -> Box a > make x = B x > > val :: Box a -> a > val (B x) = x > > test1 :: Box a -> a -> [a] > test1 box x = go box x > where > go :: Box a -> a -> [a] > go b y = [(val b), y] > > test2 :: Box a -> a -> [a] > test2 box x = go x > where > -- go :: a -> [a] > go y = [(val box), y] > > main :: IO () > main = do > print $ test1 (make 1) 2 If I uncomment the commented type declaration, I get the familiar error > Couldn't match expected type `a1' against inferred type `a' On the other hand, the earlier code is identical except that it passes an extra argument, and GHC matches the types without complaint. This is a toy example to isolate the issue; in the actual code one wants a machine-checkable type declaration to help understand the function, which is local to save passing an argument. To the best of my understanding, I've given the correct type, but GHC won't make the inference to unify the type variables. I wonder if I found a GHC blind spot. However, it is far more likely that my understanding is faulty here. Any thoughts? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081119/e4e56af8/attachment.htm From Malcolm.Wallace at cs.york.ac.uk Wed Nov 19 12:12:22 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 19 12:08:19 2008 Subject: GHC 6.10.1 type puzzler In-Reply-To: References: Message-ID: <20081119171222.5c178972.Malcolm.Wallace@cs.york.ac.uk> > > test2 :: Box a -> a -> [a] > > test2 box x = go x > > where > > -- go :: a -> [a] > > go y = [(val box), y] > > > Couldn't match expected type `a1' against inferred type `a' You need to turn on {-# ScopedTypedVariables #-}. See http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped-type-variables Your first example works without this extension, because the local definition 'go' is fully polymorphic. However, in the second example, the type variable 'a' in the signature of 'go' is not fully polymorphic - it must be exactly the _same_ 'a' as in the top-level signature. Regards, Malcolm From daniil.elovkov at googlemail.com Wed Nov 19 12:15:57 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Wed Nov 19 12:10:03 2008 Subject: GHC 6.10.1 type puzzler In-Reply-To: References: Message-ID: <492449CD.5070101@gmail.com> Dave Bayer wrote: > Here is an example illustrating a type problem I've having with GHC 6.10.1: > >> module Main where >> >> newtype Box a = B a >> >> make :: a -> Box a >> make x = B x >> >> val :: Box a -> a >> val (B x) = x >> >> test1 :: Box a -> a -> [a] >> test1 box x = go box x >> where >> go :: Box a -> a -> [a] >> go b y = [(val b), y] >> >> test2 :: Box a -> a -> [a] >> test2 box x = go x >> where >> -- go :: a -> [a] >> go y = [(val box), y] If you really want to specify the type for a local declaration, you'll have to turn on ScopedTypeVariables. Otherwise 'a' is test2 type signature and 'a' in go type signature mean different unrelated things. In test2 box remains with the first 'a', while go is with the second. There is need for unification. In the case of test1 go has all the variables. In other words, you get test1 :: forall p. Box p -> p -> [p] go :: forall q. Box q -> q -> [q] and you perfectly can call go with test1 arguments. On the other hand, test2 :: forall p. Box p -> p -> [p] go :: forall q. q -> [q] and obviously there's a problem. Do this {-# LANGUAGE ScopedTypeVariables, PatternSignatures #-} test2 :: Box a -> a -> [a] test2 box (x::a) = go x -- here you say, that x :: a where go :: a -> [a] -- here you mention the same a go y = [(val box), y] PatternSignatures appears to be needed for pattern x::a > > If I uncomment the commented type declaration, I get the familiar error > >> Couldn't match expected type `a1' against inferred type `a' > > On the other hand, the earlier code is identical except that it passes > an extra argument, and GHC matches the types without complaint. > > This is a toy example to isolate the issue; in the actual code one wants > a machine-checkable type declaration to help understand the function, > which is local to save passing an argument. To the best of my > understanding, I've given the correct type, but GHC won't make the > inference to unify the type variables. > > I wonder if I found a GHC blind spot. However, it is far more likely > that my understanding is faulty here. Any thoughts? > > Thanks, > Dave > > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Wed Nov 19 12:25:20 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 19 12:19:26 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1226081346.8437.370.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Duncan Coutts | Sent: 07 November 2008 18:09 | To: GHC-users list | Cc: Philip K.F. H?lzenspies | Subject: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? | | On Fri, 2008-11-07 at 09:14 -0800, Judah Jacobson wrote: | > On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts | > wrote: | > > | > > I get some working and some non-working. Eg backspace, del, home, end | > > work, but the ctl-left/ctl-right to jump words does not. | > > | > > Does anyone know how libedit is supposed to be configured? readline | > > uses /etc/inputrc but libedit either does not or doesn't understand all | > > of it. | > > | > > /me wonders if it was really necessary to switch from readline | > > | > > Duncan | > | > You can configure libedit with a ~/.editrc file. | > | > http://www.manpagez.com/man/5/editrc/ | | Thanks Judah. | | To save everyone else having to read the man page and working out | through trial and error what the key escape codes are, add the following | to your ~/.editrc file. | | # mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving | bind "\e[1;5D" vi-prev-word | bind "\e[1;5C" vi-next-word | | (though from reading the readline /etc/inputrc it suggests that "\e[5C" | and "\e[5D" might be right on some systems) | | It's unfortunate that editline does not seem to support any | global /etc/editrc file which would enable distros to make it do the | right thing by default like they do for readline. | | Duncan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ccshan at post.harvard.edu Wed Nov 19 12:29:55 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Wed Nov 19 12:54:40 2008 Subject: GHC 6.10.1 type puzzler References: Message-ID: Dave Bayer wrote in article in gmane.comp.lang.haskell.glasgow.user: > test1 :: Box a -> a -> [a] > test1 box x = go box x > where > go :: Box a -> a -> [a] > go b y = [(val b), y] The type signature "go :: Box a -> a -> [a]" is equivalent to "go :: Box b -> b -> [b]" or "go :: forall a. Box a -> a -> [a]" or "go :: forall b. Box b -> b -> [b]" because the type variable "a" in the type signature for "test1" does not scope over the type signature for "go". Fortunately, "go" here does have that type. > test2 :: Box a -> a -> [a] > test2 box x = go x > where > -- go :: a -> [a] > go y = [(val box), y] Here "go" does not have the type "forall a. a -> [a]"; it is not polymorphic enough. To write the signature for "go" inside "test2", you need lexically scoped type variables: http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped-type-variables -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2008-11-20 Universal Children's Day http://unicef.org/ 1948-12-10 Universal Declaration of Human Rights http://everyhumanhasrights.org From bayer at cpw.math.columbia.edu Wed Nov 19 13:28:41 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Wed Nov 19 13:22:45 2008 Subject: GHC 6.10.1 type puzzler In-Reply-To: References: Message-ID: <4D6C0388-1885-4AD2-B48F-2466D90D3C4D@math.columbia.edu> Thanks all. Sorting this out for my actual code was a bit harder, but it worked. The manual sure wasn't kidding when it said "Read this section carefully!" Dave On Nov 19, 2008, at 12:12 PM, Malcolm Wallace wrote: > You need to turn on {-# ScopedTypedVariables #-}. On Nov 19, 2008, at 12:15 PM, Daniil Elovkov wrote: > If you really want to specify the type for a local declaration, > you'll have to turn on ScopedTypeVariables. On Nov 19, 2008, at 12:29 PM, Chung-chieh Shan wrote: > To write the signature for "go" inside "test2", you need lexically > scoped type variables: > http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped-type-variables From p.k.f.holzenspies at utwente.nl Wed Nov 19 14:45:23 2008 From: p.k.f.holzenspies at utwente.nl (=?ISO-8859-1?Q?Philip_H=F6lzenspies?=) Date: Wed Nov 19 14:39:33 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: > Would it be worth adding this hard-won lore somewhere on a Wiki > where it can be found later? Dear Simon, all, I don't think logging a specific option on the Wiki is particularly useful (maybe you would have a default editrc file), because, of course, everybody has their own particular wishes. For example, aside from the word-jumping Duncan suggested, I alway use zsh-like history searching, so I like: bind "^[[A" ed-search-prev-history bind "^[[B" ed-search-next-history Also, there are no de facto escape sequences, because special keys (like function and arrow keys) have different sequences on different terminals. A useful tip that may be useful to include in the wiki is an easy trick that will help you find out your terminals escape sequences. I usually just like to start an application that has no editline or readline capabilities and press the keys. Telnet is one of my favorite applications for this purpose. Something that I would personally very much enjoy is a clear and unmistakable warning from configure when editline is not found. After installing libedit-devel (my ghci-6.10.1 finally has comfortable editing now), I checked config.log; there's not even a mention of libedit capabilities. Maybe a general summary at the end of configure of all the optional capabilities that were or were not configured. As an inspiration, look at gtk2hs' configure output. Regards, Philip From duncan.coutts at worc.ox.ac.uk Wed Nov 19 17:24:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 19 17:17:22 2008 Subject: Unicode's greek lambda In-Reply-To: References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> Message-ID: <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> On Wed, 2008-11-19 at 15:01 +0000, Tony Finch wrote: > On Wed, 19 Nov 2008, Simon Marlow wrote: > > > > Tue Jan 16 16:11:00 GMT 2007 Simon Marlow > > * Remove special lambda unicode character, it didn't work anyway > > Since lambda is a lower-case letter, it's debatable whether we want to > > steal it to mean lambda in Haskell source. However if we did, then we > > would probably want to make it a "special" symbol, not just a reserved > > symbol, otherwise writing \x->... (using unicode characters of course) > > wouldn't work, because \x would be treated as a single identifier, > > you'd need a space. > > There are a number of mathematical lambdas in Unicode (distinct from teh > Greek lambdas), but they are not in the basic multilingual plane and they > are presumably not very easy to type :-) Do you know what they are? I couldn't find any other than the greek lambda ? and the latin lambda with stroke ?. Duncan From dave at zednenem.com Wed Nov 19 17:32:59 2008 From: dave at zednenem.com (David Menendez) Date: Wed Nov 19 17:27:04 2008 Subject: Unicode's greek lambda In-Reply-To: <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> Message-ID: <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> On Wed, Nov 19, 2008 at 5:24 PM, Duncan Coutts wrote: > On Wed, 2008-11-19 at 15:01 +0000, Tony Finch wrote: >> On Wed, 19 Nov 2008, Simon Marlow wrote: >> > >> > Tue Jan 16 16:11:00 GMT 2007 Simon Marlow >> > * Remove special lambda unicode character, it didn't work anyway >> > Since lambda is a lower-case letter, it's debatable whether we want to >> > steal it to mean lambda in Haskell source. However if we did, then we >> > would probably want to make it a "special" symbol, not just a reserved >> > symbol, otherwise writing \x->... (using unicode characters of course) >> > wouldn't work, because \x would be treated as a single identifier, >> > you'd need a space. >> >> There are a number of mathematical lambdas in Unicode (distinct from teh >> Greek lambdas), but they are not in the basic multilingual plane and they >> are presumably not very easy to type :-) > > Do you know what they are? I couldn't find any other than the greek > lambda ? and the latin lambda with stroke ?. They're listed under Mathematical Alphanumeric Symbols. e.g., 1D6CC mathematical bold small lambda -- Dave Menendez From bayer at cpw.math.columbia.edu Wed Nov 19 20:06:27 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Wed Nov 19 20:00:33 2008 Subject: Lazy minimum Message-ID: <89BB8007-B733-48B2-80E9-BB9D19A40024@math.columbia.edu> Compare these two lines in ghci (if you have at least 4 GB of memory): > let a = replicate (2^26) 2 in minimum [[1],a,a] > let a = replicate (2^26) 2 in minimum [a,a,[1]] The first finishes much faster than the second. This comes up for example in isomorphism testing of graphs embedded in surfaces, which is much easier than the general case: A choice of a directed edge determines a walk of the vertices and edges of the graph, from which the graph can be recovered. A minimal walk can be used to determine a canonical form for the graph, making for a nice Haskell one-liner: > normal graph = unwalk $ minimum $ map (walk graph) $ edges graph However, this code suffers from the same issue as the toy ghci lines above. Even though the walks are lazy, the minimum function wastefully explores them. It's clear how to fix this, comparing lazy lists: Play rounds of "Survivor", peeling off the heads of the lists at each iteration. One inevitably evaluates all of each minimal list, if there is more than one. This is familiar. For my example, the automorphisms of a graph show up in the complexity of any isomorphism algorithm; they manifest themselves here as the set of minimal walks. What I'm wondering, however, is if there is a way to code "minimum" efficiently in general, > minimum :: Ord a => [a] -> a where one knows absolutely nothing further about the type "a", but one believes that lazy evaluation will run afoul of the above issue. It would seem that this would require compiler support, allowing code to access approximations to lazy data generalizing the head of a lazy list. I'm reminded of working with power series by working mod x^n for various n. Here, I'd like a bounded version of "compare", that returned EQ for data that agreed to a specified lazy evaluation depth. Did I miss that class? Is there a construct in GHC that would allow me to write "minimum" efficiently for lazy data? From dave at zednenem.com Wed Nov 19 23:38:07 2008 From: dave at zednenem.com (David Menendez) Date: Wed Nov 19 23:32:17 2008 Subject: Lazy minimum In-Reply-To: <89BB8007-B733-48B2-80E9-BB9D19A40024@math.columbia.edu> References: <89BB8007-B733-48B2-80E9-BB9D19A40024@math.columbia.edu> Message-ID: <49a77b7a0811192038l6b5ac830x6ed2855beb78bcb9@mail.gmail.com> On Wed, Nov 19, 2008 at 8:06 PM, Dave Bayer wrote: > What I'm wondering, however, is if there is a way to code "minimum" > efficiently in general, > >> minimum :: Ord a => [a] -> a > > > where one knows absolutely nothing further about the type "a", but one > believes that lazy evaluation will run afoul of the above issue. > > It would seem that this would require compiler support, allowing code to > access approximations to lazy data generalizing the head of a lazy list. I'm > reminded of working with power series by working mod x^n for various n. > Here, I'd like a bounded version of "compare", that returned EQ for data > that agreed to a specified lazy evaluation depth. > > Did I miss that class? Is there a construct in GHC that would allow me to > write "minimum" efficiently for lazy data? One possibility would be to add minimum and maximum to Ord with the appropriate default definitions, similar to Monoid's mconcat. -- Dave Menendez From rk at trie.org Thu Nov 20 00:04:46 2008 From: rk at trie.org (Rahul Kapoor) Date: Wed Nov 19 23:58:49 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: <492187D9.9000401@gmail.com> References: <492187D9.9000401@gmail.com> Message-ID: > I've made a speculative fix. If you're able to test it, that would be very > helpful: > > http://hackage.haskell.org/trac/ghc/ticket/2063 > > Cheers, > Simon I had no luck installing the binary snapshot (libedit problems, which I worked around by creating a link to the version I had) after which I started get libc version problems so I gave up on that built the HEAD snapshot from source. running ghci in-place now gives: GHCi, version 6.11.20081117: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for 57344 bytes at 0x0x4009fa00, got 0x0x7f3a9b2b8000. Try specifying an address with +RTS -xm -RTS (GHC version 6.11.20081117 for x86_64_unknown_linux) I am not really sure what I for -xm should be. Rahul From dan.doel at gmail.com Thu Nov 20 00:18:34 2008 From: dan.doel at gmail.com (Dan Doel) Date: Thu Nov 20 00:12:42 2008 Subject: Lazy minimum In-Reply-To: <49a77b7a0811192038l6b5ac830x6ed2855beb78bcb9@mail.gmail.com> References: <89BB8007-B733-48B2-80E9-BB9D19A40024@math.columbia.edu> <49a77b7a0811192038l6b5ac830x6ed2855beb78bcb9@mail.gmail.com> Message-ID: <200811200018.35834.dan.doel@gmail.com> On Wednesday 19 November 2008 11:38:07 pm David Menendez wrote: > One possibility would be to add minimum and maximum to Ord with the > appropriate default definitions, similar to Monoid's mconcat. This is probably the most sensible way. However, first seeing this, I wanted to see if I could do it with RULES, like so: -- this of course fails for Ords where a <= b, b <=a, but a and b are -- somehow distinguishable. min' :: Ord a => [a] -> [a] -> [a] min' as@(a:at) bs@(b:bt) | a < b = as | b < a = bs | otherwise = a : min' at bt -- arbitrary choice here minimum' :: Ord a => [[a]] -> [a] minimum' = foldl1 min' {-# RULES "min-list" min = min' #-} {-# RULES "minimum-list" minimum = minimum' #-} However, trying this gives me complaints about how Ord a cannot be inferred from Ord [a], so min and minimum aren't providing the right information for min' and minimum'. Perhaps it's unreasonable to expect this to work? Anyhow, barring that problem, that's probably the best hope one has of inserting a fancy procedure for lazy data without reworking the core libraries. This also has the issue of not really solving the problem all the way down. For instance, I think: let a = replicate (2^20) 2 in minimum [[[a]], [[a]], [[1]]] still shows bad behavior. So you need an algorithm more clever than the one I've come up with. :) -- Dan From dave at zednenem.com Thu Nov 20 01:27:11 2008 From: dave at zednenem.com (David Menendez) Date: Thu Nov 20 01:21:15 2008 Subject: Lazy minimum In-Reply-To: <200811200018.35834.dan.doel@gmail.com> References: <89BB8007-B733-48B2-80E9-BB9D19A40024@math.columbia.edu> <49a77b7a0811192038l6b5ac830x6ed2855beb78bcb9@mail.gmail.com> <200811200018.35834.dan.doel@gmail.com> Message-ID: <49a77b7a0811192227v74e21e7eh4d72261b4dcf867@mail.gmail.com> On Thu, Nov 20, 2008 at 12:18 AM, Dan Doel wrote: > On Wednesday 19 November 2008 11:38:07 pm David Menendez wrote: >> One possibility would be to add minimum and maximum to Ord with the >> appropriate default definitions, similar to Monoid's mconcat. > > This is probably the most sensible way. Now that I've thought about it more, the problem is that min and max are insufficiently lazy for lists. Here's a list clone that has the desired properties: data List a = Nil | a :< List a deriving (Show, Eq) instance Ord a => Ord (List a) where compare Nil Nil = EQ compare Nil _ = LT compare _ Nil = GT compare (a :< as) (b :< bs) = case compare a b of LT -> LT EQ -> compare as bs GT -> GT min (a :< as) (b :< bs) = case compare a b of LT -> a :< as EQ -> a :< min as bs GT -> b :< bs min _ _ = Nil head' (a :< as) = a head' _ = error "head': empty List" Thus, *Main> head' $ min (2 :< undefined) (2 :< undefined) 2 *Main> minimum [2 :< undefined, 2 :< undefined, 1 :< Nil] 1 :< Nil The tricky part is that derived instances of Ord do not make min (and max) lazy in this way, so you have to write your own. There are also possible space issues, since "min a b" will end up re-creating much of "a" or "b" if they share a large common prefix. > This also has the issue of not really solving the problem all the > way down. For instance, I think: > > let a = replicate (2^20) 2 > in minimum [[[a]], [[a]], [[1]]] > > still shows bad behavior. So you need an algorithm more clever than the one > I've come up with. :) Yeah, my solution falls down there, too. *Main> minimum [(2 :< undefined) :< Nil, (2 :< undefined) :< Nil, (1 :< Nil) :< Nil] *** Exception: Prelude.undefined I don't know if there's a good, general solution here. -- Dave Menendez From marlowsd at gmail.com Thu Nov 20 03:42:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 20 03:36:24 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <492522E8.3020006@gmail.com> Philip H?lzenspies wrote: > Something that I would personally very much enjoy is a clear and > unmistakable warning from configure when editline is not found. After > installing libedit-devel (my ghci-6.10.1 finally has comfortable editing > now), I checked config.log; there's not even a mention of libedit > capabilities. Maybe a general summary at the end of configure of all the > optional capabilities that were or were not configured. As an > inspiration, look at gtk2hs' configure output. Good idea - I've added it to the list of things to do in the new build system. Cheers, Simon From marlowsd at gmail.com Thu Nov 20 03:58:57 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 20 03:53:04 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: References: <492187D9.9000401@gmail.com> Message-ID: <492526D1.4070609@gmail.com> Rahul Kapoor wrote: >> I've made a speculative fix. If you're able to test it, that would be very >> helpful: >> >> http://hackage.haskell.org/trac/ghc/ticket/2063 >> >> Cheers, >> Simon > > > I had no luck installing the binary snapshot (libedit problems, which I worked > around by creating a link to the version I had) after which I started get libc > version problems so I gave up on that built the HEAD snapshot from source. > > running ghci in-place now gives: > > GHCi, version 6.11.20081117: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked > for 57344 bytes at 0x0x4009fa00, got 0x0x7f3a9b2b8000. Try specifying > an address with +RTS -xm -RTS > (GHC version 6.11.20081117 for x86_64_unknown_linux) > > I am not really sure what I for -xm should be. Ok, so we got a bit further, but it looks like at some point mmap() stopped giving us memory where we wanted it, perhaps because something else was already mapped at that address. It would be useful to get a look at the memory map. Can you load up GHCi in gdb, as follows. First, find out the path to your GHC binary and the -B option it needs: $ cat `which ghc` #!/bin/sh exec /home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/ghc -B/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/. -dynload wrapped ${1+"$@"} Here, /home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/ghc is my GHC binary, and -B/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/. is the option I need to pass. Now start gdb: $ gdb /home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/ghc and run GHC: (gdb) run --interactive -B/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/. It will now crash with the error you saw above. At this point we need to look at the memory map. Find the PID of the GHC process, by running 'ps uxw' in a terminal (don't quit gdb). Then $ cat /proc//maps where is the PID of the GHC process running in gdb, and send me the output. Cheers, Simon From jakubuv at gmail.com Thu Nov 20 04:50:21 2008 From: jakubuv at gmail.com (Jan Jakubuv) Date: Thu Nov 20 04:44:25 2008 Subject: Unicode's greek lambda In-Reply-To: <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> Message-ID: Some others are (I have no idea why they are referenced as "lamda" instead of "lambda"): 039B GREEK CAPITAL LETTER LAMDA 03BB GREEK SMALL LETTER LAMDA 1D27 GREEK LETTER SMALL CAPITAL LAMDA 1038D UGARITIC LETTER LAMDA 1D6B2 MATHEMATICAL BOLD CAPITAL LAMDA # 039B greek capital letter lamda 1D6CC MATHEMATICAL BOLD SMALL LAMDA # 03BB greek small letter lamda 1D6EC MATHEMATICAL ITALIC CAPITAL LAMDA # 039B greek capital letter lamda 1D706 MATHEMATICAL ITALIC SMALL LAMDA # 03BB greek small letter lamda 1D726 MATHEMATICAL BOLD ITALIC CAPITAL LAMDA # 039B greek capital letter lamda 1D740 MATHEMATICAL BOLD ITALIC SMALL LAMDA # 03BB greek small letter lamda 1D760 MATHEMATICAL SANS-SERIF BOLD CAPITAL LAMDA # 039B greek capital letter lamda 1D77A MATHEMATICAL SANS-SERIF BOLD SMALL LAMDA # 03BB greek small letter lamda 1D79A MATHEMATICAL SANS-SERIF BOLD ITALIC CAPITAL LAMDA # 039B greek capital letter lamda 1D7B4 MATHEMATICAL SANS-SERIF BOLD ITALIC SMALL LAMDA # 03BB greek small letter lamda jan. 2008/11/19 David Menendez : > On Wed, Nov 19, 2008 at 5:24 PM, Duncan Coutts > wrote: >> On Wed, 2008-11-19 at 15:01 +0000, Tony Finch wrote: >>> On Wed, 19 Nov 2008, Simon Marlow wrote: >>> > >>> > Tue Jan 16 16:11:00 GMT 2007 Simon Marlow >>> > * Remove special lambda unicode character, it didn't work anyway >>> > Since lambda is a lower-case letter, it's debatable whether we want to >>> > steal it to mean lambda in Haskell source. However if we did, then we >>> > would probably want to make it a "special" symbol, not just a reserved >>> > symbol, otherwise writing \x->... (using unicode characters of course) >>> > wouldn't work, because \x would be treated as a single identifier, >>> > you'd need a space. >>> >>> There are a number of mathematical lambdas in Unicode (distinct from teh >>> Greek lambdas), but they are not in the basic multilingual plane and they >>> are presumably not very easy to type :-) >> >> Do you know what they are? I couldn't find any other than the greek >> lambda ? and the latin lambda with stroke ?. > > They're listed under Mathematical Alphanumeric Symbols. > > > e.g., 1D6CC mathematical bold small lambda > > > -- > Dave Menendez > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From duncan.coutts at worc.ox.ac.uk Thu Nov 20 06:23:28 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 06:17:35 2008 Subject: Unicode's greek lambda In-Reply-To: References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> Message-ID: <1227180208.7124.41.camel@localhost> On Thu, 2008-11-20 at 09:50 +0000, Jan Jakubuv wrote: > Some others are (I have no idea why they are referenced as "lamda" > instead of "lambda"): Yeah, that's why I missed them. I was searching for what I thought was the correct spelling. Duncan From duncan.coutts at worc.ox.ac.uk Thu Nov 20 06:34:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 06:28:19 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1227180851.7124.48.camel@localhost> On Wed, 2008-11-19 at 20:45 +0100, Philip H?lzenspies wrote: > On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: > > Would it be worth adding this hard-won lore somewhere on a Wiki > > where it can be found later? > > Dear Simon, all, > > I don't think logging a specific option on the Wiki is particularly > useful (maybe you would have a default editrc file), because, of > course, everybody has their own particular wishes. I don't have any particular wishes. I just want it to "work" where "work" means does what the rest of my system does. I never configured readline, it came with sensible defaults (possibly set by my linux system distributor). What I really think is that we should add back optional readline support. People building closed source ghc binaries would not use it but linux distros could enable it and provide a better "out of the box" experience. As I understand it there would be no licencing problems with that approach. Duncan From marlowsd at gmail.com Thu Nov 20 07:51:18 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 20 07:45:24 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1227180851.7124.48.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> Message-ID: <49255D46.2050906@gmail.com> Duncan Coutts wrote: > On Wed, 2008-11-19 at 20:45 +0100, Philip H?lzenspies wrote: >> On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: >>> Would it be worth adding this hard-won lore somewhere on a Wiki >>> where it can be found later? >> Dear Simon, all, >> >> I don't think logging a specific option on the Wiki is particularly >> useful (maybe you would have a default editrc file), because, of >> course, everybody has their own particular wishes. > > I don't have any particular wishes. I just want it to "work" where > "work" means does what the rest of my system does. I never configured > readline, it came with sensible defaults (possibly set by my linux > system distributor). > > What I really think is that we should add back optional readline > support. People building closed source ghc binaries would not use it but > linux distros could enable it and provide a better "out of the box" > experience. As I understand it there would be no licencing problems with > that approach. One downside I can see is that it gives us an extra configuration to test and maintain. It's hard enough keeping one line-editing binding working, let alone two! It's true that editline seems to have brought a bunch of headaches with it, though. Perhaps Haskelline is the way to go in the future. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Thu Nov 20 08:52:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 08:46:19 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <49255D46.2050906@gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> Message-ID: <1227189132.7124.93.camel@localhost> On Thu, 2008-11-20 at 12:51 +0000, Simon Marlow wrote: > Duncan Coutts wrote: > > What I really think is that we should add back optional readline > > support. People building closed source ghc binaries would not use it but > > linux distros could enable it and provide a better "out of the box" > > experience. As I understand it there would be no licencing problems with > > that approach. > > One downside I can see is that it gives us an extra configuration to test > and maintain. It's hard enough keeping one line-editing binding working, > let alone two! > > It's true that editline seems to have brought a bunch of headaches with it, > though. Perhaps Haskelline is the way to go in the future. My selfish suggestion is that we maintain the readline configuration and let the people who originally wanted editline support do the work to maintain that configuration. I get the feeling they don't care about if it works well, just that it's got the license they want (which is a perfectly reasonable position). Duncan From bayer at cpw.math.columbia.edu Thu Nov 20 09:48:35 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Thu Nov 20 09:42:38 2008 Subject: Lazy minimum In-Reply-To: <49a77b7a0811192227v74e21e7eh4d72261b4dcf867@mail.gmail.com> References: <89BB8007-B733-48B2-80E9-BB9D19A40024@math.columbia.edu> <49a77b7a0811192038l6b5ac830x6ed2855beb78bcb9@mail.gmail.com> <200811200018.35834.dan.doel@gmail.com> <49a77b7a0811192227v74e21e7eh4d72261b4dcf867@mail.gmail.com> Message-ID: On Nov 20, 2008, at 1:27 AM, David Menendez wrote: > There are also possible space issues, since "min a b" will end up re- > creating much of "a" or "b" if they share a large common prefix. Thanks! I had put off writing the version I needed until seeing your code, which inspired me: > Compute the least list in a list of equal length lazy lists > > least :: forall a. Ord a => [[a]] -> [a] > > least ((x : xs) : xss) = w : least wss > where > (w, wss) = foldl' f (x, [xs]) xss > > f :: (a, [[a]]) -> [a] -> (a, [[a]]) > f v@(y, yss) (z : zs) = > case compare y z of > LT -> v > EQ -> (y, zs : yss) > GT -> (z, [zs]) > f v _ = v > > least _ = [] In my applications, there are usually many instances of the minimum, so peeling off a reference copy isn't all that wasteful. I just want to avoid evaluating everything else. So to summarize the responses, there's no GHC language support for introspecting lazy structures, allowing one to write a generic bounded compare that only evaluates lazy structures to a specified depth. One can however write a class, and solve this problem type-by-type with a common interface. I can see how providing language support for this could be controversial. Functions would remain referentially transparent within a given compilation, but their values would depend non-portably on the compiler. (I use a "code is indented, comments are flush" literate preprocessor (http://hackage.haskell.org/trac/ghc/ticket/2776 ) so I don't have to look at punctuation for either code or comments; syntax coloring makes it obvious which is which. The 1980's email quote symbols > in the default literate Haskell reminds me of being introduced to an IBM 360 in college, and being told I was working with virtual card images. I gasped. I remember punched cards, and it isn't an experience I want to relive. I also remember 1980's email, so my first reaction to literate Haskell was "You've got to be kidding!" Ahh, but better to propose a fix than to gripe.) From igloo at earth.li Thu Nov 20 10:16:29 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Nov 20 10:10:32 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1227189132.7124.93.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> Message-ID: <20081120151629.GA22268@matrix.chaos.earth.li> On Thu, Nov 20, 2008 at 01:52:12PM +0000, Duncan Coutts wrote: > > My selfish suggestion is that we maintain the readline configuration and > let the people who originally wanted editline support do the work to > maintain that configuration. Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to be BSD then it can't use it. Although another option would be to make GHCi a separate (GPL) frontend to the (BSD) GHC API. The only downside is that (with static linking) we have another large binary. Another upside is that other GHC API users don't get an editline dependency. Thanks Ian From rk at trie.org Thu Nov 20 10:24:41 2008 From: rk at trie.org (Rahul Kapoor) Date: Thu Nov 20 10:18:42 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: <492526D1.4070609@gmail.com> References: <492187D9.9000401@gmail.com> <492526D1.4070609@gmail.com> Message-ID: Attached is the memory map of ghc process running under gdb on a xen instance. -------------- next part -------------- 00400000-01460000 r-xp 00000000 08:01 4177923 /home/deploy/ghc-6.11.20081117/ghc/stage2-inplace/libexec/ghc 01660000-017e6000 rw-p 01060000 08:01 4177923 /home/deploy/ghc-6.11.20081117/ghc/stage2-inplace/libexec/ghc 017e6000-0182b000 rw-p 017e6000 00:00 0 [heap] 40000000-40099000 rwxp 00000000 08:01 3966016 /home/deploy/ghc-6.11.20081117/libraries/ghc-prim/dist/build/HSghc-prim-0.1.0.0.o 40099000-400a0000 rwxp 40099000 00:00 0 7fede7900000-7fede7b00000 rw-p 7fede7900000 00:00 0 7fede7bfe000-7fede7bff000 ---p 7fede7bfe000 00:00 0 7fede7bff000-7fede83ff000 rwxp 7fede7bff000 00:00 0 7fede83ff000-7fede8400000 ---p 7fede83ff000 00:00 0 7fede8400000-7fede8c00000 rwxp 7fede8400000 00:00 0 7fede8c00000-7fede8d00000 rw-p 7fede8c00000 00:00 0 7fede8ddd000-7fede8f35000 r-xp 00000000 08:01 7195193 /lib/libc-2.7.so 7fede8f35000-7fede9135000 ---p 00158000 08:01 7195193 /lib/libc-2.7.so 7fede9135000-7fede9138000 r--p 00158000 08:01 7195193 /lib/libc-2.7.so 7fede9138000-7fede913a000 rw-p 0015b000 08:01 7195193 /lib/libc-2.7.so 7fede913a000-7fede913f000 rw-p 7fede913a000 00:00 0 7fede913f000-7fede9155000 r-xp 00000000 08:01 7195207 /lib/libpthread-2.7.so 7fede9155000-7fede9355000 ---p 00016000 08:01 7195207 /lib/libpthread-2.7.so 7fede9355000-7fede9357000 rw-p 00016000 08:01 7195207 /lib/libpthread-2.7.so 7fede9357000-7fede935b000 rw-p 7fede9357000 00:00 0 7fede935b000-7fede9363000 r-xp 00000000 08:01 7195209 /lib/librt-2.7.so 7fede9363000-7fede9562000 ---p 00008000 08:01 7195209 /lib/librt-2.7.so 7fede9562000-7fede9564000 rw-p 00007000 08:01 7195209 /lib/librt-2.7.so 7fede9564000-7fede95a2000 r-xp 00000000 08:01 9191485 /usr/lib/libgmp.so.3.4.2 7fede95a2000-7fede97a2000 ---p 0003e000 08:01 9191485 /usr/lib/libgmp.so.3.4.2 7fede97a2000-7fede97a3000 rw-p 0003e000 08:01 9191485 /usr/lib/libgmp.so.3.4.2 7fede97a3000-7fede9823000 r-xp 00000000 08:01 7195197 /lib/libm-2.7.so 7fede9823000-7fede9a22000 ---p 00080000 08:01 7195197 /lib/libm-2.7.so 7fede9a22000-7fede9a24000 rw-p 0007f000 08:01 7195197 /lib/libm-2.7.so 7fede9a24000-7fede9a26000 r-xp 00000000 08:01 7195196 /lib/libdl-2.7.so 7fede9a26000-7fede9c26000 ---p 00002000 08:01 7195196 /lib/libdl-2.7.so 7fede9c26000-7fede9c28000 rw-p 00002000 08:01 7195196 /lib/libdl-2.7.so 7fede9c28000-7fede9c2a000 r-xp 00000000 08:01 7195212 /lib/libutil-2.7.so 7fede9c2a000-7fede9e29000 ---p 00002000 08:01 7195212 /lib/libutil-2.7.so 7fede9e29000-7fede9e2b000 rw-p 00001000 08:01 7195212 /lib/libutil-2.7.so 7fede9e2b000-7fede9e48000 r-xp 00000000 08:01 7195190 /lib/ld-2.7.so 7fedea02f000-7fedea03d000 rwxp 00000000 08:01 3981392 /home/deploy/ghc-6.11.20081117/libraries/integer-gmp/dist/build/HSinteger-0.1.0.0.o 7fedea03d000-7fedea041000 rw-p 7fedea03d000 00:00 0 7fedea045000-7fedea048000 rw-p 7fedea045000 00:00 0 7fedea048000-7fedea04a000 rw-p 0001d000 08:01 7195190 /lib/ld-2.7.so 7ffff2034000-7ffff2047000 rwxp 7ffffffea000 00:00 0 [stack] 7ffff2047000-7ffff2049000 rw-p 7fffffffd000 00:00 0 7ffff21fe000-7ffff2200000 r-xp 7ffff21fe000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] From marlowsd at gmail.com Thu Nov 20 11:33:15 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 20 11:27:21 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: References: <492187D9.9000401@gmail.com> <492526D1.4070609@gmail.com> Message-ID: <4925914B.7080901@gmail.com> Rahul Kapoor wrote: > Attached is the memory map of ghc process running under gdb on a xen instance. Thanks! I think I see the bug. I've just pushed another patch ("round the size up to a page in mmapForLinker() instead of in the caller"), if you could try it out that would be great. Cheers, Simon From arnarbi at gmail.com Thu Nov 20 11:46:16 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Thu Nov 20 11:40:17 2008 Subject: Unicode's greek lambda In-Reply-To: <1227180208.7124.41.camel@localhost> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> <1227180208.7124.41.camel@localhost> Message-ID: <28012bc60811200846y5e19fddcp9ef8a74aa4f42a8@mail.gmail.com> On Thu, Nov 20, 2008 at 12:23, Duncan Coutts wrote: > On Thu, 2008-11-20 at 09:50 +0000, Jan Jakubuv wrote: >> Some others are (I have no idea why they are referenced as "lamda" >> instead of "lambda"): > > Yeah, that's why I missed them. I was searching for what I thought was > the correct spelling. Same here. Another problem is font support.. none of the fonts on my system (and I have quite a lot) have these codepoints defined. One would have to open them in a font editor and copy the greek lambda. cheers, Arnar From colinpauladams at googlemail.com Thu Nov 20 12:56:41 2008 From: colinpauladams at googlemail.com (Colin Adams) Date: Thu Nov 20 12:50:42 2008 Subject: Unicode's greek lambda In-Reply-To: <28012bc60811200846y5e19fddcp9ef8a74aa4f42a8@mail.gmail.com> References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> <1227180208.7124.41.camel@localhost> <28012bc60811200846y5e19fddcp9ef8a74aa4f42a8@mail.gmail.com> Message-ID: <1afdeaec0811200956u3b3e882aw6100adee4f90198@mail.gmail.com> I thought it was worth asking David Carlisle about this. Here is his reply: Colin> I thought I would draw this complaint to your attention, since I think > you are probably responsible for getting many of these symbols into > Unicode in the first place. David>I had no part in not lam(b)da:-) that's been there since the beginning for greek text not for mathematics. Unicode know that their spelling is eccentric (and even have a comment to that effect somewhere as I recall) but the overriding rule is they never change the mames once assigned. > Another problem is font support.. none of the fonts on my > system (and I have quite a lot) have these codepoints defined. David> That seems surprising. Some of the more exotic math characters added at Unicode 3.2,4,5 are only just now getting into fonts (such as STIX and Cambria math) but (almost) any truetype or type1 font built in the last 10 years or so should have the basic latin-greek-cyrillic font set, at least. David>Whether or not the editor that you are using knows about anything other than ascii and can actually use the font is another matter of course. 2008/11/20 Arnar Birgisson : > On Thu, Nov 20, 2008 at 12:23, Duncan Coutts > wrote: >> On Thu, 2008-11-20 at 09:50 +0000, Jan Jakubuv wrote: >>> Some others are (I have no idea why they are referenced as "lamda" >>> instead of "lambda"): >> >> Yeah, that's why I missed them. I was searching for what I thought was >> the correct spelling. > > Same here. Another problem is font support.. none of the fonts on my > system (and I have quite a lot) have these codepoints defined. One > would have to open them in a font editor and copy the greek lambda. > > cheers, > Arnar > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From duncan.coutts at worc.ox.ac.uk Thu Nov 20 13:43:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 13:37:56 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <20081120151629.GA22268@matrix.chaos.earth.li> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <20081120151629.GA22268@matrix.chaos.earth.li> Message-ID: <1227206629.7124.107.camel@localhost> On Thu, 2008-11-20 at 15:16 +0000, Ian Lynagh wrote: > On Thu, Nov 20, 2008 at 01:52:12PM +0000, Duncan Coutts wrote: > > > > My selfish suggestion is that we maintain the readline configuration and > > let the people who originally wanted editline support do the work to > > maintain that configuration. > > Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to > be BSD then it can't use it. It's not quite that simple. GHC HQ does not ship readline, it's just shipping BSD code. If I link ghc against readline then the result must be distributed in compliance with the GPL, but that's ok, all linux distros do that. When GHC HQ ship binaries they can configure it to use editline. If someone (even GHC HQ) ships BSD code and GPL code linked together then that doesn't mean that suddenly the BSD code has to be re-licensed, it just means the overall result has to be shipped in a way that is compliant with the GPL (ie providing source and providing a copy of the GPL for the GPL components). I presume this already happens in the windows installer that includes gcc etc. > Although another option would be to make GHCi a separate (GPL) frontend > to the (BSD) GHC API. The only downside is that (with static linking) we > have another large binary. Another upside is that other GHC API users > don't get an editline dependency. Yes, independently of licence issues there's no need for the ghc api package to depend on any line editor. Duncan From colinpauladams at googlemail.com Thu Nov 20 14:08:41 2008 From: colinpauladams at googlemail.com (Colin Adams) Date: Thu Nov 20 14:02:42 2008 Subject: Ghci for Mac OSX? Message-ID: <1afdeaec0811201108n29d371c4ud7e76c4f8e4fb7e4@mail.gmail.com> I installed the 6.10.1 .pkg on my MacBook Air, and ghci works fine, but if I type ghci, I get program not found. Is it supposed to be available for Mac? From bayer at cpw.math.columbia.edu Thu Nov 20 14:34:33 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Thu Nov 20 14:28:34 2008 Subject: Ghci for Mac OSX? In-Reply-To: <1afdeaec0811201108n29d371c4ud7e76c4f8e4fb7e4@mail.gmail.com> References: <1afdeaec0811201108n29d371c4ud7e76c4f8e4fb7e4@mail.gmail.com> Message-ID: You must be having some kind of path issue, ghci is surely there. Here's what I see on my office iMac: > home % echo $PATH > /usr/local/bin:/usr/local/sbin:/usr/texbin:/bin:/sbin:/usr/bin:/usr/ > sbin:/Local/bin > > home % which ghci > /usr/bin/ghci > > home % cat `which ghci` > #!/bin/sh > exec /Library/Frameworks/GHC.framework/Versions/610/usr/bin/ > ghc-6.10.1 --interactive ${1+"$@"} In other words, ghci is a script in /usr/bin pointing to the actual installation, which is handled as a Framework. Just another place to stash stuff, different than what one does in Linux. Echo $PATH, watch for spaces in volume names (who knows!?), see if the "real" file is there, do the above also for ghc itself to see where it ended up. I'm sure it will be something simple... Dave On Nov 20, 2008, at 2:08 PM, Colin Adams wrote: > I installed the 6.10.1 .pkg on my MacBook Air, and ghci works fine, > but if I type ghci, I get program not found. Is it supposed to be > available for Mac? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From duncan.coutts at worc.ox.ac.uk Thu Nov 20 15:39:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 20 15:33:48 2008 Subject: pseq strictness properties Message-ID: <1227213567.7124.131.camel@localhost> I don't think I'm just speaking for myself when I say that pseq is confusing and the docs similarly. Given the type a -> b -> b we would assume that it is lazy in it's first arg and strict in the second. (Even in the presence of seq we know that it really really must be strict in it's second arg since it returns it or _|_ in which case it's still strict). Of course we know of the seq primitive with this type that is strict in both. However we also now have pseq that has the _opposite_ "static" strictness to the original expected strictness. Statically, pseq claims that it's strict in the first but lazy in the parameter that it _returns_. At runtime of course it is strict in both parameters. Given the need for pseq I would have expected pseq to statically be lazy in it's first argument (and actually be strict at runtime). I expected it'd statically be strict in the second arg. So I'm wondering if there is a good explanation for pseq having the opposite strictness properties to that which I expected. At first, even after reading the docs I assumed that it was just a typo and that it really meant it was lazy in the first arg (statically). I was just recording a patch to "fix" the documentation when I checked the underlying code and found to my surprise that the original docs are correct. I also think the docs need to be clarified to make this distinction between the actual strictness behaviour and what the compiler thinks it is during strictness analysis. Since they are different I think it's an important distinction to make. Now that I look at it, par has the same property, of statically being lazy in the second parameter that it returns (and thus is really strict). Again, this is not documented. Summary: why is it that way round, and can we think of a way to explain it better. Duncan From dons at galois.com Thu Nov 20 18:33:16 2008 From: dons at galois.com (Don Stewart) Date: Thu Nov 20 18:27:16 2008 Subject: pseq strictness properties In-Reply-To: <1227213567.7124.131.camel@localhost> References: <1227213567.7124.131.camel@localhost> Message-ID: <20081120233316.GC11226@scytale.galois.com> duncan.coutts: > I don't think I'm just speaking for myself when I say that pseq is > confusing and the docs similarly. > > Given the type > > a -> b -> b > > we would assume that it is lazy in it's first arg and strict in the > second. (Even in the presence of seq we know that it really really must > be strict in it's second arg since it returns it or _|_ in which case > it's still strict). > > Of course we know of the seq primitive with this type that is strict in > both. However we also now have pseq that has the _opposite_ "static" > strictness to the original expected strictness. Could you state "static" strictness as a StrictCheck property? I'm not quite sure what this distinction means, actually. -- Don From rk at trie.org Thu Nov 20 18:51:56 2008 From: rk at trie.org (Rahul Kapoor) Date: Thu Nov 20 18:45:58 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: <4925914B.7080901@gmail.com> References: <492187D9.9000401@gmail.com> <492526D1.4070609@gmail.com> <4925914B.7080901@gmail.com> Message-ID: > Thanks! I think I see the bug. I've just pushed another patch ("round the > size up to a page in mmapForLinker() instead of in the caller"), if you > could try it out that would be great. ghci from ghc-6.11.20081120 works without problems on my xen instance! Thanks! From claus.reinke at talk21.com Thu Nov 20 19:05:10 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Nov 20 18:59:16 2008 Subject: pseq strictness properties References: <1227213567.7124.131.camel@localhost> <20081120233316.GC11226@scytale.galois.com> Message-ID: >> I don't think I'm just speaking for myself when I say that pseq is >> confusing and the docs similarly. >> >> Given the type >> >> a -> b -> b >> >> we would assume that it is lazy in it's first arg and strict in the .. > I'm not quite sure what this distinction means, actually. If I recall the issue correctly: - 'seq' is strict in both parameters (in the second, by being like 'flip const', and in the first, by its special nature). - given that both parameters are thus needed, there is nothing to force the 'a' to be evalutated *before* the 'b'; many programs using 'seq' tend to rely on this property (which the implementation is free to ignore). - 'pseq' is still strict in both parameters, but was meant to offer better evaluation-order guarantees than 'seq' does. - a strict variant of 'case', somewhat like 'case a of !a -> b', might express the intent more closely but then one would want to abstract over it for composition, running back into 'seq'. Hope this isn't too far off;-) Claus ps. it is unfortunate that the docs try to explain evaluation order in terms of how the compiler reacts to manipulating its knowledge about strictness. Strictness of both 'seq' and 'pseq' is as one would expect, and how the intended evaluation order guarantee is achieved is strictly and subtly an implementation matter (not permitting any transformations would also work, for instance). From igloo at earth.li Thu Nov 20 20:26:25 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Nov 20 20:20:26 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1227206629.7124.107.camel@localhost> References: <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <20081120151629.GA22268@matrix.chaos.earth.li> <1227206629.7124.107.camel@localhost> Message-ID: <20081121012625.GA7786@matrix.chaos.earth.li> On Thu, Nov 20, 2008 at 06:43:49PM +0000, Duncan Coutts wrote: > On Thu, 2008-11-20 at 15:16 +0000, Ian Lynagh wrote: > > On Thu, Nov 20, 2008 at 01:52:12PM +0000, Duncan Coutts wrote: > > > > > > My selfish suggestion is that we maintain the readline configuration and > > > let the people who originally wanted editline support do the work to > > > maintain that configuration. > > > > Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to > > be BSD then it can't use it. > > It's not quite that simple. GHC HQ does not ship readline, it's just > shipping BSD code. If I link ghc against readline then the result must > be distributed in compliance with the GPL, but that's ok, all linux > distros do that. When GHC HQ ship binaries they can configure it to use > editline. OK, so I should have said "... it can't use it exclusively". But it's still GHC HQ that needs editline support (or a switch to haskeline, or splitting ghci off, or some other solution. But just reverting to readline-only won't work). Thanks Ian From marlowsd at gmail.com Fri Nov 21 03:40:38 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 21 03:34:42 2008 Subject: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64 In-Reply-To: References: <492187D9.9000401@gmail.com> <492526D1.4070609@gmail.com> <4925914B.7080901@gmail.com> Message-ID: <49267406.3020409@gmail.com> Rahul Kapoor wrote: >> Thanks! I think I see the bug. I've just pushed another patch ("round the >> size up to a page in mmapForLinker() instead of in the caller"), if you >> could try it out that would be great. > > ghci from ghc-6.11.20081120 works without problems on my xen instance! Nice! Thanks for helping out. Cheers, Simon From judah.jacobson at gmail.com Fri Nov 21 04:29:00 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 21 04:23:01 2008 Subject: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) Message-ID: <6d74b0d20811210129q6b98a713l40eaf09881654eaf@mail.gmail.com> On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh wrote: > > Although another option would be to make GHCi a separate (GPL) frontend > to the (BSD) GHC API. The only downside is that (with static linking) we > have another large binary. Another upside is that other GHC API users > don't get an editline dependency. I've actually been experimenting with something similar: darcs get http://code.haskell.org/~judah/ghci-haskeline/ If you have ghc-6.10.1, 'cabal install'ing inside that repo will give you a version of ghci which uses Haskeline as its backend. Basically, I copied 4 modules from the GHC source tree (GhciMonad, InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; the rest of GHC is obtained through the API. Current benefits over the readline/editline versions: - Works on Windows - Tab completion of quoted filenames within Haskell expressions - Tab completion of Unicode identifiers (trac #2058) - Internally, eliminates the need for some GLOBAL_VARs The only real regression I'm aware of is that Haskeline doesn't yet provide a way to "bind" custom key commands as in an inputrc or editrc file. The recent discussion has indicated how important that feature is for some users, so it's next on my TODO list. -Judah From jules at jellybean.co.uk Fri Nov 21 04:49:47 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Nov 21 04:43:49 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4926843B.2010903@jellybean.co.uk> Philip H?lzenspies wrote: > On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: >> Would it be worth adding this hard-won lore somewhere on a Wiki where >> it can be found later? > > Dear Simon, all, > > I don't think logging a specific option on the Wiki is particularly > useful (maybe you would have a default editrc file), because, of course, > everybody has their own particular wishes. For example, aside from the > word-jumping Duncan suggested, I alway use zsh-like history searching, > so I like: > > bind "^[[A" ed-search-prev-history > bind "^[[B" ed-search-next-history > > Also, there are no de facto escape sequences, because special keys (like > function and arrow keys) have different sequences on different > terminals. A useful tip that may be useful to include in the wiki is an > easy trick that will help you find out your terminals escape sequences. > I usually just like to start an application that has no editline or > readline capabilities and press the keys. Telnet is one of my favorite > applications for this purpose. But this is abhorrent. The whole point of the existence of termcap and libraries which build upon it (ncurses, readline, editline, etc) is so that individual users do not have to work out what the escape sequences produced by their terminal are. Something must be very very broken : surely it is not expected behaviour for editline to need configuration in this way? Jules From jwlato at gmail.com Fri Nov 21 04:54:18 2008 From: jwlato at gmail.com (John Lato) Date: Fri Nov 21 04:48:17 2008 Subject: cross module optimization issues In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> On Wed, Nov 19, 2008 at 4:17 PM, Simon Peyton-Jones wrote: > | I'm compiling with -O2 -Wall. After looking at the Core output, I > | think I've found the key difference. A function that is bound in a > | "where" statement is different between the monolithic and split > | sources. I have no idea why, though. I'll experiment with a few > | different things to see if I can get this resolved. > > In general, splitting code across modules should not make programs less efficient -- as Don says, GHC does quite aggressive cross-module inlining. > > There is one exception, though. If a non-exported non-recursive function is called exactly once, then it is inlined *regardless of size*, because doing so does not cause code duplication. But if it's exported and is large, then its inlining is not exposed -- and even if it were it might not be inlined, because doing so duplicates its code an unknown number of times. You can change the threshold for (a) exposing and (b) using an inlining, with flags -funfolding-creation-threshold and -funfolding-use-threshold respectively. > > If you find there's something else going on then I'm all ears. > > Simon > I did finally find the changes that make a difference. I think it's safe to say that I have no idea what's actually going on, so I'll just report my results and let others try to figure it out. I tried upping the thresholds mentioned, up to -funfolding-creation-threshold 200 -funfolding-use-threshold 100. This didn't seem to make any performance difference (I didn't check the core output). This project is based on Oleg's Iteratee code; I started using his IterateeM.hs and Enumerator.hs files and added my own stuff to Enumerator.hs (thanks Oleg, great work as always). When I started cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my minimal test case increased from 19s to 43s. I've found two factors that contributed. When I was cleaning up, I also removed a bunch of unused functions from IterateeM.hs (some of the test functions and functions specific to his running example of HTTP encoding). When I added those functions back in, and added INLINE pragmas to the exported functions in MyEnum.hs, I got the performance back. In general I hadn't added export lists to the modules yet, so all functions should have been exported. So it seems that somehow the unused functions in IterateeM.hs are affecting how the functions I care about get implemented (or exported). I did not expect that. Next step for me is to see what happens if I INLINE the functions I'm exporting and remove the others, I suppose. Thank you Simon and Don for your advice, especially since I'm pretty far over my head at this point. John From duncan.coutts at worc.ox.ac.uk Fri Nov 21 04:58:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 21 04:52:57 2008 Subject: pseq strictness properties In-Reply-To: <20081120233316.GC11226@scytale.galois.com> References: <1227213567.7124.131.camel@localhost> <20081120233316.GC11226@scytale.galois.com> Message-ID: <1227261532.7124.141.camel@localhost> On Thu, 2008-11-20 at 15:33 -0800, Don Stewart wrote: > duncan.coutts: > > I don't think I'm just speaking for myself when I say that pseq is > > confusing and the docs similarly. > > > > Given the type > > > > a -> b -> b > > > > we would assume that it is lazy in it's first arg and strict in the > > second. (Even in the presence of seq we know that it really really must > > be strict in it's second arg since it returns it or _|_ in which case > > it's still strict). > > > > Of course we know of the seq primitive with this type that is strict in > > both. However we also now have pseq that has the _opposite_ "static" > > strictness to the original expected strictness. > > Could you state "static" strictness as a StrictCheck property? > I'm not quite sure what this distinction means, actually. No, because StrictCheck can only check actual strictness properties. I mean actually passing in _|_ and getting _|_ out, at runtime. For pseq there is its actual strictness (it's strict in both args) but then the strictness that we tell the optimiser is different. We claim that it is lazy in it's second argument. That means that the optimiser is not able to do certain transformations that it might otherwise do. Basically it cannot propagate the strictness information upwards to earlier expressions or callers. -- "pseq" is defined a bit weirdly (see below) -- -- The reason for the strange "lazy" call is that it -- fools the compiler into thinking that pseq and par are non-strict in -- their second argument (even if it inlines pseq at the call site). -- If it thinks pseq is strict in "y", then it often evaluates -- "y" before "x", which is totally wrong. {-# INLINE pseq #-} pseq :: a -> b -> b pseq x y = x `seq` lazy y {-# INLINE par #-} par :: a -> b -> b par x y = case (par# x) of { _ -> lazy y } The lazy x function is a primitive that is the same as id, except that it lies to the optimiser and claims that it is not strict. Duncan From duncan.coutts at worc.ox.ac.uk Fri Nov 21 05:02:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 21 04:56:48 2008 Subject: pseq strictness properties In-Reply-To: <20081120233316.GC11226@scytale.galois.com> References: <1227213567.7124.131.camel@localhost> <20081120233316.GC11226@scytale.galois.com> Message-ID: <1227261763.7124.145.camel@localhost> On Thu, 2008-11-20 at 15:33 -0800, Don Stewart wrote: > duncan.coutts: > > I don't think I'm just speaking for myself when I say that pseq is > > confusing and the docs similarly. > > > > Given the type > > > > a -> b -> b > > > > we would assume that it is lazy in it's first arg and strict in the > > second. (Even in the presence of seq we know that it really really must > > be strict in it's second arg since it returns it or _|_ in which case > > it's still strict). > > > > Of course we know of the seq primitive with this type that is strict in > > both. However we also now have pseq that has the _opposite_ "static" > > strictness to the original expected strictness. > > Could you state "static" strictness as a StrictCheck property? > I'm not quite sure what this distinction means, actually. Note that you could make the actual and declared strictness match each other more closely by defining pseq to have the type: pseq :: a -> b -> (# b #) Now it's clear that it returns the second argument unevaluated. Of course that'd be a lot less convenient to use. Duncan From daniil.elovkov at googlemail.com Fri Nov 21 05:23:43 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Fri Nov 21 05:17:52 2008 Subject: GHCi debugger status Message-ID: <49268C2F.4040309@gmail.com> Hello folks I'd like to know, how do ghc developers and users feel about the debugger? I'm using it to some extent on ghc 6.8.2 and find it useful. But I'm getting an impression that it's not too stable. I'm not filing any bug report yet, just want to know how it feels for others. I used to make it panic. I think, it was due to existential types. Now I see it mess up the list of bindings in a funny way. For example, in a previous trace session I had a variable, say, prev. It was bound during pattern matching in a function, say, prevFunc. Now I'm having another trace session, actually stepping from the very beginning. A couple of steps after the beginning, prev suddenly appears in the bindings where prevFunc absolutely has not yet been invoked. It's completely unrelated. In 'show bindings' prev has a wrong type - SomeType (it's ADT). Its real type (when in scope) is [t]. I ask 'length prev' and get 0 :) So, what is your impression of the debugger? -- Daniil Elovkov From marlowsd at gmail.com Fri Nov 21 05:27:45 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 21 05:21:48 2008 Subject: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) In-Reply-To: <6d74b0d20811210129q6b98a713l40eaf09881654eaf@mail.gmail.com> References: <6d74b0d20811210129q6b98a713l40eaf09881654eaf@mail.gmail.com> Message-ID: <49268D21.2040600@gmail.com> Judah Jacobson wrote: > On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh wrote: >> Although another option would be to make GHCi a separate (GPL) frontend >> to the (BSD) GHC API. The only downside is that (with static linking) we >> have another large binary. Another upside is that other GHC API users >> don't get an editline dependency. > > I've actually been experimenting with something similar: > > darcs get http://code.haskell.org/~judah/ghci-haskeline/ > > If you have ghc-6.10.1, 'cabal install'ing inside that repo will give > you a version of ghci which uses Haskeline as its backend. > > Basically, I copied 4 modules from the GHC source tree (GhciMonad, > InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; > the rest of GHC is obtained through the API. > > Current benefits over the readline/editline versions: > - Works on Windows I can attest to that. Nice going Judah! $ cabal update $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ $ cd ghci-haskeline $ cabal install and I have a GHCi on Windows that can do completion, history search, and exits when I hit ^D. That's made my day. BTW, your LICENSE file looks like it was copied from the GHC source tree, it still has various references to GHC and the University of Glasgow. Cheers, Simon From simonpj at microsoft.com Fri Nov 21 05:33:41 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 21 05:27:42 2008 Subject: cross module optimization issues In-Reply-To: <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> | This project is based on Oleg's Iteratee code; I started using his | IterateeM.hs and Enumerator.hs files and added my own stuff to | Enumerator.hs (thanks Oleg, great work as always). When I started | cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my | minimal test case increased from 19s to 43s. | | I've found two factors that contributed. When I was cleaning up, I | also removed a bunch of unused functions from IterateeM.hs (some of | the test functions and functions specific to his running example of | HTTP encoding). When I added those functions back in, and added | INLINE pragmas to the exported functions in MyEnum.hs, I got the | performance back. | | In general I hadn't added export lists to the modules yet, so all | functions should have been exported. I'm totally snowed under with backlog from my recent absence, so I can't look at this myself, but if anyone else wants to I'd be happy to support with advice and suggestions. In general, having an explicit export list is good for performance. I typed an extra section in the GHC performance resource http://haskell.org/haskellwiki/Performance/GHC to explain why. In general that page is where we should document user advice for performance in GHC. I can't explain why *adding* unused functions would change performance though! Simon From simonpj at microsoft.com Fri Nov 21 05:39:06 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 21 05:33:07 2008 Subject: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) In-Reply-To: <49268D21.2040600@gmail.com> References: <6d74b0d20811210129q6b98a713l40eaf09881654eaf@mail.gmail.com> <49268D21.2040600@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33192419B32@EA-EXMSG-C334.europe.corp.microsoft.com> | > I've actually been experimenting with something similar: | > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ .... | > | > Current benefits over the readline/editline versions: | > - Works on Windows | | I can attest to that. Nice going Judah! | | $ cabal update | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ | $ cd ghci-haskeline | $ cabal install | | and I have a GHCi on Windows that can do completion, history search, and | exits when I hit ^D. That's made my day. If I had ?1 for every email I've seen in the last decade about platform-related or license-related problems with readline and now editline, I'd be rich man. Super rich. Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether? Yes that might reduce functionality slightly -- readline/editline are complicated for good reasons. But it's increase functionality in other ways (as Judah says), and by giving us one piece of software that we understand, and can distribute with GHC, it might remove a whole class of problems. Simon From neil.mitchell.2 at credit-suisse.com Fri Nov 21 05:39:46 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Fri Nov 21 05:34:53 2008 Subject: cross module optimization issues In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Hi John, I'm vaguely curious, and have next week off, so if you can provide the code, and directions for running in both variants and the test case, I'll take a look. Please email me at ndmitchell -AT- gmail.com though, as I loose this email address at 11pm tonight :-) Thanks Neil > -----Original Message----- > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Simon Peyton-Jones > Sent: 21 November 2008 10:34 am > To: John Lato > Cc: glasgow-haskell-users@haskell.org; Don Stewart > Subject: RE: cross module optimization issues > > | This project is based on Oleg's Iteratee code; I started using his > | IterateeM.hs and Enumerator.hs files and added my own stuff to > | Enumerator.hs (thanks Oleg, great work as always). When I started > | cleaning up by moving my functions from Enumerator.hs to > MyEnum.hs, my > | minimal test case increased from 19s to 43s. > | > | I've found two factors that contributed. When I was cleaning up, I > | also removed a bunch of unused functions from IterateeM.hs (some of > | the test functions and functions specific to his running example of > | HTTP encoding). When I added those functions back in, and added > | INLINE pragmas to the exported functions in MyEnum.hs, I got the > | performance back. > | > | In general I hadn't added export lists to the modules yet, so all > | functions should have been exported. > > I'm totally snowed under with backlog from my recent absence, > so I can't look at this myself, but if anyone else wants to > I'd be happy to support with advice and suggestions. > > In general, having an explicit export list is good for > performance. I typed an extra section in the GHC performance > resource http://haskell.org/haskellwiki/Performance/GHC to > explain why. In general that page is where we should > document user advice for performance in GHC. > > I can't explain why *adding* unused functions would change > performance though! > > Simon > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From marlowsd at gmail.com Fri Nov 21 05:53:50 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 21 05:47:54 2008 Subject: pseq strictness properties In-Reply-To: <1227213567.7124.131.camel@localhost> References: <1227213567.7124.131.camel@localhost> Message-ID: <4926933E.3010305@gmail.com> Duncan Coutts wrote: > I don't think I'm just speaking for myself when I say that pseq is > confusing and the docs similarly. > > Given the type > > a -> b -> b > > we would assume that it is lazy in it's first arg and strict in the > second. (Even in the presence of seq we know that it really really must > be strict in it's second arg since it returns it or _|_ in which case > it's still strict). > > Of course we know of the seq primitive with this type that is strict in > both. However we also now have pseq that has the _opposite_ "static" > strictness to the original expected strictness. > > Statically, pseq claims that it's strict in the first but lazy in the > parameter that it _returns_. At runtime of course it is strict in both > parameters. > > Given the need for pseq I would have expected pseq to statically be lazy > in it's first argument (and actually be strict at runtime). I expected > it'd statically be strict in the second arg. > > So I'm wondering if there is a good explanation for pseq having the > opposite strictness properties to that which I expected. At first, even > after reading the docs I assumed that it was just a typo and that it > really meant it was lazy in the first arg (statically). I was just > recording a patch to "fix" the documentation when I checked the > underlying code and found to my surprise that the original docs are > correct. > > I also think the docs need to be clarified to make this distinction > between the actual strictness behaviour and what the compiler thinks it > is during strictness analysis. Since they are different I think it's an > important distinction to make. Phil Trinder and others have been working on formalising the difference between pseq and seq, they might be able to tell you more. But here's how I think of it: Denotationally, pseq and seq are the interchangeable. That's important, it tells you what the strictness of pseq is: it's the same as seq. The difference between the two is entirely at the operational level, where we can talk about the order of evaluation. 'pseq x y' causes both x and y to be evaluated, and in the absence of any other demands on x and y, x will be evaluated earlier than y. This isn't quite the same as saying "pseq x y" evaluates x and then y, although in many cases that is what happens. The compiler is still free to move the evaluation of x earlier. It might also be the case that y is already evaluated, so it's not true to say that x is always evaluated before y. In order to make pseq work like this, we have to prevent GHC from performing certain transformations at compile-time. That is because otherwise, GHC is allowed to make any transformations that respect the denotation of the program, but with pseq we want a guarantee at the operational level. We want to prevent GHC from re-ordering evaluation such that y (or any "part of y" if y is a larger expression) is evaluated before x, but GHC can only do that if it knows that y is strictly demanded by pseq. So by removing this information, using the lazy annotation, we prevent GHC from performing the offending transformations. The docs probably shouldn't say anything about what the compiler sees, it should stick to what the programmer sees. Duncan - do you want to try rewording it? Cheers, Simon From marlowsd at gmail.com Fri Nov 21 05:55:00 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 21 05:49:01 2008 Subject: GHCi debugger status In-Reply-To: <49268C2F.4040309@gmail.com> References: <49268C2F.4040309@gmail.com> Message-ID: <49269384.6060603@gmail.com> Daniil Elovkov wrote: > I'd like to know, how do ghc developers and users feel about the debugger? > > I'm using it to some extent on ghc 6.8.2 and find it useful. But I'm > getting an impression that it's not too stable. I'm not filing any bug > report yet, just want to know how it feels for others. > > I used to make it panic. I think, it was due to existential types. > > Now I see it mess up the list of bindings in a funny way. For example, > in a previous trace session I had a variable, say, prev. It was bound > during pattern matching in a function, say, prevFunc. Now I'm having > another trace session, actually stepping from the very beginning. A > couple of steps after the beginning, prev suddenly appears in the > bindings where prevFunc absolutely has not yet been invoked. It's > completely unrelated. In 'show bindings' prev has a wrong type - > SomeType (it's ADT). Its real type (when in scope) is [t]. I ask 'length > prev' and get 0 :) > > So, what is your impression of the debugger? Please file bug reports! Cheers, Simon From p.k.f.holzenspies at utwente.nl Fri Nov 21 05:59:35 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Fri Nov 21 05:53:36 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <4926843B.2010903@jellybean.co.uk> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <4926843B.2010903@jellybean.co.uk> Message-ID: <200811211159.35551.p.k.f.holzenspies@utwente.nl> On Friday 21 November 2008 10:49:47 Jules Bean wrote: > Philip H?lzenspies wrote: > > Also, there are no de facto escape sequences, because special keys (like > > function and arrow keys) have different sequences on different > > terminals. A useful tip that may be useful to include in the wiki is an > > easy trick that will help you find out your terminals escape sequences. > > I usually just like to start an application that has no editline or > > readline capabilities and press the keys. Telnet is one of my favorite > > applications for this purpose. > > But this is abhorrent. > > The whole point of the existence of termcap and libraries which build > upon it (ncurses, readline, editline, etc) is so that individual users > do not have to work out what the escape sequences produced by their > terminal are. > > Something must be very very broken : surely it is not expected behaviour > for editline to need configuration in this way? One can call it broken, another will say users should settle for the default behaviour. Neither readline, nor editline *need* configuration this way, because they do come with sensible defaults. However, some people want custom behaviour and they'll have to figure out how stuff works for their machine. I think a sensible purpose of a Wiki is to help people get some of the more tricky business done. Also, I don't see what is wrong with typing in terms of escape sequences per se, but for those that have something against it; there's bound to be some program somewhere that will allow you to type instead of ^[[A. The upside of the telnet tip, is that it works on many *NIXs and their derivatives. It even works on OSX, so it's a one-size-fits-(almost)-all tip. Philip From jules at jellybean.co.uk Fri Nov 21 06:06:22 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Nov 21 06:00:21 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <200811211159.35551.p.k.f.holzenspies@utwente.nl> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <4926843B.2010903@jellybean.co.uk> <200811211159.35551.p.k.f.holzenspies@utwente.nl> Message-ID: <4926962E.5070707@jellybean.co.uk> Philip K.F. H?lzenspies wrote: > On Friday 21 November 2008 10:49:47 Jules Bean wrote: >> Philip H?lzenspies wrote: >>> Also, there are no de facto escape sequences, because special keys (like >>> function and arrow keys) have different sequences on different >>> terminals. A useful tip that may be useful to include in the wiki is an >>> easy trick that will help you find out your terminals escape sequences. >>> I usually just like to start an application that has no editline or >>> readline capabilities and press the keys. Telnet is one of my favorite >>> applications for this purpose. >> But this is abhorrent. >> >> The whole point of the existence of termcap and libraries which build >> upon it (ncurses, readline, editline, etc) is so that individual users >> do not have to work out what the escape sequences produced by their >> terminal are. >> >> Something must be very very broken : surely it is not expected behaviour >> for editline to need configuration in this way? > > One can call it broken, another will say users should settle for the default > behaviour. Neither readline, nor editline *need* configuration this way, > because they do come with sensible defaults. However, some people want custom > behaviour and they'll have to figure out how stuff works for their machine. And suppose I log on from another machine with a different TERM setting? or just use a different terminal program? This is broken. From duncan.coutts at worc.ox.ac.uk Fri Nov 21 06:20:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 21 06:14:47 2008 Subject: pseq strictness properties In-Reply-To: <4926933E.3010305@gmail.com> References: <1227213567.7124.131.camel@localhost> <4926933E.3010305@gmail.com> Message-ID: <1227266441.7124.151.camel@localhost> On Fri, 2008-11-21 at 10:53 +0000, Simon Marlow wrote: > The docs probably shouldn't say anything about what the compiler sees, it > should stick to what the programmer sees. Duncan - do you want to try > rewording it? Hmm, though the difference is really in what transformations you want the compiler not to do. I would not say the operational behaviour is actually different. Used in isolation there's really no way to distinguish them, even using trace and other tricks to observe the evaluation order. I guess we can try to simplify it to something like "evaluation happens here" (pseq) vs "evaluation happens here or before" (seq). Duncan From marlowsd at gmail.com Fri Nov 21 06:31:51 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 21 06:25:55 2008 Subject: pseq strictness properties In-Reply-To: <1227266441.7124.151.camel@localhost> References: <1227213567.7124.131.camel@localhost> <4926933E.3010305@gmail.com> <1227266441.7124.151.camel@localhost> Message-ID: <49269C27.9030103@gmail.com> Duncan Coutts wrote: > On Fri, 2008-11-21 at 10:53 +0000, Simon Marlow wrote: > >> The docs probably shouldn't say anything about what the compiler sees, it >> should stick to what the programmer sees. Duncan - do you want to try >> rewording it? > > Hmm, though the difference is really in what transformations you want > the compiler not to do. I would not say the operational behaviour is > actually different. Used in isolation there's really no way to > distinguish them, even using trace and other tricks to observe the > evaluation order. Yes, to be more precise, the difference is in what *guarantees* you get about operational behaviour. You might be able to observe a difference with trace, or you might not, depending on what the compiler did. Using trace you will always observe pseq's first argument evaluated before its second, that's not true of seq. > I guess we can try to simplify it to something like "evaluation happens > here" (pseq) vs "evaluation happens here or before" (seq). Ok, but we need to be careful: it would be wrong to talk about ordering at all with respect to seq, since it tells you nothing about ordering. The implementation might be using a non-lazy evaluation strategy, for example. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Fri Nov 21 06:39:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 21 06:33:14 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <200811211159.35551.p.k.f.holzenspies@utwente.nl> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <4926843B.2010903@jellybean.co.uk> <200811211159.35551.p.k.f.holzenspies@utwente.nl> Message-ID: <1227267550.7124.162.camel@localhost> On Fri, 2008-11-21 at 11:59 +0100, Philip K.F. H?lzenspies wrote: > On Friday 21 November 2008 10:49:47 Jules Bean wrote: > > Something must be very very broken : surely it is not expected behaviour > > for editline to need configuration in this way? > > One can call it broken, another will say users should settle for the default > behaviour. Neither readline, nor editline *need* configuration this way, > because they do come with sensible defaults. But that's just it. It seems that readline does come with sensible defaults and editline does not. For example xterm is not a rare kind of terminal (basically every terminal in use claims to be xterm) and yet delete does not work with it out-of-the-box with editline. That is broken. [To add insult to injury, even when I look up the escape sequence for delete using the cat/telnet trick, I still cannot configure editline to recognise it.] > However, some people want custom behaviour and they'll have to figure > out how stuff works for their machine. That's a different matter. Most people have never configured anything custom and just want the common basics to work. In fact most linux users have never looked at a readline man page and don't know what an escape sequence is. It has to work right for the users who do not know that it is possible to configure, otherwise they will call it broken. Duncan From Malcolm.Wallace at cs.york.ac.uk Fri Nov 21 06:37:48 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Nov 21 06:33:26 2008 Subject: pseq strictness properties In-Reply-To: <1227266441.7124.151.camel@localhost> References: <1227213567.7124.131.camel@localhost> <4926933E.3010305@gmail.com> <1227266441.7124.151.camel@localhost> Message-ID: <20081121113748.3fc200dd.Malcolm.Wallace@cs.york.ac.uk> Duncan Coutts wrote: > I guess we can try to simplify it to something like "evaluation > happens here" (pseq) vs "evaluation happens here or before" (seq). No, that is not correct, or at least it is highly misleading. The key difference between them is that: (x `pseq` y) = if y is not yet in WHNF, the compiler guarantees that x will be evaluated to WHNF before y. (x `seq` y) = if y is not yet in WHNF, the compiler can choose whether to evaluate y to WHNF before x, or x before y. In other words, pseq guarantees sequencing (given a side condition), whilst seq does not guarantee sequencing. Regards, Malcolm From dagit at codersbase.com Fri Nov 21 08:09:06 2008 From: dagit at codersbase.com (Jason Dagit) Date: Fri Nov 21 08:03:05 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> Message-ID: On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty wrote: > Jason Dagit: > > On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty > wrote: >> >> Ian Lynagh: >>> >>> On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: >>>> >>>> On 2008 Nov 4, at 20:26, Jason Dagit wrote: >>>>> >>>>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty >>>>> wrote: >>>>>> >>>>>> Are you sure it does deinstall the 6.8 compiler? >>>>>> >>>>>> After installing 6.10, there should be a 608/ and a 610/ >>>>>> directory. This >>>>>> certainly happens on my Mac and I am not aware of an option to >>>>>> change that >>>>>> behaviour. >>>> >>>> I expect if you used the OSX installer then /Library/Receipts is >>>> screwing you (it wipes the old files listed in the .bom file). Try >>>> finding and removing the receipt directory and bom file before >>>> installing. >>> >>> The only file I can see that looks relevant is >>> /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom >>> >>> Wouldn't removing it make uninstall impossible? >>> >>> In fact, if you did manage to get 2 versions installed, how would >>> /Library/Frameworks/GHC.framework/Tools/Uninstaller >>> know which version to uninstall? Wouldn't it only know how to uninstall >>> the version it came with? I'd suggest that the overlapping file >>> "Uninstaller" could be why the older version gets removed, but that >>> wouldn't explain why Manuel can install both at once. >> >> A current limitation of the MacOS package system is that it does not >> support uninstalling of packages; cf >> >> >> http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#//apple_ref/doc/uid/10000145i-CH6-DontLinkElementID_29 >> >> This is not a big drama on MacOS, as MacOS encourages the distribution of >> software packages as "bundles": >> >> >> http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html >> >> This essentially means that instead of sprinkling files all over the file >> system (as is common in other OSes), MacOS applications and frameworks >> (Mac-speak for libraries) are kept in a single directory. Uninstalling then >> means doing an rm -rf on that directory. >> >> Unfortunately, some applications (including GHC and Apple's Xcode IDE) >> can't be entirely contained in a single directory. In the case of GHC, we >> want symlinks in /usr/bin. The established way of uninstalling such >> applications is by supplying an Uninstaller script, just as I did for GHC. >> (Apple does the same for Xcode.) >> >> The purpose of the Uninstaller script is too completely remove >> GHC.framework from a machine - not just to remove one version. In fact, if >> more than one version of GHC is installed, the Uninstaller will refuse to >> run and require the manual removal of all versions, but the current (easily >> achieved by a "rm -rf >> /Library/Frameworks/GHC.framework/Versions/"). The main feature of >> the Uninstaller script is to get rid of all symlinks pointing into >> GHC.framework. The framework itself is just deleted by a "rm -rf" as >> expected. (It also removes the above mentioned receipt file.) >> >> So, to directly answer the above questions: >> * The package manger (which uses the receipts) can't uninstall and the >> uninstaller script doesn't need the receipt. So, even after deleteing the >> receibt, you can still uninstall. >> * The Uninstaller can uninstall any version (at least as long as no >> symlinks are put into new directories outside of the bundle that the >> Uninstaller doesn't know about). > > Is there an update on this thread? I would still like to have my cake and > eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the > installer hasn't been updated and if I try again I will lose my copy of > 6.8.3. > > Sorry, but for the moment, my (rather limited knowledge) of the > MacOS packaging system is exhausted, and currently I don't have the time to > search the web or experiment to try to learn more. It would be helpful to > have the input of somebody who has more experience with MacOS packages. > Manuel Okay. That's fine, the OSX installer system sounds odd. I don't want to fight with it myself. I just want to upgrade ghc and I was getting pressure to do so and I tried the .tar.bz version, but I had some annoying experiences that I can share. So, the page here: http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel Has only this as installation instructions: This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and libgmp.3.dylib under /opt/local/lib/. I had no idea how to do the install or how to satisfy the requirements. By pestering others I learned that you install libraries into /opt/local using MacPorts. The next challenge was learning what to do with the .tar.bz file once it was downloaded. I found an INSTALL file inside the tarball with some instructions thankfully. I wish the download page said something about this. It was quite a mystery. I only looked in the tarball because I was frustrated. I don't like downloading and untarring things if i don't know what to expect inside them. But, I still think I did something wrong because the first thing I tried to build with 6.10 complained that -lgmp was not found. I have checked, it's installed and I saw the ./configure script for the 6.10 installation find it. Quite baffling. I guess I'm stuck on 6.8.3 for a while longer. Jason From Christian.Maeder at dfki.de Fri Nov 21 08:57:52 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Nov 21 08:51:51 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> Message-ID: <4926BE60.3070806@dfki.de> Jason Dagit wrote: > But, I still think I did something wrong because the first thing I > tried to build with 6.10 complained that -lgmp was not found. I have > checked, it's installed and I saw the ./configure script for the 6.10 > installation find it. Actually I have the same problem. I need to set export LIBRARY_PATH=/opt/local/lib when linking, because I've created the binary-dist with this setting. Ideally, /opt/local/lib should also be listed under "library-dirs:" for ghc-pkg describe rts Alternatively, you can copy /opt/local/lib/libgmp.a into ghc's libdir /lib/ghc-6.10.1/, with the additional "benefit" that gmp is statically linked into your binary (for platforms without /opt/local/lib/libgmp.dylib) Cheers Christian From marlowsd at gmail.com Fri Nov 21 09:01:11 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 21 08:55:16 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1227189132.7124.93.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> Message-ID: <4926BF27.9070506@gmail.com> Duncan Coutts wrote: > On Thu, 2008-11-20 at 12:51 +0000, Simon Marlow wrote: >> Duncan Coutts wrote: > >>> What I really think is that we should add back optional readline >>> support. People building closed source ghc binaries would not use it but >>> linux distros could enable it and provide a better "out of the box" >>> experience. As I understand it there would be no licencing problems with >>> that approach. >> One downside I can see is that it gives us an extra configuration to test >> and maintain. It's hard enough keeping one line-editing binding working, >> let alone two! >> >> It's true that editline seems to have brought a bunch of headaches with it, >> though. Perhaps Haskelline is the way to go in the future. > > My selfish suggestion is that we maintain the readline configuration and > let the people who originally wanted editline support do the work to > maintain that configuration. I get the feeling they don't care about if > it works well, just that it's got the license they want (which is a > perfectly reasonable position). I propose we do this: * extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package. * Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs. This gives us line-editing on Windows, and removes problematic external C library dependencies. * Make it possible to compile the ghc-bin package against readline. Upload ghc-bin to Hackage, so people can say cabal install ghc-bin -f readline and get a GHCi built against readline if they want. Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package? Ok? Cheers, Simon From Christian.Maeder at dfki.de Fri Nov 21 09:10:07 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Nov 21 09:04:06 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: <4926BE60.3070806@dfki.de> References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> <4926BE60.3070806@dfki.de> Message-ID: <4926C13F.6010802@dfki.de> Also note that gmp.h will not be found without: export CPATH=/opt/local/include This directory should be part of the "include-dirs:" for the rts package. And again the file /opt/local/include/gmp.h could be simply copied to /lib/ghc-6.10.1/include/ Sorry for the trouble Christian Christian Maeder wrote: > Jason Dagit wrote: >> But, I still think I did something wrong because the first thing I >> tried to build with 6.10 complained that -lgmp was not found. I have >> checked, it's installed and I saw the ./configure script for the 6.10 >> installation find it. > > Actually I have the same problem. I need to set > > export LIBRARY_PATH=/opt/local/lib > > when linking, because I've created the binary-dist with this setting. > > Ideally, /opt/local/lib should also be listed under "library-dirs:" for > > ghc-pkg describe rts > > Alternatively, you can copy /opt/local/lib/libgmp.a into ghc's libdir > /lib/ghc-6.10.1/, with the additional "benefit" that gmp is > statically linked into your binary (for platforms without > /opt/local/lib/libgmp.dylib) > > Cheers Christian From dagit at codersbase.com Fri Nov 21 09:36:09 2008 From: dagit at codersbase.com (Jason Dagit) Date: Fri Nov 21 09:30:09 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: <4926C13F.6010802@dfki.de> References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> <4926BE60.3070806@dfki.de> <4926C13F.6010802@dfki.de> Message-ID: On Fri, Nov 21, 2008 at 6:10 AM, Christian Maeder wrote: > Also note that gmp.h will not be found without: > > export CPATH=/opt/local/include > > This directory should be part of the "include-dirs:" for the rts > package. And again the file /opt/local/include/gmp.h could be simply > copied to /lib/ghc-6.10.1/include/ Hmm...Okay, so how do I add a path to include-dirs? In my case =$HOME, so I looked under ~/lib/ghc-6.10.1 and I didn't see any files I could modify to change it. Was it an option I missed when I was doing the configure for the install? Thanks for making this package. I hope we can make the install easier to understand and less error prone (fewer things to tweak locally). Thanks, Jason From gwright at comcast.net Fri Nov 21 09:56:55 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri Nov 21 09:51:04 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> Message-ID: Hi Jason, On Nov 21, 2008, at 8:09 AM, Jason Dagit wrote: > On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty > wrote: >> Jason Dagit: >> >> On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty >> wrote: >>> >>> Ian Lynagh: >>>> >>>> On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery >>>> KF8NH wrote: >>>>> >>>>> On 2008 Nov 4, at 20:26, Jason Dagit wrote: >>>>>> >>>>>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty >>>>>> wrote: >>>>>>> >>>>>>> Are you sure it does deinstall the 6.8 compiler? >>>>>>> >>>>>>> After installing 6.10, there should be a 608/ and a 610/ >>>>>>> directory. This >>>>>>> certainly happens on my Mac and I am not aware of an option to >>>>>>> change that >>>>>>> behaviour. >>>>> >>>>> I expect if you used the OSX installer then /Library/Receipts is >>>>> screwing you (it wipes the old files listed in the .bom file). >>>>> Try >>>>> finding and removing the receipt directory and bom file before >>>>> installing. >>>> >>>> The only file I can see that looks relevant is >>>> /Library/Receipts/boms/ >>>> org.haskell.glasgowHaskellCompiler.ghc.pkg.bom >>>> >>>> Wouldn't removing it make uninstall impossible? >>>> >>>> In fact, if you did manage to get 2 versions installed, how would >>>> /Library/Frameworks/GHC.framework/Tools/Uninstaller >>>> know which version to uninstall? Wouldn't it only know how to >>>> uninstall >>>> the version it came with? I'd suggest that the overlapping file >>>> "Uninstaller" could be why the older version gets removed, but that >>>> wouldn't explain why Manuel can install both at once. >>> >>> A current limitation of the MacOS package system is that it does not >>> support uninstalling of packages; cf >>> >>> >>> http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ >>> /apple_ref/doc/uid/10000145i-CH6-DontLinkElementID_29 >>> >>> This is not a big drama on MacOS, as MacOS encourages the >>> distribution of >>> software packages as "bundles": >>> >>> >>> http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html >>> >>> This essentially means that instead of sprinkling files all over >>> the file >>> system (as is common in other OSes), MacOS applications and >>> frameworks >>> (Mac-speak for libraries) are kept in a single directory. >>> Uninstalling then >>> means doing an rm -rf on that directory. >>> >>> Unfortunately, some applications (including GHC and Apple's Xcode >>> IDE) >>> can't be entirely contained in a single directory. In the case of >>> GHC, we >>> want symlinks in /usr/bin. The established way of uninstalling such >>> applications is by supplying an Uninstaller script, just as I did >>> for GHC. >>> (Apple does the same for Xcode.) >>> >>> The purpose of the Uninstaller script is too completely remove >>> GHC.framework from a machine - not just to remove one version. In >>> fact, if >>> more than one version of GHC is installed, the Uninstaller will >>> refuse to >>> run and require the manual removal of all versions, but the >>> current (easily >>> achieved by a "rm -rf >>> /Library/Frameworks/GHC.framework/Versions/"). The main >>> feature of >>> the Uninstaller script is to get rid of all symlinks pointing into >>> GHC.framework. The framework itself is just deleted by a "rm -rf" >>> as >>> expected. (It also removes the above mentioned receipt file.) >>> >>> So, to directly answer the above questions: >>> * The package manger (which uses the receipts) can't uninstall and >>> the >>> uninstaller script doesn't need the receipt. So, even after >>> deleteing the >>> receibt, you can still uninstall. >>> * The Uninstaller can uninstall any version (at least as long as no >>> symlinks are put into new directories outside of the bundle that the >>> Uninstaller doesn't know about). >> >> Is there an update on this thread? I would still like to have my >> cake and >> eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the >> installer hasn't been updated and if I try again I will lose my >> copy of >> 6.8.3. >> >> Sorry, but for the moment, my (rather limited knowledge) of the >> MacOS packaging system is exhausted, and currently I don't have the >> time to >> search the web or experiment to try to learn more. It would be >> helpful to >> have the input of somebody who has more experience with MacOS >> packages. >> Manuel > > Okay. That's fine, the OSX installer system sounds odd. I don't want > to fight with it myself. I just want to upgrade ghc and I was getting > pressure to do so and I tried the .tar.bz version, but I had some > annoying experiences that I can share. > > So, the page here: > http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel > > Has only this as installation instructions: > This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by > Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and > libgmp.3.dylib under /opt/local/lib/. > > I had no idea how to do the install or how to satisfy the > requirements. By pestering others I learned that you install > libraries into /opt/local using MacPorts. The next challenge was > learning what to do with the .tar.bz file once it was downloaded. I > found an INSTALL file inside the tarball with some instructions > thankfully. I wish the download page said something about this. It > was quite a mystery. I only looked in the tarball because I was > frustrated. I don't like downloading and untarring things if i don't > know what to expect inside them. > > But, I still think I did something wrong because the first thing I > tried to build with 6.10 complained that -lgmp was not found. I have > checked, it's installed and I saw the ./configure script for the 6.10 > installation find it. > > Quite baffling. > > I guess I'm stuck on 6.8.3 for a while longer. > > Jason The latest MacPorts ghc 6.10.1 fixes a number of build bugs and might work for you. It builds on ppc/Tiger, i386/Leopard and i386/Tiger. ppc/ Leopard still fails, but I now have an account on a machine that I can use to test and debug. If you could send a detailed log of the failure to find "-lgmp" I would appreciate it. I've fixed two different bugs involving the library path that caused this symptom. It would be good to know if your failure is covered by the existing patches. I'll send the patches upstream along with bug tickets in the next few days. Best Wishes, Greg From ccshan at post.harvard.edu Fri Nov 21 09:06:17 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Fri Nov 21 09:54:32 2008 Subject: Lazy minimum References: <89BB8007-B733-48B2-80E9-BB9D19A40024@math.columbia.edu> <49a77b7a0811192038l6b5ac830x6ed2855beb78bcb9@mail.gmail.com> <200811200018.35834.dan.doel@gmail.com> <49a77b7a0811192227v74e21e7eh4d72261b4dcf867@mail.gmail.com> Message-ID: Dave Bayer wrote in article in gmane.comp.lang.haskell.glasgow.user: > So to summarize the responses, there's no GHC language support for > introspecting lazy structures, allowing one to write a generic bounded > compare that only evaluates lazy structures to a specified depth. One > can however write a class, and solve this problem type-by-type with a > common interface. You might like how Lazy SmallCheck does it (then again, maybe not) http://www.cs.york.ac.uk/fp/smallcheck/smallcheck.pdf (Section 4.6) It might also help to use discriminators instead of Ord for comparison: http://portal.acm.org/citation.cfm?id=1411220 -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2008-11-20 Universal Children's Day http://unicef.org/ 1948-12-10 Universal Declaration of Human Rights http://everyhumanhasrights.org From Christian.Maeder at dfki.de Fri Nov 21 10:04:15 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Nov 21 09:58:14 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> <4926BE60.3070806@dfki.de> <4926C13F.6010802@dfki.de> Message-ID: <4926CDEF.6070002@dfki.de> Jason Dagit wrote: > On Fri, Nov 21, 2008 at 6:10 AM, Christian Maeder > wrote: >> Also note that gmp.h will not be found without: >> >> export CPATH=/opt/local/include >> >> This directory should be part of the "include-dirs:" for the rts >> package. And again the file /opt/local/include/gmp.h could be simply >> copied to /lib/ghc-6.10.1/include/ > > Hmm...Okay, so how do I add a path to include-dirs? In my case > =$HOME, so I looked under ~/lib/ghc-6.10.1 and I didn't see > any files I could modify to change it. I would suggest to only copy libgmp.a and gmp.h, because the file to edit it /lib/ghc-6.10.1/package.conf. Search for (package) "rts" and the fields "libraryDirs" and "includeDirs". But if you mess up this file, all may be lost (so back it up first). > > Was it an option I missed when I was doing the configure for the install? I'm not sure what configure options to pass (before my building or your installing) > Thanks for making this package. I hope we can make the install easier > to understand and less error prone (fewer things to tweak locally). > > Thanks, > Jason Thanks, too Christian From arnarbi at gmail.com Fri Nov 21 10:21:12 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Fri Nov 21 10:15:12 2008 Subject: Unicode's greek lambda In-Reply-To: <1afdeaec0811200956u3b3e882aw6100adee4f90198@mail.gmail.com> References: <20081118.180025.234710170.kazu@iij.ad.jp> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> <1227180208.7124.41.camel@localhost> <28012bc60811200846y5e19fddcp9ef8a74aa4f42a8@mail.gmail.com> <1afdeaec0811200956u3b3e882aw6100adee4f90198@mail.gmail.com> Message-ID: <28012bc60811210721h5cfe9e84g1b79c9c95906a626@mail.gmail.com> Hi, On Thu, Nov 20, 2008 at 18:56, Colin Adams wrote: >> Another problem is font support.. none of the fonts on my >> system (and I have quite a lot) have these codepoints defined. > > David> That seems surprising. Some of the more exotic math characters added at > Unicode 3.2,4,5 are only just now getting into fonts (such as STIX and > Cambria math) but (almost) any truetype or type1 font built in the last > 10 years or so should have the basic latin-greek-cyrillic font set, at > least. To clarify - most of modern fonts do in deed have latin-greek-cyrillic (including the U+03BB lambda), but I was referring to the specific math symbols such as the U+1D6CC bold lam(b)da, which reside in the Supplementary Multilingual Plane (SMP). Those are indeed not present in my fonts, including Lucida Math and Adobe Mathematical Pi). cheers, Arnar From dagit at codersbase.com Fri Nov 21 10:22:09 2008 From: dagit at codersbase.com (Jason Dagit) Date: Fri Nov 21 10:16:08 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> Message-ID: On Fri, Nov 21, 2008 at 6:56 AM, Gregory Wright wrote: > > Hi Jason, > > On Nov 21, 2008, at 8:09 AM, Jason Dagit wrote: > >> On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty >> wrote: >>> >>> Jason Dagit: >>> >>> On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty >>> wrote: >>>> >>>> Ian Lynagh: >>>>> >>>>> On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH >>>>> wrote: >>>>>> >>>>>> On 2008 Nov 4, at 20:26, Jason Dagit wrote: >>>>>>> >>>>>>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty >>>>>>> wrote: >>>>>>>> >>>>>>>> Are you sure it does deinstall the 6.8 compiler? >>>>>>>> >>>>>>>> After installing 6.10, there should be a 608/ and a 610/ >>>>>>>> directory. This >>>>>>>> certainly happens on my Mac and I am not aware of an option to >>>>>>>> change that >>>>>>>> behaviour. >>>>>> >>>>>> I expect if you used the OSX installer then /Library/Receipts is >>>>>> screwing you (it wipes the old files listed in the .bom file). Try >>>>>> finding and removing the receipt directory and bom file before >>>>>> installing. >>>>> >>>>> The only file I can see that looks relevant is >>>>> /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom >>>>> >>>>> Wouldn't removing it make uninstall impossible? >>>>> >>>>> In fact, if you did manage to get 2 versions installed, how would >>>>> /Library/Frameworks/GHC.framework/Tools/Uninstaller >>>>> know which version to uninstall? Wouldn't it only know how to uninstall >>>>> the version it came with? I'd suggest that the overlapping file >>>>> "Uninstaller" could be why the older version gets removed, but that >>>>> wouldn't explain why Manuel can install both at once. >>>> >>>> A current limitation of the MacOS package system is that it does not >>>> support uninstalling of packages; cf >>>> >>>> >>>> >>>> http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#//apple_ref/doc/uid/10000145i-CH6-DontLinkElementID_29 >>>> >>>> This is not a big drama on MacOS, as MacOS encourages the distribution >>>> of >>>> software packages as "bundles": >>>> >>>> >>>> >>>> http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html >>>> >>>> This essentially means that instead of sprinkling files all over the >>>> file >>>> system (as is common in other OSes), MacOS applications and frameworks >>>> (Mac-speak for libraries) are kept in a single directory. Uninstalling >>>> then >>>> means doing an rm -rf on that directory. >>>> >>>> Unfortunately, some applications (including GHC and Apple's Xcode IDE) >>>> can't be entirely contained in a single directory. In the case of GHC, >>>> we >>>> want symlinks in /usr/bin. The established way of uninstalling such >>>> applications is by supplying an Uninstaller script, just as I did for >>>> GHC. >>>> (Apple does the same for Xcode.) >>>> >>>> The purpose of the Uninstaller script is too completely remove >>>> GHC.framework from a machine - not just to remove one version. In fact, >>>> if >>>> more than one version of GHC is installed, the Uninstaller will refuse >>>> to >>>> run and require the manual removal of all versions, but the current >>>> (easily >>>> achieved by a "rm -rf >>>> /Library/Frameworks/GHC.framework/Versions/"). The main >>>> feature of >>>> the Uninstaller script is to get rid of all symlinks pointing into >>>> GHC.framework. The framework itself is just deleted by a "rm -rf" as >>>> expected. (It also removes the above mentioned receipt file.) >>>> >>>> So, to directly answer the above questions: >>>> * The package manger (which uses the receipts) can't uninstall and the >>>> uninstaller script doesn't need the receipt. So, even after deleteing >>>> the >>>> receibt, you can still uninstall. >>>> * The Uninstaller can uninstall any version (at least as long as no >>>> symlinks are put into new directories outside of the bundle that the >>>> Uninstaller doesn't know about). >>> >>> Is there an update on this thread? I would still like to have my cake >>> and >>> eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the >>> installer hasn't been updated and if I try again I will lose my copy of >>> 6.8.3. >>> >>> Sorry, but for the moment, my (rather limited knowledge) of the >>> MacOS packaging system is exhausted, and currently I don't have the time >>> to >>> search the web or experiment to try to learn more. It would be helpful >>> to >>> have the input of somebody who has more experience with MacOS packages. >>> Manuel >> >> Okay. That's fine, the OSX installer system sounds odd. I don't want >> to fight with it myself. I just want to upgrade ghc and I was getting >> pressure to do so and I tried the .tar.bz version, but I had some >> annoying experiences that I can share. >> >> So, the page here: >> http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel >> >> Has only this as installation instructions: >> This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by >> Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and >> libgmp.3.dylib under /opt/local/lib/. >> >> I had no idea how to do the install or how to satisfy the >> requirements. By pestering others I learned that you install >> libraries into /opt/local using MacPorts. The next challenge was >> learning what to do with the .tar.bz file once it was downloaded. I >> found an INSTALL file inside the tarball with some instructions >> thankfully. I wish the download page said something about this. It >> was quite a mystery. I only looked in the tarball because I was >> frustrated. I don't like downloading and untarring things if i don't >> know what to expect inside them. >> >> But, I still think I did something wrong because the first thing I >> tried to build with 6.10 complained that -lgmp was not found. I have >> checked, it's installed and I saw the ./configure script for the 6.10 >> installation find it. >> >> Quite baffling. >> >> I guess I'm stuck on 6.8.3 for a while longer. >> >> Jason > > The latest MacPorts ghc 6.10.1 fixes a number of build bugs and might work > for you. It builds on ppc/Tiger, i386/Leopard and i386/Tiger. ppc/Leopard > still > fails, but I now have an account on a machine that I can use to test and > debug. I've had a history of bad experiences with MacPorts and I remain fully skeptical of its use. In particular, I've seen too many darcs users get bitten by macport builds when a build from source "just works", every copy of emacs that I've built from macports has started segfaulting when Apple send their next update, and ghc builds can take a day (6-10 hours realistically). Other more minor problems I'd had include it wasting space without a good clean up option, confusing me and one other problem that someone showed me how to fix today so maybe I won't mention it. I also do not like the MacPort philosophy of requiring the end user to build the requested package along with recursively building/installing all the dependencies. In this regard, I would prefer Fink except that software in fink tends to ridiculously old. > If you could send a detailed log of the failure to find "-lgmp" I would > appreciate it. > I've fixed two different bugs involving the library path that caused this > symptom. > It would be good to know if your failure is covered by the existing patches. > > I'll send the patches upstream along with bug tickets in the next few days. The error was rather simple and I don't expect you'll be interested in it as it was the result of a cabal-install when using the Christian Maeder's ghc build. But, here it is just in case I'm wrong: $ cabal install "zlib >= 0.5" Resolving dependencies... 'zlib-0.5.0.0' is cached. Configuring zlib-0.5.0.0... Preprocessing library zlib-0.5.0.0... ld: library not found for -lgmp collect2: ld returned 1 exit status linking dist/build/Codec/Compression/Zlib/Stream_hsc_make.o failed command was: /usr/bin/gcc -lz -L/Users/dagit/lib/ghc-6.10.1/bytestring-0.9.1.4 -L/Users/dagit/lib/ghc-6.10.1/base-3.0.3.0 -L/Users/dagit/lib/ghc-6.10.1/syb-0.1.0.0 -L/Users/dagit/lib/ghc-6.10.1/base-4.0.0.0 -L/Users/dagit/lib/ghc-6.10.1/integer-0.1.0.0 -L/Users/dagit/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Users/dagit/lib/ghc-6.10.1 -lm -lffi -lgmp -ldl dist/build/Codec/Compression/Zlib/Stream_hsc_make.o -o dist/build/Codec/Compression/Zlib/Stream_hsc_make cabal: Error: some packages failed to install: zlib-0.5.0.0 failed during the building phase. The exception was: exit: ExitFailure 1 Thanks, Jason From dagit at codersbase.com Fri Nov 21 10:33:23 2008 From: dagit at codersbase.com (Jason Dagit) Date: Fri Nov 21 10:27:23 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: <4926CDEF.6070002@dfki.de> References: <20081104181106.GA20684@matrix.chaos.earth.li> <20081105133745.GA3649@matrix.chaos.earth.li> <5DBF01D2-BC4F-409D-B28E-C14251BE1B26@cse.unsw.edu.au> <4926BE60.3070806@dfki.de> <4926C13F.6010802@dfki.de> <4926CDEF.6070002@dfki.de> Message-ID: On Fri, Nov 21, 2008 at 7:04 AM, Christian Maeder wrote: > Jason Dagit wrote: >> On Fri, Nov 21, 2008 at 6:10 AM, Christian Maeder >> wrote: >>> Also note that gmp.h will not be found without: >>> >>> export CPATH=/opt/local/include >>> >>> This directory should be part of the "include-dirs:" for the rts >>> package. And again the file /opt/local/include/gmp.h could be simply >>> copied to /lib/ghc-6.10.1/include/ >> >> Hmm...Okay, so how do I add a path to include-dirs? In my case >> =$HOME, so I looked under ~/lib/ghc-6.10.1 and I didn't see >> any files I could modify to change it. > > I would suggest to only copy libgmp.a and gmp.h, because the file to > edit it /lib/ghc-6.10.1/package.conf. Search for (package) "rts" > and the fields "libraryDirs" and "includeDirs". But if you mess up this > file, all may be lost (so back it up first). I created a backup, then made the edits you suggested and the build failure I was seeing went away. Thanks! >> >> Was it an option I missed when I was doing the configure for the install? > > I'm not sure what configure options to pass (before my building or your > installing) Hopefully someone like Ian can comment here. Thanks, Jason From dagit at codersbase.com Fri Nov 21 11:04:18 2008 From: dagit at codersbase.com (Jason Dagit) Date: Fri Nov 21 10:58:19 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC Message-ID: Hello, Here is an example where ghc 6.8.x was fine, but now 6.10 complains. \begin{code} type CommuteFunction = forall x y. (Prim :< Prim) C(x y) -> Perhaps ((Prim :< Prim) C(x y)) commute_split :: CommuteFunction commute_split (Split patches :< patch) = toPerhaps $ do (p1 :< ps) <- cs (patches :< patch) case sort_coalesceFL ps of p :>: NilFL -> return (p1 :< p) ps' -> return (p1 :< Split ps') where cs :: ((FL Prim) :< Prim) C(x y) -> Maybe ((Prim :< (FL Prim)) C(x y)) cs (NilFL :< p1) = return (p1 :< NilFL) cs (p:>:ps :< p1) = do p1' :< p' <- commutex (p :< p1) p1'' :< ps' <- cs (ps :< p1') return (p1'' :< p':>:ps') commute_split _ = Unknown \end{code} Now with ghc 6.10 we get this error: GADT pattern match with non-rigid result type `Maybe a' Solution: add a type signature In a case alternative: p :>: NilFL -> return (p1 :< p) In the expression: case sort_coalesceFL ps of { p :>: NilFL -> return (p1 :< p) ps' -> return (p1 :< Split ps') } In the second argument of `($)', namely `do (p1 :< ps) <- cs (patches :< patch) case sort_coalesceFL ps of { p :>: NilFL -> return (p1 :< p) ps' -> return (p1 :< Split ps') }' You can see more context here: http://darcs.net/src/Darcs/Patch/Prim.lhs around line 472 My understanding was that from 6.6 to 6.8, GADT type checking was refined to fill some gaps in the soundness. Did that happen again between 6.8 and 6.10 or is 6.10 being needlessly strict here? Thanks, Jason From naur at post11.tele.dk Fri Nov 21 11:03:51 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Fri Nov 21 11:02:01 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: References: <20081104181106.GA20684@matrix.chaos.earth.li> Message-ID: <200811211703.51986.naur@post11.tele.dk> Hello Greg, On Friday 21 November 2008 15:56, Gregory Wright wrote: > ... > ppc/ > Leopard still > fails, but I now have an account on a machine that I can use to test > and debug. And if you need such an access (now or in the future), please just say the word and you can get access to my PPC Mac OS X 10.5 Leopard machine. > ... Best regards Thorkil From dgorin at dc.uba.ar Fri Nov 21 11:25:22 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Fri Nov 21 11:19:29 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: References: Message-ID: On Nov 21, 2008, at 2:04 PM, Jason Dagit wrote: > Hello, > > [...] > > My understanding was that from 6.6 to 6.8, GADT type checking was > refined to fill some gaps in the soundness. Did that happen again > between 6.8 and 6.10 or is 6.10 being needlessly strict here? > > Thanks, > Jason typing rules for gadts changed in 6.10. try: http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081121/a1d5855b/attachment.htm From colin at colina.demon.co.uk Fri Nov 21 11:37:52 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Nov 21 11:32:01 2008 Subject: Crash in garbage collector In-Reply-To: <49216AEB.7080703@gmail.com> (Simon Marlow's message of "Mon\, 17 Nov 2008 13\:00\:27 +0000") References: <20081116181430.GA10839@matrix.chaos.earth.li> <20081116191947.GA5556@matrix.chaos.earth.li> <49216AEB.7080703@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> Colin Paul Adams wrote: >>>>>>> "Ian" == Ian Lynagh writes: >> Ian> If you were lucky it would abort with an assertion Ian> failure. Anyway, gdb should now have debugging symbols to Ian> work with. >> >> It already did (I passed the -g option to gcc). >> >> I guess I will need to install the GHC source to get file >> listings. That sounds like hard work. I think I'll wait for >> 6.10.1 . Simon> If you're calling a Haskell library from C, the problem Simon> might be that you forgot hs_add_root(), or that your Simon> hs_add_root() isn't pointing to the right module (it should Simon> point to the module that transitively imports all the other Simon> modules in your library). You can use multiple Simon> hs_add_root() calls if necessary. I'm sure I have that right. There is only one module. Unless somehow the __GLASGOW_HASKELL__ symbol isn't getting defined for the C compile. I'll try removing the #ifdef to see if that makes a difference. -- Colin Adams Preston Lancashire From rfhayes at reillyhayes.com Fri Nov 21 11:45:14 2008 From: rfhayes at reillyhayes.com (R Hayes) Date: Fri Nov 21 11:39:14 2008 Subject: Ghci for Mac OSX? In-Reply-To: <1afdeaec0811201108n29d371c4ud7e76c4f8e4fb7e4@mail.gmail.com> References: <1afdeaec0811201108n29d371c4ud7e76c4f8e4fb7e4@mail.gmail.com> Message-ID: <65B23C7C-24D1-4A73-A54E-EC75F23DD4AD@reillyhayes.com> I had this problem. The installer didn't make the sym links from / usr/bin/ghc* to /Library/Frameworks/GHC.framework/Versions/Current/usr/ bin/ ghc* The issue was I had installed the beta package and not removed it. The fix was to uninstall 6.10.1 using /Library/Frameworks/ GHC.framework/Tools/Uninstaller and then reinstall the package. -r On Nov 20, 2008, at 11:08 AM, Colin Adams wrote: > I installed the 6.10.1 .pkg on my MacBook Air, and ghci works fine, > but if I type ghci, I get program not found. Is it supposed to be > available for Mac? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From jtod at dcs.gla.ac.uk Fri Nov 21 11:52:28 2008 From: jtod at dcs.gla.ac.uk (John O'Donnell) Date: Fri Nov 21 11:46:26 2008 Subject: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) References: <6d74b0d20811210129q6b98a713l40eaf09881654eaf@mail.gmail.com><49268D21.2040600@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B32@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Simon says... > Could we reduce GHC's surface area by just using haskeline and dumping > readline/editline support altogether? I'm in favor of doing this. For portability and consistency, it's better to have just one version that is unencumbered by these license issues, as long as it works on the main platforms (including Macintosh - has that been tested?). If ghc tries to support both readline and editline, along with haskeline, applications written in Haskell will have different behaviours depending on the combination (platform,line-editor). Better just to simplify. John O'Donnell -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org on behalf of Simon Peyton-Jones Sent: Fri 2008-11-21 10:39 To: Simon Marlow; Judah Jacobson Cc: glasgow-haskell-users@haskell.org Subject: RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) | > I've actually been experimenting with something similar: | > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ .... | > | > Current benefits over the readline/editline versions: | > - Works on Windows | | I can attest to that. Nice going Judah! | | $ cabal update | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ | $ cd ghci-haskeline | $ cabal install | | and I have a GHCi on Windows that can do completion, history search, and | exits when I hit ^D. That's made my day. If I had ?1 for every email I've seen in the last decade about platform-related or license-related problems with readline and now editline, I'd be rich man. Super rich. Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether? Yes that might reduce functionality slightly -- readline/editline are complicated for good reasons. But it's increase functionality in other ways (as Judah says), and by giving us one piece of software that we understand, and can distribute with GHC, it might remove a whole class of problems. Simon _______________________________________________ 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/20081121/be63fccc/attachment.htm From simonpj at microsoft.com Fri Nov 21 11:57:16 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 21 11:51:18 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> You need a type signature for the case expression. As Daniel says, this is worth a read http://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jason Dagit | Sent: 21 November 2008 16:04 | To: glasgow-haskell-users@haskell.org | Subject: GADT Type Checking GHC 6.10 versus older GHC | | Hello, | | Here is an example where ghc 6.8.x was fine, but now 6.10 complains. | | \begin{code} | type CommuteFunction = forall x y. (Prim :< Prim) C(x y) -> Perhaps | ((Prim :< Prim) C(x y)) | | commute_split :: CommuteFunction | commute_split (Split patches :< patch) = | toPerhaps $ do (p1 :< ps) <- cs (patches :< patch) | case sort_coalesceFL ps of | p :>: NilFL -> return (p1 :< p) | ps' -> return (p1 :< Split ps') | where cs :: ((FL Prim) :< Prim) C(x y) -> Maybe ((Prim :< (FL Prim)) C(x y)) | cs (NilFL :< p1) = return (p1 :< NilFL) | cs (p:>:ps :< p1) = do p1' :< p' <- commutex (p :< p1) | p1'' :< ps' <- cs (ps :< p1') | return (p1'' :< p':>:ps') | commute_split _ = Unknown | \end{code} | | Now with ghc 6.10 we get this error: | GADT pattern match with non-rigid result type `Maybe a' | Solution: add a type signature | In a case alternative: p :>: NilFL -> return (p1 :< p) | In the expression: | case sort_coalesceFL ps of { | p :>: NilFL -> return (p1 :< p) | ps' -> return (p1 :< Split ps') } | In the second argument of `($)', namely | `do (p1 :< ps) <- cs (patches :< patch) | case sort_coalesceFL ps of { | p :>: NilFL -> return (p1 :< p) | ps' -> return (p1 :< Split ps') }' | | You can see more context here: | http://darcs.net/src/Darcs/Patch/Prim.lhs around line 472 | | My understanding was that from 6.6 to 6.8, GADT type checking was | refined to fill some gaps in the soundness. Did that happen again | between 6.8 and 6.10 or is 6.10 being needlessly strict here? | | Thanks, | Jason | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From colin at colina.demon.co.uk Fri Nov 21 12:00:14 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Nov 21 11:54:13 2008 Subject: Crash in garbage collector In-Reply-To: (Colin Paul Adams's message of "Fri\, 21 Nov 2008 16\:37\:52 +0000") References: <20081116181430.GA10839@matrix.chaos.earth.li> <20081116191947.GA5556@matrix.chaos.earth.li> <49216AEB.7080703@gmail.com> Message-ID: >>>>> "Colin" == Colin Paul Adams writes: Simon> If you're calling a Haskell library from C, the problem Simon> might be that you forgot hs_add_root(), or that your Simon> hs_add_root() isn't pointing to the right module (it should Simon> point to the module that transitively imports all the other Simon> modules in your library). You can use multiple Simon> hs_add_root() calls if necessary. Colin> I'm sure I have that right. There is only one Colin> module. Unless somehow the __GLASGOW_HASKELL__ symbol isn't Colin> getting defined for the C compile. I'll try removing the Colin> #ifdef to see if that makes a difference. It wasn't that. And yum has just updated my version of ghc from 6.8.2 to 6.8.3 - no 6.10.1 available yet. I'll just wait for that first, in case the new GC makes a change. -- Colin Adams Preston Lancashire From gwright at comcast.net Fri Nov 21 11:29:37 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri Nov 21 12:14:32 2008 Subject: ANNOUNCE: GHC version 6.10.1 - MacOS installer In-Reply-To: <200811211703.51986.naur@post11.tele.dk> References: <20081104181106.GA20684@matrix.chaos.earth.li> <200811211703.51986.naur@post11.tele.dk> Message-ID: <2A36D86E-D7FE-41FB-AAF6-3D77B2D9919B@comcast.net> Hi Thorkil, On Nov 21, 2008, at 11:03 AM, Thorkil Naur wrote: > Hello Greg, > > On Friday 21 November 2008 15:56, Gregory Wright wrote: >> ... >> ppc/ >> Leopard still >> fails, but I now have an account on a machine that I can use to test >> and debug. > > And if you need such an access (now or in the future), please just > say the > word and you can get access to my PPC Mac OS X 10.5 Leopard machine. > >> ... > > Best regards > Thorkil Thank you for your kind offer. I will likely take you up on it in the future. Best Wishes, Greg From c.chryssochoidis at gmail.com Fri Nov 21 14:33:18 2008 From: c.chryssochoidis at gmail.com (Christos Chryssochoidis) Date: Fri Nov 21 14:27:17 2008 Subject: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) In-Reply-To: References: <6d74b0d20811210129q6b98a713l40eaf09881654eaf@mail.gmail.com> <49268D21.2040600@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B32@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Hello, 2008/11/21 John O'Donnell : > Simon says... > >> Could we reduce GHC's surface area by just using haskeline and dumping >> readline/editline support altogether? > > I'm in favor of doing this. For portability and consistency, it's better > to have just one version that is unencumbered by these license issues, > as long as it works on the main platforms (including Macintosh - has that > been tested?). It works very well on my Mac. Both tab completion of quoted filenames in Haskell expressions and of unicode identifiers works well. (It doesn't complete non-latin file names, but I can live with that.) I've also noticed that with haskeline one can type in ghci non-latin characters, as was the case before, with readline, but not anymore with editline. Hope it helps C.Chryssochoidis > If ghc tries to support both readline and editline, along > with haskeline, applications written in Haskell will have different > behaviours > depending on the combination (platform,line-editor). Better just to > simplify. > > John O'Donnell > > -----Original Message----- > From: glasgow-haskell-users-bounces@haskell.org on behalf of Simon > Peyton-Jones > Sent: Fri 2008-11-21 10:39 > To: Simon Marlow; Judah Jacobson > Cc: glasgow-haskell-users@haskell.org > Subject: RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - > EditLine / terminal incompatibility?) > > | > I've actually been experimenting with something similar: > | > > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ > .... > | > > | > Current benefits over the readline/editline versions: > | > - Works on Windows > | > | I can attest to that. Nice going Judah! > | > | $ cabal update > | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ > | $ cd ghci-haskeline > | $ cabal install > | > | and I have a GHCi on Windows that can do completion, history search, and > | exits when I hit ^D. That's made my day. > > If I had ?1 for every email I've seen in the last decade about > platform-related or license-related problems with readline and now editline, > I'd be rich man. Super rich. > > Could we reduce GHC's surface area by just using haskeline and dumping > readline/editline support altogether? Yes that might reduce functionality > slightly -- readline/editline are complicated for good reasons. But it's > increase functionality in other ways (as Judah says), and by giving us one > piece of software that we understand, and can distribute with GHC, it might > remove a whole class of problems. > > Simon > _______________________________________________ > 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 judah.jacobson at gmail.com Fri Nov 21 18:44:06 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 21 18:38:05 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1227267550.7124.162.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <4926843B.2010903@jellybean.co.uk> <200811211159.35551.p.k.f.holzenspies@utwente.nl> <1227267550.7124.162.camel@localhost> Message-ID: <6d74b0d20811211544t21c35ab9jaadea74e65028df@mail.gmail.com> On 11/21/08, Duncan Coutts wrote: > On Fri, 2008-11-21 at 11:59 +0100, Philip K.F. H?lzenspies wrote: > > On Friday 21 November 2008 10:49:47 Jules Bean wrote: > > > > Something must be very very broken : surely it is not expected behaviour > > > for editline to need configuration in this way? > > > > One can call it broken, another will say users should settle for the default > > behaviour. Neither readline, nor editline *need* configuration this way, > > because they do come with sensible defaults. > > But that's just it. It seems that readline does come with sensible > defaults and editline does not. For example xterm is not a rare kind of > terminal (basically every terminal in use claims to be xterm) and yet > delete does not work with it out-of-the-box with editline. That is > broken. > > [To add insult to injury, even when I look up the escape sequence for > delete using the cat/telnet trick, I still cannot configure editline to > recognise it.] After further investigation, I think this technically isn't a terminal compatibility issue, but rather a missing feature; i.e., editline just doesn't intentionally support using the delete key. The command ed-delete-next-char which we found in the editrc manpage is really meant to represent pressing 'x' in the vi bindings, which is why it hasn't been working as expected. AFAICT, editline has no command equivalent to pressing 'delete'. Of course, regardless of the cause, the net result (delete key not working) is the same. I just wanted to point out that editline does use the same terminal capability libraries (termcap/terminfo) as readline, so there's no fundamental reason this couldn't be implemented portably other than (I'm guessing) the lack of motivation or time from its authors/contributors. -Judah From judah.jacobson at gmail.com Fri Nov 21 18:49:24 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 21 18:43:22 2008 Subject: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) In-Reply-To: <49268D21.2040600@gmail.com> References: <6d74b0d20811210129q6b98a713l40eaf09881654eaf@mail.gmail.com> <49268D21.2040600@gmail.com> Message-ID: <6d74b0d20811211549s14cc6a0awa06423693c7f1b01@mail.gmail.com> On Fri, Nov 21, 2008 at 2:27 AM, Simon Marlow wrote: > Judah Jacobson wrote: >> >> On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh wrote: >>> >>> Although another option would be to make GHCi a separate (GPL) frontend >>> to the (BSD) GHC API. The only downside is that (with static linking) we >>> have another large binary. Another upside is that other GHC API users >>> don't get an editline dependency. >> >> I've actually been experimenting with something similar: >> >> darcs get http://code.haskell.org/~judah/ghci-haskeline/ >> >> If you have ghc-6.10.1, 'cabal install'ing inside that repo will give >> you a version of ghci which uses Haskeline as its backend. >> >> Basically, I copied 4 modules from the GHC source tree (GhciMonad, >> InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; >> the rest of GHC is obtained through the API. > > BTW, your LICENSE file looks like it was copied from the GHC source tree, it > still has various references to GHC and the University of Glasgow. The vast majority of code in that project is copied directly from the GHC source tree, and any changes I've made are intended to be merged back into GHC (or a ghci subproject); so I thought it easiest just to keep the code under the same license and copyright. Is there a better way to do this? -Judah From judah.jacobson at gmail.com Fri Nov 21 19:57:27 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Nov 21 19:51:24 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <4926BF27.9070506@gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <4926BF27.9070506@gmail.com> Message-ID: <6d74b0d20811211657x34c4e51dq9dfa631c9c32d105@mail.gmail.com> On 11/21/08, Simon Marlow wrote: > > I propose we do this: > > * extract the GHCi UI from the GHC package, put it in the ghc-bin package > (maybe we should rename this package to ghc-main or something). This > removes the editline and bytestring (for now) dependencies from the GHC > package. > > * Move to Haskeline for the default build. We have to bring in terminfo > and utf8-string as bootlibs. > > This gives us line-editing on Windows, and removes problematic external C > library dependencies. Just so it's clear, Haskeline on POSIX does require (n)curses, an external C library, in order to access terminfo capabilities portably. But in my experience curses is much more widely available by default than readline or editline, so I still think this is a significant improvement. > * Make it possible to compile the ghc-bin package against readline. > Upload ghc-bin to Hackage, so people can say > cabal install ghc-bin -f readline > and get a GHCi built against readline if they want. Oops - except that > this would mean that the ghc-main package has a variant license. So > maybe we have to have a separate ghc-readline package? That sounds reasonable. As a side note, I'm very interested to learn of any more issues with Haskeline that would make it less preferable than the readline backend. -Judah From conal at conal.net Fri Nov 21 21:28:20 2008 From: conal at conal.net (Conal Elliott) Date: Fri Nov 21 21:22:18 2008 Subject: Exporting an #include from one package to another? Message-ID: Is there a way to package up an #include like to share across (be #include'd into) various other haskell packages? I have some standard templates for type class instances that I can't define as instances without creating lots of overlapping instances. I can write an include file easily enough, but I don't know how to get other packages to find and #include that include file. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081121/eb84d43d/attachment.htm From dagit at codersbase.com Fri Nov 21 22:10:00 2008 From: dagit at codersbase.com (Jason Dagit) Date: Fri Nov 21 22:03:58 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Fri, Nov 21, 2008 at 8:57 AM, Simon Peyton-Jones wrote: > You need a type signature for the case expression. As Daniel says, this is > worth a read > > http://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching Thanks Simon. I had read that several times in the past and I've pointed it out to others. It's still relevant but, my question was about whether or not examples like the one posted are really in error or if GHC is just being overly strict now. In my case, we had rigid type signatures all over the place. The wiki document says that the type must be rigid at the point of the match. I guess that's what we were violating. If the code I posted isn't supposed to type check then I would like to report, as user feedback, that GADTs have become unwieldy. I couldn't figure out how to fix that code by just adding a type signature. The only way I could manage to fix it was to remove the case-expressions and replace them with local functions and give the type signature of those functions. From a practical point of view, it seems that GADTs cannot be used with case-expressions. So that means that I am now unable to use pattern matches on GADTs with case, let, and where. I urge you to consider designing a modified or new syntactic form for working with GADT pattern matches. The quasi-dependent typing that GADTs give developers is very powerful and it would seem that GHC Haskell with GADTs is as close to dependent typing that developers writing "real-world" software can get. I know of no other production ready compilers that provide dependent or close to dependent typing. Dependent typing seems to be a growing area of interest. For these reasons I think it's important for GHC to focus on making them pleasanter to work with again; even if it means adding to the language again. I also feel that the type errors given when working with existential types, especially GADTs with existentials, are confusing. I think mostly because the types of the sub-expressions in the program are not visible to the user. More introspection into the inferred types would help users. I have some ideas on how to improve this, what the output should look like and I would like to implement it too, but I haven't had a chance to start a prototype yet. Thank you for your time! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081121/57eedcce/attachment-0001.htm From colin at colina.demon.co.uk Sat Nov 22 00:42:20 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Nov 22 00:36:23 2008 Subject: Unicode's greek lambda In-Reply-To: (Jan Jakubuv's message of "Thu\, 20 Nov 2008 09\:50\:21 +0000") References: <20081118.180025.234710170.kazu@iij.ad.jp> <20081118103001.6accc332.Malcolm.Wallace@cs.york.ac.uk> <20081118115115.GA5102@soi.city.ac.uk> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> Message-ID: Jan> Some others are (I have no idea why they are referenced as Jan> "lamda" instead of "lambda"): See http://unicode.org/notes/tn27/ : "U+039B GREEK CAPITAL LETTER LAMDA U+03BB GREEK SMALL LETTER LAMDA * The use of the spelling lamda derives from ISO 10646. This does not mean that it is more correct than lambda, merely that the spelling without the 'b' is the one used in the formal character names." -- Colin Adams Preston Lancashire From allbery at ece.cmu.edu Sat Nov 22 02:30:46 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Nov 22 02:24:47 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <4926BF27.9070506@gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <4926BF27.9070506@gmail.com> Message-ID: <9F9814E9-E4F3-4188-BCCC-6B01CD2B904D@ece.cmu.edu> On 2008 Nov 21, at 9:01, Simon Marlow wrote: > * extract the GHCi UI from the GHC package, put it in the ghc-bin > package > (maybe we should rename this package to ghc-main or something). > This > removes the editline and bytestring (for now) dependencies from > the GHC > package. > > * Move to Haskeline for the default build. We have to bring in > terminfo > and utf8-string as bootlibs. This gives us line-editing on Windows, > and removes problematic external C library dependencies. > > * Make it possible to compile the ghc-bin package against readline. > Upload ghc-bin to Hackage, so people can say > cabal install ghc-bin -f readline > and get a GHCi built against readline if they want. Oops - except > that > this would mean that the ghc-main package has a variant license. So > maybe we have to have a separate ghc-readline package? My humble opinion: Dissociate ghc-bin and ghci from ghc; the latter is actually ghci- {haskeline,readline,editline,noediting,...}. (Does cabal have virtual packages yet?) There is a corresponding library issue, though: System.Console.Readline. I'd handle this by having packages which export their own namespaces... but we'd like to have a generic interface too so someone can write a program using any available editing package. So, have the packages also output a module which is by default hidden, and allow the user to select which one is used by unhiding it. (This might lead to wanting additional cabal functionality: "preferred" packages. Or maybe flags already handle that well enough.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dominic.steinitz at blueyonder.co.uk Sat Nov 22 03:58:02 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Nov 22 04:04:02 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC References: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Jason Dagit codersbase.com> writes: > > > On Fri, Nov 21, 2008 at 8:57 AM, Simon Peyton-Jones microsoft.com> wrote: > You need a type signature for the case expression. As Daniel says, this is worth a readhttp://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching > > > Thanks Simon. I had read that several times in the past and I've pointed it out to others. It's still relevant but, my question was about whether or not examples like the one posted are really in error or if GHC is just being overly strict now. > > In my case, we had rigid type signatures all over the place. The wiki document says that the type must be rigid at the point of the match. I guess that's what we were violating. If the code I posted isn't supposed to type check then I would like to report, as user feedback, that GADTs have become unwieldy. This is really worrying. I have spent some considerable time using GADTs to structure a library. I haven't tried 6.10 yet because it's not available in a packaged form for my flavour of linux. I will put some work into doing this today and report back. Dominic. From duncan.coutts at worc.ox.ac.uk Sat Nov 22 08:31:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 22 08:25:06 2008 Subject: Exporting an #include from one package to another? In-Reply-To: References: Message-ID: <1227360665.7124.195.camel@localhost> On Fri, 2008-11-21 at 18:28 -0800, Conal Elliott wrote: > Is there a way to package up an #include like to share across (be > #include'd into) various other haskell packages? > > I have some standard templates for type class instances that I can't > define as instances without creating lots of overlapping instances. I > can write an include file easily enough, but I don't know how to get > other packages to find and #include that include file. Yes. This is partly what the "install-includes:" field in the .cabal file is for. Each client has to #include it explicitly of course, but the include search path should be set up to make that work. Duncan From dominic.steinitz at blueyonder.co.uk Sat Nov 22 08:33:49 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Nov 22 08:27:59 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC References: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Dominic Steinitz blueyonder.co.uk> writes: > > packaged form for my flavour of linux. I will put some work into doing this > today and report back. > > Dominic. > Phew - I installed the windows 6.10.1 package and everything to do with GADTs still seems to work. Dominic. From duncan.coutts at worc.ox.ac.uk Sat Nov 22 08:49:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 22 08:43:43 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <4926BF27.9070506@gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <4926BF27.9070506@gmail.com> Message-ID: <1227361783.7124.209.camel@localhost> On Fri, 2008-11-21 at 14:01 +0000, Simon Marlow wrote: > I propose we do this: > > * extract the GHCi UI from the GHC package, put it in the ghc-bin package > (maybe we should rename this package to ghc-main or something). This > removes the editline and bytestring (for now) dependencies from the GHC > package. This is good independently of the other suggestions. > * Move to Haskeline for the default build. We have to bring in terminfo > and utf8-string as bootlibs. This gives us line-editing on Windows, > and removes problematic external C library dependencies. I think this is worth trying. It seems like Judah is prepared to put the work in to make haskeline work on various platforms and to trim the dependencies. Eg I'd rather us decide what to do about Unicode input rather than just end up de-facto standardising the utf8-string package. It seemed like we had a consensus on what to do for the H98 IO with Unicode. We just need to get on with it. In addition we need to agree some control over encoding when using a specific encoding is called for (eg reading a file that is known to be UTF-16 independent of the locale). > * Make it possible to compile the ghc-bin package against readline. > Upload ghc-bin to Hackage, so people can say > cabal install ghc-bin -f readline > and get a GHCi built against readline if they want. If haskeline "works" then I doubt there will be much pressure for readline support. The pining for the "good old days of readline" at the moment are only because editline clearly doesn't "work". [For some definition of "work"] > Oops - except that > this would mean that the ghc-main package has a variant license. So > maybe we have to have a separate ghc-readline package? A variant license isn't a fundamental technical problem though perhaps the consensus is that variant licenses are a "bad thing". I'm not sure. One would have to use OtherLicense and specify what the conditions are in the license file. Duncan From colin at colina.demon.co.uk Sat Nov 22 12:12:32 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Nov 22 12:06:34 2008 Subject: Unicode's greek lambda In-Reply-To: <28012bc60811210721h5cfe9e84g1b79c9c95906a626@mail.gmail.com> (Arnar Birgisson's message of "Fri\, 21 Nov 2008 16\:21\:12 +0100") References: <20081118.180025.234710170.kazu@iij.ad.jp> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> <1227180208.7124.41.camel@localhost> <28012bc60811200846y5e19fddcp9ef8a74aa4f42a8@mail.gmail.com> <1afdeaec0811200956u3b3e882aw6100adee4f90198@mail.gmail.com> <28012bc60811210721h5cfe9e84g1b79c9c95906a626@mail.gmail.com> Message-ID: >>>>> "Arnar" == Arnar Birgisson writes: Arnar> To clarify - most of modern fonts do in deed have Arnar> latin-greek-cyrillic (including the U+03BB lambda), but I Arnar> was referring to the specific math symbols such as the Arnar> U+1D6CC bold lam(b)da, which reside in the Supplementary Arnar> Multilingual Plane (SMP). Those are indeed not present in Arnar> my fonts, including Lucida Math and Adobe Mathematical Pi). I tackled David Carlisle about this too: David> On windows there's cambria math (unfortunately with a restrictive licence that restricts it to that platform, though you can get it for free by getting (for example) the free powerpoint viewer from microsoft) for a free font with a full range of characters best bet is stix font which has been 10 years in the making and is currently between beta and full release (but late again) the stix site removed the fonts after the beata test but you can get them from mozilla, and you need them if reading mathml in FF3. http://www.stixfonts.org/ http://www.mozilla.org/projects/mathml/fonts/ Colin > echo $(uc 1D6cc) - doesn't print anything recognizable David> That would require not only fonts with glyphs in that slot but also that the software (xterm here) understands plane 1 not just the 16bit unicode 2 support. I don't know whether xterm does or not. I downloaded the fonts, but xterm still doesn't display the character concerned. Nor does Firefox, although I haven't tried it with MathML yet. -- Colin Adams Preston Lancashire From dons at galois.com Sat Nov 22 13:55:11 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 22 13:49:09 2008 Subject: cross module optimization issues In-Reply-To: <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> Message-ID: <20081122185511.GE17052@scytale.galois.com> jwlato: > On Wed, Nov 19, 2008 at 4:17 PM, Simon Peyton-Jones > wrote: > > | I'm compiling with -O2 -Wall. After looking at the Core output, I > > | think I've found the key difference. A function that is bound in a > > | "where" statement is different between the monolithic and split > > | sources. I have no idea why, though. I'll experiment with a few > > | different things to see if I can get this resolved. > > > > In general, splitting code across modules should not make programs less efficient -- as Don says, GHC does quite aggressive cross-module inlining. > > > > There is one exception, though. If a non-exported non-recursive function is called exactly once, then it is inlined *regardless of size*, because doing so does not cause code duplication. But if it's exported and is large, then its inlining is not exposed -- and even if it were it might not be inlined, because doing so duplicates its code an unknown number of times. You can change the threshold for (a) exposing and (b) using an inlining, with flags -funfolding-creation-threshold and -funfolding-use-threshold respectively. > > > > If you find there's something else going on then I'm all ears. > > > > Simon > > > > I did finally find the changes that make a difference. I think it's > safe to say that I have no idea what's actually going on, so I'll just > report my results and let others try to figure it out. > > I tried upping the thresholds mentioned, up to > -funfolding-creation-threshold 200 -funfolding-use-threshold 100. > This didn't seem to make any performance difference (I didn't check > the core output). > > This project is based on Oleg's Iteratee code; I started using his > IterateeM.hs and Enumerator.hs files and added my own stuff to > Enumerator.hs (thanks Oleg, great work as always). When I started > cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my > minimal test case increased from 19s to 43s. > > I've found two factors that contributed. When I was cleaning up, I > also removed a bunch of unused functions from IterateeM.hs (some of > the test functions and functions specific to his running example of > HTTP encoding). When I added those functions back in, and added > INLINE pragmas to the exported functions in MyEnum.hs, I got the > performance back. > > In general I hadn't added export lists to the modules yet, so all > functions should have been exported. > > So it seems that somehow the unused functions in IterateeM.hs are > affecting how the functions I care about get implemented (or > exported). I did not expect that. Next step for me is to see what > happens if I INLINE the functions I'm exporting and remove the others, > I suppose. > > Thank you Simon and Don for your advice, especially since I'm pretty > far over my head at this point. > Is this , since it is in IO code, a -fno-state-hack scenario? Simon wrote recently about when and why -fno-state-hack would be needed, if you want to follow that up. -- Don From allbery at ece.cmu.edu Sat Nov 22 18:34:23 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Nov 22 18:28:26 2008 Subject: Unicode's greek lambda In-Reply-To: References: <20081118.180025.234710170.kazu@iij.ad.jp> <1227041936.21705.20.camel@dell.linuxdev.us.dell.com> <492412ED.4070206@gmail.com> <1227133461.21705.85.camel@dell.linuxdev.us.dell.com> <49a77b7a0811191432y2a580856n3c95e72ec68b3844@mail.gmail.com> <1227180208.7124.41.camel@localhost> <28012bc60811200846y5e19fddcp9ef8a74aa4f42a8@mail.gmail.com> <1afdeaec0811200956u3b3e882aw6100adee4f90198@mail.gmail.com> <28012bc60811210721h5cfe9e84g1b79c9c95906a626@mail.gmail.com> Message-ID: On 2008 Nov 22, at 12:12, Colin Paul Adams wrote: >>>>>> "Arnar" == Arnar Birgisson writes: > > Arnar> To clarify - most of modern fonts do in deed have > Arnar> latin-greek-cyrillic (including the U+03BB lambda), but I > Arnar> was referring to the specific math symbols such as the > Arnar> U+1D6CC bold lam(b)da, which reside in the Supplementary > Arnar> Multilingual Plane (SMP). Those are indeed not present in > Arnar> my fonts, including Lucida Math and Adobe Mathematical Pi). > > David> On windows there's cambria math (unfortunately with a > restrictive > licence that restricts it to that platform, though you can get it for > free by getting (for example) the free powerpoint viewer from > microsoft) > > for a free font with a full range of characters best bet is stix font > which has been 10 years in the making and is currently between beta > and http://dejavu.sourceforge.net/ works for me. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From colin at colina.demon.co.uk Sun Nov 23 06:14:59 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 23 06:08:52 2008 Subject: Linking to Haskell code from an external program In-Reply-To: <49216358.9060806@gmail.com> (Simon Marlow's message of "Mon\, 17 Nov 2008 12\:28\:08 +0000") References: <49216358.9060806@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Colin> I then attempted to move it into Eiffel. I can compile the Colin> C code OK, but I'm running into problems with linking. >> Colin> I solved most of the problems by adding the -v flag to the Colin> call to ghc which I used to link the original (haskell + c Colin> only) program, and cut-and-paste the linker options from Colin> their into the Eiffel configuration file. This isn't really Colin> satisfactory - I would like some automatic way to determine Colin> what the flags should be. Simon> The only other way I can think of is to construct the Simon> arguments yourself by querying the package database, Simon> e.g. "ghc-pkg field ld-options rts", but you'll have to Simon> combine the information from several different fields of Simon> the packages you use, and basically reproduce what GHC does Simon> to construct the ld command line. Can you point me at where it does this? Thanks. -- Colin Adams Preston Lancashire From shoot.spam at gmail.com Sun Nov 23 09:07:19 2008 From: shoot.spam at gmail.com (Vishal Belsare) Date: Sun Nov 23 09:01:14 2008 Subject: sum[1..100000] --> stack overflow in GHC, but not in Hugs? Message-ID: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> Hi, Please bear with a very basic question. I am trying to 'learn me a Haskell for great good' using Hutton's book and some online tutorials. I started off with Hugs and recently used GHC (to use the 'let a = .." syntax interactively, which Hugs doesn't allow perhaps). There's a simple issue I am having with GHC. sum[1..100000] works fine on Hugs, however, the same in GHCi generates a stack overflow exception. I am trying to figure out what's going on. Prelude> sum[1..100000] 5000050000 Prelude> sum[1..1000000] *** Exception: stack overflow Prelude> ________________________ Hugs> sum[1..10000] 50005000 Hugs> sum[1..100000] 5000050000 Hugs> Thanks in anticipation. Best regards, Vishal Belsare ps: please excuse if the question is too uncool for the list. I come from an economics background; the markets are bad, I am depressed and to add to my pain, GHC refuses to let me know sum[1..100000] -- Firstly, I propose for myself the rule that the obviousness of a proposition does not free me from the obligation to continue searching for a proof of it, at least until I clearly realize that absolutely no proof could ever be required, and why. ~ Bernhard Bolzano From dagit at codersbase.com Sun Nov 23 09:16:53 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sun Nov 23 09:10:46 2008 Subject: sum[1..100000] --> stack overflow in GHC, but not in Hugs? In-Reply-To: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> References: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> Message-ID: On Sun, Nov 23, 2008 at 6:07 AM, Vishal Belsare wrote: > Hi, > > Please bear with a very basic question. I am trying to 'learn me a > Haskell for great good' using Hutton's book and some online tutorials. > I started off with Hugs and recently used GHC (to use the 'let a = > ." syntax interactively, which Hugs doesn't allow perhaps). You might also learn you a haskell for great good with: http://learnyouahaskell.com > > > There's a simple issue I am having with GHC. sum[1..100000] works fine > on Hugs, however, the same in GHCi generates a stack overflow > exception. I am trying to figure out what's going on. You might try telling ghci to use optimizations. I but that will fix this problem. I can't reproduce your stack overflow locally (I even tried with bigger numbers). But, this might help: ghci -O then try your code. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081123/f85b8363/attachment.htm From jwlato at gmail.com Sun Nov 23 09:46:50 2008 From: jwlato at gmail.com (John Lato) Date: Sun Nov 23 09:40:43 2008 Subject: cross module optimization issues In-Reply-To: <20081122185511.GE17052@scytale.galois.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <20081122185511.GE17052@scytale.galois.com> Message-ID: <9979e72e0811230646t63c45197s3f385dfdf8c0b9bc@mail.gmail.com> On Sat, Nov 22, 2008 at 6:55 PM, Don Stewart wrote: > jwlato: > > Is this , since it is in IO code, a -fno-state-hack scenario? > Simon wrote recently about when and why -fno-state-hack would be > needed, if you want to follow that up. > > -- Don > Unfortunately, -fno-state-hack doesn't seem to make much difference. In any case, only the functions that actually do file IO are in the IO monad; otherwise the functions use a generic Monad constraint. Although you have reminded me that I should make a non-IO test case. For Neil, and anyone else interested in looking at this, I'll put the code and build instructions up later today. I've just been cleaning up some test cases to make it easier to run. John From colin at colina.demon.co.uk Sun Nov 23 10:20:20 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 23 10:14:14 2008 Subject: Linking to Haskell code from an external program In-Reply-To: (Colin Paul Adams's message of "Sun\, 23 Nov 2008 11\:14\:59 +0000") References: <49216358.9060806@gmail.com> Message-ID: >>>>> "Colin" == Colin Paul Adams writes: >>>>> "Simon" == Simon Marlow writes: Colin> I then attempted to move it into Eiffel. I can compile the Colin> C code OK, but I'm running into problems with linking. >>> Colin> I solved most of the problems by adding the -v flag to the Colin> call to ghc which I used to link the original (haskell + c Colin> only) program, and cut-and-paste the linker options from Colin> their into the Eiffel configuration file. This isn't really Colin> satisfactory - I would like some automatic way to determine Colin> what the flags should be. Simon> The only other way I can think of is to construct the Simon> arguments yourself by querying the package database, Simon> e.g. "ghc-pkg field ld-options rts", but you'll have to Simon> combine the information from several different fields of Simon> the packages you use, and basically reproduce what GHC does Simon> to construct the ld command line. I have upgraded to ghc 6.10.1 by compiling from source. Now I can't get it to link, either using my previous method of linking a standalone C program via ghc -v, and copying the -u options, or by running: ghc-pkg field rts ld-options (I found out by trial-and error that the syntax you gave above was inverted). In both cases, I get errors: /home/colin/fib/Fib.o: In function `r131_info': (.text+0x79): undefined reference to `base_GHCziBase_ZC_con_info' /home/colin/fib/Fib.o: In function `r131_info': (.text+0x10f): undefined reference to `base_GHCziBase_ZMZN_closure' /home/colin/fib/Fib.o: In function `s13p_info': (.text+0x157): undefined reference to `base_GHCziBase_ZMZN_closure' /home/colin/fib/Fib.o: In function `s13F_info': (.text+0x2cf): undefined reference to `base_GHCziBase_ZMZN_closure' /home/colin/fib/Fib.o: In function `s13c_info': (.text+0x32): undefined reference to `base_GHCziNum_plusInteger_info' /home/colin/fib/Fib.o: In function `r131_info': (.text+0x124): undefined reference to `base_GHCziList_foldr21_info' /home/colin/fib/Fib.o:(.data+0x0): undefined reference to `base_GHCziNum_Szh_static_info' /home/colin/fib/Fib.o:(.data+0x10): undefined reference to `base_GHCziNum_Szh_static_info' /home/colin/fib/Fib.o: In function `r131_closure': (.data+0x38): undefined reference to `base_GHCziBase_ZC_static_info' /home/colin/fib/Fib.o: In function `r131_closure': (.data+0x58): undefined reference to `base_GHCziBase_ZC_static_info' collect2: ld returned 1 exit status I tried in desperation to add -u flag for each of the undefined symbols above, but it makes no difference. I'm quite lost now. My C code looks like this: static char * program_name = "Eiffel program"; static char * terminator = (char *) 0; int argc; char **argv[2]; argc = 1; argv [0] = &program_name; argv [1] = &terminator; hs_init(&argc, argv); #ifdef __GLASGOW_HASKELL__ #include "Fib_stub.h" extern void __stginit_Fib ( void ); hs_add_root(__stginit_Fib); #endif return (fibonacci_hs($n)); hs_exit(); (and in addition there are includes for and "HsFFI.h" somewhere preceding the above). -- Colin Adams Preston Lancashire From duncan.coutts at worc.ox.ac.uk Sun Nov 23 10:22:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 23 10:16:03 2008 Subject: sum[1..100000] --> stack overflow in GHC, but not in Hugs? In-Reply-To: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> References: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> Message-ID: <1227453726.7124.317.camel@localhost> On Sun, 2008-11-23 at 19:37 +0530, Vishal Belsare wrote: > Hi, > > Please bear with a very basic question. I am trying to 'learn me a > Haskell for great good' using Hutton's book and some online tutorials. > I started off with Hugs and recently used GHC (to use the 'let a = > .." syntax interactively, which Hugs doesn't allow perhaps). > > There's a simple issue I am having with GHC. sum[1..100000] works fine > on Hugs, however, the same in GHCi generates a stack overflow > exception. I am trying to figure out what's going on. Note: Hugs is using the wrong definition of sum, that's why it has different behaviour. The Haskell98 report defines them as: sum, product :: (Num a) => [a] -> a sum = foldl (+) 0 product = foldl (*) 1 While hugs uses: sum, product :: Num a => [a] -> a sum = foldl' (+) 0 product = foldl' (*) 1 Obviously these have different semantics (eg on lazy Num instances) as well as different operational behaviour. Either hugs or the Prelude should be fixed. It is a bit odd that they're defined with foldl, since if they were really meant to be lazy then why were they not defined with foldr? It is being considered for Haskell': http://hackage.haskell.org/trac/haskell-prime/ticket/120 Duncan From colin at colina.demon.co.uk Sun Nov 23 11:22:58 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 23 11:16:52 2008 Subject: Grammar for (Glasgow) Haskell Message-ID: Is this available as a happy file (or something similar)? I tried searching the 6.10.1 source package for *.y, but the three files I found don't seem to be what I'm looking for. What I want to try to do is to generate C wrappers to call GHC-compiled code by parsing foreign export declarations. But I figure just searching the code for a regular expression on the lines of foreign[ ]+export is going to be over-simplistic. But I'd rather not type in all the Haskell grammar myself (I'm lazy - you wouldn't expect any other sort of person on this list, I assume :-) ). -- Colin Adams Preston Lancashire From duncan.coutts at worc.ox.ac.uk Sun Nov 23 11:52:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 23 11:46:23 2008 Subject: Grammar for (Glasgow) Haskell In-Reply-To: References: Message-ID: <1227459146.7124.323.camel@localhost> On Sun, 2008-11-23 at 16:22 +0000, Colin Paul Adams wrote: > Is this available as a happy file (or something similar)? > > I tried searching the 6.10.1 source package for *.y, but the three files > I found don't seem to be what I'm looking for. ls compiler/parser reveals... Lexer.x Parser.y.pp However you might get further using the ghc api package. Duncan From colin at colina.demon.co.uk Sun Nov 23 12:37:19 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 23 12:31:13 2008 Subject: Grammar for (Glasgow) Haskell In-Reply-To: <1227459146.7124.323.camel@localhost> (Duncan Coutts's message of "Sun\, 23 Nov 2008 16\:52\:26 +0000") References: <1227459146.7124.323.camel@localhost> Message-ID: >>>>> "Duncan" == Duncan Coutts writes: Duncan> ls compiler/parser reveals... Duncan> Lexer.x Parser.y.pp Thanks. Duncan> However you might get further using the ghc api package. Could be. But how do I make use of it? -- Colin Adams Preston Lancashire From igloo at earth.li Sun Nov 23 13:26:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 23 13:20:19 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1227361783.7124.209.camel@localhost> References: <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <4926BF27.9070506@gmail.com> <1227361783.7124.209.camel@localhost> Message-ID: <20081123182624.GA3722@matrix.chaos.earth.li> On Sat, Nov 22, 2008 at 01:49:43PM +0000, Duncan Coutts wrote: > On Fri, 2008-11-21 at 14:01 +0000, Simon Marlow wrote: > > > * Move to Haskeline for the default build. We have to bring in terminfo > > and utf8-string as bootlibs. This gives us line-editing on Windows, > > and removes problematic external C library dependencies. > > I think this is worth trying. It seems like Judah is prepared to put the > work in to make haskeline work on various platforms and to trim the > dependencies. > > Eg I'd rather us decide what to do about Unicode input rather than just > end up de-facto standardising the utf8-string package. Right, if we're targetting this for 6.12 then there's no rush (and we have some time until 6.10.2, too, if we decide to change things for that). I think we should step back and think about whether utf8-string is the package that we're going to want to use for: * IO in the base libraries * The ptext function in Text.PrettyPrint * Implementing FastString on top of as we really want all of these to use the same library. Thanks Ian From dons at galois.com Sun Nov 23 13:50:41 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 23 13:44:30 2008 Subject: sum[1..100000] --> stack overflow in GHC, but not in Hugs? In-Reply-To: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> References: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> Message-ID: <20081123185041.GB22615@scytale.galois.com> shoot.spam: > Hi, > > Please bear with a very basic question. I am trying to 'learn me a > Haskell for great good' using Hutton's book and some online tutorials. > I started off with Hugs and recently used GHC (to use the 'let a = > .." syntax interactively, which Hugs doesn't allow perhaps). > > There's a simple issue I am having with GHC. sum[1..100000] works fine > on Hugs, however, the same in GHCi generates a stack overflow > exception. I am trying to figure out what's going on. > > > Prelude> sum[1..100000] > 5000050000 > Prelude> sum[1..1000000] > *** Exception: stack overflow > Prelude> > > ________________________ > > Hugs> sum[1..10000] > 50005000 > Hugs> sum[1..100000] > 5000050000 > Hugs> > > > Thanks in anticipation. > > Best regards, > Vishal Belsare > Probably the simplest thing to do is compile the code, $ cat A.hs main = print (sum [1..1000000]) $ ghc -O2 A.hs $ time ./a.out 500000500000 ./a.out 0.09s user 0.00s system 96% cpu 0.100 total As Duncan pointed out, Hugs has a non-standard strict implementation of sum, which is nice, but breaks the spec if you do it at every type. GHC with optimisations determines that indeed this should be strict, replacing sum with a specialised version, but those optimisations are enabled in the compiler, not ghci. -- Don From phercek at gmail.com Sun Nov 23 14:24:11 2008 From: phercek at gmail.com (Peter Hercek) Date: Sun Nov 23 14:18:16 2008 Subject: GHCi debugger status In-Reply-To: <49268C2F.4040309@gmail.com> References: <49268C2F.4040309@gmail.com> Message-ID: Daniil Elovkov wrote: > I'd like to know, how do ghc developers and users feel about the debugger? Sometimes it is better/quicker than "printf debugging" :) > Now I see it mess up the list of bindings in a funny way. For example, > in a previous trace session I had a variable, say, prev. It was bound > during pattern matching in a function, say, prevFunc. Now I'm having > another trace session, actually stepping from the very beginning. A > couple of steps after the beginning, prev suddenly appears in the > bindings where prevFunc absolutely has not yet been invoked. It's > completely unrelated. In 'show bindings' prev has a wrong type - > SomeType (it's ADT). Its real type (when in scope) is [t]. I ask 'length > prev' and get 0 :) It is supposed to show only free variables in the selected expression. I'm sure I had cases when I was able to access variables which were not free in the selected expression but which would have been in scope if used in the selected expression. The values available seemed correct (contrary to your case). I thought it was a step to get all the variables in scope to be visible but later I learned it is not feasible and my lucky experience was probably a bug. If I encounter it again should I fill a bug report? I mean: is it really a bug? Peter. From jgmorris at cecs.pdx.edu Sun Nov 23 14:59:25 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Sun Nov 23 14:53:17 2008 Subject: sum[1..100000] --> stack overflow in GHC, but not in Hugs? In-Reply-To: <20081123185041.GB22615@scytale.galois.com> References: <80a89bc00811230607s40b1de56i47f3ebe8ada518a0@mail.gmail.com> <20081123185041.GB22615@scytale.galois.com> Message-ID: <6cf91caa0811231159v55c2dfecybd61d143288cfa1b@mail.gmail.com> On Sun, Nov 23, 2008 at 10:50 AM, Don Stewart wrote: > shoot.spam: >> I started off with Hugs and recently used GHC (to use the 'let a = >> .." syntax interactively, which Hugs doesn't allow perhaps). > > Probably the simplest thing to do is compile the code, I rather doubt that's the simplest way to use the 'let...' syntax interactively, actually. /g -- I am in here From simonpj at microsoft.com Mon Nov 24 03:23:24 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 24 03:17:19 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3319241A127@EA-EXMSG-C334.europe.corp.microsoft.com> In my case, we had rigid type signatures all over the place. The wiki document says that the type must be rigid at the point of the match. I guess that's what we were violating. If the code I posted isn't supposed to type check then I would like to report, as user feedback, that GADTs have become unwieldy. I grant that it's less convenient than one would like. The difficulty is that GADTs get you into territory where it's easy to write programs that have multiple *incomparable* types. That is, there is no "best" type (unlike Hindley-Milner). So we pretty much have to ask the programmer to express the type. Once we are in that territory, we need to give simple rules that say when a type signature is needed. I know that I have not yet found a way to express these rules -- perhaps GHC's users can help. My initial shot is http://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching I couldn't figure out how to fix that code by just adding a type signature. Did you try giving a type signature to the (entire) case expression, as I suggested? That should do it. I urge you to consider designing a modified or new syntactic form for working with GADT pattern matches. The quasi-dependent typing that GADTs give developers is very powerful and it would seem that GHC Haskell with GADTs is as close to dependent typing that developers writing "real-world" software can get. I know of no other production ready compilers that provide dependent or close to dependent typing. Dependent typing seems to be a growing area of interest. For these reasons I think it's important for GHC to focus on making them pleasanter to work with again; even if it means adding to the language again. If I knew how to do that, I'd love to. Here's one idea you might not like: restrict GADT matching to function definitions only (not case expressions), and require a type signature for such pattern matches. That wouldn't require adding new stuff. But GHC's current story is a bit more flexible. I also feel that the type errors given when working with existential types, especially GADTs with existentials, are confusing. I think mostly because the types of the sub-expressions in the program are not visible to the user. More introspection into the inferred types would help users. I have some ideas on how to improve this, what the output should look like and I would like to implement it too, but I haven't had a chance to start a prototype yet. I agree they are confusing. I always encourage people to suggest alternative wording for an error message that would make it less confusing (leaving aside how feasible or otherwise it'd be to generate such wording). So next time you are confused but figure it out, do suggest an alternative. Thanks for helping. You can't develop a good user interface without articulate and reflective users. Thanks. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081124/0c6f9d83/attachment-0001.htm From simonpj at microsoft.com Mon Nov 24 04:00:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 24 03:54:03 2008 Subject: Linking to Haskell code from an external program In-Reply-To: References: <49216358.9060806@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> It looks as if you are somehow failing to link your binary with package 'base'. (Are you using 'ghc' as your linker; you should be.) But others are better than I at this kind of stuff. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Colin Paul Adams | Sent: 23 November 2008 15:20 | To: Simon Marlow | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Linking to Haskell code from an external program | | >>>>> "Colin" == Colin Paul Adams writes: | | >>>>> "Simon" == Simon Marlow writes: | Colin> I then attempted to move it into Eiffel. I can compile the | Colin> C code OK, but I'm running into problems with linking. | >>> | Colin> I solved most of the problems by adding the -v flag to the | Colin> call to ghc which I used to link the original (haskell + c | Colin> only) program, and cut-and-paste the linker options from | Colin> their into the Eiffel configuration file. This isn't really | Colin> satisfactory - I would like some automatic way to determine | Colin> what the flags should be. | | Simon> The only other way I can think of is to construct the | Simon> arguments yourself by querying the package database, | Simon> e.g. "ghc-pkg field ld-options rts", but you'll have to | Simon> combine the information from several different fields of | Simon> the packages you use, and basically reproduce what GHC does | Simon> to construct the ld command line. | | I have upgraded to ghc 6.10.1 by compiling from source. | | Now I can't get it to link, either using my previous method of linking | a standalone C program via ghc -v, and copying the -u options, or by | running: | | ghc-pkg field rts ld-options | | (I found out by trial-and error that the syntax you gave above was | inverted). | | In both cases, I get errors: | | /home/colin/fib/Fib.o: In function `r131_info': | (.text+0x79): undefined reference to `base_GHCziBase_ZC_con_info' | /home/colin/fib/Fib.o: In function `r131_info': | (.text+0x10f): undefined reference to `base_GHCziBase_ZMZN_closure' | /home/colin/fib/Fib.o: In function `s13p_info': | (.text+0x157): undefined reference to `base_GHCziBase_ZMZN_closure' | /home/colin/fib/Fib.o: In function `s13F_info': | (.text+0x2cf): undefined reference to `base_GHCziBase_ZMZN_closure' | /home/colin/fib/Fib.o: In function `s13c_info': | (.text+0x32): undefined reference to `base_GHCziNum_plusInteger_info' | /home/colin/fib/Fib.o: In function `r131_info': | (.text+0x124): undefined reference to `base_GHCziList_foldr21_info' | /home/colin/fib/Fib.o:(.data+0x0): undefined reference to `base_GHCziNum_Szh_static_info' | /home/colin/fib/Fib.o:(.data+0x10): undefined reference to `base_GHCziNum_Szh_static_info' | /home/colin/fib/Fib.o: In function `r131_closure': | (.data+0x38): undefined reference to `base_GHCziBase_ZC_static_info' | /home/colin/fib/Fib.o: In function `r131_closure': | (.data+0x58): undefined reference to `base_GHCziBase_ZC_static_info' | collect2: ld returned 1 exit status | | I tried in desperation to add -u flag for each of the undefined | symbols above, but it makes no difference. | | I'm quite lost now. | | My C code looks like this: | | static char * program_name = "Eiffel program"; | static char * terminator = (char *) 0; | int argc; | char **argv[2]; | argc = 1; | argv [0] = &program_name; | argv [1] = &terminator; | hs_init(&argc, argv); | #ifdef __GLASGOW_HASKELL__ | #include "Fib_stub.h" | extern void __stginit_Fib ( void ); | hs_add_root(__stginit_Fib); | #endif | return (fibonacci_hs($n)); | hs_exit(); | | (and in addition there are includes for and "HsFFI.h" | somewhere preceding the above). | -- | Colin Adams | Preston Lancashire | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From colin at colina.demon.co.uk Mon Nov 24 04:08:59 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Nov 24 04:02:51 2008 Subject: Linking to Haskell code from an external program In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> (Simon Peyton-Jones's message of "Mon\, 24 Nov 2008 09\:00\:11 +0000") References: <49216358.9060806@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: >>>>> "Simon" == Simon Peyton-Jones writes: Simon> It looks as if you are somehow failing to link your binary Simon> with package 'base'. (Are you using 'ghc' as your linker; Simon> you should be.) But others are better than I at this kind Simon> of stuff. I have base-4.0.0.0 specified. No, I am not using ghc as the linker. Since I am calling the Haskell routine from an Eiffel program, I don't see how I could do that with any sort of ease. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Mon Nov 24 04:13:52 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 24 04:07:47 2008 Subject: GHCi debugger status In-Reply-To: References: <49268C2F.4040309@gmail.com> Message-ID: <492A7050.6090707@gmail.com> Peter Hercek wrote: > Daniil Elovkov wrote: >> I'd like to know, how do ghc developers and users feel about the >> debugger? > > Sometimes it is better/quicker than "printf debugging" :) > >> Now I see it mess up the list of bindings in a funny way. For example, >> in a previous trace session I had a variable, say, prev. It was bound >> during pattern matching in a function, say, prevFunc. Now I'm having >> another trace session, actually stepping from the very beginning. A >> couple of steps after the beginning, prev suddenly appears in the >> bindings where prevFunc absolutely has not yet been invoked. It's >> completely unrelated. In 'show bindings' prev has a wrong type - >> SomeType (it's ADT). Its real type (when in scope) is [t]. I ask >> 'length prev' and get 0 :) > > It is supposed to show only free variables in the selected expression. > I'm sure I had cases when I was able to access variables which were > not free in the selected expression but which would have been in > scope if used in the selected expression. The values available seemed > correct (contrary to your case). I thought it was a step to get all > the variables in scope to be visible but later I learned it is not > feasible and my lucky experience was probably a bug. If I encounter > it again should I fill a bug report? I mean: is it really a bug? At the least it's suspicious, and could be a bug. Please do report it, as long as you can describe exactly how to reproduce the problem. Cheers, Simon From colin at colina.demon.co.uk Mon Nov 24 04:56:05 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Nov 24 04:49:59 2008 Subject: Backspace/delete/history in ghci Message-ID: I can't use the backspace key, or arrow keys in ghci (6.10.1) as i would normally expect to on any program on Linux. Is this connected with the readline/editline/haskelline debate I have observed recently? -- Colin Adams Preston Lancashire From claus.reinke at talk21.com Mon Nov 24 06:06:03 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Nov 24 06:00:27 2008 Subject: GHCi debugger status References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com> Message-ID: <7EE0915016A84FBCAE3075123F47D2E3@cr3lt> >> It is supposed to show only free variables in the selected expression. >> I'm sure I had cases when I was able to access variables which were >> not free in the selected expression but which would have been in >> scope if used in the selected expression. The values available seemed >> correct (contrary to your case). I thought it was a step to get all >> the variables in scope to be visible but later I learned it is not >> feasible and my lucky experience was probably a bug. If I encounter >> it again should I fill a bug report? I mean: is it really a bug? Perhaps someone could help me to understand how the debugger is supposed to be used, as I tend to have this problem, too: - when I'm at a break point, I'd really like to see the current scope or, if that is too expensive, the next enclosing scope, in full (not only would that tell me what instantiation of my code I'm in, it would also seem necessary if I want to reconstruct what the current expression is) - with only the current expression and some of its free variables accessible, I seem to be unable to use the debugger effectively (it would be less of a problem if the current expression could be displayed in partially reduced source form, instead of partially defined value form) Currently, I only use the debugger rarely, and almost always have to switch to trace/etc to pin down what it is hinting at. What is the intended usage pattern that makes the debugger more effective/ convenient than trace/etc, and usable without resorting to the latter? Claus From barney_stratford at fastmail.fm Mon Nov 24 06:26:55 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Mon Nov 24 06:20:44 2008 Subject: Can't compile GHC 6.8.2 Message-ID: <1227526015.21086.1286434575@webmail.messagingengine.com> I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the typechecker refuses to compile. The problem seems to be that the hi-boot files in compiler/typecheck contain some incorrect type signatures. I've fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As it stands, it says tcMatchesFun :: Name.Name -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) but it should say something like tcMatchesFun :: Name.Name -> Bool -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, so I tried saying Prelude.Bool instead. Now I get the complaint that Prelude.Bool isn't in scope. Has anyone else seen this issue? I've looked for answers in the docs and with Google, but no luck. I'm running Mac OS 10.3, with GHC 6.2 installed under Fink. I borrowed the Fink package for GHC 6.8.2 and adapted it slightly so it would bootstrap from my existing GHC, as the bootstrap code available for download relies on a later version of my OS. GHC 6.2 can't compile GHC 6.10, which is why I'm going for the earlier version. Cheers, Barney. From marlowsd at gmail.com Mon Nov 24 07:00:35 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 24 06:54:30 2008 Subject: GHCi debugger status In-Reply-To: <7EE0915016A84FBCAE3075123F47D2E3@cr3lt> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com> <7EE0915016A84FBCAE3075123F47D2E3@cr3lt> Message-ID: <492A9763.8030100@gmail.com> Claus Reinke wrote: > >> It is supposed to show only free variables in the selected expression. >>> I'm sure I had cases when I was able to access variables which were >>> not free in the selected expression but which would have been in >>> scope if used in the selected expression. The values available seemed >>> correct (contrary to your case). I thought it was a step to get all >>> the variables in scope to be visible but later I learned it is not >>> feasible and my lucky experience was probably a bug. If I encounter >>> it again should I fill a bug report? I mean: is it really a bug? > > Perhaps someone could help me to understand how the debugger is supposed > to be used, as I tend to have this problem, too: > > - when I'm at a break point, I'd really like to see the current scope > or, if that is too expensive, the next enclosing scope, in full > (not only would that tell me what instantiation of my code I'm in, > it would also seem necessary if I want to reconstruct what the > current expression is) I don't understand what you mean here - surely in order to "reconstruct what the current expression is" you only need to know the values of the free variables of that expression? Also I don't understand what you mean by the "next enclosing scope". Could you give an example? > - with only the current expression and some of its free variables > accessible, I seem to be unable to use the debugger effectively > (it would be less of a problem if the current expression could > be displayed in partially reduced source form, instead of partially > defined value form) I don't know what "partially defined value form" is. The debugger shows the source code as... source code! I think I know what you mean though. You want the debugger to substitute the values of free variables in the source code, do some reductions, and show you the result. Unfortunately this is quite hard to implement in GHCi (but I agree it might be useful), because GHCi is not a source-level interpreter. > Currently, I only use the debugger rarely, and almost always have to > switch to trace/etc to pin down what it is hinting at. What is the > intended usage pattern that makes the debugger more effective/ > convenient than trace/etc, and usable without resorting to the latter? Set a breakpoint on an expression that has the variable you're interested in free, and display its value. If your variable isn't free in the expression you want to set a breakpoint on, then you can add a dummy reference to it. Cheers, Simon From marlowsd at gmail.com Mon Nov 24 07:07:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 24 07:01:30 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <1227361783.7124.209.camel@localhost> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <4926BF27.9070506@gmail.com> <1227361783.7124.209.camel@localhost> Message-ID: <492A9906.3020505@gmail.com> Duncan Coutts wrote: > On Fri, 2008-11-21 at 14:01 +0000, Simon Marlow wrote: > >> I propose we do this: >> >> * extract the GHCi UI from the GHC package, put it in the ghc-bin package >> (maybe we should rename this package to ghc-main or something). This >> removes the editline and bytestring (for now) dependencies from the GHC >> package. > > This is good independently of the other suggestions. > >> * Move to Haskeline for the default build. We have to bring in terminfo >> and utf8-string as bootlibs. This gives us line-editing on Windows, >> and removes problematic external C library dependencies. > > I think this is worth trying. It seems like Judah is prepared to put the > work in to make haskeline work on various platforms and to trim the > dependencies. > > Eg I'd rather us decide what to do about Unicode input rather than just > end up de-facto standardising the utf8-string package. It seemed like we > had a consensus on what to do for the H98 IO with Unicode. We just need > to get on with it. Yes - I did some work on this, but didn't finish it. Unfortunately trying to shoehorn encodings into the IO library isn't pretty, and I became a bit disillusioned. I could probably still get it working, but I think I was really hoping that a better architecture for the IO library might emerge, and so far it didn't :-) > In addition we need to agree some control over > encoding when using a specific encoding is called for (eg reading a file > that is known to be UTF-16 independent of the locale). Right, this will certainly be possible when we have System.IO doing encoding/decoding, we just need to agree on an API. >> Oops - except that >> this would mean that the ghc-main package has a variant license. So >> maybe we have to have a separate ghc-readline package? > > A variant license isn't a fundamental technical problem though perhaps > the consensus is that variant licenses are a "bad thing". I'm not sure. > One would have to use OtherLicense and specify what the conditions are > in the license file. I think it's a good idea to avoid variant licenses, especially in libraries. We want it to be easy for someone to know whether they're complying with the licenses for the libraries they depend on, and if those licenses depend on choices made at the time the library was built, then it's much harder. Cheers, Simon From marlowsd at gmail.com Mon Nov 24 07:09:06 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 24 07:03:01 2008 Subject: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? In-Reply-To: <492A9906.3020505@gmail.com> References: <200811071213.05230.p.k.f.holzenspies@utwente.nl> <1226061367.8437.335.camel@localhost> <6d74b0d20811070914h618e677do65995cf11acf474f@mail.gmail.com> <1226081346.8437.370.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CAF1@EA-EXMSG-C334.europe.corp.microsoft.com> <1227180851.7124.48.camel@localhost> <49255D46.2050906@gmail.com> <1227189132.7124.93.camel@localhost> <4926BF27.9070506@gmail.com> <1227361783.7124.209.camel@localhost> <492A9906.3020505@gmail.com> Message-ID: <492A9962.40905@gmail.com> Simon Marlow wrote: > I think it's a good idea to avoid variant licenses, especially in > libraries. We want it to be easy for someone to know whether they're > complying with the licenses for the libraries they depend on, and if > those licenses depend on choices made at the time the library was built, > then it's much harder. Oh, I should add that ghci-bin (or whatever) is an application, not a library, so it's less of an issue for it to have a variant license. Cheers, Simon From marlowsd at gmail.com Mon Nov 24 07:15:23 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 24 07:09:19 2008 Subject: Linking to Haskell code from an external program In-Reply-To: References: <49216358.9060806@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <492A9ADB.2070105@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Peyton-Jones writes: > > Simon> It looks as if you are somehow failing to link your binary > Simon> with package 'base'. (Are you using 'ghc' as your linker; > Simon> you should be.) But others are better than I at this kind > Simon> of stuff. > > I have base-4.0.0.0 specified. > > No, I am not using ghc as the linker. Since I am calling the Haskell > routine from an Eiffel program, I don't see how I could do that with > any sort of ease. I think you'll have to post complete instructions to reproduce the problem you're having; it's hard to piece it together from the information you've given. The problem will be in the details somewhere. Cheers, Simon From marlowsd at gmail.com Mon Nov 24 07:16:33 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 24 07:10:27 2008 Subject: Backspace/delete/history in ghci In-Reply-To: References: Message-ID: <492A9B21.1000304@gmail.com> Colin Paul Adams wrote: > I can't use the backspace key, or arrow keys in ghci (6.10.1) as i > would normally expect to on any program on Linux. > > Is this connected with the readline/editline/haskelline debate I have > observed recently? You seem to be encountering an unusually severe reaction to the editline switchover. What terminal type is this? Cheers, Simon From marlowsd at gmail.com Mon Nov 24 07:19:18 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 24 07:13:12 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1227526015.21086.1286434575@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> Message-ID: <492A9BC6.60206@gmail.com> Barney Stratford wrote: > I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the > typechecker refuses to compile. The problem seems to be that the hi-boot > files in compiler/typecheck contain some incorrect type signatures. I've > fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As > it stands, it says > > tcMatchesFun :: Name.Name > -> HsExpr.MatchGroup Name.Name > -> TcType.BoxyRhoType > -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) > > but it should say something like > > tcMatchesFun :: Name.Name -> Bool > -> HsExpr.MatchGroup Name.Name > -> TcType.BoxyRhoType > -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) > > Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, > so I tried saying Prelude.Bool instead. Now I get the complaint that > Prelude.Bool isn't in scope. > > Has anyone else seen this issue? I've looked for answers in the docs and > with Google, but no luck. I think we only supported using GHC 6.4 for building 6.8. Using 6.2 might be possible, but no guarantees. To answer your question above, you probably want GHC.Base.Bool (hi-boot files used to need "original names", that is, the module that originally defined a thing, which might be different from the module you normally get it from). Cheers, Simon From colin at colina.demon.co.uk Mon Nov 24 07:28:27 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Nov 24 07:22:18 2008 Subject: Backspace/delete/history in ghci In-Reply-To: <492A9B21.1000304@gmail.com> (Simon Marlow's message of "Mon\, 24 Nov 2008 12\:16\:33 +0000") References: <492A9B21.1000304@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> Colin Paul Adams wrote: >> I can't use the backspace key, or arrow keys in ghci (6.10.1) >> as i would normally expect to on any program on Linux. >> >> Is this connected with the readline/editline/haskelline debate >> I have observed recently? Simon> You seem to be encountering an unusually severe reaction to Simon> the editline switchover. What terminal type is this? It's Terminal 2.22.2 - A terminal emulator for the GNOME desktop, on linux (Fedora 9 64-bit). -- Colin Adams Preston Lancashire From simonpj at microsoft.com Mon Nov 24 07:28:28 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 24 07:22:26 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1227526015.21086.1286434575@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> 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 a) the algorithm we use. I think we say that any GHC can be compiled with the previous three major releases, but maybe it's two. b) a table giving the claimed state of play To compile You need at least 6.10 6.6 6.8 6.4 no need to go back too far. THanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Barney Stratford | Sent: 24 November 2008 11:27 | To: glasgow-haskell-users@haskell.org | Subject: Can't compile GHC 6.8.2 | | I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the | typechecker refuses to compile. The problem seems to be that the hi-boot | files in compiler/typecheck contain some incorrect type signatures. I've | fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As | it stands, it says | | tcMatchesFun :: Name.Name | -> HsExpr.MatchGroup Name.Name | -> TcType.BoxyRhoType | -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) | | but it should say something like | | tcMatchesFun :: Name.Name -> Bool | -> HsExpr.MatchGroup Name.Name | -> TcType.BoxyRhoType | -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) | | Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, | so I tried saying Prelude.Bool instead. Now I get the complaint that | Prelude.Bool isn't in scope. | | Has anyone else seen this issue? I've looked for answers in the docs and | with Google, but no luck. | | I'm running Mac OS 10.3, with GHC 6.2 installed under Fink. I borrowed | the Fink package for GHC 6.8.2 and adapted it slightly so it would | bootstrap from my existing GHC, as the bootstrap code available for | download relies on a later version of my OS. GHC 6.2 can't compile GHC | 6.10, which is why I'm going for the earlier version. | | Cheers, | Barney. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From claus.reinke at talk21.com Mon Nov 24 07:50:20 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Nov 24 07:44:18 2008 Subject: GHCi debugger status References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com><7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> Message-ID: <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> >> - when I'm at a break point, I'd really like to see the current scope >> or, if that is too expensive, the next enclosing scope, in full >> (not only would that tell me what instantiation of my code I'm in, >> it would also seem necessary if I want to reconstruct what the >> current expression is) > > I don't understand what you mean here - surely in order to "reconstruct > what the current expression is" you only need to know the values of the > free variables of that expression? Also I don't understand what you mean > by the "next enclosing scope". Could you give an example? If is the current expression f a b = -- 'a' and 'b' should be inspectable, independent of g x y = where a = .. -- 'a' should be inspectable (ideally, 'x'/'y', too) > I don't know what "partially defined value form" is. The debugger shows > the source code as... source code! :list shows source code (without substitution) :print shows partially defined values (partially defined value form, with thunks) :force tries to evaluate, replacing uninspectable thunks with values There is no way to see source with substituted variables, or unevaluated expressions. So there's an information gap between source and values. It is in this gap that many of the interesting/buggy reductions happen (at least in my code;-). > I think I know what you mean though. You want the debugger to substitute > the values of free variables in the source code, do some reductions, and > show you the result. Unfortunately this is quite hard to implement in GHCi > (but I agree it might be useful), because GHCi is not a source-level > interpreter. Yes, that is what I've been missing ever since I moved from my previous functional language to Haskell. But I agree that it would be hard to add as an afterthought. I have high hopes that the GHCi debugger + scope might go most of the way in terms of practical needs. I really think the GHCi debugger is a great step in the right direction, but without being able to inspect the context of the current expression (about which we can only inspect its value, evaluation status, and free variables) it is stuck short of fullfiling its potential. Unless I'm using it wrongly, which is why I was asking. >> Currently, I only use the debugger rarely, and almost always have to >> switch to trace/etc to pin down what it is hinting at. What is the >> intended usage pattern that makes the debugger more effective/ >> convenient than trace/etc, and usable without resorting to the latter? > > Set a breakpoint on an expression that has the variable you're interested > in free, and display its value. If your variable isn't free in the > expression you want to set a breakpoint on, then you can add a dummy > reference to it. Adding dummy references means modifying the source, at which point trace variants do nearly as well. The remaining value of the debugger is that I can decide at debug time whether or not I want to see the traced value. Without modifying the source code, there may be no way to step forward to any expression that has the interesting variables free. In small examples, it is usually easy to work around the debugger limitations, so I'll have to remember to make a note next time I encounter the issues in real life debugging. However, even in small examples, one can see hints of the issues. Consider this code and session: f x y z | x :break f Breakpoint 0 activated at Debug.hs:(1,0)-(2,24) *Main> f 3 2 1 Stopped at Debug.hs:(1,0)-(2,24) _result :: a = _ [Debug.hs:(1,0)-(2,24)] *Main> :list vv 1 f x y z | x :step Stopped at Debug.hs:1:10-12 _result :: a = _ [Debug.hs:1:10-12] *Main> :list 1 f x y z | x :step Stopped at Debug.hs:2:10-18 _result :: a = _ [Debug.hs:2:10-18] *Main> :list 1 f x y z | x :step Stopped at Debug.hs:2:22-24 _result :: Integer = _ y :: Integer = 2 z :: Integer = _ [Debug.hs:2:22-24] *Main> :list 1 f x y z | x :step 2 --------------------- Things to note: - when reaching the breakpoint "in" 'f', one isn't actually in 'f' yet - nothing about 'f' can be inspected - at no point in the session was 'x' inspectable, even though it is likely to contain information needed to understand 'f', especially when we are deep in a recursion of a function that can be called from many places; this information doesn't happen to be needed in the current branch, but debugging the current expression always happens in a context, and accessing information about this context is what the GHCi debugger doesn't seem to support well In this particular example, the second item is most likely a bug (the free variables of the guard were never offered for inspection). That is perhaps more easily shown in the other branch: --------------------- *Main> f 1 2 3 Stopped at Debug.hs:(1,0)-(2,24) _result :: a = _ [Debug.hs:(1,0)-(2,24)] *Main> :list vv 1 f x y z | x :step Stopped at Debug.hs:1:10-12 _result :: a = _ [Debug.hs:1:10-12] *Main> :list 1 f x y z | x :step Stopped at Debug.hs:1:22 _result :: a = _ z :: a = _ [Debug.hs:1:22] *Main> :list 1 f x y z | x :step 3 --------------------- Cheers, Claus From phercek at gmail.com Mon Nov 24 08:03:22 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon Nov 24 07:57:21 2008 Subject: GHCi debugger status In-Reply-To: <492A9763.8030100@gmail.com> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com> <7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> Message-ID: Simon Marlow wrote: > Claus Reinke wrote: >> Perhaps someone could help me to understand how the debugger is >> supposed to be used, as I tend to have this problem, too: >> >> - when I'm at a break point, I'd really like to see the current scope >> or, if that is too expensive, the next enclosing scope, in full >> (not only would that tell me what instantiation of my code I'm in, >> it would also seem necessary if I want to reconstruct what the >> current expression is) > > I don't understand what you mean here - surely in order to "reconstruct > what the current expression is" you only need to know the values of the > free variables of that expression? Also I don't understand what you > mean by the "next enclosing scope". Could you give an example? Maybe what Claus means is that he would like to see the dynamic stack and be able to traverse it and at each location in the dynamic stack he could investigate the free variables in the expression (corresponding to the dynamic stack slot). I actually considered this as a feature request but I decided that I would like to have this implemented sooner: http://hackage.haskell.org/trac/ghc/ticket/2737 >> Currently, I only use the debugger rarely, and almost always have to >> switch to trace/etc to pin down what it is hinting at. What is the >> intended usage pattern that makes the debugger more effective/ >> convenient than trace/etc, and usable without resorting to the latter? > > Set a breakpoint on an expression that has the variable you're > interested in free, and display its value. If your variable isn't free > in the expression you want to set a breakpoint on, then you can add a > dummy reference to it. Actually I use it a bit differently mostly because I know (or I'm guessing) where the bug is located and set a breakpoint at a place which is hit just after the wrong decision happens. The "just after wrong decision" requirement is there so that I do not need to have too complicated expressions in the conditional breakpoint. Then I count how many times the breakpoint is hit of find some other expression which is true just before the hit I'm interested in (the hit with bug). I modify the script of the breakpoint so that it stops just before the hit I'm iterested in and restart. After restart the debugger stops at the modified breakpoint and I continue with either :steplocal or :trace. This is so that I have values of previous expressions in the trace history. Then (If I used :trace) I check the values in the trace history to find out why I got at the wrong place. The procedure is quite complicated but I do not know about quicker way to position the debugger at the right place and with the right variable values caught in the trace history. If I would not know the approximate location of the bug then hpc can help. For more simple things "printf debugging" is just enough. Peter. From dagit at codersbase.com Mon Nov 24 08:30:49 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Nov 24 08:24:39 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3319241A127@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A127@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Mon, Nov 24, 2008 at 12:23 AM, Simon Peyton-Jones wrote: > In my case, we had rigid type signatures all over the place. The wiki > document says that the type must be rigid at the point of the match. I > guess that's what we were violating. If the code I posted isn't supposed to > type check then I would like to report, as user feedback, that GADTs have > become unwieldy. > > > > I grant that it's less convenient than one would like. The difficulty is > that GADTs get you into territory where it's easy to write programs that > have multiple **incomparable** types. That is, there is no "best" type > (unlike Hindley-Milner). So we pretty much have to ask the programmer to > express the type. > > > > Once we are in that territory, we need to give simple rules that say when a > type signature is needed. I know that I have not yet found a way to > express these rules -- perhaps GHC's users can help. My initial shot is > http://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching > > > > > > > > I couldn't figure out how to fix that code by just adding a type signature. > > > > > Did you try giving a type signature to the (entire) case expression, as I > suggested? That should do it. > Perhaps I don't understand the suggestion, but for me the only way I could fix it was to put all the pattern matches into local functions with type signatures. I can show you the diffs if you would find it useful to see how 'programmers in the wild' react to this. > > > I urge you to consider designing a modified or new syntactic form for > working with GADT pattern matches. The quasi-dependent typing that GADTs > give developers is very powerful and it would seem that GHC Haskell with > GADTs is as close to dependent typing that developers writing "real-world" > software can get. I know of no other production ready compilers that > provide dependent or close to dependent typing. Dependent typing seems to > be a growing area of interest. For these reasons I think it's important for > GHC to focus on making them pleasanter to work with again; even if it means > adding to the language again. > > > > If I knew how to do that, I'd love to. Here's one idea you might not like: > restrict GADT matching to function definitions only (not case expressions), > and require a type signature for such pattern matches. That wouldn't > require adding new stuff. But GHC's current story is a bit more flexible. > In practice that's what we are doing. Any new code we write using our GADT data types is written in exactly that style because removing case-expressions on each GHC release is mildly annoying. As a user of GHC I can't predict when a case-expression on a GADT will be valid and when it give an error. Thankfully there ended up being less than 10 functions that we had to modify to become compatible with ghc-6.10. Some tasks look more daunting from the outset than they are in reality. > > > I also feel that the type errors given when working with existential types, > especially GADTs with existentials, are confusing. I think mostly because > the types of the sub-expressions in the program are not visible to the user. > More introspection into the inferred types would help users. I have some > ideas on how to improve this, what the output should look like and I would > like to implement it too, but I haven't had a chance to start a prototype > yet. > > > > I agree they are confusing. I always encourage people to suggest > alternative wording for an error message that would make it less confusing > (leaving aside how feasible or otherwise it'd be to generate such wording). > So next time you are confused but figure it out, do suggest an alternative. > The first two stumbling blocks I ever had with the type errors was the meaning of rigid type and the difference between inferred and expected type. These days neither of those are an issue for me, but maybe its useful to hear. I take rigid type to mean a type that I specified. It may not be 100% accurate but it's close enough for intuiton. I think the problem with inferred vs. expected is that the difference in their meanings is too narrow. My understanding is that the expected type is based on rigid types and the inferred type is based on the type inference. Using words that are more polar in meaning, but still accurate, could potentially help here. Such as inferred vs. provided. But this is very minor. I think the real problem here is that the type checker does a very non-trivial amount of reasoning about your code then it spits out some well written error messages with a good deal of static only context. What I mean is, the errors do a good job of giving me back static information thus saving me some time of looking up the context and also helping me zero in on the trouble area, but it doesn't help me to understand the why of the error. I think the information that is still lacking is knowledge about the process that the type checker used to arrive at its conclusion. Every time I've been really stumped by the type checker I used the exact same trick to get unstuck. I mimicked a type checker on paper to the best of my ability until I had annotated a paper version of the code with types at each sub-expression. Then I compared that against the output from GHC. Only once I had that annotated version of the code could I sit back and think about what was wrong with the code to fix it. Obviously this annotation could be done by a machine. I think if the error message could dump your program annotated with types to html that we could achieve this introspection. I think there is a lot of fine tuning that would need to be done here, but that basic idea could be carried very far. For example, rendering all the eigenvariables that result from existential types in a different alphabet, such as greek, may be a useful fine tuning. I picture this as a -ddump-types flag or something of that nature and it would need to be able to bump the inferred versus expected types as well. Eventually it may even be handy if the programmer could 'single step' through the type check process. I would like to work on the above feature, and I really probably should have developed that before my work with GADTs, but it's hard to know ahead of time what will be a hurdle. I admit I know very little about how GHC is implemented, so do you think that the above should be possible? Do you have advice on getting started over that which can be found on the ghc trac? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081124/34daf50d/attachment.htm From phercek at gmail.com Mon Nov 24 08:31:48 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon Nov 24 08:25:52 2008 Subject: GHCi debugger status In-Reply-To: <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com><7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> Message-ID: Claus Reinke wrote: > f x y z | x | otherwise = z*y > > --------------------- > $ /cygdrive/d/fptools/ghc/ghc/stage2-inplace/ghc.exe --interactive > Debug.hs -ignore-dot-ghci > GHCi, version 6.11.20081122: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > [1 of 1] Compiling Main ( Debug.hs, interpreted ) > Ok, modules loaded: Main. > *Main> :break f > Breakpoint 0 activated at Debug.hs:(1,0)-(2,24) > *Main> f 3 2 1 > Stopped at Debug.hs:(1,0)-(2,24) > _result :: a = _ > [Debug.hs:(1,0)-(2,24)] *Main> :list > vv > 1 f x y z | x 2 | otherwise = z*y > ^^ > 3 > [Debug.hs:(1,0)-(2,24)] *Main> :step > Stopped at Debug.hs:1:10-12 > _result :: a = _ > [Debug.hs:1:10-12] *Main> :list > 1 f x y z | x ^^^ > 2 | otherwise = z*y > [Debug.hs:1:10-12] *Main> Looks like a bug to me, At this location the x a y should be observable and cought in trace history. It actually looks very similar to bug I reported here: http://hackage.haskell.org/trac/ghc/ticket/2740 Notice that if you write your function like this (as I mostly do): f x y z = if x References: <638ABD0A29C8884A91BC5FB5C349B1C33192419E71@EA-EXMSG-C334.europe.corp.microsoft.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A127@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C331927EE5DF@EA-EXMSG-C334.europe.corp.microsoft.com> Did you try giving a type signature to the (entire) case expression, as I suggested? That should do it. Perhaps I don't understand the suggestion, but for me the only way I could fix it was to put all the pattern matches into local functions with type signatures. I can show you the diffs if you would find it useful to see how 'programmers in the wild' react to this. I just mean: give a type signature to the entire case expression. Thus (case ... of { ...}) :: type I'd welcome a way to say that more clearly. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081124/b1a1f587/attachment-0001.htm From mnislaih at gmail.com Mon Nov 24 09:29:56 2008 From: mnislaih at gmail.com (Pepe Iborra) Date: Mon Nov 24 09:23:44 2008 Subject: GHCi debugger status In-Reply-To: References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com> <7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> Message-ID: <44b20d900811240629q3bcc5cdck38e25a98d64cdb2c@mail.gmail.com> On Mon, Nov 24, 2008 at 2:03 PM, Peter Hercek wrote: > Simon Marlow wrote: >> >> Claus Reinke wrote: >>> >>> Perhaps someone could help me to understand how the debugger is supposed >>> to be used, as I tend to have this problem, too: >>> >>> - when I'm at a break point, I'd really like to see the current scope >>> or, if that is too expensive, the next enclosing scope, in full >>> (not only would that tell me what instantiation of my code I'm in, >>> it would also seem necessary if I want to reconstruct what the >>> current expression is) >> >> I don't understand what you mean here - surely in order to "reconstruct >> what the current expression is" you only need to know the values of the free >> variables of that expression? Also I don't understand what you mean by the >> "next enclosing scope". Could you give an example? > > Maybe what Claus means is that he would like to see the dynamic > stack and be able to traverse it and at each location in the > dynamic stack he could investigate the free variables in the > expression (corresponding to the dynamic stack slot). I actually > considered this as a feature request but I decided that I would > like to have this implemented sooner: > http://hackage.haskell.org/trac/ghc/ticket/2737 > As long as you start with :trace, you can see the dynamic stack with :history, and traverse it with :back. At any point in the stack the free variables are available, or so I believe. What is the missing feature you would like to request in this case? From daniil.elovkov at googlemail.com Mon Nov 24 10:02:16 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Mon Nov 24 09:56:09 2008 Subject: GHCi debugger status In-Reply-To: <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com><7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> Message-ID: <492AC1F8.1060808@gmail.com> Hello I think apart from some other notes the concern here, as started by Peter when he joined the thread, can be concisely summarised like this: it would be good if the set of bound variables were equal to the set of variables syntactically in scope Apparently, Simon has already explained that that would bear a lot of overhead in the thread "could ghci debugger search for free variables better?" in the end of October - beginning of November. The reason for that overhead, as I recall the nature of execution in ghc, should be that closures only have pointers to their free variables. Indeed it's only them that is needed for _computing_ the closure. And when we enter a closure we 'forgive' all the outer scope, which is nevertheless syntactically in scope. I understand the reasons, but I think it's a very serious drawback. I'd love to have a Haskell debugger which is no worse than traditional imperative debuggers, but this seems like a more or less fundamental obstacle. 2 workarounds have been suggested 1. Add references to the identifier of interest in the code, so that it becomes a free variable in the expression where we will stop. This is hardly compatible with the 'no worse' part. 2. Go back in history to the expression where the identifier of interest is free and thus bound. For example, in the same October/November thread Peter suggests :tracelocal, which would only record the history of evaluation inside this function. Then, when walking back in history looking for the identifier of interest, one would not get lost in many-many evaluations happening lazily outside of this function and they would not overflow the history slots. A refinement of :tracelocal could be :tracedirect (or something) that would save the history not anywhere within the given function but only within parents, so to say. For example, f x y = let v = large_exp_v w = large_exp_w in (w x) + (v y) If we inspect (v y) then (w x) + (v y) is the parent. In this parent w becomes bound. We don't have to record the history for large_exp_v and large_exp_w and we still can get bound all variables which are syntactically in scope. Also, I think about having a visual debugger (say in Eclipse) that would add value the the ghci debugger. Particularly it could maintain the illusion that all vars in scope and really available, by going back and forth in history. It could do quite a number of other things as well. Anyway, even with :tracelocal and :tracedirect the history size limit still can be quite a limitation (yes, tautology). What will happen if we don't limit its size? No memory will ever be released? Claus Reinke wrote: >>> - when I'm at a break point, I'd really like to see the current scope >>> or, if that is too expensive, the next enclosing scope, in full >>> (not only would that tell me what instantiation of my code I'm in, >>> it would also seem necessary if I want to reconstruct what the >>> current expression is) From phercek at gmail.com Mon Nov 24 10:09:09 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon Nov 24 10:03:07 2008 Subject: GHCi debugger status In-Reply-To: <44b20d900811240629q3bcc5cdck38e25a98d64cdb2c@mail.gmail.com> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com> <7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> <44b20d900811240629q3bcc5cdck38e25a98d64cdb2c@mail.gmail.com> Message-ID: Pepe Iborra wrote: > On Mon, Nov 24, 2008 at 2:03 PM, Peter Hercek wrote: >> Maybe what Claus means is that he would like to see the dynamic >> stack and be able to traverse it and at each location in the >> dynamic stack he could investigate the free variables in the >> expression (corresponding to the dynamic stack slot). I actually >> considered this as a feature request but I decided that I would >> like to have this implemented sooner: >> http://hackage.haskell.org/trac/ghc/ticket/2737 >> > > As long as you start with :trace, you can see the dynamic stack with > :history, and traverse it with :back. > At any point in the stack the free variables are available, or so I believe. > What is the missing feature you would like to request in this case? Hmmm, I believe that dynamic stack is not the same as :trace history. The point is that the trace history shows all the evalueated expressions as they occure in time. But dynamic stack shows only the expressions which evaluation did not finish yet. Example: 1 let fn a = 2 let f x = x + 1 in 3 case f a of 4 1 -> "one" 5 _ -> "" When selected expression is "one" then the trace will contain something like this (just doing it from the top of my head): line 1-5 fn a = ... line 3-5 case f a of ... line 3 f a line 2 let f x = x + 1 in line 2 x + 1 possibly something from outside which forces x and consequently a line 4 "one" But the dynamic stack would contain: line 1-5 fn a = ... line 3-5 case f a of ... line 4 "one" The difference is that the dynamic stack contains only the items which computation is not finished yet. The stuff which was already reduced to a final value is not there any more. This way you could trace the dynamic stack back to see what arguments was your function called with since the arguments must be free variables in the expression which called your function of interest. Of course the same information is in the trace too ... that is if your trace history is long enough and you are willing to search it manually. That is the rason for ticket 2737. I do not want to search it manually! Maybe trace is the dynamic stack and I did not realize what trace contains till now. That would be kind of a shame :-D Peter. From phercek at gmail.com Mon Nov 24 10:43:37 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon Nov 24 10:37:45 2008 Subject: GHCi debugger status In-Reply-To: <492AC1F8.1060808@gmail.com> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com><7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> <492AC1F8.1060808@gmail.com> Message-ID: Daniil Elovkov wrote: > A refinement of :tracelocal could be :tracedirect (or something) that > would save the history not anywhere within the given function but only > within parents, so to say. For example, This looks like what I thought of as searching for values in dynamic stack (explained in my response to Pepe Iborra in this thread). I just did not ask for it with a new ticket since: * I think it is already requested by some other ticket * if you compile with -Wall then :tracelocal should have the same information and only rarely name collision happens so automatic tracelocal trace search should return what you are looking for too and when needed it reruns more ... that is if the function is short enough to fit in the tracelocal history queue The ticket actually has two almost independent parts: * Adding tracelocal trace. * Adding the automatic search for symbols in the trace and the trace in the search could be also some other kind of trace like (e.g. dynamic stack). This would not be that useful though since the names at higher levels in stack are typically different. So to make it good it would require matching formal arguments to expressions on higher level and evaluating them, not that easy to do as simple tracelocal search which is just based on stupid string comparison. Peter. From judah.jacobson at gmail.com Mon Nov 24 11:03:45 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Nov 24 10:57:35 2008 Subject: Backspace/delete/history in ghci In-Reply-To: References: Message-ID: <6d74b0d20811240803i8bbcd88nd56fa0ff38abfb42@mail.gmail.com> On Mon, Nov 24, 2008 at 1:56 AM, Colin Paul Adams wrote: > I can't use the backspace key, or arrow keys in ghci (6.10.1) as i > would normally expect to on any program on Linux. > Did you compile ghc yourself or download the distribution from somewhere? If you're compiling it yourself, you'll need to first install Fedora's libedit-devel package. Hope that helps, -Judah From colin at colina.demon.co.uk Mon Nov 24 11:12:23 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Nov 24 11:06:19 2008 Subject: Backspace/delete/history in ghci In-Reply-To: <6d74b0d20811240803i8bbcd88nd56fa0ff38abfb42@mail.gmail.com> (Judah Jacobson's message of "Mon\, 24 Nov 2008 08\:03\:45 -0800") References: <6d74b0d20811240803i8bbcd88nd56fa0ff38abfb42@mail.gmail.com> Message-ID: >>>>> "Judah" == Judah Jacobson writes: Judah> On Mon, Nov 24, 2008 at 1:56 AM, Colin Paul Adams Judah> wrote: >> I can't use the backspace key, or arrow keys in ghci (6.10.1) >> as i would normally expect to on any program on Linux. >> Judah>Did you compile ghc yourself or download the distribution Judah> from somewhere? I compiled it myself, since there doesn't seem to be an rpm available for Fedora 9 yet for 6.10.1. Judah> If you're compiling it yourself, you'll need to Judah> first install Fedora's libedit-devel package. OK. But how come it compiled at all in that case? -- Colin Adams Preston Lancashire From daniil.elovkov at googlemail.com Mon Nov 24 11:28:02 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Mon Nov 24 11:21:52 2008 Subject: GHCi debugger status In-Reply-To: References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com><7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> <492AC1F8.1060808@gmail.com> Message-ID: <492AD612.1040303@gmail.com> Peter Hercek wrote: > Daniil Elovkov wrote: >> A refinement of :tracelocal could be :tracedirect (or something) that >> would save the history not anywhere within the given function but only >> within parents, so to say. For example, > > This looks like what I thought of as searching for values in dynamic > stack (explained in my response to Pepe Iborra in this thread). Yes, first when I saw that your message I also thought "Hey, Peter has already suggested it!" :) But now I see that we're talking about slightly different things. Consider fun x y = let f1 = ... (f2 x) ... -- f1 calls f2 f2 = exp_f2 in ... Now, if we're at exp_f2 then 'dynamic stack' in your terminology includes (f2 x) since it's the caller and all f1 as well. On the other hand, :tracedirect that I suggested would not include f1, as it's not a direct ancestor. And for the purpose of binding variables which are syntactically in scope, it is indeed not needed. :tracedirect would be sufficient. Also, I think that :tracedirect can be easily implemented based only on simple syntactic inclusion relation. > I just did not ask for it with a new ticket since: > * I think it is already requested by some other ticket > * if you compile with -Wall then :tracelocal should have the same > information and only rarely name collision happens so automatic > tracelocal trace search should return what you are looking for > too and when needed it reruns more ... that is if the function > is short enough to fit in the tracelocal history queue > > The ticket actually has two almost independent parts: > * Adding tracelocal trace. > * Adding the automatic search for symbols in the trace and > the trace in the search could be also some other kind of > trace like (e.g. dynamic stack). This would not be that > useful though since the names at higher levels in stack > are typically different. So to make it good it would > require matching formal arguments to expressions on > higher level and evaluating them, not that easy to do > as simple tracelocal search which is just based on stupid > string comparison. From barney_stratford at fastmail.fm Mon Nov 24 11:28:49 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Mon Nov 24 11:22:39 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: <1227544129.27701.1286488959@webmail.messagingengine.com> I can now confirm that 6.2 can, in fact, bootstrap 6.8.2 (with the corrections to those hi-boots), although I've still not got the build to complete. If anyone wants to see the patch file, then let me know and I'll send it when I've ironed out the last creases. Thanks to all those who helped out. Barney. From colin at colina.demon.co.uk Mon Nov 24 11:49:04 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Nov 24 11:43:00 2008 Subject: Backspace/delete/history in ghci In-Reply-To: <6d74b0d20811240803i8bbcd88nd56fa0ff38abfb42@mail.gmail.com> (Judah Jacobson's message of "Mon\, 24 Nov 2008 08\:03\:45 -0800") References: <6d74b0d20811240803i8bbcd88nd56fa0ff38abfb42@mail.gmail.com> Message-ID: >>>>> "Judah" == Judah Jacobson writes: Judah> somewhere? If you're compiling it yourself, you'll need to Judah> first install Fedora's libedit-devel package. Judah> Hope that helps, -Judah It did. It's working fine now. Thanks. -- Colin Adams Preston Lancashire From mnislaih at gmail.com Mon Nov 24 12:09:38 2008 From: mnislaih at gmail.com (Pepe Iborra) Date: Mon Nov 24 12:03:28 2008 Subject: GHCi debugger status In-Reply-To: <492AD612.1040303@gmail.com> 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> Message-ID: <44b20d900811240909q1c272f92w4889422276f30d43@mail.gmail.com> On Mon, Nov 24, 2008 at 5:28 PM, Daniil Elovkov wrote: > Peter Hercek wrote: >> >> Daniil Elovkov wrote: >>> >>> A refinement of :tracelocal could be :tracedirect (or something) that >>> would save the history not anywhere within the given function but only >>> within parents, so to say. For example, >> >> This looks like what I thought of as searching for values in dynamic stack >> (explained in my response to Pepe Iborra in this thread). > > Yes, first when I saw that your message I also thought "Hey, Peter has > already suggested it!" :) > > But now I see that we're talking about slightly different things. Consider > > fun x y = > let f1 = ... (f2 x) ... -- f1 calls f2 > f2 = exp_f2 > in ... > > Now, if we're at exp_f2 then 'dynamic stack' in your terminology includes > (f2 x) since it's the caller and all f1 as well. > > On the other hand, :tracedirect that I suggested would not include f1, as > it's not a direct ancestor. And for the purpose of binding variables which > are syntactically in scope, it is indeed not needed. :tracedirect would be > sufficient. > > Also, I think that :tracedirect can be easily implemented based only on > simple syntactic inclusion relation. I am not convinced this would not imply the same problems as simply storing all the variables in scope at a breakpoint. Consider this slightly more contorted example: fun x y = let f1 = ... (f2 x) ... -- f1 calls f2 f2 x = x * 2 in case x of 1 -> f2 0 _ -> f2 (f1 y) g x = let z = (some complex computation) in z `div` x main = print (g (fun 1 2)) This is a classical example of why laziness gets in the way of debugging. Now, when (f2 0) gets finally evaluated and throws a divByZero error, x and y are nowhere to be found. Since we do not have a real dynamic stack, it is difficult to say where their values should be stored. The only place I can think of is at the breakpoint itself, but then as Simon said this poses a serious efficiency problem. From claus.reinke at talk21.com Mon Nov 24 12:41:32 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Nov 24 12:35:29 2008 Subject: GHCi debugger status 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> Message-ID: <4B38ABE7843C4D8C8A1BC76320571745@cr3lt> > fun x y = > let f1 = ... (f2 x) ... -- f1 calls f2 > f2 x = x * 2 > in case x of > 1 -> f2 0 > _ -> f2 (f1 y) > > g x = let z = (some complex computation) in z `div` x > > main = print (g (fun 1 2)) > > This is a classical example of why laziness gets in the way of > debugging. Now, when (f2 0) gets finally evaluated and throws a > divByZero error, x and y are nowhere to be found. > Since we do not have a real dynamic stack, it is difficult to say > where their values should be stored. The only place I can think of is > at the breakpoint itself, but then as Simon said this poses a serious > efficiency problem. Isn't that a case of premature optimization? I will happily compain about performance issues later, after the debugger turns out to be merely too slow!-) Currently, the issue is one of it not working as well as it could, which seems rather more important to me (think of it as infinitely too slow for my needs:-). Once it comes to performance issues (btw, is there a debugger home page on the wiki, where issues/FAQs like "why can't I have scope contexts" are documented?), an obvious compromise would be to state explicitly where to preserve scope information - something like: :break fun{x,y}/{f1,f2}/f2{x} would set a breakpoint on f2, associating with it information about the static scope context including only the named names (items between // define the path towards the name we want to break, level by level; additional names can be added in {} at each level), without affecting other parts of the program. Claus From colin at colina.demon.co.uk Mon Nov 24 14:24:55 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Nov 24 14:18:53 2008 Subject: Linking to Haskell code from an external program In-Reply-To: <492A9ADB.2070105@gmail.com> (Simon Marlow's message of "Mon\, 24 Nov 2008 12\:15\:23 +0000") References: <49216358.9060806@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> <492A9ADB.2070105@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> Colin Paul Adams wrote: >>>>>>> "Simon" == Simon Peyton-Jones >>>>>>> writes: >> Simon> It looks as if you are somehow failing to link your binary Simon> with package 'base'. (Are you using 'ghc' as your linker; Simon> you should be.) But others are better than I at this kind Simon> of stuff. >> >> I have base-4.0.0.0 specified. >> >> No, I am not using ghc as the linker. Since I am calling the >> Haskell routine from an Eiffel program, I don't see how I could >> do that with any sort of ease. Simon> I think you'll have to post complete instructions to Simon> reproduce the problem you're having; it's hard to piece it Simon> together from the information you've given. The problem Simon> will be in the details somewhere. It seems it was some complication when switching from 6.8 to 6.10. I didn't clean up properly. Links now, but I'm still getting the crash in the garbage collector. :-( -- Colin Adams Preston Lancashire From barney_stratford at fastmail.fm Mon Nov 24 17:15:53 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Mon Nov 24 17:09:41 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: <1227564953.16428.1286554165@webmail.messagingengine.com> There's good news and bad news. The good news is that the compilation of my shiny almost-new GHC is complete. The bad news is, it won't link. It's grumbling about ld: /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) has external relocation entries in non-writable section (__TEXT,__text) for symbols: ___gmpn_cmp ___gmpn_gcd_1 ___gmpz_fdiv_qr ___gmpz_init ___gmpz_tdiv_qr ___gmpz_com ___gmpz_xor ___gmpz_ior ___gmpz_and ___gmpz_divexact ___gmpz_tdiv_r ___gmpz_tdiv_q ___gmpz_gcd ___gmpz_mul ___gmpz_sub ___gmpz_add Looking through the archives, it seems like this is an old favourite bug rearing its ugly head again. The suggested remedy of commenting out the line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as that line isn't there anyway. The manpage for ld has an option "-read_only_relocs warning" that looks like it might suppress this problem, but I don't fully understand what it's doing. What would you suggest? Cheers, Barney. From naur at post11.tele.dk Mon Nov 24 17:41:48 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Mon Nov 24 17:36:23 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1227564953.16428.1286554165@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> Message-ID: <200811242341.50048.naur@post11.tele.dk> Hello, On Monday 24 November 2008 23:15, Barney Stratford wrote: > There's good news and bad news. The good news is that the compilation of > my shiny almost-new GHC is complete. The bad news is, it won't link. > It's grumbling about > > ld: > /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) > has external relocation entries in non-writable section (__TEXT,__text) > for symbols: > ___gmpn_cmp > ___gmpn_gcd_1 > ___gmpz_fdiv_qr > ___gmpz_init > ___gmpz_tdiv_qr > ___gmpz_com > ___gmpz_xor > ___gmpz_ior > ___gmpz_and > ___gmpz_divexact > ___gmpz_tdiv_r > ___gmpz_tdiv_q > ___gmpz_gcd > ___gmpz_mul > ___gmpz_sub > ___gmpz_add > > Looking through the archives, it seems like this is an old favourite bug > rearing its ugly head again. The suggested remedy of commenting out the > line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as > that line isn't there anyway. The manpage for ld has an option > "-read_only_relocs warning" that looks like it might suppress this > problem, but I don't fully understand what it's doing. > > What would you suggest? The heading seems to be: Your build is missing it's required GMP (GNU Multiple Precision) library which is used for the Haskell Integer type. Whether this information is enough to get you going again, I cannot tell, as I have no experience with your particular circumstances: There may be additional problems ahead getting this library installed and making sure that it gets referred from all the right places. But that seems to be the answer: Get GMP, install it, and make sure that linking and running Haskell code (not least GHC itself) have access. > > Cheers, > Barney. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Best regards Thorkil From barney_stratford at fastmail.fm Mon Nov 24 17:48:24 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Mon Nov 24 17:42:12 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <200811242341.50048.naur@post11.tele.dk> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> <200811242341.50048.naur@post11.tele.dk> Message-ID: <1227566904.23799.1286561457@webmail.messagingengine.com> > The heading seems to be: Your build is missing it's required GMP (GNU > Multiple Precision) library No, I have GMP installed, and it's correctly compiling against it. The issue isn't that these symbols are missing altogether, but rather that there's something wrong with them. It looks to me like it's identical to this bug afflicting 6.9: http://hackage.haskell.org/trac/ghc/ticket/2262 Cheers, Barney. From naur at post11.tele.dk Mon Nov 24 18:12:27 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Mon Nov 24 18:07:01 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1227566904.23799.1286561457@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <200811242341.50048.naur@post11.tele.dk> <1227566904.23799.1286561457@webmail.messagingengine.com> Message-ID: <200811250012.28554.naur@post11.tele.dk> Hello, On Monday 24 November 2008 23:48, Barney Stratford wrote: > > The heading seems to be: Your build is missing it's required GMP (GNU > > Multiple Precision) library > No, I have GMP installed, and it's correctly compiling against it. The > issue isn't that these symbols are missing altogether, but rather that > there's something wrong with them. It looks to me like it's identical to > this bug afflicting 6.9: http://hackage.haskell.org/trac/ghc/ticket/2262 Yes, you are right, I didn't address the real issue. Sorry, I don't really know what to do about this. > > Cheers, > Barney. > I notice, however, that the workaround for the issue that you referrred to (#2262) was to remove a line saying -fvia-C. That would, in most circumstances, be roughly the same as saying -fasm (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-codegen). I suggest that you look at http://hackage.haskell.org/trac/ghc/wiki/Building and in particular http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking for some inspiration. Best regards Thorkil From marlowsd at gmail.com Tue Nov 25 03:43:36 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 25 03:37:29 2008 Subject: Linking to Haskell code from an external program In-Reply-To: References: <49216358.9060806@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> <492A9ADB.2070105@gmail.com> Message-ID: <492BBAB8.2030404@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Marlow writes: > > Simon> Colin Paul Adams wrote: > >>>>>>> "Simon" == Simon Peyton-Jones > >>>>>>> writes: > >> > Simon> It looks as if you are somehow failing to link your binary > Simon> with package 'base'. (Are you using 'ghc' as your linker; > Simon> you should be.) But others are better than I at this kind > Simon> of stuff. > >> > >> I have base-4.0.0.0 specified. > >> > >> No, I am not using ghc as the linker. Since I am calling the > >> Haskell routine from an Eiffel program, I don't see how I could > >> do that with any sort of ease. > > Simon> I think you'll have to post complete instructions to > Simon> reproduce the problem you're having; it's hard to piece it > Simon> together from the information you've given. The problem > Simon> will be in the details somewhere. > > It seems it was some complication when switching from 6.8 to 6.10. I > didn't clean up properly. > > Links now, but I'm still getting the crash in the garbage collector. :-( Perhaps try reducing the example until the problem goes away, so we can see at which stage it gets introduced? Or can you boil down your example to something we can reproduce? Cheers, Simon From marlowsd at gmail.com Tue Nov 25 04:01:57 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 25 03:55:49 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1227564953.16428.1286554165@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> Message-ID: <492BBF05.70507@gmail.com> Barney Stratford wrote: > There's good news and bad news. The good news is that the compilation of > my shiny almost-new GHC is complete. The bad news is, it won't link. > It's grumbling about > > ld: > /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) > has external relocation entries in non-writable section (__TEXT,__text) > for symbols: > ___gmpn_cmp > ___gmpn_gcd_1 > ___gmpz_fdiv_qr > ___gmpz_init > ___gmpz_tdiv_qr > ___gmpz_com > ___gmpz_xor > ___gmpz_ior > ___gmpz_and > ___gmpz_divexact > ___gmpz_tdiv_r > ___gmpz_tdiv_q > ___gmpz_gcd > ___gmpz_mul > ___gmpz_sub > ___gmpz_add > > Looking through the archives, it seems like this is an old favourite bug > rearing its ugly head again. The suggested remedy of commenting out the > line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as > that line isn't there anyway. The manpage for ld has an option > "-read_only_relocs warning" that looks like it might suppress this > problem, but I don't fully understand what it's doing. > > What would you suggest? The workaround is almost certainly to build the RTS with -fasm. However, I'd be really pleased if someone could get to the bottom of this, so that we can fix the root cause. You can get a look at the .s file generated for PrimOps by saying $ cd rts $ make PrimOps.s (make sure you're still compiling via-C). Have a look at the references to those symbols, do they look suspicious at all? Try compiling the same module with -fasm, and compare the .s file with the via-C version. Also you could try poking around in the .o file with objdump, and see what relocation entries are being generated in both cases. Cheers, Simon From colin at colina.demon.co.uk Tue Nov 25 04:10:18 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Nov 25 04:04:07 2008 Subject: Linking to Haskell code from an external program In-Reply-To: <492BBAB8.2030404@gmail.com> (Simon Marlow's message of "Tue\, 25 Nov 2008 08\:43\:36 +0000") References: <49216358.9060806@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> <492A9ADB.2070105@gmail.com> <492BBAB8.2030404@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: >> Links now, but I'm still getting the crash in the garbage >> collector. :-( Simon> Perhaps try reducing the example until the problem goes Simon> away, so we can see at which stage it gets introduced? Or Simon> can you boil down your example to something we can Simon> reproduce? I've managed to solve it this morning. It was the way I was setting up argc and argv (badly) for the call to hs_init. Doing it properly means there are no longer any crashes with either Eiffel compliler. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Tue Nov 25 04:20:41 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 25 04:14:32 2008 Subject: GHCi debugger status In-Reply-To: <4B38ABE7843C4D8C8A1BC76320571745@cr3lt> 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> Message-ID: <492BC369.9010403@gmail.com> Claus Reinke wrote: >> fun x y = >> let f1 = ... (f2 x) ... -- f1 calls f2 >> f2 x = x * 2 >> in case x of >> 1 -> f2 0 >> _ -> f2 (f1 y) >> >> g x = let z = (some complex computation) in z `div` x >> >> main = print (g (fun 1 2)) >> >> This is a classical example of why laziness gets in the way of >> debugging. Now, when (f2 0) gets finally evaluated and throws a >> divByZero error, x and y are nowhere to be found. >> Since we do not have a real dynamic stack, it is difficult to say >> where their values should be stored. The only place I can think of is >> at the breakpoint itself, but then as Simon said this poses a serious >> efficiency problem. > > Isn't that a case of premature optimization? I will happily compain > about performance issues later, after the debugger turns out to be > merely too slow!-) No, it's a real problem. If we retained all the variables in scope at every breakpoint, GHCi would grow a whole bunch of space leaks. It's pretty important that adding debugging shouldn't change the space behaviour of the program. Of course, constant factors are fine, but we're talking asymptotic changes here. Now perhaps it would be possible to arrange that the extra variables are only retained if they are needed by a future breakpoint, but that's tricky (conditional stubbing of variables), and :trace effectively enables all breakpoints so you get the space leaks back. A similar argument applies to keeping the dynamic stack. The problem with the dynamic stack is that it doesn't look much like you expect, due to tail-calls. However, I think it would be good to let the user browse the dynamic stack (somehow, I haven't thought through how hard this would be). But what I'd really like is to give the user access to the *lexical* stack, by re-using the functionality that we already have for tracking the lexical stack in the profiler. See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack > (btw, is there a debugger home page > on the wiki, where issues/FAQs like "why can't I have scope contexts" > are documented?) No, please by all means start one. Cheers, Simon From barney_stratford at fastmail.fm Tue Nov 25 04:22:45 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Tue Nov 25 04:16:31 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <492BBF05.70507@gmail.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> <492BBF05.70507@gmail.com> Message-ID: <1227604965.24940.1286633457@webmail.messagingengine.com> > The workaround is almost certainly to build the RTS with -fasm. According to http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-codegen, -fasm is the default option anyway, or am I missing something here? It looks like this is an issue with the way Apple's version of gcc works. The gmp people are complaining bitterly, saying not to use a Mac at all. Perhaps the real issue here is that I should get a new computer. This old lady's got a bit wrinkly, but there's life in her yet. Barney. From malcolm.wallace at cs.york.ac.uk Tue Nov 25 04:23:21 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 25 04:18:08 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1227564953.16428.1286554165@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> Message-ID: <7AF06832-900D-4838-B53C-965E2DF2C662@cs.york.ac.uk> > The suggested remedy of commenting out the > line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as > that line isn't there anyway. In case it is not obvious from what other people have said, way back in the days of ghc-6.2, you got -fvia-C by default, whether it was specified on the command-line or not. To override via-C, you needed to explicitly choose the opposite (-fasm). With more recent versions of the compiler, the default flipped over to -fasm. Regards, Malcolm From barney_stratford at fastmail.fm Tue Nov 25 04:34:21 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Tue Nov 25 04:28:07 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <7AF06832-900D-4838-B53C-965E2DF2C662@cs.york.ac.uk> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> <7AF06832-900D-4838-B53C-965E2DF2C662@cs.york.ac.uk> Message-ID: <1227605661.26818.1286635785@webmail.messagingengine.com> > in the days of ghc-6.2, you got -fvia-C by default The thing is, 6.2 is building 6.8 just fine. Stage 1 is quite happy. The problem arises during linking of Stage 2 - ie 6.8 can't build itself. Cheers, Barney. From jwlato at gmail.com Tue Nov 25 05:28:10 2008 From: jwlato at gmail.com (John Lato) Date: Tue Nov 25 05:21:57 2008 Subject: Can't compile GHC 6.8.2 Message-ID: <9979e72e0811250228r61e63e92u616185ceefb1b2b@mail.gmail.com> > On Monday 24 November 2008 23:15, Barney Stratford wrote: >> There's good news and bad news. The good news is that the compilation of >> my shiny almost-new GHC is complete. The bad news is, it won't link. >> It's grumbling about >> >> ld: >> /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) >> has external relocation entries in non-writable section (__TEXT,__text) >> for symbols: >> ___gmpn_cmp ----------- etc. ---------- IMO, many apple dev. tools are insidiously broken (Apple's cpp is my current nemesis). Could you try using a different linker? That might be a sufficient workaround. You could call gcc with the correct arguments to complete the linking phase, rather than ld (or vice-versa). The only other suggestion I've seen is to re-order the exported functions before compiling the library. I don't know if this would help in your case, but it has worked with other libraries. That's the best I can suggest, anyway. John From marlowsd at gmail.com Tue Nov 25 06:02:50 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 25 05:56:40 2008 Subject: GHCi debugger status In-Reply-To: <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> References: <49268C2F.4040309@gmail.com> <492A7050.6090707@gmail.com><7EE0915016A84FBCAE3075123F47D2E3@cr3lt> <492A9763.8030100@gmail.com> <6BEC1E07BF4447B6BE42D2D27E0F70A3@cr3lt> Message-ID: <492BDB5A.5020100@gmail.com> Claus Reinke wrote: > Consider this code and session: > > f x y z | x | otherwise = z*y > ... > Things to note: > > - when reaching the breakpoint "in" 'f', one isn't actually in 'f' yet - > nothing > about 'f' can be inspected > - at no point in the session was 'x' inspectable, even though it is > likely to > contain information needed to understand 'f', especially when we are > deep in a recursion of a function that can be called from many places; > this information doesn't happen to be needed in the current branch, > but debugging the current expression always happens in a context, and > accessing information about this context is what the GHCi debugger > doesn't seem to support well > > In this particular example, the second item is most likely a bug (the > free variables of the guard were never offered for inspection). Indeed it was a bug, the same as #2740, and I've just fixed it. Thanks for boiling it down to a nice small example. Cheers, Simon From marlowsd at gmail.com Tue Nov 25 06:08:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 25 06:02:52 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <1227604965.24940.1286633457@webmail.messagingengine.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> <492BBF05.70507@gmail.com> <1227604965.24940.1286633457@webmail.messagingengine.com> Message-ID: <492BDCCB.2090504@gmail.com> Barney Stratford wrote: >> The workaround is almost certainly to build the RTS with -fasm. > According to > http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-codegen, > -fasm is the default option anyway, or am I missing something here? > > It looks like this is an issue with the way Apple's version of gcc > works. The gmp people are complaining bitterly, saying not to use a Mac > at all. Do you have a link to something describing the problem? I didn't turn up anything that looked directly relevant, only this: http://gmplib.org/macos.html which seems to suggest that problems can be worked around with flags to gcc. We don't use -fno-pic. Cheers, Simon From phercek at gmail.com Tue Nov 25 08:11:45 2008 From: phercek at gmail.com (Peter Hercek) Date: Tue Nov 25 08:05:47 2008 Subject: GHCi debugger status In-Reply-To: <492BC369.9010403@gmail.com> 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> Message-ID: Simon Marlow wrote: > A similar argument applies to keeping the dynamic stack. The problem > with the dynamic stack is that it doesn't look much like you expect, due > to tail-calls. Do you think people expect the tail-calls to add a stack frame to the dynamic stack or is there something more complicated? I would expect a tail-call to overwrite the last stack frame on the dynamic stack - just like imperative loops, which is what they correspond to. Dynamic stack should correspond closely to the stack which overflows when we get the "stack overflow exception". That is what I would expect. If somebody wants the history of tail-calls he can check the trace information, which should not be a problem especially if some filtering (like tracelocal) is possible. Peter. From claus.reinke at talk21.com Tue Nov 25 08:25:20 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Nov 25 08:19:12 2008 Subject: GHCi debugger status 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> Message-ID: <7A9B504362CA4256B62E8D75A3E35518@cr3lt> > No, it's a real problem. If we retained all the variables in scope at > every breakpoint, GHCi would grow a whole bunch of space leaks. It's > pretty important that adding debugging shouldn't change the space behaviour > of the program. Of course, constant factors are fine, but we're talking > asymptotic changes here. > > Now perhaps it would be possible to arrange that the extra variables are > only retained if they are needed by a future breakpoint, but that's tricky > (conditional stubbing of variables), and :trace effectively enables all > breakpoints so you get the space leaks back. 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. Whatever cost that involves, it is unavoidable if we want to be able to inspect parts of the lexical scope at the breakpoint, we'd have full control over the cost incurred, and at least we wouldn't have to keep modifying our sources to inspect different aspects of our code in a debugging session. Claus From barney_stratford at fastmail.fm Tue Nov 25 09:32:30 2008 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Tue Nov 25 09:26:30 2008 Subject: Can't compile GHC 6.8.2 In-Reply-To: <492BDCCB.2090504@gmail.com> References: <1227526015.21086.1286434575@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EE4B8@EA-EXMSG-C334.europe.corp.microsoft.com> <1227564953.16428.1286554165@webmail.messagingengine.com> <492BBF05.70507@gmail.com> <1227604965.24940.1286633457@webmail.messagingengine.com> <492BDCCB.2090504@gmail.com> Message-ID: <1227623550.6544.1286676061@webmail.messagingengine.com> > Do you have a link to something describing the problem? This might be relevant: I don't know. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14612 Further useful information. The problem doesn't manifest itself when compiling GHC 6.6, so the question is what parts of the runtime system changed in the meantime. The changes to rts/Linker.c are just refactorings and addition of 64-bit support. The only other place I can see where those things are mentioned is in rts/PrimOps.cmm. In the meantime, I'll try using a later GCC and see if that helps (assuming I can compile it!). Barney. From igloo at earth.li Tue Nov 25 10:00:01 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 25 09:53:48 2008 Subject: Future plans: unicode and line editing Message-ID: <20081125150001.GA12129@matrix.chaos.earth.li> Hi all, We've been weighing up the options to solve the recent problems that editline has given us, and we think that this is the best way forward: For 6.12: * http://hackage.haskell.org/trac/ghc/ticket/2811 Implement unicode support for text I/O (we've had this on the TODO list for some time now; it was slated for 6.10, but didn't make it) * http://hackage.haskell.org/trac/ghc/ticket/2812 Switch to using haskeline instead of editline Haskeline should be able to use the above unicode support, rather than the utf8-string package * http://hackage.haskell.org/trac/ghc/ticket/2813 Create (and ship with GHC) a utf8 bytestring-a-like I'm not sure if this is actually needed by either of the above, but it is certainly related, and something we want to do anyway We won't be trying to get any of the above into future 6.10 releases. However, for 6.10 you can use Judah's ghci-haskeline: http://code.haskell.org/~judah/ghci-haskeline/ which uses the GHC API and the haskeline package to implement the GHCi frontend. If you have any problems using ghci-haskeline, then it is likely that GHCi in 6.12 will have the same problems, so please let us know! Comments and criticisms welcomed! Thanks Ian From marlowsd at gmail.com Tue Nov 25 11:00:53 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 25 10:54:44 2008 Subject: GHCi debugger status In-Reply-To: <7A9B504362CA4256B62E8D75A3E35518@cr3lt> 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> Message-ID: <492C2135.6060306@gmail.com> Claus Reinke wrote: >> No, it's a real problem. If we retained all the variables in scope at >> every breakpoint, GHCi would grow a whole bunch of space leaks. It's >> pretty important that adding debugging shouldn't change the space >> behaviour of the program. Of course, constant factors are fine, but >> we're talking asymptotic changes here. >> >> Now perhaps it would be possible to arrange that the extra variables >> are only retained if they are needed by a future breakpoint, but >> that's tricky (conditional stubbing of variables), and :trace >> effectively enables all breakpoints so you get the space leaks back. > > 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). Cheers, Simon From bernd.holzmueller at ics-ag.de Tue Nov 25 16:09:15 2008 From: bernd.holzmueller at ics-ag.de (=?ISO-8859-15?Q?Bernd_Holzm=FCller?=) Date: Tue Nov 25 16:02:58 2008 Subject: How to reliably terminate a process Message-ID: <492C697B.1050308@ics-ag.de> Hi, I am writing an application on Windows XP using ghc 6.10.1 that manages test cases (same applies to ghc 6.8.3). For each selected test case, the application runs an executable associated with the test case using System.Process.runInteractiveCommand. These processes have to be aborted in some cases, for example, when their specified termination time is up. As I realized, however, aborting these processes using terminateProcess is not reliable. Most often, the processes do not terminate correctly but have to be killed from the Windows Task Manager. In some cases, the process still produces output - in particular if I apply getProcessExitCode on the process just killed. By the way: calling and killing the process from the shell with Ctrl-C successfully kills the process. Any advice on how to reliably terminate a process on Windows? Thanks, Bernd From dons at galois.com Tue Nov 25 16:28:48 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 25 16:22:31 2008 Subject: Future plans: unicode and line editing In-Reply-To: <20081125150001.GA12129@matrix.chaos.earth.li> References: <20081125150001.GA12129@matrix.chaos.earth.li> Message-ID: <20081125212848.GG14812@scytale.galois.com> igloo: > > Hi all, > > We've been weighing up the options to solve the recent problems that > editline has given us, and we think that this is the best way forward: > > For 6.12: > > * http://hackage.haskell.org/trac/ghc/ticket/2811 > Implement unicode support for text I/O > (we've had this on the TODO list for some time now; it was slated for > 6.10, but didn't make it) > > * http://hackage.haskell.org/trac/ghc/ticket/2812 > Switch to using haskeline instead of editline > Haskeline should be able to use the above unicode support, rather than > the utf8-string package > > * http://hackage.haskell.org/trac/ghc/ticket/2813 > Create (and ship with GHC) a utf8 bytestring-a-like > I'm not sure if this is actually needed by either of the above, but it > is certainly related, and something we want to do anyway > > > We won't be trying to get any of the above into future 6.10 releases. > However, for 6.10 you can use Judah's ghci-haskeline: > http://code.haskell.org/~judah/ghci-haskeline/ > which uses the GHC API and the haskeline package to implement the GHCi > frontend. > > If you have any problems using ghci-haskeline, then it is likely that > GHCi in 6.12 will have the same problems, so please let us know! > > > Comments and criticisms welcomed! Can we construct a set of tests that determines if a given line editing code base works to our satisfaction? -- Don From igloo at earth.li Tue Nov 25 17:59:27 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 25 17:53:17 2008 Subject: Future plans: unicode and line editing In-Reply-To: <20081125212848.GG14812@scytale.galois.com> References: <20081125150001.GA12129@matrix.chaos.earth.li> <20081125212848.GG14812@scytale.galois.com> Message-ID: <20081125225927.GA21459@matrix.chaos.earth.li> On Tue, Nov 25, 2008 at 01:28:48PM -0800, Donald Bruce Stewart wrote: > > Can we construct a set of tests that determines if a given line editing > code base works to our satisfaction? If you can make some tests then that would be great. You need to be careful though, e.g. input had better look like it is really coming from a terminal or the line editing library might behave differently. Thanks Ian From igloo at earth.li Tue Nov 25 18:03:02 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 25 17:56:48 2008 Subject: How to reliably terminate a process In-Reply-To: <492C697B.1050308@ics-ag.de> References: <492C697B.1050308@ics-ag.de> Message-ID: <20081125230302.GB21459@matrix.chaos.earth.li> On Tue, Nov 25, 2008 at 10:09:15PM +0100, Bernd Holzm?ller wrote: > > Any advice on how to reliably terminate a process on Windows? You can see how the timeout program in GHC's testsuite does this here: http://darcs.haskell.org/testsuite/timeout/timeout.hs Thanks Ian From s.clover at gmail.com Tue Nov 25 18:15:06 2008 From: s.clover at gmail.com (Sterling Clover) Date: Tue Nov 25 18:08:51 2008 Subject: How to reliably terminate a process In-Reply-To: <492C697B.1050308@ics-ag.de> References: <492C697B.1050308@ics-ag.de> Message-ID: Due to the way which runInteractiveCommand works (through spawning a shell), it is impossible to consistently terminate a process launched using it. If the process tries to read from stdin, then it will die properly -- however, last I checked, processes blocking on reading stdin from within runInteractiveCommand will cause bizarre memory leaks. runInteractiveProcess will work as you expect. For more information, see the bug report here: http://hackage.haskell.org/trac/ghc/ticket/2638 Regards, Sterl. On Tue, Nov 25, 2008 at 4:09 PM, Bernd Holzm?ller < bernd.holzmueller@ics-ag.de> wrote: > Hi, > > I am writing an application on Windows XP using ghc 6.10.1 that manages > test cases (same applies to ghc 6.8.3). For each selected test case, the > application runs an executable associated with the test case using > System.Process.runInteractiveCommand. These processes have to be aborted in > some cases, for example, when their specified termination time is up. As I > realized, however, aborting these processes using terminateProcess is not > reliable. Most often, the processes do not terminate correctly but have to > be killed from the Windows Task Manager. In some cases, the process still > produces output - in particular if I apply getProcessExitCode on the process > just killed. By the way: calling and killing the process from the shell with > Ctrl-C successfully kills the process. > > Any advice on how to reliably terminate a process on Windows? > > Thanks, > Bernd > _______________________________________________ > 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/20081125/914cef18/attachment-0001.htm From conal at conal.net Wed Nov 26 01:38:00 2008 From: conal at conal.net (Conal Elliott) Date: Wed Nov 26 01:31:45 2008 Subject: Exporting an #include from one package to another? In-Reply-To: <1227360665.7124.195.camel@localhost> References: <1227360665.7124.195.camel@localhost> Message-ID: wonderful! i'll try it out. thanks, duncan. On Sat, Nov 22, 2008 at 5:31 AM, Duncan Coutts wrote: > On Fri, 2008-11-21 at 18:28 -0800, Conal Elliott wrote: > > Is there a way to package up an #include like to share across (be > > #include'd into) various other haskell packages? > > > > I have some standard templates for type class instances that I can't > > define as instances without creating lots of overlapping instances. I > > can write an include file easily enough, but I don't know how to get > > other packages to find and #include that include file. > > Yes. This is partly what the "install-includes:" field in the .cabal > file is for. > > Each client has to #include it explicitly of course, but the include > search path should be set up to make that work. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081125/288b0050/attachment.htm From waldmann at imn.htwk-leipzig.de Wed Nov 26 08:57:52 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Nov 26 08:51:53 2008 Subject: Grammar for (Glasgow) Haskell References: Message-ID: waldmann@afa:~/software/haskell/ghc-6.10.1> find . -name "*.y*" ./compiler/main/ParsePkgConf.y.source ./compiler/parser/ParserCore.y.source ./compiler/parser/Parser.y.pp.source ./compiler/parser/HaddockParse.y.source ... From jason.dusek at gmail.com Wed Nov 26 09:17:02 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Nov 26 09:10:46 2008 Subject: Linking to Haskell code from an external program In-Reply-To: References: <49216358.9060806@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> <492A9ADB.2070105@gmail.com> <492BBAB8.2030404@gmail.com> Message-ID: <42784f260811260617h2cd0f9a9sa889558da71cec9a@mail.gmail.com> Colin Paul Adams wrote: > I've managed to solve it this morning. It was the way I was > setting up argc and argv (badly) for the call to hs_init. > Doing it properly means there are no longer any crashes with > either Eiffel compliler. What is the "bad" way to set them up? -- _jsn From colin at colina.demon.co.uk Wed Nov 26 09:29:27 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Nov 26 09:23:27 2008 Subject: Linking to Haskell code from an external program In-Reply-To: <42784f260811260617h2cd0f9a9sa889558da71cec9a@mail.gmail.com> (Jason Dusek's message of "Wed\, 26 Nov 2008 06\:17\:02 -0800") References: <49216358.9060806@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3319241A16F@EA-EXMSG-C334.europe.corp.microsoft.com> <492A9ADB.2070105@gmail.com> <492BBAB8.2030404@gmail.com> <42784f260811260617h2cd0f9a9sa889558da71cec9a@mail.gmail.com> Message-ID: >>>>> "Jason" == Jason Dusek writes: Jason> Colin Paul Adams wrote: >> I've managed to solve it this morning. It was the way I was >> setting up argc and argv (badly) for the call to hs_init. >> Doing it properly means there are no longer any crashes with >> either Eiffel compliler. Jason> What is the "bad" way to set them up? Any way that doesn't conform to the specification, I guess. So it was all my fault. (I haven't done any significant C programming for at least 6 years. And I hate it these days.) -- Colin Adams Preston Lancashire From alios at alios.org Wed Nov 26 09:30:15 2008 From: alios at alios.org (Markus Barenhoff) Date: Wed Nov 26 09:25:58 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems Message-ID: <20081126143015.GA28186@beteigeuze.alios.net> Hi! Because the ports seem not to get updated, I tried to compile ghc 6.10.1 under freebsd 7 on amd64 myself. For compiling I first used the ports ghc version (6.8.3) and then, in a second try I used the self build 6.10.1 to build it again. I added building of api docs with: $ echo "HADDOCK_DOCS = YES" >> mk/build.mk I configured it with a simple ./configure and not more options. The compiler seems to work well on both versions. But if i try to start ghci I get the following: ---- snip ---- $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: Unable to mmap() for jump islands Loading package ghc-prim ... ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-freebsd): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---- snip ---- It looks he has some kind of library loading problems? Any ideas? 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/20081126/6267359e/attachment.bin From allbery at ece.cmu.edu Thu Nov 27 00:52:24 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Nov 27 00:46:15 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <20081126143015.GA28186@beteigeuze.alios.net> References: <20081126143015.GA28186@beteigeuze.alios.net> Message-ID: On 2008 Nov 26, at 9:30, Markus Barenhoff wrote: > Because the ports seem not to get updated, I tried to compile ghc > 6.10.1 > under freebsd 7 on amd64 myself. For compiling I first used the > ports ghc The tree's not being updated because 64-bit on freebsd doesn't work yet, as you found. I believe a fix for the mmap() problem has been committed for the upcoming 6.10.2. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From phercek at gmail.com Thu Nov 27 03:19:00 2008 From: phercek at gmail.com (Peter Hercek) Date: Thu Nov 27 03:12:57 2008 Subject: simple ghci debugger question Message-ID: Is there a way to redirect output of a ghci debugger command so that I can process it with a (ghci) script before it is displayed? Peter. From simonpj at microsoft.com Thu Nov 27 04:29:19 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 27 04:23:12 2008 Subject: Fun with type functions Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33281447D7F@EA-EXMSG-C334.europe.corp.microsoft.com> Friends GHC has embodied data type families since 6.8, and now type synonym families (aka type functions) in 6.10. However, apart from our initial papers there isn't much published material about how to *use* type families. But that hasn't stopped you: quite a few people are using them already, and of course there is a rich seam of work on using functional dependencies to express type-level computation. Ken Shan and Oleg Kiselyov and I are collaborating to write a paper for an upcoming workshop, under the general rubric of "Fun with type functions" (in homage to Thomas Hallgren's paper "Fun with functional dependencies" and Ralf Hinze's paper "Fun with phantom types"). So this message is to ask you: can you tell us about the most persuasive, fun application you've encountered, for type families or functional dependencies? Simple is good. It doesn't have to be elaborate: just something that does something useful you could not have done otherwise. Pointers to email threads are fine. Don't assume we already know about them (even if we participated in the thread :-) Part of what we're interested in is that *you* found the example compelling. Many thanks Simon, Ken, Oleg PS: I'm broadcasting this message to GHC-users and Haskell-cafe, but to avoid deluging ghc-users, please reply just to us and Haskell cafe. (Interested ghc-users can follow the threads there from the archives if they want.) From marlowsd at gmail.com Thu Nov 27 04:46:20 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 27 04:40:08 2008 Subject: How to reliably terminate a process In-Reply-To: References: <492C697B.1050308@ics-ag.de> Message-ID: <492E6C6C.10801@gmail.com> Sterling Clover wrote: > Due to the way which runInteractiveCommand works (through spawning a > shell), it is impossible to consistently terminate a process launched > using it. If the process tries to read from stdin, then it will die > properly -- however, last I checked, processes blocking on reading stdin > from within runInteractiveCommand will cause bizarre memory leaks. > > runInteractiveProcess will work as you expect. The documentation for terminateProcess now includes this: -- Note: on Windows, if the process was a shell command created by -- 'createProcess' with 'shell', or created by 'runCommand' or -- 'runInteractiveCommand', then 'terminateProcess' will only -- terminate the shell, not the command itself. On Unix systems, both -- processes are in a process group and will be terminated together. Cheers, Simon From marlowsd at gmail.com Thu Nov 27 04:49:05 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 27 04:42:50 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: References: <20081126143015.GA28186@beteigeuze.alios.net> Message-ID: <492E6D11.1090102@gmail.com> Brandon S. Allbery KF8NH wrote: > On 2008 Nov 26, at 9:30, Markus Barenhoff wrote: >> Because the ports seem not to get updated, I tried to compile ghc 6.10.1 >> under freebsd 7 on amd64 myself. For compiling I first used the ports ghc > > The tree's not being updated because 64-bit on freebsd doesn't work yet, > as you found. I believe a fix for the mmap() problem has been committed > for the upcoming 6.10.2. Yes. http://hackage.haskell.org/trac/ghc/ticket/2063 The patches haven't been merged into stable yet, but you can grab a HEAD snapshot and try that instead - we'd appreciate the testing. Cheers, Simon From marlowsd at gmail.com Thu Nov 27 04:50:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 27 04:44:01 2008 Subject: simple ghci debugger question In-Reply-To: References: Message-ID: <492E6D58.2000605@gmail.com> Peter Hercek wrote: > Is there a way to redirect output of a ghci debugger command > so that I can process it with a (ghci) script before it is > displayed? Claus had some GHCi macros for doing this sort of thing. Claus? Cheers, Simon From alios at alios.org Thu Nov 27 06:32:16 2008 From: alios at alios.org (Markus Barenhoff) Date: Thu Nov 27 06:26:49 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <492E6D11.1090102@gmail.com> References: <20081126143015.GA28186@beteigeuze.alios.net> <492E6D11.1090102@gmail.com> Message-ID: <20081127113216.GA92698@beteigeuze.alios.net> On Thu 27.11 09:49, Simon Marlow wrote: > Brandon S. Allbery KF8NH wrote: > >On 2008 Nov 26, at 9:30, Markus Barenhoff wrote: > >>Because the ports seem not to get updated, I tried to compile ghc 6.10.1 > >>under freebsd 7 on amd64 myself. For compiling I first used the ports ghc > > > >The tree's not being updated because 64-bit on freebsd doesn't work yet, > >as you found. I believe a fix for the mmap() problem has been committed > >for the upcoming 6.10.2. > > Yes. > > http://hackage.haskell.org/trac/ghc/ticket/2063 > > The patches haven't been merged into stable yet, but you can grab a HEAD > snapshot and try that instead - we'd appreciate the testing. 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 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/20081127/97f41381/attachment.bin From claus.reinke at talk21.com Thu Nov 27 06:56:27 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Nov 27 06:50:12 2008 Subject: simple ghci debugger question References: <492E6D58.2000605@gmail.com> Message-ID: > Peter Hercek wrote: >> Is there a way to redirect output of a ghci debugger command >> so that I can process it with a (ghci) script before it is >> displayed? > > Claus had some GHCi macros for doing this sort of thing. Claus? Sure, recorded here (sections 4/5, but the rest of the page should also be better known; if only so that others would add their tips and tricks as well; hmm, ghc-haskeline isn't there, yet): http://www.haskell.org/haskellwiki/GHC/GHCi#Using_.ghci.2C_a_mini-tutorial Some of the items mentioned in the tutorial email have since been added to GHCi, but I still use the :grep, :redir, and :ghc_pkg stuff; :redir(Err) only works properly if -fbreak-on-exceptions is not switched on, haven't investigated workarounds yet. There is also a stub page for the GHCi debugger, nothing on it yet: http://www.haskell.org/haskellwiki/GHC/GHCi_debugger Claus From dominic.steinitz at blueyonder.co.uk Fri Nov 28 02:28:23 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri Nov 28 02:33:39 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC References: b97f58860811211910p194d56e2y1f5bf52de5371258@mail.gmail.com Message-ID: <492F9D97.5090507@blueyonder.co.uk> > In my case, we had rigid type signatures all over the place. The > wiki document says that the type must be rigid at the point of the > match. I guess that's what we were violating. If the code I posted > isn't supposed to type check then I would like to report, as user > feedback, that GADTs have become unwieldy. I'm now running into this problem big time on my existing test harness (I'd previously checked the main code and that worked - see http://www.haskell.org/pipermail/glasgow-haskell-users/2008-November/016160.html). > > I grant that it's less convenient than one would like. The > difficulty is that GADTs get you into territory where it's easy to > write programs that have multiple *incomparable* types. That is, > there is no "best" type (unlike Hindley-Milner). So we pretty much > have to ask the programmer to express the type. > > Once we are in that territory, we need to give simple rules that say > when a type signature is needed. I know that I have not yet found a > way to express these rules -- perhaps GHC's users can help. My > initial shot is > http://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching > > I couldn't figure out how to fix that code by just adding a type > signature. I've read this and I couldn't figure it out either. I've tried the heuristic and it works fine for some cases but not others: > arbitrarySeq :: Sequence a -> Gen RepSeqVal > arbitrarySeq Nil = > return (RepSeqVal Nil Empty) > arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) = > do u <- arbitraryType t > us <- arbitrarySeq ts > case u of > RepTypeVal a v -> > case us of > RepSeqVal bs vs -> > return (RepSeqVal (Cons (CTMandatory (NamedType n i a)) bs) (v:*:vs)) > QuickTest.lhs:240:13: > GADT pattern match in non-rigid context for `Nil' > Solution: add a type signature > In the pattern: Nil > In the definition of `arbitrarySeq': > arbitrarySeq Nil = return (RepSeqVal Nil Empty) > *Rename> :t Nil > Nil :: Sequence Nil So this fixes the first case: > arbitrarySeq :: Sequence a -> Gen RepSeqVal > arbitrarySeq (Nil :: Sequence Nil) = > return (RepSeqVal Nil Empty) But not the second case: > QuickTest.lhs:242:14: > GADT pattern match in non-rigid context for `Cons' > Solution: add a type signature > In the pattern: Cons (CTMandatory (NamedType n i t)) ts > In the definition of `arbitrarySeq': > arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) > = do u <- arbitraryType t > us <- arbitrarySeq ts > case u of RepTypeVal a v -> ... And now I'm stuck: > *Rename> :t Cons > Cons :: ComponentType a -> Sequence l -> Sequence (a :*: l) What type should I give the Cons pattern? If I try the heuristic: > arbitrarySeq ((Cons (CTMandatory (NamedType n i t)) ts) :: Int) = the the compiler suggests > QuickTest.lhs:242:14: > Couldn't match expected type `Sequence a' > against inferred type `Int' but trying > arbitrarySeq ((Cons (CTMandatory (NamedType n i t)) ts) :: Sequence a) = gives > QuickTest.lhs:242:68: Not in scope: type variable `a' > > Did you try giving a type signature to the (entire) case expression, > as I suggested? That should do it. > I'm not sure what this means or how to do it. Can you give an example or is it buried in some earlier email? I will go and have another look. > I urge you to consider designing a modified or new syntactic form for > working with GADT pattern matches. The quasi-dependent typing that > GADTs give developers is very powerful and it would seem that GHC > Haskell with GADTs is as close to dependent typing that developers > writing "real-world" software can get. I know of no other production > ready compilers that provide dependent or close to dependent typing. > Dependent typing seems to be a growing area of interest. For these > reasons I think it's important for GHC to focus on making them > pleasanter to work with again; even if it means adding to the > language again. > > If I knew how to do that, I'd love to. Here's one idea you might not > like: restrict GADT matching to function definitions only (not case > expressions), and require a type signature for such pattern matches. > That wouldn't require adding new stuff. But GHC's current story is a > bit more flexible. > > I also feel that the type errors given when working with existential > types, especially GADTs with existentials, are confusing. I think I am using existential types to test GADT code. See http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no longer works with 6.10.1. > mostly because the types of the sub-expressions in the program are > not visible to the user. More introspection into the inferred types > would help users. I have some ideas on how to improve this, what the > output should look like and I would like to implement it too, but I > haven't had a chance to start a prototype yet. > > I agree they are confusing. I always encourage people to suggest > alternative wording for an error message that would make it less > confusing (leaving aside how feasible or otherwise it'd be to > generate such wording). So next time you are confused but figure it > out, do suggest an alternative. > > Thanks for helping. You can't develop a good user interface without > articulate and reflective users. Thanks. > From dominic.steinitz at blueyonder.co.uk Fri Nov 28 03:20:21 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri Nov 28 03:25:35 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: <492F9D97.5090507@blueyonder.co.uk> References: b97f58860811211910p194d56e2y1f5bf52de5371258@mail.gmail.com <492F9D97.5090507@blueyonder.co.uk> Message-ID: <492FA9C5.9040409@blueyonder.co.uk> Ignore my last email. I was accidentally using > The Glorious Glasgow Haskell Compilation System, version 6.9.20080616 Mind you I am still having problems just not the same ones. I'll report back later. Dominic. From simonpj at microsoft.com Fri Nov 28 03:47:03 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 28 03:40:43 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: <492F9D97.5090507@blueyonder.co.uk> References: b97f58860811211910p194d56e2y1f5bf52de5371258@mail.gmail.com <492F9D97.5090507@blueyonder.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33281448383@EA-EXMSG-C334.europe.corp.microsoft.com> | > I also feel that the type errors given when working with existential | > types, especially GADTs with existentials, are confusing. I think | | I am using existential types to test GADT code. See | http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no longer | works with 6.10.1. Really? I've just compiled that entire page with 6.10.1, and it was fine, except that I had to add a type signature for prettyRep. No problems there. Simon From dominic.steinitz at blueyonder.co.uk Fri Nov 28 03:49:35 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri Nov 28 03:54:42 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33281448383@EA-EXMSG-C334.europe.corp.microsoft.com> References: b97f58860811211910p194d56e2y1f5bf52de5371258@mail.gmail.com <492F9D97.5090507@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C33281448383@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <492FB09F.5040105@blueyonder.co.uk> Simon Peyton-Jones wrote: > | > I also feel that the type errors given when working with existential > | > types, especially GADTs with existentials, are confusing. I think > | > | I am using existential types to test GADT code. See > | http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no longer > | works with 6.10.1. > > Really? I've just compiled that entire page with 6.10.1, and it was fine, except that I had to add a type signature for prettyRep. No problems there. > > Simon > > Sorry I inadvertently used an old copy of ghc. Dominic. From simonpj at microsoft.com Fri Nov 28 04:19:19 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 28 04:12:59 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: <492F9D97.5090507@blueyonder.co.uk> References: b97f58860811211910p194d56e2y1f5bf52de5371258@mail.gmail.com <492F9D97.5090507@blueyonder.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C332814483C1@EA-EXMSG-C334.europe.corp.microsoft.com> | > arbitrarySeq :: Sequence a -> Gen RepSeqVal | > arbitrarySeq Nil = | > return (RepSeqVal Nil Empty) | > arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) = | > do u <- arbitraryType t | > us <- arbitrarySeq ts | > case u of | > RepTypeVal a v -> | > case us of | > RepSeqVal bs vs -> | > return (RepSeqVal (Cons (CTMandatory (NamedType n i a)) bs) (v:*:vs)) | | | > QuickTest.lhs:240:13: | > GADT pattern match in non-rigid context for `Nil' | > Solution: add a type signature | > In the pattern: Nil | > In the definition of `arbitrarySeq': | > arbitrarySeq Nil = return (RepSeqVal Nil Empty) That looks odd to me. But it's hard to help without having the code. If you send it I'll try to help. | > Did you try giving a type signature to the (entire) case expression, | > as I suggested? That should do it. | > | | I'm not sure what this means or how to do it. Can you give an example or | is it buried in some earlier email? I will go and have another look. I mean replace (case blah of { ... }) by (case blah of { ... }) :: type-sig That is, attach a type signature to the case expression itself. Does that help at least explain what the sentence means? If so would you like to clarify the wiki advice? Thanks Simon From dominic.steinitz at blueyonder.co.uk Fri Nov 28 04:12:59 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri Nov 28 04:18:11 2008 Subject: GADT Type Checking GHC 6.10 versus older GHC In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C332814483C1@EA-EXMSG-C334.europe.corp.microsoft.com> References: b97f58860811211910p194d56e2y1f5bf52de5371258@mail.gmail.com <492F9D97.5090507@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C332814483C1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <492FB61B.70506@blueyonder.co.uk> Simon Peyton-Jones wrote: > | > arbitrarySeq :: Sequence a -> Gen RepSeqVal > | > arbitrarySeq Nil = > | > return (RepSeqVal Nil Empty) > | > arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) = > | > do u <- arbitraryType t > | > us <- arbitrarySeq ts > | > case u of > | > RepTypeVal a v -> > | > case us of > | > RepSeqVal bs vs -> > | > return (RepSeqVal (Cons (CTMandatory (NamedType n i a)) bs) (v:*:vs)) > | > | > | > QuickTest.lhs:240:13: > | > GADT pattern match in non-rigid context for `Nil' > | > Solution: add a type signature > | > In the pattern: Nil > | > In the definition of `arbitrarySeq': > | > arbitrarySeq Nil = return (RepSeqVal Nil Empty) > > That looks odd to me. But it's hard to help without having the code. If you send it I'll try to help. > > | > Did you try giving a type signature to the (entire) case expression, > | > as I suggested? That should do it. > | > > | > | I'm not sure what this means or how to do it. Can you give an example or > | is it buried in some earlier email? I will go and have another look. > > I mean replace > (case blah of { ... }) > by > (case blah of { ... }) :: type-sig > > That is, attach a type signature to the case expression itself. Does that help at least explain what the sentence means? If so would you like to clarify the wiki advice? > > Thanks > > Simon > > Simon, I'm sorry to have put you to so much trouble by accidentally using an old version of ghc I must have had lying around. As penance, I will go and update the wiki with what I have learnt. Dominic. From marlowsd at gmail.com Fri Nov 28 04:42:02 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 28 04:35:45 2008 Subject: ghc 6.10.1 on freebsd 7 amd64 - ghci problems In-Reply-To: <20081127113216.GA92698@beteigeuze.alios.net> References: <20081126143015.GA28186@beteigeuze.alios.net> <492E6D11.1090102@gmail.com> <20081127113216.GA92698@beteigeuze.alios.net> Message-ID: <492FBCEA.4090406@gmail.com> Markus Barenhoff wrote: > On Thu 27.11 09:49, Simon Marlow wrote: >> Brandon S. Allbery KF8NH wrote: >>> On 2008 Nov 26, at 9:30, Markus Barenhoff wrote: >>>> Because the ports seem not to get updated, I tried to compile ghc 6.10.1 >>>> under freebsd 7 on amd64 myself. For compiling I first used the ports ghc >>> The tree's not being updated because 64-bit on freebsd doesn't work yet, >>> as you found. I believe a fix for the mmap() problem has been committed >>> for the upcoming 6.10.2. >> Yes. >> >> http://hackage.haskell.org/trac/ghc/ticket/2063 >> >> The patches haven't been merged into stable yet, but you can grab a HEAD >> snapshot and try that instead - we'd appreciate the testing. > > 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?). 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? Also you could try doing as the error message suggests, and specify a different address. e.g. ghci +RTS -xm30000000 ghci +RTS -xm50000000 for 0.75 and 1.25GB respectively. Cheers, Simon From ndmitchell at gmail.com Fri Nov 28 04:47:55 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Nov 28 04:41:34 2008 Subject: cross module optimization issues In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> Hi I've talked to John a bit, and discussed test cases etc. I've tracked this down a little way. Given the attached file, compiling witih SHORT_EXPORT_LIST makes the code go _slower_. By exporting the "print_lines" function the code doubles in speed. This runs against everything I was expecting, and that Simon has described. Taking a look at the .hi files for the two alternatives, there are two differences: 1) In the faster .hi file, the body of print_lines is exported. This is reasonable and expected. 2) In the faster .hi file, there are additional specialisations, which seemingly have little/nothing to do with print_lines, but are omitted if it is not exported: "SPEC >>= [GHC.IOBase.IO]" ALWAYS forall @ el $dMonad :: GHC.Base.Monad GHC.IOBase.IO Sound.IterateeM.>>= @ GHC.IOBase.IO @ el $dMonad = Sound.IterateeM.a `cast` (forall el1 a b. Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO a -> (a -> Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO b) -> trans (sym ((GHC.IOBase.:CoIO) (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO b))) (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO b))) @ el "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el $dMonad :: GHC.Base.Monad GHC.IOBase.IO Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad = Sound.IterateeM.$s$f2 @ el "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el $dMonad :: GHC.Base.Monad GHC.IOBase.IO Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad = Sound.IterateeM.$s$f21 @ el "SPEC Sound.IterateeM.liftI [GHC.IOBase.IO]" ALWAYS forall @ el @ a $dMonad :: GHC.Base.Monad GHC.IOBase.IO Sound.IterateeM.liftI @ GHC.IOBase.IO @ el @ a $dMonad = Sound.IterateeM.$sliftI @ el @ a "SPEC return [GHC.IOBase.IO]" ALWAYS forall @ el $dMonad :: GHC.Base.Monad GHC.IOBase.IO Sound.IterateeM.return @ GHC.IOBase.IO @ el $dMonad = Sound.IterateeM.a7 `cast` (forall el1 a. a -> trans (sym ((GHC.IOBase.:CoIO) (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO a))) (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO a))) @ el My guess is that these cause the slowdown - but is there any reason that print_lines not being exported should cause them to be omitted? All these tests were run on GHC 6.10.1 with -O2. Thanks Neil On Fri, Nov 21, 2008 at 10:33 AM, Simon Peyton-Jones wrote: > | This project is based on Oleg's Iteratee code; I started using his > | IterateeM.hs and Enumerator.hs files and added my own stuff to > | Enumerator.hs (thanks Oleg, great work as always). When I started > | cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my > | minimal test case increased from 19s to 43s. > | > | I've found two factors that contributed. When I was cleaning up, I > | also removed a bunch of unused functions from IterateeM.hs (some of > | the test functions and functions specific to his running example of > | HTTP encoding). When I added those functions back in, and added > | INLINE pragmas to the exported functions in MyEnum.hs, I got the > | performance back. > | > | In general I hadn't added export lists to the modules yet, so all > | functions should have been exported. > > I'm totally snowed under with backlog from my recent absence, so I can't look at this myself, but if anyone else wants to I'd be happy to support with advice and suggestions. > > In general, having an explicit export list is good for performance. I typed an extra section in the GHC performance resource http://haskell.org/haskellwiki/Performance/GHC to explain why. In general that page is where we should document user advice for performance in GHC. > > I can't explain why *adding* unused functions would change performance though! > > Simon > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: IterateeM.hs Type: text/x-haskell Size: 26371 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081128/18e27ff6/IterateeM-0001.bin From marlowsd at gmail.com Fri Nov 28 04:51:12 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 28 04:44:52 2008 Subject: GHCi debugger status In-Reply-To: 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> Message-ID: <492FBF10.5010406@gmail.com> Peter Hercek wrote: > Simon Marlow wrote: >> A similar argument applies to keeping the dynamic stack. The problem >> with the dynamic stack is that it doesn't look much like you expect, >> due to tail-calls. > > Do you think people expect the tail-calls to add a stack frame to the > dynamic stack or is there something more complicated? Right, I think they expect exactly that, and it'll confuse people that some stack frames are "missing". Often it's not clear which calls are tail-calls and which are not. Mind you, I think the fact that it's a dynamic call stack rather than a lexical call stack is likely to confuse the same set of users even more. > I would expect a tail-call to overwrite the last stack frame on the > dynamic stack - just like imperative loops, which is what they > correspond to. Dynamic stack should correspond closely to the stack > which overflows when we get the "stack overflow exception". That is what > I would expect. Fair enough - that at least is a data point suggesting that providing the dynamic call stack with no special provision for tail-calls would be useful to some people. Cheers, Simon From simonpj at microsoft.com Fri Nov 28 05:31:25 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 28 05:25:04 2008 Subject: cross module optimization issues In-Reply-To: <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33281448470@EA-EXMSG-C334.europe.corp.microsoft.com> The specialisations are indeed caused (indirectly) by the presence of print_lines. If print_lines is dead code (as it is when print_lines is not exported), then there are no calls to the overloaded functions at these specialised types, and so you don't get the specialised versions. You can get specialised versions by a SPECIALISE pragma, or SPECIALISE INSTANCE Does that make sense? Simon | -----Original Message----- | From: Neil Mitchell [mailto:ndmitchell@gmail.com] | Sent: 28 November 2008 09:48 | To: Simon Peyton-Jones | Cc: John Lato; glasgow-haskell-users@haskell.org; Don Stewart | Subject: Re: cross module optimization issues | | Hi | | I've talked to John a bit, and discussed test cases etc. I've tracked | this down a little way. | | Given the attached file, compiling witih SHORT_EXPORT_LIST makes the | code go _slower_. By exporting the "print_lines" function the code | doubles in speed. This runs against everything I was expecting, and | that Simon has described. | | Taking a look at the .hi files for the two alternatives, there are two | differences: | | 1) In the faster .hi file, the body of print_lines is exported. This | is reasonable and expected. | | 2) In the faster .hi file, there are additional specialisations, which | seemingly have little/nothing to do with print_lines, but are omitted | if it is not exported: | | "SPEC >>= [GHC.IOBase.IO]" ALWAYS forall @ el | $dMonad :: GHC.Base.Monad GHC.IOBase.IO | Sound.IterateeM.>>= @ GHC.IOBase.IO @ el $dMonad | = Sound.IterateeM.a | `cast` | (forall el1 a b. | Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO a | -> (a -> Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO b) | -> trans | (sym ((GHC.IOBase.:CoIO) | (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO b))) | (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO b))) | @ el | "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el | $dMonad :: | GHC.Base.Monad GHC.IOBase.IO | Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad | = Sound.IterateeM.$s$f2 @ el | "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el | $dMonad :: | GHC.Base.Monad GHC.IOBase.IO | Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad | = Sound.IterateeM.$s$f21 @ el | "SPEC Sound.IterateeM.liftI [GHC.IOBase.IO]" ALWAYS forall @ el | @ a | $dMonad :: | GHC.Base.Monad GHC.IOBase.IO | Sound.IterateeM.liftI @ GHC.IOBase.IO @ el @ a $dMonad | = Sound.IterateeM.$sliftI @ el @ a | "SPEC return [GHC.IOBase.IO]" ALWAYS forall @ el | $dMonad :: GHC.Base.Monad | GHC.IOBase.IO | Sound.IterateeM.return @ GHC.IOBase.IO @ el $dMonad | = Sound.IterateeM.a7 | `cast` | (forall el1 a. | a | -> trans | (sym ((GHC.IOBase.:CoIO) | (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO a))) | (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO a))) | @ el | | My guess is that these cause the slowdown - but is there any reason | that print_lines not being exported should cause them to be omitted? | | All these tests were run on GHC 6.10.1 with -O2. | | Thanks | | Neil | | | On Fri, Nov 21, 2008 at 10:33 AM, Simon Peyton-Jones | wrote: | > | This project is based on Oleg's Iteratee code; I started using his | > | IterateeM.hs and Enumerator.hs files and added my own stuff to | > | Enumerator.hs (thanks Oleg, great work as always). When I started | > | cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my | > | minimal test case increased from 19s to 43s. | > | | > | I've found two factors that contributed. When I was cleaning up, I | > | also removed a bunch of unused functions from IterateeM.hs (some of | > | the test functions and functions specific to his running example of | > | HTTP encoding). When I added those functions back in, and added | > | INLINE pragmas to the exported functions in MyEnum.hs, I got the | > | performance back. | > | | > | In general I hadn't added export lists to the modules yet, so all | > | functions should have been exported. | > | > I'm totally snowed under with backlog from my recent absence, so I can't look at this | myself, but if anyone else wants to I'd be happy to support with advice and suggestions. | > | > In general, having an explicit export list is good for performance. I typed an extra section | in the GHC performance resource http://haskell.org/haskellwiki/Performance/GHC to explain why. | In general that page is where we should document user advice for performance in GHC. | > | > I can't explain why *adding* unused functions would change performance though! | > | > Simon | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > From phercek at gmail.com Fri Nov 28 06:09:56 2008 From: phercek at gmail.com (Peter Hercek) Date: Fri Nov 28 06:03:47 2008 Subject: GHCi debugger status In-Reply-To: <492FBF10.5010406@gmail.com> 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> <492FBF10.5010406@gmail.com> Message-ID: Simon Marlow wrote: > Peter Hercek wrote: >> Simon Marlow wrote: >>> A similar argument applies to keeping the dynamic stack. The problem >>> with the dynamic stack is that it doesn't look much like you expect, >>> due to tail-calls. >> >> Do you think people expect the tail-calls to add a stack frame to the >> dynamic stack or is there something more complicated? > > Right, I think they expect exactly that, and it'll confuse people that > some stack frames are "missing". Often it's not clear which calls are > tail-calls and which are not. Mind you, I think the fact that it's a > dynamic call stack rather than a lexical call stack is likely to confuse > the same set of users even more. That is a good point, I might not see at the first look whether it is a tail call or not. Which reminds me that if it is implemented the way I expected then stack frames which are tail calls should be marked that way so that it is possible to see at the first look whether the given stack frame is a tail-call or not. If it will be a lexical call stack I'm curious how the pruning will be done so that we do not miss stack frames when we return from some code which corresponds to an imperative loop. Maybe a top limit on the number of stored lexical frames in one imperative (call-recursive) frame? From my point of view this could work well enough if it can print something like "and here there were some lexical frames pruned and we are going one dynamic frame higher". My reasons why I want to see it with tail-calls collapsed into one stack frame is that I need debugger to figure out why something does not work so I should see what it looks like close to the execution model where the bugs actually present themselves. I believe that collapsed tail-calls is not such a big deal if there is a way to filter trace history (like tracelocal idea or something similar) or maybe having a really long trace history. Hmmm, maybe it would be even possible to recover last part of the lexical stack from the dynamic stack and the trace history. I discussed a bit with Pepe Iborra about how to build the dynamic (lazy) stack from a trace on the fly. Something like whenever we reduce an expression we would prune the corresponding node in the trace. Such a pruned trace should correspond to the dynamic stack. (If I do not miss something which I probably do.) And moreover if we record the expressions (their source code range) we just pruned and the result they reduced to then we can show it with some command like :showexpressionresults. This would provide access to unnamed values which could have been sent to a lower level calls as inputs. And that is part of the problem we discussed in this thread. Anyway thank you, Clause Reinke and Pepe Iborra for all the great help with ghci ... I'm still learning how to script ghci debugger better. I hope I can make it better than "printf debugging" with the scripts :-) Peter. From jwlato at gmail.com Fri Nov 28 07:07:14 2008 From: jwlato at gmail.com (John Lato) Date: Fri Nov 28 07:00:51 2008 Subject: cross module optimization issues In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33281448470@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33281448470@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <9979e72e0811280407i1809dacejc54840183c456b2c@mail.gmail.com> Neil, thank you very much for taking the time to look at this; I greatly appreciate it. One thing I don't understand is why the specializations are caused by print_lines. I suppose the optimizer can infer something which it couldn't otherwise. If I read this properly, the functions being specialized are liftI, (>>=), return, and $f2. One thing I'm not sure about is when INLINE provides the desired optimal behavior, as opposed to SPECIALIZE. The monad functions are defined in the Monad instance, and thus aren't currently INLINE'd or SPECIALIZE'd. However, if they are separate functions, would INLINE be sufficient? Would that give the optimizer enough to work with the derive the specializations on its own? I'll have some time to experiment with this myself tomorrow, but I'd appreciate some direction (rather than guessing blindly). What is "$f2"? I've seen that appear before, but I'm not sure where it comes from. Thanks, John On Fri, Nov 28, 2008 at 10:31 AM, Simon Peyton-Jones wrote: > The specialisations are indeed caused (indirectly) by the presence of print_lines. If print_lines is dead code (as it is when print_lines is not exported), then there are no calls to the overloaded functions at these specialised types, and so you don't get the specialised versions. You can get specialised versions by a SPECIALISE pragma, or SPECIALISE INSTANCE > > Does that make sense? > > Simon > > | -----Original Message----- > | From: Neil Mitchell [mailto:ndmitchell@gmail.com] > | Sent: 28 November 2008 09:48 > | To: Simon Peyton-Jones > | Cc: John Lato; glasgow-haskell-users@haskell.org; Don Stewart > | Subject: Re: cross module optimization issues > | > | Hi > | > | I've talked to John a bit, and discussed test cases etc. I've tracked > | this down a little way. > | > | Given the attached file, compiling witih SHORT_EXPORT_LIST makes the > | code go _slower_. By exporting the "print_lines" function the code > | doubles in speed. This runs against everything I was expecting, and > | that Simon has described. > | > | Taking a look at the .hi files for the two alternatives, there are two > | differences: > | > | 1) In the faster .hi file, the body of print_lines is exported. This > | is reasonable and expected. > | > | 2) In the faster .hi file, there are additional specialisations, which > | seemingly have little/nothing to do with print_lines, but are omitted > | if it is not exported: > | > | "SPEC >>= [GHC.IOBase.IO]" ALWAYS forall @ el > | $dMonad :: GHC.Base.Monad GHC.IOBase.IO > | Sound.IterateeM.>>= @ GHC.IOBase.IO @ el $dMonad > | = Sound.IterateeM.a > | `cast` > | (forall el1 a b. > | Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO a > | -> (a -> Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO b) > | -> trans > | (sym ((GHC.IOBase.:CoIO) > | (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO b))) > | (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO b))) > | @ el > | "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el > | $dMonad :: > | GHC.Base.Monad GHC.IOBase.IO > | Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad > | = Sound.IterateeM.$s$f2 @ el > | "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el > | $dMonad :: > | GHC.Base.Monad GHC.IOBase.IO > | Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad > | = Sound.IterateeM.$s$f21 @ el > | "SPEC Sound.IterateeM.liftI [GHC.IOBase.IO]" ALWAYS forall @ el > | @ a > | $dMonad :: > | GHC.Base.Monad GHC.IOBase.IO > | Sound.IterateeM.liftI @ GHC.IOBase.IO @ el @ a $dMonad > | = Sound.IterateeM.$sliftI @ el @ a > | "SPEC return [GHC.IOBase.IO]" ALWAYS forall @ el > | $dMonad :: GHC.Base.Monad > | GHC.IOBase.IO > | Sound.IterateeM.return @ GHC.IOBase.IO @ el $dMonad > | = Sound.IterateeM.a7 > | `cast` > | (forall el1 a. > | a > | -> trans > | (sym ((GHC.IOBase.:CoIO) > | (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO a))) > | (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO a))) > | @ el > | > | My guess is that these cause the slowdown - but is there any reason > | that print_lines not being exported should cause them to be omitted? > | > | All these tests were run on GHC 6.10.1 with -O2. > | > | Thanks > | > | Neil > | > | > | On Fri, Nov 21, 2008 at 10:33 AM, Simon Peyton-Jones > | wrote: > | > | This project is based on Oleg's Iteratee code; I started using his > | > | IterateeM.hs and Enumerator.hs files and added my own stuff to > | > | Enumerator.hs (thanks Oleg, great work as always). When I started > | > | cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my > | > | minimal test case increased from 19s to 43s. > | > | > | > | I've found two factors that contributed. When I was cleaning up, I > | > | also removed a bunch of unused functions from IterateeM.hs (some of > | > | the test functions and functions specific to his running example of > | > | HTTP encoding). When I added those functions back in, and added > | > | INLINE pragmas to the exported functions in MyEnum.hs, I got the > | > | performance back. > | > | > | > | In general I hadn't added export lists to the modules yet, so all > | > | functions should have been exported. > | > > | > I'm totally snowed under with backlog from my recent absence, so I can't look at this > | myself, but if anyone else wants to I'd be happy to support with advice and suggestions. > | > > | > In general, having an explicit export list is good for performance. I typed an extra section > | in the GHC performance resource http://haskell.org/haskellwiki/Performance/GHC to explain why. > | In general that page is where we should document user advice for performance in GHC. > | > > | > I can't explain why *adding* unused functions would change performance though! > | > > | > Simon > | > > | > > | > _______________________________________________ > | > Glasgow-haskell-users mailing list > | > Glasgow-haskell-users@haskell.org > | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > | > > From simonpj at microsoft.com Fri Nov 28 09:46:33 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 28 09:40:12 2008 Subject: cross module optimization issues In-Reply-To: <9979e72e0811280407i1809dacejc54840183c456b2c@mail.gmail.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33281448470@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811280407i1809dacejc54840183c456b2c@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328144869D@EA-EXMSG-C334.europe.corp.microsoft.com> The $f2 comes from the instance Monad (IterateeGM ...). print_lines uses a specialised version of that instance, namely Monad (IterateeGM el IO) The fact that print_lines uses it makes GHC generate a specialised version of the instance decl. Even in the absence of print_lines you can generate the specialised instance thus instance Monad m => Monad (IterateeGM el m) where {-# SPECIALISE instance Monad (IterateeGM el IO) #-} ... methods... does that help? Simon | -----Original Message----- | From: John Lato [mailto:jwlato@gmail.com] | Sent: 28 November 2008 12:07 | To: Simon Peyton-Jones | Cc: Neil Mitchell; glasgow-haskell-users@haskell.org; Don Stewart | Subject: Re: cross module optimization issues | | Neil, thank you very much for taking the time to look at this; I | greatly appreciate it. | | One thing I don't understand is why the specializations are caused by | print_lines. I suppose the optimizer can infer something which it | couldn't otherwise. | | If I read this properly, the functions being specialized are liftI, | (>>=), return, and $f2. One thing I'm not sure about is when INLINE | provides the desired optimal behavior, as opposed to SPECIALIZE. The | monad functions are defined in the Monad instance, and thus aren't | currently INLINE'd or SPECIALIZE'd. However, if they are separate | functions, would INLINE be sufficient? Would that give the optimizer | enough to work with the derive the specializations on its own? I'll | have some time to experiment with this myself tomorrow, but I'd | appreciate some direction (rather than guessing blindly). | | What is "$f2"? I've seen that appear before, but I'm not sure where | it comes from. | | Thanks, | John | | On Fri, Nov 28, 2008 at 10:31 AM, Simon Peyton-Jones | wrote: | > The specialisations are indeed caused (indirectly) by the presence of print_lines. If | print_lines is dead code (as it is when print_lines is not exported), then there are no calls | to the overloaded functions at these specialised types, and so you don't get the specialised | versions. You can get specialised versions by a SPECIALISE pragma, or SPECIALISE INSTANCE | > | > Does that make sense? | > | > Simon | > | > | -----Original Message----- | > | From: Neil Mitchell [mailto:ndmitchell@gmail.com] | > | Sent: 28 November 2008 09:48 | > | To: Simon Peyton-Jones | > | Cc: John Lato; glasgow-haskell-users@haskell.org; Don Stewart | > | Subject: Re: cross module optimization issues | > | | > | Hi | > | | > | I've talked to John a bit, and discussed test cases etc. I've tracked | > | this down a little way. | > | | > | Given the attached file, compiling witih SHORT_EXPORT_LIST makes the | > | code go _slower_. By exporting the "print_lines" function the code | > | doubles in speed. This runs against everything I was expecting, and | > | that Simon has described. | > | | > | Taking a look at the .hi files for the two alternatives, there are two | > | differences: | > | | > | 1) In the faster .hi file, the body of print_lines is exported. This | > | is reasonable and expected. | > | | > | 2) In the faster .hi file, there are additional specialisations, which | > | seemingly have little/nothing to do with print_lines, but are omitted | > | if it is not exported: | > | | > | "SPEC >>= [GHC.IOBase.IO]" ALWAYS forall @ el | > | $dMonad :: GHC.Base.Monad GHC.IOBase.IO | > | Sound.IterateeM.>>= @ GHC.IOBase.IO @ el $dMonad | > | = Sound.IterateeM.a | > | `cast` | > | (forall el1 a b. | > | Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO a | > | -> (a -> Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO b) | > | -> trans | > | (sym ((GHC.IOBase.:CoIO) | > | (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO b))) | > | (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO b))) | > | @ el | > | "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el | > | $dMonad :: | > | GHC.Base.Monad GHC.IOBase.IO | > | Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad | > | = Sound.IterateeM.$s$f2 @ el | > | "SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el | > | $dMonad :: | > | GHC.Base.Monad GHC.IOBase.IO | > | Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad | > | = Sound.IterateeM.$s$f21 @ el | > | "SPEC Sound.IterateeM.liftI [GHC.IOBase.IO]" ALWAYS forall @ el | > | @ a | > | $dMonad :: | > | GHC.Base.Monad GHC.IOBase.IO | > | Sound.IterateeM.liftI @ GHC.IOBase.IO @ el @ a $dMonad | > | = Sound.IterateeM.$sliftI @ el @ a | > | "SPEC return [GHC.IOBase.IO]" ALWAYS forall @ el | > | $dMonad :: GHC.Base.Monad | > | GHC.IOBase.IO | > | Sound.IterateeM.return @ GHC.IOBase.IO @ el $dMonad | > | = Sound.IterateeM.a7 | > | `cast` | > | (forall el1 a. | > | a | > | -> trans | > | (sym ((GHC.IOBase.:CoIO) | > | (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO a))) | > | (sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO a))) | > | @ el | > | | > | My guess is that these cause the slowdown - but is there any reason | > | that print_lines not being exported should cause them to be omitted? | > | | > | All these tests were run on GHC 6.10.1 with -O2. | > | | > | Thanks | > | | > | Neil | > | | > | | > | On Fri, Nov 21, 2008 at 10:33 AM, Simon Peyton-Jones | > | wrote: | > | > | This project is based on Oleg's Iteratee code; I started using his | > | > | IterateeM.hs and Enumerator.hs files and added my own stuff to | > | > | Enumerator.hs (thanks Oleg, great work as always). When I started | > | > | cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my | > | > | minimal test case increased from 19s to 43s. | > | > | | > | > | I've found two factors that contributed. When I was cleaning up, I | > | > | also removed a bunch of unused functions from IterateeM.hs (some of | > | > | the test functions and functions specific to his running example of | > | > | HTTP encoding). When I added those functions back in, and added | > | > | INLINE pragmas to the exported functions in MyEnum.hs, I got the | > | > | performance back. | > | > | | > | > | In general I hadn't added export lists to the modules yet, so all | > | > | functions should have been exported. | > | > | > | > I'm totally snowed under with backlog from my recent absence, so I can't look at this | > | myself, but if anyone else wants to I'd be happy to support with advice and suggestions. | > | > | > | > In general, having an explicit export list is good for performance. I typed an extra | section | > | in the GHC performance resource http://haskell.org/haskellwiki/Performance/GHC to explain | why. | > | In general that page is where we should document user advice for performance in GHC. | > | > | > | > I can't explain why *adding* unused functions would change performance though! | > | > | > | > Simon | > | > | > | > | > | > _______________________________________________ | > | > Glasgow-haskell-users mailing list | > | > Glasgow-haskell-users@haskell.org | > | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | > From mnislaih at gmail.com Fri Nov 28 10:26:10 2008 From: mnislaih at gmail.com (pepe) Date: Fri Nov 28 10:19:53 2008 Subject: cross module optimization issues In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3328144869D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33281448470@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811280407i1809dacejc54840183c456b2c@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3328144869D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On 28/11/2008, at 15:46, Simon Peyton-Jones wrote: > The $f2 comes from the instance Monad (IterateeGM ...). > print_lines uses a specialised version of that instance, namely > Monad (IterateeGM el IO) > The fact that print_lines uses it makes GHC generate a specialised > version of the instance decl. > > Even in the absence of print_lines you can generate the specialised > instance thus > > instance Monad m => Monad (IterateeGM el m) where > {-# SPECIALISE instance Monad (IterateeGM el IO) #-} > ... methods... > > does that help? Once Simon and Neil dig the issue and analyze it, the reason seems evident. But this thread reminds of why writing high performance Haskell code is regarded as a black art outside the community (well, and sometimes inside too). Wouldn't a JIT version of GHC be a great thing to have? Or would a backend for LLVM be already beneficial enough? Cheers pepe From jwlato at gmail.com Fri Nov 28 10:56:16 2008 From: jwlato at gmail.com (John Lato) Date: Fri Nov 28 10:49:55 2008 Subject: cross module optimization issues In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3328144869D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <20081115220956.GT15077@scytale.galois.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33281448470@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811280407i1809dacejc54840183c456b2c@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3328144869D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <9979e72e0811280756i25d9e738y946c65bc2099189@mail.gmail.com> Yes, this does help, thank you. I didn't know you could generate specialized instances. In fact, I was so sure that this was some arcane feature I immediately went to the GHC User Guide because I didn't believe it was documented. I immediately stumbled upon Section 8.13.9. Thanks to everyone who helped me with this. I think I've achieved a small bit of enlightenment. Cheers, John On Fri, Nov 28, 2008 at 2:46 PM, Simon Peyton-Jones wrote: > The $f2 comes from the instance Monad (IterateeGM ...). > print_lines uses a specialised version of that instance, namely > Monad (IterateeGM el IO) > The fact that print_lines uses it makes GHC generate a specialised version of the instance decl. > > Even in the absence of print_lines you can generate the specialised instance thus > > instance Monad m => Monad (IterateeGM el m) where > {-# SPECIALISE instance Monad (IterateeGM el IO) #-} > ... methods... > > does that help? > > Simon > From ndmitchell at gmail.com Fri Nov 28 11:02:04 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Nov 28 10:55:41 2008 Subject: cross module optimization issues In-Reply-To: References: <9979e72e0811151407p202e6326td26575d982a62402@mail.gmail.com> <9979e72e0811180257j55cf9e74qd56800d0ecbad7a4@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33191A9CA60@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811210154j68d770e5g6ebcaeab78d81acd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419B27@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811280147n94a3854k964141265ced9b90@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33281448470@EA-EXMSG-C334.europe.corp.microsoft.com> <9979e72e0811280407i1809dacejc54840183c456b2c@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3328144869D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <404396ef0811280802q7808992do1b855946e475319f@mail.gmail.com> Hi >> instance Monad m => Monad (IterateeGM el m) where >> {-# SPECIALISE instance Monad (IterateeGM el IO) #-} >> >> does that help? Yes. With that specialise line in, we get identical performance between the two results. So, in summary: The print_lines function uses the IterateeGM with IO as the underlying monad, which causes GHC to specialise IterateeGM with IO. If print_lines is not exported, then it is deleted as dead code, and the specialisation is never generated. The specialisation is crucial for performance later on. In this way, by keeping unused code reachable, GHC does better optimisation. > Once Simon and Neil dig the issue and analyze it, the reason seems evident. > But this thread reminds of why writing high performance Haskell code is > regarded as a black art outside the community (well, and sometimes inside > too). > > Wouldn't a JIT version of GHC be a great thing to have? > Or would a backend for LLVM be already beneficial enough? I don't think either would have the benefits offered by specialisation. If GHC exported more information about instances, it could do more specialisations later, but it is a trade off. If you ran GHC in some whole-program mode, then you wouldn't have the problem, but would gain additional problems. I always hoped Supero (http://www-users.cs.york.ac.uk/~ndm/supero/) would remove some of the black art associated with program optimisation - there are no specialise pragmas, and I'm pretty sure in the above example it would have done the correct thing. In some ways, whole-program and fewer special cases gives a much better mental model of how optimisation might effect a program. Of course, its still a research prototype, but perhaps one day... Thanks Neil From isaacdupree at charter.net Fri Nov 28 11:10:43 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Nov 28 11:04:25 2008 Subject: GHCi debugger status In-Reply-To: <492C2135.6060306@gmail.com> 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> Message-ID: <49301803.9040003@charter.net> 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? -Isaac From john at repetae.net Sun Nov 30 23:59:38 2008 From: john at repetae.net (John Meacham) Date: Sun Nov 30 23:53:07 2008 Subject: Weak pointers and STM Message-ID: <20081201045938.GF7014@sliver.repetae.net> 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? 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? I just wanted to be sure before I base an integral component of a projects design on these working properly. thanks! John -- John Meacham - ?repetae.net?john?