From simonmarhaskell at gmail.com Fri Feb 1 04:27:13 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 1 04:26:32 2008 Subject: Using "GHC as a library" with own functions makes runStmt return RunBreak In-Reply-To: References: Message-ID: <47A2E5F1.8020500@gmail.com> Mads Lindstr?m wrote: > For those interested I figured out how to avoid the RunBreak -returns. > Use RunToCompletion in stead of SingleStep in the application of runStmt. > I guess Interactive-6.8.hs should also use SingleStep. SingleStep is what GHCi uses to implement :step - that is, it runs until the next breakpoint location and then stops, returning RunBreak to the caller of runStmt. To run the whole statement, what you want is RunToCompletion, as you discovered. Cheers, Simon From simonmarhaskell at gmail.com Fri Feb 1 04:37:54 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 1 04:37:12 2008 Subject: Bootstrapping for Leopard In-Reply-To: <20080130195956.GA23183@petunia.outback.escape.de> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> <20080130195956.GA23183@petunia.outback.escape.de> Message-ID: <47A2E872.40208@gmail.com> Matthias Kilian wrote: > On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote: > [...] >> This is due to a change of the configure stage that AFAIK was made to >> easy building on windows. Instead, of using shell commands/scripts >> (as GHC did previously) to obtain some configuration information (here >> the file path at which the top of the GHC build tree is located), the >> build system now uses small Haskell programs/scripts. This makes the >> build more portable ** if there is already a Haskell compiler on the >> system **. > > But it just doesn't make sense at all. You need a good set of shell > commands at all, since they're used by configure as well as in > Makefiles. I really can't believe that simple stuff like this doesn't > work on windos: > > --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 > +++ aclocal.m4 Sun Jan 20 17:10:07 2008 > @@ -1098,20 +1098,14 @@ AC_REQUIRE([AC_PROG_CC]) > AC_DEFUN([FP_FIND_ROOT],[ > AC_MSG_CHECKING(for path to top of build tree) > > -dnl This would be > -dnl make -C utils/pwd clean && make -C utils/pwd > -dnl except we don't want to have to know what make is called. Sigh. > -if test ! -f utils/pwd/pwd && test ! -f utils/pwd/pwd.exe; then > - cd utils/pwd > - rm -f *.o > - rm -f *.hi > - rm -f pwd > - rm -f pwd.exe > - $WithGhc -v0 --make pwd -o pwd > - cd ../.. > -fi > - > -hardtop=`utils/pwd/pwd forwardslash` > +case $HostPlatform in > +*cygwin32|*mingw32) > + hardtop=`pwd | tr \\ /` > + ;; > +*) > + hardtop=`pwd` > + ;; > +esac > > if ! test -d "$hardtop"; then > AC_MSG_ERROR([cannot determine current directory]) Things are complicated because - on Cygwin, pwd gives you /cygdrive/c/... - on MSYS, pwd gives you /c/... (remember we still support MSYS), and we want c:/... So we used to use cygpath on cygwin, and some horrible sed command on MSYS, IIRC. It was a mess, and frequently went wrong. Sure there are other ways to do it, but I think at the time it seemed simpler to write a Haskell program. In hindsight, probably a C program (compiled using mingw gcc) would be better for bootstrapping. A shell script would be problematic for the reasons above, I'm guessing. Cheers, Simon From simonmarhaskell at gmail.com Fri Feb 1 04:46:09 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 1 04:45:28 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47A1C37A.4020700@informatik.uni-kiel.de> References: <47A1C37A.4020700@informatik.uni-kiel.de> Message-ID: <47A2EA61.7040805@gmail.com> Bernd Brassel wrote: > Consider the following program: > > module Stack where > > import System.IO.Unsafe > > main = print (sim (replicate 1299959 ())) > > sim [] = True > sim (_:xs) = goodStack (sim xs) > > goodStack x = fromJust (Just x) --no stack overflow > badStack x = unsafePerformIO (return x) --stack overflow > > fromJust (Just x) = x goodStack == id, and GHC even with no optimisation will transform it into id, and inline it into sim. So with goodStack, sim ends up being tail-recursive. With badStack, sim is no longer tail recursive (unsafePerformIO is not inlined), so it runs out of stack. Simple! > Is this behaviour necessary? Is there any work around, e.g., employing > the foreign function interface? There's unsafeInlinePerformIO (sometimes called inlinePerformIO), which is usable in certain cases, but be very careful. From Data.ByteString.Internal: {-# INLINE inlinePerformIO #-} inlinePerformIO :: IO a -> a #if defined(__GLASGOW_HASKELL__) inlinePerformIO (IO m) = case m realWorld# of (# _, r #) -> r #else inlinePerformIO = unsafePerformIO #endif But even this might not give you tail recursion, depending on the context. Cheers, Simon From simonmarhaskell at gmail.com Fri Feb 1 04:49:28 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 1 04:48:51 2008 Subject: Is GHC 6.8.2 on solaris 32 bits or 64 bits In-Reply-To: <31bdb3200801310803v6f06a615l5d862c7ae0340318@mail.gmail.com> References: <31bdb3200801310803v6f06a615l5d862c7ae0340318@mail.gmail.com> Message-ID: <47A2EB28.1000806@gmail.com> hsing-chou chen wrote: > Thank you for porting GHC 6.8.2 to solaris, I am assigned a > > job to make sure GHC run 64 bits on solaris. Is your > > solaris port 64 bits. Or it only 32 BITS. I know 32 bits > > GHC can still run on 64 bits solaris. However company want > > to run really 64 bits GHC on solaris. Thanks a lot if you You want to look at the porting instructions: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting Start from GHC 6.6.1 (6.8.2 doesn't bootstrap from .hc files yet). This won't be easy, you'll need to know details of the processor architecture, and be prepared to learn about GHC internals. But it'll be fun, if you like that sort of thing :) Cheers, Simon From bbr at informatik.uni-kiel.de Fri Feb 1 07:39:13 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Fri Feb 1 07:43:45 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47A2EA61.7040805@gmail.com> References: <47A1C37A.4020700@informatik.uni-kiel.de> <47A2EA61.7040805@gmail.com> Message-ID: <47A312F1.2090500@informatik.uni-kiel.de> Thanks for your answer Simon. Simon Marlow wrote: > Bernd Brassel wrote: >> Consider the following program: >> >> module Stack where >> >> import System.IO.Unsafe >> >> main = print (sim (replicate 1299959 ())) >> >> sim [] = True >> sim (_:xs) = goodStack (sim xs) >> >> goodStack x = fromJust (Just x) --no stack overflow >> badStack x = unsafePerformIO (return x) --stack overflow >> >> fromJust (Just x) = x > > goodStack == id, and GHC even with no optimisation will transform it > into id, and inline it into sim. So with goodStack, sim ends up being > tail-recursive. With badStack, sim is no longer tail recursive > (unsafePerformIO is not inlined), so it runs out of stack. Simple! Is it really that simple? I guess that in a lazy language we have to look a bit closer to see what is tail recursive and what is not. If I understand you correctly, you say that if goodStack was not inlined you would have a bad stack as well, right? But look at what it would be doing. In a lazy language the call to sim would go to the heap and whatever goodStack does to the stack is already done before sim is restarted. And the same could be true with the unsafePerformIO-return combination. What is the reason to hold anything on the stack for this after the call to unsafe is finished? I have tried the example with badStack in one other compiler and two interpreters. None of them has any problem running the example. For one of the interpreters I could exactly measure that the stack is constant the whole time. And I know that no optimisation or inlining is going on for that interpreter. Just try the example with hugs. It easily runs through while replacing badStack with the function pushStack True = True immediately runs out of memory. (With this function, the example is indeed not tail recursive and your argument is valid.) So there is definitely something that unsafePerformIO does to the stack in the ghc that is special to that compiler. From P.Achten at cs.ru.nl Fri Feb 1 07:50:01 2008 From: P.Achten at cs.ru.nl (Peter Achten) Date: Fri Feb 1 07:49:28 2008 Subject: Second Call for Papers TFP 2008, The Netherlands Message-ID: <47A31579.1090704@cs.ru.nl> 2ND CALL FOR PAPERS TRENDS IN FUNCTIONAL PROGRAMMING 2008 RADBOUD UNIVERSITY NIJMEGEN, THE NETHERLANDS MAY 26-28, 2008 INVITED SPEAKER: PROF. HENK BARENDREGT http://www.st.cs.ru.nl/AFP_TFP_2008/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts and full papers. A formal post-symposium refereeing process selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2008 is hosted by the Radboud University Nijmegen, The Netherlands, and will be held in the rural setting of Center Parcs ?Het Heijderbos?, Heijen (in the vicinity of Nijmegen), The Netherlands. TFP 2008 is co-located with the 6th Int?l. Summer School on Advanced Functional Programming (AFP?08), which is held immediately before TFP?08. SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research: leading-edge, previously unpublished research. Position: on what new trends should or should not be. Project: descriptions of recently started new projects. Evaluation: what lessons can be drawn from a finished project. Overview: summarizing work with respect to a trendy subject. Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Contributions on the following subject areas are particularly welcomed: * Dependently Typed Functional Programming * Validation and Verification of Functional Programs * Debugging for Functional Languages * Functional Programming and Security * Functional Programming and Mobility * Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications * Functional Languages for Telecommunications Applications * Functional Languages for Embedded Systems * Functional Programming Applied to Global Computing * Functional GRIDs * Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) * Interoperability with Imperative Programming Languages * Novel Memory Management Techniques * Parallel/Concurrent Functional Languages * Program Transformation Techniques * Empirical Performance Studies * Abstract/Virtual Machines and Compilers for Functional Languages * New Implementation Strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2008 program chairs, Peter Achten and Pieter Koopman, at afp_tfp_2008@cs.ru.nl. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of full papers (15 pages) and extended abstracts (at least 3 pages) by the program committee. TFP encourages PhD students to submit papers. PhD students may request the program committee to provide extensive feedback on their full papers at the time of submission. Full papers describing work accepted for presentation must be completed before the symposium for publication in the draft proceedings and on-line. Further details can be found at the TFP 2008 website http://www.st.cs.ru.nl/AFP_TFP_2008/. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. IMPORTANT DATES (ALL 2008) Paper Submission: March 3 Notification of Acceptance: March 31 Early Registration Deadline: April 14 Late Registration Deadline: May 5 Camera Ready Symposium: May 5 TFP Symposium: May 26-28 Post Symposium Paper Submission: June 20 Notification of Acceptance: September 7 Camera Ready Revised Paper: September 21 PROGRAMME COMMITTEE Peter Achten (co-chair) Radboud Univ. Nijmegen, NL Andrew Butterfield Trinity College, IE Manuel Chakravarty Univ. of New South Wales, AU John Clements Cal Poly State Univ., USA Matthias Felleisen Northeastern Univ., USA Jurriaan Hage Utrecht Univ., NL Michael Hanus Christian-Albrechts Univ. zu Kiel, DE Ralf Hinze Univ. of Oxford, UK Graham Hutton Univ. of Nottingham, UK Johan Jeuring Utrecht Univ., NL Pieter Koopman (co-chair) Radboud Univ. Nijmegen, NL Shriram Krishnamurthi Brown Univ., USA Hans-Wolfgang Loidl Ludwig-Maximilians Univ.M?nchen, DE Rita Loogen Philipps-Univ. Marburg, DE Greg Michaelson Heriot-Watt Univ., UK Marco T. Moraz?n (symp. chair) Seton Hall Univ., USA Sven-Bodo Scholz Univ. of Hertfordshire, UK Ulrik Schultz Univ. of Southern Denmark, DK Clara Segura Univ. Complutense de Madrid, ES Olin Shivers Northeastern Univ., USA Phil Trinder Heriot-Watt Univ., UK Varmo Vene Univ. of Tartu, EE Vikt?ria Zs?k E?tv?s Lor?nd Univ., HU ORGANIZATION Symposium Chair: Marco T. Moraz?n, Seton Hall University, USA Programme Chair: Peter Achten, Pieter Koopman, Radboud University Nijmegen, NL Treasurer: Greg Michaelson, Heriot-Watt University, UK From dbueno at gmail.com Sat Feb 2 12:27:44 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Feb 2 12:26:54 2008 Subject: Read instance of StdGen returns no parse In-Reply-To: <2608b8a80801261601y5448fb90i4704b4665719daef@mail.gmail.com> References: <6dbd4d000801261221k792eee8q3aeebb1a32124288@mail.gmail.com> <2608b8a80801261601y5448fb90i4704b4665719daef@mail.gmail.com> Message-ID: <6dbd4d000802020927q5140deccld724164af78b9b35@mail.gmail.com> On Jan 26, 2008 7:01 PM, Yitzchak Gale wrote: [snip explanation] > The documentation in System.Random is a bit misleading. > It says "the read instance of StdGen has the following properties: > It guarantees to succeed on any string..." The word "read" should > really be "Read" instead. It also wouldn't hurt to mention that the > read *function* may fail, so use reads instead. > > Hope this helps. Definitely. The error now makes sense. Thanks for the response. -- Denis From catamorphism at gmail.com Sat Feb 2 20:44:14 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Sat Feb 2 20:43:24 2008 Subject: [Haskell-cafe] strange GHC assembler failure In-Reply-To: References: Message-ID: <4683d9370802021744n4a2d9ffen4c511a1224041ed3@mail.gmail.com> On 2/2/08, Tim Newsham wrote: > I'm getting a weird build error: > [ 9 of 95] Compiling Plugin.Pl.Common ( Plugin/Pl/Common.hs, > dist/build/lambdabot/lambdabot-tmp/Plugin/Pl/Common.o ) > /tmp/ghc52608_0/ghc52608_0.s: Assembler messages: > > /tmp/ghc52608_0/ghc52608_0.s:36:0: Error: unassigned file number 1 > [... more of these ...] > > I narrowed this down -- this happens when I add my new library > "silc-client" to the "Build-depends:" line in the cabal file even > if none of its code is referenced. Removing the dependency makes > the error go away. The module I'm referencing is a new one I'm > still working on and it makes use of FFI and references external > headers and libraries. > (I put a copy at http://www.thenewsh.com/~newsham/silc-client.tgz > if it helps anyone debug.. this is not release-quality code > though). > > Any idea what is going on here? > This would probably be a better question for ghc-users, since that's a lower-traffic list for GHC-specific questions. Redirected there. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Now, don't bother to flame me, because by the time you read this post I will be a different person from the one who wrote it. You cannot step in the same river twice." -- Sarah Barton From igloo at earth.li Sun Feb 3 11:35:48 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 3 11:34:57 2008 Subject: Bootstrapping for Leopard In-Reply-To: <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> Message-ID: <20080203163548.GA10976@matrix.chaos.earth.li> On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote: > Philip K.F. H?lzenspies: > > > >for f in `$(FIND) ghc-$(ProjectVersion)/compiler > >ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \ > > if test "x$$f" !=3D "x"; then \ > > echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \ > > fi; \ > >done; > > > >This adds some non-existing .hc files to the hc-files-to-go list > >that tar will > >not find, later on, causing an error. I just added a test to see > >whether the > >file exists. If it does not, I call make for that .hc file > >explicitly, which > >solves the problem for most files. The files that don't have a make > >target, I > >simply omitted from the hc-files-to-go. I haven't been able to test > >the > >severity of this, because of the second problem. > > I am not sure what the problem is here. Simon? Ian? I think there are some files that are meant to be missing; you can ignore the tar warnings/errors about them. I'm not sure what they are OTTOMH - possibly debug, prof, debug_prof etc variants of AutoApply. Thanks Ian From p.k.f.holzenspies at utwente.nl Sun Feb 3 12:12:35 2008 From: p.k.f.holzenspies at utwente.nl (=?ISO-8859-1?Q?Philip_H=F6lzenspies?=) Date: Sun Feb 3 12:12:22 2008 Subject: Bootstrapping for Leopard In-Reply-To: <20080203163548.GA10976@matrix.chaos.earth.li> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> <20080203163548.GA10976@matrix.chaos.earth.li> Message-ID: On Feb 3, 2008, at 5:35 PM, Ian Lynagh wrote: > I think there are some files that are meant to be missing; you can > ignore the tar warnings/errors about them. > > I'm not sure what they are OTTOMH - possibly debug, prof, debug_prof > etc > variants of AutoApply. Dear Ian, All, They are indeed variants of AutoApply, but to simply ignore the tar error does not seem like a good idea. Tar terminates upon these errors and other stuff gets added to the hc-files-to-go later on in the Makefile. IMHO, if indeed these files are not required, the makefile should read: for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/ rts -name "*.cmm" -follow -print` ""; do\ fd="`echo $$f | sed 's/cmm$$/hc/g'`; \ if test "x$$f" != "x" -a -e "$$fd"; then \ echo $fd >> hc-files-to-go; \ fi; \ done; I don't know whether the -a argument for test is "common" test syntax, but it should give a logical. The -e option tests that "$$fd" exists and is a file. Regards, Philip From igloo at earth.li Sun Feb 3 12:31:54 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 3 12:31:01 2008 Subject: Deforesting edtiInt In-Reply-To: <1b795e7b0801311505g736ff817r3d948809046d9a5f@mail.gmail.com> References: <1b795e7b0801311505g736ff817r3d948809046d9a5f@mail.gmail.com> Message-ID: <20080203173154.GA16385@matrix.chaos.earth.li> Hi Robin, On Thu, Jan 31, 2008 at 11:05:32PM +0000, Robin Houston wrote: > > Except that it is a lot slower than it needs to be. After digging > around a bit, I suspected that the reason for this is that the general > form of enumeration [from, then .. to] does not benefit from the > deforestation optimisation. > > When I added some deforestation rules to GHC/Enum.lhs and rebuilt the > library, I found my suspicion confirmed: after the change, my code > runs roughly twice as fast. Thanks for the patch! Looks good to me; I've applied it. Thanks Ian From igloo at earth.li Sun Feb 3 14:15:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 3 14:14:48 2008 Subject: A suggestion for GHC download pages In-Reply-To: <479E166C.5060005@vex.net> References: <479E166C.5060005@vex.net> Message-ID: <20080203191541.GB16935@matrix.chaos.earth.li> Hi Albert, On Mon, Jan 28, 2008 at 12:52:44PM -0500, Albert Y. C. Lai wrote: > On GHC version-specific download pages (e.g., > http://www.haskell.org/ghc/download_ghc_682.html), Thanks for your suggestions! I've rejigged the page accordingly. Thanks Ian From adam at thejenkins.org Sun Feb 3 14:37:42 2008 From: adam at thejenkins.org (Adam P Jenkins) Date: Sun Feb 3 14:36:58 2008 Subject: GHC lazy eval optimization bug Message-ID: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> The haskell program below demonstrates an optimization bug with the GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and on a Linux i686 machine. This email should build as a literate haskell program. Build the program as ghc --make -O lazyevalbug.lhs and run it with no arguments. An IO action runs 4 times, printing out how long it took each time. It takes 1 to 2 seconds to run each time, but it should only take 1 second or 2 the first time, and finish almost instantaneously the rest of the times. If you run the program with "fast" as a cmdline arg, as in ./lazyevalbug fast then it will behave how I'd expect it to: the first IO action takes a couple of seconds tand the rest finish instantaneously. If you build the program without the -O switch, then it behaves the same with our without the "fast" commandline arg. DETAILS: The bug involves lazy evalutation behaving in an unexpected way when the program is compiled with the -O switch. If I create an IO action which refers to a variable which was defined outside of the IO action, and then run that IO action multiple times, then in some circumstances the variable value will be re-computed each time the IO action is run. This seems to violate the behavior I expect from lazy evaluation. I.e. if I have code like this: let val = really_expensive_computation in map (\x -> val + x) [1, 2, 3] I would expect val to only be computed once. And it is. However if instead of referring to val in a lambda function I refer to val from an IO action, then in some cases it seems to be re-evaluated every time the action is performed. I.e. let val = really_expensive_computation in replicateM_ 3 (print val) When compiled with -O, the above will recompute val 3 times. However adding a second reference to "val" seems to make the problem go away. Another thing I noticed is, the problem seems to only occur if really_expensive_computation involves the IO monad somehow, for example if it's doing a computation based on some input read from stdin. If really_expensive_computation only involves data generated within the program then the bug never occurs. The program below demonstrates this problem with the doSlow and doFast functions. See the comment above these functions. Also, in main, if you comment out the getStdGen line and uncomment the mkStdGen line, then the problem goes away. This demonstrates the fact that if the computation uses data from an IO action the problem occurs, otherwise it doesn't. > import System (getArgs) > import qualified System.Time as ST > import Control.Monad (when, replicateM_) > import System.Random (getStdGen, mkStdGen, randoms) Takes an IO action, runs it, and prints line saying how long it took to run > timeIt :: IO a -> IO () > timeIt action = > do tic <- ST.getClockTime > action > toc <- ST.getClockTime > putStrLn $ "Took " ++ (timeDiffToString (ST.diffClockTimes toc tic)) > -- System.Time.timeDiffToString doesn't handle fractions of a > -- second correctly, so I implement my own version > where timeDiffToString d = > let secs = ST.tdMin d * 60 + ST.tdSec d > frac = (realToFrac $ abs $ ST.tdPicosec d) / (realToFrac $ 10^12) > in show ((realToFrac secs) + frac) ++ " secs" True if a number is prime. Just a function meant to use up some time > isPrime :: (Integral n) => n -> Bool > isPrime n = > let lim = round (sqrt $ realToFrac n) in > not $ any (\x -> n `rem` x == 0) [2..lim] doSlow and doFast are exactly the same, except that doFast has an extra "when" statement which references "primes". The mere existence of this extra reference to "primes" in doFast seems to cause the primes list to only be generated once, so the first time action runs takes around 1.6 seconds, but subsequent actions finish in a small fraction of a second. In doSlow, the action takes 1.6 seconds each time it runs, not just the first time, indicating that primes is getting re-created each time the action is run. > doSlow, doFast :: (Integral a) => [a] -> IO () > doSlow lst = let primes = filter isPrime lst > action = timeIt $ print (length primes) > in do replicateM_ 4 action > doFast lst = let primes = filter isPrime lst > action = timeIt $ print (length primes) > in do replicateM_ 4 action > when (null primes) (print "No primes") In main, comment out the getStdGen line and uncomment the mkStdGen line and the problem goes away as well. The same is true if I read data from stdin vs generating a list in memory. > main = do args <- getArgs > let doFunc = if (length args) > 0 && args!!0 == "fast" > then doFast > else doSlow > --gen <- return $ mkStdGen 42 > gen <- getStdGen > let lst = take 10000 $ randoms gen :: [Integer] > doFunc lst From haskell at list.mightyreason.com Sun Feb 3 15:10:34 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sun Feb 3 15:09:47 2008 Subject: GHC lazy eval optimization bug In-Reply-To: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> References: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> Message-ID: <47A61FBA.3040803@list.mightyreason.com> I can confirm this performance bug with GHC version 6.6.1 on OS X PCC (G4) Leopard. It performs correctly, lazily keeping 'primes' for all 4 repetitions, when using "ghc -Onot" but the the doSlow fails to retain 'primes' when compiling with "ghc -O" and "ghc -O2" Cheers, Chris From dons at galois.com Sun Feb 3 15:15:37 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 3 15:14:45 2008 Subject: GHC lazy eval optimization bug In-Reply-To: <47A61FBA.3040803@list.mightyreason.com> References: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> <47A61FBA.3040803@list.mightyreason.com> Message-ID: <20080203201537.GD29420@scytale.galois.com> haskell: > I can confirm this performance bug with GHC version 6.6.1 on OS X PCC (G4) > Leopard. > > It performs correctly, lazily keeping 'primes' for all 4 repetitions, when > using "ghc -Onot" but the the doSlow fails to retain 'primes' when > compiling with "ghc -O" and "ghc -O2" Sounds like the known issue of the simplifier eta-expanding `State#` lambdas on purpose, which is good for IO, but risks re-computation. The 'calendar' nofib program exhibits this, iirc. See, http://hackage.haskell.org/trac/ghc/ticket/1168 http://hackage.haskell.org/trac/ghc/ticket/1957 Try compiling with: -fno-state-hack -- Don From stefanor at cox.net Sun Feb 3 15:18:01 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Feb 3 15:17:41 2008 Subject: GHC lazy eval optimization bug In-Reply-To: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> References: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> Message-ID: <20080203201801.GA4558@localhost.localdomain> On Sun, Feb 03, 2008 at 02:37:42PM -0500, Adam P Jenkins wrote: > The haskell program below demonstrates an optimization bug with the > GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and > on a Linux i686 machine. This email should build as a literate haskell > program. Build the program as While this may be unfortunate, it is a consequence of document behavior; thus I would not consider it a bug per-se. Try with -fno-state-hack; the documentation for this option, I believe, should explain what is going on. (Hint: IO a ~ State# -> (State#, a)) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080203/2c76f5e8/attachment.bin From haskell at list.mightyreason.com Sun Feb 3 15:34:41 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sun Feb 3 15:33:50 2008 Subject: GHC lazy eval optimization bug In-Reply-To: <20080203201537.GD29420@scytale.galois.com> References: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> <47A61FBA.3040803@list.mightyreason.com> <20080203201537.GD29420@scytale.galois.com> Message-ID: <47A62561.2090109@list.mightyreason.com> Thanks Don. That is the issue. I just added this comment/request to trac #1168: > This just came up on the mailing list again. The program was slow unless > (-fno-state-hack) was used. > > Is it possible to have GHC emit a warning (as part of -Wall) to let the use > know that GHC is applying a potentially risky simplification? I had tried -Wall before you told me about -fno-state-hack. If -Wall had warned me about the hack then I could have understood the problem without a frequently asked question to the list. Cheers, Chris Don Stewart wrote: > haskell: >> I can confirm this performance bug with GHC version 6.6.1 on OS X PCC (G4) >> Leopard. >> >> It performs correctly, lazily keeping 'primes' for all 4 repetitions, when >> using "ghc -Onot" but the the doSlow fails to retain 'primes' when >> compiling with "ghc -O" and "ghc -O2" > > Sounds like the known issue of the simplifier eta-expanding `State#` > lambdas on purpose, which is good for IO, but risks re-computation. The > 'calendar' nofib program exhibits this, iirc. > > See, > http://hackage.haskell.org/trac/ghc/ticket/1168 > http://hackage.haskell.org/trac/ghc/ticket/1957 > > Try compiling with: > > -fno-state-hack > > -- Don From chak at cse.unsw.edu.au Sun Feb 3 20:21:45 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Feb 3 20:20:53 2008 Subject: Bootstrapping for Leopard In-Reply-To: <47A2E872.40208@gmail.com> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> <20080130195956.GA23183@petunia.outback.escape.de> <47A2E872.40208@gmail.com> Message-ID: > Things are complicated because > > - on Cygwin, pwd gives you /cygdrive/c/... > - on MSYS, pwd gives you /c/... > > (remember we still support MSYS), and we want c:/... > > So we used to use cygpath on cygwin, and some horrible sed command > on MSYS, IIRC. It was a mess, and frequently went wrong. > > Sure there are other ways to do it, but I think at the time it > seemed simpler to write a Haskell program. In hindsight, probably a > C program (compiled using mingw gcc) would be better for > bootstrapping. A shell script would be problematic for the reasons > above, I'm guessing. I understand that this is a difficult issues, but as it is booting from HC files and hence porting is simply broken. So, I wonder what the way forward is... Manuel From Christian.Maeder at dfki.de Mon Feb 4 05:04:55 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Feb 4 05:04:02 2008 Subject: Is GHC 6.8.2 on solaris 32 bits or 64 bits In-Reply-To: <47A2EB28.1000806@gmail.com> References: <31bdb3200801310803v6f06a615l5d862c7ae0340318@mail.gmail.com> <47A2EB28.1000806@gmail.com> Message-ID: <47A6E347.2080008@dfki.de> Simon Marlow wrote: > hsing-chou chen wrote: >> Thank you for porting GHC 6.8.2 to solaris, I am assigned a >> >> job to make sure GHC run 64 bits on solaris. Is your >> >> solaris port 64 bits. Or it only 32 BITS. I know 32 bits >> >> GHC can still run on 64 bits solaris. However company want >> >> to run really 64 bits GHC on solaris. Thanks a lot if you > > You want to look at the porting instructions: > > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting > > Start from GHC 6.6.1 (6.8.2 doesn't bootstrap from .hc files yet). > > This won't be easy, you'll need to know details of the processor > architecture, and be prepared to learn about GHC internals. But it'll > be fun, if you like that sort of thing :) That's too much for me. I'll wait until ghc-6.8 (or ghc-6.10) can be bootstrapped from C-sources. One (maybe minor) problem under Solaris (and MacOS I think) is that already configure decides by default to be under i386, i.e. in 32bit mode (through "arch" or "uname -p"). Only extending the call to gcc with "-m64" will create 64Bit code. You have done it under Linux. Maybe you find an easy path from 32Bit to 64Bit under Linux that one may also try under Solaris and Macs. Cheers Christian From simonmarhaskell at gmail.com Mon Feb 4 07:18:01 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 4 07:17:09 2008 Subject: Bootstrapping for Leopard In-Reply-To: References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> <20080130195956.GA23183@petunia.outback.escape.de> <47A2E872.40208@gmail.com> Message-ID: <47A70279.9030706@gmail.com> Manuel M T Chakravarty wrote: >> Things are complicated because >> >> - on Cygwin, pwd gives you /cygdrive/c/... >> - on MSYS, pwd gives you /c/... >> >> (remember we still support MSYS), and we want c:/... >> >> So we used to use cygpath on cygwin, and some horrible sed command on >> MSYS, IIRC. It was a mess, and frequently went wrong. >> >> Sure there are other ways to do it, but I think at the time it seemed >> simpler to write a Haskell program. In hindsight, probably a C >> program (compiled using mingw gcc) would be better for bootstrapping. >> A shell script would be problematic for the reasons above, I'm guessing. > > I understand that this is a difficult issues, but as it is booting from > HC files and hence porting is simply broken. So, I wonder what the way > forward is... Porting is "simply broken" for various reasons at the moment - in particular the switch to Cabal for building the libraries broke it. We knew this at the time, but felt it was more important to make the switch now and fix bootstrapping later. For pwd, I imagine the best way forward is to use a C program, I don't think there are any deep issues there. Cheers, Simon From simonmarhaskell at gmail.com Mon Feb 4 07:24:34 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 4 07:23:42 2008 Subject: Is GHC 6.8.2 on solaris 32 bits or 64 bits In-Reply-To: <47A6E347.2080008@dfki.de> References: <31bdb3200801310803v6f06a615l5d862c7ae0340318@mail.gmail.com> <47A2EB28.1000806@gmail.com> <47A6E347.2080008@dfki.de> Message-ID: <47A70402.80501@gmail.com> Christian Maeder wrote: > Simon Marlow wrote: >> hsing-chou chen wrote: >>> Thank you for porting GHC 6.8.2 to solaris, I am assigned a >>> >>> job to make sure GHC run 64 bits on solaris. Is your >>> >>> solaris port 64 bits. Or it only 32 BITS. I know 32 bits >>> >>> GHC can still run on 64 bits solaris. However company want >>> >>> to run really 64 bits GHC on solaris. Thanks a lot if you >> You want to look at the porting instructions: >> >> http://hackage.haskell.org/trac/ghc/wiki/Building/Porting >> >> Start from GHC 6.6.1 (6.8.2 doesn't bootstrap from .hc files yet). >> >> This won't be easy, you'll need to know details of the processor >> architecture, and be prepared to learn about GHC internals. But it'll >> be fun, if you like that sort of thing :) > > That's too much for me. I'll wait until ghc-6.8 (or ghc-6.10) can be > bootstrapped from C-sources. Waiting for 6.8 or 6.10 to be bootstrappable won't actually help with the porting you need to do to get a 64-bit Sparc port working. You'll still need to modify parts of the system that deal with architecture- and platform-specific things. If I get libffi integrated (hopefully for 6.10) then this will reduce the porting effort, as the clever libffi folks will already have 64-bit Sparc support. However, we'll likely be dropping the C backend in 6.10, so the only way to get good performance will be to write a native code generator. Hopefully by then we'll have refactored the NCG to make it easier to add new ones, though. Cheers, Simon From adam at thejenkins.org Mon Feb 4 10:11:46 2008 From: adam at thejenkins.org (Adam P Jenkins) Date: Mon Feb 4 10:10:55 2008 Subject: GHC lazy eval optimization bug In-Reply-To: <20080203201801.GA4558@localhost.localdomain> References: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> <20080203201801.GA4558@localhost.localdomain> Message-ID: <768B04E5-0E24-4804-B786-DB69843B8986@thejenkins.org> Thank you for the explanation. Inlining does explain the behavior I was seeing, and -fno-state-hack does make the program behave the way I'd expect. I would like to humbly submit that perhaps this optimization should be off by default. It seems to me that any compiler optimization which can potentially increase your program's runtime by an order of complexity is dangerous. Also, while the Haskell Report doesn't seem to specify anything about lazy evaluation behavior, it seems to me that in order to program in Haskell, assuming that a computation assigned to a variable won't be recomputed multiple times is almost as necessary an assumption as assuming that the compiler will optimize away tail recursion. For instance GHC FAQ entry 7.2 implicitly assumes this is true: http://haskell.org/haskellwiki/GHC:FAQ#Does_GHC_do_common_subexpression_elimination.3F In my real program where I ran into this problem it took me quite a while to figure out why my program's performance wasn't making any sense, and why seemingly irrelevant changes to my code made the performance problem go away. Thank you, Adam On Feb 3, 2008, at 3:18 PM, Stefan O'Rear wrote: > On Sun, Feb 03, 2008 at 02:37:42PM -0500, Adam P Jenkins wrote: >> The haskell program below demonstrates an optimization bug with the >> GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and >> on a Linux i686 machine. This email should build as a literate >> haskell >> program. Build the program as > > While this may be unfortunate, it is a consequence of document > behavior; thus I would not consider it a bug per-se. Try with > -fno-state-hack; the documentation for this option, I believe, should > explain what is going on. (Hint: IO a ~ State# -> (State#, a)) > > Stefan From P.Achten at cs.ru.nl Mon Feb 4 12:03:54 2008 From: P.Achten at cs.ru.nl (Peter Achten) Date: Mon Feb 4 12:03:01 2008 Subject: 1st call for participation AFP 2008, The Netherlands Message-ID: <47A7457A.7010107@cs.ru.nl> 1ST CALL FOR PARTICIPATION 6TH INTERNATIONAL SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING 2008 (AFP ?08) RADBOUD UNIVERSITY NIJMEGEN AND UTRECHT UNIVERSITY, THE NETHERLANDS MAY 19-24, 2008 http://www.st.cs.ru.nl/AFP_TFP_2008/ AFP is a series of international summer schools which aims to bring computer scientists, in particular young researchers and programmers, up to date with the latest advances in practical advanced functional programming. Functional programming emphasizes the evaluation of expressions rather than the execution of commands. We focus on functional programming techniques in ?programming in the real world? and bridge the gap between results presented at programming conferences and material from textbooks on functional programming. In this school you will receive in depth lectures about advanced functional programming techniques, taught by experts in the field. Lectures are accompanied by practical problems to be solved by the students at the school. AFP 2008 is hosted by the Radboud University Nijmegen, and Utrecht University, The Netherlands, and will be held in the rural setting of Center Parcs ?Het Heijderbos?, Heijen (in the vicinity of Nijmegen), The Netherlands. AFP 2008 is co-located with the 9th Symposium on Trends in Functional Programming (TFP?08), which is held after AFP?08. PROGRAM INFORMATION The following speakers will give the lectures (in alphabetic order): Umut Acar (Toyota Technological Institute, University of Chicago, US) Richard Bird (University of Oxford, UK) Olivier Danvy (University of Aarhus, DK) Johan Jeuring (Utrecht University, NL) Mark Jones (Portland State University, US) Ulf Norell (Chalmers University, SE) Simon Peyton Jones (Microsoft Research, UK) Rinus Plasmeijer (Radboud University Nijmegen, NL) During the summer school, all participants receive printed lecture notes. Participants are expected to have a notebook, in order to be able to participate with the practical problems. After the summer school, all lecture notes will be revised, reviewed, and published in the LNCS series of Springer. All registered participants receive a copy of these lecture notes. VENUE INFORMATION AFP (and TFP) is held in The Netherlands, at Center Parcs ?Het Heijderbos? which is a holiday resort in the woodlands near the city of Nijmegen. We accomodate participants in DeLuxe Cottages, each of which has three separate bed-rooms, shared bathroom, toilet, kitchen, and terrace. Cottages will be shared by three participants. If you wish to reduce costs, you can choose to share a bedroom. The summer school and symposium will take place in the business center of the venue. Breakfast, lunch and diner is included within the limits of the venue. The resort features, amongst others, a sub-tropical swimming pool (free for participants), restaurants, shops, water sports lake, midget golf court, squash court, and outdoor and indoor tennis courts. Nijmegen is considered to be the oldest city of the Netherlands, being approximately 2000 years old. Nijmegen is located at the east border of the Netherlands, near Germany. Nijmegen can be reached easily from several airports such as Schiphol airport, Eindhoven airport, and D?sseldorf airport, as well as by train and car. Conveniently close to Center Parcs ?Het Heijderbos? you will find airport Weeze in Germany. The venue Center Parcs ?Het Heijderbos? can be reached from Nijmegen by train to Boxmeer (25 minutes). From there you will need to order a taxi. The venue can also be reached by car: parking is free for participants of AFP and TFP. SUMMER SCHOOL FEES AFP 2008 includes accommodation, conference, breakfast ? lunch ? diner, speakers, and proceedings costs. The early registration fee is ? 995; the late registration fee is ? 1095. Please note that if you require financial support, you can apply for a grant (see below). GRANT INFORMATION We have taken great care to reduce the registration cost as much as possible. We can grant a subsidy for a limited number of PhD student participants for whom the costs are still too high. In order to apply for this subsidy, you need to send (by surface mail or e-mail) a request for subsidy which contains your personal information, affiliation, a description of your current status, project description, a motivation why you should receive the grant, and a recommendation from your PhD supervisor. This letter should arrive before april 7 2008 to: Rinus Plasmeijer Radboud University Nijmegen Toernooiveld 1 6525ED Nijmegen rinus@cs.ru.nl You will receive a notification whether your request has been granted before april 14 2008. REGISTRATION INFORMATION Early registration opens at march 1 2008. Late registration opens at april 15 2008. Registration closes at may 5 2008. We can not guarantee accommodation in case you wish to register later than may 5 2008. IMPORTANT DATES (ALL 2008) Early Registration Opens: March 1 Early Registration Deadline: April 14 Late Registration Opens: April 15 Late Registration Deadline: May 5 AFP Summer School: May 19-24 ORGANIZATION Programme Chair: Rinus Plasmeijer, Pieter Koopman, Radboud University Nijmegen, NL Doaitse Swierstra, Utrecht University, NL Arrangements: Peter Achten, Simone Meeuwsen, Radboud University Nijmegen, NL E-mail: afp_tfp_2008@cs.ru.nl From kili at outback.escape.de Mon Feb 4 15:08:27 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon Feb 4 15:09:54 2008 Subject: Bootstrapping for Leopard In-Reply-To: <47A70279.9030706@gmail.com> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> <20080130195956.GA23183@petunia.outback.escape.de> <47A2E872.40208@gmail.com> <47A70279.9030706@gmail.com> Message-ID: <20080204200826.GA4277@petunia.outback.escape.de> On Mon, Feb 04, 2008 at 12:18:01PM +0000, Simon Marlow wrote: > Porting is "simply broken" for various reasons at the moment - in > particular the switch to Cabal for building the libraries broke it. We > knew this at the time, but felt it was more important to make the switch > now and fix bootstrapping later. Be prepared: I'll send some comments and (probably silly) questions on cvs-ghc@ in a few minutes ;-) > For pwd, I imagine the best way forward is to use a C program, I don't > think there are any deep issues there. Unless some windows people have the time to step in and help make it work with simple shell stuff, some C helpers would be just fine. Ciao, Kili From simonpj at microsoft.com Tue Feb 5 04:32:05 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 5 04:31:09 2008 Subject: GHC lazy eval optimization bug In-Reply-To: <768B04E5-0E24-4804-B786-DB69843B8986@thejenkins.org> References: <07C6CDE0-AD16-4235-BD24-0A15FA7507D2@thejenkins.org> <20080203201801.GA4558@localhost.localdomain> <768B04E5-0E24-4804-B786-DB69843B8986@thejenkins.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C31832687477@EA-EXMSG-C334.europe.corp.microsoft.com> | Thank you for the explanation. Inlining does explain the behavior I | was seeing, and -fno-state-hack does make the program behave the way | I'd expect. | | I would like to humbly submit that perhaps this optimization should be | off by default. I agree that the current behaviour sometimes bites badly, as it did for you here. Trouble is, removing the hack has (or used to have) a significant negative effect on performance of lots of programs. Still, I think that there are various other possibilities to try. For example, compiling the I/O libraries (only) with the state-hack on, and with it off by default elsewhere, might gather most of the benefits without the costs. Or restricting it to top level functions. Or something like that. It needs someone who's willing to do some measurements and try variations. We can make suggestions about things to try. Meanwhile, I'll tack these remarks onto http://hackage.haskell.org/trac/ghc/ticket/1168 Thanks for bringing this up. Simon From g9ks157k at acme.softbase.org Wed Feb 6 14:24:44 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Feb 6 14:24:05 2008 Subject: Will implicit parameters survive? Message-ID: <200802062024.44782.g9ks157k@acme.softbase.org> Hello, what are the plans for implicit parameters? Will GHC continue to support them or could it be that they will be removed at some time? I think that implicit parameters can be very useful for implementing global variables as described in . Surprisingly, the interest in implicit parameters seems to be rather low as the GHC survey from 2005 suggests. Despite this, I?d propose that support for implicit parameters continues. But what do the GHC developers think? Best wishes, Wolfgang From bulat.ziganshin at gmail.com Wed Feb 6 16:11:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 6 18:21:02 2008 Subject: Will implicit parameters survive? In-Reply-To: <200802062024.44782.g9ks157k@acme.softbase.org> References: <200802062024.44782.g9ks157k@acme.softbase.org> Message-ID: <572951047.20080207001156@gmail.com> Hello Wolfgang, Wednesday, February 6, 2008, 10:24:44 PM, you wrote: > I think that implicit parameters can be very useful for implementing global > variables as described in i everyday face the problems with global variables (that are too global, especial when you going to make your program multithreading/multiwindow/multi...) and explicit parameters which need to be passed to every serious function called. i think that implicit parameters (or at least this idea) is highly useful feature and its importance will increase as we switch to more multithreaded style of programming so, please add me to (potential) users of these feature -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dustin.deweese at gmail.com Wed Feb 6 22:12:27 2008 From: dustin.deweese at gmail.com (Dustin DeWeese) Date: Wed Feb 6 22:11:25 2008 Subject: GHC armel port for N810 In-Reply-To: <56d259a00801230432t606c15caue6a5217c0623545a@mail.gmail.com> References: <1201037179.3130.28.camel@yt1300.home.lan> <56d259a00801230432t606c15caue6a5217c0623545a@mail.gmail.com> Message-ID: <97ccbd220802061912u2c7fbdcbu701bf3ec44c007bf@mail.gmail.com> Martin, I was able to make an unregisterised port of GHC 6.8.2 to the N810 by using Scratchbox with the qemu-arm-eabi patch[1]. Have you started on a registerised port? I have been reading the ARM Architecture Reference Manual and other documents about the ARM ABI, and I am working on a registerised port of GHC for the N810. [1] http://maemogeek.blogspot.com/2007/11/installing-qemu-arm-eabi-patch-into.html On Jan 23, 2008 7:32 AM, Martin Guy wrote: > > I've been working on porting GHC to armel for the Nokia N810. > > Unfortunately, I can't use the packages you made because the OS > > (maemo.org) is based on Debian Sarge and uses libc-2.5. I'm using > > scratchbox (scratchbox.org) and qemu and following the instructions at > > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting , but have > > been unsuccessful. The stage1 compiler compiles fine, but then crashes > > when building the stage2 compiler on qemu. I've tried GHC 6.4.2, 6.6.1, > > and 6.8.2, but 6.6.1 is the version I get furthest with. Is there any > > tips you can give me? Do you still have the intermediate .hc files from > > your builds? (The .hc files built on a ARM might work better.) Did you > > have similar problems with qemu? > > I used a fast x86 to make the .hc files, as documented in the URL you > cite, > then did the final build on a lot of real ARMs. The problem is it > needs over 128MB RAM (yes, RAM) to compile some of the files - I did > these few under QEMU. My personal notes are attached - these are not a > product, they are my own personal notes, so please don't expect them > to be a how-to. Porting GHC was difficult and not straightforward, > dying at many stages for many different reasons. > > The real answer is for Maemo to update its software to versions from > this century. > I did this in 2006 trying to bootstrap the Debian arm EABI port and my > notes are at > http://cluster.aleph1.co.uk/~martin/maemo-fixes.txt > > For further help with this, I suggest we find a mailing list where > others can give their expertise and experience, and where in future > people will find the outcome of our discussion. How about > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ? > > Good luck! > > M > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080206/568d26e4/attachment.htm From simonpj at microsoft.com Thu Feb 7 05:57:24 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 7 05:56:21 2008 Subject: Will implicit parameters survive? In-Reply-To: <200802062024.44782.g9ks157k@acme.softbase.org> References: <200802062024.44782.g9ks157k@acme.softbase.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C31832710361@EA-EXMSG-C334.europe.corp.microsoft.com> I don't have any active plans to remove implicit parameters. I think they are not heavily used, but for those that do use them they seem to be quite helpful, and (important for me) their effect on the compiler is quite localised, so they cause little trouble. Still, I'm always interested to know how much interest there is in particular features. Maybe we should do a new GHC survey! S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Wolfgang Jeltsch | Sent: 06 February 2008 19:25 | To: glasgow-haskell-users@haskell.org | Subject: Will implicit parameters survive? | | Hello, | | what are the plans for implicit parameters? Will GHC continue to support them | or could it be that they will be removed at some time? | | I think that implicit parameters can be very useful for implementing global | variables as described in . | Surprisingly, the interest in implicit parameters seems to be rather low as | the GHC survey from 2005 suggests. Despite this, I?d propose that support | for implicit parameters continues. But what do the GHC developers think? | | Best wishes, | Wolfgang | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bbr at informatik.uni-kiel.de Thu Feb 7 06:09:22 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Feb 7 06:11:36 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47A2EA61.7040805@gmail.com> References: <47A1C37A.4020700@informatik.uni-kiel.de> <47A2EA61.7040805@gmail.com> Message-ID: <47AAE6E2.1010104@informatik.uni-kiel.de> I have got around the problem by defining my unsafe actions by the foreign function interface. But I still think there is a bug concerning stack use in unsafePerformIO in ghc. And I also think that this bug potentially concerns every use of unsafe. Or did I just not get the point of your argument and my answer to it was still beside the point? Greetings Bernd From simonmarhaskell at gmail.com Thu Feb 7 07:19:40 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 7 07:18:39 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47A312F1.2090500@informatik.uni-kiel.de> References: <47A1C37A.4020700@informatik.uni-kiel.de> <47A2EA61.7040805@gmail.com> <47A312F1.2090500@informatik.uni-kiel.de> Message-ID: <47AAF75C.1060606@gmail.com> Bernd Brassel wrote: > Thanks for your answer Simon. > > Simon Marlow wrote: >> Bernd Brassel wrote: >>> Consider the following program: >>> >>> module Stack where >>> >>> import System.IO.Unsafe >>> >>> main = print (sim (replicate 1299959 ())) >>> >>> sim [] = True >>> sim (_:xs) = goodStack (sim xs) >>> >>> goodStack x = fromJust (Just x) --no stack overflow >>> badStack x = unsafePerformIO (return x) --stack overflow >>> >>> fromJust (Just x) = x >> goodStack == id, and GHC even with no optimisation will transform it >> into id, and inline it into sim. So with goodStack, sim ends up being >> tail-recursive. With badStack, sim is no longer tail recursive >> (unsafePerformIO is not inlined), so it runs out of stack. Simple! > > Is it really that simple? I guess that in a lazy language we have to > look a bit closer to see what is tail recursive and what is not. If I > understand you correctly, you say that if goodStack was not inlined you > would have a bad stack as well, right? My apologies - I oversimplified things. You're quite right, it looks like the unsafePerformIO version ought to be tail-recursive too. It turns out to be rather subtle. If you replace unsafePerformIO by unsafeDupablePerformIO (from GHC.IOBase), then you do indeed get tail-recursion. But this is only due to a clever trick in the RTS: what happens is that (sim xs) is a thunk, so when evaluating it, even in a tail-recursive position, an update frame is pushed on the stack. The next recursive call to (sim xs) pushes another update frame on the stack, and so on. Since these update frames are all adjacent to one another, a trick known as "stack squeezing" can squash them down into a single frame, and this is what happens for unsafeDupablePerformIO. The ordinary unsafePerformIO is performing stack squeezing once per call, because the stack squeezing is done by the same code that does the "duplicate computation" check that unsafePerformIO needs to do. Stack squeezing doesn't look at the same bit of stack twice, so subsequent squeezings don't manage to remove any update frames. I've fixed this in my tree. It also needed some tweaks to the heuristic which decides whether to squeeze or not based on a cost/benefit tradeoff. So the upshot is: you can use unsafeDupablePerformIO right now, or you can wait until I've tested and committed this patch to get tail-recursion with unsafePerformIO. I've no idea how it works in Hugs, you'll have to ask them :) Cheers, Simon From bbr at informatik.uni-kiel.de Thu Feb 7 08:29:47 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Feb 7 08:32:35 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47AAF75C.1060606@gmail.com> References: <47A1C37A.4020700@informatik.uni-kiel.de> <47A2EA61.7040805@gmail.com> <47A312F1.2090500@informatik.uni-kiel.de> <47AAF75C.1060606@gmail.com> Message-ID: <47AB07CB.509@informatik.uni-kiel.de> Simon Marlow wrote: > So the upshot is: you can use unsafeDupablePerformIO right now, or you > can wait until I've tested and committed this patch to get > tail-recursion with unsafePerformIO. Wow, thank you for the detailed answer! That was really interesting. > I've no idea how it works in Hugs, you'll have to ask them :) At least I can tell you how it is done in that other interpreter I mentioned. The reason that you can be better for that example is that the argument of badStack is not shared. No need to push an update frame for it. I am pretty sure that it is the same with the other compiler, both for Curry not for Haskell btw., but like you I am not sure with Hugs. If the ghc does not take into account what is statically not shared, I guess there is potential for a good optimization here which would go well beyond unsafe programs. Greetings and thanks! Bernd From bbr at informatik.uni-kiel.de Thu Feb 7 09:08:06 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Feb 7 09:10:01 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47AB07CB.509@informatik.uni-kiel.de> References: <47A1C37A.4020700@informatik.uni-kiel.de> <47A2EA61.7040805@gmail.com> <47A312F1.2090500@informatik.uni-kiel.de> <47AAF75C.1060606@gmail.com> <47AB07CB.509@informatik.uni-kiel.de> Message-ID: <47AB10C6.1030706@informatik.uni-kiel.de> There is another point that makes me wonder now. If the update frame for the recursive call is the problem then my solution with foreign C functions would produce a bad stack also. But this is not the case. The code looks now like this: sim [] = True sim (_:xs) = yags (sim xs) ref = cinitialize yags x = replace (C_Ref ref) x () And it is running within 0.15M of stack. Did your explanation also account for this phenomenon? Sorry to take that much time off you with this! Bernd From bbr at informatik.uni-kiel.de Fri Feb 8 03:55:57 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Fri Feb 8 04:06:30 2008 Subject: Shared Libraries in ghci Message-ID: <47AC191D.8070209@informatik.uni-kiel.de> Sorry to ask a C question here, but I could not find an answer on the net. How do I create a library that can be used in ghci? This is the situation: I have a c file coracle.c. I do /tmp$ cc -c -o coracle.o coracle.c /tmp$ ar rc libcoracle.a coracle.o /tmp$ ranlib libcoracle.a and then I the library is linked statically with ghc just fine: /tmp$ ghc -L/tmp -lcoracle --make COracle.hs But if I create a shared library, like this: /tmp$ cc -c -shared -o libcoracle.so coracle.c then ghci does not like the format: /tmp$ ghci -L/tmp -lcoracle COracle.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) coracle ... failed. Dynamic linker error message was: /tmp/libcoracle.so: only ET_DYN and ET_EXEC can be loaded Whilst trying to load: (dynamic) coracle Directories to search are: /tmp ghc-6.8.2: user specified .o/.so/.DLL could not be loaded. In the web I only find bla about which bit in the ELF-header of the library tells you that it is ET_DYN or not. But never how to build such a library. I guess it is too much to hope for a C-freak around here but I am sure a semi-freak or quarter-freak will do as well. Thanks in advance! Bernd From simonmarhaskell at gmail.com Fri Feb 8 05:29:20 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 8 05:28:17 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47AB10C6.1030706@informatik.uni-kiel.de> References: <47A1C37A.4020700@informatik.uni-kiel.de> <47A2EA61.7040805@gmail.com> <47A312F1.2090500@informatik.uni-kiel.de> <47AAF75C.1060606@gmail.com> <47AB07CB.509@informatik.uni-kiel.de> <47AB10C6.1030706@informatik.uni-kiel.de> Message-ID: <47AC2F00.9020102@gmail.com> Bernd Brassel wrote: > There is another point that makes me wonder now. If the update frame for > the recursive call is the problem then my solution with foreign C > functions would produce a bad stack also. But this is not the case. > The code looks now like this: > > > sim [] = True > sim (_:xs) = yags (sim xs) > > ref = cinitialize > > yags x = replace (C_Ref ref) x () > > And it is running within 0.15M of stack. > Did your explanation also account for this phenomenon? > > Sorry to take that much time off you with this! > Bernd The stack of update frames is not in itself a problem, because stack squeezing removes them leaving you with O(1) stack again. The problem with unsafePerformIO was that the duplication-protection was interfering with stack squeezing. Regarding sharing analysis, we did used to have an update analyser in GHC, but it was expensive to run and rarely gave worthwhile benefits, so eventually we dropped it. Perhaps there are some trivial examples of unshared thunks that we could spot, though. Cheers, Simon From simonmarhaskell at gmail.com Fri Feb 8 05:32:09 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 8 05:31:04 2008 Subject: Shared Libraries in ghci In-Reply-To: <47AC191D.8070209@informatik.uni-kiel.de> References: <47AC191D.8070209@informatik.uni-kiel.de> Message-ID: <47AC2FA9.8000804@gmail.com> Bernd Brassel wrote: > Sorry to ask a C question here, but I could not find an answer on the net. > > How do I create a library that can be used in ghci? > > This is the situation: > I have a c file coracle.c. I do > > /tmp$ cc -c -o coracle.o coracle.c > /tmp$ ar rc libcoracle.a coracle.o > /tmp$ ranlib libcoracle.a > > and then I the library is linked statically with ghc just fine: > > /tmp$ ghc -L/tmp -lcoracle --make COracle.hs > > But if I create a shared library, like this: > > /tmp$ cc -c -shared -o libcoracle.so coracle.c Normally it's done like this: $ gcc -fPIC -c foo.c $ gcc -shared -o libfoo.so foo.o Hope this helps. Cheers, Simon > then ghci does not like the format: > > /tmp$ ghci -L/tmp -lcoracle COracle.hs > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Loading object (dynamic) coracle ... failed. > Dynamic linker error message was: > /tmp/libcoracle.so: only ET_DYN and ET_EXEC can be loaded > Whilst trying to load: (dynamic) coracle > Directories to search are: > /tmp > ghc-6.8.2: user specified .o/.so/.DLL could not be loaded. > > In the web I only find bla about which bit in the ELF-header of the > library tells you that it is ET_DYN or not. But never how to build such > a library. > > I guess it is too much to hope for a C-freak around here but I am sure a > semi-freak or quarter-freak will do as well. > > Thanks in advance! > Bernd > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bbr at informatik.uni-kiel.de Fri Feb 8 05:53:14 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Fri Feb 8 06:08:57 2008 Subject: Shared Libraries in ghci In-Reply-To: <47AC2FA9.8000804@gmail.com> References: <47AC191D.8070209@informatik.uni-kiel.de> <47AC2FA9.8000804@gmail.com> Message-ID: <47AC349A.9080301@informatik.uni-kiel.de> Simon Marlow wrote: > Normally it's done like this: > > $ gcc -fPIC -c foo.c > $ gcc -shared -o libfoo.so foo.o > > Hope this helps. Right away! Big Thanks! Bernd From robert.van.herk at philips.com Fri Feb 8 06:11:03 2008 From: robert.van.herk at philips.com (Robert van Herk) Date: Fri Feb 8 06:09:25 2008 Subject: Array.ST is not being nice to me Message-ID: Hi all, I have a problem with regards to the speed of ST arrays. In short: a Data.Map.Map outperforms Data.Array.ST in my application, whereas as far as I understand it, the ST array should be quicker. My application is a compiler. It compiles some source code into a (huge) number of boolean equations. These equations are finally printed to stdout; they form my "byte-code". Also the equations are defined in terms of the other equations again. So, for instance, compiled byte code may look like: 1 == 5 5 == True /\ 3 3 == False To optimize the compiled code, I do some tricks like constant propagation. So, for instance, if I know that one equation always results in some constant, I substitute that constant for that equation. So above set of equations will be rewritten as: 1 == False 5 == False 3 == False ------ All in all, my compiler does the following: - It generates a set of equations for some statement in the source code - It rewrites these equations - It remembers for each equation which other equations it depends upon, such that if these are rewritten to something simple, this equation may be rewritten too. So there are a lot of lookups of the equations, especially for all the rewritings. All in all, I store quite some data for each equation, amongst which are: data EquationState = EQS {cDefinition::Equation, usedBy::Map.Map Int (), ...} First, I stored all the equations in a Data.Map.Map. Int EquationState. But then I thought it'd be more clever to put it into an ST array, seen the large number of lookups. So now i put it into an ST array. However, the code runs much, much slower now (about 4 times). The ST array does use slightly less memory though. I did some profiling. It seems that it is not the GC that is making over-hours. So my theory now is: I do a large number of lookups. Only a small number of these lookups trigger a change in the array. One EquationState is pretty big. Is it so that when you look something up from an ST array, the whole element gets deeply copied in memory, just in case you would change it in the array? Seen the size of my elements, I could imagine that that would cause a whole bunch of needless copying. Or is there some other reason for this slower behaviour of ST array? Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080208/f2212257/attachment-0001.htm From bbr at informatik.uni-kiel.de Fri Feb 8 05:59:43 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Fri Feb 8 06:10:01 2008 Subject: What does unsafePerformIO do to the stack In-Reply-To: <47AC2F00.9020102@gmail.com> References: <47A1C37A.4020700@informatik.uni-kiel.de> <47A2EA61.7040805@gmail.com> <47A312F1.2090500@informatik.uni-kiel.de> <47AAF75C.1060606@gmail.com> <47AB07CB.509@informatik.uni-kiel.de> <47AB10C6.1030706@informatik.uni-kiel.de> <47AC2F00.9020102@gmail.com> Message-ID: <47AC361F.7020301@informatik.uni-kiel.de> Simon Marlow wrote: > Perhaps there are some trivial examples of > unshared thunks that we could spot, though. The sharing analysis in the interpreter is also very simple and inexpensive. But the gain is frequent. Maybe giving it a try would be worthwhile. Thanks again for all your answers! Bernd From simonpj at microsoft.com Fri Feb 8 06:12:38 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 8 06:11:31 2008 Subject: Shared Libraries in ghci In-Reply-To: <47AC349A.9080301@informatik.uni-kiel.de> References: <47AC191D.8070209@informatik.uni-kiel.de> <47AC2FA9.8000804@gmail.com> <47AC349A.9080301@informatik.uni-kiel.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C31832710AC2@EA-EXMSG-C334.europe.corp.microsoft.com> Any chance of documenting your experience on the GHC user documentation page? http://haskell.org/haskellwiki/GHC (under "collaborative documentation") A kind of how-to that worked for you, with pointers to relevant manual parts etc. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Bernd Brassel | Sent: 08 February 2008 10:53 | To: Simon Marlow | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Shared Libraries in ghci | | Simon Marlow wrote: | | > Normally it's done like this: | > | > $ gcc -fPIC -c foo.c | > $ gcc -shared -o libfoo.so foo.o | > | > Hope this helps. | | Right away! Big Thanks! | | Bernd | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From haskell at list.mightyreason.com Fri Feb 8 06:33:23 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri Feb 8 06:32:17 2008 Subject: Array.ST is not being nice to me In-Reply-To: References: Message-ID: <47AC3E03.3080803@list.mightyreason.com> > > So my theory now is: > I do a large number of lookups. Try using Data.Array.Base.unsafeRead (and maybe ata.Array.Base.unsafeWrite). These avoid the bounds checking on the index each time you lookup something in the array. From simonmarhaskell at gmail.com Fri Feb 8 07:05:53 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 8 07:04:49 2008 Subject: Array.ST is not being nice to me In-Reply-To: <47AC3E03.3080803@list.mightyreason.com> References: <47AC3E03.3080803@list.mightyreason.com> Message-ID: <47AC45A1.70101@gmail.com> Chris Kuklewicz wrote: > >> >> So my theory now is: >> I do a large number of lookups. > > Try using Data.Array.Base.unsafeRead (and maybe > ata.Array.Base.unsafeWrite). These avoid the bounds checking on the > index each time you lookup something in the array. Right. Also keep an eye on the GC time (+RTS -sstderr) if you're using boxed mutable arrays - we don't do card-marking, so GC is pretty sub-optimal when it comes to large mutable boxed arrays. Decreasing the number of GCs with +RTS -A can help if you're suffereing from this - but always try with and without, sometimes it makes things worse by making less effective use of the L2 cache. Cheers, Simon From bbr at informatik.uni-kiel.de Fri Feb 8 07:27:49 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Fri Feb 8 07:46:46 2008 Subject: Shared Libraries in ghci In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C31832710AC2@EA-EXMSG-C334.europe.corp.microsoft.com> References: <47AC191D.8070209@informatik.uni-kiel.de> <47AC2FA9.8000804@gmail.com> <47AC349A.9080301@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C31832710AC2@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47AC4AC5.2090108@informatik.uni-kiel.de> Simon Peyton-Jones wrote: > Any chance of documenting your experience on the GHC user documentation page? > http://haskell.org/haskellwiki/GHC (under "collaborative documentation") > A kind of how-to that worked for you, with pointers to relevant manual parts etc. > > Simon Is this something that would go to GHC/FAQ/4 about the GHCI? From pocm at soton.ac.uk Sat Feb 9 10:33:40 2008 From: pocm at soton.ac.uk (Paulo J. Matos) Date: Sat Feb 9 10:32:31 2008 Subject: Internships at GHC HQ In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C316EC9CDEAC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C316EC9CDEAC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <11b141710802090733t1e26cf18gb0f05e1ddf16d2ca@mail.gmail.com> On Jan 25, 2008 11:40 AM, Simon Peyton-Jones wrote: > Would you be interested in working at Microsoft Research for three months? If so, you might want to think about applying for an internship. > > Simon and I are looking for interns, starting in summer 2008. Lots of background info here: > http://hackage.haskell.org/trac/ghc/wiki/Internships > including a bunch of possible projects, although you may also have ideas of your own. > Hello Simon, I wonder if there is any interest by the part of Microsoft and the Haskell community in a software model checker using SAT-based techniques for Haskell. There's have been in the last few year a couple of approaches on this for C by several people, including some Microsoft people. Cheers, Paulo Matos > But the bottom line is > - apply by end Feb 2008 for this round > - tell one of us that you have done so > > (None of this is restricted to Haskell stuff. You can apply to work at any Microsoft Research lab, on any topic. But there are a lot of applicants, so you are more likely to be successful if you are fairly specific about who at MSR you'd like to work with and why, and contact that person to say that you've applied.) > > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK From robert.van.herk at philips.com Sat Feb 9 11:14:33 2008 From: robert.van.herk at philips.com (Robert van Herk) Date: Sat Feb 9 11:12:49 2008 Subject: Array.ST is not being nice to me In-Reply-To: <47AC45A1.70101@gmail.com> Message-ID: Hi all, > >> So my theory now is: > >> I do a large number of lookups. > > > > Try using Data.Array.Base.unsafeRead (and maybe > > ata.Array.Base.unsafeWrite). These avoid the bounds checking on the > > index each time you lookup something in the array. > > Right. Also keep an eye on the GC time (+RTS -sstderr) if you're using > boxed mutable arrays - we don't do card-marking, so GC is pretty > sub-optimal when it comes to large mutable boxed arrays. Decreasing the > number of GCs with +RTS -A can help if you're suffereing from this - > but always try with and without, sometimes it makes things worse by making > less effective use of the L2 cache. Thanks for you advice. I changed all the reads to unsafeReads and all the writes to unsafeWrites. That indeed sped up things a bit (about 10 percent on the total running time). I also checked the GC time, but that is (only) 30% of the total running time. So still, the program with ST array is about 3 times slower than the program with Data.Map. Also, the function lookupEq that looks up the states of the equations from the array, is responsible for 20% of the running time, and 19% of the allocated memory. I would say that is should allocate almost no memory: lookupEq :: Int -> MyMonad (Maybe EquationState) lookupEq cid = do s <- get mEs <- lift $ unsafeRead s cid return mEs type MyMonad a = forall s2. StateT (Eqns s2) (ST s2) a type Eqns s2 = STArray s2 Int (Maybe EquationState) data EquationState = EQS {cDefinition::Equation, usedBy::Map.Map Int (), ...} How can it be the lookupEq allocates memory? Is is not that, because of some tricky strictness/lazyness thing about ST array, unsafeRead causes the element that is read from the array to be copied in memory? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080209/95191d99/attachment.htm From jpvogel1 at gmail.com Sun Feb 10 22:26:19 2008 From: jpvogel1 at gmail.com (John Vogel) Date: Sun Feb 10 22:25:06 2008 Subject: Some problems writing a threaded program Message-ID: I am running my program in WinXP with ghc 2.6.8 If you install netstat and change the parameters it should still work in linux. Why does thread # 3 dominate over the over threads int the output? Why does thread # 4 never seem to run? I can't use the sleep function in System.Process.Win32 since it puts all the threads asleep at the same time. Is there a way to put only one thread asleep? That would allow more of a chance for thread #4 to run. The simplified program: --------------------------------------------------------------- module Main where import Data.IORef import Data.List import System.IO import System.Process import Control.Concurrent import Control.Concurrent.Chan data Connection = Null | Last | Active deriving (Eq) instance Show Connection where show Null = "Null" show Last = "Last" show Active = "Active" instance Read Connection where readsPrec _ s = case take 5 s of " UDP" -> [(Active, "")] " TCP" -> [(Active, "")] "Last" -> [(Last,"")] _ -> [(Null,"")] -- ptrints one 0 and 1 main = do stop <- newIORef False cbuffer <- newChan :: IO (Chan Connection) putStr "0" (_,output,_,ph) <- runInteractiveCommand "netstat -noa 5" sequence $ map forkIO $ [(processConnections ph output cbuffer), (stopNetstat ph stop False), (printChan cbuffer),(checkStop stop "xxxx")] putStr "1" _ <- waitForProcess ph --mapM killThread ts putStrLn "\nDone" -- thread # 2 processConnections :: ProcessHandle -> Handle -> (Chan Connection) -> IO () processConnections ph hout chan = do h <- hReady hout e <- getProcessExitCode ph putStr "2" if (not h && e /= Nothing) then do writeChan chan Last >> return () else do if h then do readConnection hout >>= writeChan chan else do processConnections ph hout chan readConnection :: Handle -> IO Connection readConnection hout = do l <- hGetLine hout let c = (read l :: Connection) if (c == Null) then do (readConnection hout) else do (return c) -- thread number 3 stopNetstat :: ProcessHandle -> (IORef Bool) -> Bool -> IO () stopNetstat netstat _ True = terminateProcess netstat stopNetstat netstat gref False = putStr "3" >> yield >> readIORef gref >>= stopNetstat netstat gref --thread 4 printChan :: (Chan Connection) -> IO () printChan chan = do putStr "4" c <- readChan chan printConnection c printChan chan checkStop :: (IORef Bool) -> String -> IO () checkStop ref s = do if (take 4 s == "stop") then do (writeIORef ref True) else do (getChar >>= (\x -> checkStop ref ((tail s) ++ [x]))) printConnection :: Connection -> IO () printConnection c = case c of Null -> putStr "N" Last -> putStr "L" _ -> putStr "A" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080210/9f15b196/attachment-0001.htm From dons at galois.com Sun Feb 10 22:28:46 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 10 22:27:31 2008 Subject: Some problems writing a threaded program In-Reply-To: References: Message-ID: <20080211032846.GC28106@scytale.galois.com> jpvogel1: > I am running my program in WinXP with ghc 2.6.8 > > If you install netstat and change the parameters it should still work in > linux. > > Why does thread # 3 dominate over the over threads int the output? > Why does thread # 4 never seem to run? > > I can't use the sleep function in System.Process.Win32 since it puts all > the > threads asleep at the same time. Is there a way to put only one thread > asleep? > > That would allow more of a chance for thread #4 to run. There is 'threadDelay' and 'yield' if you need to either sleep a thread, or explicitly trigger a scheduler event. http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4 From simonmarhaskell at gmail.com Mon Feb 11 06:20:52 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 11 06:19:37 2008 Subject: Shared Libraries in ghci In-Reply-To: <47AC4AC5.2090108@informatik.uni-kiel.de> References: <47AC191D.8070209@informatik.uni-kiel.de> <47AC2FA9.8000804@gmail.com> <47AC349A.9080301@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C31832710AC2@EA-EXMSG-C334.europe.corp.microsoft.com> <47AC4AC5.2090108@informatik.uni-kiel.de> Message-ID: <47B02F94.7040600@gmail.com> Bernd Brassel wrote: > Simon Peyton-Jones wrote: >> Any chance of documenting your experience on the GHC user documentation page? >> http://haskell.org/haskellwiki/GHC (under "collaborative documentation") >> A kind of how-to that worked for you, with pointers to relevant manual parts etc. >> >> Simon > > Is this something that would go to GHC/FAQ/4 about the GHCI? I'd put it in here: http://haskell.org/haskellwiki/GHC/Using_the_FFI Cheers, Simon From simonmarhaskell at gmail.com Mon Feb 11 06:25:58 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 11 06:24:45 2008 Subject: Array.ST is not being nice to me In-Reply-To: References: Message-ID: <47B030C6.6070403@gmail.com> Robert van Herk wrote: > Hi all, > > > > >> So my theory now is: > > >> I do a large number of lookups. > > > > > > Try using Data.Array.Base.unsafeRead (and maybe > > > ata.Array.Base.unsafeWrite). These avoid the bounds checking on the > > > index each time you lookup something in the array. > > > > Right. Also keep an eye on the GC time (+RTS -sstderr) if you're using > > boxed mutable arrays - we don't do card-marking, so GC is pretty > > sub-optimal when it comes to large mutable boxed arrays. Decreasing the > > number of GCs with +RTS -A can help if you're suffereing from > this - > > but always try with and without, sometimes it makes things worse by > making > > less effective use of the L2 cache. > > Thanks for you advice. > > I changed all the reads to unsafeReads and all the writes to > unsafeWrites. That indeed sped up things a bit (about 10 percent on the > total running time). > > I also checked the GC time, but that is (only) 30% of the total running > time. > > So still, the program with ST array is about 3 times slower than the > program with Data.Map. > > Also, the function lookupEq that looks up the states of the equations > from the array, is responsible for 20% of the running time, and 19% of > the allocated memory. I would say that is should allocate almost no memory: > > lookupEq :: Int -> MyMonad (Maybe EquationState) > lookupEq cid = > do s <- get > mEs <- lift $ unsafeRead s cid > return mEs > > type MyMonad a = forall s2. StateT (Eqns s2) (ST s2) a > type Eqns s2 = STArray s2 Int (Maybe EquationState) > > data EquationState = EQS {cDefinition::Equation, usedBy::Map.Map Int (), > ...} Perhaps your monad is not being optimised away? Look at the -ddump-simpl code for lookupEq to figure out why it is allocating memory. Cheers, Simon From simonmarhaskell at gmail.com Mon Feb 11 06:39:24 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 11 06:38:09 2008 Subject: Some problems writing a threaded program In-Reply-To: References: Message-ID: <47B033EC.1090200@gmail.com> John Vogel wrote: > I am running my program in WinXP with ghc 2.6.8 > > If you install netstat and change the parameters it should still work in > linux. > > > Why does thread # 3 dominate over the over threads int the output? > Why does thread # 4 never seem to run? > > I can't use the sleep function in System.Process.Win32 since it puts all > the > threads asleep at the same time. Is there a way to put only one thread > asleep? > > That would allow more of a chance for thread #4 to run. I haven't looked in detail at what happens in your program, but there is a matter of style here: you appear to be using busy-waiting and polling a lot. GHC's runtime shouldn't be considered "fair" in any sense other than the most basic: a thread will get to run eventually, but if it immediately blocks then it loses its timeslice. There's no guarantee that a thread will get a fair share of the CPU. So busy-waiting and polling will often suffer from a lack of fairness in the scheduler. Let me be a little more concrete: you're doing a lot of output to stdout. Now, stdout has a lock on it - only one thread can be holding stdout at any one time. Often, a thread will be preempted while holding the stdout lock, and since the other threads are all waiting to output to stdout too, none of them can make progress, so the original thread gets another timeslice (unfair!). This is why, if you try to write one of those AAAABBBB... concurrency tests using GHC, you'll probably get AAAAAAAAAA... GHC's scheduler is intentionally simple, because it is designed to cope with workloads that consist of mostly *blocked* threads, and a very few running threads. However, you might get more fairness using a couple of cores and running with +RTS -N2. Perhaps one day we'll have to consider questions of fairness and priority, hopefully in the context of a user-programmable scheduler. But for now, this is the way it is. Cheers, Simon From jpvogel1 at gmail.com Mon Feb 11 09:43:16 2008 From: jpvogel1 at gmail.com (John Vogel) Date: Mon Feb 11 09:41:57 2008 Subject: Some problems writing a threaded program In-Reply-To: <47B033EC.1090200@gmail.com> References: <47B033EC.1090200@gmail.com> Message-ID: > > Thankyou both Don Stewart and Simon Marlow for your responses. By adding yield and threadDelay in certain spots I have at least prevented some of the threads from being starved of CPU time. The only issue now is that terminateProcess doesn't always terminate netstat.exe in the cmd.exe so I don't get an exit condition. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080211/0392d336/attachment.htm From chak at cse.unsw.edu.au Mon Feb 11 22:58:09 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Feb 11 22:57:02 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) Message-ID: Ladies and Gentlemen, Finally, you can have the glorious GHC in a format satisfying the discerning Mac user: http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080211-i386.pkg Installation instructions: nil This is *not* the same compiler as in the official 6.8.2 release. It is the state of the 6.8 branch at the 11th of February - hence, the funny version number. Once, 6.8.3 is being released, there'll be a clean release package. The package includes all extra libraries and full documentation. It installs GHC systemwide and requires an admin password. Happy Installing! Manuel -=- Extra details for the curious -=- GHC is being packaged as a framework bundle - GHC.framework - that is installed in /Library/Frameworks/. As far as I can tell this is the most appropriate way of bundling a compiler environment on the Mac. Frameworks are versioned and we use GHC's integer version number to assign framework versions - ie, the present package installs version 608. This is in line with Apple's recommendation to use version numbers that signify API changes for frameworks. The package installs appropriate links in /usr/bin, /usr/man/man1, and /usr/share/doc to make the binaries, ghc manpage, and html documentation easily accessible. Furthermore, it comes with a shell script that removes the GHC.framework and all symbolic links into the framework. The framework is currently not relocatable and an admin password is needed to install it. Contributions improving this situation would be most welcome. The GHC binary in the package links statically against GNU readline (to provide editing capabilities at the GHCi prompt). This is fine as GHC's BSD3 licence is compatible with readline's GPL, and it does *not* affect programs compiled with GHC at all. The above package is for Intel Leopard. I expect that a separate PPC version is easy to build (but cross-compilation and fat binaries are not supported by GHC). I am less sure about building packages on Tiger as I don't know whether the underlying Xcode project requires Xcode 3.0 - Tiger only has 2.5. However, it should be possible to build packages on Leopard that run on both Tiger and Leopard. (I could give that a try if anybody with a Tiger box is willing to play guinea pig.) Further information on GHC installer packages as well as instructions on how to build your own are at http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer From dons at galois.com Mon Feb 11 23:02:47 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 11 23:01:31 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: References: Message-ID: <20080212040247.GA23302@scytale.galois.com> Great! Does this mean we can submit GHC to be distributed from Apple's "hackage", http://www.apple.com/downloads/ ? (Click the "Submit Downloads" button). -- Don chak: > Ladies and Gentlemen, > > Finally, you can have the glorious GHC in a format satisfying the > discerning Mac user: > > http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080211-i386.pkg > > Installation instructions: nil > > This is *not* the same compiler as in the official 6.8.2 release. It > is the state of the 6.8 branch at the 11th of February - hence, the > funny version number. Once, 6.8.3 is being released, there'll be a > clean release package. > > The package includes all extra libraries and full documentation. It > installs GHC systemwide and requires an admin password. > > Happy Installing! > Manuel > > -=- Extra details for the curious -=- > > GHC is being packaged as a framework bundle - GHC.framework - that is > installed in /Library/Frameworks/. As far as I can tell this is the > most appropriate way of bundling a compiler environment on the Mac. > Frameworks are versioned and we use GHC's integer version number to > assign framework versions - ie, the present package installs version > 608. This is in line with Apple's recommendation to use version > numbers that signify API changes for frameworks. The package installs > appropriate links in /usr/bin, /usr/man/man1, and /usr/share/doc to > make the binaries, ghc manpage, and html documentation easily > accessible. Furthermore, it comes with a shell script that removes > the GHC.framework and all symbolic links into the framework. > > The framework is currently not relocatable and an admin password is > needed to install it. Contributions improving this situation would be > most welcome. > > The GHC binary in the package links statically against GNU readline > (to provide editing capabilities at the GHCi prompt). This is fine as > GHC's BSD3 licence is compatible with readline's GPL, and it does > *not* affect programs compiled with GHC at all. > > The above package is for Intel Leopard. I expect that a separate PPC > version is easy to build (but cross-compilation and fat binaries are > not supported by GHC). I am less sure about building packages on > Tiger as I don't know whether the underlying Xcode project requires > Xcode 3.0 - Tiger only has 2.5. However, it should be possible to > build packages on Leopard that run on both Tiger and Leopard. (I > could give that a try if anybody with a Tiger box is willing to play > guinea pig.) > > Further information on GHC installer packages as well as instructions > on how to build your own are at > > http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From chak at cse.unsw.edu.au Mon Feb 11 23:29:42 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Feb 11 23:28:24 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: <20080212040247.GA23302@scytale.galois.com> References: <20080212040247.GA23302@scytale.galois.com> Message-ID: <7E7158D6-04D5-4137-9DD2-9945384BE18E@cse.unsw.edu.au> Don Stewart: > Great! > > Does this mean we can submit GHC to be distributed from Apple's > "hackage", http://www.apple.com/downloads/ ? (Click the "Submit > Downloads" button). Yes, I was thinking about that, too. However, I think we should wait until 6.8.3 and until we have a stable download url for the package. I'd also be nice to have a cool logo/icon. Manuel From dons at galois.com Mon Feb 11 23:34:14 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 11 23:33:03 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: <7E7158D6-04D5-4137-9DD2-9945384BE18E@cse.unsw.edu.au> References: <20080212040247.GA23302@scytale.galois.com> <7E7158D6-04D5-4137-9DD2-9945384BE18E@cse.unsw.edu.au> Message-ID: <20080212043414.GB23302@scytale.galois.com> chak: > Don Stewart: > >Great! > > > >Does this mean we can submit GHC to be distributed from Apple's > >"hackage", http://www.apple.com/downloads/ ? (Click the "Submit > >Downloads" button). > > Yes, I was thinking about that, too. However, I think we should wait > until 6.8.3 and until we have a stable download url for the package. > I'd also be nice to have a cool logo/icon. > Someone want to clean up the "classic" GHC logo? http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg :) From haskell at list.mightyreason.com Tue Feb 12 04:29:05 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Feb 12 04:27:47 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: References: Message-ID: <47B166E1.1000706@list.mightyreason.com> Manuel M T Chakravarty wrote: > The above package is for Intel Leopard. I expect that a separate PPC > version is easy to build (but cross-compilation and fat binaries are not > supported by GHC). I have not seen any announcement that GHC 6.8.x is working on OS X Leopard running on PPC. I would be pleased to be corrected. From chak at cse.unsw.edu.au Tue Feb 12 05:52:17 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Feb 12 05:51:03 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: <47B166E1.1000706@list.mightyreason.com> References: <47B166E1.1000706@list.mightyreason.com> Message-ID: Chris Kuklewicz: > Manuel M T Chakravarty wrote: >> The above package is for Intel Leopard. I expect that a separate >> PPC version is easy to build (but cross-compilation and fat >> binaries are not supported by GHC). > > I have not seen any announcement that GHC 6.8.x is working on OS X > Leopard running on PPC. I would be pleased to be corrected. Sorry, but my statement was only wrt to the mechanism used to build installer packages. If general compilation problems still persist, they will prevent you from constructing installer packages as well. (I haven't got a PPC, so I didn't keep track of that.) Manuel From leather at cs.uu.nl Tue Feb 12 06:06:57 2008 From: leather at cs.uu.nl (Sean Leather) Date: Tue Feb 12 06:05:36 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: References: <47B166E1.1000706@list.mightyreason.com> Message-ID: <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> Chris Kuklewicz: > > I have not seen any announcement that GHC 6.8.x is working on OS X > Leopard running on PPC. I would be pleased to be corrected. > I have Christian Maeder's distribution of 6.8.2 for Tiger (as found on the the GHC download page) running on my PowerBook G4 with Leopard. No deviations from the instructions were necessary. Manuel M T Chakravarty wrote: > > If general compilation problems still persist, they will prevent you from constructing installer packages as well. (I haven't got a PPC, so I didn't keep track of that.) > I'm planning on setting up the GHC source for building when I have time. If this happens, I will try to build the PPC package. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080212/634ecc6c/attachment.htm From gale at sefer.org Tue Feb 12 07:59:25 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Feb 12 07:58:04 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: <20080212043414.GB23302@scytale.galois.com> References: <20080212040247.GA23302@scytale.galois.com> <7E7158D6-04D5-4137-9DD2-9945384BE18E@cse.unsw.edu.au> <20080212043414.GB23302@scytale.galois.com> Message-ID: <2608b8a80802120459k7527c99r89d49d724e06cce4@mail.gmail.com> Manuel M T Chakravarty wrote: >> I'd also be nice to have a cool logo/icon. Don Stewart wrote: > Someone want to clean up the "classic" GHC logo? > http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg > :) The Clyde Arc in Glasgow, combined somehow with a lambda, could be the basis of a striking logo. Unfortunately, that bridge is suffering from some serious structural and safety issues these days, so perhaps that is ill-advised... -Yitz From gale at sefer.org Tue Feb 12 08:04:02 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Feb 12 08:02:42 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: References: Message-ID: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> Manuel M T Chakravarty wrote: > Finally, you can have the glorious GHC in a format satisfying the > discerning Mac user Fantastic news! Thanks! > The GHC binary in the package links statically against GNU readline > (to provide editing capabilities at the GHCi prompt). This is fine as > GHC's BSD3 licence is compatible with readline's GPL, and it does > *not* affect programs compiled with GHC at all. Thank you for clarifying this. > The above package is for Intel Leopard... it should be possible to > build packages on Leopard that run on both Tiger and Leopard. (I > could give that a try if anybody with a Tiger box is willing to play > guinea pig.) I volunteer. What do I need to do? Thanks, Yitz From catamorphism at gmail.com Tue Feb 12 12:17:01 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue Feb 12 12:15:40 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: <2608b8a80802120459k7527c99r89d49d724e06cce4@mail.gmail.com> References: <20080212040247.GA23302@scytale.galois.com> <7E7158D6-04D5-4137-9DD2-9945384BE18E@cse.unsw.edu.au> <20080212043414.GB23302@scytale.galois.com> <2608b8a80802120459k7527c99r89d49d724e06cce4@mail.gmail.com> Message-ID: <4683d9370802120917h5296402bl327e0770265c0556@mail.gmail.com> On 2/12/08, Yitzchak Gale wrote: > Manuel M T Chakravarty wrote: > >> I'd also be nice to have a cool logo/icon. > > Don Stewart wrote: > > Someone want to clean up the "classic" GHC logo? > > http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg > > :) > > The Clyde Arc in Glasgow, combined somehow with a lambda, > could be the basis of a striking logo. > A logo involving some stylized version of the Clyde Arc drawn so that it looks like it's bridging between a lambda and a CPU, or something like that (shades of this cartoon by Phil Wadler: http://cs.wellesley.edu/~cs301/fall03/lambda-and-chip.gif) could be cool. I am a mediocre artist, but I'd be willing to give it a try if there are no better ones around. > Unfortunately, that bridge is suffering from some serious > structural and safety issues these days, so perhaps > that is ill-advised... > It seems perfectly appropriate to me. *ducks and runs* Also, this from Manuel's original message is just beautiful: > Installation instructions: nil I'm almost tempted to switch back to a Mac. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I like my terminals like my women: VT100 compatible with Tektronix extensions." -- Sean "Teki" Dobbs From marco-oweber at gmx.de Tue Feb 12 12:38:05 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Feb 12 12:36:50 2008 Subject: slightly modified hasktags version / Who can commit it? Message-ID: <20080212173805.GA22732@gmx.de> I've hacked on hasktags again http://mawercer.de/hasktags.hs I'd like to merge changes into the ghc distribution or ask someone to do so. changes: a) full qualified module names are added as well now b) hack: removed empty tokens so that getcons finds [..] rqBody :: RqBody, [..] c) ctag files are sorted now testcase : ============= ======================================================= -- module name should be found module A.B.testcase where -- Request, Request2 -- rqMethod, rqBody, rqPeer should be found as well data Request = Request2 { rqMethod::Method, rqBody :: RqBody, rqPeer :: Host } deriving(Show,Read,Typeable) ============= ======================================================= hasktags distributed with ghc (6.8.2): Request testcase.hs 6 Request2 testcase.hs 6 rqMethod testcase.hs 6 testcase.hs 7 <<< name is missing testcase.hs 8 <<< name is missing my modified version: A.B.testcase testcase.hs 2 <<< module name added Request2 testcase.hs 6 Request testcase.hs 6 rqMethod testcase.hs 6 rqBody testcase.hs 7 rqPeer testcase.hs 8 From haskell at list.mightyreason.com Tue Feb 12 14:18:25 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Feb 12 14:17:11 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> Message-ID: <47B1F101.20804@list.mightyreason.com> I am now testing that binary distribution for powerpc on my Leopard G4 notebook. It is not always working. It is my habit to compile the Setup.hs or Setup.lhs to "setup" with "ghc --make Setup.hs -o setup". The "./setup configure ..." is working. The "./setup build" causes a segmentation fault. This is for every project I try (including ones with very default Setup.hs contents). The Cabal-1.2.3.0 used is supplied by the binary distribution of ghc 6.8.2 BUT "runghc Setup.hs build" is working. And while some things succeed, such as DList-0.4, the Network.FastCGI fails: > chrisk$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > chrisk$ runghc Setup.lhs build > Preprocessing library fastcgi-3001.0.1... > Building fastcgi-3001.0.1... > [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.o ) > [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.p_o ) > ar: creating archive dist/build/libHSfastcgi-3001.0.1.a > ar: creating archive dist/build/libHSfastcgi-3001.0.1_p.a > ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o > ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o So I sadly say there is still no working ghc 6.8.x for powerpc Leopard. -- Chris From leather at cs.uu.nl Tue Feb 12 14:43:29 2008 From: leather at cs.uu.nl (Sean Leather) Date: Tue Feb 12 14:42:07 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <47B1F101.20804@list.mightyreason.com> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> Message-ID: <35ceab3a0802121143y5a51088ar7a90fbff90ee2e40@mail.gmail.com> Hi Chris, It is my habit to compile the Setup.hs or Setup.lhs to "setup" with "ghc > --make > Setup.hs -o setup". > > The "./setup configure ..." is working. > > The "./setup build" causes a segmentation fault. This is for every > project I > try (including ones with very default Setup.hs contents). The > Cabal-1.2.3.0 > used is supplied by the binary distribution of ghc 6.8.2 > I tried the same thing and got the same result. Could it be a problem with how Cabal itself was built instead of GHC? So I sadly say there is still no working ghc 6.8.x for powerpc Leopard. > I guess you're right. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080212/b786cf0d/attachment.htm From chak at cse.unsw.edu.au Tue Feb 12 23:14:21 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Feb 12 23:13:02 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> Message-ID: <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> >> The above package is for Intel Leopard... it should be possible to >> build packages on Leopard that run on both Tiger and Leopard. (I >> could give that a try if anybody with a Tiger box is willing to play >> guinea pig.) > > I volunteer. What do I need to do? Try this http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg It's a quick build of todays HEAD with only the boot libraries. Have a look whether that installs on Tiger (I am pretty sure it will) and whether you can run /usr/bin/ghci (not so sure about that). If it works that far, please compile some small Haskell program and see whether you can run the compiled program. If we are very lucky and all of this works, please try to compile ghc itself with the compiler in the package. Thanks, Manuel PS: It's a dmg this time around, because apparently only 10.5 packages are single file archives. From simonmarhaskell at gmail.com Wed Feb 13 06:39:29 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 13 06:38:09 2008 Subject: Some problems writing a threaded program In-Reply-To: References: <47B033EC.1090200@gmail.com> Message-ID: <47B2D6F1.2060200@gmail.com> John Vogel wrote: > Thankyou both Don Stewart and Simon Marlow for your responses. > > > > By adding yield and threadDelay in certain spots I have at least prevented > some of the threads from being starved of CPU time. > > The only issue now is that terminateProcess doesn't always terminate > netstat.exe in the cmd.exe so I don't get an exit condition. Windows doesn't have the same concept of process groups that Unix has, so killing a shell doesn't necessarily kill its children. Have a look at the hoops Ian had to jump through to get this working for our timeout program in the GHC testsuite: http://darcs.haskell.org/testsuite/timeout/ Cheers, Simon From simonmarhaskell at gmail.com Wed Feb 13 06:41:41 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 13 06:40:20 2008 Subject: slightly modified hasktags version / Who can commit it? In-Reply-To: <20080212173805.GA22732@gmx.de> References: <20080212173805.GA22732@gmx.de> Message-ID: <47B2D775.5090805@gmail.com> Marc Weber wrote: > I've hacked on hasktags again > http://mawercer.de/hasktags.hs > I'd like to merge changes into the ghc distribution or ask someone to do > so. > > changes: > a) full qualified module names are added as well now > b) hack: removed empty tokens so that getcons finds > [..] rqBody :: RqBody, [..] > c) ctag files are sorted now Have you fixed this? http://hackage.haskell.org/trac/ghc/ticket/1184 Would you mind opening a ticket, or using 'darcs send' to send us a patch? Cheers, Simon From Christian.Maeder at dfki.de Wed Feb 13 06:53:57 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 13 06:52:34 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <47B1F101.20804@list.mightyreason.com> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> Message-ID: <47B2DA55.9040805@dfki.de> Chris Kuklewicz wrote: > The "./setup build" causes a segmentation fault. This is for every > project I try (including ones with very default Setup.hs contents). I can at least reproduce the segmentation fault by running my PPC-Tiger binary on an i386-Leopard, by compiling with additional options "-optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc". m29:fastcgi-3001.0.1 maeder$ ghc -opta-arch -optappc -optl-arch -optlppc --make Setup.lhs Linking Setup ... m29:fastcgi-3001.0.1 maeder$ ./Setup configure Configuring fastcgi-3001.0.1... Warning: No license-file field. m29:fastcgi-3001.0.1 maeder$ ./Setup build Segmentation fault and even (after adding the above options to the bin/ghc-6.8.2 script) m29:fastcgi-3001.0.1 maeder$ runghc Setup.lhs build Preprocessing library fastcgi-3001.0.1... Building fastcgi-3001.0.1... [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.o ) ar: creating archive dist/build/libHSfastcgi-3001.0.1.a ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o Cheers Christian From kr.angelov at gmail.com Wed Feb 13 07:30:09 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Feb 13 07:28:45 2008 Subject: Some problems writing a threaded program In-Reply-To: References: <47B033EC.1090200@gmail.com> Message-ID: 2008/2/11 John Vogel : > The only issue now is that terminateProcess doesn't always terminate > netstat.exe in the cmd.exe so I don't get an exit condition. A simple way is to use runInteractiveProcess instead of runInteractiveCommand. The former doesn't start a new cmd.exe but starts netstat.exe directly. There isn't point of using runInteractiveCommand unless you want to execute some shell commands or batch files. Regards, Krasimir From gale at sefer.org Wed Feb 13 12:51:21 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Feb 13 12:49:57 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> Message-ID: <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> Manuel M T Chakravarty wrote: > Try this > http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg I got it, but there were some download problems. I hope the file is intact. It has exactly 44740924 bytes. Perhaps you could send me an md5sum to be certain. > Have a look whether that installs on Tiger > (I am pretty sure it will) It did. > and whether you can run /usr/bin/ghci (not so sure about that). It didn't. $ /usr/bin/ghci Bus error In the readme, you say that I require Xcode 3.0. Tiger came with Xcode 2.4.1, and I have not updated it. (I tried once, but the download was so huge that I decided to forget it unless there was some real need.) Could that be part of the problem? Thanks, Yitz From Christian.Maeder at dfki.de Thu Feb 14 03:26:47 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 03:25:28 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <47B1F101.20804@list.mightyreason.com> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> Message-ID: <47B3FB47.5050301@dfki.de> Could you create a ticket for this (or is there one already)? I'm willing to recompile ghc-6.8.2 with different options or patches on PPC Tiger, but even compiling via-C does not work (not to mention bootstrapping from hc sources). http://hackage.haskell.org/trac/ghc/ticket/2012 (Only few seem to be interested in getting PPC bugs fixed. Is this architecture dying out?) Cheers Christian Does ghc-6.8.1 or ghc-6.6.1 work on PPC leopard and can be used for compiling ghc-6.8.2? Chris Kuklewicz wrote: > I am now testing that binary distribution for powerpc on my Leopard G4 > notebook. > > It is not always working. > > It is my habit to compile the Setup.hs or Setup.lhs to "setup" with "ghc > --make Setup.hs -o setup". > > The "./setup configure ..." is working. > > The "./setup build" causes a segmentation fault. This is for every > project I try (including ones with very default Setup.hs contents). The > Cabal-1.2.3.0 used is supplied by the binary distribution of ghc 6.8.2 > > BUT "runghc Setup.hs build" is working. > > And while some things succeed, such as DList-0.4, the Network.FastCGI > fails: > >> chrisk$ ghc --version >> The Glorious Glasgow Haskell Compilation System, version 6.8.2 > >> chrisk$ runghc Setup.lhs build >> Preprocessing library fastcgi-3001.0.1... >> Building fastcgi-3001.0.1... >> [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, >> dist/build/Network/FastCGI.o ) >> [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, >> dist/build/Network/FastCGI.p_o ) >> ar: creating archive dist/build/libHSfastcgi-3001.0.1.a >> ar: creating archive dist/build/libHSfastcgi-3001.0.1_p.a >> ld: atom sorting error for >> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and >> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in >> dist/build/Network/FastCGI.o >> ld: atom sorting error for >> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and >> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in >> dist/build/Network/FastCGI.o > > So I sadly say there is still no working ghc 6.8.x for powerpc Leopard. > From Alistair_Bayley at invescoperpetual.co.uk Thu Feb 14 04:35:48 2008 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Thu Feb 14 04:34:29 2008 Subject: ghc-6.8.1 on WinXP: windres: can't open font file `for' Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> I've just installed ghc-6.8.1 on my WinXP workstation (I already have it successfully working on my laptop). When I compile anything, the linking stage fails with: c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory Any clues as to what's wrong? Google isn't very helpful... (I've stripped my path back to just windows, windows\system32, and ghc, but no joy). Alistair P.S. output from ghc -v3 (trimmed): Linking Main.exe ... *** Windres: c:\ghc\ghc-6.8.1\bin/windres --preprocessor=c:\ghc\ghc-6.8.1\gcc -Bc:\ghc\ghc-6.8.1\gcc-lib/ -E -xc -DRC_INVOKED --input=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.rc --output=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.o --output-format=coff c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory The .rc file it is given contains: 1 24 MOVEABLE PURE "Main.exe.manifest" so this "... font file 'for':..." message is a puzzle. ***************************************************************** 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 chak at cse.unsw.edu.au Thu Feb 14 05:09:07 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Feb 14 05:07:48 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> Message-ID: <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> Yitzchak Gale: > Manuel M T Chakravarty wrote: >> Try this >> http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg > > I got it, but there were some download problems. I hope the > file is intact. It has exactly 44740924 bytes. Perhaps you > could send me an md5sum to be certain. The file length is correct. wireless-139 chak 2 (/Users/chak): md5 Public/Web/haskell/ GHC-6.9.20080213-i386.dmg MD5 (Public/Web/haskell/GHC-6.9.20080213-i386.dmg) = cc76dea615234aa83d85ef5c30021828 >> and whether you can run /usr/bin/ghci (not so sure about that). > > It didn't. > > $ /usr/bin/ghci > Bus error > > In the readme, you say that I require Xcode 3.0. Tiger came with > Xcode 2.4.1, and I have not updated it. (I tried once, but the > download was so huge that I decided to forget it unless there > was some real need.) Could that be part of the problem? If ghc worked in the past on your machine, then your Xcode version should be fine. (It's really only important that we have a version of gcc that plays nicely with ghc.) But you are right, I need to update that readme for Tiger (the recommendation for 3.0 really only applies to Leopard.) I had a closer look at cross compilation for 10.4 and I think I know why we get the bus error and how to avoid it. To avoid you having to download another GHC build, which may have problems again, I have compiled two versions of hello world and put them in a tar ball at http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2 It contains HelloWorld-Leopard and HelloWorld-Tiger. Please try to run them both. I believe HelloWorld-Leopard will also give you a bus error, but I hope HelloWorld-Tiger will work. (Interestingly HelloWorld-Tiger is about 8x bigger than HelloWorld- Leopard. I don't think this has anything to do with GHC, but is due to Apple's cross-compilation SDK.) Manuel From gale at sefer.org Thu Feb 14 05:35:00 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 14 05:33:33 2008 Subject: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel) In-Reply-To: <4683d9370802120917h5296402bl327e0770265c0556@mail.gmail.com> References: <20080212040247.GA23302@scytale.galois.com> <7E7158D6-04D5-4137-9DD2-9945384BE18E@cse.unsw.edu.au> <20080212043414.GB23302@scytale.galois.com> <2608b8a80802120459k7527c99r89d49d724e06cce4@mail.gmail.com> <4683d9370802120917h5296402bl327e0770265c0556@mail.gmail.com> Message-ID: <2608b8a80802140235pc1f9badrb6205735d2887314@mail.gmail.com> Manuel M T Chakravarty wrote: >> I'd also be nice to have a cool logo/icon. Tim Chevalier wrote: > I am a mediocre artist, but I'd be willing to give it a try if there > are no better ones around. Sounds great, please give it a whirl. > I'm almost tempted to switch back to a Mac. Since you have been a Mac user, you are aware of how fidgety this platform is about aesthetics. We all appreciate the overall pleasant experience, but it creates a challenge if you want to do something seemingly simple like create a decent icon. I'm sure whatever you do will be great for our purposes. But FWIW, in case you don't have it, here is a link to the section devoted to icons in the "Apple Human Interface Guidelines": http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIcons/chapter_15_section_1.html#//apple_ref/doc/uid/20000967-TP6 http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelines.pdf Thanks, Yitz From chak at cse.unsw.edu.au Thu Feb 14 05:36:23 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Feb 14 05:35:10 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <47B2DA55.9040805@dfki.de> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> <47B2DA55.9040805@dfki.de> Message-ID: <6DA05F20-DF7F-4305-B06E-44B15338FFE6@cse.unsw.edu.au> Christian Maeder: > Chris Kuklewicz wrote: >> The "./setup build" causes a segmentation fault. This is for every >> project I try (including ones with very default Setup.hs contents). > > I can at least reproduce the segmentation fault by running my PPC- > Tiger > binary on an i386-Leopard, by compiling with additional options > "-optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc". > > m29:fastcgi-3001.0.1 maeder$ ghc -opta-arch -optappc -optl-arch - > optlppc > --make Setup.lhs > Linking Setup ... > m29:fastcgi-3001.0.1 maeder$ ./Setup configure > Configuring fastcgi-3001.0.1... > Warning: No license-file field. > m29:fastcgi-3001.0.1 maeder$ ./Setup build > Segmentation fault I can't see how ghc can generate a correct executable if you pass these cross-compilation options to GHC. Even if you can get GHC to generate proper PPC code, it will link against *Haskell* libraries that contain i386 code. (The options -optl-arch -optlppc will give you the PPC versions of the system libraries, but not the GHC packages.) Or am I missing something? > and even (after adding the above options to the bin/ghc-6.8.2 script) > > m29:fastcgi-3001.0.1 maeder$ runghc Setup.lhs build > Preprocessing library fastcgi-3001.0.1... > Building fastcgi-3001.0.1... > [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, > dist/build/Network/FastCGI.o ) > ar: creating archive dist/build/libHSfastcgi-3001.0.1.a > ld: atom sorting error for > _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and > _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in > dist/build/Network/FastCGI.o > ld: atom sorting error for > _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and > _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in > dist/build/Network/FastCGI.o According to Wolfgang Thaller's answer to a previous post by yourself, these atom sorting errors are harmless: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013988.html Manuel From haskell at list.mightyreason.com Thu Feb 14 06:17:48 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Thu Feb 14 06:16:30 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <47B3FB47.5050301@dfki.de> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> <47B3FB47.5050301@dfki.de> Message-ID: <47B4235C.5090303@list.mightyreason.com> Christian Maeder wrote: > Could you create a ticket for this (or is there one already)? There have been a few tickets, some still outstanding, about leopard powerpc failures. > I'm > willing to recompile ghc-6.8.2 with different options or patches on PPC > Tiger, but even compiling via-C does not work (not to mention > bootstrapping from hc sources). > > http://hackage.haskell.org/trac/ghc/ticket/2012 > > (Only few seem to be interested in getting PPC bugs fixed. Is this > architecture dying out?) I submitted a patch that went into ghc-6.8.x to help fix assembly code generation (to keey the new cursed 'ld' happy) on powerpc 10.5.x Apple stopped creating and selling new PPC machines some time ago. But I think nearly half of the running machines are still PPC. But only people with previous PPC hardware who buy new OS X 10.5 and also want ghc-6.8 are getting bitten. > Cheers Christian > > Does ghc-6.8.1 or ghc-6.6.1 work on PPC leopard and can be used for > compiling ghc-6.8.2? > The ghc-6.6.1 I had under 10.4 still works like a champ after upgrading to 10.5 -- Chris From Christian.Maeder at dfki.de Thu Feb 14 07:09:50 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 07:08:25 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <6DA05F20-DF7F-4305-B06E-44B15338FFE6@cse.unsw.edu.au> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> <47B2DA55.9040805@dfki.de> <6DA05F20-DF7F-4305-B06E-44B15338FFE6@cse.unsw.edu.au> Message-ID: <47B42F8E.8010206@dfki.de> Manuel M T Chakravarty wrote: > I can't see how ghc can generate a correct executable if you pass these > cross-compilation options to GHC. Even if you can get GHC to generate > proper PPC code, it will link against *Haskell* libraries that contain > i386 code. Of course I'm using a PPC haskell compiler on i368 with its PCC *Haskell* libraries. HTH Christian From Christian.Maeder at dfki.de Thu Feb 14 08:10:29 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 08:09:05 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <6DA05F20-DF7F-4305-B06E-44B15338FFE6@cse.unsw.edu.au> References: <47B166E1.1000706@list.mightyreason.com> <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> <47B2DA55.9040805@dfki.de> <6DA05F20-DF7F-4305-B06E-44B15338FFE6@cse.unsw.edu.au> Message-ID: <47B43DC5.3040108@dfki.de> Manuel M T Chakravarty wrote: >> ld: atom sorting error for >> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and >> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in >> dist/build/Network/FastCGI.o > > According to Wolfgang Thaller's answer to a previous post by yourself, > these atom sorting errors are harmless: > > > http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013988.html Indeed, a final "runghc Setup.lhs install" worked for me. Christian m29:~ maeder$ ghc-pkg list /home/mac-bkb/ghc/ghc-6.8.2/lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, HaXml-1.13.2, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, xhtml-3000.0.2.1 /home/maeder/.ghc/powerpc-darwin-6.8.2/package.conf: HAIFA-0.11, HTTP-3001.0.0.1, Shellac-0.9, Shellac-readline-0.9, fastcgi-3001.0.1, hxt-7.3, programatica-1.0, syb-generics-2.9 m29:~ maeder$ uname -a Darwin m29.informatik.uni-bremen.de 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 From phonohawk at ps.sakura.ne.jp Thu Feb 14 09:07:11 2008 From: phonohawk at ps.sakura.ne.jp (PHO) Date: Thu Feb 14 09:05:54 2008 Subject: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page In-Reply-To: <47B3FB47.5050301@dfki.de> References: <35ceab3a0802120306t5fa5ab98v7047e3d6871cddb6@mail.gmail.com> <47B1F101.20804@list.mightyreason.com> <47B3FB47.5050301@dfki.de> Message-ID: <20080214.230711.208960998.phonohawk@ps.sakura.ne.jp> From: Christian Maeder Subject: Re: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page Date: Thu, 14 Feb 2008 09:26:47 +0100 > Could you create a ticket for this (or is there one already)? I'm > willing to recompile ghc-6.8.2 with different options or patches on PPC > Tiger, but even compiling via-C does not work (not to mention > bootstrapping from hc sources). > > http://hackage.haskell.org/trac/ghc/ticket/2012 > > (Only few seem to be interested in getting PPC bugs fixed. Is this > architecture dying out?) At least I'm still happily using ghc-6.8.2 with PPC Tiger because I know there are lots of lots of problems in Leopard. Please don't abandon PPC... _______________________________________________________ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080214/7644d639/attachment-0001.bin From gale at sefer.org Thu Feb 14 14:19:46 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 14 14:18:18 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> Message-ID: <2608b8a80802141119k1e6e4fbbh4ad0598621288586@mail.gmail.com> Manuel M T Chakravarty wrote: > The file length is correct. > MD5 (Public/Web/haskell/GHC-6.9.20080213-i386.dmg) = > cc76dea615234aa83d85ef5c30021828 Bingo! Thanks. I wrote: >> In the readme, you say that I require Xcode 3.0. Tiger came with >> Xcode 2.4.1, and I have not updated it. Could that be part of the >> problem? > ...your Xcode version should be fine. OK, good. > http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2 > It contains HelloWorld-Leopard and HelloWorld-Tiger. Please try to > run them both. I believe HelloWorld-Leopard will also give you a bus > error, but I hope HelloWorld-Tiger will work. $ ./HelloWorld-Tiger Hello World! $ ./HelloWorld-Leopard Bus error Yay! Thanks, Yitz From catamorphism at gmail.com Thu Feb 14 18:20:43 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Feb 14 18:19:14 2008 Subject: GHC logo ideas (was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)) Message-ID: <4683d9370802141520j43714b1ct1623a3d715e64f77@mail.gmail.com> On 2/14/08, Yitzchak Gale wrote: > Manuel M T Chakravarty wrote: > >> I'd also be nice to have a cool logo/icon. > > > Tim Chevalier wrote: > > I am a mediocre artist, but I'd be willing to give it a try if there > > are no better ones around. > > > Sounds great, please give it a whirl. > Well, I got bored in class, so here's a sketch: http://lafalafu.com/krc/Scratch/ghc-logo-idea.png This is still based on Yitzhak's idea of incorporating the Clyde Arc. The extra bit of the lambda that extends on the left and turns into a chip is meant to look like the bridge, though I'm not sure I got the shape right. I hereby release the above-linked image into the public domain. If anyone wants to mess with it or make something prettier that's based on the same idea, feel free. If anyone likes it, I could try to turn this into something more polished. I'm not sure to what extent GHC-land is crying out for a new logo, though... > > > I'm almost tempted to switch back to a Mac. > > > Since you have been a Mac user, you are aware of how > fidgety this platform is about aesthetics. We all appreciate Well, that was actually just in response to the "Installation instructions: nil" comment in the OP. I'd love to use something that has no installation instructions :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I do not write about nice people. I am not nice people." -- Dorothy Allison From chak at cse.unsw.edu.au Thu Feb 14 18:24:23 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Feb 14 18:22:57 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <2608b8a80802141119k1e6e4fbbh4ad0598621288586@mail.gmail.com> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> <2608b8a80802141119k1e6e4fbbh4ad0598621288586@mail.gmail.com> Message-ID: Yitzchak Gale: > Manuel M T Chakravarty wrote: >> http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2 >> It contains HelloWorld-Leopard and HelloWorld-Tiger. Please try to >> run them both. I believe HelloWorld-Leopard will also give you a bus >> error, but I hope HelloWorld-Tiger will work. > > $ ./HelloWorld-Tiger > Hello World! > $ ./HelloWorld-Leopard > Bus error Great. Then, I think I know what to do. I'll add a new option to configure to specify what Apple calls the "deployment target" of a GHC build. By using 10.4 as the deployment target we can then build GHC distributions in any form (installer, binary dist, or local installs) for 10.4 on a 10.5 box. However, some extra fiddling will be required to make sure utilities, such as ghc-pkg, are also properly cross- compiled. I'll let you know when I have got a new GHC installer using this approach. Manuel From asviraspossible at gmail.com Thu Feb 14 19:07:06 2008 From: asviraspossible at gmail.com (Victor Nazarov) Date: Thu Feb 14 19:05:37 2008 Subject: GHC logo ideas (was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)) In-Reply-To: <4683d9370802141520j43714b1ct1623a3d715e64f77@mail.gmail.com> References: <4683d9370802141520j43714b1ct1623a3d715e64f77@mail.gmail.com> Message-ID: On Fri, Feb 15, 2008 at 2:20 AM, Tim Chevalier wrote: > > Well, I got bored in class, so here's a sketch: > http://lafalafu.com/krc/Scratch/ghc-logo-idea.png > > This is still based on Yitzhak's idea of incorporating the Clyde Arc. > The extra bit of the lambda that extends on the left and turns into a > chip is meant to look like the bridge, though I'm not sure I got the > shape right. > > I hereby release the above-linked image into the public domain. If > anyone wants to mess with it or make something prettier that's based > on the same idea, feel free. If anyone likes it, I could try to turn > this into something more polished. > The same Idea, but my try: http://img120.imageshack.us/my.php?image=ghclogoprojecteh4.png -- vir http://vir.comtv.ru/ From petersen at haskell.org Fri Feb 15 02:08:48 2008 From: petersen at haskell.org (Jens Petersen) Date: Fri Feb 15 02:07:18 2008 Subject: building ghc-6.8.2 network library fails under gcc43 Message-ID: (I know gcc-4.3 is still under development, but it is expected to be the version of gcc in Fedora 9 which will be released around the end of April.) Has anyone tried or managed to build ghc with gcc-4.3? I tried yesterday in the Fedora buildsystem and got to: Socket.hsc: In function 'main': Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1150: error: invalid use of undefined type 'struct ucred' Socket.hsc:1151: error: invalid use of undefined type 'struct ucred' Socket.hsc:1152: error: invalid use of undefined type 'struct ucred' Socket.hsc:2419: error: 'NI_MAXHOST' undeclared (first use in this function) Socket.hsc:2419: error: (Each undeclared identifier is reported only once Socket.hsc:2419: error: for each function it appears in.) Socket.hsc:2420: error: 'NI_MAXSERV' undeclared (first use in this function) compiling dist/build/Network/Socket_hsc_make.c failed command was: gcc -c -D__GLASGOW_HASKELL__=608 -I/builddir/build/BUILD/ghc-6.8.2/includes -I/builddir/build/BUILD/ghc-6.8.2/gmp/gmpbuild -D__GLASGOW_HASKELL__=608 -DCALLCONV=ccall -Iinclude dist/build/Network/Socket_hsc_make.c -o dist/build/Network/Socket_hsc_make.o Preprocessing library network-2.1.0.0... The full buildlog is at http://koji.fedoraproject.org/koji/getfile?taskID=425959&name=build.log Before investigating further I just wondered if anyone has already looked at this and might have a patch or workaround? Jens From simonmarhaskell at gmail.com Fri Feb 15 09:26:55 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 15 09:25:28 2008 Subject: ghc-6.8.1 on WinXP: windres: can't open font file `for' In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> References: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> Message-ID: <47B5A12F.70002@gmail.com> Bayley, Alistair wrote: > I've just installed ghc-6.8.1 on my WinXP workstation (I already have it > successfully working on my laptop). When I compile anything, the linking > stage fails with: > > c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file > or directory This one was fixed in 6.8.2. Cheers, Simon From Alistair_Bayley at invescoperpetual.co.uk Fri Feb 15 09:50:32 2008 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Fri Feb 15 09:49:02 2008 Subject: ghc-6.8.1 on WinXP: windres: can't open font file `for' In-Reply-To: <47B5A12F.70002@gmail.com> References: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> <47B5A12F.70002@gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E92BC@GBLONXMB02.corp.amvescap.net> > From: Simon Marlow [mailto:simonmarhaskell@gmail.com] > > > c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': > > No such file or directory > > This one was fixed in 6.8.2. Bummer. I was hoping to be able to use 6.8.1 with gtk2hs (AFAIUI, gtk2hs doesn't work with/hasn't been compiled against 6.8.2 yet). Is there a workaround or something I can tweak in my 6.8.1 installation? Alistair ***************************************************************** 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 ndmitchell at gmail.com Fri Feb 15 10:13:26 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 15 10:11:54 2008 Subject: ghc-6.8.1 on WinXP: windres: can't open font file `for' In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E92BC@GBLONXMB02.corp.amvescap.net> References: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> <47B5A12F.70002@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92BC@GBLONXMB02.corp.amvescap.net> Message-ID: <404396ef0802150713i1809dc1ek4177d74664cfedc0@mail.gmail.com> Alistair, > Bummer. I was hoping to be able to use 6.8.1 with gtk2hs (AFAIUI, gtk2hs > doesn't work with/hasn't been compiled against 6.8.2 yet). Is there a > workaround or something I can tweak in my 6.8.1 installation? It's much easier to gently prod Duncan until he gives in and releases a new gtk2hs version. Thanks Neil /me commences the prodding From Alistair_Bayley at invescoperpetual.co.uk Fri Feb 15 10:21:19 2008 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Fri Feb 15 10:19:49 2008 Subject: ghc-6.8.1 on WinXP: windres: can't open font file `for' In-Reply-To: <404396ef0802150713i1809dc1ek4177d74664cfedc0@mail.gmail.com> References: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> <47B5A12F.70002@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92BC@GBLONXMB02.corp.amvescap.net> <404396ef0802150713i1809dc1ek4177d74664cfedc0@mail.gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E92BD@GBLONXMB02.corp.amvescap.net> > From: Neil Mitchell [mailto:ndmitchell@gmail.com] > > > Bummer. I was hoping to be able to use 6.8.1 with gtk2hs > (AFAIUI, gtk2hs > > doesn't work with/hasn't been compiled against 6.8.2 yet). > Is there a > > workaround or something I can tweak in my 6.8.1 installation? > > It's much easier to gently prod Duncan until he gives in and releases > a new gtk2hs version. Maybe... the fact that I don't have this problem with 6.8.1 on my laptop implies that there *might* be something external to ghc that I can change that would fix it. Alistair ***************************************************************** 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 igloo at earth.li Fri Feb 15 13:49:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Feb 15 13:48:11 2008 Subject: slightly modified hasktags version / Who can commit it? In-Reply-To: <20080212173805.GA22732@gmx.de> References: <20080212173805.GA22732@gmx.de> Message-ID: <20080215184941.GA6518@matrix.chaos.earth.li> Hi Marc, On Tue, Feb 12, 2008 at 06:38:05PM +0100, Marc Weber wrote: > I've hacked on hasktags again > http://mawercer.de/hasktags.hs > I'd like to merge changes into the ghc distribution or ask someone to do > so. Thanks! I assume that this is the same as http://mawercer.de/hasktags_patch in which case I've applied it. Thanks Ian From bos at serpentine.com Fri Feb 15 14:43:47 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Feb 15 14:42:14 2008 Subject: building ghc-6.8.2 network library fails under gcc43 In-Reply-To: References: Message-ID: <47B5EB73.50800@serpentine.com> Jens Petersen wrote: > Has anyone tried or managed to build ghc with gcc-4.3? The failures you report seem to be due to changes in glibc headers in Rawhide. References: <20080212173805.GA22732@gmx.de> <47B2D775.5090805@gmail.com> Message-ID: <20080216030319.GA26659@gmx.de> Hi Simon, thanks for pointing me to the ticket (therby telling me that hasktags was not really usable before ?). The ticket can be marked as fixed now I hope. I've tried enhancing it but I don't know wether it still finds everyting in all cases. So more testing is needed. I've included a small testcase within comments which shows that the patch enables hasktags to find twice as much tags as before (type annotations and implementations) Maybe you, Ian or sb. else can apply this patch as well? http://mawercer.de/hasktags_patch2 Sincerly Marc From waldmann at imn.htwk-leipzig.de Sat Feb 16 10:53:24 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Feb 16 10:51:57 2008 Subject: ghci feature request: partially read modules Message-ID: <47B706F4.4090206@imn.htwk-leipzig.de> Hello. Here is one ghci feature that I find mildly annoying: If ghci (re-)reads a module that contains some error, then it considers the module loading as a complete failure, and at the prompt I get the Prelude environment. I'd like to have at least the import statements executed, and possibly the declarations that were error-free. That would help me in interactively debugging the erraneous part of the module. (Often the error is some type error, related to some imported entity; but when my module contains the error, then the imports are gone.) Perhaps I'm doing something wrong, then please educate me; or perhaps there's an easy way to implement partial reading and typechecking. (It'd be enough to have this for the "current" module, of course.) Thanks - Johannes Waldmann. From dbueno at gmail.com Sat Feb 16 10:56:31 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Feb 16 10:54:57 2008 Subject: ghci feature request: partially read modules In-Reply-To: <47B706F4.4090206@imn.htwk-leipzig.de> References: <47B706F4.4090206@imn.htwk-leipzig.de> Message-ID: <6dbd4d000802160756x1cc567b2v1dedda583c77e73c@mail.gmail.com> On Sat, Feb 16, 2008 at 10:53 AM, Johannes Waldmann wrote: > If ghci (re-)reads a module that contains some error, > then it considers the module loading as a complete failure, > and at the prompt I get the Prelude environment. > > I'd like to have at least the import statements executed, > and possibly the declarations that were error-free. Seconded. > Perhaps I'm doing something wrong, then please educate me; Seconded, again. -- Denis From stefanor at cox.net Sat Feb 16 12:12:24 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 16 12:10:50 2008 Subject: ghci feature request: partially read modules In-Reply-To: <47B706F4.4090206@imn.htwk-leipzig.de> References: <47B706F4.4090206@imn.htwk-leipzig.de> Message-ID: <20080216171224.GA3126@localhost.localdomain> On Sat, Feb 16, 2008 at 04:53:24PM +0100, Johannes Waldmann wrote: > Hello. > > Here is one ghci feature that I find mildly annoying: > > If ghci (re-)reads a module that contains some error, > then it considers the module loading as a complete failure, > and at the prompt I get the Prelude environment. > > I'd like to have at least the import statements executed, > and possibly the declarations that were error-free. > That would help me in interactively debugging > the erraneous part of the module. > (Often the error is some type error, related to some imported entity; > but when my module contains the error, then the imports are gone.) > > Perhaps I'm doing something wrong, then please educate me; > or perhaps there's an easy way to implement partial reading > and typechecking. (It'd be enough to have this for the "current" > module, of course.) > > Thanks - Johannes Waldmann. This is fairly easy for type errors - just have the 'type of expression' function return errors using Either etc, and at the top level drop all expressions with error type. As for parse errors - good luck. Haskell is incredibly difficult to parse even if you ignore several of its less-friendly features. If you allow them... for a long time I said it had never even been proven possible, but then I found a workable algorithm exponential in the file size. Now, how do you propose handling parse errors? Here's an example of why it's hardly trivial: foo = x + y + z where { x = 2; y = 3; z = 4; } Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080216/e9588fb3/attachment.bin From waldmann at imn.htwk-leipzig.de Sat Feb 16 12:58:29 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Feb 16 12:56:53 2008 Subject: ghci feature request: partially read modules In-Reply-To: <20080216171224.GA3126@localhost.localdomain> References: <47B706F4.4090206@imn.htwk-leipzig.de> <20080216171224.GA3126@localhost.localdomain> Message-ID: <47B72445.9060005@imn.htwk-leipzig.de> Sure. Syntax errors are usually easy to spot and fix (for the programmer who uses some reasonable code layout); the motivation for my proposal was type errors. I think it would be perfectly acceptable if ghci rejects modules with parse errors (as it does now) but handles modules with type errors more gracefully. Since type checking a group of declarations (= a module) often considers all declarations at the same time, there may be no sensible way to proceed after a type error. Then it would even be OK to not bind any of the identifiers of the module, as long as the import declarations are available at ghci prompt. (This would still be an improvement over the present situation.) Best regards, Johannes. From stefanor at cox.net Sat Feb 16 13:13:42 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 16 13:12:09 2008 Subject: ghci feature request: partially read modules In-Reply-To: <47B72445.9060005@imn.htwk-leipzig.de> References: <47B706F4.4090206@imn.htwk-leipzig.de> <20080216171224.GA3126@localhost.localdomain> <47B72445.9060005@imn.htwk-leipzig.de> Message-ID: <20080216181342.GA3923@localhost.localdomain> On Sat, Feb 16, 2008 at 06:58:29PM +0100, Johannes Waldmann wrote: > Sure. > > Syntax errors are usually easy to spot and fix > (for the programmer who uses some reasonable code layout); > the motivation for my proposal was type errors. > > I think it would be perfectly acceptable > if ghci rejects modules with parse errors (as it does now) > but handles modules with type errors more gracefully. > > Since type checking a group of declarations (= a module) > often considers all declarations at the same time, > there may be no sensible way to proceed after a type error. > > Then it would even be OK > to not bind any of the identifiers of the module, > as long as the import declarations are available at ghci prompt. > (This would still be an improvement over the present situation.) Implementing Haskell polymorphism requires that the functions be sorted into dependancy groups, so that undepended definitions can be generalized. Example: foo x = 2 bar = foo 'a' + foo True If this were typechecked all at once (using the standard Damas-Milner algorithm) you would get a "cannot match Bool to Char" type error. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080216/f5076397/attachment.bin From marco-oweber at gmx.de Sat Feb 16 21:04:59 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Feb 16 21:03:24 2008 Subject: slightly modified hasktags version (now supports kinds) In-Reply-To: <20080216030319.GA26659@gmx.de> References: <20080212173805.GA22732@gmx.de> <47B2D775.5090805@gmail.com> <20080216030319.GA26659@gmx.de> Message-ID: <20080217020459.GB31110@gmx.de> Now there is http://mawercer.de/hasktags_patch3 (fixed exhausted pattern match when processing literate haskell files) No aborts while tagging the core libraries, some extra libraries and HAppS libs. (45 packages tested) From igloo at earth.li Sun Feb 17 05:46:11 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 17 05:44:35 2008 Subject: slightly modified hasktags version (now supports kinds) In-Reply-To: <20080217020459.GB31110@gmx.de> References: <20080212173805.GA22732@gmx.de> <47B2D775.5090805@gmail.com> <20080216030319.GA26659@gmx.de> <20080217020459.GB31110@gmx.de> Message-ID: <20080217104611.GA21336@matrix.chaos.earth.li> Hi Marc, On Sun, Feb 17, 2008 at 03:04:59AM +0100, Marc Weber wrote: > Now there is > http://mawercer.de/hasktags_patch3 Thanks for the patches, but unfortunately hasktags doesn't build with them. If you want to test building it without building the whole of GHC then I think this should work: autoreconf ./configure cd utils/hasktags/ make depend make Thanks Ian From marco-oweber at gmx.de Sun Feb 17 08:37:30 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Feb 17 08:35:54 2008 Subject: slightly modified hasktags version (now supports kinds) In-Reply-To: <20080217104611.GA21336@matrix.chaos.earth.li> References: <20080212173805.GA22732@gmx.de> <47B2D775.5090805@gmail.com> <20080216030319.GA26659@gmx.de> <20080217020459.GB31110@gmx.de> <20080217104611.GA21336@matrix.chaos.earth.li> Message-ID: <20080217133730.GA8772@gmx.de> Hi Ian, thanks for your feedback. I should have taken more care. change line 198 let (tokenLines :: [[Token]]) = to let tokenLines May I ask you to (amend-)record it? I don't mind wether darcs lists me as author of this tiny minor fix. Or is it easier for you to apply another patch? Marc W. From seidl at big.tuwien.ac.at Sun Feb 17 09:32:37 2008 From: seidl at big.tuwien.ac.at (Martina Seidl) Date: Sun Feb 17 09:30:42 2008 Subject: statically linking Message-ID: <47B84585.7020905@big.tuwien.ac.at> Hallo, I urgently need a statically linked binary (ELF 32) of a Haskell program I have written and I could not figure out yet how to achieve this. Could anyone give me a hint please? Best regards, Martina From bjorn at bringert.net Sun Feb 17 10:17:28 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Sun Feb 17 10:15:51 2008 Subject: statically linking In-Reply-To: <47B84585.7020905@big.tuwien.ac.at> References: <47B84585.7020905@big.tuwien.ac.at> Message-ID: On Feb 17, 2008 3:32 PM, Martina Seidl wrote: > Hallo, > > I urgently need a statically linked binary (ELF 32) of a Haskell program I > have written and I could not figure out yet how to achieve this. > > Could anyone give me a hint please? > > Best regards, > Martina Hi Martina, Adding -static -optl-static to your ghc command line normally does it. -- /Bj?rn From leather at cs.uu.nl Sun Feb 17 15:00:31 2008 From: leather at cs.uu.nl (Sean Leather) Date: Sun Feb 17 14:58:53 2008 Subject: GHC build failures on Mac OS X Leopard: ppc & x86 Message-ID: <35ceab3a0802171200t32a0960csb82a98b6ac1f5b6a@mail.gmail.com> Hi, I tried to build GHC "stable" on my two computers, a PowerBook G4 and a MacBook, both running 10.5.2. This is the first time I've ever tried, so I'm somewhat clueless about a lot of it. I went with the basic instructions (./configure; make) with no 'mk/build.mk' and no configure options other than '--prefix'. On each system, I ran into a different error, though both point to the linker, 'ld'. The PowerBook failure looks similar to ticket #1958 [1]; however, it doesn't appear to be building parsec at that point. I gather that it's building stage1 due to the "-o stage1/ghc-6.8.2.20080213". The MacBook build apparently completed stage1 and failed in trying to build stage2 (i.e. "-o stage2/ghc-inplace"). I have included snippets below from the output of each build. I thought it might be useful to share and see if these are already known problems with/without workarounds. Also, I'm willing to help debug/test if there's anything specific you want me to try. Otherwise, I'll probably fiddle with the 'mk/build.mk' (as discussed in [1] and [2]) and/or changing which linker is used. Additionally, I have a somewhat unrelated question. What's the different between ghc-stable [3] and ghc-6.8 [4]? Thanks, Sean [1] http://hackage.haskell.org/trac/ghc/ticket/1958 [2] http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking [3] http://darcs.haskell.org/ghc-stable/ [4] http://darcs.haskell.org/ghc-6.8/ ------------------------------------------------ PPC build output ------------------------------------------------ /usr/local/ghc-6.8.2-ppc-tiger/bin/ghc -o stage1/ghc-6.8.2.20080213 -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -L../compat -lghccompat -no-link-chk stage1/basicTypes/BasicTypes.o stage1/basicTypes/DataCon.o collect2: ld terminated with signal 10 [Bus error] <> make[1]: *** [stage1/ghc-6.8.2.20080213] Error 1 make: *** [stage1] Error 1 ------------------------------------------------ x86 build output ------------------------------------------------ ../compiler/stage1/ghc-inplace -no-user-package-conf -cpp stage2/ghc-inplace.c -o stage2/ghc-inplace ld: in /Users/leather/Projects/ghc-stable/ghc/libraries/haskell98/dist/build/libHShaskell98-1.0.1.0.a, archive has no table of contents collect2: ld returned 1 exit status make[2]: *** [stage2/ghc-inplace] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 From topekarem at gmail.com Mon Feb 18 03:43:47 2008 From: topekarem at gmail.com (TOPE KAREM) Date: Mon Feb 18 03:42:09 2008 Subject: Recursion over lists Message-ID: <3717bcc50802180043ud368abcv266332596ba9eaaa@mail.gmail.com> Hello everyone, I am just learning to program in Haskell, and I found recursion very interesting. However, I need to write a recursive function over two lists. The function must check the elements in the two lists and return an element that is common to both lists if there is any. Any assistance would be appreciated. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080218/80112318/attachment.htm From chak at cse.unsw.edu.au Mon Feb 18 04:19:54 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Feb 18 04:18:17 2008 Subject: GHC build failures on Mac OS X Leopard: ppc & x86 In-Reply-To: <35ceab3a0802171200t32a0960csb82a98b6ac1f5b6a@mail.gmail.com> References: <35ceab3a0802171200t32a0960csb82a98b6ac1f5b6a@mail.gmail.com> Message-ID: Sean Leather: > I tried to build GHC "stable" on my two computers, a PowerBook G4 and > a MacBook, both running 10.5.2. This is the first time I've ever > tried, so I'm somewhat clueless about a lot of it. I went with the > basic instructions (./configure; make) with no 'mk/build.mk' and no > configure options other than '--prefix'. [..] > The MacBook build apparently completed stage1 and failed in trying to > build stage2 (i.e. "-o stage2/ghc-inplace"). I can't help you with the PPC, but on the MacBook try building with make EXTRA_AR_ARGS=-s It's a known bug with Cabal. Manuel > ------------------------------------------------ > x86 build output > ------------------------------------------------ > > ../compiler/stage1/ghc-inplace -no-user-package-conf -cpp > stage2/ghc-inplace.c -o stage2/ghc-inplace > > ld: in /Users/leather/Projects/ghc-stable/ghc/libraries/haskell98/ > dist/build/libHShaskell98-1.0.1.0.a, > archive has no table of contents > > collect2: ld returned 1 exit status > > make[2]: *** [stage2/ghc-inplace] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 From flippa at flippac.org Mon Feb 18 10:39:16 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Mon Feb 18 10:37:02 2008 Subject: Recursion over lists In-Reply-To: <3717bcc50802180043ud368abcv266332596ba9eaaa@mail.gmail.com> References: <3717bcc50802180043ud368abcv266332596ba9eaaa@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, TOPE KAREM wrote: > Hello everyone, > > I am just learning to program in Haskell, and I found recursion very > interesting. > However, I need to write a recursive function over two lists. > > The function must check the elements in the two lists and return an > element that is common to both lists if there is any. > > Any assistance would be appreciated. > Imagine for a moment that instead of "two lists" you have "a pair of lists", and thus each time you recurse you must generate a new pair of lists. After that it should be more or less business as usual if you're comfortable working on one list. -- flippa@flippac.org There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. From simonpj at microsoft.com Mon Feb 18 12:54:05 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 18 12:52:26 2008 Subject: ghci feature request: partially read modules In-Reply-To: <47B706F4.4090206@imn.htwk-leipzig.de> References: <47B706F4.4090206@imn.htwk-leipzig.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C318352FA746@EA-EXMSG-C334.europe.corp.microsoft.com> That's a fair suggestion. (With the subsequent clarification about getting through the parser and renamer first.) Would you like to check the open feature requests (in case it's there already) and add it as a feature request? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Johannes Waldmann | Sent: 16 February 2008 15:53 | To: glasgow-haskell-users@haskell.org | Subject: ghci feature request: partially read modules | | Hello. | | Here is one ghci feature that I find mildly annoying: | | If ghci (re-)reads a module that contains some error, | then it considers the module loading as a complete failure, | and at the prompt I get the Prelude environment. | | I'd like to have at least the import statements executed, | and possibly the declarations that were error-free. | That would help me in interactively debugging | the erraneous part of the module. | (Often the error is some type error, related to some imported entity; | but when my module contains the error, then the imports are gone.) | | Perhaps I'm doing something wrong, then please educate me; | or perhaps there's an easy way to implement partial reading | and typechecking. (It'd be enough to have this for the "current" | module, of course.) | | Thanks - Johannes Waldmann. | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From leather at cs.uu.nl Mon Feb 18 13:35:05 2008 From: leather at cs.uu.nl (Sean Leather) Date: Mon Feb 18 13:33:24 2008 Subject: GHC build failures on Mac OS X Leopard: ppc & x86 In-Reply-To: References: <35ceab3a0802171200t32a0960csb82a98b6ac1f5b6a@mail.gmail.com> Message-ID: <35ceab3a0802181035x22f97881o4d6e17cfe7e8e1c@mail.gmail.com> Hi, Manuel M T Chakravarty: > I can't help you with the PPC, but on the MacBook try building with > > make EXTRA_AR_ARGS=-s > > It's a known bug with Cabal. Thanks, Manuel, it builds now. Afterwards, I ran 'make' in 'testsuite/tests/ghc-regress' and got this: OVERALL SUMMARY for test run started at Mon Feb 18 17:55:20 CET 2008 2084 total tests, which gave rise to 10640 test cases, of which 0 caused framework failures 2160 were skipped 7487 expected passes 372 expected failures 0 unexpected passes 621 unexpected failures That seems like a large number of unexpected failures; however, I haven't seen a summary from a build of Mac OS X on x86, so I don't know what to expect. At a glance, many of the failures refer to ghci (at least that's what I assume the "(ghci)" next to the name means). Here is a sample: =====> user001(ghci) cd ../../../libraries/unix/tests && '/Users/leather/Projects/ghc-stable/ghc/compiler/stage1/ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_apple_darwin user001.hs --interactive -v0 -ignore-dot-ghci -package unix user001.interp.stdout 2>user001.interp.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: *** unexpected failure for user001(ghci) Is this reasonable? In other words, is something broken? Another thing I need to tweak, perhaps? Thanks, Sean From carli139 at yahoo.com.mx Mon Feb 18 13:46:19 2008 From: carli139 at yahoo.com.mx (Carlos Gomez A.) Date: Mon Feb 18 13:44:38 2008 Subject: a help for install Message-ID: <864256.86995.qm@web55508.mail.re4.yahoo.com> hi, my name is carlos I need information for correct install or what are dependencies on ghc ? I have a Debian System. I have this message error to install the ghc: Debian-System/haskell/ghc-6.8.2# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Canonicalised to: i386-unknown-linux checking for ghc... no checking for ghc-pkg matching ... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld configure: error: GHC is required unless bootstrapping from .hc files. Debian-System/haskell/ghc-6.8.2# --------------------------------- ?Capacidad ilimitada de almacenamiento en tu correo! No te preocupes m?s por el espacio de tu cuenta con Correo Yahoo!: http://correo.yahoo.com.mx/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080218/90457683/attachment-0001.htm From stefanor at cox.net Mon Feb 18 13:51:11 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Feb 18 13:49:30 2008 Subject: a help for install In-Reply-To: <864256.86995.qm@web55508.mail.re4.yahoo.com> References: <864256.86995.qm@web55508.mail.re4.yahoo.com> Message-ID: <20080218185111.GA4103@localhost.localdomain> On Mon, Feb 18, 2008 at 12:46:19PM -0600, Carlos Gomez A. wrote: > hi, my name is carlos > > I need information for correct install or > > what are dependencies on ghc ? > > I have a Debian System. > > > I have this message error to install the ghc: > > > Debian-System/haskell/ghc-6.8.2# ./configure > > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > Canonicalised to: i386-unknown-linux > checking for ghc... no > checking for ghc-pkg matching ... no > checking for ghc-pkg... no > checking whether ghc has readline package... no > checking for nhc... no > checking for nhc98... no > checking for hbc... no > checking for ld... /usr/bin/ld > configure: error: GHC is required unless bootstrapping from .hc files. > > Debian-System/haskell/ghc-6.8.2# As the message indicatied, you need GHC if you want to install from source. If you don't have GHC, get a binary (there is one in apt). Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080218/24d350ba/attachment.bin From haskell at list.mightyreason.com Mon Feb 18 16:57:27 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Feb 18 16:55:55 2008 Subject: GHC build failures on Mac OS X Leopard: ppc & x86 In-Reply-To: <35ceab3a0802181035x22f97881o4d6e17cfe7e8e1c@mail.gmail.com> References: <35ceab3a0802171200t32a0960csb82a98b6ac1f5b6a@mail.gmail.com> <35ceab3a0802181035x22f97881o4d6e17cfe7e8e1c@mail.gmail.com> Message-ID: <47B9FF47.3000906@list.mightyreason.com> Sean Leather wrote: > Hi, > > I tried to build GHC "stable" on my two computers, a PowerBook G4 and > a MacBook, both running 10.5.2 > > Manuel M T Chakravarty: >> I can't help you with the PPC... As far as I know -- and I wish to be wrong -- there is no known way to get a fully working ghc-6.8.x on OS 10.5.y on the PowerPC (PPC) architecture. I spent some free time helping debug the ghc-6.8 release, which led to a patch for some of the problems being applied in ghc-6.8.1. But a few other problems remain, I suggest looking at open ghc trac tickets on the powerpc architecture. I still use ghc-6.6.1 for now. From chak at cse.unsw.edu.au Mon Feb 18 18:58:44 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Feb 18 18:57:08 2008 Subject: GHC build failures on Mac OS X Leopard: ppc & x86 In-Reply-To: <35ceab3a0802181035x22f97881o4d6e17cfe7e8e1c@mail.gmail.com> References: <35ceab3a0802171200t32a0960csb82a98b6ac1f5b6a@mail.gmail.com> <35ceab3a0802181035x22f97881o4d6e17cfe7e8e1c@mail.gmail.com> Message-ID: Sean Leather: > Manuel M T Chakravarty: >> I can't help you with the PPC, but on the MacBook try building with >> >> make EXTRA_AR_ARGS=-s >> >> It's a known bug with Cabal. > > Thanks, Manuel, it builds now. > > Afterwards, I ran 'make' in 'testsuite/tests/ghc-regress' and got > this: > > OVERALL SUMMARY for test run started at Mon Feb 18 17:55:20 CET 2008 > 2084 total tests, which gave rise to > 10640 test cases, of which > 0 caused framework failures > 2160 were skipped > > 7487 expected passes > 372 expected failures > 0 unexpected passes > 621 unexpected failures > > That seems like a large number of unexpected failures; however, I > haven't seen a summary from a build of Mac OS X on x86, so I don't > know what to expect. > > At a glance, many of the failures refer to ghci (at least that's what > I assume the "(ghci)" next to the name means). Here is a sample: I haven't run the full test suite on the 6.8 branch. Try make Validating=YES fast stage=2 CLEANUP=1 That should go through (sometimes when test outputs changes due to changes on the HEAD), it takes a while until the tests are adapted to expect different outputs for 6.8. Manuel From g9ks157k at acme.softbase.org Tue Feb 19 06:03:02 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 06:01:45 2008 Subject: [Haskell-cafe] Re: a help for install In-Reply-To: <200802191136.13871.g9ks157k@acme.softbase.org> References: <864256.86995.qm@web55508.mail.re4.yahoo.com> <200802191136.13871.g9ks157k@acme.softbase.org> Message-ID: <200802191203.03140.g9ks157k@acme.softbase.org> Am Dienstag, 19. Februar 2008 11:36 schrieb Wolfgang Jeltsch: > Am Montag, 18. Februar 2008 19:46 schrieb Carlos Gomez A.: > > hi, my name is carlos > > > > I need information for correct install or > > > > what are dependencies on ghc ? > > > > I have a Debian System. > > Always use your distribution?s packages until they aren?t any or there is > good reason not to do so. Try ?aptitude install ghc6?. > > Best wishes, > Wolfgang Sorry, this should go to glasgow-haskell-users@haskell.org. :-( Best wishes, Wolfgang From Christian.Maeder at dfki.de Tue Feb 19 06:49:09 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 19 06:47:24 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> <2608b8a80802141119k1e6e4fbbh4ad0598621288586@mail.gmail.com> Message-ID: <47BAC235.4010102@dfki.de> Manuel M T Chakravarty wrote: >> $ ./HelloWorld-Tiger >> Hello World! >> $ ./HelloWorld-Leopard >> Bus error only setting export MACOSX_DEPLOYMENT_TARGET=10.4 on Leopard during compilation should make it run on a Tiger, too. HTH Christian From g9ks157k at acme.softbase.org Tue Feb 19 16:05:22 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 16:04:03 2008 Subject: [Haskell-cafe] Re: a help for install In-Reply-To: <200802191203.03140.g9ks157k@acme.softbase.org> References: <864256.86995.qm@web55508.mail.re4.yahoo.com> <200802191136.13871.g9ks157k@acme.softbase.org> <200802191203.03140.g9ks157k@acme.softbase.org> Message-ID: <200802192205.23054.g9ks157k@acme.softbase.org> Am Dienstag, 19. Februar 2008 12:03 schrieb Wolfgang Jeltsch: > Am Dienstag, 19. Februar 2008 11:36 schrieb Wolfgang Jeltsch: > > Am Montag, 18. Februar 2008 19:46 schrieb Carlos Gomez A.: > > > hi, my name is carlos > > > > > > I need information for correct install or > > > > > > what are dependencies on ghc ? > > > > > > I have a Debian System. > > > > Always use your distribution?s packages until they aren?t any or there is > > good reason not to do so. Try ?aptitude install ghc6?. > > > > Best wishes, > > Wolfgang > > Sorry, this should go to glasgow-haskell-users@haskell.org. :-( > > Best wishes, > Wolfgang Sorry, this has gone to haskell-cafe but should not go to this list. :-( But the original message should, of course: > Always use your distribution?s packages until they aren?t any or there is > good reason not to do so. Try ?aptitude install ghc6?. That?s all I wanted to say. :-) Best wishes, Wolfgang From chak at cse.unsw.edu.au Tue Feb 19 19:56:26 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Feb 19 19:54:47 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <47BAC235.4010102@dfki.de> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> <2608b8a80802141119k1e6e4fbbh4ad0598621288586@mail.gmail.com> <47BAC235.4010102@dfki.de> Message-ID: <150B70E5-7017-4D6F-8F41-6C814261D7C8@cse.unsw.edu.au> Christian Maeder: > Manuel M T Chakravarty wrote: >>> $ ./HelloWorld-Tiger >>> Hello World! >>> $ ./HelloWorld-Leopard >>> Bus error > > only setting > > export MACOSX_DEPLOYMENT_TARGET=10.4 > > on Leopard during compilation should make it run on a Tiger, too. I tried that, too, but it somehow only works partially. If I build ghc with that environment setting, the GHC binary still has some Leopard symbols in it (though much less than without that setting). Specifically, I am seeing dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr = libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc on running env DYLD_PRINT_BINDINGS= compiler/stage2/ghc-6.9.20080219 Any idea why that may be? In contrast, if I instruct GHC's build system to use -optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk -optl-mmacosx- version-min=10.4 -optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk on all CC and LD targets, I don't seem to have any Leopard symbols anymore. FWIW, Xcode 3.0 also seem to use explicit SDK options. Manuel From Christian.Maeder at dfki.de Wed Feb 20 04:52:10 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 20 04:50:23 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <150B70E5-7017-4D6F-8F41-6C814261D7C8@cse.unsw.edu.au> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> <2608b8a80802141119k1e6e4fbbh4ad0598621288586@mail.gmail.com> <47BAC235.4010102@dfki.de> <150B70E5-7017-4D6F-8F41-6C814261D7C8@cse.unsw.edu.au> Message-ID: <47BBF84A.1080009@dfki.de> Manuel M T Chakravarty wrote: > Christian Maeder: >> export MACOSX_DEPLOYMENT_TARGET=10.4 >> > Specifically, I am seeing > > dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr = > libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc what tells you that this is Leopard specific? > on running > > env DYLD_PRINT_BINDINGS= compiler/stage2/ghc-6.9.20080219 > > Any idea why that may be? no, no idea. > -optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk > -optl-mmacosx-version-min=10.4 Interesting, in contrast to you I had a problem with -mmacosx-version-min and had to use MACOSX_DEPLOYMENT_TARGET when building user programs on Leopard using my Tiger bindist. http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/014093.html > -optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk > > on all CC and LD targets, I don't seem to have any Leopard symbols > anymore. FWIW, Xcode 3.0 also seem to use explicit SDK options. I haven't built ghc on Leopard, yet, but I'll expect to use -isysroot and -syslibroot then, too. Cheers Christian From Christian.Maeder at dfki.de Wed Feb 20 07:14:23 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 20 07:12:35 2008 Subject: GHC build failures on Mac OS X Leopard: ppc In-Reply-To: <47B9FF47.3000906@list.mightyreason.com> References: <35ceab3a0802171200t32a0960csb82a98b6ac1f5b6a@mail.gmail.com> <35ceab3a0802181035x22f97881o4d6e17cfe7e8e1c@mail.gmail.com> <47B9FF47.3000906@list.mightyreason.com> Message-ID: <47BC199F.5090304@dfki.de> Chris Kuklewicz wrote: > As far as I know -- and I wish to be wrong -- there is no known way to > get a fully working ghc-6.8.x on OS 10.5.y on the PowerPC (PPC) > architecture. One problem left was: m29:fastcgi-3001.0.1 maeder$ ./Setup build Segmentation fault I could work around this by using "runghc Setup.lhs build" (and only got distrubing warnings that I could ignore). I've tried to debug the problem, but only got the following after typing "run" twice in gdb on Intel Leopard: (gdb) run Starting program: /Users/Shared/maeder/haskell/fastcgi-3001.0.1/Setup build arch: posix_spawnp: /Users/Shared/maeder/haskell/fastcgi-3001.0.1/Setup: Bad CPU type in executable Program exited with code 01. Could you create a ticket for this problem and investigate it further? Christian From simonmarhaskell at gmail.com Wed Feb 20 10:06:20 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 20 10:04:38 2008 Subject: ghc-6.8.1 on WinXP: windres: can't open font file `for' In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E92BD@GBLONXMB02.corp.amvescap.net> References: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> <47B5A12F.70002@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92BC@GBLONXMB02.corp.amvescap.net> <404396ef0802150713i1809dc1ek4177d74664cfedc0@mail.gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92BD@GBLONXMB02.corp.amvescap.net> Message-ID: <47BC41EC.80001@gmail.com> Bayley, Alistair wrote: >> From: Neil Mitchell [mailto:ndmitchell@gmail.com] >> >>> Bummer. I was hoping to be able to use 6.8.1 with gtk2hs >> (AFAIUI, gtk2hs >>> doesn't work with/hasn't been compiled against 6.8.2 yet). >> Is there a >>> workaround or something I can tweak in my 6.8.1 installation? >> It's much easier to gently prod Duncan until he gives in and releases >> a new gtk2hs version. > > Maybe... the fact that I don't have this problem with 6.8.1 on my laptop > implies that there *might* be something external to ghc that I can > change that would fix it. I assume the bug you're encountering is this one: http://hackage.haskell.org/trac/ghc/ticket/1828 in which case the workaround is not to install GHC to a patch containing spaces. If it's not that bug, then we'll have to investigate further. Cheers, Simon From Alistair_Bayley at invescoperpetual.co.uk Wed Feb 20 10:20:58 2008 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Wed Feb 20 10:19:23 2008 Subject: ghc-6.8.1 on WinXP: windres: can't open font file `for' In-Reply-To: <47BC41EC.80001@gmail.com> References: <125EACD0CAE4D24ABDB4D148C4593DA9049E92B5@GBLONXMB02.corp.amvescap.net> <47B5A12F.70002@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92BC@GBLONXMB02.corp.amvescap.net> <404396ef0802150713i1809dc1ek4177d74664cfedc0@mail.gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92BD@GBLONXMB02.corp.amvescap.net> <47BC41EC.80001@gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E92CD@GBLONXMB02.corp.amvescap.net> > From: Simon Marlow [mailto:simonmarhaskell@gmail.com] > > I assume the bug you're encountering is this one: > > http://hackage.haskell.org/trac/ghc/ticket/1828 > > in which case the workaround is not to install GHC to a patch > containing > spaces. > > If it's not that bug, then we'll have to investigate further. I searched trac for windres and found two tickets (including that one above), neither of which seems to describe my problem. Here's the (trimmed) output from ghc -v3: Linking Main.exe ... *** Windres: c:\ghc\ghc-6.8.1\bin/windres --preprocessor=c:\ghc\ghc-6.8.1\gcc -Bc:\ghc\ghc-6.8.1\gcc-lib/ -E -xc -DRC_INVOKED --input=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.rc --output=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.o --output-format=coff c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory You can see that my ghc installation is on a path sans spaces. Would you like more information? Alistair ***************************************************************** 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 chak at cse.unsw.edu.au Wed Feb 20 18:26:54 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Feb 20 18:25:12 2008 Subject: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)] In-Reply-To: <47BBF84A.1080009@dfki.de> References: <2608b8a80802120504u13817294xb7a93727e4eeb81a@mail.gmail.com> <66212D47-8FF0-43C8-9739-C9ADC109AEFA@cse.unsw.edu.au> <2608b8a80802130951i3bb19b2dl3a3cca4dd7afd2d7@mail.gmail.com> <4E9A5A71-A7C1-410C-8260-3262000FA576@cse.unsw.edu.au> <2608b8a80802141119k1e6e4fbbh4ad0598621288586@mail.gmail.com> <47BAC235.4010102@dfki.de> <150B70E5-7017-4D6F-8F41-6C814261D7C8@cse.unsw.edu.au> <47BBF84A.1080009@dfki.de> Message-ID: <77B8D935-59BF-4B08-B1A0-E2A6A1190863@cse.unsw.edu.au> Christian Maeder: > Manuel M T Chakravarty wrote: >> Christian Maeder: >>> export MACOSX_DEPLOYMENT_TARGET=10.4 >>> >> Specifically, I am seeing >> >> dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr = >> libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc > > what tells you that this is Leopard specific? http://lists.apple.com/archives/darwin-dev/2007/Nov/msg00108.html >> -optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk >> -optl-mmacosx-version-min=10.4 > > Interesting, in contrast to you I had a problem with > -mmacosx-version-min and had to use MACOSX_DEPLOYMENT_TARGET when > building user programs on Leopard using my Tiger bindist. > > http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/014093.html I made a similar observation. Using -syslibroot in addition, fixed the problem for me. >> -optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk >> >> on all CC and LD targets, I don't seem to have any Leopard symbols >> anymore. FWIW, Xcode 3.0 also seem to use explicit SDK options. > > I haven't built ghc on Leopard, yet, but I'll expect to use -isysroot > and -syslibroot then, too. Hold off another day or two and you get that automatically by just using --with-macos-deployment-target=10.4 with GHC's ./configure. (This will even enable you to generate a GHC build for 10.4 from a bootstrap compiler for 10.5, which is non-trivial due to the programs in utils/ and some other stuff.) Manuel From v.dijk.bas at gmail.com Thu Feb 21 21:06:39 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Feb 21 21:04:45 2008 Subject: Recursion over lists In-Reply-To: <3717bcc50802180043ud368abcv266332596ba9eaaa@mail.gmail.com> References: <3717bcc50802180043ud368abcv266332596ba9eaaa@mail.gmail.com> Message-ID: 2008/2/18 TOPE KAREM : > However, I need to write a recursive function over two lists. ( Note that functions which use explicit recursion are usually harder to understand then functions which abstract over the recursion using higher order functions. See: http://haskell.org/haskellwiki/Things_to_avoid#Avoid_explicit_recursion ) > The function must check the elements in the two lists and return an > element that is common to both lists if there is any. Lets call the function you want to define: 'common'. You should always start with the design. Designing in Haskell means defining the type of your function. According to your specification, 'common' takes two lists of which the elements should be compared for equality: common :: Eq a => [a] -> [a] -> ... 'common' should return a value that indicates that there are no common elements in both lists or a value that indicates which element is common to both lists. The 'Prelude' [2] already contains a data type that we can use for this. It's called 'Maybe' and it's parameterized by the value that can possibly be returned. It's defined as follows: data Maybe a = Nothing | Just a So the final type of 'common' is: common :: Eq a => [a] -> [a] -> Maybe a Before you immediately start programming let's first think about some properties of 'common'. The nice thing about properties is that they give you a formal specification instead of the informal one you've given above. What's truly nice is that you can define these properties in Haskell itself! And later use these properties to automatically _test_ your function using a tool called 'QuickCheck' [3]. The most obvious property of 'common' that comes to my mind is that for all lists 'xs' and 'ys' if 'common xs ys' equals 'Nothing' then each element of 'ys' should not be an element of 'xs'. And if 'common xs ys' equals 'Just z' then 'z' should be an element of both 'xs' and 'ys'. This can be defined in Haskell as follows: prop_common :: [Int] -> [Int] -> Bool prop_common xs ys = case common xs ys of Nothing -> all (`notElem` xs) ys Just z -> z `elem` xs && z `elem` ys Note that I've fixed the type of the lists to [Int]. This is useful when testing the function later on with QuickCheck. Now, I'm not going to give the definition of 'common xs ys', that wouldn't be fun! But I good give you some pointers. First you could try filtering all the elements of 'ys' that are elements of 'xs'. Then use a auxiliary functions which transforms the filtered list into a 'Maybe' value. Tip use Hoogle [1] to search for existing functions (like 'filter'). Finally, if you have defined your function you should test it against the specification (prop_common). You can do this with QuickCheck. Just 'import Test.QuickCheck' and run 'test prop_common'. This will automatically generate random test cases and apply 'prop_common' to them. If your definition passes the test you can be quite sure it's correct. regards, Bas [1] http://www.haskell.org/hoogle [2] The Prelude is a library containing lots of useful functions, data types, classes and instances that is always loaded automatically in each of your modules. Just 'hoogle' [1] for 'Prelude': [3] QuickCheck is a tool for testing Haskell programs automatically. Just 'hoogle' [1] for 'QuickCheck': P.S. It's better to ask such questions on the haskell-cafe mailinglist. See: http://haskell.org/haskellwiki/Mailing_lists From pcc03 at doc.ic.ac.uk Fri Feb 22 09:39:36 2008 From: pcc03 at doc.ic.ac.uk (Peter Collingbourne) Date: Fri Feb 22 09:37:43 2008 Subject: hs-plugins -- simple example fails Message-ID: <20080222143936.GC22242@doc.ic.ac.uk> Hello, I'm having problems trying to use hs-plugins (the darcs version, as I am on a 64-bit machine). The test suite mostly works without problems, but I can't get my own code to work. I put together a simple example which illustrates my problem: Main.hs ==================== module Main (Tree(..), Interface(..), main) where import Ptr import System.Plugins data Tree = Tree (Ptr Tree) data Interface = Interface { processTree :: Ptr Tree -> IO (Ptr Tree) } main = load "XYZuse.o" ["."] [] "resource" >>= (\(LoadSuccess _ v) -> (processTree v nullPtr)) ==================== XYZuse.hs ==================== module XYZuse (resource) where import Main resource = Interface { processTree = return } ==================== This is the output I get: ==================== $ ghc -c -o Main.o Main.hs $ ghc -c -o XYZuse.o XYZuse.hs $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :l Main Ok, modules loaded: Main. Prelude Main> main Loading package Cabal-1.1.6 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src-1.0 ... linking ... done. Loading package plugins-1.0 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol Main_processTree_closure whilst processing object file ./Main.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. ==================== Thanks, -- Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080222/fd71f634/attachment.bin From mdanish at andrew.cmu.edu Fri Feb 22 12:20:56 2008 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Fri Feb 22 12:19:02 2008 Subject: hs-plugins -- simple example fails In-Reply-To: <20080222143936.GC22242@doc.ic.ac.uk> References: <20080222143936.GC22242@doc.ic.ac.uk> Message-ID: <20080222172056.GG13177@mapcar.org> On Fri, Feb 22, 2008 at 02:39:36PM +0000, Peter Collingbourne wrote: > This could be caused by: > * Loading two different object files which export the same symbol ^ I think this is the cause. Try factoring out "Interface" into its own module. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org From matthew_bentham at yahoo.com Sat Feb 23 19:54:21 2008 From: matthew_bentham at yahoo.com (Matthew Bentham) Date: Sat Feb 23 19:52:24 2008 Subject: Problem with Windows ghc 6.8.2 Message-ID: <523157.69524.qm@web51608.mail.re2.yahoo.com> Hi all, I'm not too experienced with ghc or Haskell, so I wanted to check here rather than submitting a bug: $ cat test.hs import Text.PrettyPrint main = print "foo" $ /c/ghc/ghc-6.6.1/bin/ghc test.hs $ ./main.exe "foo" $ /c/ghc/ghc-6.8.2/bin/ghc test.hs test.o(.text+0x217):fake: undefined reference to `__stginit_prettyzm1zi0zi0zi0_TextziPrettyPrint_' $ I'm using Vista64. The session above was copied from a cygwin shell, but it does the same in an msys shell or cmd.exe. Both versions of ghc were installed using the official binary distribution. I'm having trouble compiling ghc from source at the moment (I think there's another issue I'm hitting with the 6.6.1 build, haven't tracked it down yet) so I can't debug what is going wrong myself. I'd appreciate people's advice about what to do. Should my test program work or am I doing something wrong? Maybe there are some optional libraries to install that I have missed, that used to be core? Output from ghc -v test.hs follows: $ rm test.hi $ $ $ /c/ghc/ghc-6.8.2/bin/ghc -v test.hs *** Tidy Core: Result size = 16 writeBinIface: 1 Names writeBinIface: 7 dict entries *** CorePrep: Result size = 18 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: c:\ghc\ghc-6.8.2\gcc -Bc:\ghc\ghc-6.8.2\gcc-lib/ -I. -c c:\Users\mjb67\AppData\Local\Temp\ghc4332_0\ghc4332_0.s -o test.o *** Windres: c:\ghc\ghc-6.8.2\bin/windres --preprocessor="c:\ghc\ghc-6.8.2\gcc" "-Bc:\ghc\ghc-6.8.2\gcc-lib/" "-E" "-xc" "-DRC_INVOKED" --use-temp-file --input=c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.rc --output=c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o --output-format=coff *** Linker: c:\ghc\ghc-6.8.2\gcc -Bc:\ghc\ghc-6.8.2\gcc-lib/ -v -o main.exe -DDONT_WANT_WIN32_DLL_SUPPORT test.o c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o -Lc:/ghc/ghc-6.8.2/lib\haskell98-1.0.1.0 -Lc:/ghc/ghc-6.8.2/lib\array-0.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\process-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\random-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\directory-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\filepath-1.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-time-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-locale-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\base-3.0.1.0 -Lc:/ghc/ghc-6.8.2 -Lc:/ghc/ghc-6.8.2/gcc-lib -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -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 Reading specs from c:/ghc/ghc-6.8.2/gcc-lib/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) ld -Bdynamic -o main.exe -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 c:/ghc/ghc-6.8.2/gcc-lib/crt2.o c:/ghc/ghc-6.8.2/gcc-lib/crtbegin.o -Lc:/ghc/ghc-6.8.2/lib\haskell98-1.0.1.0 -Lc:/ghc/ghc-6.8.2/lib\array-0.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\process-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\random-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\directory-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\filepath-1.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-time-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-locale-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\base-3.0.1.0 -Lc:/ghc/ghc-6.8.2 -Lc:/ghc/ghc-6.8.2/gcc-lib -Lc:/ghc/ghc-6.8.2/gcc-lib test.o c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/ghc/ghc-6.8.2/gcc-lib/crtend.o test.o(.text+0x217):fake: undefined reference to `__stginit_prettyzm1zi0zi0zi0_TextziPrettyPrint_' *** Deleting temp files: Deleting: c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.rc c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.s *** Deleting temp dirs: Deleting: c:/Users/mjb67/AppData/Local/Temp/ghc4332_0 From daniel.is.fischer at web.de Sat Feb 23 20:13:48 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Feb 23 20:10:14 2008 Subject: Problem with Windows ghc 6.8.2 In-Reply-To: <523157.69524.qm@web51608.mail.re2.yahoo.com> References: <523157.69524.qm@web51608.mail.re2.yahoo.com> Message-ID: <200802240213.48150.daniel.is.fischer@web.de> Am Sonntag, 24. Februar 2008 01:54 schrieb Matthew Bentham: > Hi all, > > I'm not too experienced with ghc or Haskell, so I wanted to check here > rather than submitting a bug: It's probably the base-split. In 6.6.1, Text.PrettyPrint was in the base package, in 6.8.2 it's in the pretty package. Try compiling with -package pretty, or better still, with --make: /path/to/ghc --make test or /path/to/ghc -o test.exe test.hs -package pretty If that's not it, you might have a real problem. Cheers, Daniel > > $ cat test.hs > import Text.PrettyPrint > main = print "foo" > $ /c/ghc/ghc-6.6.1/bin/ghc test.hs > $ ./main.exe > "foo" > $ /c/ghc/ghc-6.8.2/bin/ghc test.hs > test.o(.text+0x217):fake: undefined reference to > `__stginit_prettyzm1zi0zi0zi0_TextziPrettyPrint_' $ > > I'm using Vista64. The session above was copied from a cygwin shell, but > it does the same in an msys shell or cmd.exe. Both versions of ghc were > installed using the official binary distribution. > > I'm having trouble compiling ghc from source at the moment (I think there's > another issue I'm hitting with the 6.6.1 build, haven't tracked it down > yet) so I can't debug what is going wrong myself. > > I'd appreciate people's advice about what to do. Should my test program > work or am I doing something wrong? Maybe there are some optional > libraries to install that I have missed, that used to be core? > > From frederik at a5.repetae.net Sat Feb 23 20:18:59 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sat Feb 23 20:17:04 2008 Subject: how to use ghci-debugger with packages Message-ID: <20080224011859.GA6714@a5.repetae.net> Hello, I have a program which uses some code in a package, and I would like to be able to find out the source of an error which is occuring inside that package. Can I use the ghci-debugger to do this? If I try to set a breakpoint inside the package, it says: "cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module Vector.Sparse.Wrappers is not interpreted" But this page: http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html has no use of the word "package", so I assume that reading that (long) document won't ansnwer my question... Thank you, Frederik -- http://ofb.net/~frederik/ From daniel.is.fischer at web.de Sat Feb 23 20:36:08 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Feb 23 20:32:35 2008 Subject: how to use ghci-debugger with packages In-Reply-To: <20080224011859.GA6714@a5.repetae.net> References: <20080224011859.GA6714@a5.repetae.net> Message-ID: <200802240236.08237.daniel.is.fischer@web.de> Am Sonntag, 24. Februar 2008 02:18 schrieb Frederik Eaton: > Hello, > > I have a program which uses some code in a package, and I would like > to be able to find out the source of an error which is occuring inside > that package. Can I use the ghci-debugger to do this? If I try to set > a breakpoint inside the package, it says: > > "cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module > Vector.Sparse.Wrappers is not interpreted" > > But this page: > > http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html > > has no use of the word "package", so I assume that reading that (long) > document won't ansnwer my question... > > Thank you, > > Frederik The users-guide says "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger." The modules of an installed package are always compiled, I think. If you have the source available, you could try to put that in your working directory (probably hide the installed package before starting ghci). Cheers, Daniel From matthew_bentham at yahoo.com Sat Feb 23 20:36:03 2008 From: matthew_bentham at yahoo.com (Matthew Bentham) Date: Sat Feb 23 20:34:05 2008 Subject: Problem with Windows ghc 6.8.2 Message-ID: <770422.52718.qm@web51604.mail.re2.yahoo.com> ----- Original Message ---- > From: Daniel Fischer > To: Matthew Bentham ; glasgow-haskell-users@haskell.org > Sent: Sunday, February 24, 2008 1:13:48 AM > Subject: Re: Problem with Windows ghc 6.8.2 > > Am Sonntag, 24. Februar 2008 01:54 schrieb Matthew Bentham: > > Hi all, > > > > I'm not too experienced with ghc or Haskell, so I wanted to check here > > rather than submitting a bug: > > It's probably the base-split. In 6.6.1, Text.PrettyPrint was in the base > package, in 6.8.2 it's in the pretty package. > Try compiling with -package pretty, or better still, with --make: > > /path/to/ghc --make test > > or > > /path/to/ghc -o test.exe test.hs -package pretty > > If that's not it, you might have a real problem. Thanks, they both work great. Matthew From frederik at a5.repetae.net Sat Feb 23 21:33:58 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sat Feb 23 21:32:02 2008 Subject: how to use ghci-debugger with packages In-Reply-To: <200802240236.08237.daniel.is.fischer@web.de> References: <20080224011859.GA6714@a5.repetae.net> <200802240236.08237.daniel.is.fischer@web.de> Message-ID: <20080224023358.GD13696@a5.repetae.net> On Sun, Feb 24, 2008 at 02:36:08AM +0100, Daniel Fischer wrote: > Am Sonntag, 24. Februar 2008 02:18 schrieb Frederik Eaton: > > Hello, > > > > I have a program which uses some code in a package, and I would like > > to be able to find out the source of an error which is occuring inside > > that package. Can I use the ghci-debugger to do this? If I try to set > > a breakpoint inside the package, it says: > > > > "cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module > > Vector.Sparse.Wrappers is not interpreted" > > > > But this page: > > > > http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html > > > > has no use of the word "package", so I assume that reading that (long) > > document won't ansnwer my question... > > > > Thank you, > > > > Frederik > > The users-guide says > "There is one major restriction: breakpoints and single-stepping are only > available in interpreted modules; compiled code is invisible to the > debugger." > > The modules of an installed package are always compiled, I think. That's what I think as well, but I'm not sure (and it seems like the documentation should mention that: CC'ing glasgow-haskell-bugs). I can't see a reason why an installed package wouldn't be able to contain its own source code, for instance... > If you have the source available, you could try to put that in your working > directory (probably hide the installed package before starting ghci). Thanks, I may try that. I'm currently trying to get my GNU-make-based build to install profiling versions of package modules, in the hope that -xc might give more useful information than it did a year ago... Frederik -- http://ofb.net/~frederik/ From andrei.formiga at gmail.com Sat Feb 23 22:15:28 2008 From: andrei.formiga at gmail.com (Andrei Formiga) Date: Sat Feb 23 22:13:28 2008 Subject: Visual Haskell sources Message-ID: Hello, The Visual Haskell 0.2 release notes [1] say that sources are available, but the download page only has binaries available. Where are the sources? Also, does it use the Visual Studio SDK, and is it compatible with VS 2008? Thanks. [1] http://haskell.org/visualhaskell/doc/index.html#release-notes -- []s, Andrei Formiga From jason.dusek at gmail.com Sun Feb 24 02:56:25 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Feb 24 02:54:25 2008 Subject: static constants -- ideas? Message-ID: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> I have an awkward programming problem -- I need to take a dictionary, parse it, build a bunch of intermediate lists and then make maps and tries out of the list. A "programming problem" because it's taken me a fair amount of effort to pull together the parser and list generator -- and "awkward" because a 69000 item list, [(String, [(String, String)])], does not compile under GHC (stack overflow). (It's not likely to compile under anything else, either!) Members of #haskell have urged me to load the offending material from a file; indeed, it only takes ten seconds to parse the dictionary and build the lists, sort them and dump them back out again -- but it offends my sensibilities. I don't want to wait ten seconds to load my dictionary every time. I could use the FFI, then I can make the trie and lists all in C. That'd work great. My list likely uses too much RAM now, anyways. I'm considering one other option though -- I wonder if I can build large constants in GHC Core? If anybody has tried it -- or found some other way to make big huge constants in Haskell -- I would sure like to know about it. On another note, I am extremely curious about the difference between statically compiling a list and building it at runtime. I find it hard to wrap my head around the fact that I can build the list at runtime in a short time, but can not compile it without eating all of my machine's RAM. Is it due to laziness, maybe? Well, no -- because I subject the whole list to a sort. It's not just streaming records in from one IO handle and out another. -- _jsn From dons at galois.com Sun Feb 24 03:07:08 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 24 03:05:12 2008 Subject: static constants -- ideas? In-Reply-To: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> Message-ID: <20080224080708.GA16331@scytale.galois.com> jason.dusek: > I have an awkward programming problem -- I need to take a > dictionary, parse it, build a bunch of intermediate lists and > then make maps and tries out of the list. A "programming > problem" because it's taken me a fair amount of effort to pull > together the parser and list generator -- and "awkward" > because a 69000 item list, [(String, [(String, String)])], > does not compile under GHC (stack overflow). (It's not likely > to compile under anything else, either!) > > Members of #haskell have urged me to load the offending > material from a file; indeed, it only takes ten seconds to > parse the dictionary and build the lists, sort them and dump > them back out again -- but it offends my sensibilities. I > don't want to wait ten seconds to load my dictionary every > time. > > I could use the FFI, then I can make the trie and lists all in > C. That'd work great. My list likely uses too much RAM now, > anyways. > > I'm considering one other option though -- I wonder if I can > build large constants in GHC Core? If anybody has tried it -- > or found some other way to make big huge constants in Haskell > -- I would sure like to know about it. You can build large constant bytestrings, fwiw. They turn into an Addr#, and GHC will leave them alone. See, e.g. this regex testsuite, which has *lots* of bytestring (overloaded) literals, http://code.haskell.org/~dons/code/pcre-light/tests/Unit.hs Using the OverloadedStrings pragma. This is approximately the same approach as Alex (the lexer generator) takes with its lexing tables stored in an unboxed string literal. -- Don From jason.dusek at gmail.com Sun Feb 24 03:19:05 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Feb 24 03:17:06 2008 Subject: static constants -- ideas? In-Reply-To: <20080224080708.GA16331@scytale.galois.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080224080708.GA16331@scytale.galois.com> Message-ID: <42784f260802240019j430d47c4ka90b874cd68f3963@mail.gmail.com> Don Stewart wrote: > You can build large constant bytestrings, fwiw. They turn into > an Addr#, and GHC will leave them alone. Well, for my particular problem -- I guess I could align all the elements of the lists, and then build the trie and maps from the ByteStrings at startup. -- _jsn From dons at galois.com Sun Feb 24 03:37:03 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 24 03:35:06 2008 Subject: static constants -- ideas? In-Reply-To: <42784f260802240019j430d47c4ka90b874cd68f3963@mail.gmail.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080224080708.GA16331@scytale.galois.com> <42784f260802240019j430d47c4ka90b874cd68f3963@mail.gmail.com> Message-ID: <20080224083703.GA16463@scytale.galois.com> jason.dusek: > Don Stewart wrote: > > You can build large constant bytestrings, fwiw. They turn into > > an Addr#, and GHC will leave them alone. > > Well, for my particular problem -- I guess I could align all > the elements of the lists, and then build the trie and maps > from the ByteStrings at startup. You could pull them out with Data.Binary too, making it a little faster constructing. -- Don From jay at satirist.org Sun Feb 24 22:21:36 2008 From: jay at satirist.org (Jay Scott) Date: Sun Feb 24 22:19:40 2008 Subject: static constants -- ideas? In-Reply-To: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> Message-ID: <20080225032136.1157084960@mail.satirist.org> Jason Dusek jason.dusek@gmail.com: > I have an awkward programming problem -- I need to take a > dictionary, parse it, build a bunch of intermediate lists and > then make maps and tries out of the list. A "programming > problem" because it's taken me a fair amount of effort to pull > together the parser and list generator -- and "awkward" > because a 69000 item list, [(String, [(String, String)])], > does not compile under GHC (stack overflow). I also have constants that are too large to compile. I am resigned to loading them from data files--other solutions seem even worse. With data files: - The program starts up more slowly. - The code is more complex. - There may be some hassles with laziness. - Distributing the executable is not as simple. Data.Binary eases the irritation somewhat. Jay From dons at galois.com Sun Feb 24 22:23:34 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 24 22:21:33 2008 Subject: static constants -- ideas? In-Reply-To: <20080225032136.1157084960@mail.satirist.org> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> Message-ID: <20080225032334.GN19935@scytale.galois.com> jay: > Jason Dusek jason.dusek@gmail.com: > > I have an awkward programming problem -- I need to take a > > dictionary, parse it, build a bunch of intermediate lists and > > then make maps and tries out of the list. A "programming > > problem" because it's taken me a fair amount of effort to pull > > together the parser and list generator -- and "awkward" > > because a 69000 item list, [(String, [(String, String)])], > > does not compile under GHC (stack overflow). > > I also have constants that are too large to compile. I am resigned to > loading them from data files--other solutions seem even worse. > > With data files: > > - The program starts up more slowly. > - The code is more complex. > - There may be some hassles with laziness. > - Distributing the executable is not as simple. > > Data.Binary eases the irritation somewhat. Did you try bytestring literals (and maybe parsing them in-memory with Data.Binary)? -- Don From jay at satirist.org Sun Feb 24 22:37:46 2008 From: jay at satirist.org (Jay Scott) Date: Sun Feb 24 22:35:47 2008 Subject: static constants -- ideas? In-Reply-To: <20080225032334.GN19935@scytale.galois.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> Message-ID: <20080225033746.2135353202@mail.satirist.org> Don Stewart dons@galois.com: >jay: >> I also have constants that are too large to compile. I am resigned to >> loading them from data files--other solutions seem even worse. ... >> Data.Binary eases the irritation somewhat. > >Did you try bytestring literals (and maybe parsing them in-memory with >Data.Binary)? That didn't occur to me, since neither of my large constants includes strings.... I think you're suggesting that each constant could appear in the source as a long bytestring and be deserialized into the data structure. If that works, it should improve the startup time, but it's still not as nice as simply compiling it straight up. I'll try it. Jay From bos at serpentine.com Sun Feb 24 22:46:07 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Feb 24 22:44:05 2008 Subject: static constants -- ideas? In-Reply-To: <20080225033746.2135353202@mail.satirist.org> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> Message-ID: <47C239FF.2020708@serpentine.com> Jay Scott wrote: > That didn't occur to me, since neither of my large constants includes > strings.... The trick I usually use in cases like this is to compile the data as C code and link against it, then access it from Haskell via a Ptr. References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> Message-ID: <20080225040019.GR19935@scytale.galois.com> jay: > Don Stewart dons@galois.com: > >jay: > >> I also have constants that are too large to compile. I am resigned to > >> loading them from data files--other solutions seem even worse. > ... > >> Data.Binary eases the irritation somewhat. > > > >Did you try bytestring literals (and maybe parsing them in-memory with > >Data.Binary)? > > That didn't occur to me, since neither of my large constants includes > strings.... I think you're suggesting that each constant could appear in > the source as a long bytestring and be deserialized into the data > structure. If that works, it should improve the startup time, but it's > still not as nice as simply compiling it straight up. > > I'll try it. Here's an example, which stores a Data.Map in a gzip-compressed bytestring literal (a C string literal in the compiled code). The Map is reconstructed on startup. {-# LANGUAGE OverloadedStrings #-} import Data.Binary import qualified Data.Map as M import qualified Data.ByteString.Char8 as S import Data.ByteString.Lazy import Codec.Compression.GZip -- -- this is a gzip compressed literal bytestring, storing a binary-encoded Data.Map -- mytable = "\US\139\b\NUL\NUL\NUL\NUL\NUL\NUL\ETXEN\219\SO\194 \f\197\224\188\196\CAN\227\US\224\171~\NAKc\GS4ce\161`\178\191\215(\176\190\180\167\231\210\n\241\171\203\191\ti\157\217\149\249< \ENQ\214\&9>\202\162\179a\132X\233\ESC=\231\215\164\SYN\157\DC2D\226*\146\174o\t\167\DLE\209\"i_\240\193\129\199 References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> Message-ID: <47C29BC4.90604@list.mightyreason.com> Is it _possible_ to use Template Haskell to take the name of the external binary file and produce such a bytestring literal? From simonmarhaskell at gmail.com Mon Feb 25 06:14:08 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 25 06:12:34 2008 Subject: how to use ghci-debugger with packages In-Reply-To: <20080224023358.GD13696@a5.repetae.net> References: <20080224011859.GA6714@a5.repetae.net> <200802240236.08237.daniel.is.fischer@web.de> <20080224023358.GD13696@a5.repetae.net> Message-ID: <47C2A300.4020501@gmail.com> Frederik Eaton wrote: > Thanks, I may try that. I'm currently trying to get my GNU-make-based > build to install profiling versions of package modules, in the hope > that -xc might give more useful information than it did a year ago... I would think the chances of that are fairly low, there haven't been any significant changes to the way cost centres work. Cheers, Simon From simonpj at microsoft.com Mon Feb 25 06:24:30 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 25 06:22:30 2008 Subject: static constants -- ideas? In-Reply-To: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C31F96DE7805@EA-EXMSG-C334.europe.corp.microsoft.com> | On another note, I am extremely curious about the difference | between statically compiling a list and building it at | runtime. I find it hard to wrap my head around the fact that I | can build the list at runtime in a short time, but can not | compile it without eating all of my machine's RAM. It's not quite as stupid as it sounds. The run-time version is like an *interpreter*: you write an interpreter (a parser in fact) that interprets the byte-strings you read from disk, and builds in-heap data. The compile time version is, well, a compiler, and generates statically-allocated data. This may be a lot bigger than the interpreter, of course, and it all has to be stuffed through all the compiler phases. That should certainly be possible, but it's just something that GHC is not well optimised for. We are actively working on the more egregious manifestations thought: see http://hackage.haskell.org/trac/ghc/ticket/2002. Anyway, have another go when you see that #2002 is fixed. Simon From frederik at a5.repetae.net Mon Feb 25 06:50:27 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Feb 25 06:48:26 2008 Subject: how to use ghci-debugger with packages In-Reply-To: <47C2A300.4020501@gmail.com> References: <20080224011859.GA6714@a5.repetae.net> <200802240236.08237.daniel.is.fischer@web.de> <20080224023358.GD13696@a5.repetae.net> <47C2A300.4020501@gmail.com> Message-ID: <20080225115027.GJ13696@a5.repetae.net> On Mon, Feb 25, 2008 at 11:14:08AM +0000, Simon Marlow wrote: > Frederik Eaton wrote: > > >Thanks, I may try that. I'm currently trying to get my GNU-make-based > >build to install profiling versions of package modules, in the hope > >that -xc might give more useful information than it did a year ago... > > I would think the chances of that are fairly low, there haven't been any significant > changes to the way cost centres work. OK thanks... Actually I got the GHCi debugger to help me (having discovered -fbreak-on-exception). Frederik P.S. Here are some suggestions for the GHCi debugger documentation: http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger." --> "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger. Note that packages only contain compiled code - so debugging a package requires finding its source and loading that directly." "There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error." --> "There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error. For instance, it is possible to break automatically when an exception is thrown, even if it is thrown from within compiled code (see 3.5.6. Debugging exceptions)." From simonmarhaskell at gmail.com Tue Feb 26 05:17:02 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 05:15:03 2008 Subject: Visual Haskell sources In-Reply-To: References: Message-ID: <47C3E71E.6080603@gmail.com> Andrei Formiga wrote: > Hello, > > The Visual Haskell 0.2 release notes [1] say that sources are > available, but the download page only has binaries available. Where > are the sources? Also, does it use the Visual Studio SDK, and is it > compatible with VS 2008? Thanks. > > > [1] http://haskell.org/visualhaskell/doc/index.html#release-notes > Sources are here: http://darcs.haskell.org/vshaskell/ good luck compiling it :-) Cheers, Simon From simonmarhaskell at gmail.com Tue Feb 26 05:26:38 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 05:24:40 2008 Subject: how to use ghci-debugger with packages In-Reply-To: <20080225115027.GJ13696@a5.repetae.net> References: <20080224011859.GA6714@a5.repetae.net> <200802240236.08237.daniel.is.fischer@web.de> <20080224023358.GD13696@a5.repetae.net> <47C2A300.4020501@gmail.com> <20080225115027.GJ13696@a5.repetae.net> Message-ID: <47C3E95E.7060209@gmail.com> Frederik Eaton wrote: > P.S. Here are some suggestions for the GHCi debugger documentation: > > http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html > > "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger." > --> > "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger. Note that packages only contain compiled code - so debugging a package requires finding its source and loading that directly." > > "There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error." > --> > "There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error. For instance, it is possible to break automatically when an exception is thrown, even if it is thrown from within compiled code (see 3.5.6. Debugging exceptions)." Thanks! I'll push these changes. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Feb 26 06:47:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 07:03:39 2008 Subject: H98 Text IO Message-ID: <1204026469.3076.381.camel@localhost> >From the H98 report: All I/O functions defined here are character oriented. [...] These functions cannot be used portably for binary I/O. In the following, recall that String is a synonym for [Char] (Section 6.1.2). So ordinary text Handles are for text, not binary. Char is of course a Unicode code point. The crucial question of course is what encoding of text to use. For the H98 IO functions we cannot set it as a parameter, we have to pick a sensible default. Currently different implementations disagree on that default. Hugs has for some time used the current locale on posix systems (and I'm guessing the current code page on windows). GHC has always used the Latin-1 encoding. These days, most operating systems use a locale/codepage encoding that covers full the Unicode range. So on hugs we get the benefit of that but on GHC we do not. This is endlessly surprising for beginners. They do putStrLn "???????????" and it comes out on their terminal as junk. It also causes problems for serious programs, see for example the recent hand-wringing on cabal-devel. So here is a concrete proposal: * Haskell98 file IO should always use UTF-8. * Haskell98 IO to terminals should use the current locale encoding. The main controversial point I think is whether to always use UTF-8 or always use the current locale or some split as I've suggested. C chose to always go with the current locale. Some people think that was a mistake because the interpretation changes from user to user. For terminals it is more clear cut that the locale is the right choice because that is what the terminal is capable of displaying. Using anything else will produce junk. We can detect if a handle is a terminal when we open it using hIsTerminalDevice. This should be done automatically (and ghc would ghc get it for free because it already does that check to determine default buffering modes). Sockets and pipes would be treated the same as files when opened in the default text mode. The only special case is terminals. The major problem is with code that assumes GHC's Handles are essentially Word8 and layer their own UTF8 or other decoding over the top. The utf8-string package has this problem for example. Such code should be using openBinaryFile because they are reading/writing binary data, not String text. Note that many programs that really need to work with binary file already use openBinaryFile, those that do not are already broken on Windows which does cr/lf conversion on text files which breaks many binary formats (though not utf8). So we have decide which is more painful, keeping a limited text IO system in GHC or breaking some existing programs which assume GHC's current behaviour. Opinions? Please can we keep this discussion to the interpretation of the H98 IO functions and not get into the separate discussion of how we could extend or redesign the whole IO system. This is a questions of what are the right defaults. Duncan From john at repetae.net Tue Feb 26 07:41:49 2008 From: john at repetae.net (John Meacham) Date: Tue Feb 26 07:39:42 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <20080226124148.GC5260@sliver.repetae.net> I came to the same conclusions. I think using either the current encoding or utf8 are perfectly reasonable interpretations of the standard. Jhc used to use the current locale always, but now it uses utf8 always as that was easier to make portable to other operating systems. (though current locale support will likely be added back at some point) I think this is a-okay as far as haskell 98 goes. Assuming latin1 without doing an 'openBinaryFile' is certainly not okay in my book. John -- John Meacham - ?repetae.net?john? From simonmarhaskell at gmail.com Tue Feb 26 08:22:07 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 08:20:07 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <47C4127F.2020204@gmail.com> Duncan Coutts wrote: >>From the H98 report: > > All I/O functions defined here are character oriented. [...] > These functions cannot be used portably for binary I/O. > > In the following, recall that String is a synonym for [Char] > (Section 6.1.2). > > So ordinary text Handles are for text, not binary. Char is of course a > Unicode code point. > > The crucial question of course is what encoding of text to use. For the > H98 IO functions we cannot set it as a parameter, we have to pick a > sensible default. Currently different implementations disagree on that > default. Hugs has for some time used the current locale on posix systems > (and I'm guessing the current code page on windows). GHC has always used > the Latin-1 encoding. > > These days, most operating systems use a locale/codepage encoding that > covers full the Unicode range. So on hugs we get the benefit of that but > on GHC we do not. > > This is endlessly surprising for beginners. They do > putStrLn "???????????" > and it comes out on their terminal as junk. > > It also causes problems for serious programs, see for example the recent > hand-wringing on cabal-devel. > > So here is a concrete proposal: > > * Haskell98 file IO should always use UTF-8. > * Haskell98 IO to terminals should use the current locale > encoding. While I support Duncan's proposal (we discussed it on IRC), I thought I should point out some of the ramifications of this, and the alternatives. If everything that is not a terminal uses UTF-8 by default, then shell commands may behave in an unexpected way, e.g. for a Haskell program "prog", prog | cat will output in UTF-8, and if your locale encoding is something other than UTF-8 you'll see junk. Similarly, prog >file; cat file will give the same (wrong) result. So some alternatives that fix this are 1. all text I/O is in the locale encoding (what C and Hugs do) 2. stdin/stdout/stderr and terminals are always in the locale encoding, everything else is UTF-8 3. everything is UTF-8 (1) has the advantage of being easy to understand, but causes problems when you want to move a file created on one system to another system, or share files between users. The programmer in this case has to anticipate the problem and set an encoding (and we're not proposing to provide a way to specify encodings, yet, so openBinaryFile and a separate UTF-8 step would be required). (2) has a sort of "do what I want" feel, and will almost certanly cause confusion in some cases, simply because it's an aribtrary choice. (3) is easy to understand, but does the wrong thing for people who have a locale encoding other than UTF-8. Duncan's proposal occupies a useful point: text that we know to be ephemeral, because it is being sent to a terminal, is definitely sent in the user's default encoding. Text that might be persistent or might be crossing a locale-boundary is always written in UTF-8, which is good for interchange and portability, the catch is that sometimes we identify a Handle as persistent when it is really ephemeral. Note that sensible people who set their locale to UTF-8 are not affected by any of this - and that includes most new installations of Linux these days, I believe. Cheers, Simon From rl at cse.unsw.edu.au Tue Feb 26 08:31:43 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 08:29:43 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <47C414BF.3000302@cse.unsw.edu.au> Duncan Coutts wrote: > > So here is a concrete proposal: > > * Haskell98 file IO should always use UTF-8. > * Haskell98 IO to terminals should use the current locale > encoding. Personally, I'd find this deeply surprising. I don't care that much what locale gets used for I/O (if it matters, you have to deal with it explicitly anyway) as long as it is consistent. I'm probably mistaken, but doesn't this proposal mean that I can't implement cat in H98 using text I/O? That would be a bit disturbing. Also, would this affect the encoding used for file names? If so, how? Roman From duncan.coutts at worc.ox.ac.uk Tue Feb 26 08:34:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 08:41:39 2008 Subject: H98 Text IO In-Reply-To: <47C4127F.2020204@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> Message-ID: <1204032894.3076.393.camel@localhost> On Tue, 2008-02-26 at 13:22 +0000, Simon Marlow wrote: > So some alternatives that fix this are > > 1. all text I/O is in the locale encoding (what C and Hugs do) > > 2. stdin/stdout/stderr and terminals are always in the locale > encoding, everything else is UTF-8 I was initially confused about how this one was different from what I first proposed. The difference is that I was suggesting stdin/stdout/stderr be in the locale *only* if thet're connected to a terminal, rather than always. > 3. everything is UTF-8 Personally I'm not really fussed about which compromise we pick. I think the more important point is that all the Haskell implementations pick the same compromise so that we can effectively standardise the behaviour. Duncan From duncan.coutts at worc.ox.ac.uk Tue Feb 26 08:46:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 08:49:29 2008 Subject: H98 Text IO In-Reply-To: <47C414BF.3000302@cse.unsw.edu.au> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> Message-ID: <1204033604.3076.398.camel@localhost> On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: > Duncan Coutts wrote: > > > > So here is a concrete proposal: > > > > * Haskell98 file IO should always use UTF-8. > > * Haskell98 IO to terminals should use the current locale > > encoding. > > Personally, I'd find this deeply surprising. I don't care that much what > locale gets used for I/O (if it matters, you have to deal with it > explicitly anyway) as long as it is consistent. I'm probably mistaken, > but doesn't this proposal mean that I can't implement cat in H98 using > text I/O? That would be a bit disturbing. You've never been able to do that with the guarantees provided by H98. The current base lib provides System.IO.openBinaryFile which does make it possible to implement cat on binary files. > Also, would this affect the encoding used for file names? If so, how? No, that's a separate issue. Duncan From rl at cse.unsw.edu.au Tue Feb 26 09:14:41 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 09:12:44 2008 Subject: H98 Text IO In-Reply-To: <1204033604.3076.398.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <1204033604.3076.398.camel@localhost> Message-ID: <47C41ED1.8020704@cse.unsw.edu.au> Duncan Coutts wrote: > On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: >> Duncan Coutts wrote: >>> So here is a concrete proposal: >>> >>> * Haskell98 file IO should always use UTF-8. >>> * Haskell98 IO to terminals should use the current locale >>> encoding. >> Personally, I'd find this deeply surprising. I don't care that much what >> locale gets used for I/O (if it matters, you have to deal with it >> explicitly anyway) as long as it is consistent. I'm probably mistaken, >> but doesn't this proposal mean that I can't implement cat in H98 using >> text I/O? That would be a bit disturbing. > > You've never been able to do that with the guarantees provided by H98. As a matter of fact, 21.10.2 from the Haskell Report suggests that at least copying text files should be possible. Unless I'm mistaken, your proposal would invalidate that example somewhat. This begs another question. What exactly does "current locale" mean, given that we have lazy I/O and the locale can be changed on the fly? >> Also, would this affect the encoding used for file names? If so, how? > > No, that's a separate issue. Hmm, so how do I reliably read a list of file names from a file? Roman From simonmarhaskell at gmail.com Tue Feb 26 09:18:17 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 09:16:25 2008 Subject: H98 Text IO In-Reply-To: <47C4127F.2020204@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> Message-ID: <47C41FA9.7020104@gmail.com> Simon Marlow wrote: > Duncan Coutts wrote: Let's call this one proposal 0: >> * Haskell98 file IO should always use UTF-8. >> * Haskell98 IO to terminals should use the current locale >> encoding. and the others: > 1. all text I/O is in the locale encoding (what C and Hugs do) > > 2. stdin/stdout/stderr and terminals are always in the locale > encoding, everything else is UTF-8 > > 3. everything is UTF-8 Some other points that came up on IRC: - there's a long precedent for behaving differently when connected to a terminal. For example, 'ls' formats output in columns when connected to a terminal, or displays output in colour. This is a point in favour of (0). - we might expect that "prog file" behaves the same as "prog References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <1204033604.3076.398.camel@localhost> <47C41ED1.8020704@cse.unsw.edu.au> Message-ID: <47C42F8A.8010602@gmail.com> Roman Leshchinskiy wrote: > Duncan Coutts wrote: >> On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: >>> Also, would this affect the encoding used for file names? If so, how? >> >> No, that's a separate issue. > > Hmm, so how do I reliably read a list of file names from a file? You didn't say what format the file takes, so there are a couple of options. If you get to choose the format, then using read/show is easiest. If you're stuck with a predefined format, say one filename per line, then it depends what system you're on: - on Windows, filenames are Unicode, so the file must be in some encoding: decode it appropriately. - on Unix, filenames are binary, so use openBinaryFile and hGetLine. Yes, this is all broken (in particular FilePath == [Char] is wrong), but at least it's possible to do what you want, and it's not getting any worse with the proposed change. Filenames are something else that need an overhaul, but one thing at a time. Cheers, Simon From john at repetae.net Tue Feb 26 10:28:07 2008 From: john at repetae.net (John Meacham) Date: Tue Feb 26 10:26:00 2008 Subject: H98 Text IO In-Reply-To: <1204032894.3076.393.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> Message-ID: <20080226152807.GD5260@sliver.repetae.net> On Tue, Feb 26, 2008 at 01:34:54PM +0000, Duncan Coutts wrote: > Personally I'm not really fussed about which compromise we pick. I think > the more important point is that all the Haskell implementations pick > the same compromise so that we can effectively standardise the > behaviour. Wait, are you talking about changing what ghc does or trying to change the haskell standard? I always thought ghc should do something more sane with character IO, non unicode aware programs are a blight. I don't think choosing something arbitrary to standardize on is a good idea. It is not always clear what the best choice is. like, for instance until recently, jhc used locale encoding on linux, due to glibc's strong charset support and guarenteed use of unicode wchar_t's, but utf8 always on bsd-varients, where the wchar_t situation was less clear cut. On embedded systems, only supporting ASCII IO is certainly a valid choice. For a .NET backend, we will want to use .NET's native character IO routines. The important thing is standardizing how _binary_ handles work across compilers. As long as everyone has a compatible openBinaryHandle then we can layer whatever we want on it with compatible libraries. I think the current behavior of GHC is poor and should be fixed, I believe the intent of the haskell 98 standard is that character IO be performed in a suitable system specific way, which always truncating to 8bits does not meet IMHO. But no need to prescribe something arbitrary language-wide for a particular issue with ghc. John -- John Meacham - ?repetae.net?john? From jpvogel1 at gmail.com Tue Feb 26 11:59:34 2008 From: jpvogel1 at gmail.com (John Vogel) Date: Tue Feb 26 11:57:27 2008 Subject: H98 Text IO In-Reply-To: <20080226152807.GD5260@sliver.repetae.net> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> <20080226152807.GD5260@sliver.repetae.net> Message-ID: Why not leave the defaults as they ARE OR USE utf-8 and give the programmer the capability to specify what encoding they want when they want to use a different one? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080226/31f2759e/attachment.htm From haskell at list.mightyreason.com Tue Feb 26 12:42:25 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Feb 26 12:40:24 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <47C44F81.8070907@list.mightyreason.com> The H98 spec has the inside half of story nailed down: Char is Unicode, and Handles are text I/O that deal in [Char]. The outside half of the story is the binary encoding of the [Char], which was unspecified, and left to the implementation. The implementation dependence allows GHC to create a "setHandleEncoding" (or "withHandleEncoding") operation. [I do not want to get bogged down in syntax]. This is something that, like all details of encoding, is not the H98 spec. In addition, there may be some command line parameters to GHC. Imagine that GHC 6.10.1 is released with encoding support. If the user runs ghc with no options or setup changes, then the new defaults will apply. The goal is that more complicated situations are reflected in more complicated "ghc" or "main" invocations. The least complicated usage defaults to being identical cross-platform and regardless of terminal I/O. I think the best default would be UTF8 for all text handles. This can be easily documented, it can be easily understood, and will produce the fewest suprises. I imagine that in this proposed ghc-6.10.1: * GHC's handles now carry an encoding parameter. ** There is a way to create a new handle from an old one that differs only in the encoding. (perhaps 'hNew <- cloneHandleWithEncoding "Latin1" hOld') * GHC's has mutable global variables that control the encoding parameter of new handles. ** Unless influenced by command-line switches, these default to UTF8. ** There are IO commands to read & write these global variables. ** There are different defaults for new terminal I/O handles and other I/O handles, so they could be given different encodings. If you want to use the "local" or native encoding, then compile with "ghc --local-encoding" or start the program with something like "main = handlesUseLocalEncoding >> do ..." If you want to use "Latin1" then use either "ghc --encoding Latin1" or "main = handlesUseEncoding "Latin1" >> do ..." To compile older programs one could use "ghc --compat 6.8" or "ghc --encoding Latin1" to access the old defaults. One might even add "+RTS --encoding Latin1 -RTS" runtime options to set the initial encoding. Though I think this is unlikely to be useful in practice. I think that having terminal I/O be special is great for command line applications. But the nice behavior of such applications like "ls" must not determine what the GHC runtime does by default. From tux_rocker at reinier.de Tue Feb 26 14:44:25 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Tue Feb 26 14:57:40 2008 Subject: H98 Text IO Message-ID: Op 26-feb-2008, om 18:42 heeft Chris Kuklewicz het volgende geschreven: > The goal is that more complicated situations are reflected in > more complicated "ghc" or "main" invocations. The least complicated > usage defaults to being identical cross-platform and regardless of > terminal I/O. > > I think the best default would be UTF8 for all text handles. This can > be easily documented, it can be easily understood, and will produce > the fewest suprises. > (...) > ** Unless influenced by command-line switches, these default to UTF8. I think that making the behavior of programs change, depending on compiler options, will produce a lot of surprises. I think that being only able to set the default encoding from within the program is a better idea, because it keeps the specification of the behavior of the program inside the source. Reinier From duncan.coutts at worc.ox.ac.uk Tue Feb 26 16:15:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 16:15:25 2008 Subject: H98 Text IO In-Reply-To: <20080226152807.GD5260@sliver.repetae.net> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> <20080226152807.GD5260@sliver.repetae.net> Message-ID: <1204060549.3076.408.camel@localhost> On Tue, 2008-02-26 at 07:28 -0800, John Meacham wrote: > On Tue, Feb 26, 2008 at 01:34:54PM +0000, Duncan Coutts wrote: > > Personally I'm not really fussed about which compromise we pick. I think > > the more important point is that all the Haskell implementations pick > > the same compromise so that we can effectively standardise the > > behaviour. > > Wait, are you talking about changing what ghc does or trying to change > the haskell standard? I always thought ghc should do something more sane > with character IO, non unicode aware programs are a blight. > > I don't think choosing something arbitrary to standardize on is a good > idea. It is not always clear what the best choice is. like, for instance > until recently, jhc used locale encoding on linux, due to glibc's strong > charset support and guarenteed use of unicode wchar_t's, but utf8 always > on bsd-varients, where the wchar_t situation was less clear cut. On > embedded systems, only supporting ASCII IO is certainly a valid choice. > For a .NET backend, we will want to use .NET's native character IO > routines. Oh I wasn't trying to pin it down that much. If you want to use ebdic on some embedded platform by default I don't care. I really mean that it'd be nice if hugs, ghc, jhcm nhc98 etc could agree for each of the major platforms, Linux/Unix, OS X and Windows. And I don't mean necessarily that they should do the same thing across platforms (eg as I understand it OS X would always use UTF8 not a variable locale) just that they should do the same on the same platform. So not a change of the H98 spec, just a common consensus on the major platforms. Duncan From duncan.coutts at worc.ox.ac.uk Tue Feb 26 16:24:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 16:22:52 2008 Subject: H98 Text IO In-Reply-To: <47C41ED1.8020704@cse.unsw.edu.au> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <1204033604.3076.398.camel@localhost> <47C41ED1.8020704@cse.unsw.edu.au> Message-ID: <1204061095.3076.418.camel@localhost> On Wed, 2008-02-27 at 01:14 +1100, Roman Leshchinskiy wrote: > Duncan Coutts wrote: > > On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: > >> I'm probably mistaken, > >> but doesn't this proposal mean that I can't implement cat in H98 using > >> text I/O? That would be a bit disturbing. > > > > You've never been able to do that with the guarantees provided by H98. > > As a matter of fact, 21.10.2 from the Haskell Report suggests that at > least copying text files should be possible. Unless I'm mistaken, your > proposal would invalidate that example somewhat. > This begs another question. What exactly does "current locale" mean, > given that we have lazy I/O and the locale can be changed on the fly? The current locale is a Posix concept. There are posix functions for changing it. I'd suggest that a Handle inherits the current locale as its encoding at the point of creation of the Handle. Further changes to the posix locale would not change any existing open Handles. If we were to provide an action to change the encoding of an open Handle then it is clear that it cannot act on semi-closed handles. That'd make lazy IO ok. From haskell at list.mightyreason.com Tue Feb 26 16:27:31 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Feb 26 16:25:26 2008 Subject: H98 Text IO In-Reply-To: References: Message-ID: <47C48443.5050907@list.mightyreason.com> Reinier Lamers wrote: > Op 26-feb-2008, om 18:42 heeft Chris Kuklewicz het volgende geschreven: >> The goal is that more complicated situations are reflected in >> more complicated "ghc" or "main" invocations. The least complicated >> usage defaults to being identical cross-platform and regardless of >> terminal I/O. >> >> I think the best default would be UTF8 for all text handles. This can >> be easily documented, it can be easily understood, and will produce >> the fewest suprises. > > (...) >> ** Unless influenced by command-line switches, these default to UTF8. > I think that making the behavior of programs change, depending on > compiler options, will produce a lot of surprises. I think that being > only able to set the default encoding from within the program is a > better idea, because it keeps the specification of the behavior of the > program inside the source. > > Reinier I thought about that. I started with realizing that *all* code written for GHC is written knowing Handles only return Word8 sized Latin1 characters. So there are several way one might proceed, some of which are: 1) No command line switches, default to Latin1. To get unicode you call a special 'turnOnUnicodeHandleGoodness' IO operation. This is good since it does not break old code. 2) No command line switches, default to something new. This required all old code to be conditionally retrofit with a 'turnOffUnicode' IO operation. This breaks much of the code that has been written, and is thus bad. 3) Add a "ghc --turn-on-unicode" command line switch. This makes all old code build just fine, since it lacks the switch to activate the new behavior. 4) Add a "ghc --turn-off-unicode" command line switch. This is nice since it lets new code use the new Handle encoding by default, but not nice in requiring that old code built using ghc-6.10 use an additional option. I also think the following are likely to be true: *) Cabal is already controlling the ghc compiler switches for most code. *) The experience of the ghc-6.6 to ghc-6.8 transition involved updating most cabal files to allow old code to work with new compiler. *) Other changes, unrelated to the unicode handles, will require most old packages to update their cabal files to with with ghc-6.10 *) The additional work to updated the cabal file to add the "--turn-off-unicode" command line switch to ghc would be 1 word to 1 line. So I think that making ghc default to option (4) above saves nearly zero work when updating old cabal files compared to option (3). The benefit of option (3) compared to (4) is that no boilerplate will be needed to obtain the new handle encoding. And I simply prefer that the better handle encoding be the default; move the implementation forward. Now if GHC does not have a command line switch then either with (2) you have to conditionally (perhaps with #ifdef) update almost every bit of code on hackage or with (1) you have all future programs burdened with boilerplate, which some people may forget. So I will enjoy having switches as well as the IO commands. From duncan.coutts at worc.ox.ac.uk Tue Feb 26 19:06:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 19:04:55 2008 Subject: H98 Text IO In-Reply-To: <47C41FA9.7020104@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> Message-ID: <1204070819.3076.490.camel@localhost> On Tue, 2008-02-26 at 14:18 +0000, Simon Marlow wrote: > Simon Marlow wrote: > > Duncan Coutts wrote: > > Let's call this one proposal 0: > > >> * Haskell98 file IO should always use UTF-8. > >> * Haskell98 IO to terminals should use the current locale > >> encoding. > > and the others: > > > 1. all text I/O is in the locale encoding (what C and Hugs do) > > > > 2. stdin/stdout/stderr and terminals are always in the locale > > encoding, everything else is UTF-8 > > > > 3. everything is UTF-8 So it's clear that all these solutions have some downsides. We have to decide what is more important. Let me try and summarise: basically we can be consistent with the OS environment or consistent with other Haskell systems in other environments or try to get some mixture of the two. It is pretty clear however that trying to get a mixture still leads to some inconsistency with the OS environment. * "status quo" (what ghc/hugs do now) This gives consistency with the OS environment with hugs and jhc but not ghc, nhc or yhc. It gives consistency between haskell programs (using the same haskell implementation) on different platforms for ghc and nhc but not for hugs or jhc. There is no consistency between haskell implementations. * "always locale" (solution 1 above) This gives us consistency with the OS environment. All of the shell snippets people have posted work with this. The main disadvantage is that files moved between systems may be interpreted differently. * "always utf8" (solution 3 above) This gives consistency between Haskell programs across platforms. The main disadvantage is that it is very unhelpful if the locale is not UTF8. It fails the "putStr" test of printing string literals to the terminal. * "mixture A" (solution 0 above) The input/output format changes depending on the device. prog | cat prints junk in non-UTF8 locales. * "mixture B" (solution 2 above) The output format changes depending on the device. prog in behaves differently to prog < in. And some example people have noted: * putStr "???????????" That is just printing a string literal to the console/terminal. Now that major implementations support Unicode .hs source files it's kind of nice if this works. This works with "always locale" and "mixture A" and "mixture B" above. This fails for "status quo" with ghc (but works for hugs) and fails for "always utf8" unless the locale happens to be utf8. * ./prog vs ./prog | cat That is, piping the output of a haskell program through cat and printing the result to a terminal produces the same output as displaying the program output directly. This works with "always locale" and "mixture B" and fails with "mixture A". With "always utf8" and with "status quo" it has the property that it consistently produces the same junk on the terminal which some people see as a bonus (when not in a utf8 or latin1 locale respectively). * ./prog vs ./prog >file; cat file This is another variation on the above and it has the same failures. * ./prog in vs ./prog < in That is reading a file given as a command line arg via readFile gives the same result as reading stdin that has been redirected from a the same file. This works with "always locale" and "mixture A" and fails with "mixture B". This is the dual of the previous two examples. This fails with "always utf8" and with "status quo" when the file was produced by another text processing program from the same environment (eg a generic text editor). * ./foo vs ./foo | hexdump -C The output bytes we get sent to the terminal is exactly the same as what we see piped to a program to examine those bytes. This fails for "mixture A" and works for all the others. Works in the strict sense that the bytes are the same, not in the sense that the text output is readable. So the problem with the mixture approaches is that the terminal and files and pipes are all really interchangeable so we can find surprising inconsistencies within the same OS environment. The problem with the "always utf8" is that it's never right unless the locale is set to utf8. As a data point, Java and python use "always locale" as default if you don't specify an encoding when opening a text stream. I think personally I'm coming round to the "always locale" point of view. We already have no cross-platform consistency for text files because of the lf vs cr/lf issue and we have no cross-implementation consistency. Duncan From haskell at list.mightyreason.com Wed Feb 27 03:54:17 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Feb 27 03:52:11 2008 Subject: H98 Text IO In-Reply-To: <20080227073358.GB6257@holst> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> <20080227073358.GB6257@holst> Message-ID: <47C52539.2060307@list.mightyreason.com> Small correction: I think "./prog in vs ./prog < in " and "utf8" should be "ok". (and I thought this was switched to Glasgow-haskell-users@haskell.org) David Leuschner wrote: >> Let me try and summarise: > > Thanks for the great summary! And thanks to Emacs' table mode here're the > results displayed as a table: > > +--------------------------------+-----+--------+------+-------+-------+ > | | now | locale | utf8 | mix-A | mix-B | > +--------------------------------+-----+--------+------+-------+-------+ > | putStrLn "..." | - | ok | - | ok | ok | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog vs ./prog | cat | ok | ok | ok | - | ok | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog in vs ./prog < in | - | ok | - | ok | - | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog vs ./prog | hexdump -C | ok | ok | ok | - | ok | > +--------------------------------+-----+--------+------+-------+-------+ > > > The mixtures are good ideas but can give inconsistent and suriprising > results (especially when debugging encoding issues). And if our CEO would > have known that ... putStrLn ... doesn't work he'd have > probably ruled out Haskell right from the start. Even "utf8" gives > surprising results: I'd be very surprised if my Mac-written Haskell > program outputs junk on Windows or Linux even if the byte sequence is > exactly the same UTF-8 text. > > Personally I think consistency on a single platform is more important than > trying to achieve cross-platform consistency which involves a lot more > than just encoding. If you've reached that point with your program you're > probably anyway using "advanced functions" to exactly specify what will be > output. Following "the principle of least surprise" is also a good idea. > > Cheers, > > David > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From johan.tibell at gmail.com Wed Feb 27 04:25:39 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Feb 27 04:23:36 2008 Subject: H98 Text IO In-Reply-To: <1204070819.3076.490.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> Message-ID: <90889fe70802270125l11b765b9pb936412df7687f73@mail.gmail.com> On Wed, Feb 27, 2008 at 1:06 AM, Duncan Coutts wrote: > As a data point, Java and python use "always locale" as default if you > don't specify an encoding when opening a text stream. > > I think personally I'm coming round to the "always locale" point of > view. We already have no cross-platform consistency for text files > because of the lf vs cr/lf issue and we have no cross-implementation > consistency. I think following Java and Python in this matter is a good idea and leads to fewer surprises for developers. If you want files created on one machine to work on another you have to be explicit about encoding. -- Johan From matthew_bentham at yahoo.com Wed Feb 27 06:35:38 2008 From: matthew_bentham at yahoo.com (Matthew Bentham) Date: Wed Feb 27 06:33:30 2008 Subject: H98 Text IO Message-ID: <196452.41270.qm@web51603.mail.re2.yahoo.com> ----- Original Message ---- > From: Johan Tibell > To: Duncan Coutts > Cc: Haskell Libraries ; GHC-users list ; Simon Marlow > Sent: Wednesday, February 27, 2008 9:25:39 AM > Subject: Re: H98 Text IO > > On Wed, Feb 27, 2008 at 1:06 AM, Duncan Coutts > wrote: > > As a data point, Java and python use "always locale" as default if you > > don't specify an encoding when opening a text stream. > > > > I think personally I'm coming round to the "always locale" point of > > view. We already have no cross-platform consistency for text files > > because of the lf vs cr/lf issue and we have no cross-implementation > > consistency. > > I think following Java and Python in this matter is a good idea and > leads to fewer surprises for developers. If you want files created on > one machine to work on another you have to be explicit about encoding. I'm a newcomer to haskell so I don't want to goof by offering any naive opinions, but I would like to inform the discussion by linking to a couple of useful things. This blog post on encodings in python (mostly related to the behaviour of the standard input/output streams): http://drj11.wordpress.com/2007/05/14/python-how-is-sysstdoutencoding-chosen/ Particularly: "It?s not unreasonable to have a program that wants to encode its outputin a particular encoding. The example I gave earlier still seemsreasonable to be, a program that takes input in one encoding andrecodes to a different encoding on its output, with both the input andoutput encoding specified on the command line. Clearly such a programshould be able to use stdin and stdout so that it can form part of apipe. So how in Python do I change sys.stdout to use a particular encoding? It?s a right pain." And the reference to the POSIX documentation related to locale, mentioned earlier in this thread: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html The problem that I see is generally that because stdin/out/err are _already_open_ by the time they reach the haskell program, it is pretty hard for the developer "to be explicit about encoding" if no library is provided to effectively change the encoding used by an already-open stream. From duncan.coutts at worc.ox.ac.uk Wed Feb 27 06:51:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 27 06:49:35 2008 Subject: H98 Text IO In-Reply-To: <47C52539.2060307@list.mightyreason.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> <20080227073358.GB6257@holst> <47C52539.2060307@list.mightyreason.com> Message-ID: <1204113085.3076.531.camel@localhost> On Wed, 2008-02-27 at 08:54 +0000, Chris Kuklewicz wrote: > Small correction: > > I think "./prog in vs ./prog < in " and "utf8" should be "ok". Ah yes, quite right. Similarly ./prog -o out vs ./prog > out because neither involve printing to the terminal. Duncan From jules at jellybean.co.uk Wed Feb 27 10:52:16 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Feb 27 10:50:10 2008 Subject: H98 Text IO In-Reply-To: <196452.41270.qm@web51603.mail.re2.yahoo.com> References: <196452.41270.qm@web51603.mail.re2.yahoo.com> Message-ID: <47C58730.2020508@jellybean.co.uk> Matthew Bentham wrote: > "It?s not unreasonable to have a program that wants to encode its outputin a particular encoding. The example I gave earlier still seemsreasonable to be, a program that takes input in one encoding andrecodes to a different encoding on its output, with both the input andoutput encoding specified on the command line. Clearly such a programshould be able to use stdin and stdout so that it can form part of apipe. So how in Python do I change sys.stdout to use a particular encoding? It?s a right pain." > Which is an excellent point. But there are two (different) areas here. (1) how we make the over-simplistic H98 interface do something 'mostly right' or 'least worst' (2) how we design a better (but necessarily non-H98) interface for more sophisticated programs. And we need to solve (1) independently of all the possible nice design spaces for (2). Jules From s.clover at gmail.com Wed Feb 27 15:14:52 2008 From: s.clover at gmail.com (Sterling Clover) Date: Wed Feb 27 15:12:48 2008 Subject: Exports of STM constructors. Message-ID: I was recently bitten by the urge to hack around with STM, and discovered to my dismay that there's no way to get at the primitive constructors for TVar and STM, both of which are defined in GHC.Conc. Given that, when we so desire, we can get at the primitives to break IO into pieces, manually unbox integers and such, and that the primitives for working with MVars are similarly exposed through appropriate imports, it would be really nice (or, well, at least fun) to be able to do the same for STM. --S -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080227/7638a6bc/attachment.htm From josef.svenningsson at gmail.com Fri Feb 29 08:52:46 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Fri Feb 29 08:50:30 2008 Subject: STM and fairness Message-ID: <8dde104f0802290552t74713c41j3ea8e42ffbff6dcb@mail.gmail.com> Hi, I'd like to know a bit about the STM implementation in GHC, specifically about how it tries to achieve fairness. I've been reading "Composable Memory Transactions" but it does not contain that much details on this specific matter. What I want to know boils down to this: what order are processes run which have been woken up from a call to retry? When programming with condition variables the standard behaviour is that the process which has waited the longest is the first one to get to run. But that doesn't seem to be the behaviour here. Consider the following program: \begin{code} module STMFair where import Control.Concurrent import Control.Concurrent.STM test n = do v <- newTVarIO 0 mapM_ (\n -> forkIO (process n v) >> threadDelay delay) [1..n] atomically (writeTVar v 1) threadDelay delay delay = 500000 process id var = do putStrLn ("Process " ++ show id ++ " started") atomically $ do v <- readTVar var if v == 0 then retry else return () putStrLn ("Process " ++ show id ++ " finished") \end{code} When I run 'test 2' I expect it to print: Process 1 started Process 2 started Process 1 finished Process 2 finished This would correspond to the oldest process being executed first. But that is not what happens instead I get this (ghci 6.8.2, Ubuntu Linux): Process 1 started Process 2 started Process 2 finished Process 1 finished This is certainly not the behaviour I would want. I discovered this behaviour when implementing the dining philosophers using STM and there one of the philosophers gets starved. Except, that he's not quite starved. When I run the simulation long enough he will eventually be able to eat but then for a long time there will be some other philosopher that is starved. I find this behaviour very mysterious and it would be nice to have some light shed on it. Apart from this mysterious behaviour it seems quite easy to improve the fairness of the implementation. From my examples above it seems that the wait queues for a transactional variable do contain the processes in the order they call retry (try running 'test n' for some large n). It just seems that they are given to the scheduler in the wrong order, so all that needs to be done is to reverse the list. Am I right? Thanks for reading, Josef From zunino at di.unipi.it Fri Feb 29 10:27:45 2008 From: zunino at di.unipi.it (Roberto Zunino) Date: Fri Feb 29 10:58:01 2008 Subject: STM and fairness In-Reply-To: <8dde104f0802290552t74713c41j3ea8e42ffbff6dcb@mail.gmail.com> References: <8dde104f0802290552t74713c41j3ea8e42ffbff6dcb@mail.gmail.com> Message-ID: <47C82471.3080607@di.unipi.it> Josef Svenningsson wrote: > What I want to know boils down to > this: what order are processes run which have been woken up from a > call to retry? IIUC, the order of wake up is irrelevant, since *all* the threads will re-run the transaction in parallel. So, even if thread 1 is the first to wake up, thread 2 might beat it in the race, and complete its transaction first. The execution model should be roughly this one: do not lock anything, run every read/write to TVar's in parallel, performing copy-on-write so that isolation is preserved. When the transaction ends, commit the data written in c-o-w's: lock everything, check that previously read data is still the same, and if it is overwrite the master copy of Tvars, unlock everything. I suggest you put some random delay in your fairness tests, maybe using unsafeIOtoSTM, so that you can improve starvation ;-) Also, try running a very slow (much-delayed) transaction againts several fast ones. I expect the slow one will never reach completion. AFAIK, achieving fairness in STM can be quite hard (not unlike other mainstream approaches to concurrency, sadly). Zun. From josef.svenningsson at gmail.com Fri Feb 29 11:24:57 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Fri Feb 29 11:22:39 2008 Subject: STM and fairness In-Reply-To: <47C82471.3080607@di.unipi.it> References: <8dde104f0802290552t74713c41j3ea8e42ffbff6dcb@mail.gmail.com> <47C82471.3080607@di.unipi.it> Message-ID: <8dde104f0802290824o7b2674daw853601b035a2079d@mail.gmail.com> On Fri, Feb 29, 2008 at 4:27 PM, Roberto Zunino wrote: > Josef Svenningsson wrote: > > What I want to know boils down to > > this: what order are processes run which have been woken up from a > > call to retry? > > IIUC, the order of wake up is irrelevant, since *all* the threads will > re-run the transaction in parallel. So, even if thread 1 is the first to > wake up, thread 2 might beat it in the race, and complete its > transaction first. > That's not quite right since there is no true parallelism here. I'm running on a single core (which I suppose I could have mentioned) and so it is up the scheduler to make sure that processes get a fair chance at doing their business, i.e. achieving fairness. The point I was trying to make is that the scheduler isn't doing a very good job in this case. > I suggest you put some random delay in your fairness tests, maybe using > unsafeIOtoSTM, so that you can improve starvation ;-) > I'd rather fix the scheduler. > Also, try running a very slow (much-delayed) transaction againts several > fast ones. I expect the slow one will never reach completion. > Indeed. This is a well known problem with STM but afaict orthogonal to the problem I'm talking about. > AFAIK, achieving fairness in STM can be quite hard (not unlike other > mainstream approaches to concurrency, sadly). > Yes. Still, in the particular situation I showed I think we can do a better job than what is currently being done. Cheers, Josef From jay at satirist.org Fri Feb 29 13:26:31 2008 From: jay at satirist.org (Jay Scott) Date: Fri Feb 29 14:01:30 2008 Subject: static constants -- ideas? In-Reply-To: <20080225040019.GR19935@scytale.galois.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <20080225040019.GR19935@scytale.galois.com> Message-ID: <20080229182631.931052453@mail.satirist.org> Don Stewart dons@galois.com: >jay: >> Don Stewart dons@galois.com: >> >jay: >> >> I also have constants that are too large to compile. I am resigned to >> >> loading them from data files--other solutions seem even worse. >> ... >> >> Data.Binary eases the irritation somewhat. >> > >> >Did you try bytestring literals (and maybe parsing them in-memory with >> >Data.Binary)? >> >> That didn't occur to me, since neither of my large constants includes >> strings.... I think you're suggesting that each constant could appear in >> the source as a long bytestring and be deserialized into the data >> structure. If that works, it should improve the startup time, but it's >> still not as nice as simply compiling it straight up. >> >> I'll try it. > >Here's an example, which stores a Data.Map in a gzip-compressed >bytestring literal (a C >string literal in the compiled code). The Map is reconstructed on >startup. > > {-# LANGUAGE OverloadedStrings #-} > > import Data.Binary > import qualified Data.Map as M > import qualified Data.ByteString.Char8 as S > import Data.ByteString.Lazy > import Codec.Compression.GZip > > -- > -- this is a gzip compressed literal bytestring, storing a binary- >encoded Data.Map > -- > mytable = > "\US\139\b\NUL\NUL\NUL\NUL\NUL\NUL\ETXEN\219\SO\194 \f\197\224 >\188\196\CAN\227\US\224\171~\NAKc\GS4ce\161`\178\191\215(\176\190\180\167 >\231\210\n\241\171\203\191\ti\157\217\149\249< \ENQ\214\&9>\202\162\179a >\132X\233\ESC=\231\215\164\SYN\157\DC2D\226*\146\174o\t\167\DLE\209\"i_ >\240\193\129\199\203\209x\205\140\166\RS\163\237]9f\170\143\ACK\163g\223\STX\184\&7\rH >\222\FSW\130\&7D\197\NUL\164\&0U\193\186\t\186o\228\180~\NUL\a6\249\137# >\SOH\NUL\NUL" > > main = print =<< M.lookup "ghc" m > where > -- build the table from the bytestring: > m :: M.Map String (Maybe String) > m = decode . decompress . fromChunks . return $ mytable > >Running it: > > $ ./A > Just "dinosaur!" > >:) > >Important to use a bytestring, since that gets compiled to a C string >literal (and not messed >with by the simplifier). > >-- Don > From jay at satirist.org Fri Feb 29 14:06:46 2008 From: jay at satirist.org (Jay Scott) Date: Fri Feb 29 14:04:36 2008 Subject: static constants -- ideas? In-Reply-To: <20080225040019.GR19935@scytale.galois.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <20080225040019.GR19935@scytale.galois.com> Message-ID: <20080229190646.1955876085@mail.satirist.org> Don Stewart dons@galois.com: >jay: >> Don Stewart dons@galois.com: >> >jay: >> >> I also have constants that are too large to compile. I am resigned to >> >> loading them from data files--other solutions seem even worse. >> ... >> >> Data.Binary eases the irritation somewhat. >> > >> >Did you try bytestring literals (and maybe parsing them in-memory with >> >Data.Binary)? I finally squeezed enough time to try it, and it didn't work for me. -- ghc Overflow.hs [1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o ) Overflow.hs:8:10:stack overflow: use +RTS -K to increase it -- where Overflow.hs is in the vicinity of 40M and looks like -- {-# LANGUAGE OverloadedStrings #-} module Overflow where import qualified Data.ByteString.Lazy as S bigData :: S.ByteString bigData = "\0\0\0\0\0\5\67\195\0\0\0\0... -- I didn't compress it, because Codec.Compression.GZip didn't compile for me. It looked like a library change since 6.6 broke it. Is there a handy string escaping function in the libraries somewhere? It only took a minute to write one, and I spent longer than that looking, so maybe it's the wrong question.... Surely it's in there somewhere, and I'm just 2 dum 2 c. Jay From dons at galois.com Fri Feb 29 14:10:30 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 29 14:08:15 2008 Subject: static constants -- ideas? In-Reply-To: <20080229190646.1955876085@mail.satirist.org> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <20080225040019.GR19935@scytale.galois.com> <20080229190646.1955876085@mail.satirist.org> Message-ID: <20080229191030.GB17551@scytale.galois.com> jay: > Don Stewart dons@galois.com: > >jay: > >> Don Stewart dons@galois.com: > >> >jay: > >> >> I also have constants that are too large to compile. I am resigned to > >> >> loading them from data files--other solutions seem even worse. > >> ... > >> >> Data.Binary eases the irritation somewhat. > >> > > >> >Did you try bytestring literals (and maybe parsing them in-memory with > >> >Data.Binary)? > > I finally squeezed enough time to try it, and it didn't work for me. > > -- > ghc Overflow.hs > [1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o ) Enable optimisations! Compile with ghc -O2. You need this to avoid having a very slow pack call at runtime. > Overflow.hs:8:10:stack overflow: use +RTS -K to increase it > -- > > where Overflow.hs is in the vicinity of 40M and looks like > > -- > {-# LANGUAGE OverloadedStrings #-} > > module Overflow where > > import qualified Data.ByteString.Lazy as S > > bigData :: S.ByteString > bigData = "\0\0\0\0\0\5\67\195\0\0\0\0... > -- > > I didn't compress it, because Codec.Compression.GZip didn't compile for > me. It looked like a library change since 6.6 broke it. Probably you don't have the zlib.h header? Or make sure you have the latest version of zlib from hackage -- it does work. > Is there a handy string escaping function in the libraries somewhere? It > only took a minute to write one, and I spent longer than that looking, > so maybe it's the wrong question.... Surely it's in there somewhere, and > I'm just 2 dum 2 c. The show function? From jay at satirist.org Fri Feb 29 14:33:49 2008 From: jay at satirist.org (Jay Scott) Date: Fri Feb 29 14:31:44 2008 Subject: static constants -- ideas? In-Reply-To: <20080229191030.GB17551@scytale.galois.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <20080225040019.GR19935@scytale.galois.com> <20080229190646.1955876085@mail.satirist.org> <20080229191030.GB17551@scytale.galois.com> Message-ID: <20080229193349.1445528694@mail.satirist.org> Don Stewart dons@galois.com: >jay: >> Don Stewart dons@galois.com: >> >jay: >> >> Don Stewart dons@galois.com: >> >> >jay: >> >> >> I also have constants that are too large to compile. I am resigned to >> >> >> loading them from data files--other solutions seem even worse. >> >> ... >> >> >> Data.Binary eases the irritation somewhat. >> >> > >> >> >Did you try bytestring literals (and maybe parsing them in-memory with >> >> >Data.Binary)? >> >> I finally squeezed enough time to try it, and it didn't work for me. > >> >> -- >> ghc Overflow.hs >> [1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o ) > >Enable optimisations! Compile with ghc -O2. You need this to avoid >having a very slow pack call at runtime. Yes, I tried basic variations like that. The result is the same with -O1 or with -O2, and with Data.ByteString or Data.ByteString.Lazy . >> I'm just 2 dum 2 c. > >The show function? Ha ha! Jay From dons at galois.com Fri Feb 29 14:35:10 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 29 14:32:53 2008 Subject: static constants -- ideas? In-Reply-To: <20080229193349.1445528694@mail.satirist.org> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <20080225040019.GR19935@scytale.galois.com> <20080229190646.1955876085@mail.satirist.org> <20080229191030.GB17551@scytale.galois.com> <20080229193349.1445528694@mail.satirist.org> Message-ID: <20080229193510.GC17551@scytale.galois.com> jay: > Don Stewart dons@galois.com: > > >jay: > >> Don Stewart dons@galois.com: > >> >jay: > >> >> Don Stewart dons@galois.com: > >> >> >jay: > >> >> >> I also have constants that are too large to compile. I am resigned to > >> >> >> loading them from data files--other solutions seem even worse. > >> >> ... > >> >> >> Data.Binary eases the irritation somewhat. > >> >> > > >> >> >Did you try bytestring literals (and maybe parsing them in-memory with > >> >> >Data.Binary)? > >> > >> I finally squeezed enough time to try it, and it didn't work for me. > > > >> > >> -- > >> ghc Overflow.hs > >> [1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o ) > > > >Enable optimisations! Compile with ghc -O2. You need this to avoid > >having a very slow pack call at runtime. > > Yes, I tried basic variations like that. The result is the same with -O1 > or with -O2, and with Data.ByteString or Data.ByteString.Lazy . Ok, hmm, that really shouldn't be the case. Do you have the example available somewhere? It's just a 40M inline bytestring? -- Don From simonpj at microsoft.com Fri Feb 29 15:06:10 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 29 15:01:12 2008 Subject: STM and fairness In-Reply-To: <8dde104f0802290552t74713c41j3ea8e42ffbff6dcb@mail.gmail.com> References: <8dde104f0802290552t74713c41j3ea8e42ffbff6dcb@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C31F97234321@EA-EXMSG-C334.europe.corp.microsoft.com> | I'd like to know a bit about the STM implementation in GHC, | specifically about how it tries to achieve fairness. I've been reading | "Composable Memory Transactions" but it does not contain that much | details on this specific matter. What I want to know boils down to | this: what order are processes run which have been woken up from a | call to retry? Tim is the one who implemented this stuff, so I'm ccing him. If threads queue up on a single MVar, it's obvious how to achieve fairness of a sort. Furthremore, if 100 threads are blocked on one MVar, the scheduler can wake up exactly one when the MVar is filled. With STM it's much less obvious. First, a thread may block on a whole bunch of TVars; if any of them are changed, the thread should re-run. So there is no single list of threads to reverse or not reverse. Second, if 100 threads are blocked on a TVar, t, waking up just one of them may not suffice -- it may read some more TVars and then retry again, re-blocking itself on t (plus some more). The only simple thing to do is to wake all of them up. In common situations (e.g. a buffer), we may wake up all 100 threads, only for 99 of them to lose the race and block again. This arises from the fact that transactions do a wonderful thing, by letting you perform multiple operations atomically -- but that makes it harder to optimize. All that said, you may well be right that one could do a better job of scheduling. For example, even though there may be lots of threads blocked on a TVar, and all must be made runnable, they could perhaps be run in the same order that they blocked, so the longest-blocked got to run first. I don't think we try to do that, but Tim would know. By all means suggest a patch! Simon From ben.franksen at online.de Thu Feb 28 17:53:50 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sat Mar 1 15:22:43 2008 Subject: H98 Text IO References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> <20080226152807.GD5260@sliver.repetae.net> <1204060549.3076.408.camel@localhost> <20080226224028.GA6371@holst> Message-ID: David Leuschner wrote: > If I write simple program just printing a non-ASCII string to the terminal > or to a file I'd expect that I can read it on the screen or using my > favorite text editor without having change anything -- neither in my > terminal nor in my program. When I run the program on my platform don't > mind if somebody else might get differently encoded output from the same > program as long as I get what I expect. I think this is sensible advice. Furthermore I want to be able to chose an encoding (e.g. by setting my environment), even for file/socket IO, instead of being locked into utf-8. Thus, for Linux, I'd say always use the environment encoding. More advanced stuff like sending in a certain encoding e.g. over network or to a foreign file system should not use H98 IO but newer libraries that allow to set the encoding programmatically, or encode yourself and read/write Word8. Cheers Ben