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.c