From jason.dusek at gmail.com Sat Mar 1 02:56:50 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Mar 1 02:54:32 2008 Subject: static constants -- ideas? In-Reply-To: <47C239FF.2020708@serpentine.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <47C239FF.2020708@serpentine.com> Message-ID: <42784f260802292356u116805e1s5830c9a237a28827@mail.gmail.com> Bryan O'Sullivan wrote: > The trick I usually use in cases like this is to compile the > data as C code and link against it, then access it from > Haskell via a Ptr. For my particular application, I really need to ship a single static binary that has it all -- data as well as algorithms -- so I'm going with the FFI. It's too bad that I end up working in the IO monad much of the time. I hope we'll have massive static constants someday soon! -- _jsn From jay at satirist.org Sat Mar 1 15:24:03 2008 From: jay at satirist.org (Jay Scott) Date: Sat Mar 1 15:21:51 2008 Subject: static constants -- ideas? In-Reply-To: <42784f260802292356u116805e1s5830c9a237a28827@mail.gmail.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <47C239FF.2020708@serpentine.com> <42784f260802292356u116805e1s5830c9a237a28827@mail.gmail.com> Message-ID: <20080301202403.1099006804@mail.satirist.org> Jason Dusek jason.dusek@gmail.com: >Bryan O'Sullivan wrote: >> The trick I usually use in cases like this is to compile the >> data as C code and link against it, then access it from >> Haskell via a Ptr. > > For my particular application, I really need to ship a single > static binary that has it all -- data as well as algorithms -- > so I'm going with the FFI. It's too bad that I end up working > in the IO monad much of the time. I hope we'll have massive > static constants someday soon! unsafePerformIO should be safe on constants, right? It has worked for me, at least. Jay From jason.dusek at gmail.com Sat Mar 1 19:39:34 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Mar 1 19:37:13 2008 Subject: static constants -- ideas? In-Reply-To: <20080301202403.1099006804@mail.satirist.org> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <20080225032136.1157084960@mail.satirist.org> <20080225032334.GN19935@scytale.galois.com> <20080225033746.2135353202@mail.satirist.org> <47C239FF.2020708@serpentine.com> <42784f260802292356u116805e1s5830c9a237a28827@mail.gmail.com> <20080301202403.1099006804@mail.satirist.org> Message-ID: <42784f260803011639r5330f3c2m8f4bca1a44b59d90@mail.gmail.com> On Sat, Mar 1, 2008 at 12:24 PM, Jay Scott wrote: > Jason Dusek jason.dusek@gmail.com: > unsafePerformIO should be safe on constants, right? It has worked for > me, at least. Unfortunately, reading in the list does not allow me to ship a single binary. It's not file reading, though, that forces me in to the IO Monad -- it's pointer dereferencing. -- _jsn From jason.dusek at gmail.com Sat Mar 1 19:42:22 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Mar 1 19:40:01 2008 Subject: static constants -- ideas? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C31F96DE7805@EA-EXMSG-C334.europe.corp.microsoft.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C31F96DE7805@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <42784f260803011642v10c3d399me6bdfb20902f5e52@mail.gmail.com> Simon Peyton-Jones wrote: > It's not quite as stupid as it sounds...have another go when > you see that #2002 is fixed. Thanks for pointing me to that -- in the meantime, I'd still rather write C and Haskell than plain C++! -- _jsn From rturk at science.uva.nl Mon Mar 3 04:18:04 2008 From: rturk at science.uva.nl (Remi Turk) Date: Mon Mar 3 04:16:48 2008 Subject: GHC code generation micro-optimisation patch Message-ID: <20080303091804.GA3855@krikkit.lan> Hi, during the past semester I followed a seminar on the "Efficient implementation of functional languages" by Jeroen Fokker at the University Utrecht. During that course we worked on a feedback directed GHC optimisation, but that got me interested in another possible GHC backend micro-optimisation: The short story is this: An 8 line patch to GHC, tested with ghc 6.8.2 on nofib, ignoring all results with a < 0.5s runtime, yields an average runtime and compile time improvement of about 0.6%. The worst nofib slowdown is 5%, and the best speedup 8% Whether this is acceptable/enough for inclusion, is of course not up to me. The long story is that in compiler/codeGen/CgUtils.hs:mk_switch, an extra case is added to detect and treat specially the case analysis of 2 constructor datatypes.[1] Previously, case analysis of 2 constructor data types looked as follows in C--: _tmp = R1 & 3; if (_tmp >= 2) goto snd_con_lbl; With this patch, it generates the following: if (R1 & 2 != 0) goto snd_con_lbl; At least on x86 machines, the resulting assembly is more interesting. The original: movl %esi,%eax andl $3,%eax cmpl $2,%eax jae .snd_con_lbl After the patch: testl $2,%esi jne .snd_con_lbl The following table contains a summary of the nofib results: Machine Athlon32* Athlon64* Pentium4 Pentium4-dual PentiumD --------------------------------------------------------------------------------------- Vendor AMD AMD Intel Intel Intel Word size 32 64 32** 32** 32** OS Linux Linux Linux Linux Linux # CPU's 1 2 1 2 2 Mhz 950 2600 2800 2800 3000 L1 code/uops (Kb) 64 64 12 12 12 L1 data (Kb) 64 64 8 8 16 L2 (Kb) 256 1024 512 512 2048 -1 s.d. runtime (%) -1.4 -1.2 -2.4 -2.2 -5.1 +1 s.d. runtime (%) +1.1 +0.4 +1.5 +2.1 +1.3 Avg runtime (%) -0.2 -0.4 -0.4 -0.1 -1.9 Worst runtime (%) +2.5 +1.0 +3.1 +2.5 +5.0 Worst program cacheprof power simple wheel-sieve-1 integrate Best runtime (%) -5.1 -2.9 -5.0 -5.5 -8.1 Best program parstof hidden para life cryptarithm1 -1 s.d. mutator (%) -1.5 -1.6 -3.0 -3.0 -4.8 +1 s.d. mutator (%) +1.1 +0.8 +1.5 +2.2 +1.8 Avg mutator (%) -0.2 -0.4 -0.8 -0.5 -1.6 Avg bin size (%) -0.1 -0.2 -0.1 -0.1 -0.1 Avg mod size (%) -0.3 -0.5 -0.3 -0.3 -0.3 Avg comp time (%) -0.6 -0.7 -1.1 -0.6 -0.2 --------------------------------------------------------------------------------------- Cachegrind results -1 s.d. runtime (%) -2.0 -2.4 -3.2 -3.8 -3.3 +1 s.d. runtime (%) +0.5 +0.8 +1.2 +1.7 +0.6 Avg runtime (%) -0.7 -0.8 -1.0 -1.1 -1.3 -1 s.d. instr. (%) -4.2 -4.1 -4.3 -4.4 -4.4 +1 s.d. instr. (%) -0.6 -0.5 -0.6 -0.7 -0.7 Avg instr (%) -2.4 -2.3 -2.5 -2.5 -2.5 -1 s.d. cache misses (%) -0.6 -1.8 -0.4 -2.0 -2.8 +1 s.d. cache misses (%) +0.7 +2.2*** +0.7 +0.9 +1.1 Avg cache misses (%) +0.0 +0.2 +0.1 -0.6 -0.9 Avg comp time (%) -0.6 +0.3 -0.7 -0.4 -0.1 * On all Athlon results, but not on those of the Pentiums, nofib-analyse gave lots of "spurious result" warnings. On the Athlon32, nofib even failed with "output does not match" errors, which I could not verify when running diff on the output manually. I "fixed" the first problem by ignoring it and the second one by changing runstdtest to pretend the actual output always matches the expected output. ** CPU may actually be 64bits, but all software (including kernel) is 32bits *** cacheprof here has a whopping 21.0% more cache misses. The second biggest increase is 1.0% The attached patch is against 6.8.2, but currently applies without problem against the HEAD. The full nofib results can be found at http://www.students.cs.uu.nl/~rturk/fast2case-nofib-results/ The normal runs were done with NoFibRuns = 5, and for the cachegrind runs it was set to 2. On most machines I ran nofib multiple times and, both for normal and for "fast2case", took the fastest run. Thanks to Jeroen Fokker for giving the seminar that made me think of this in the first place, to Mark Stobbe and Eelco Lempsink for being great guys to work with during the seminar, and to Alexey Rodriguez for helping me keep my sanity in the midst of weird cache- and pipeline effects. And finally to the University Utrecht and Chris Regenboog for enabling me to run nofib on more computers than only my own poor old 950Mhz machine. Groeten, Remi [1] Technically, it will work for 4 constructor datatypes on 64 bit architectures too, but who cares. -------------- next part -------------- --- ghc-6.8.2-normal/compiler/codeGen/CgUtils.hs 2007-12-10 19:11:32.000000000 +0100 +++ ghc-6.8.2-fast2case/compiler/codeGen/CgUtils.hs 2008-02-22 14:06:14.000000000 +0100 @@ -696,6 +696,15 @@ -- the branches is the tag 0, because comparing '== 0' is likely to be -- more efficient than other kinds of comparison. +-- optimize 2 constructor datatype case +mk_switch (CmmMachOp (MO_And rep) [arg, CmmLit (CmmInt tAG_MASK' rep')]) [(1, stmts1), (2, stmts2)] Nothing _ _ via_C + | tAG_MASK' == fromIntegral tAG_MASK = do + id <- forkCgStmts stmts2 + return $ CmmComment (mkFastString "Fast2Case") `consCgStmt` (CmmCondBranch cond id `consCgStmt` stmts1) + where + tag_expr' = CmmMachOp (MO_And rep) [arg, CmmLit (CmmInt 2 rep')] + cond = cmmNeWord tag_expr' (CmmLit (mkIntCLit 0)) + -- DENSE TAG RANGE: use a switch statment. -- -- We also use a switch uncoditionally when compiling via C, because From simonmarhaskell at gmail.com Mon Mar 3 07:30:12 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Mar 3 07:28:22 2008 Subject: GHC code generation micro-optimisation patch In-Reply-To: <20080303091804.GA3855@krikkit.lan> References: <20080303091804.GA3855@krikkit.lan> Message-ID: <47CBEF54.8000202@gmail.com> Remi Turk wrote: > during the past semester I followed a seminar on the "Efficient > implementation of functional languages" by Jeroen Fokker at the > University Utrecht. During that course we worked on a feedback > directed GHC optimisation, but that got me interested in another > possible GHC backend micro-optimisation: > > The short story is this: > > An 8 line patch to GHC, tested with ghc 6.8.2 on nofib, ignoring all > results with a < 0.5s runtime, yields an average runtime and > compile time improvement of about 0.6%. > The worst nofib slowdown is 5%, and the best speedup 8% > Whether this is acceptable/enough for inclusion, is of course not > up to me. Hi Remi - thanks very much for the patch. It certainly looks worthwhile. I have some pending changes myself to mk_switch - it turns out that we're doing quite a bad job of compiling 3-way comparisons too (look at the code for fib sometime), so I'll try to incorporate your change into my refactorings. Cheers, Simon From dons at galois.com Mon Mar 3 17:21:27 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 3 17:19:10 2008 Subject: static constants -- ideas? In-Reply-To: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> References: <42784f260802232356j35874987uc33a11ff990955a3@mail.gmail.com> Message-ID: <20080303222127.GA21789@scytale.galois.com> jason.dusek: > I have an awkward programming problem -- I need to take a > dictionary, parse it, build a bunch of intermediate lists and > then make maps and tries out of the list. A "programming > problem" because it's taken me a fair amount of effort to pull > together the parser and list generator -- and "awkward" > because a 69000 item list, [(String, [(String, String)])], > does not compile under GHC (stack overflow). (It's not likely > to compile under anything else, either!) Here's an example of the approach Bryan outlined, which does seem to work for files as large as gcc can handle: * generate your big Haskell Map * serialise it with Data.Binary, and Codec.Compression.GZip to a file * compile the data into a C const array, and link that into Haskell * decode it on startup, ressurecting the Haskell data. The C source looks like: const uint8_t beowulf[] = { 31, 139, 8, 0, 0, 0, 0, 0, 0, 3, 124, 189, 75, 150, 46, 54, 93, 193, 96, 144, 241, 168, 172, 238, 214, 0, ... http://code.haskell.org/~dons/code/compiled-constants/cbits/constants.c which is the gzip, Data.Binary encoded version of a Map ByteString Int. Then the Haskell code need only access this array as a Ptr Word8, wrap that as a Bytestring, then run Data.Binary over the result to rebuild the Map. As you can see here: http://code.haskell.org/~dons/code/compiled-constants/Constants.hs I've put a couple of examples of how to access C-side serialised Haskell values in a package here: http://code.haskell.org/~dons/code/compiled-constants/ Cheers, Don From gwright at comcast.net Tue Mar 4 09:13:54 2008 From: gwright at comcast.net (Gregory Wright) Date: Tue Mar 4 09:11:25 2008 Subject: ANN: ghc 6.8.2 from MacPorts Message-ID: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> After what many would consider an unconscionable delay, I am happy to announce that ghc 6.8.2 is available from MacPorts. The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ intel. Users with Leopard/ppc are out of luck until for now, for reason discussed earlier on this list. In partial recompense for their patience, users will get a ghc with more patches than any previous MacPorts ghc. A few notes: The file locking bugs #1992 and #2134 are fixed. Bug #1992 was a simple lock logic error and should be killed dead. Bug #2134 was the result of a lazy readFile holding a lock for an unpredictable time. There may be more cases like this one, and I would appreciate a note from anyone who come across a lock error during building. Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug which under unusual circumstances would repeatably (and mysteriously) crash the build. This was first noticed running the building in an eshell under Aquamacs. Archives were built without tables of contents because ranlib wasn't being run or wasn't running to completion. Builds in the usual Terminal.app didn't trip over this bug. OpenGL support is built by default. It can be turned off using the no_opengl variant. OpenAL support is disabled. Apple's OpenAL framework lacks ALUT support (needed for the ghc binding) but has name clashes with the freealut library from the OpenAL.org website. Fixing this is probably straightforward. If someone is interested, I can give them some pointers on getting started. MacPort's ghc ought to always link with the correct libgmp (the one provided by the gmp port). The latest versions of alex, happy, haddock and hs-Edison are also available. Best Wishes, Greg From jgbailey at gmail.com Tue Mar 4 20:07:03 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Tue Mar 4 20:04:32 2008 Subject: Assembly decoding help? Message-ID: I'm trying to get a feel for the assembly output by GHC on my platform. Below is a module containing one function and the associated assembly. I've put in comments what I think is going on, but I'd appreciate it if anyone could give me some pointers. I'd really like to know three things: * Why does _Add_unsafeShiftR_info check if (%esi) is 3? * What's going on in _s86_info? * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is that a jump to the I# constructor and, if so, how did it's address get to that offset from %ebp? Thanks in advance for any assistance! Justin --- cut here ---- # Compiled with # # ghc -c Add.hs -fext-core -keep-s-files -fasm -O2 -ddump-to-file -ddump-stg -ddump-cmm # # Platform: Windows XP. # Processor Pentium 4. # GHC Version: 6.8.2. # # > {-# OPTIONS_GHC -fglasgow-exts -fbang-patterns #-} # > module Add (unsafeShiftR) # # > where # # > import Data.Bits # > import GHC.Base (uncheckedShiftRL#, Int(..), word2Int#, int2Word#) # # > I# a `unsafeShiftR` I# b = I# (word2Int# (int2Word# a `uncheckedShiftRL#` b)) # .data .align 4 .globl _Add_unsafeShiftR_closure _Add_unsafeShiftR_closure: .long _Add_unsafeShiftR_info # Specifies entry point for unsafeShiftR? .text .align 4,0x90 .long 33 .long 34 _s87_info: addl $8,%edi cmpl 92(%ebx),%edi # Stack check? ja .Lc8n movl 4(%ebp),%eax # Get value to be shifted movl 3(%esi),%ecx # Get shift amount shrl %cl,%eax # Shift value movl $_base_GHCziBase_Izh_con_info,-4(%edi) # Get ready to call I#? movl %eax,(%edi) # Constructor value leal -3(%edi),%esi # Address to what in I#? addl $8,%ebp # Make room on stack for next caller? jmp *(%ebp) # Go to constructor? Tail call? .Lc8n: movl $8,112(%ebx) jmp *-8(%ebx) # Error routine if stack overflows? .text .align 4,0x90 .long 1 .long 34 _s86_info: movl 4(%ebp),%eax # Testing what here? movl 3(%esi),%ecx movl %ecx,4(%ebp) movl %eax,%esi movl $_s87_info,(%ebp) testl $3,%esi jne _s87_info jmp *(%esi) .text .align 4,0x90 .long 131084 .long 0 .long 15 .globl _Add_unsafeShiftR_info _Add_unsafeShiftR_info: movl (%ebp),%esi movl $_s86_info,(%ebp) testl $3,%esi # Looking at StgRetInfoTable here? jne _s86_info # Enter body of unsafeShiftR? jmp *(%esi) .data .align 4 __module_registered: .long 0 .text .align 4,0x90 .globl ___stginit_Add_ ___stginit_Add_: cmpl $0,__module_registered jne .Lc8E .Lc8F: movl $1,__module_registered addl $-4,%ebp movl $___stginit_base_GHCziBase_,(%ebp) addl $-4,%ebp movl $___stginit_base_Prelude_,(%ebp) addl $-4,%ebp movl $___stginit_base_DataziBits_,(%ebp) .Lc8E: addl $4,%ebp jmp *-4(%ebp) .text .align 4,0x90 .globl ___stginit_Add ___stginit_Add: jmp ___stginit_Add_ .ident "GHC 6.8.2" From stefanor at cox.net Tue Mar 4 20:38:09 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Mar 4 20:35:40 2008 Subject: Assembly decoding help? In-Reply-To: References: Message-ID: <20080305013808.GA3878@localhost.localdomain> On Tue, Mar 04, 2008 at 05:07:03PM -0800, Justin Bailey wrote: > I'm trying to get a feel for the assembly output by GHC on my > platform. Below is a module containing one function and the associated > assembly. I've put in comments what I think is going on, but I'd > appreciate it if anyone could give me some pointers. I'd really like > to know three things: > > * Why does _Add_unsafeShiftR_info check if (%esi) is 3? > * What's going on in _s86_info? > * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is > that a jump to the I# constructor and, if so, how did it's address get > to that offset from %ebp? > > Thanks in advance for any assistance! It would be more helpful if you didn't try to go from Haskell to assembly in one step - it's a lot easier to understand each big step of the GHC pipeline individually. Haskell | \-> Core (ghc -ddump-simpl Foo.hs > Foo.core; or -fext-core if you want something ugly but parsable; an unrestricted but simple expression-functional language) | \-> STG (ghc -ddump-stg ...) (Much more regular than Core; more like functional C) | \-> C-- (ghc -ddump-cmm) (just what it says: Simplified C for compiler writers. The universal assembly language for the 21st century) | \-> assembly 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/20080304/3bbb295b/attachment.bin From catamorphism at gmail.com Tue Mar 4 22:21:37 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue Mar 4 22:19:06 2008 Subject: Assembly decoding help? In-Reply-To: References: Message-ID: <4683d9370803041921g574b778fvdd38f3951791aaa3@mail.gmail.com> On 3/4/08, Justin Bailey wrote: > I'm trying to get a feel for the assembly output by GHC on my > platform. Below is a module containing one function and the associated > assembly. I've put in comments what I think is going on, but I'd > appreciate it if anyone could give me some pointers. I'd really like > to know three things: > > * Why does _Add_unsafeShiftR_info check if (%esi) is 3? > * What's going on in _s86_info? > * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is > that a jump to the I# constructor and, if so, how did it's address get > to that offset from %ebp? > I agree with Stefan's advice: read the STG code, especially to answer the second two questions (-ddump-stg), and read the STG paper (if you haven't already): Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine, SL Peyton Jones, Journal of Functional Programming 2(2), Apr 1992, pp127-202. Then if anything's still not clear, ask on the mailing list. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The future is not google-able." -- William Gibson From bertram.felgenhauer at googlemail.com Tue Mar 4 22:53:21 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Tue Mar 4 22:50:55 2008 Subject: Assembly decoding help? In-Reply-To: References: Message-ID: <20080305035321.GA11849@zombie.inf.tu-dresden.de> Justin Bailey wrote: > I'm trying to get a feel for the assembly output by GHC on my > platform. Below is a module containing one function and the associated > assembly. I've put in comments what I think is going on, but I'd > appreciate it if anyone could give me some pointers. I'd really like > to know three things: > > * Why does _Add_unsafeShiftR_info check if (%esi) is 3? > * What's going on in _s86_info? > * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is > that a jump to the I# constructor and, if so, how did it's address get > to that offset from %ebp? One point that seems to irritate you is that ghc does pointer tagging; the lower 2 bits of a pointer are zero if it points to an unevaluated closure (a thunk); otherwise they encode a constructor. (I'm not sure what happens in the case when there are more than 3 constructors. But in your case there's only one, I#, with tag 01.) Register usage (as far as I can see): %ebp - STG stack pointer %edi - Heap pointer (in particular cmpl 92(%ebx),%edi is a heap check and will trigger a GC) %esi - at start of *_info, points to most recently evaluated value. %ebx - points to some RTS global variables. Rough outline of the code: _Add_unsafeShiftR_info: find first argument, and evaluate it if it's not yet fully evaluated. continue at _s86_info. (note that a pointer to _s86_info, a continuation, is stored on the control stack) _s86_info: store the first argument value on the stack, load the second one, and evaluate it if necessary. continue at _s87_info. _s87_info: load both arguments, and compute result. The result is fully evaluated, so a tagged pointer is returned. (the -3 is -4, plus 1 for the tag) clean up the stack (the space for the two arguments is no longer needed) and jump to the continuation stored by the caller. HTH, Bertram From jinwoo68 at gmail.com Wed Mar 5 04:21:22 2008 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Wed Mar 5 04:18:50 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> Message-ID: <7070515b0803050121w5d81eab1u8bb706dc2f0980eb@mail.gmail.com> Thank you! But "ghc" has disappeared from MacPorts SW list. Only "ghc-devel" can be seen. Please look into it. jinwoo On Tue, Mar 4, 2008 at 11:13 PM, Gregory Wright wrote: > > After what many would consider an unconscionable delay, I am happy to > announce > that ghc 6.8.2 is available from MacPorts. > > The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ > intel. Users with > Leopard/ppc are out of luck until for now, for reason discussed > earlier on this list. > > In partial recompense for their patience, users will get a ghc with > more patches > than any previous MacPorts ghc. > > A few notes: > > The file locking bugs #1992 and #2134 are fixed. Bug #1992 was a > simple > lock logic error and should be killed dead. Bug #2134 was the > result > of a lazy readFile > holding a lock for an unpredictable time. There may be more cases > like this one, > and I would appreciate a note from anyone who come across a lock > error during building. > > Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug > which under > unusual circumstances would repeatably (and mysteriously) crash the > build. > This was first noticed running the building in an eshell under > Aquamacs. Archives > were built without tables of contents because ranlib wasn't being > run > or wasn't > running to completion. Builds in the usual Terminal.app didn't > trip > over this bug. > > OpenGL support is built by default. It can be turned off using the > no_opengl variant. > > OpenAL support is disabled. Apple's OpenAL framework lacks ALUT > support (needed > for the ghc binding) but has name clashes with the freealut library > from the OpenAL.org > website. Fixing this is probably straightforward. If someone is > interested, I can give > them some pointers on getting started. > > MacPort's ghc ought to always link with the correct libgmp (the one > provided by the gmp port). > > > The latest versions of alex, happy, haddock and hs-Edison are also > available. > > > Best Wishes, > Greg > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Jinwoo Lee Always remember that you are unique. Just like everyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080305/f4dc2c19/attachment.htm From gwright at comcast.net Wed Mar 5 09:51:35 2008 From: gwright at comcast.net (Gregory Wright) Date: Wed Mar 5 09:49:13 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <7070515b0803050121w5d81eab1u8bb706dc2f0980eb@mail.gmail.com> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <7070515b0803050121w5d81eab1u8bb706dc2f0980eb@mail.gmail.com> Message-ID: <43D146B3-2444-436E-83D8-BF0E798F06E0@comcast.net> On Mar 5, 2008, at 4:21 AM, Jinwoo Lee wrote: > Thank you! > But "ghc" has disappeared from MacPorts SW list. > Only "ghc-devel" can be seen. > Please look into it. > ghc vanished from the distribution server for a few hours yesterday because of a unanticipated corner case in the indexing script. (The server runs Leopard/ppc, and incorrectly rejected ports that correctly reported that they do not run on Leopard/ppc.) A workaround was implemented and it is now available. MacPorts helps debug ghc and ghc helps debug MacPorts! -Greg From duncan.coutts at worc.ox.ac.uk Wed Mar 5 18:16:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 5 18:13:41 2008 Subject: scope of header files Message-ID: <1204758974.11558.256.camel@localhost> I was under the impression that with ghc, ffi import declarations like this do not escape the module: foreign import ccall unsafe "foo.h foo" foo :: IO () However it seems that this one does: foreign import ccall unsafe "curses.h & stdscr" stdscrp :: Ptr WINDOWptr from: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mage-1.0 perhapsPbecause it's a pointer import it gets treated differently? Is this correct and expected behaviour? It's hard to tell what header files need to be used globally and inherited by client packages and which can safely be used privately. Duncan From josef.svenningsson at gmail.com Wed Mar 5 18:39:30 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Wed Mar 5 18:36:59 2008 Subject: STM and fairness In-Reply-To: References: <8dde104f0802290552t74713c41j3ea8e42ffbff6dcb@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C31F97234321@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <8dde104f0803051539m3093b542u42b446cae0b1e765@mail.gmail.com> Tim, Simon, Thanks for your detailed descriptions. Much of my understanding was confirmed. I'll see if I can send you a patch with my suggested fix as soon as my teaching is over. Thanks, Josef On Mon, Mar 3, 2008 at 2:03 PM, Tim Harris (RESEARCH) wrote: > Hi, > > At the moment we don't make any particular effort to make threads runnable in some specific order when they are unblocked. The current implementation is simply what was easiest to write. > > If I remember rightly threads blocked on TVars will initially be "half-woken", putting them on the same run-queue as their waker and leaving the STM data structures intact. When scheduled they will check whether or not the TVars' contents differ from the values that caused them to block: if the values are unchanged then a thread can block again without needing to build up wait queue structures. In Simon's example of 100 threads blocked on a single-cell TVar buffer, this would mean 99 of them are validated and block again without needing to re-execute the rest of the transaction containing the TVar access. This will probably happen within a single OS thread so these are lightweight thread switches within the GHC run time rather than 99 OS thread switches. > > At some point it might be nice to look at using run-time feedback about how individual TVars are used. I suspect that, looking at it dynamically, there are a few simple policies that would apply to most TVars (wake-all / wake-one) with the caveat that anything other than "wake-all" must eventually fall back to "wake-all" to preserve the intended semantics for "retry". > > NB -- when thinking about a shared buffer built over TVars there's also the possibility that a non-blocked thread will consume the resource ahead of a blocked thread that has been woken. As with programming with locks/condition-variables, avoiding this case would need an explicit queue of consumers to be maintained by the application (and symmetrically for producers). > > In any case, running threads in something approximating the same order they blocked sounds sensible to me. The lists of threads blocked on a TVar are doubly-linked (right?) so wouldn't need to be explicitly reversed. > > Tim > > > > > > > > > -----Original Message----- > From: Simon Peyton-Jones > Sent: 29 February 2008 20:06 > To: Josef Svenningsson; glasgow-haskell-users@haskell.org > Cc: Tim Harris (RESEARCH) > Subject: RE: STM and fairness > > | I'd like to know a bit about the STM implementation in GHC, > | specifically about how it tries to achieve fairness. I've been reading > | "Composable Memory Transactions" but it does not contain that much > | details on this specific matter. What I want to know boils down to > | this: what order are processes run which have been woken up from a > | call to retry? > > Tim is the one who implemented this stuff, so I'm ccing him. > > If threads queue up on a single MVar, it's obvious how to achieve fairness of a sort. Furthremore, if 100 threads are blocked on one MVar, the scheduler can wake up exactly one when the MVar is filled. With STM it's much less obvious. > > First, a thread may block on a whole bunch of TVars; if any of them are changed, the thread should re-run. So there is no single list of threads to reverse or not reverse. > > Second, if 100 threads are blocked on a TVar, t, waking up just one of them may not suffice -- it may read some more TVars and then retry again, re-blocking itself on t (plus some more). The only simple thing to do is to wake all of them up. In common situations (e.g. a buffer), we may wake up all 100 threads, only for 99 of them to lose the race and block again. > > This arises from the fact that transactions do a wonderful thing, by letting you perform multiple operations atomically -- but that makes it harder to optimize. > > > All that said, you may well be right that one could do a better job of scheduling. For example, even though there may be lots of threads blocked on a TVar, and all must be made runnable, they could perhaps be run in the same order that they blocked, so the longest-blocked got to run first. I don't think we try to do that, but Tim would know. > > By all means suggest a patch! > > Simon > From ross at soi.city.ac.uk Wed Mar 5 18:46:42 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Mar 5 18:44:09 2008 Subject: scope of header files In-Reply-To: <1204758974.11558.256.camel@localhost> References: <1204758974.11558.256.camel@localhost> Message-ID: <20080305234641.GA29735@soi.city.ac.uk> On Wed, Mar 05, 2008 at 11:16:14PM +0000, Duncan Coutts wrote: > I was under the impression that with ghc, ffi import declarations like > this do not escape the module: > > foreign import ccall unsafe "foo.h foo" foo :: IO () GHC can inline the stub across module (and thus package) boundaries, so the #include can escape. > It's hard to tell what header files need to be used globally and > inherited by client packages and which can safely be used privately. No, it's easy: they're all potentially inherited. From duncan.coutts at worc.ox.ac.uk Wed Mar 5 19:23:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 5 19:21:11 2008 Subject: scope of header files In-Reply-To: <20080305234641.GA29735@soi.city.ac.uk> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> Message-ID: <1204763015.11558.305.camel@localhost> On Wed, 2008-03-05 at 23:46 +0000, Ross Paterson wrote: > On Wed, Mar 05, 2008 at 11:16:14PM +0000, Duncan Coutts wrote: > > I was under the impression that with ghc, ffi import declarations like > > this do not escape the module: > > > > foreign import ccall unsafe "foo.h foo" foo :: IO () > > GHC can inline the stub across module (and thus package) boundaries, > so the #include can escape. I've been informed before that: foreign import ccall unsafe "foo" foo :: IO () can escape and needs -#include on the command line and for all client code. However for ghc: foreign import ccall unsafe "foo.h foo" foo :: IO () does not escape because ghc does not track which .h file should be #included later. It's not that it couldn't escape according to the FFI spec but that ghc currently does not do cross-module inlining for such declarations. That's what I've been told and it's the behaviour I've observed, except for the case I noted. Quite a few packages rely on ghc's behaviour on this, or just rely on the fact that in practise things do not get inlined that aggressively. If we started looking carefully I think we'd find most hackage packages that use FFI get this wrong. > > It's hard to tell what header files need to be used globally and > > inherited by client packages and which can safely be used privately. > > No, it's easy: they're all potentially inherited. Which is really annoying :-) I'd like greater control over it, in particular a way to limit headers to package scope so that dependent code does not need the headers. Duncan From ross at soi.city.ac.uk Wed Mar 5 19:35:52 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Mar 5 19:33:18 2008 Subject: scope of header files In-Reply-To: <1204763015.11558.305.camel@localhost> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> Message-ID: <20080306003551.GB29735@soi.city.ac.uk> On Thu, Mar 06, 2008 at 12:23:35AM +0000, Duncan Coutts wrote: > However for ghc: > > foreign import ccall unsafe "foo.h foo" foo :: IO () > > does not escape because ghc does not track which .h file should be > #included later. It's not that it couldn't escape according to the FFI > spec but that ghc currently does not do cross-module inlining for such > declarations. That's what I've been told and it's the behaviour I've > observed, except for the case I noted. Ah yes, I remember that now. From john at repetae.net Wed Mar 5 20:37:05 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 5 20:34:31 2008 Subject: scope of header files In-Reply-To: <1204763015.11558.305.camel@localhost> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> Message-ID: <20080306013705.GA4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 12:23:35AM +0000, Duncan Coutts wrote: > Which is really annoying :-) I'd like greater control over it, in > particular a way to limit headers to package scope so that dependent > code does not need the headers. Ideally there would be no need for headers at all. Everything needed is inherently in the foreign declaration. If anything, the headers should just be used as a sanity check, not actually to affect the generated code. It would be nice if ghc just stopped relying on them and ignored them altogether. John -- John Meacham - ?repetae.net?john? From duncan.coutts at worc.ox.ac.uk Wed Mar 5 21:18:08 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 5 21:15:36 2008 Subject: scope of header files In-Reply-To: <20080306013705.GA4914@sliver.repetae.net> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> Message-ID: <1204769888.11558.314.camel@localhost> On Wed, 2008-03-05 at 17:37 -0800, John Meacham wrote: > On Thu, Mar 06, 2008 at 12:23:35AM +0000, Duncan Coutts wrote: > > Which is really annoying :-) I'd like greater control over it, in > > particular a way to limit headers to package scope so that dependent > > code does not need the headers. > > Ideally there would be no need for headers at all. Everything needed is > inherently in the foreign declaration. If anything, the headers should > just be used as a sanity check, not actually to affect the generated > code. It would be nice if ghc just stopped relying on them and ignored > them altogether. We're going to have to figure out what to do with crazy header files that use lots of macros. For example the mage-1.1.0 package does not compile without -fvia-C. This is because of the curses.h interface. For example: foreign import ccall unsafe "curses.h & ACS_UARROW" acs_uarrow :: Ptr ChType And what is "ACS_UARROW"? We might hope it's a pointer with a corresponding linker symbol. Sadly not: #define ACS_UARROW NCURSES_ACS('-') /* arrow pointing up */ where: #define NCURSES_ACS(c) (acs_map[NCURSES_CAST(unsigned char,c)]) extern NCURSES_EXPORT_VAR(chtype) acs_map[]; Yay, it's an index into an array. So that obviously does not work. If we compile without going via C we get a linker error because there is no ACS_UARROW linker symbol. If we compile via C then through a bit of luck it seems to compile. There are rather too many of these C libs that define their public interfaces as macros. I had to adjust the zlib binding the other day to allow it to compile without -fvia-C. It now implements a couple macros in the Haskell code. I hope zlib don't change their macro in the next version. Duncan From igloo at earth.li Wed Mar 5 21:39:35 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 5 21:37:02 2008 Subject: scope of header files In-Reply-To: <1204769888.11558.314.camel@localhost> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> Message-ID: <20080306023935.GA6082@matrix.chaos.earth.li> On Thu, Mar 06, 2008 at 02:18:08AM +0000, Duncan Coutts wrote: > > foreign import ccall unsafe "curses.h & ACS_UARROW" > acs_uarrow :: Ptr ChType > > #define ACS_UARROW NCURSES_ACS('-') /* arrow pointing up */ You ought to use a C wrapper around these sorts of things. If you're lucky, the API docs will tell you which values and functions might be macros, e.g. http://www.opengroup.org/onlinepubs/007908799/xcurses/curses.h.html is clear about what is (or might be) what. I can't remember if it's been discussed before, but I think it might be a good idea for the FFI to be able to create these C stubs itself, if you give a certain keyword - or perhaps even by default as it's the safe thing to do, at the expense of performance. Thanks Ian From john at repetae.net Wed Mar 5 21:46:50 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 5 21:44:15 2008 Subject: scope of header files In-Reply-To: <1204769888.11558.314.camel@localhost> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> Message-ID: <20080306024650.GB4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 02:18:08AM +0000, Duncan Coutts wrote: > There are rather too many of these C libs that define their public > interfaces as macros. I had to adjust the zlib binding the other day to > allow it to compile without -fvia-C. It now implements a couple macros > in the Haskell code. I hope zlib don't change their macro in the next > version. Yeah, I ran into the exact same issue with my curses binding. the solution was to use hsc2hs to create wrappers when needed. something like this: foreign import ccall "get_COLOR_PAIRS" colorPairsPtr :: Ptr CInt #def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;} hsc2hs is needed anyway for portable C bindings so it isn't too onerous of a requirement. John -- John Meacham - ?repetae.net?john? From john at repetae.net Wed Mar 5 21:57:14 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 5 21:54:40 2008 Subject: scope of header files In-Reply-To: <20080306023935.GA6082@matrix.chaos.earth.li> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> <20080306023935.GA6082@matrix.chaos.earth.li> Message-ID: <20080306025714.GC4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 02:39:35AM +0000, Ian Lynagh wrote: > I can't remember if it's been discussed before, but I think it might be > a good idea for the FFI to be able to create these C stubs itself, if > you give a certain keyword - or perhaps even by default as it's the > safe thing to do, at the expense of performance. The FFI defines an ABI spec, not an API one. As in, a C compiler is never inherently involved, (hence the ability to have Haskell compilers with a pure assembly back end). Tools like hsc2hs are there to bridge the gap to a particular language when needed. Some libraries guarantee an ABI, others just an API. Hopefully it is documented. :). In general, in order to support dynamic linking, the ABI must remain stable so tools like 'hsc2hs' often aren't needed when interfacing to C code. In any case, it is not the FFI's job, though of course, specific Haskell compilers are free to provide extensions. But I'd rather see GHC get further away from C idiosyncrasies instead of closer. John -- John Meacham - ?repetae.net?john? From wmacgyver at gmail.com Thu Mar 6 00:57:41 2008 From: wmacgyver at gmail.com (Wilson MacGyver) Date: Thu Mar 6 00:55:29 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> Message-ID: <47CF87D5.5000907@gmail.com> Gregory Wright wrote: > > After what many would consider an unconscionable delay, I am happy to > announce > that ghc 6.8.2 is available from MacPorts. thank you for all the hard work, port installing now as we speak. Good job. Mac From john at repetae.net Thu Mar 6 02:25:47 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 6 02:23:14 2008 Subject: monomorphic or not? Message-ID: <20080306072547.GD4914@sliver.repetae.net> http://www.cse.unsw.edu.au/~dons/code/nobench/real/compress/compress.hs if you notice this program has the line > compress = map toEnum . codes_to_ascii . encode It seems to me this should run afoul of the monomorphism restriction due to the unknown ambiguous type in Enum, but ghc 6.8.2 happily accepts it. Jhc thinks it is illegal according to my reading of the specification. Any ideas about what is going on here? John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Thu Mar 6 03:56:15 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 6 03:53:48 2008 Subject: monomorphic or not? In-Reply-To: <20080306072547.GD4914@sliver.repetae.net> References: <20080306072547.GD4914@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C323E5559769@EA-EXMSG-C334.europe.corp.microsoft.com> No, it's fine. compress is indeed monomorphic, but since it's called at exactly one type, namely Char, so it gets the monomorphic type [Char] -> [Char]. That is what the Haskell Report says. (Or tries to.) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | John Meacham | Sent: 06 March 2008 07:26 | To: glasgow-haskell-users@haskell.org | Subject: monomorphic or not? | | http://www.cse.unsw.edu.au/~dons/code/nobench/real/compress/compress.hs | | if you notice this program has the line | | > compress = map toEnum . codes_to_ascii . encode | | It seems to me this should run afoul of the monomorphism restriction due | to the unknown ambiguous type in Enum, but ghc 6.8.2 happily accepts it. | Jhc thinks it is illegal according to my reading of the specification. | Any ideas about what is going on here? | | John | | -- | John Meacham - ?repetae.net?john? | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From duncan.coutts at worc.ox.ac.uk Thu Mar 6 05:43:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 6 05:42:09 2008 Subject: scope of header files In-Reply-To: <20080306024650.GB4914@sliver.repetae.net> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> <20080306024650.GB4914@sliver.repetae.net> Message-ID: <1204800222.11558.319.camel@localhost> On Wed, 2008-03-05 at 18:46 -0800, John Meacham wrote: > On Thu, Mar 06, 2008 at 02:18:08AM +0000, Duncan Coutts wrote: > > There are rather too many of these C libs that define their public > > interfaces as macros. I had to adjust the zlib binding the other day to > > allow it to compile without -fvia-C. It now implements a couple macros > > in the Haskell code. I hope zlib don't change their macro in the next > > version. > > Yeah, I ran into the exact same issue with my curses binding. the > solution was to use hsc2hs to create wrappers when needed. > > something like this: > > foreign import ccall "get_COLOR_PAIRS" colorPairsPtr :: Ptr CInt > #def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;} The problem with that is that it doesn't follow the rules about scope of header files either. Technically the little .h file that hsc2hs generates for you needs to be installed and used by every client package. > hsc2hs is needed anyway for portable C bindings so it isn't too onerous > of a requirement. Or c2hs! :-) Duncan From john at repetae.net Thu Mar 6 06:11:20 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 6 06:08:45 2008 Subject: scope of header files In-Reply-To: <1204800222.11558.319.camel@localhost> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> <20080306024650.GB4914@sliver.repetae.net> <1204800222.11558.319.camel@localhost> Message-ID: <20080306111120.GE4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 10:43:41AM +0000, Duncan Coutts wrote: > > something like this: > > > > foreign import ccall "get_COLOR_PAIRS" colorPairsPtr :: Ptr CInt > > #def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;} > > The problem with that is that it doesn't follow the rules about scope of > header files either. Technically the little .h file that hsc2hs > generates for you needs to be installed and used by every client > package. no, because your stub functions have a well defined ABI (that was the point of the stub functions after all), so you wouldn't need to keep the header around in general assuming the compiler supported header-less compilation (which ghc doesn't yet AFAIK). I always thought c2hs should actually generate hsc files. That would allow people to compile programs that use c2hs without having to install c2hs on their build machines. hsc2hs is the minimal tool needed to write portable C interfaces so needs to be installed on target systems anyway. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Thu Mar 6 06:12:49 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 6 06:10:42 2008 Subject: scope of header files In-Reply-To: <1204763015.11558.305.camel@localhost> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C323E55598D4@EA-EXMSG-C334.europe.corp.microsoft.com> If, following this thread, you conclude that GHC should do something different than what it does, can you submit a Trac ticket? With a small example? Thanks S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Duncan Coutts | Sent: 06 March 2008 00:24 | To: Ross Paterson | Cc: glasgow-haskell-users@haskell.org | Subject: Re: scope of header files | | | On Wed, 2008-03-05 at 23:46 +0000, Ross Paterson wrote: | > On Wed, Mar 05, 2008 at 11:16:14PM +0000, Duncan Coutts wrote: | > > I was under the impression that with ghc, ffi import declarations like | > > this do not escape the module: | > > | > > foreign import ccall unsafe "foo.h foo" foo :: IO () | > | > GHC can inline the stub across module (and thus package) boundaries, | > so the #include can escape. | | I've been informed before that: | | foreign import ccall unsafe "foo" foo :: IO () | | can escape and needs -#include on the command line and for all client | code. However for ghc: | | foreign import ccall unsafe "foo.h foo" foo :: IO () | | does not escape because ghc does not track which .h file should be | #included later. It's not that it couldn't escape according to the FFI | spec but that ghc currently does not do cross-module inlining for such | declarations. That's what I've been told and it's the behaviour I've | observed, except for the case I noted. | | Quite a few packages rely on ghc's behaviour on this, or just rely on | the fact that in practise things do not get inlined that aggressively. | If we started looking carefully I think we'd find most hackage packages | that use FFI get this wrong. | | > > It's hard to tell what header files need to be used globally and | > > inherited by client packages and which can safely be used privately. | > | > No, it's easy: they're all potentially inherited. | | Which is really annoying :-) I'd like greater control over it, in | particular a way to limit headers to package scope so that dependent | code does not need the headers. | | Duncan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From duncan.coutts at worc.ox.ac.uk Thu Mar 6 06:27:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 6 06:28:02 2008 Subject: scope of header files In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C323E55598D4@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C323E55598D4@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1204802831.11558.336.camel@localhost> On Thu, 2008-03-06 at 11:12 +0000, Simon Peyton-Jones wrote: > If, following this thread, you conclude that GHC should do something > different than what it does, can you submit a Trac ticket? With a > small example? It's probably not worth quibbling about the issue I raised about "foo.h &foo" imports escaping a module when the whole behaviour of "foo.h foo" declarations not escaping is not specified. I'll file a feature request for more explicit control over scope of header files instead. Duncan From john at repetae.net Thu Mar 6 06:37:45 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 6 06:35:09 2008 Subject: monomorphic or not? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C323E5559769@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080306072547.GD4914@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C323E5559769@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080306113745.GF4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 08:56:15AM +0000, Simon Peyton-Jones wrote: > No, it's fine. compress is indeed monomorphic, but since it's called > at exactly one type, namely Char, so it gets the monomorphic type > [Char] -> [Char]. That is what the Haskell Report says. (Or tries > to.) But when I modify the module header to be: > module Main(main,compress) where It still doesn't complain, it can't know that all other uses of 'compress' in other modules will also be at a Char type. It also seems to me that the Dependency Analysis (4.5.1 in the report) would cause 'compress' to be typed and generalized before 'main' was even processed... Hmm.. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Thu Mar 6 06:43:08 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 6 06:40:52 2008 Subject: monomorphic or not? In-Reply-To: <20080306113745.GF4914@sliver.repetae.net> References: <20080306072547.GD4914@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C323E5559769@EA-EXMSG-C334.europe.corp.microsoft.com> <20080306113745.GF4914@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C323E5559922@EA-EXMSG-C334.europe.corp.microsoft.com> | On Thu, Mar 06, 2008 at 08:56:15AM +0000, Simon Peyton-Jones wrote: | > No, it's fine. compress is indeed monomorphic, but since it's called | > at exactly one type, namely Char, so it gets the monomorphic type | > [Char] -> [Char]. That is what the Haskell Report says. (Or tries | > to.) | | But when I modify the module header to be: | | > module Main(main,compress) where | | It still doesn't complain, it can't know that all other uses of | 'compress' in other modules will also be at a Char type. See 4.5.5 in the Report http://haskell.org/onlinereport/decls.html. Rule 1 says that 'compress' is not generalised. So it gets the type [t] -> [t] where 'a' is an as-yet-un-determined type; in implementation terms, a unification variable. Rule 2 says "Any monomorphic type variables that remain when type inference for an entire module is complete, are considered ambiguous, and are resolved to particular types using the defaulting rules". But in this case no monomoprhic variables remain, because by then the type of compress has been refined to [Char] -> [Char] Well, that's the way GHC interprets the report anyway! Simon From john at repetae.net Thu Mar 6 07:03:21 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 6 07:00:46 2008 Subject: monomorphic or not? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C323E5559922@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080306072547.GD4914@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C323E5559769@EA-EXMSG-C334.europe.corp.microsoft.com> <20080306113745.GF4914@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C323E5559922@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080306120321.GG4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 11:43:08AM +0000, Simon Peyton-Jones wrote: > See 4.5.5 in the Report http://haskell.org/onlinereport/decls.html. > > Rule 1 says that 'compress' is not generalised. So it gets the type > [t] -> [t] > where 'a' is an as-yet-un-determined type; in implementation terms, a unification variable. > > Rule 2 says "Any monomorphic type variables that remain when type inference for an entire module is complete, are considered ambiguous, and are resolved to particular types using the defaulting rules". But in this case no monomoprhic variables remain, because by then the type of compress has been refined to [Char] -> [Char] Ah! it all makes sense now. excellent. It has been a persistent annoyance that jhc gets dinged by the monomorphism restriction more than ghc, but now I see why. thanks! John -- John Meacham - ?repetae.net?john? From duncan.coutts at worc.ox.ac.uk Thu Mar 6 07:41:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 6 07:39:41 2008 Subject: scope of header files In-Reply-To: <20080306111120.GE4914@sliver.repetae.net> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> <20080306024650.GB4914@sliver.repetae.net> <1204800222.11558.319.camel@localhost> <20080306111120.GE4914@sliver.repetae.net> Message-ID: <1204807316.11558.355.camel@localhost> On Thu, 2008-03-06 at 03:11 -0800, John Meacham wrote: > On Thu, Mar 06, 2008 at 10:43:41AM +0000, Duncan Coutts wrote: > > > something like this: > > > > > > foreign import ccall "get_COLOR_PAIRS" colorPairsPtr :: Ptr CInt > > > #def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;} > > > > The problem with that is that it doesn't follow the rules about scope of > > header files either. Technically the little .h file that hsc2hs > > generates for you needs to be installed and used by every client > > package. > > no, because your stub functions have a well defined ABI (that was the > point of the stub functions after all), so you wouldn't need to keep the > header around in general assuming the compiler supported header-less > compilation (which ghc doesn't yet AFAIK). Well ghc does both. If you compile the above -fvia-C then you may well get warnings from gcc about missing prototypes, if you compile -fasm then ghc believes the ABI given by the FFI decl. It also seems I thought the ffi spec said more about headers than it actually does. :-) > I always thought c2hs should actually generate hsc files. That would > allow people to compile programs that use c2hs without having to install > c2hs on their build machines. hsc2hs is the minimal tool needed to write > portable C interfaces so needs to be installed on target systems anyway. c2hs has to read the header files on your system to be able to check any consistency. I'm not sure why hsc2hs is the minimal tool. It relies on a C compiler where c2hs does not. What happens with Haskell implementations that do not bundle a C compiler (eg ghc in future on win32)? Duncan From john at repetae.net Thu Mar 6 07:50:05 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 6 07:47:30 2008 Subject: scope of header files In-Reply-To: <1204807316.11558.355.camel@localhost> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> <20080306024650.GB4914@sliver.repetae.net> <1204800222.11558.319.camel@localhost> <20080306111120.GE4914@sliver.repetae.net> <1204807316.11558.355.camel@localhost> Message-ID: <20080306125005.GH4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 12:41:56PM +0000, Duncan Coutts wrote: > c2hs has to read the header files on your system to be able to check any > consistency. > > I'm not sure why hsc2hs is the minimal tool. It relies on a C compiler > where c2hs does not. What happens with Haskell implementations that do > not bundle a C compiler (eg ghc in future on win32)? Hmm... I am not quite sure how c2hs works then. like, how can it figure out the offsets of fields in data structures without knowing the field layout algorithm for a given architecture/os combo without invoking a c compiler? Though, if there were a way to figure that stuff out without a c compiler in a portable way, that would be cool. John -- John Meacham - ?repetae.net?john? From Christian.Maeder at dfki.de Thu Mar 6 11:59:50 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 6 11:57:21 2008 Subject: timer_create Message-ID: <47D02306.2010102@dfki.de> Hi, my binary distribution http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-linux.tar.bz2 creates binaries that fail on some i386 linux boxes with: timer_create: Invalid argument I've built the distribution with gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) and the file lib/ghc-6.8.2/include/ghcautoconf.h contains: #define HAVE_TIMER_CREATE 1 The failing machine uses gcc version 3.3.5 and ./configure within the ghc-6.8.2 sources says: checking for a working timer_create(CLOCK_REALTIME)... no Take this as a warning when using my binary-dist above (or when building your own). Or is there a work around (apart from creating a new binary-dist using ghc-6.6.1)? Cheers Christian From wss at cs.nott.ac.uk Thu Mar 6 12:57:16 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Thu Mar 6 12:54:40 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> Message-ID: <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> Hi Greg, Thanks again for maintaining ghc in macports! I tried installing ghc through macports. Unfortunately, the build failed with the following error message below. I'd be happy to send you a complete log, if you think it would help. Many thanks, Wouter main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries' main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries' main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs' main/ParsePkgConf.hs:299:35: Not in scope: `includes' main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions' main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions' main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions' main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs' main/ParsePkgConf.hs:304:35: Not in scope: `frameworks' main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces' main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs' main/ParsePkgConf.hs:307:34: Not in scope: `depends' main/ParsePkgConf.hs:320:43: Not in scope: `depends' <> make[2]: *** [stage2/main/ParsePkgConf.o] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 Warning: the following items did not execute (for ghc): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. From duncan.coutts at worc.ox.ac.uk Thu Mar 6 22:04:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 6 22:02:10 2008 Subject: scope of header files In-Reply-To: <20080306125005.GH4914@sliver.repetae.net> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> <20080306024650.GB4914@sliver.repetae.net> <1204800222.11558.319.camel@localhost> <20080306111120.GE4914@sliver.repetae.net> <1204807316.11558.355.camel@localhost> <20080306125005.GH4914@sliver.repetae.net> Message-ID: <1204859086.11558.378.camel@localhost> On Thu, 2008-03-06 at 04:50 -0800, John Meacham wrote: > On Thu, Mar 06, 2008 at 12:41:56PM +0000, Duncan Coutts wrote: > > c2hs has to read the header files on your system to be able to check any > > consistency. > > > > I'm not sure why hsc2hs is the minimal tool. It relies on a C compiler > > where c2hs does not. What happens with Haskell implementations that do > > not bundle a C compiler (eg ghc in future on win32)? > > Hmm... I am not quite sure how c2hs works then. like, how can it figure > out the offsets of fields in data structures without knowing the field > layout algorithm for a given architecture/os combo without invoking a c > compiler? It's calculated directly. > Though, if there were a way to figure that stuff out without a c > compiler in a portable way, that would be cool. It is specified by the platform C ABI. So it varies from one platform to another, but it is specified for most platforms, that's what allows you to link code compiled by different C compilers and have it work. Duncan From john at repetae.net Thu Mar 6 22:47:25 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 6 22:44:46 2008 Subject: scope of header files In-Reply-To: <1204859086.11558.378.camel@localhost> References: <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <1204769888.11558.314.camel@localhost> <20080306024650.GB4914@sliver.repetae.net> <1204800222.11558.319.camel@localhost> <20080306111120.GE4914@sliver.repetae.net> <1204807316.11558.355.camel@localhost> <20080306125005.GH4914@sliver.repetae.net> <1204859086.11558.378.camel@localhost> Message-ID: <20080307034724.GK4914@sliver.repetae.net> On Fri, Mar 07, 2008 at 03:04:46AM +0000, Duncan Coutts wrote: > > Though, if there were a way to figure that stuff out without a c > > compiler in a portable way, that would be cool. > > It is specified by the platform C ABI. So it varies from one platform to > another, but it is specified for most platforms, that's what allows you > to link code compiled by different C compilers and have it work. Yeah, I was thinking about a potentially unknown platform, so you can distribute portable code that is only localized when it is finally compiled for the given platform. Though, I should look at that code for calculating the offsets in c2hs, those could come in handy. I have some code in jhc to take a generic jhc library and specialize it for a given architecture, adding the ability to figure out structure offsets would be useful too. The idea is that to install a jhc library all you need to do is grab a single 'hl' file and drop it somewhere, but you can optionally re-optimize it specifically for your platform, (presumably after pulling it down from the web or hackage or somewhere..) John -- John Meacham - ?repetae.net?john? From gwright at comcast.net Fri Mar 7 17:34:37 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri Mar 7 17:32:06 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> Message-ID: Hi Wouter, On Mar 6, 2008, at 12:57 PM, Wouter Swierstra wrote: > Hi Greg, > > Thanks again for maintaining ghc in macports! > > I tried installing ghc through macports. Unfortunately, the build > failed with the following error message below. I'd be happy to send > you a complete log, if you think it would help. Many thanks, > > Wouter > > > > main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries' > > main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries' > > main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs' > > main/ParsePkgConf.hs:299:35: Not in scope: `includes' > > main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions' > > main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions' > > main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions' > > main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs' > > main/ParsePkgConf.hs:304:35: Not in scope: `frameworks' > > main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces' > > main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs' > > main/ParsePkgConf.hs:307:34: Not in scope: `depends' > > main/ParsePkgConf.hs:320:43: Not in scope: `depends' > < residency (3 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.09 > MUT (0.13 elapsed), 0.06 GC (0.07 elapsed) :ghc>> > make[2]: *** [stage2/main/ParsePkgConf.o] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 > > Warning: the following items did not execute (for ghc): > org.macports.activate org.macports.build org.macports.destroot > org.macports.install > Error: Status 1 encountered during processing. > This is odd. What platform (intel/ppc and OS X version) are you running on? A complete log would help too. The output of # sudo port -dv destroot ghc > dest.log 2>&1 is good. You will probably want to compress the log file before sending. One thing you might try is to ensure that you have no failed build lying around by running # sudo port clean ghc # sudo port install ghc The combination of ghc Makefiles and MacPorts infrastructure is not able to recover from a failed or interrupted build. You need to clean up and start over. You should also clean before recording the log. Best, greg From gwright at comcast.net Fri Mar 7 18:57:45 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri Mar 7 18:55:05 2008 Subject: ANN: prof2dot, a graphical profiling tool Message-ID: <6BE969B5-113C-4DAC-89AC-B215AAE60E88@comcast.net> I am pleased to announce the first release of prof2dot, a graphical profiling tool for use with GHC. While GHC has in the past worked with graphical profiling tools, they have been heavyweight and/or proprietary. Prof2dot is a simple tool for converting profiling information into a graphical format, released under a BSD3 license. It is simple because it offloads all of the work of rendering the graph onto Graphviz. So you need to install the Graphviz tools in order to use it. The program is a filter that takes the profiling output generated by running a GHC-compiled program with the "+RTS -px -RTS" option and turns it into a dot file. (The "dot" format is a textual representation of a directed or undirected graph.) The dot file can rendered in any format supported by Graphviz's dot program, and the file itself can be post-processed or edited to adjust the layout. Features of prof2dot: * display either the call graph (default) or the call tree, * colorize by cost center count, time or allocations, * group cost centers in the same module. Prof2dot installs as a typical caballized application. Running "prof2dot -?" from the command line will give a short summary of how to use the program and its options. Rendering very large graphs can exceed the internal resource limits of dot. You may have to compile your own version of the Graphviz tools with higher limits to handle these cases. A example of a colorized profile of a medium sized project is shown on our company's web site: http://antiope.com/downloads.html. Click on the small image to download a pdf of the complete profile graph. Prof2dot is available from hackage or the link given above. -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080307/af178fa0/attachment-0001.htm From igloo at earth.li Sun Mar 9 19:24:21 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Mar 9 19:21:35 2008 Subject: Release plans Message-ID: <20080309232421.GA3933@matrix.chaos.earth.li> Hi all, Here are our plans for the next couple of GHC releases. First, we intend to release the next version of GHC from the current stable branch, 6.8.3, around the end of May 2008. This will probably be the last release from this branch. We currently have 90 bugs in either the "6.8.3" or "6.8 branch" milestone, but we do not expect that we will have time to fix them all! So please take a few minutes to take a look through the list, and if there are any that are particularly important to you please: * add a comment to the bug report saying why it is important to you. It is not necessary to also send us a mail, as we get the comments e-mailed to us automatically. * add yourself to the CC list for the bug (we use this to get a count of the number of people interested in a bug). This will help us to make a release that fixes as many problems, for as many people, as possible. The list is here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.3&milestone=6.8+branch&order=priority After that, around ICFP (late September 2008) we plan to make the first release, 6.10.1, from the next stable branch, 6.10. There will be more information on what exciting changes this will bring closer to the time. Thanks Ian, on behalf of the GHC team From ndmitchell at gmail.com Sun Mar 9 19:32:10 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Mar 9 19:29:24 2008 Subject: Release plans In-Reply-To: <20080309232421.GA3933@matrix.chaos.earth.li> References: <20080309232421.GA3933@matrix.chaos.earth.li> Message-ID: <404396ef0803091632l33aabc25ifc4fa24c3918a03a@mail.gmail.com> Hi > First, we intend to release the next version of GHC from the current > stable branch, 6.8.3, around the end of May 2008. This will probably be > the last release from this branch. Is it possible to include the cabal-install tool with this release, in the Windows installer? The cabal-install tool provides very useful functionality, and is currently rather tricky to install. If cabal-install was already installed, then installing cabal-install would be trivial (note how cabal-install causes a mental black hole). Thanks Neil From duncan.coutts at worc.ox.ac.uk Sun Mar 9 20:22:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 9 20:20:03 2008 Subject: Release plans In-Reply-To: <404396ef0803091632l33aabc25ifc4fa24c3918a03a@mail.gmail.com> References: <20080309232421.GA3933@matrix.chaos.earth.li> <404396ef0803091632l33aabc25ifc4fa24c3918a03a@mail.gmail.com> Message-ID: <1205108569.11558.681.camel@localhost> On Sun, 2008-03-09 at 23:32 +0000, Neil Mitchell wrote: > Hi > > > First, we intend to release the next version of GHC from the current > > stable branch, 6.8.3, around the end of May 2008. This will probably be > > the last release from this branch. > > Is it possible to include the cabal-install tool with this release, in > the Windows installer? > > The cabal-install tool provides very useful functionality, and is > currently rather tricky to install. If cabal-install was already > installed, then installing cabal-install would be trivial (note how > cabal-install causes a mental black hole). Note that cabal-install requires the yet-unreleased Cabal-1.4.x and that GHC-6.8.3 will come with a release from the Cabal-1.2.x branch to preserve API compatibility with the earlier GHC-6.8.x releases. You could still have a cabal-install binary in the Windows installer and not include the Cabal-1.4.x library that you built it against. Alternatively it'd be possible to include Cabal-1.4.x too and have it not exposed by default. That'd enable cabal-install to use it for any packages that use a custom Setup.hs without it being picked up by default by ghc --make or ghci. cabal-install will become easier to install anyway once we make an official release of it and Cabal-1.4. If that's still too tricky for people we could make a single tarball that bundles Cabal-1.4, zlib, HTTP and cabal-install but installs only the cabal-install binary. Duncan From ndmitchell at gmail.com Mon Mar 10 04:23:28 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 04:20:40 2008 Subject: Release plans In-Reply-To: <1205108569.11558.681.camel@localhost> References: <20080309232421.GA3933@matrix.chaos.earth.li> <404396ef0803091632l33aabc25ifc4fa24c3918a03a@mail.gmail.com> <1205108569.11558.681.camel@localhost> Message-ID: <404396ef0803100123y47a61489w74430db3955a9a69@mail.gmail.com> Hi > You could still have a cabal-install binary in the Windows installer and > not include the Cabal-1.4.x library that you built it against. That sounds easiest, and should give all the cabal-install benefits to Windows users. > Alternatively it'd be possible to include Cabal-1.4.x too and have it > not exposed by default. That'd enable cabal-install to use it for any > packages that use a custom Setup.hs without it being picked up by > default by ghc --make or ghci. Unless the API 100% stable, I'd be wary of supporting a not quite finished release on Cabal in something as major as GHC. Upgrading Cabal is fairly easy, if people want to do it themselves. If Cabal supported darcs links, you could even imagine upgrading cabal with "cabal install cabal --from-darcs" - that would be wonderful! Thanks Neil From duncan.coutts at worc.ox.ac.uk Mon Mar 10 07:36:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 10 07:38:54 2008 Subject: Release plans In-Reply-To: <404396ef0803100123y47a61489w74430db3955a9a69@mail.gmail.com> References: <20080309232421.GA3933@matrix.chaos.earth.li> <404396ef0803091632l33aabc25ifc4fa24c3918a03a@mail.gmail.com> <1205108569.11558.681.camel@localhost> <404396ef0803100123y47a61489w74430db3955a9a69@mail.gmail.com> Message-ID: <1205148962.11558.778.camel@localhost> On Mon, 2008-03-10 at 08:23 +0000, Neil Mitchell wrote: > Hi > > > You could still have a cabal-install binary in the Windows installer and > > not include the Cabal-1.4.x library that you built it against. > > That sounds easiest, and should give all the cabal-install benefits to > Windows users. Not quite all. If a package specifies not build type or uses Custom then we have to compile the Setup.hs using the installed Cabal lib. In theory cabal-install can build it against an older version of the Cabal lib, in practise it's not been tested much. > > Alternatively it'd be possible to include Cabal-1.4.x too and have it > > not exposed by default. That'd enable cabal-install to use it for any > > packages that use a custom Setup.hs without it being picked up by > > default by ghc --make or ghci. > > Unless the API 100% stable, I'd be wary of supporting a not quite > finished release on Cabal in something as major as GHC. If it was a 1.4 release then it would have to be stable. We do follow the package versioning policy. > Upgrading Cabal is fairly easy, if people want to do it themselves. We can make it just as easy to install cabal-install even if it didn't come with this version of GHC. > If Cabal supported darcs links, you could even imagine upgrading cabal > with "cabal install cabal --from-darcs" - that would be wonderful! It's an often requested feature, see ticket #58. Of course cabal-install can install releases on hackage of Cabal and itself. Duncan From mechvel at botik.ru Mon Mar 10 08:03:45 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Mar 10 08:01:19 2008 Subject: swap (x, y) Message-ID: <20080310120345.GA26709@scico.botik.ru> I define and use swap (x, y) = (y, x) because do not find such in the standard library. Please, can people point at it, in the standard library, or at least in GHC? Thank you in advance for your help. ----------------- Serge Mechveliani mechvel@botik.ru From ndmitchell at gmail.com Mon Mar 10 08:11:40 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 08:08:51 2008 Subject: swap (x, y) In-Reply-To: <20080310120345.GA26709@scico.botik.ru> References: <20080310120345.GA26709@scico.botik.ru> Message-ID: <404396ef0803100511n62658d4exa7d2a99d9ede831f@mail.gmail.com> Hi Serge, > I define and use swap (x, y) = (y, x) > > because do not find such in the standard library. You can search for it in the standard libraries using Hoogle: http://haskell.org/hoogle/?q=(a,b)->(b,a) > Please, can people point at it, in the standard library, or at least > in GHC? And as it turns out, it isn't anywhere in the standard libraries. I think this would be a useful function to add to Data.Tuple, so feel free to propose it for addition. Thanks Neil From gale at sefer.org Tue Mar 11 05:59:23 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Mar 11 05:56:37 2008 Subject: swap (x, y) In-Reply-To: <404396ef0803100511n62658d4exa7d2a99d9ede831f@mail.gmail.com> References: <20080310120345.GA26709@scico.botik.ru> <404396ef0803100511n62658d4exa7d2a99d9ede831f@mail.gmail.com> Message-ID: <2608b8a80803110259s39825426r701126e5db34bac2@mail.gmail.com> Hi Neil, Neil Mitchell wrote: > You can search for it in the standard libraries using Hoogle: > [something mangled] I think you were trying to suggest searching for "(a,b)->(b,a)" by using a URI directly. My mail reader justifiably mangled your proposed URI, as would any non-broken mail reader, since it included the illegal character '>'. See RFC 2396. You would have to use http://haskell.org/hoogle/?q=(a,b)-%3E(b,a) Easiest just to say: "Go to http://haskell.org/hoogle and search for (a,b)->(b,a)". Regards, Yitz From simonmarhaskell at gmail.com Tue Mar 11 17:47:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Mar 11 17:44:51 2008 Subject: scope of header files In-Reply-To: <20080306013705.GA4914@sliver.repetae.net> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> Message-ID: <47D6FDF9.6050404@gmail.com> John Meacham wrote: > On Thu, Mar 06, 2008 at 12:23:35AM +0000, Duncan Coutts wrote: >> Which is really annoying :-) I'd like greater control over it, in >> particular a way to limit headers to package scope so that dependent >> code does not need the headers. > > Ideally there would be no need for headers at all. Everything needed is > inherently in the foreign declaration. If anything, the headers should > just be used as a sanity check, not actually to affect the generated > code. It would be nice if ghc just stopped relying on them and ignored > them altogether. Yeah, I'd like -fvia-C to be headerless. We talked about it a while back (on the haskell-prime list I think). The main issue is that GHC would have to generate prototypes based on the FFI declaration, and since it can't guarantee to generate a prototype that is exactly the same as the C prototype given in the header file (e.g. it doesn't know about const), we would have to ensure that there really are no other prototypes in scope, to prevent errors from the C compiler. One reason I want to do this is that it would make via-C compilation less fragile, particularly in terms of getting the .cabal file right. Via-C compilation is about to get a lot less common - in 6.10 it'll only be used for bootstrapping, so we don't want a significant fraction of libraries fail to work when bootstrapped via C due to missing include-files declarations. Cheers, Simon From simonmarhaskell at gmail.com Tue Mar 11 19:25:52 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Mar 11 19:23:13 2008 Subject: scope of header files In-Reply-To: <1204758974.11558.256.camel@localhost> References: <1204758974.11558.256.camel@localhost> Message-ID: <47D71500.6090202@gmail.com> Duncan Coutts wrote: > I was under the impression that with ghc, ffi import declarations like > this do not escape the module: > > foreign import ccall unsafe "foo.h foo" foo :: IO () > > However it seems that this one does: > > foreign import ccall unsafe "curses.h & stdscr" stdscrp :: Ptr WINDOWptr > > from: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mage-1.0 > > perhapsPbecause it's a pointer import it gets treated differently? I just tried this and couldn't reproduce the problem. ----------------- module Test where import Foreign data WINDOWptr foreign import ccall unsafe "curses.h & stdscr" stdscrp :: Ptr WINDOWptr ----------------- Using -ddump-simpl we can see the declaration marked as NEVER inline, and indeed it doesn't appear in the .hi file. The code that does this is in DsForeign.csCImport, and it certainly looks like it handles the &foo case in addition to normal foreign calls. Maybe there's something else going on.. can you boil down the example at all? Cheers, Simon From john at repetae.net Wed Mar 12 13:43:56 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 12 13:41:01 2008 Subject: scope of header files In-Reply-To: <47D6FDF9.6050404@gmail.com> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <47D6FDF9.6050404@gmail.com> Message-ID: <20080312174355.GA15073@sliver.repetae.net> On Tue, Mar 11, 2008 at 02:47:37PM -0700, Simon Marlow wrote: > Yeah, I'd like -fvia-C to be headerless. We talked about it a while back > (on the haskell-prime list I think). The main issue is that GHC would have > to generate prototypes based on the FFI declaration, and since it can't > guarantee to generate a prototype that is exactly the same as the C > prototype given in the header file (e.g. it doesn't know about const), we > would have to ensure that there really are no other prototypes in scope, to > prevent errors from the C compiler. I was thinking that you just wouldn't include any extra c headers at all then, just write out the appropriate c code to call with the conventions specified in the ffi import specification and you won't need external headers at all so there isn't anything to conflict with. John -- John Meacham - ?repetae.net?john? From joseph.bruce at pnl.gov Wed Mar 12 17:21:12 2008 From: joseph.bruce at pnl.gov (Bruce, Joseph R (Joe)) Date: Wed Mar 12 17:18:17 2008 Subject: Understanding the undefine flags passed to gcc when linking Message-ID: Hi, When I run 'ghc -v ...', the linking is done via gcc->ld with a large list of -u flags passed in. I'm hoping to find a way to link my object files without those flags, but first I need to understand what they are doing. Can someone explain it to me? Or point me to documentation that explains it? My ultimate goal is to build a static Haskell library and make it available to c programmers ignorant of Haskell. The undefines described above are a major obstacle. Does anyone know a way around them? Thanks, Joe Bruce Phone: 509.372.6198 Pacific Northwest National Laboratory 902 Battelle Blvd. Richland, WA From simonmarhaskell at gmail.com Wed Mar 12 18:10:27 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Mar 12 18:07:36 2008 Subject: scope of header files In-Reply-To: <20080312174355.GA15073@sliver.repetae.net> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <47D6FDF9.6050404@gmail.com> <20080312174355.GA15073@sliver.repetae.net> Message-ID: <47D854D3.901@gmail.com> John Meacham wrote: > On Tue, Mar 11, 2008 at 02:47:37PM -0700, Simon Marlow wrote: >> Yeah, I'd like -fvia-C to be headerless. We talked about it a while back >> (on the haskell-prime list I think). The main issue is that GHC would have >> to generate prototypes based on the FFI declaration, and since it can't >> guarantee to generate a prototype that is exactly the same as the C >> prototype given in the header file (e.g. it doesn't know about const), we >> would have to ensure that there really are no other prototypes in scope, to >> prevent errors from the C compiler. > > I was thinking that you just wouldn't include any extra c headers at all > then, just write out the appropriate c code to call with the conventions > specified in the ffi import specification and you won't need external > headers at all so there isn't anything to conflict with. Yes, pretty much. There are a bunch of C headers that define the macros used by the generated C code, and we have to be careful that they don't include anything external - in the past we used to #include several things from /usr/include, but I think we're much cleaner these days. Cheers, Simon From simonmarhaskell at gmail.com Wed Mar 12 18:18:06 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Mar 12 18:15:20 2008 Subject: Understanding the undefine flags passed to gcc when linking In-Reply-To: References: Message-ID: <47D8569E.9040201@gmail.com> Bruce, Joseph R (Joe) wrote: > > When I run 'ghc -v ...', the linking is done via gcc->ld with a large > list of -u flags passed in. I'm hoping to find a way to link my object > files without those flags, but first I need to understand what they are > doing. Can someone explain it to me? Or point me to documentation that > explains it? > > My ultimate goal is to build a static Haskell library and make it > available to c programmers ignorant of Haskell. The undefines described > above are a major obstacle. Does anyone know a way around them? The -u flags arise because there is a circular dependency between the RTS (libHSrts.a) and the base package (libHSbase.a). The RTS refers to a few datatypes and functions in the base package, for instance the constructors for True and False, I#, C# and so on, and some exceptions that the RTS automatically raises for certain events (e.g. stack overflow, non-termination). One way to avoid needing the -u flags would be to link the base package twice, but that would slow down linking, and twice might not be enough. With shared libraries there's no problem, because we always just link the whole library, this is only an issue with static libraries. So for building a static Haskell library, can't you just link the RTS and base package together in a single .a file? Cheers, Simon From joseph.bruce at pnl.gov Wed Mar 12 19:10:24 2008 From: joseph.bruce at pnl.gov (Bruce, Joseph R (Joe)) Date: Wed Mar 12 19:07:29 2008 Subject: Understanding the undefine flags passed to gcc when linking In-Reply-To: <47D8569E.9040201@gmail.com> References: <47D8569E.9040201@gmail.com> Message-ID: Thanks Simon. That is the best answer I've received to this question in many askings. I will try to go the shared library route. A question about you last comment: when you say link RTS and base, you mean extract the object files and package in a single .a? Am I going to run into namespace collisions? Joe > -----Original Message----- > From: Simon Marlow [mailto:simonmarhaskell@gmail.com] > Sent: Wednesday, March 12, 2008 3:18 PM > To: Bruce, Joseph R (Joe) > Cc: glasgow-haskell-users@haskell.org > Subject: Re: Understanding the undefine flags passed to gcc > when linking > > Bruce, Joseph R (Joe) wrote: > > > > When I run 'ghc -v ...', the linking is done via gcc->ld > with a large > > list of -u flags passed in. I'm hoping to find a way to link my > > object files without those flags, but first I need to > understand what > > they are doing. Can someone explain it to me? Or point me to > > documentation that explains it? > > > > My ultimate goal is to build a static Haskell library and make it > > available to c programmers ignorant of Haskell. The undefines > > described above are a major obstacle. Does anyone know a > way around them? > > The -u flags arise because there is a circular dependency > between the RTS (libHSrts.a) and the base package > (libHSbase.a). The RTS refers to a few datatypes and > functions in the base package, for instance the constructors > for True and False, I#, C# and so on, and some exceptions > that the RTS automatically raises for certain events (e.g. > stack overflow, non-termination). > > One way to avoid needing the -u flags would be to link the > base package twice, but that would slow down linking, and > twice might not be enough. > With shared libraries there's no problem, because we always > just link the whole library, this is only an issue with > static libraries. > > So for building a static Haskell library, can't you just link > the RTS and base package together in a single .a file? > > Cheers, > Simon > From duncan.coutts at worc.ox.ac.uk Wed Mar 12 22:18:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 12 22:15:54 2008 Subject: scope of header files In-Reply-To: <47D71500.6090202@gmail.com> References: <1204758974.11558.256.camel@localhost> <47D71500.6090202@gmail.com> Message-ID: <1205374728.11558.1034.camel@localhost> On Tue, 2008-03-11 at 16:25 -0700, Simon Marlow wrote: > Duncan Coutts wrote: > > from: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mage-1.0 > > > > perhapsPbecause it's a pointer import it gets treated differently? > > I just tried this and couldn't reproduce the problem. > Maybe there's something else going on.. can you boil down the example at > all? I can reproduce the problem with the mage-1.0 tarball with the following changes: add -fvia-C to the ghc-options add include-dirs: src Inspecting Main.hc we find things like: _s2oT = *((P_)(W_)&stdscr); that is references to the stdscr pointer. I was trying to get a boiled down example. I started with src/Main and commented stuff out. By commenting out the call to clear_screen the error went away. That's because it's clear_screen from src/Curses.hsc that references stdscrp. I swear it's non-deterministic, even when removing the .hi files before each run. Here's the smallest I can get it: module Curses (screen_size) where import Foreign data WINDOW = WINDOW type WINDOWptr = Ptr WINDOW foreign import ccall unsafe "curses.h & stdscr" stdscrp :: Ptr WINDOWptr screen_size :: IO () screen_size = do stdscr <- peek stdscrp return () module Main (main) where import Curses main = print =<< screen_size And (re-)building using: $ rm Main.hi Curses.hi; ghc-6.8.2 --make -O2 -fvia-C -fffi Main.hs -keep-hc-files [1 of 2] Compiling Curses ( Curses.hs, Curses.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) In file included from /usr/lib64/ghc-6.8.2/include/Stg.h:150, from Main.hc:3:0: Main.hc: In function ?Main_a_entry?: Main.hc:46:0: error: ?stdscr? undeclared (first use in this function) Main.hc:46:0: error: (Each undeclared identifier is reported only once Main.hc:46:0: error: for each function it appears in.) Inspecting Main.hc we see _sFH = *((P_)(W_)&stdscr); inside the Main_a_entry. The Curses.hc does #include "curses.h" as required. It's Main.hc that does not, despite using &stdscr. Seems that -O2 is not necessary, -O also elicits the failure. ghc --show-iface Curses.hi shows us these interesting exports: screen_size :: GHC.IOBase.IO () {- Arity: 1 HasNoCafRefs Strictness: L Unfolding: (Curses.a `cast` (sym ((GHC.IOBase.:CoIO) ()))) -} a :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) {- Arity: 1 HasNoCafRefs Strictness: L Unfolding: (\ s :: GHC.Prim.State# GHC.Prim.RealWorld -> case @ (# GHC.Prim.State# GHC.Prim.RealWorld, () #) GHC.Prim.readAddrOffAddr# @ GHC.Prim.RealWorld __label "stdscr" 0 s of wild2 { (# s2, x #) -> (# s2, GHC.Base.() #) }) -} (re-indented to fit) The __label "stdscr" in a's unfolding is particularly interesting. That looks like the route by which "stdscr" escapes the Curses module and ends up in Main, outside of the scope of the header file. Duncan From Christian.Maeder at dfki.de Thu Mar 13 05:25:25 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 13 05:22:29 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> Message-ID: <47D8F305.1060202@dfki.de> Gregory Wright wrote: > Leopard/ppc are out of luck until for now, for reason discussed earlier > on this list. I was able to build ghc 6.8.2 on Leopard/ppc using the patch from http://hackage.haskell.org/trac/ghc/ticket/1958 (also below) Could you try if it works for you, too? Cheers Christian +++ ghc-6.8.2/compiler/nativeGen/PprMach.hs @@ -657,7 +657,7 @@ SLIT(".section .data\n\t.align 4")) ,IF_ARCH_x86_64(IF_OS_darwin(SLIT(".const_data\n.align 3"), SLIT(".section .data\n\t.align 8")) - ,IF_ARCH_powerpc(IF_OS_darwin(SLIT(".const_data\n.align 2"), + ,IF_ARCH_powerpc(IF_OS_darwin(SLIT(".text\n.align 2"), SLIT(".data\n\t.align 2")) ,))))) From Christian.Maeder at dfki.de Thu Mar 13 07:10:28 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 13 07:07:33 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <47D8F305.1060202@dfki.de> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> Message-ID: <47D90BA4.3050805@dfki.de> Christian Maeder wrote: > Gregory Wright wrote: >> Leopard/ppc are out of luck until for now, for reason discussed earlier >> on this list. > > I was able to build ghc 6.8.2 on Leopard/ppc using the patch from > > http://hackage.haskell.org/trac/ghc/ticket/1958 > (also below) > > Could you try if it works for you, too? I forgot to mention, that I had to build a bootstrapping compiler on pcc tiger with this patch first. C. From gwright at comcast.net Thu Mar 13 09:54:24 2008 From: gwright at comcast.net (Gregory Wright) Date: Thu Mar 13 09:51:45 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <47D90BA4.3050805@dfki.de> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> <47D90BA4.3050805@dfki.de> Message-ID: <6BC05245-946C-443B-8C49-E8577311F99A@comcast.net> Hi Christian, On Mar 13, 2008, at 7:10 AM, Christian Maeder wrote: >> I was able to build ghc 6.8.2 on Leopard/ppc using the patch from >> >> http://hackage.haskell.org/trac/ghc/ticket/1958 >> (also below) >> >> Could you try if it works for you, too? > > I forgot to mention, that I had to build a bootstrapping compiler on > pcc > tiger with this patch first. > I'll build a bootstrap compiler with this patch today so we can give it a try. Thanks! -Greg From gwright at comcast.net Thu Mar 13 10:42:48 2008 From: gwright at comcast.net (Gregory Wright) Date: Thu Mar 13 10:39:58 2008 Subject: ghc's trac is wedged Message-ID: <100FA60C-52DA-41F3-824A-07C0DB0F78A0@comcast.net> Hi, This morning (13 March 2008) the ghc trac wedged reporting Trac detected an internal error: with the python traceback Traceback (most recent call last): File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, in dispatch resp = chosen_handler.process_request(req) File "/var/lib/python-support/python2.4/trac/web/auth.py", line 100, in process_request self._do_login(req) File "/var/lib/python-support/python2.4/trac/web/auth.py", line 139, in _do_login "VALUES (%s, %s, %s, %s)", (cookie, remote_user, File "/var/lib/python-support/python2.4/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 237, in execute self.con._begin() File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 503, in _begin self.db.execute("BEGIN") OperationalError: database is locked Please let me know if there is a more direct way to report failures such as this one, instead of posting to the list. Best Wishes, Greg From johan.tibell at gmail.com Thu Mar 13 14:47:03 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Mar 13 14:44:04 2008 Subject: Making rule application less fragile Message-ID: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> Hi, I'm trying (for the first time ever) to use RULES pragmas to achieve some nice speedups in my bytestring parsing library. The relevant code in my library's module is: -- The module imports Control.Applicative which containes 'many' and 'some'. -- | The parser @satisfy p@ succeeds for any byte for which the -- supplied function @p@ returns 'True'. Returns the byte that is -- actually parsed. satisfy :: (Word8 -> Bool) -> Parser Word8 satisfy p = Parser $ \s@(S bs pos eof) succ fail -> case S.uncons bs of Just (b, bs') -> if p b then succ b (S bs' (pos + 1) eof) else fail s Nothing -> if eof then fail s else IPartial $ \x -> case x of Just bs' -> retry (S bs' pos eof) Nothing -> fail (S bs pos True) where retry s' = unParser (satisfy p) s' succ fail -- | @byte b@ parses a single byte @b@. Returns the parsed byte -- (i.e. @b@). byte :: Word8 -> Parser Word8 byte b = satisfy (== b) -- --------------------------------------------------------------------- -- Rewrite rules satisfyMany :: (Word8 -> Bool) -> Parser S.ByteString satisfyMany p = undefined -- More efficient implementation goes here. satisfySome :: (Word8 -> Bool) -> Parser S.ByteString satisfySome p = undefined -- More efficient implementation goes here. {-# RULES "fmap/pack/many/satisfy" forall p. fmap S.pack (many (satisfy p)) = satisfyMany p "fmap/pack/some/satisfy" forall p. fmap S.pack (some (satisfy p)) = satisfySome p #-} In another module where I use the library I have this code: pHeaders :: Parser [(S.ByteString, S.ByteString)] pHeaders = many header where header = liftA2 (,) fieldName (byte (c2w ':') *> spaces *> contents) fieldName = liftA2 (S.cons) letter fieldChars contents = liftA2 (S.append) (fmap S.pack $ some notEOL <* crlf) (continuation <|> pure S.empty) continuation = liftA2 (S.cons) ((c2w ' ') <$ some (oneOf (map c2w " \t"))) contents -- It's important that all three of these definitions are kept on the -- top level to have RULES fire correctly. fieldChars = fmap S.pack $ many fieldChar -- fieldChar = letter <|> digit <|> oneOf (map c2w "-_") fieldChar = satisfy isFieldChar where isFieldChar b = (isDigit $ chr $ fromIntegral b) || (isAlpha $ chr $ fromIntegral b) || (b `elem` map c2w "-_") I want the fieldChars use of 'fmap S.pack $ many fieldChar' to trigger my rewrite rule "fmap/pack/many/satisfy" which it does in this case. The trouble is that the rule only triggers when I make at least fieldChars and fieldChar top-level definition and isFieldChar either a named local definition in fieldChar or a top-level definition. If I turn the predicate (isFieldChar) into to an anonymous lambda function it doesn't trigger, if I make either fieldChars or fieldChars a local defintion (in a where clause) of pHeaders it doesn't trigger. If I make fieldChar a local definition in fieldChars it doesn't trigger, etc. It would be great if there was a way to make this a bit less fragile and have the rule trigger more often as it is potentially a huge performance win. I understand it's hard to guarantee that the rule always triggers but now it triggers in rare cases. -- Johan From simonmarhaskell at gmail.com Thu Mar 13 16:31:41 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Mar 13 16:28:48 2008 Subject: ghc's trac is wedged In-Reply-To: <100FA60C-52DA-41F3-824A-07C0DB0F78A0@comcast.net> References: <100FA60C-52DA-41F3-824A-07C0DB0F78A0@comcast.net> Message-ID: <47D98F2D.1060501@gmail.com> Gregory Wright wrote: > This morning (13 March 2008) the ghc trac wedged reporting > > Trac detected an internal error: > > with the python traceback > > Traceback (most recent call last): > File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, > in dispatch_request > dispatcher.dispatch(req) > File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, > in dispatch > resp = chosen_handler.process_request(req) > File "/var/lib/python-support/python2.4/trac/web/auth.py", line 100, > in process_request > self._do_login(req) > File "/var/lib/python-support/python2.4/trac/web/auth.py", line 139, > in _do_login > "VALUES (%s, %s, %s, %s)", (cookie, remote_user, > File "/var/lib/python-support/python2.4/trac/db/util.py", line 50, in > execute > return self.cursor.execute(sql_escape_percent(sql), args) > File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 237, in > execute > self.con._begin() > File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 503, in > _begin > self.db.execute("BEGIN") > OperationalError: database is locked > > > Please let me know if there is a more direct way to report failures such > as this one, > instead of posting to the list. This happens from time to time for me too, usually it goes away with a retry. Cheers, Simon From simonmarhaskell at gmail.com Thu Mar 13 16:47:07 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Mar 13 16:44:15 2008 Subject: Understanding the undefine flags passed to gcc when linking In-Reply-To: References: <47D8569E.9040201@gmail.com> Message-ID: <47D992CB.3000803@gmail.com> Bruce, Joseph R (Joe) wrote: > Thanks Simon. That is the best answer I've received to this question in > many askings. > > I will try to go the shared library route. Shared libraries are currently experimental - you'll probably experience problems, and parts of the infrastructure are still in flux. I wouldn't recommend relying on shared libraries just yet. > A question about you last > comment: when you say link RTS and base, you mean extract the object > files and package in a single .a? Am I going to run into namespace > collisions? Yes, put the whole of the RTS and base into a single .a. You shouldn't run into namespace collisions, as the symbol namespace is global anyway. Cheers, Simon > Joe > >> -----Original Message----- >> From: Simon Marlow [mailto:simonmarhaskell@gmail.com] >> Sent: Wednesday, March 12, 2008 3:18 PM >> To: Bruce, Joseph R (Joe) >> Cc: glasgow-haskell-users@haskell.org >> Subject: Re: Understanding the undefine flags passed to gcc >> when linking >> >> Bruce, Joseph R (Joe) wrote: >>> When I run 'ghc -v ...', the linking is done via gcc->ld >> with a large >>> list of -u flags passed in. I'm hoping to find a way to link my >>> object files without those flags, but first I need to >> understand what >>> they are doing. Can someone explain it to me? Or point me to >>> documentation that explains it? >>> >>> My ultimate goal is to build a static Haskell library and make it >>> available to c programmers ignorant of Haskell. The undefines >>> described above are a major obstacle. Does anyone know a >> way around them? >> >> The -u flags arise because there is a circular dependency >> between the RTS (libHSrts.a) and the base package >> (libHSbase.a). The RTS refers to a few datatypes and >> functions in the base package, for instance the constructors >> for True and False, I#, C# and so on, and some exceptions >> that the RTS automatically raises for certain events (e.g. >> stack overflow, non-termination). >> >> One way to avoid needing the -u flags would be to link the >> base package twice, but that would slow down linking, and >> twice might not be enough. >> With shared libraries there's no problem, because we always >> just link the whole library, this is only an issue with >> static libraries. >> >> So for building a static Haskell library, can't you just link >> the RTS and base package together in a single .a file? >> >> Cheers, >> Simon >> From tora at zonetora.co.uk Thu Mar 13 17:31:34 2008 From: tora at zonetora.co.uk (Tristan Allwood) Date: Thu Mar 13 17:28:31 2008 Subject: setlocale Message-ID: <20080313213134.GA27623@doc.ic.ac.uk> Hi, I've been playing around with hs-curses and utf8, and have discovered that I need to use an ffi call at the top of my main to setlocale(LC_ALL, "") in order to get the hscurses bindings to display utf8-encoded strings correctly. If I understand correctly, the fact that I need to do this means that the ghc rts is either not setting the default locale, or is forcing it to be a c-style one. With that as my context I'm just wondering: a) if this is a known issue b) if there's a known work-around other than rolling your own ffi wrapped call (a library function that I'm not aware of) c) any side effects this might have elsewhere d) if I'm being stupid and could get this to work by just using env vars Regards, Tristan Allwood 21:23:39 - tora@colorado:~ >locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= >ghc -v Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.1 >uname -a Linux colorado 2.6.24-1-amd64 #1 SMP Mon Feb 11 13:47:43 UTC 2008 x86_64 GNU/Linux -- Tristan Allwood PhD Student Department of Computing Imperial College London From dons at galois.com Thu Mar 13 18:24:39 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 13 18:21:51 2008 Subject: Making rule application less fragile In-Reply-To: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> References: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> Message-ID: <20080313222439.GE13771@scytale.galois.com> Hey Johan, The main thing to remember is that anything you wish to match on in a rule needs to not be inlined in the first pass. So to match "many" or "satisfy" robustly, you'll need: {-# NOINLINE [1] many #-} For example. johan.tibell: > Hi, > > I'm trying (for the first time ever) to use RULES pragmas to achieve > some nice speedups in my bytestring parsing library. The relevant code > in my library's module is: > > -- The module imports Control.Applicative which containes 'many' and 'some'. > > -- | The parser @satisfy p@ succeeds for any byte for which the > -- supplied function @p@ returns 'True'. Returns the byte that is > -- actually parsed. > satisfy :: (Word8 -> Bool) -> Parser Word8 > satisfy p = > Parser $ \s@(S bs pos eof) succ fail -> > case S.uncons bs of > Just (b, bs') -> if p b > then succ b (S bs' (pos + 1) eof) > else fail s > Nothing -> if eof > then fail s > else IPartial $ \x -> > case x of > Just bs' -> retry (S bs' pos eof) > Nothing -> fail (S bs pos True) > where retry s' = unParser (satisfy p) s' succ fail > > -- | @byte b@ parses a single byte @b@. Returns the parsed byte > -- (i.e. @b@). > byte :: Word8 -> Parser Word8 > byte b = satisfy (== b) > > -- --------------------------------------------------------------------- > -- Rewrite rules > > satisfyMany :: (Word8 -> Bool) -> Parser S.ByteString > satisfyMany p = undefined -- More efficient implementation goes here. > > satisfySome :: (Word8 -> Bool) -> Parser S.ByteString > satisfySome p = undefined -- More efficient implementation goes here. > > {-# RULES > > "fmap/pack/many/satisfy" forall p. > fmap S.pack (many (satisfy p)) = satisfyMany p > > "fmap/pack/some/satisfy" forall p. > fmap S.pack (some (satisfy p)) = satisfySome p > #-} > > In another module where I use the library I have this code: > > pHeaders :: Parser [(S.ByteString, S.ByteString)] > pHeaders = many header > where > header = liftA2 (,) fieldName (byte (c2w ':') *> spaces *> contents) > fieldName = liftA2 (S.cons) letter fieldChars > contents = liftA2 (S.append) (fmap S.pack $ some notEOL <* crlf) > (continuation <|> pure S.empty) > continuation = liftA2 (S.cons) ((c2w ' ') <$ > some (oneOf (map c2w " \t"))) contents > > -- It's important that all three of these definitions are kept on the > -- top level to have RULES fire correctly. > fieldChars = fmap S.pack $ many fieldChar > > -- fieldChar = letter <|> digit <|> oneOf (map c2w "-_") > fieldChar = satisfy isFieldChar > where > isFieldChar b = (isDigit $ chr $ fromIntegral b) || > (isAlpha $ chr $ fromIntegral b) || > (b `elem` map c2w "-_") > > I want the fieldChars use of 'fmap S.pack $ many fieldChar' to trigger > my rewrite rule "fmap/pack/many/satisfy" which it does in this case. > The trouble is that the rule only triggers when I make at least > fieldChars and fieldChar top-level definition and isFieldChar either a > named local definition in fieldChar or a top-level definition. If I > turn the predicate (isFieldChar) into to an anonymous lambda function > it doesn't trigger, if I make either fieldChars or fieldChars a local > defintion (in a where clause) of pHeaders it doesn't trigger. If I > make fieldChar a local definition in fieldChars it doesn't trigger, > etc. > > It would be great if there was a way to make this a bit less fragile > and have the rule trigger more often as it is potentially a huge > performance win. I understand it's hard to guarantee that the rule > always triggers but now it triggers in rare cases. > > -- Johan > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From johan.tibell at gmail.com Thu Mar 13 18:31:08 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Mar 13 18:28:10 2008 Subject: Making rule application less fragile In-Reply-To: <20080313222439.GE13771@scytale.galois.com> References: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> <20080313222439.GE13771@scytale.galois.com> Message-ID: <90889fe70803131531w2e4fbaafhe99ea8eeba9323cb@mail.gmail.com> On Thu, Mar 13, 2008 at 11:24 PM, Don Stewart wrote: > Hey Johan, > > The main thing to remember is that anything you wish to match on > in a rule needs to not be inlined in the first pass. > > So to match "many" or "satisfy" robustly, you'll need: > > {-# NOINLINE [1] many #-} > > For example. Does that mean that I should add a [2] to my rules so they are run after? I guess it doesn't hurt to try them earlier. -- Johan From simonmarhaskell at gmail.com Thu Mar 13 18:31:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Mar 13 18:28:48 2008 Subject: setlocale In-Reply-To: <20080313213134.GA27623@doc.ic.ac.uk> References: <20080313213134.GA27623@doc.ic.ac.uk> Message-ID: <47D9AB49.9060901@gmail.com> Tristan Allwood wrote: > I've been playing around with hs-curses and utf8, and have discovered > that I need to use an ffi call at the top of my main to > setlocale(LC_ALL, "") in order to get the hscurses bindings to display > utf8-encoded strings correctly. > > If I understand correctly, the fact that I need to do this means that > the ghc rts is either not setting the default locale, or is forcing it > to be a c-style one. With that as my context I'm just wondering: > > a) if this is a known issue > > b) if there's a known work-around other than rolling your own ffi > wrapped call (a library function that I'm not aware of) > > c) any side effects this might have elsewhere > > d) if I'm being stupid and could get this to work by just using env vars Correct, the RTS does not set the locale. It used to at one stage, when we used the C isw* functions to implement Data.Char.isAlpha and so on, but now we use our own Unicode tables so we don't need to set the locale. There probably ought to be a way to call setlocale via System.Posix, but it doesn't look like there is yet. Setting the locale *might* have side-effects, for instance we noticed before that heap profiling broke in some locales because the RTS code to generate the .hp file was using fprintf to print numbers, and the number format depends on the locale. Strictly speaking this is a bug in GHC, we should be generating the heap profile data in a fixed known format. If this happens to you, please file a ticket. Cheers, Simon From dons at galois.com Thu Mar 13 18:32:46 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 13 18:29:53 2008 Subject: Making rule application less fragile In-Reply-To: <90889fe70803131531w2e4fbaafhe99ea8eeba9323cb@mail.gmail.com> References: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> <20080313222439.GE13771@scytale.galois.com> <90889fe70803131531w2e4fbaafhe99ea8eeba9323cb@mail.gmail.com> Message-ID: <20080313223246.GH13771@scytale.galois.com> johan.tibell: > On Thu, Mar 13, 2008 at 11:24 PM, Don Stewart wrote: > > Hey Johan, > > > > The main thing to remember is that anything you wish to match on > > in a rule needs to not be inlined in the first pass. > > > > So to match "many" or "satisfy" robustly, you'll need: > > > > {-# NOINLINE [1] many #-} > > > > For example. > > Does that mean that I should add a [2] to my rules so they are run > after? I guess it doesn't hurt to try them earlier. Right, the rules can run anytime. You want them to run before many gets inlined. From ross at soi.city.ac.uk Thu Mar 13 18:52:24 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Mar 13 18:49:28 2008 Subject: setlocale In-Reply-To: <47D9AB49.9060901@gmail.com> References: <20080313213134.GA27623@doc.ic.ac.uk> <47D9AB49.9060901@gmail.com> Message-ID: <20080313225224.GA15842@soi.city.ac.uk> On Thu, Mar 13, 2008 at 03:31:37PM -0700, Simon Marlow wrote: > Setting the locale *might* have side-effects, for instance we noticed > before that heap profiling broke in some locales because the RTS code to > generate the .hp file was using fprintf to print numbers, and the number > format depends on the locale. You could avoid this by setting LC_CTYPE instead of LC_ALL. From igloo at earth.li Thu Mar 13 19:59:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 13 19:56:26 2008 Subject: ghc's trac is wedged In-Reply-To: <47D98F2D.1060501@gmail.com> References: <100FA60C-52DA-41F3-824A-07C0DB0F78A0@comcast.net> <47D98F2D.1060501@gmail.com> Message-ID: <20080313235924.GA26011@matrix.chaos.earth.li> On Thu, Mar 13, 2008 at 01:31:41PM -0700, Simon Marlow wrote: > Gregory Wright wrote: > > >This morning (13 March 2008) the ghc trac wedged reporting > > > >Trac detected an internal error: > > > >OperationalError: database is locked > > This happens from time to time for me too, usually it goes away with a > retry. I think it happens when the system load (especially high disk IO?) means that trac's attempt to grab some lock doesn't succeed in a certain amount of time. This morning 20GB of logs were being gzipped, so that was probably the cause. Thanks Ian From igloo at earth.li Thu Mar 13 20:05:18 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 13 20:02:19 2008 Subject: setlocale In-Reply-To: <20080313225224.GA15842@soi.city.ac.uk> References: <20080313213134.GA27623@doc.ic.ac.uk> <47D9AB49.9060901@gmail.com> <20080313225224.GA15842@soi.city.ac.uk> Message-ID: <20080314000518.GB26011@matrix.chaos.earth.li> On Thu, Mar 13, 2008 at 10:52:24PM +0000, Ross Paterson wrote: > On Thu, Mar 13, 2008 at 03:31:37PM -0700, Simon Marlow wrote: > > Setting the locale *might* have side-effects, for instance we noticed > > before that heap profiling broke in some locales because the RTS code to > > generate the .hp file was using fprintf to print numbers, and the number > > format depends on the locale. > > You could avoid this by setting LC_CTYPE instead of LC_ALL. It's probably best if we work correctly even if the user needs to set LC_CTYPE themselves for some reason, though. Thanks Ian From igloo at earth.li Thu Mar 13 20:19:16 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 13 20:16:17 2008 Subject: timer_create In-Reply-To: <47D02306.2010102@dfki.de> References: <47D02306.2010102@dfki.de> Message-ID: <20080314001916.GC26011@matrix.chaos.earth.li> Hi Christian, On Thu, Mar 06, 2008 at 05:59:50PM +0100, Christian Maeder wrote: > > #define HAVE_TIMER_CREATE 1 > > Or is there a work around (apart from creating a new binary-dist using > ghc-6.6.1)? I don't think using ghc 6.6.1 will make a difference. However, if you alter mk/config.h after running configure, so that it thinks it doesn't have timer_create, then you should get a bindist that works on older machines. I'm not sure why we have both HAVE_TIMER_CREATE and USE_TIMER_CREATE. Thanks Ian From ross at soi.city.ac.uk Thu Mar 13 20:21:38 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Mar 13 20:18:45 2008 Subject: setlocale In-Reply-To: <20080314000518.GB26011@matrix.chaos.earth.li> References: <20080313213134.GA27623@doc.ic.ac.uk> <47D9AB49.9060901@gmail.com> <20080313225224.GA15842@soi.city.ac.uk> <20080314000518.GB26011@matrix.chaos.earth.li> Message-ID: <20080314002137.GA17024@soi.city.ac.uk> On Fri, Mar 14, 2008 at 12:05:18AM +0000, Ian Lynagh wrote: > On Thu, Mar 13, 2008 at 10:52:24PM +0000, Ross Paterson wrote: > > On Thu, Mar 13, 2008 at 03:31:37PM -0700, Simon Marlow wrote: > > > Setting the locale *might* have side-effects, for instance we noticed > > > before that heap profiling broke in some locales because the RTS code to > > > generate the .hp file was using fprintf to print numbers, and the number > > > format depends on the locale. > > > > You could avoid this by setting LC_CTYPE instead of LC_ALL. > > It's probably best if we work correctly even if the user needs to set > LC_CTYPE themselves for some reason, though. I think you mean LC_NUMERIC. Setting LC_CTYPE won't affect printing numbers or collation, but it will enable character encoding, which is what the original poster was after. From igloo at earth.li Thu Mar 13 20:36:09 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 13 20:33:09 2008 Subject: setlocale In-Reply-To: <20080314002137.GA17024@soi.city.ac.uk> References: <20080313213134.GA27623@doc.ic.ac.uk> <47D9AB49.9060901@gmail.com> <20080313225224.GA15842@soi.city.ac.uk> <20080314000518.GB26011@matrix.chaos.earth.li> <20080314002137.GA17024@soi.city.ac.uk> Message-ID: <20080314003609.GD26011@matrix.chaos.earth.li> On Fri, Mar 14, 2008 at 12:21:38AM +0000, Ross Paterson wrote: > On Fri, Mar 14, 2008 at 12:05:18AM +0000, Ian Lynagh wrote: > > On Thu, Mar 13, 2008 at 10:52:24PM +0000, Ross Paterson wrote: > > > On Thu, Mar 13, 2008 at 03:31:37PM -0700, Simon Marlow wrote: > > > > Setting the locale *might* have side-effects, for instance we noticed > > > > before that heap profiling broke in some locales because the RTS code to > > > > generate the .hp file was using fprintf to print numbers, and the number > > > > format depends on the locale. > > > > > > You could avoid this by setting LC_CTYPE instead of LC_ALL. > > > > It's probably best if we work correctly even if the user needs to set > > LC_CTYPE themselves for some reason, though. > > I think you mean LC_NUMERIC. > > Setting LC_CTYPE won't affect printing numbers or collation, but it will > enable character encoding, which is what the original poster was after. Oh, right, I misunderstood you, but I see what you mean now. But it would be best if the RTS worked no matter what the user set (as far as is possible, anyway). Thanks Ian From Christian.Maeder at dfki.de Fri Mar 14 05:21:29 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Mar 14 05:18:29 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> <47D90BA4.3050805@dfki.de> Message-ID: <47DA4399.3040604@dfki.de> Hi Greg, I can't test it myself because I don't have root access to our machines. Maybe someone else can? (Meanwhile I'll try to make a binary-dist that includes the extra-libs.) Cheers Christian Gregory Wright wrote: > > Hi Christian, > > I built a new bootstrapping compiler on Tiger/ppc, incorporating > Thorkil's .text section > patch. I've modified the portfile, but since I don't have a Leopard/ppc > machine I can't > try it. Could you give it a go? > > Do > > $ sudo port selfupdate > $ sudo port clean --all ghc > $ sudo port -dv install ghc > inst.log 2>&1 > > You might want to check after the selfupdate that you have revision 2 of > the ghc portfile. > It may take a few hours for the server to index the port and make it > available by rsync. > > If it fails, you can compress the log and send it to me. The "-dv" > flags dump all of the > MacPorts and build information. > > There may still be a stupid bug or two since I can't test it myself. > > Thanks, > Greg > From Christian.Maeder at dfki.de Fri Mar 14 05:26:45 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Mar 14 05:23:47 2008 Subject: timer_create In-Reply-To: <20080314001916.GC26011@matrix.chaos.earth.li> References: <47D02306.2010102@dfki.de> <20080314001916.GC26011@matrix.chaos.earth.li> Message-ID: <47DA44D5.6070001@dfki.de> Ian Lynagh wrote: > Hi Christian, > > On Thu, Mar 06, 2008 at 05:59:50PM +0100, Christian Maeder wrote: >> #define HAVE_TIMER_CREATE 1 >> >> Or is there a work around (apart from creating a new binary-dist using >> ghc-6.6.1)? > > I don't think using ghc 6.6.1 will make a difference. At least our ghc-6.6.1 binary-dist works better, maybe because it was built with an older gcc. > However, if you alter mk/config.h after running configure, so that it > thinks it doesn't have timer_create, then you should get a bindist that > works on older machines. ok, thanks. > I'm not sure why we have both HAVE_TIMER_CREATE and USE_TIMER_CREATE. I'd like to know, too. Christian From simonmarhaskell at gmail.com Fri Mar 14 13:12:02 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Mar 14 13:09:23 2008 Subject: timer_create In-Reply-To: <47DA44D5.6070001@dfki.de> References: <47D02306.2010102@dfki.de> <20080314001916.GC26011@matrix.chaos.earth.li> <47DA44D5.6070001@dfki.de> Message-ID: <47DAB1E2.1080008@gmail.c