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.com> Christian Maeder wrote: > Ian Lynagh wrote: >> I'm not sure why we have both HAVE_TIMER_CREATE and USE_TIMER_CREATE. > > I'd like to know, too. It's because the configure script checks for more than just the existence of timer_create() (HAVE_TIMER_CREATE), it checks that it works well enough to use (USE_TIMER_CREATE). Historical versions of Linux had broken implementations of timer_create() that we need to avoid. Unfortunately this means that taking a GHC binary built on a newer Linux will not work on an older version. timer_create() is needed so that we can avoid needing to use the SIGALRM signal, which interferes with other things (there are previous tickets on this, a search for SIGALRM should turn them up). Cheers, Simon From Christian.Maeder at dfki.de Fri Mar 14 13:21:56 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Mar 14 13:18:56 2008 Subject: timer_create In-Reply-To: <47DAB1E2.1080008@gmail.com> References: <47D02306.2010102@dfki.de> <20080314001916.GC26011@matrix.chaos.earth.li> <47DA44D5.6070001@dfki.de> <47DAB1E2.1080008@gmail.com> Message-ID: <47DAB434.7000101@dfki.de> Simon Marlow wrote: > Unfortunately this means that taking a GHC binary built on a newer Linux > will not work on an older version. Do you know by chance which linux library (or rpm package) needs to be updated (if I run such an old version)? > timer_create() is needed so that we can avoid needing to use the SIGALRM > signal, which interferes with other things (there are previous tickets > on this, a search for SIGALRM should turn them up). Yes, Thanks Christian From john at repetae.net Fri Mar 14 13:28:31 2008 From: john at repetae.net (John Meacham) Date: Fri Mar 14 13:25:28 2008 Subject: Making rule application less fragile In-Reply-To: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> References: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> Message-ID: <20080314172831.GB30301@sliver.repetae.net> Note also that you are attaching your rule to 'fmap', however, since your rule only applies to the 'Parser' monad (if I am reading it properly) then 'fmap' will have been replaced by the 'fmap' in the Functor Parser instance. So you would probably be better off doing something like instance Functor Parser where fmap = parserFmap {-# RULES forall x . parserFmap S.pack ( ... Also, you have to be careful attaching rules to functions you don't define, as you don't know how it will interact with other rules, inline pragmas or whatnot that might already be attached to that function. John -- John Meacham - ?repetae.net?john? From Christian.Maeder at dfki.de Fri Mar 14 13:30:46 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Mar 14 13:27:44 2008 Subject: timer_create In-Reply-To: <47DAB434.7000101@dfki.de> References: <47D02306.2010102@dfki.de> <20080314001916.GC26011@matrix.chaos.earth.li> <47DA44D5.6070001@dfki.de> <47DAB1E2.1080008@gmail.com> <47DAB434.7000101@dfki.de> Message-ID: <47DAB646.1020801@dfki.de> Christian Maeder wrote: > Simon Marlow wrote: >> Unfortunately this means that taking a GHC binary built on a newer Linux >> will not work on an older version. > > Do you know by chance which linux library (or rpm package) needs to be > updated (if I run such an old version)? It seems to be glibc. Can this one be easily updated? Christian From johan.tibell at gmail.com Fri Mar 14 13:32:58 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Mar 14 13:29:58 2008 Subject: Making rule application less fragile In-Reply-To: <20080314172831.GB30301@sliver.repetae.net> References: <90889fe70803131147x255046a2nd8a5bf45742be5c5@mail.gmail.com> <20080314172831.GB30301@sliver.repetae.net> Message-ID: <90889fe70803141032q4d608360kaf3383c91bc34c7e@mail.gmail.com> On Fri, Mar 14, 2008 at 6:28 PM, John Meacham wrote: > Note also that you are attaching your rule to 'fmap', however, since > your rule only applies to the 'Parser' monad (if I am reading it > properly) then 'fmap' will have been replaced by the 'fmap' in the > Functor Parser instance. So you would probably be better off doing > something like > > instance Functor Parser where > fmap = parserFmap > > {-# RULES forall x . parserFmap S.pack ( ... Didn't think of that. I'll change my code accordingly. > Also, you have to be careful attaching rules to functions you don't > define, as you don't know how it will interact with other rules, inline > pragmas or whatnot that might already be attached to that function. Sounds like good advice. Thanks. From jason.dusek at gmail.com Sat Mar 15 03:32:29 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Mar 15 03:29:24 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: <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> Simon Marlow wrote: > GHC...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)... Why doesn't GHC know about const? -- _jsn From ross at soi.city.ac.uk Sat Mar 15 08:56:33 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Mar 15 08:53:36 2008 Subject: scope of header files In-Reply-To: <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> Message-ID: <20080315125633.GA2621@soi.city.ac.uk> On Sat, Mar 15, 2008 at 12:32:29AM -0700, Jason Dusek wrote: > Simon Marlow wrote: > > GHC...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)... > > Why doesn't GHC know about const? Because the Ptr type doesn't indicate const-ness (perhaps it should). From jason.dusek at gmail.com Sat Mar 15 14:55:38 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Mar 15 14:52:32 2008 Subject: scope of header files In-Reply-To: <20080315125633.GA2621@soi.city.ac.uk> 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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> Message-ID: <42784f260803151155s4780185fx1fc8201ea52d030b@mail.gmail.com> Ross Paterson wrote: > Jason Dusek wrote: > > Why doesn't GHC know about const? > > Because the Ptr type doesn't indicate const-ness (perhaps it > should). If it did, could we read constant strings without unsafePerformIO? -- _jsn From bulat.ziganshin at gmail.com Sat Mar 15 14:58:55 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 15 14:55:22 2008 Subject: scope of header files In-Reply-To: <42784f260803151155s4780185fx1fc8201ea52d030b@mail.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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> <42784f260803151155s4780185fx1fc8201ea52d030b@mail.gmail.com> Message-ID: <1951014340.20080315215855@gmail.com> Hello Jason, Saturday, March 15, 2008, 9:55:38 PM, you wrote: >> Because the Ptr type doesn't indicate const-ness (perhaps it >> should). > If it did, could we read constant strings without > unsafePerformIO? probably no; at least for getArgs it was argued that it should have IO return type because its result is different from run to run -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jason.dusek at gmail.com Sat Mar 15 15:08:31 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Mar 15 15:05:26 2008 Subject: scope of header files In-Reply-To: <1951014340.20080315215855@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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> <42784f260803151155s4780185fx1fc8201ea52d030b@mail.gmail.com> <1951014340.20080315215855@gmail.com> Message-ID: <42784f260803151208u6b8d02aerf38e828f55558d7@mail.gmail.com> Bulat Ziganshin wrote: > Saturday, March 15, 2008, 9:55:38 PM, you wrote: > > > ...the Ptr type doesn't indicate const-ness (perhaps it > > > should). > > > > If it did, could we read constant strings without > > unsafePerformIO? > > probably no; at least for getArgs it was argued that it should > have IO return type because its result is different from run > to run What does getArgs have to do with it? I'm assuming that reading n elements from a const array will always return the same elements -- is this an error? -- _jsn From bulat.ziganshin at gmail.com Sat Mar 15 15:12:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 15 15:08:31 2008 Subject: scope of header files In-Reply-To: <42784f260803151208u6b8d02aerf38e828f55558d7@mail.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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> <42784f260803151155s4780185fx1fc8201ea52d030b@mail.gmail.com> <1951014340.20080315215855@gmail.com> <42784f260803151208u6b8d02aerf38e828f55558d7@mail.gmail.com> Message-ID: <1694863665.20080315221204@gmail.com> Hello Jason, Saturday, March 15, 2008, 10:08:31 PM, you wrote: >> probably no; at least for getArgs it was argued that it should >> have IO return type because its result is different from run >> to run > What does getArgs have to do with it? > I'm assuming that reading n elements from a const array will > always return the same elements -- is this an error? like getArgs, it may return different values on different runs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jason.dusek at gmail.com Sat Mar 15 15:23:19 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Mar 15 15:20:14 2008 Subject: scope of header files In-Reply-To: <1694863665.20080315221204@gmail.com> References: <1204758974.11558.256.camel@localhost> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <47D6FDF9.6050404@gmail.com> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> <42784f260803151155s4780185fx1fc8201ea52d030b@mail.gmail.com> <1951014340.20080315215855@gmail.com> <42784f260803151208u6b8d02aerf38e828f55558d7@mail.gmail.com> <1694863665.20080315221204@gmail.com> Message-ID: <42784f260803151223n395aba17me92a62511e29af02@mail.gmail.com> Bulat Ziganshin wrote: > Saturday, March 15, 2008, 10:08:31 PM, you wrote: > > What does getArgs have to do with it? > > > > I'm assuming that reading n elements from a const array will > > always return the same elements -- is this an error? > > like getArgs, it may return different values on different runs Oh, I get it now. Even though it won't change for the life of a process, it can change each time the program is run. However, there is a difference with the array -- because it is statically linked into my Haskell program. Now, it's true that this can not be expected in general (though it's very common for Haskell). -- _jsn From prj at po.cwru.edu Sun Mar 16 00:05:03 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Sun Mar 16 00:02:02 2008 Subject: building against gmp in a nonstandard location Message-ID: I'm having some trouble building ghc against gmp installed in an unusual place. (Actually, I install every package in its own directory, but gmp seems to be the one causing trouble here.) First attempt: adding the necessary -I, -L, and -Xlinker -R options to CPPFLAGS/LDFLAGS when invoking ./configure, and I also created mk/build.mk to add the -I flags to SRC_CC_OPTS and SRC_HSC2HS_OPTS, and -optc-I, -optl-L, and -optl-Xlinker -optl-R flags to SRC_HC_OPTS. This method worked for ghc 6.6.1, but 6.8.2 gives me: /command/ghc -H16m -O -O2 -optc-I/nil -optc-I/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include -optc-I/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/ncurses/include -optc-I/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/readline/include -optc-I/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/binutils/include -optc-pipe -optl-pipe -optc-Os -optl-Os '-optc-march=pentium3' '-optl-march=pentium3' '-optc-mfpmath=sse' '-optl-mfpmath=sse' -optc-msse -optl-msse -optc-mmmx -optl-mmmx -optl-L/nil -optl-L/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/library -optl-L/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/ncurses/library -optl-L/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/readline/library -optl-L/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/binutils/library -optl-Xlinker -optl-R -optl-Xlinker -optl/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/library -optl-Xlinker -optl-R -optl-Xlinker -optl/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/ncurses/library -optl-Xlinker -optl-R -optl-Xlinker -optl/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/readline/library -optl-Xlinker -optl-R -optl-Xlinker -optl/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/binutils/library -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c stranal/StrictAnal.lhs -o stage1/stranal/StrictAnal.o -ohi stage1/stranal/StrictAnal.hi <> make[1]: *** No rule to make target `stage1//package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h', needed by `stage1/parser/cutils.o'. Stop. Second attempt: CPPFLAGS, LDFLAGS and mk/build.mk as above, and I also gave --with-gmp-{includes,libraries} to ./configure. This ends with the same error. Third attempt: all of the above, plus I modified mkdependC.prl to omit dependencies on absolute paths. (I suspect this is wrong, since I assume other people have successfully used gmp in a nonstandard path without having to patch anything, but anyway...) New failure: ../../compiler/stage1/ghc-inplace -Iinclude -package rts-1.0 -optc-O2 -odir dist/build -c cbits/longlong.c -o dist/build/cbits/longlong.o In file included from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/compile/src/ghc-6.8.2/includes/Stg.h:150, from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/compile/src/ghc-6.8.2/includes/Rts.h:19, from cbits/longlong.c:29:0: /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/compile/src/ghc-6.8.2/includes/Regs.h:28:17: error: gmp.h: No such file or directory I would have thought the SRC_HC_OPTS options I put in mk/build.mk would be used for this compilation, but apparently not. Does anyone see where the problem might be? paul From duncan.coutts at worc.ox.ac.uk Sun Mar 16 19:24:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 16 19:21:39 2008 Subject: timer_create In-Reply-To: <47DAB646.1020801@dfki.de> References: <47D02306.2010102@dfki.de> <20080314001916.GC26011@matrix.chaos.earth.li> <47DA44D5.6070001@dfki.de> <47DAB1E2.1080008@gmail.com> <47DAB434.7000101@dfki.de> <47DAB646.1020801@dfki.de> Message-ID: <1205709888.7594.8.camel@localhost> On Fri, 2008-03-14 at 18:30 +0100, Christian Maeder wrote: > Christian Maeder wrote: > > Simon Marlow wrote: > >> Unfortunately this means that taking a GHC binary built on a newer Linux > >> will not work on an older version. > > > > Do you know by chance which linux library (or rpm package) needs to be > > updated (if I run such an old version)? > > It seems to be glibc. Can this one be easily updated? Generally no. Every single application depends on glibc. On most binary distros upgrading glibc requires upgrading everything else (at least between major versions that add new features). Duncan From niklas.broberg at gmail.com Sun Mar 16 20:23:37 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Mar 16 20:20:27 2008 Subject: Bug or not-yet-supported? Message-ID: I haven't payed much attention to how much of type families is/should be implemented for 6.8.2. What of equality constraints? The following parses alright, but can't be used it seems. ------------------------------------ module Foo where class C a where proof :: a instance (a ~ Int) => C a where proof = 1 ------------------------------------ %> ghci -fglasgow-exts -XUndecidableInstances Foo.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, modules loaded: Foo. *Foo> proof :: Int : panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-mingw32): nameModule $dC{v aoz} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ------------------------------------ I would follow that last advice if I knew this was *supposed* to work. :-) Cheers, /Niklas From chak at cse.unsw.edu.au Sun Mar 16 21:13:26 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Mar 16 21:10:19 2008 Subject: Bug or not-yet-supported? In-Reply-To: References: Message-ID: <0DB14114-3860-4908-BB5C-6700EA13615E@cse.unsw.edu.au> Niklas Broberg: > I haven't payed much attention to how much of type families is/should > be implemented for 6.8.2. What of equality constraints? The following > parses alright, but can't be used it seems. > > ------------------------------------ > module Foo where > > class C a where > proof :: a > > instance (a ~ Int) => C a where > proof = 1 > ------------------------------------ > > %> ghci -fglasgow-exts -XUndecidableInstances Foo.hs > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Foo ( Foo.hs, interpreted ) > Ok, modules loaded: Foo. > *Foo> proof :: Int > : panic! (the 'impossible' happened) > (GHC version 6.8.2 for i386-unknown-mingw32): > nameModule $dC{v aoz} > > Please report this as a GHC bug: http://www.haskell.org/ghc/ > reportabug > > ------------------------------------ > I would follow that last advice if I knew this was *supposed* to > work. :-) It is supposed to work in 6.9. I am sorry, but type families are not an officially supported feature in 6.8.x, and hence, any bug fixes that requires invasive changes in the type checker will not be merged into the 6.8 branch (and by now the 6.8 and 6.9 code bases diverged quite a bit). This is simply to ensure the stability of the stable branch. Type families will be properly supported in 6.10. Manuel From rl at cse.unsw.edu.au Sun Mar 16 21:38:44 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sun Mar 16 21:35:40 2008 Subject: scope of header files In-Reply-To: <42784f260803151155s4780185fx1fc8201ea52d030b@mail.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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> <42784f260803151155s4780185fx1fc8201ea52d030b@mail.gmail.com> Message-ID: <47DDCBA4.2080401@cse.unsw.edu.au> Jason Dusek wrote: > Ross Paterson wrote: >> Jason Dusek wrote: >>> Why doesn't GHC know about const? >> Because the Ptr type doesn't indicate const-ness (perhaps it >> should). > > If it did, could we read constant strings without > unsafePerformIO? That would be unsound since a const pointer doesn't necessarily point to const data. Constness here only means that the data can't be modified through this particular pointer. Roman From niklas.broberg at gmail.com Mon Mar 17 07:45:11 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Mar 17 07:42:01 2008 Subject: Bug or not-yet-supported? In-Reply-To: <0DB14114-3860-4908-BB5C-6700EA13615E@cse.unsw.edu.au> References: <0DB14114-3860-4908-BB5C-6700EA13615E@cse.unsw.edu.au> Message-ID: > It is supposed to work in 6.9. I am sorry, but type families are not > an officially supported feature in 6.8.x, and hence, any bug fixes > that requires invasive changes in the type checker will not be merged > into the 6.8 branch (and by now the 6.8 and 6.9 code bases diverged > quite a bit). This is simply to ensure the stability of the stable > branch. Type families will be properly supported in 6.10. Oh, no worries, I'm in no hurry. I just wanted to know if this was something you were helped by knowing, but I suspected it was just as you say here. So I won't bother about a bug report, and will eagerly await 6.10. :-) /Niklas From john at repetae.net Mon Mar 17 11:46:48 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 11:43:36 2008 Subject: scope of header files In-Reply-To: <20080315125633.GA2621@soi.city.ac.uk> 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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> Message-ID: <20080317154648.GF5971@sliver.repetae.net> On Sat, Mar 15, 2008 at 12:56:33PM +0000, Ross Paterson wrote: > Because the Ptr type doesn't indicate const-ness (perhaps it should). Even many of the C people think adding const to the language was a bad idea.. for instance, is strchr(3) const char *strchr(const char *s, int c); or char *strchr(char *s, int c); ? both are useful, the C standard split the different and went with the equally incorrect char *strchr(const char *s, int c); In any case, 'const' is defined to not affect the calling convention at all for a function (in C, I am not sure if this is the case in C++) so there is no need to worry about it for the haskell FFI spec. John -- John Meacham - ?repetae.net?john? From haskell at list.mightyreason.com Mon Mar 17 16:12:20 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Mar 17 16:09:29 2008 Subject: Success report: Leopard powerpc In-Reply-To: <6BC05245-946C-443B-8C49-E8577311F99A@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> <47D90BA4.3050805@dfki.de> <6BC05245-946C-443B-8C49-E8577311F99A@comcast.net> Message-ID: <47DED0A4.9060103@list.mightyreason.com> I used both ghc-6.6.1 and macports to create a working ghc-6.8.2 on OS X 10.5.2 on a powerpc G4 laptop. From gwright at comcast.net Mon Mar 17 16:30:20 2008 From: gwright at comcast.net (Gregory Wright) Date: Mon Mar 17 16:27:28 2008 Subject: Success report: Leopard powerpc In-Reply-To: <47DED0A4.9060103@list.mightyreason.com> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> <47D90BA4.3050805@dfki.de> <6BC05245-946C-443B-8C49-E8577311F99A@comcast.net> <47DED0A4.9060103@list.mightyreason.com> Message-ID: Excellent news. Thanks to you and Christian for trying it out. -Greg On Mar 17, 2008, at 4:12 PM, Chris Kuklewicz wrote: > I used both ghc-6.6.1 and macports to create a working ghc-6.8.2 on > OS X 10.5.2 on a powerpc G4 laptop. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From alfonso.acosta at gmail.com Mon Mar 17 16:37:36 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Mar 17 16:34:25 2008 Subject: Success report: Leopard powerpc In-Reply-To: <47DED0A4.9060103@list.mightyreason.com> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> <47D90BA4.3050805@dfki.de> <6BC05245-946C-443B-8C49-E8577311F99A@comcast.net> <47DED0A4.9060103@list.mightyreason.com> Message-ID: <6a7c66fc0803171337g5b45ff4fp669768a173fa7366@mail.gmail.com> On 3/17/08, Chris Kuklewicz wrote: > I used both ghc-6.6.1 and macports to create a working ghc-6.8.2 on OS X 10.5.2 > on a powerpc G4 laptop. Great! It would be awsome if a PPC/Lepoard installation package was made available from GHC's page. From Christian.Maeder at dfki.de Tue Mar 18 05:58:27 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Mar 18 05:55:17 2008 Subject: Success report: Leopard powerpc In-Reply-To: <6a7c66fc0803171337g5b45ff4fp669768a173fa7366@mail.gmail.com> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> <47D90BA4.3050805@dfki.de> <6BC05245-946C-443B-8C49-E8577311F99A@comcast.net> <47DED0A4.9060103@list.mightyreason.com> <6a7c66fc0803171337g5b45ff4fp669768a173fa7366@mail.gmail.com> Message-ID: <47DF9243.3040601@dfki.de> Alfonso Acosta wrote: > It would be awsome if a PPC/Lepoard installation package was made > available from GHC's page. I can offer http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2 but also see http://hackage.haskell.org/trac/ghc/ticket/2031 I've also made a binary-dist that uses the GMP and GNUreadline frameworks http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.8.2-powerpc-apple-darwin-leopard.tar.bz2 I've tried to compile it on leopard to be useable on tiger, too, by using: SRC_HC_OPTS += -optc-isysroot -optc/Developer/SDKs/MacOSX10.4u.sdk -optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk -optl-macosx_version_min=10.4 -optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk But it still does not run under tiger. While it compiles and links on tiger, the dynamic linker complains when starting the binary (see below), although the symbol _alloc_blocks is part of the created binary (by inspecting it using "nm"). So, use the above binary-dists at your own risk. I've still no idea, what kind of libs for gmp and readline I should use: static ones, frameworks, or dylibs installed under /opt/local/lib (or possibly elsewhere) Cheers Christian bigmac:/local/home/maeder/haskell/uni maeder$ ghc --make -no-recomp Setup.hs [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... bigmac:/local/home/maeder/haskell/uni maeder$ ./Setup dyld: Symbol not found: _alloc_blocks Referenced from: /local/home/maeder/haskell/uni/./Setup Expected in: /usr/lib/libSystem.B.dylib Trace/BPT trap From jason.dusek at gmail.com Tue Mar 18 19:01:36 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Mar 18 18:58:20 2008 Subject: scope of header files In-Reply-To: <47DDCBA4.2080401@cse.unsw.edu.au> 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> <42784f260803150032x1dc6cb49qc7027e61e98a77fd@mail.gmail.com> <20080315125633.GA2621@soi.city.ac.uk> <42784f260803151155s4780185fx1fc8201ea52d030b@mail.gmail.com> <47DDCBA4.2080401@cse.unsw.edu.au> Message-ID: <42784f260803181601y4fa522f1x3eb5bb49ca5b73d2@mail.gmail.com> Roman Leshchinskiy wrote: > Constness here only means that the data can't be modified > through this particular pointer. Oh, I see. Thank you for clarifiying. I must always "bless" my constant arrays with `unsafePerformIO`. -- _jsn From bbr at informatik.uni-kiel.de Wed Mar 19 07:15:34 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Wed Mar 19 07:12:21 2008 Subject: Optimization beyond the Module Border Message-ID: <47E0F5D6.9040402@informatik.uni-kiel.de> Hi all, I have noticed that there is a great difference between optimizing modules separately and all at once, e.g., with -fforce-recomp. I have had examples factors up to 15 in run time (and even different behavior in context with unsafePerformIO). Is there any option that makes ghc write out that intermediate optimization data he seems to use in order to get the same efficiency in a module-wise compilation? Greetings Bernd From simonpj at microsoft.com Wed Mar 19 11:23:55 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 19 11:19:41 2008 Subject: Optimization beyond the Module Border In-Reply-To: <47E0F5D6.9040402@informatik.uni-kiel.de> References: <47E0F5D6.9040402@informatik.uni-kiel.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> | I have noticed that there is a great difference between optimizing | modules separately and all at once, e.g., with -fforce-recomp. I have | had examples factors up to 15 in run time (and even different behavior | in context with unsafePerformIO). GHC does a lot of cross-module inlining already, and *does* write stuff into interface files, provided you use -O. I'm always interested in performance differences of a factor of 15 though! Can you supply an example (as small as poss) for us to look at? Thanks Simon From bbr at informatik.uni-kiel.de Wed Mar 19 13:03:18 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Wed Mar 19 13:00:05 2008 Subject: Optimization beyond the Module Border In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47E14756.10007@informatik.uni-kiel.de> Simon Peyton-Jones wrote: > GHC does a lot of cross-module inlining already, and *does* write stuff into interface files, provided you use -O. I used -O4. Is that the bad thing? > I'm always interested in performance differences of a factor of 15 though! Can you supply an example (as small as poss) for us to look at? Yes certainly, although small will be a big problem, I guess. I admit that the factor 15 is a bit dubious since the fast run-time was so small (1.88 sec vs. 0.112 sec). I will see what I can do on the morrow. From dons at galois.com Wed Mar 19 13:20:12 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 19 13:16:55 2008 Subject: Optimization beyond the Module Border In-Reply-To: <47E14756.10007@informatik.uni-kiel.de> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> Message-ID: <20080319172012.GB9086@scytale.galois.com> bbr: > Simon Peyton-Jones wrote: > > > GHC does a lot of cross-module inlining already, and *does* write stuff into interface files, provided you use -O. > > I used -O4. Is that the bad thing? There's nothing about -O2 However, I think that's ok -- it clamps -ON | N>2 to -O2 > > I'm always interested in performance differences of a factor of 15 though! Can you supply an example (as small as poss) for us to look at? > > Yes certainly, although small will be a big problem, I guess. > I admit that the factor 15 is a bit dubious since the fast run-time was > so small (1.88 sec vs. 0.112 sec). > > I will see what I can do on the morrow. I'd be interested in any progress here -- we noticed issues with optimisations in the stream fusion package across module boundaries that we never tracked down. If there's some key things not firing, that would be good to know. From igloo at earth.li Wed Mar 19 13:31:08 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 19 13:27:49 2008 Subject: [GHC] #2163: GHC makes thunks for Integers we are strict in In-Reply-To: <053.c31478c8c9cbf73d2dee4bfe4f4061f1@localhost> References: <044.669eae6b361993c49cbaa68b68f5129a@localhost> <053.c31478c8c9cbf73d2dee4bfe4f4061f1@localhost> Message-ID: <20080319173107.GA16275@matrix.chaos.earth.li> On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote: > > > W.f = > > \ (x_a5h :: GHC.Num.Integer) -> > > let { > > x'_sa7 [ALWAYS Just S] :: GHC.Num.Integer > > [Str: DmdType] > > x'_sa7 = GHC.Num.plusInteger x_a5h W.lvl } in > > GHC.Num.timesInteger x'_sa7 x'_sa7 > > `let` can be strict in Core - it doesn't always indicate a thunk. Aha! I knew that let was strict for types like Int#, but didn't realise that it could be for "normal" types too. What is it in the above let that shows that it will be evaluated strictly? The "Just S"? Also, what is the advantage to having strictly evaluated let's, both for unboxed and normal types? Presumably it helps with some optimisation - perhaps let-bound things might be inlined, whereas case'd things aren't, which reduces the number of cases the optimiser needs to consider, or something? > (don't worry, this often catches me out too. Perhaps a strict let > should be indicated more explicitly in `-ddump-simpl`). I'd certainly find it useful if it was clearer. Thanks Ian From Malcolm.Wallace at cs.york.ac.uk Wed Mar 19 14:00:03 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Mar 19 14:06:30 2008 Subject: Optimization beyond the Module Border In-Reply-To: <20080319172012.GB9086@scytale.galois.com> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> Message-ID: <20080319180003.39d53df2.Malcolm.Wallace@cs.york.ac.uk> > I'd be interested in any progress here -- we noticed issues with > optimisations in the stream fusion package across module boundaries > that we never tracked down. If there's some key things not firing, > that would be good to know. I suspect that if all modules are compiled -O0, then you recompile one module with -O2, high up in the dependency graph (i.e. it depends on many lower-level modules), plus all things that in turn depend on it (--make), you will not get the good performance you expect. None of the lower-level functions will have exported inlinings or fusion rules into the interface file. _All_ modules must be recompiled with -O2, especially the bottom of the dependency chain, to get the best benefit from optimisation. Regards, Malcolm From conal at conal.net Wed Mar 19 17:11:35 2008 From: conal at conal.net (Conal Elliott) Date: Wed Mar 19 17:08:16 2008 Subject: Expected behavior of "deriving Ord"? Message-ID: I have an algebraic data type (not newtype) that derives Ord: data AddBounds a = MinBound | NoBound a | MaxBound deriving (Eq, Ord, Read, Show) I was hoping to get a min method defined in terms of the min method of the type argument (a). Instead, I think GHC is producing something in terms of compare or (<=). Maybe it's defaulting min altogether. What is the expected behavior in (a) the language standard and (b) GHC? The reason I care is that my type parameter a turns out to have partial information, specifically lower bounds. The type of min allows this partial info to be used in producing partial info about the result, while the type of (<=) and compare do not. Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080319/d0bfc1d8/attachment.htm From duncan.coutts at worc.ox.ac.uk Wed Mar 19 17:35:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 19 17:32:20 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: References: Message-ID: <1205962536.7594.102.camel@localhost> On Wed, 2008-03-19 at 14:11 -0700, Conal Elliott wrote: > I have an algebraic data type (not newtype) that derives Ord: > > data AddBounds a = MinBound | NoBound a | MaxBound > deriving (Eq, Ord, Read, Show) > > I was hoping to get a min method defined in terms of the min method of > the type argument (a). Instead, I think GHC is producing something in > terms of compare or (<=). Maybe it's defaulting min altogether. What > is the expected behavior in (a) the language standard and (b) GHC? The H98 report says: 10.1 Derived instances of Eq and Ord The class methods automatically introduced by derived instances of Eq and Ord are (==), (/=), compare, (<), (<=), (>), (>=), max, and min. The latter seven operators are defined so as to compare their arguments lexicographically with respect to the constructor set given, with earlier constructors in the datatype declaration counting as smaller than later ones. For example, for the Bool datatype, we have that (True > False) == True. Derived comparisons always traverse constructors from left to right. These examples illustrate this property: (1,undefined) == (2,undefined) => False (undefined,1) == (undefined,2) => _|_ All derived operations of class Eq and Ord are strict in both arguments. For example, False <= _|_ is _|_, even though False is the first constructor of the Bool type. Which doesn't seem to help but looking at the later example: 10.5 An Example As a complete example, consider a tree datatype: data Tree a = Leaf a | Tree a :^: Tree a deriving (Eq, Ord, Read, Show) Automatic derivation of instance declarations for Bounded and Enum are not possible, as Tree is not an enumeration or single-constructor datatype. The complete instance declarations for Tree are shown in Figure 10.1, Note the implicit use of default class method definitions---for example, only <= is defined for Ord, with the other class methods (<, >, >=, max, and min) being defined by the defaults given in the class declaration shown in Figure 6.1 (page ). So that is relying on the default class methods: max x y | x <= y = y | otherwise = x min x y | x <= y = x | otherwise = y As for GHC, Looking at the comments in compiler/typecheck/TcGenDeriv.lhs it says that it generates code that uses compare like so: max a b = case (compare a b) of { LT -> b; EQ -> a; GT -> a } min a b = case (compare a b) of { LT -> a; EQ -> b; GT -> b } > The reason I care is that my type parameter a turns out to have > partial information, specifically lower bounds. The type of min > allows this partial info to be used in producing partial info about > the result, while the type of (<=) and compare do not. So I suggest that you use an explicit Ord instance and define min/max the way you want. Duncan From conal at conal.net Wed Mar 19 18:01:12 2008 From: conal at conal.net (Conal Elliott) Date: Wed Mar 19 17:57:56 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: <1205962536.7594.102.camel@localhost> References: <1205962536.7594.102.camel@localhost> Message-ID: Thanks for the pointers. I'd found 10.1 but hadn't noticed 10.5. So I suggest that you use an explicit Ord instance and define min/max the > way you want. > Yep. That's my solution: instance Ord a => Ord (AddBounds a) where MinBound <= _ = True NoBound _ <= MinBound = False NoBound a <= NoBound b = a <= b NoBound _ <= MaxBound = True MaxBound <= MaxBound = True MaxBound <= _ = False MinBound `min` _ = MinBound _ `min` MinBound = MinBound NoBound a `min` NoBound b = NoBound (a `min` b) u `min` MaxBound = u MaxBound `min` v = v MinBound `max` v = v u `max` MinBound = u NoBound a `max` NoBound b = NoBound (a `max` b) _ `max` MaxBound = MaxBound MaxBound `max` _ = MaxBound Cheers, - Conal On Wed, Mar 19, 2008 at 2:35 PM, Duncan Coutts wrote: > > On Wed, 2008-03-19 at 14:11 -0700, Conal Elliott wrote: > > I have an algebraic data type (not newtype) that derives Ord: > > > > data AddBounds a = MinBound | NoBound a | MaxBound > > deriving (Eq, Ord, Read, Show) > > > > I was hoping to get a min method defined in terms of the min method of > > the type argument (a). Instead, I think GHC is producing something in > > terms of compare or (<=). Maybe it's defaulting min altogether. What > > is the expected behavior in (a) the language standard and (b) GHC? > > The H98 report says: > > 10.1 Derived instances of Eq and Ord > The class methods automatically introduced by derived instances > of Eq and Ord are (==), (/=), compare, (<), (<=), (>), (>=), > max, and min. The latter seven operators are defined so as to > compare their arguments lexicographically with respect to the > constructor set given, with earlier constructors in the datatype > declaration counting as smaller than later ones. For example, > for the Bool datatype, we have that (True > False) == True. > > Derived comparisons always traverse constructors from left to > right. These examples illustrate this property: > > (1,undefined) == (2,undefined) => False > (undefined,1) == (undefined,2) => _|_ > > All derived operations of class Eq and Ord are strict in both > arguments. For example, False <= _|_ is _|_, even though False > is the first constructor of the Bool type. > > Which doesn't seem to help but looking at the later example: > > 10.5 An Example > As a complete example, consider a tree datatype: > > data Tree a = Leaf a | Tree a :^: Tree a > deriving (Eq, Ord, Read, Show) > > Automatic derivation of instance declarations for Bounded and > Enum are not possible, as Tree is not an enumeration or > single-constructor datatype. The complete instance declarations > for Tree are shown in Figure 10.1, Note the implicit use of > default class method definitions---for example, only <= is > defined for Ord, with the other class methods (<, >, >=, max, > and min) being defined by the defaults given in the class > declaration shown in Figure 6.1 (page ). > > So that is relying on the default class methods: > > max x y | x <= y = y > | otherwise = x > min x y | x <= y = x > | otherwise = y > > As for GHC, Looking at the comments in compiler/typecheck/TcGenDeriv.lhs > it says that it generates code that uses compare like so: > > max a b = case (compare a b) of { LT -> b; EQ -> a; GT -> a } > min a b = case (compare a b) of { LT -> a; EQ -> b; GT -> b } > > > The reason I care is that my type parameter a turns out to have > > partial information, specifically lower bounds. The type of min > > allows this partial info to be used in producing partial info about > > the result, while the type of (<=) and compare do not. > > So I suggest that you use an explicit Ord instance and define min/max > the way you want. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080319/6f2e563e/attachment.htm From igloo at earth.li Wed Mar 19 19:49:48 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 19 19:46:28 2008 Subject: [GHC] #2163: GHC makes thunks for Integers we are strict in In-Reply-To: <20080319173107.GA16275@matrix.chaos.earth.li> References: <044.669eae6b361993c49cbaa68b68f5129a@localhost> <053.c31478c8c9cbf73d2dee4bfe4f4061f1@localhost> <20080319173107.GA16275@matrix.chaos.earth.li> Message-ID: <20080319234948.GA23944@matrix.chaos.earth.li> On Wed, Mar 19, 2008 at 05:31:08PM +0000, Ian Lynagh wrote: > On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote: > > > > (don't worry, this often catches me out too. Perhaps a strict let > > should be indicated more explicitly in `-ddump-simpl`). > > I'd certainly find it useful if it was clearer. In fact, simpl hides more than I'd realised. With these definitions: f :: Integer -> Integer -> Integer -> Integer f x y z | y == 1 = x * z | otherwise = f (x * x) y (z * z) g :: Integer -> Integer -> Integer -> Integer g x y z | y == 1 = x | otherwise = g (x * x) y (z * z) simpl shows B.f (GHC.Num.timesInteger x_a5B x_a5B) y_a5D (GHC.Num.timesInteger z_a5F z_a5F); and B.g (GHC.Num.timesInteger x_a74 x_a74) y_a76 (GHC.Num.timesInteger z_a78 z_a78); for the recursive calls, although in the STG you can see that the multiplication of z is done strictly in f but not g (which is correct, as g is not strict in z). So perhaps the solution is just that I should look at the STG rather than the simpl when I want to see what's going on. Thanks Ian From dons at galois.com Wed Mar 19 19:51:53 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 19 19:48:35 2008 Subject: [GHC] #2163: GHC makes thunks for Integers we are strict in In-Reply-To: <20080319234948.GA23944@matrix.chaos.earth.li> References: <044.669eae6b361993c49cbaa68b68f5129a@localhost> <053.c31478c8c9cbf73d2dee4bfe4f4061f1@localhost> <20080319173107.GA16275@matrix.chaos.earth.li> <20080319234948.GA23944@matrix.chaos.earth.li> Message-ID: <20080319235153.GI9924@scytale.galois.com> igloo: > On Wed, Mar 19, 2008 at 05:31:08PM +0000, Ian Lynagh wrote: > > On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote: > > > > > > (don't worry, this often catches me out too. Perhaps a strict let > > > should be indicated more explicitly in `-ddump-simpl`). > > > > I'd certainly find it useful if it was clearer. > > In fact, simpl hides more than I'd realised. With these definitions: > > f :: Integer -> Integer -> Integer -> Integer > f x y z | y == 1 = x * z > | otherwise = f (x * x) y (z * z) > > g :: Integer -> Integer -> Integer -> Integer > g x y z | y == 1 = x > | otherwise = g (x * x) y (z * z) > > simpl shows > > B.f (GHC.Num.timesInteger x_a5B x_a5B) y_a5D > (GHC.Num.timesInteger z_a5F z_a5F); > > and > > B.g (GHC.Num.timesInteger x_a74 x_a74) y_a76 > (GHC.Num.timesInteger z_a78 z_a78); > > for the recursive calls, although in the STG you can see that the > multiplication of z is done strictly in f but not g (which is correct, > as g is not strict in z). > > So perhaps the solution is just that I should look at the STG rather > than the simpl when I want to see what's going on. > > > Thanks We really need an official and blessed view of the optimised core, with full, relevant information, in human readable form. Just simplifiying the obvious qualified names would be a start, and some simple alpha renaming. -- Don From bdonlan at gmail.com Thu Mar 20 02:38:56 2008 From: bdonlan at gmail.com (Bryan Donlan) Date: Thu Mar 20 02:35:35 2008 Subject: Bug: GHC hangs rather than reporting an occurs check error Message-ID: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> Hi all, I've found a case where GHC will hang (consuming more and more memory) when it should report an occurs check error. The test case is at http://fushizen.net/~bd/kaos-ghc.loop.tgz - the error in question is that the arguments in the StateT instance for HOLift are reversed like so: diff --git a/src/Kaos/KaosM.hs b/src/Kaos/KaosM.hs index ec4e69a..268250a 100644 --- a/src/Kaos/KaosM.hs +++ b/src/Kaos/KaosM.hs @@ -88,7 +88,7 @@ genlift' unbox box f m = box $ \s -> f (unbox m s) class HOLift m b | m -> b where genlift :: (forall r'. b r' -> b r') -> (forall r. m r -> m r) -instance HOLift m (StateT s m) where +instance HOLift (StateT s m) m where genlift = genlift' runStateT StateT instance (HOLift m b, KaosDiagM r b) => KaosDiagM r m where Thanks, Bryan Donlan From bdonlan at gmail.com Thu Mar 20 02:39:27 2008 From: bdonlan at gmail.com (Bryan Donlan) Date: Thu Mar 20 02:36:07 2008 Subject: Bug: GHC hangs rather than reporting an occurs check error In-Reply-To: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> References: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> Message-ID: <3e8340490803192339s5e4a843es89ef3d7d83ca4cee@mail.gmail.com> On Thu, Mar 20, 2008 at 2:38 AM, Bryan Donlan wrote: > Hi all, > > I've found a case where GHC will hang (consuming more and more memory) > when it should report an occurs check error. The test case is at > http://fushizen.net/~bd/kaos-ghc.loop.tgz - the error in question is > that the arguments in the StateT instance for HOLift are reversed like so: Forgot to mention this, but I'm using GHC 6.8.2 on ubuntu hardy. From bbr at informatik.uni-kiel.de Thu Mar 20 04:47:28 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Mar 20 04:44:16 2008 Subject: Optimization beyond the Module Border In-Reply-To: <20080319172012.GB9086@scytale.galois.com> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> Message-ID: <47E224A0.1020000@informatik.uni-kiel.de> > I suspect that if all modules are compiled -O0, then you recompile one > module with -O2, high up in the dependency graph (i.e. it depends on > many lower-level modules), plus all things that in turn depend on it > (--make), you will not get the good performance you expect. None of the > lower-level functions will have exported inlinings or fusion rules into > the interface file. _All_ modules must be recompiled with -O2, > especially the bottom of the dependency chain, to get the best benefit > from optimisation. > > Regards, > Malcolm I am very sorry, I think what Malcolm describes might be exactly what had happened. Now that I tried to blow up the example from 0.122 msec to get a more significant result, I can't reproduce the effect. Funny thing though, as I was pretty keen on doing a thorough job as it was all about measuring the quality of the work of the previous fortnight. Now I find that - after all - I did a much better job than it seemed yesterday :o) So there may be two (minor) issues left if you would be interested. Firstly, about profiling in connection with optimization. When I compiled things with -O2 AND -prof -auto-all no profile would be written. Now you might think that having both at once is a silly idea, the side effects of profiling might be the first to be "optimized" away. But I think it was not so silly after all as I had introduced a lot of overhead into my programs which I was pretty sure could be optimized away. Hence, I was not at all interested in the unoptimized profile. And I think it is not so unusual to want to improve only those things that the compiler cannot improve by itself. Couldn't the profiling things be added AFTER all optimization was done? And then, secondly, about the connection of optimization with side effects. I had programs behave differently when compiling them all in one go or module-wise. (And if I am not able to reproduce that effect as well I will do a little merry dance!) Is this also interesting? Might it be connected with what Don mentioned about the stream fusion package? (Although I cannot remember mentioning any side effects in Duncan's talk in Freiburg.) Thanks for your time and sorry once again for using the system all wrong! Bernd From simonpj at microsoft.com Thu Mar 20 05:00:25 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 20 04:57:14 2008 Subject: Optimization beyond the Module Border In-Reply-To: <20080319180003.39d53df2.Malcolm.Wallace@cs.york.ac.uk> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> <20080319180003.39d53df2.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A1460C@EA-EXMSG-C334.europe.corp.microsoft.com> | > I'd be interested in any progress here -- we noticed issues with | > optimisations in the stream fusion package across module boundaries | > that we never tracked down. If there's some key things not firing, | > that would be good to know. | | I suspect that if all modules are compiled -O0, then you recompile one | module with -O2, high up in the dependency graph (i.e. it depends on | many lower-level modules), plus all things that in turn depend on it | (--make), you will not get the good performance you expect. None of the | lower-level functions will have exported inlinings or fusion rules into | the interface file. _All_ modules must be recompiled with -O2, | especially the bottom of the dependency chain, to get the best benefit | from optimisation. Absolutely correct. Should this be better documented? If so, would someone like to think where in GHC's user manual they would have looked (or did look), and send me some text that would have helped them, had it been there? As it were. Simon From Christian.Maeder at dfki.de Thu Mar 20 05:00:30 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 20 04:57:15 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: References: Message-ID: <47E227AE.3080305@dfki.de> Conal Elliott wrote: > I have an algebraic data type (not newtype) that derives Ord: > > data AddBounds a = MinBound | NoBound a | MaxBound > deriving (Eq, Ord, Read, Show) The class Ord is not suited for partial orders. If you write your own Ord instances anyway, I'd suggest to introduce a proper new class (say Lattice), too! I hope that the computation of "uncomparable" does terminate in your case. Maybe the lattice operation "join and "meet" are even more appropriate than "min" and "max". However, if your type parameter "a" has a total order, the above derived instance looks correct. HTH Christian From igloo at earth.li Thu Mar 20 10:17:51 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 20 10:14:29 2008 Subject: Optimization beyond the Module Border In-Reply-To: <47E224A0.1020000@informatik.uni-kiel.de> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> <47E224A0.1020000@informatik.uni-kiel.de> Message-ID: <20080320141751.GA22737@matrix.chaos.earth.li> On Thu, Mar 20, 2008 at 09:47:28AM +0100, Bernd Brassel wrote: > > compiled things with -O2 AND -prof -auto-all no profile would be > written. This should work, for the reasons that you give. Did you use options like +RTS -p when running the program? If so, please give us an example to reproduce the problem. > And then, secondly, about the connection of optimization with side > effects. I had programs behave differently when compiling them all in > one go or module-wise. Again, please tell us how to reproduce this. Thanks Ian From igloo at earth.li Thu Mar 20 10:31:10 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 20 10:27:49 2008 Subject: building against gmp in a nonstandard location In-Reply-To: References: Message-ID: <20080320143110.GB22737@matrix.chaos.earth.li> Hi Paul, On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote: > > make[1]: *** No rule to make target `stage1//package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h', needed by `stage1/parser/cutils.o'. Stop. Where is gmp.h actually installed? Do you know where this dependency is coming from? Is it compiler/.depend-1? If so, try looking at the mkdependC commandline and see if that provides any clues. > Second attempt: CPPFLAGS, LDFLAGS and mk/build.mk as above, and I also > gave --with-gmp-{includes,libraries} to ./configure. This ends with > the same error. What happens if you only use the flags? > Third attempt: all of the above, plus I modified mkdependC.prl to omit > dependencies on absolute paths. (I suspect this is wrong, since I > assume other people have successfully used gmp in a nonstandard path > without having to patch anything, but anyway...) New failure: > > ../../compiler/stage1/ghc-inplace -Iinclude -package rts-1.0 -optc-O2 -odir dist/build -c cbits/longlong.c -o dist/build/cbits/longlong.o > In file included from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/compile/src/ghc-6.8.2/includes/Stg.h:150, > from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/compile/src/ghc-6.8.2/includes/Rts.h:19, > from cbits/longlong.c:29:0: > /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/compile/src/ghc-6.8.2/includes/Regs.h:28:17: > error: gmp.h: No such file or directory > > I would have thought the SRC_HC_OPTS options I put in mk/build.mk > would be used for this compilation, but apparently not. Does anyone > see where the problem might be? This is compiling a C file, so it uses SRC_CC_OPTS instead. Thanks Ian From matthew.pocock at ncl.ac.uk Thu Mar 20 10:42:24 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Thu Mar 20 10:39:09 2008 Subject: Optimization beyond the Module Border In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A1460C@EA-EXMSG-C334.europe.corp. microsoft.com> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> <20080319180003.39d53df2.Malcolm.Wallace@cs.york.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A1460C@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <41335.128.240.229.65.1206024144.squirrel@webmail.ncl.ac.uk> > | > I'd be interested in any progress here -- we noticed issues with > | > optimisations in the stream fusion package across module boundaries > | > that we never tracked down. If there's some key things not firing, > | > that would be good to know. > | > | I suspect that if all modules are compiled -O0, then you recompile one > | module with -O2, high up in the dependency graph (i.e. it depends on > | many lower-level modules), plus all things that in turn depend on it > | (--make), you will not get the good performance you expect. None of the > | lower-level functions will have exported inlinings or fusion rules into > | the interface file. _All_ modules must be recompiled with -O2, > | especially the bottom of the dependency chain, to get the best benefit > | from optimisation. > > Absolutely correct. > > Should this be better documented? If so, would someone like to think > where in GHC's user manual they would have looked (or did look), and send > me some text that would have helped them, had it been there? As it were. > > Simon Would it be possible for the compiler to say something like: "You are applying level 2 optimization but some dependencies where compiled without optimization enabled. To get full optimization, consider recompiling x,y,z with -O2" - at least this would give us a fighting chance to 'fix' things. Matthew > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From igloo at earth.li Thu Mar 20 10:43:58 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 20 10:40:37 2008 Subject: Bug: GHC hangs rather than reporting an occurs check error In-Reply-To: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> References: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> Message-ID: <20080320144358.GC22737@matrix.chaos.earth.li> On Thu, Mar 20, 2008 at 02:38:56AM -0400, Bryan Donlan wrote: > > http://fushizen.net/~bd/kaos-ghc.loop.tgz This gives me "403 Forbidden". Thanks Ian From conal at conal.net Thu Mar 20 13:28:26 2008 From: conal at conal.net (Conal Elliott) Date: Thu Mar 20 13:25:07 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: <47E227AE.3080305@dfki.de> References: <47E227AE.3080305@dfki.de> Message-ID: AddBounds makes total orders from total orders. It just adds new least and greatest elements. The problem with the derived instance is that it doesn't exploit the potential laziness of min on 'a'. Because of their types, min it can produce partial info from partial info and (<=) and compares cannot. - Conal On Thu, Mar 20, 2008 at 2:00 AM, Christian Maeder wrote: > Conal Elliott wrote: > > I have an algebraic data type (not newtype) that derives Ord: > > > > data AddBounds a = MinBound | NoBound a | MaxBound > > deriving (Eq, Ord, Read, Show) > > The class Ord is not suited for partial orders. If you write your own > Ord instances anyway, I'd suggest to introduce a proper new class (say > Lattice), too! > > I hope that the computation of "uncomparable" does terminate in your > case. Maybe the lattice operation "join and "meet" are even more > appropriate than "min" and "max". > > However, if your type parameter "a" has a total order, the above derived > instance looks correct. > > HTH Christian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080320/d2ea114e/attachment-0001.htm From prj at po.cwru.edu Thu Mar 20 13:29:26 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Thu Mar 20 13:26:10 2008 Subject: building against gmp in a nonstandard location In-Reply-To: <20080320143110.GB22737@matrix.chaos.earth.li> (Ian Lynagh's message of "Thu\, 20 Mar 2008 14\:31\:10 +0000") References: <20080320143110.GB22737@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote: >> make[1]: *** No rule to make target `stage1//package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h', needed by `stage1/parser/cutils.o'. Stop. > > Where is gmp.h actually installed? /package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h > Do you know where this dependency is coming from? Is it > compiler/.depend-1? Yes, and .depend-BASE before that. The only difference in .depend-1 is that "stage1/" is prepended. compiler/parser/cutils.c includes includes/Rts.h, which includes gmp.h. So mkdependC puts that information in .depend-BASE. I'm sure it doesn't belong there, since gmp.h isn't part of the GHC source tree, and I guess if it works for other people, then it must not be there for them (can anyone confirm that?), but I don't see how it gets filtered out for them. >> Second attempt: CPPFLAGS, LDFLAGS and mk/build.mk as above, and I also >> gave --with-gmp-{includes,libraries} to ./configure. This ends with >> the same error. > > What happens if you only use the flags? Do you mean CPPFLAGS and LDFLAGS, without putting anything in mk/build.mk or specifying --with-gmp-*? That fails here: Creating ghcplatform.h... Done. ../utils/mkdependC/mkdependC -f .depend -- -O -DTABLES_NEXT_TO_CODE -I. -I../rts -- mkDerivedConstants.c gcc -O -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -o mkDerivedConstants.o In file included from Stg.h:150, from Rts.h:19, from mkDerivedConstants.c:23: Regs.h:28:17: error: gmp.h: No such file or directory In file included from Stg.h:150, from Rts.h:19, from mkDerivedConstants.c:23: Regs.h:121: error: expected specifier-qualifier-list before 'MP_INT' In file included from mkDerivedConstants.c:23: Rts.h:203: error: expected ')' before '*' token Rts.h:204: error: expected ')' before '*' token mkDerivedConstants.c: In function 'main': mkDerivedConstants.c:218: error: 'StgRegTable' has no member named 'rRet' mkDerivedConstants.c:218: error: 'StgRegTable' has no member named 'rRet' mkDerivedConstants.c:222: error: 'StgRegTable' has no member named 'rmp_tmp1' mkDerivedConstants.c:223: error: 'StgRegTable' has no member named 'rmp_tmp2' mkDerivedConstants.c:224: error: 'StgRegTable' has no member named 'rmp_result1' mkDerivedConstants.c:225: error: 'StgRegTable' has no member named 'rmp_result2' mkDerivedConstants.c:417: error: 'MP_INT' undeclared (first use in this function) mkDerivedConstants.c:417: error: (Each undeclared identifier is reported only once mkDerivedConstants.c:417: error: for each function it appears in.) mkDerivedConstants.c:418: error: expected expression before ')' token mkDerivedConstants.c:418: error: expected expression before ')' token mkDerivedConstants.c:419: error: expected expression before ')' token mkDerivedConstants.c:419: error: expected expression before ')' token mkDerivedConstants.c:420: error: expected expression before ')' token mkDerivedConstants.c:420: error: expected expression before ')' token mkDerivedConstants.c:422: error: 'mp_limb_t' undeclared (first use in this function) make[1]: *** [mkDerivedConstants.o] Error 1 make: *** [stage1] Error 1 > This is compiling a C file, so it uses SRC_CC_OPTS instead. Actually, it would be GHC_CC_OPTS, since it's ghc compiling a C file, right? I tried adding the -optc-I flags, etc., to GHC_CC_OPTS in mk/build.mk, and it gets farther now, but still fails: Configuring hpc-0.5.0.0... rm -f hpc/GNUmakefile cp Makefile.local hpc if ifBuildable/ifBuildable hpc; then \ cd hpc && setup/Setup makefile -f GNUmakefile; \ fi In file included from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+3/compile/src/ghc-6.8.2/includes/Stg.h:150, from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+3/compile/src/ghc-6.8.2/includes/Rts.h:19, from Reflect.hsc:18: /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+3/compile/src/ghc-6.8.2/includes/Regs.h:28:17: error: gmp.h: No such file or directory This seems to be coming from an invocation of hsc2hs for dependency generation. I don't know how to add extra options to that invocation, since it isn't directly in any of the Makefiles. But if it works for everyone else, I shouldn't need to, either... paul From dons at galois.com Thu Mar 20 13:39:05 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 20 13:35:45 2008 Subject: Optimization beyond the Module Border In-Reply-To: <47E224A0.1020000@informatik.uni-kiel.de> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> <47E224A0.1020000@informatik.uni-kiel.de> Message-ID: <20080320173905.GA15505@scytale.galois.com> bbr: > > I suspect that if all modules are compiled -O0, then you recompile one > > module with -O2, high up in the dependency graph (i.e. it depends on > > many lower-level modules), plus all things that in turn depend on it > > (--make), you will not get the good performance you expect. None of the > > lower-level functions will have exported inlinings or fusion rules into > > the interface file. _All_ modules must be recompiled with -O2, > > especially the bottom of the dependency chain, to get the best benefit > > from optimisation. > > > > Regards, > > Malcolm > > I am very sorry, I think what Malcolm describes might be exactly what > had happened. Now that I tried to blow up the example from 0.122 msec to > get a more significant result, I can't reproduce the effect. Funny thing > though, as I was pretty keen on doing a thorough job as it was all about > measuring the quality of the work of the previous fortnight. Now I find > that - after all - I did a much better job than it seemed yesterday :o) > > So there may be two (minor) issues left if you would be interested. > Firstly, about profiling in connection with optimization. When I > compiled things with -O2 AND -prof -auto-all no profile would be > written. Now you might think that having both at once is a silly idea, > the side effects of profiling might be the first to be "optimized" away. You almost always want to profile with full optimisations on. Otherwise its not even close to measuring the kind of code you're actually running. > But I think it was not so silly after all as I had introduced a lot of > overhead into my programs which I was pretty sure could be optimized > away. Hence, I was not at all interested in the unoptimized profile. And > I think it is not so unusual to want to improve only those things that > the compiler cannot improve by itself. Couldn't the profiling things be > added AFTER all optimization was done? > > And then, secondly, about the connection of optimization with side > effects. I had programs behave differently when compiling them all in > one go or module-wise. (And if I am not able to reproduce that effect as > well I will do a little merry dance!) Is this also interesting? Might it > be connected with what Don mentioned about the stream fusion package? > (Although I cannot remember mentioning any side effects in Duncan's talk > in Freiburg.) No, I can't think of any issue there. -- Don From bbr at informatik.uni-kiel.de Thu Mar 20 13:49:44 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Mar 20 13:46:29 2008 Subject: Optimization beyond the Module Border In-Reply-To: <20080320173905.GA15505@scytale.galois.com> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> <47E224A0.1020000@informatik.uni-kiel.de> <20080320173905.GA15505@scytale.galois.com> Message-ID: <47E2A3B8.5080003@informatik.uni-kiel.de> Don Stewart wrote: > You almost always want to profile with full optimisations on. > Otherwise its not even close to measuring the kind of code you're > actually running. Ian Lynagh wrote: > This should work, for the reasons that you give. Did you use options > like +RTS -p when running the program? Yes guys, you are sooo right... And I think it is really time for the easter holidays! Not that I forgot to turn on the RTS option but something close to as stupid if not worse: I looked into the wrong file. :o(( My gosh, before I stay to get the trophy of the most stupid mail of the list, I think I will go home now... Have a happy Easter! Bernd From Christian.Maeder at dfki.de Thu Mar 20 14:00:46 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 20 13:57:26 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: References: <47E227AE.3080305@dfki.de> Message-ID: <47E2A64E.6030700@dfki.de> Conal Elliott wrote: > AddBounds makes total orders from total orders. It just adds new least > and greatest elements. > > The problem with the derived instance is that it doesn't exploit the > potential laziness of min on 'a'. Because of their types, min it can > produce partial info from partial info and (<=) and compares cannot. Right, I've mixed up partial orders, partial (infinite?) values as input to total order functions. I could not construct an example, though. min (NoBound MinBound) (NoBound (NoBound undefined)) worked using ghci. Cheers Christian From conal at conal.net Thu Mar 20 14:14:28 2008 From: conal at conal.net (Conal Elliott) Date: Thu Mar 20 14:11:07 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: <47E2A64E.6030700@dfki.de> References: <47E227AE.3080305@dfki.de> <47E2A64E.6030700@dfki.de> Message-ID: Oh -- partial & partial. Thanks. I was pretty puzzled there. The type argument I ran into trouble with represents a value as a list of increasing lower bounds, ending in the exact value. min produces lower bounds from lower bounds and so is immediately productive before even knowing which argument is the lesser one. (<=) returns Bool, and so cannot produce any partial information. Unfortunately, the derived Ord instance omits min which therefore defaults to a definition in terms of (<=), which therefore cannot produce partial 'a' info. - Conal Some references on "improving values": @Article{Burton91:Encapsulating, author = {F. Warren Burton}, title = {Encapsulating nondeterminacy in an abstract data type with deterministic semantics}, journal = {Journal of Functional Programming}, year = 1991, volume = 1, number = 1, pages = {3--20}, month = {January} } @inproceedings{Burton89:Indeterminate, author = {F. Warren Burton}, title = {Indeterminate behavior with determinate semantics in parallel programs}, booktitle = {FPCA '89: Proceedings of the fourth international conference on Functional programming languages and computer architecture}, year = {1989}, isbn = {0-89791-328-0}, pages = {340--346}, location = {Imperial College, London, United Kingdom}, doi = {http://doi.acm.org/10.1145/99370.99402}, publisher = {ACM}, address = {New York, NY, USA}, } On Thu, Mar 20, 2008 at 11:00 AM, Christian Maeder wrote: > Conal Elliott wrote: > > AddBounds makes total orders from total orders. It just adds new least > > and greatest elements. > > > > The problem with the derived instance is that it doesn't exploit the > > potential laziness of min on 'a'. Because of their types, min it can > > produce partial info from partial info and (<=) and compares cannot. > > Right, I've mixed up partial orders, partial (infinite?) values as input > to total order functions. I could not construct an example, though. > > min (NoBound MinBound) (NoBound (NoBound undefined)) > > worked using ghci. > > Cheers Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080320/9c4b393c/attachment.htm From quuxman at gmail.com Thu Mar 20 16:07:55 2008 From: quuxman at gmail.com (ac) Date: Thu Mar 20 16:04:32 2008 Subject: Type checking of partial programs Message-ID: Is anybody interested in working on this? This is a project I've been interested in for some time, but recognize I probably need some guidance before I go off and start hacking on it. As dcoutts pointed out on #haskell-soc, this may be of particular interest to people working on yi and HaRe. Other interesting and related projects include parsing partial programs to insert "placeholders" in appropriate places. An example of a partial program could be: foo :: [Foo] -> foo xs = map xs What are the possible type signatures for placeholder 1 and the possible expressions for placeholder 2? I would like to stir up a discussion about this, and eventually write some useful code. -Abram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080320/16722128/attachment-0001.htm From igloo at earth.li Thu Mar 20 16:11:27 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 20 16:08:05 2008 Subject: building against gmp in a nonstandard location In-Reply-To: References: <20080320143110.GB22737@matrix.chaos.earth.li> Message-ID: <20080320201127.GA7181@matrix.chaos.earth.li> On Thu, Mar 20, 2008 at 01:29:26PM -0400, Paul Jarc wrote: > Ian Lynagh wrote: > > On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote: > > >> Second attempt: CPPFLAGS, LDFLAGS and mk/build.mk as above, and I also > >> gave --with-gmp-{includes,libraries} to ./configure. This ends with > >> the same error. > > > > What happens if you only use the flags? > > Do you mean CPPFLAGS and LDFLAGS, without putting anything in > mk/build.mk or specifying --with-gmp-*? That fails here: Sorry, I meant --with-gmp-{includes,libraries}. > if ifBuildable/ifBuildable hpc; then \ > cd hpc && setup/Setup makefile -f GNUmakefile; \ > fi > In file included from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+3/compile/src/ghc-6.8.2/includes/Stg.h:150, > from /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+3/compile/src/ghc-6.8.2/includes/Rts.h:19, > from Reflect.hsc:18: > /fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+3/compile/src/ghc-6.8.2/includes/Regs.h:28:17: error: gmp.h: No such file or directory > > This seems to be coming from an invocation of hsc2hs I think this is something we fixed in the 6.8 darcs branch since releasing 6.8.2. Try building a recent 6.8 branch snapshot instead: http://www.haskell.org/ghc/dist/stable/dist/ Thanks Ian From bdonlan at gmail.com Thu Mar 20 16:13:07 2008 From: bdonlan at gmail.com (Bryan Donlan) Date: Thu Mar 20 16:09:47 2008 Subject: Bug: GHC hangs rather than reporting an occurs check error In-Reply-To: <20080320144358.GC22737@matrix.chaos.earth.li> References: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> <20080320144358.GC22737@matrix.chaos.earth.li> Message-ID: <3e8340490803201313j3c115e8co73ee09d833ce67cd@mail.gmail.com> On Thu, Mar 20, 2008 at 10:43 AM, Ian Lynagh wrote: > On Thu, Mar 20, 2008 at 02:38:56AM -0400, Bryan Donlan wrote: > > > > http://fushizen.net/~bd/kaos-ghc.loop.tgz > > This gives me "403 Forbidden". Er, typo: http://fushizen.net/~bd/kaos-ghc-loop.tgz From igloo at earth.li Thu Mar 20 16:39:10 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 20 16:35:54 2008 Subject: Bug: GHC hangs rather than reporting an occurs check error In-Reply-To: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> References: <3e8340490803192338s3fa59600g348276a8d68c9715@mail.gmail.com> Message-ID: <20080320203910.GA9805@matrix.chaos.earth.li> On Thu, Mar 20, 2008 at 02:38:56AM -0400, Bryan Donlan wrote: > > I've found a case where GHC will hang (consuming more and more memory) > when it should report an occurs check error. The test case is at > http://fushizen.net/~bd/kaos-ghc.loop.tgz - the error in question is > that the arguments in the StateT instance for HOLift are reversed like > so: > > -instance HOLift m (StateT s m) where > +instance HOLift (StateT s m) m where I haven't looked at this in detail, but you have enabled the UndecidableInstances extension, so it's not necessarily a bug if the type checker goes into a loop. Thanks Ian From prj at po.cwru.edu Fri Mar 21 01:44:37 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Fri Mar 21 01:41:16 2008 Subject: building against gmp in a nonstandard location In-Reply-To: <20080320201127.GA7181@matrix.chaos.earth.li> (Ian Lynagh's message of "Thu\, 20 Mar 2008 20\:11\:27 +0000") References: <20080320143110.GB22737@matrix.chaos.earth.li> <20080320201127.GA7181@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > Sorry, I meant --with-gmp-{includes,libraries}. Ah, ok. --with-gmp-* alone, without setting environment variables, creating mk/build.mk, or anything else, gives the same error as --with-gmp-* plus environment variables ("No rule to make target `stage1//.../gmp.h', needed by `stage1/parser/cutils.o'.") Trying 6.8.2.20080317, using --with-ghc-*, setting environment variables, creating mk/build.mk, and hacking mkdependC.prl to omit dependencies on absolute paths, I get past the gmp problems, only to run into a similar problem with readline. I've put the appropriate flags for readline in $CPPFLAGS/$LDFLAGS and mk/build.mk, and the build ends with: Configuring readline-1.0.1.0... if ifBuildable/ifBuildable readline; then \ cd readline && \ cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ mv GNUmakefile GNUmakefile.tmp; \ setup/Setup makefile -f GNUmakefile; \ cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ make -wr && \ setup/Setup register --inplace; \ fi mv: cannot stat `GNUmakefile': No such file or directory In file included from Readline.hsc:36: include/HsReadline.h:10:31: error: readline/readline.h: No such file or directory include/HsReadline.h:11:30: error: readline/history.h: No such file or directory Readline.hsc: In function 'main': Readline.hsc:614: error: 'ISFUNC' undeclared (first use in this function) Readline.hsc:614: error: (Each undeclared identifier is reported only once Readline.hsc:614: error: for each function it appears in.) Readline.hsc:616: error: 'ISMACR' undeclared (first use in this function) Readline.hsc:618: error: 'ISKMAP' undeclared (first use in this function) Readline.hsc:723: error: 'UNDO_DELETE' undeclared (first use in this function) Readline.hsc:724: error: 'UNDO_INSERT' undeclared (first use in this function) Readline.hsc:725: error: 'UNDO_BEGIN' undeclared (first use in this function) Readline.hsc:726: error: 'UNDO_END' undeclared (first use in this function) Readline.hsc:1089: error: 'MULT_MATCH' undeclared (first use in this function) Readline.hsc:1112: error: 'SINGLE_MATCH' undeclared (first use in this function) compiling dist/build/System/Console/Readline_hsc_make.c failed command was: gcc -c -D__GLASGOW_HASKELL__=608 -I/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/includes -I/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/gmp/gmpbuild -I/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/conf/gmp/include -D__GLASGOW_HASKELL__=608 -Iinclude dist/build/System/Console/Readline_hsc_make.c -o dist/build/System/Console/Readline_hsc_make.o Preprocessing library readline-1.0.1.0... make[2]: Entering directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/libraries/readline' make[2]: *** No targets specified and no makefile found. Stop. make[2]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/libraries/readline' make[1]: *** [make.library.readline] Error 2 make[1]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/libraries' make: *** [stage1] Error 2 So next, I tried also passing --with-readline-{includes,libraries} to the toplevel ./configure. As I hoped, those arguments were relayed to the configure script for readline, but that still isn't enough: Configuring readline-1.0.1.0... if ifBuildable/ifBuildable readline; then \ cd readline && \ cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ mv GNUmakefile GNUmakefile.tmp; \ setup/Setup makefile -f GNUmakefile; \ cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ make -wr && \ setup/Setup register --inplace; \ fi mv: cannot stat `GNUmakefile': No such file or directory /package/host/code.dogmap.org/foreign/gcc-4.2.3+spf+0/conf/binutils/command/ld: cannot find -lncurses collect2: ld returned 1 exit status linking dist/build/System/Console/Readline_hsc_make.o failed command was: gcc -lreadline -lncurses -L/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/conf/readline/library dist/build/System/Console/Readline_hsc_make.o -o dist/build/System/Console/Readline_hsc_make Preprocessing library readline-1.0.1.0... make[2]: Entering directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/libraries/readline' make[2]: *** No targets specified and no makefile found. Stop. make[2]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/libraries/readline' make[1]: *** [make.library.readline] Error 2 make[1]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.8.2.20080317+spf+0/compile/src/ghc-6.8.2.20080317/libraries' make: *** [stage1] Error 2 There are no --with-* flags for ncurses, so the only ways I can see to say where ncurses is are the ones I'm already using, and which are apparently insufficient - $CPPFLAGS/$LDFLAGS in the environment, and SRC_HC_OPTS/SRC_HSC2HC_OPTS/SRC_CC_OPTS/GHC_CC_OPTS in mk/build.mk. paul From bernardy at chalmers.se Fri Mar 21 03:37:21 2008 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Fri Mar 21 03:33:57 2008 Subject: Type checking of partial programs In-Reply-To: References: Message-ID: <953e0d250803210037lbaf59f2q27ccd2d443b1d795@mail.gmail.com> 2008/3/20 ac : > Is anybody interested in working on this? This is a project I've been > interested in for some time, but recognize I probably need some guidance > before I go off and start hacking on it. As dcoutts pointed out on > #haskell-soc, this may be of particular interest to people working on yi and > HaRe. Other interesting and related projects include parsing partial > programs to insert "placeholders" in appropriate places. An example of a > partial program could be: > > foo :: [Foo] -> > foo xs = map xs > > What are the possible type signatures for placeholder 1 and the possible > expressions for placeholder 2? > (I'm maintainer of Yi) It turns out that already exists, an is called undefined :) It would be nice if GHC API could provide (maybe it does already) a way to retrieve the type of an expression "after unification". That would more or less solve this case. When it comes to , I guess one could use the same approach. You would then get the kind of the type. Finding possible expressions is a much harder problem, but in the case of haskell types that might be more or less manageable. If you implement the above in GHC API, they would be usable in Yi indeed. At the moment we only have a beginning of integration with GHC API, but is quite rudimentary. If you (or somebody) wishes to work on that kind of a project I'll be ready to mentor it. I don't think I'm comfortable enough with GHC to mentor your particular idea though. I should also mention that a good example of what this could look like is Agda2 (and its siblings) ; where the "placeholder" is fundamental to interactive proof/program construction. Cheers, JP. From simonpj at microsoft.com Fri Mar 21 04:36:49 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Mar 21 04:33:26 2008 Subject: Optimization beyond the Module Border In-Reply-To: <41335.128.240.229.65.1206024144.squirrel@webmail.ncl.ac.uk> References: <47E0F5D6.9040402@informatik.uni-kiel.de> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14363@EA-EXMSG-C334.europe.corp.microsoft.com> <47E14756.10007@informatik.uni-kiel.de> <20080319172012.GB9086@scytale.galois.com> <20080319180003.39d53df2.Malcolm.Wallace@cs.york.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A1460C@EA-EXMSG-C334.europe.corp.microsoft.com> <41335.128.240.229.65.1206024144.squirrel@webmail.ncl.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A14C20@EA-EXMSG-C334.europe.corp.microsoft.com> | Would it be possible for the compiler to say something like: "You are | applying level 2 optimization but some dependencies where compiled without | optimization enabled. To get full optimization, consider recompiling x,y,z | with -O2" - at least this would give us a fighting chance to 'fix' things. That's a reasonable suggestion. Currently the .hi file for a module does not record whether or not optimisation was on when compiling that module, so this'd mean an interface-file format change, plus a bit of jiggery pokery. Why not submit a Trac feature request? Simon From Christian.Maeder at dfki.de Sat Mar 22 08:00:08 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Sat Mar 22 07:56:43 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: References: <47E227AE.3080305@dfki.de> <47E2A64E.6030700@dfki.de> Message-ID: <47E4F4C8.9040606@dfki.de> Conal Elliott wrote: > The type argument I ran into trouble with represents a value as a list > of increasing lower bounds, ending in the exact value. min produces > lower bounds from lower bounds and so is immediately productive before > even knowing which argument is the lesser one. Is this only a matter of efficiency? Can it be compared with a faster equality check that does not need to evaluate terms always, because it compares the internal pointers first (and returns True for equal ones)? Cheers Christian P.S. Maybe it is still a good idea to have a separate user defined class Min for your purpose, because then you don't have to hand-write compare functions, but then I don't know the nesting of your data types, though a generic instance Ord a => Min a may help. From niklas.broberg at gmail.com Sun Mar 23 12:34:22 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Mar 23 12:30:50 2008 Subject: Inconsistent .hi files with associated types? Message-ID: Hi all, I'm getting a weird warning/error message from GHC that I don't understand: ===================== $ runhaskell Setup build Preprocessing library hsp-hjscript-0.3.4... Building hsp-hjscript-0.3.4... [1 of 1] Compiling HSP.HJScript ( HSP/HJScript.hs, dist\build/HSP/HJScript.o ) C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f35 Unfolding of HSP.Monad.$f35: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R32XML Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f6 Unfolding of HSP.Monad.$f6: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R5SetResult Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShsp-hjscript-0.3.4.a ===================== Can anyone explain to me what's up here? I have no .hi-boot files., and -ddump-if-trace gives no further info. Both XML and SetResult are associated types. Both of the instances in question are defined in a different package, which compiles without error. The classes that define the types are in yet another package, which also compiles without error. I note that the compilation of the package continues, so I suppose these are error messages only, even though they sound quite fatal. But what effect will this have on programs using the module? Cheers, /Niklas From quuxman at gmail.com Sun Mar 23 17:24:03 2008 From: quuxman at gmail.com (ac) Date: Sun Mar 23 17:20:31 2008 Subject: [Haskell-cafe] Type checking of partial programs In-Reply-To: References: <47E2CADB.50008@di.unipi.it> Message-ID: So a number of people responded with various ways this is already possible. Of course GHC can already do this... it's type inference. The part I'm interested in working on is exposing the functionality in GHC's API to make this as easy as possible. -Abram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080323/c4b752bd/attachment.htm From marco-oweber at gmx.de Mon Mar 24 04:31:57 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Mar 24 04:28:20 2008 Subject: Scripting an application in haskell: howto expose application api ? Message-ID: <20080324083157.GB13926@gmx.de> Hi, I'd like to add haskell scripting (ghc) support to vim. Passing the cmd to a .hsc module already works fine. But I can't imagine yet how to expose vim functions to the session started with newSession from the GHC API. Of course one way to go is interprocess communication (opening kind of pipe sending events/ commands replies..) But maybe you can think of someting easier ? Sincerly Marc Weber From claus.reinke at talk21.com Mon Mar 24 08:29:37 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 24 08:26:06 2008 Subject: Scripting an application in haskell: howto expose application api ? References: <20080324083157.GB13926@gmx.de> Message-ID: <005101c88daa$bac9e750$ee3d8351@cr3lt> > I'd like to add haskell scripting (ghc) support to vim. > Passing the cmd to a .hsc module already works fine. > But I can't imagine yet how to expose vim functions to the > session started with newSession from the GHC API. > > Of course one way to go is interprocess communication (opening kind of > pipe sending events/ commands replies..) > But maybe you can think of someting easier ? as an otherwise happy vim user, about the only gripe i have with vim are the consequences of its answer to ':help design-not': VIM IS... NOT *design-not* - Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)" while there was a point in having a simpler editor by focussing on editing, this particular phrasing ignores completely that having a single standard portable way of running and controlling asynchronous subprocesses is a simple but powerful enabler, not a source of complexity itself. the sad consequence is that vim has dozens of workarounds for getting similar effects in different contexts, but no supported standard. to get something portable, your best bet (and with no good odds) would be to establish ghc at the same level as the other supported vim scripting interfaces: perl, tcl, python, etc. but that would mean a change to vim sources, and would need to be distributed with standard vim distributions to be useful (some debugger interfaces rely on patched vims, but who wants to install non-standard vims to support your scripts?). there are of course various ways to cheat around this limitation, but none are satisfactory, imho. some examples: - interprocess communication: hard to get supported in a portable fashion (think windows users..), especially if you only rely on the standard vim-distributions. it was the route we chose for HaRe some years ago, to enable a vim session to call a running refactorer process, but i never liked using sockets for this (perhaps there's an easier way now that you don't have to worry about win98 anymore?) - vim's client/server feature: the main escape route, but gets fragile if you need to escape command strings; HaRe used this for the refactorer to call back into the Vim session, which seems to be your question? - dynamic loading support: a bit rudimentary last time i looked, but possibly workable - but if your script crashes, vim will, too, and you still need to be able to call back to vim - you might also be able to re-purpose one of the several tool-specific vim interfaces - or you can move beyond standard distributions and require perl or python support compiled in, then use their interprocess communication support. but then you require your users to install perl or python, which will be loaded dynamically into the vim session just to run a 20-line script for calling the ghc session:-( because of its many useful applications, the topic comes up again and again on the vim lists, so perhaps Bram will give in at some point.. claus ps: if you don't need much session state (and why would you with haskell?), you could simply start a new ghc session for each haskell script. such synchronous subprocesses are easy in vim and todays machines are fast, especially if the scripts are non-trivial. From fegaras at cse.uta.edu Mon Mar 24 17:01:19 2008 From: fegaras at cse.uta.edu (Leonidas Fegaras) Date: Mon Mar 24 16:57:44 2008 Subject: Announce: HXQ: A Compiler from XQuery to Haskell Message-ID: <1206392479.3688.17.camel@functor.uta.edu> I would like to announce the release of HXQ: A Compiler from XQuery to Haskell. HXQ is a fast and space-efficient translator from XQuery (the standard query language for XML) to embedded Haskell code. The translation is based on Haskell templates. HXQ takes full advantage of Haskell's lazy evaluation to keep in memory only those parts of XML data needed at each point of evaluation, thus performing stream-based evaluation. This results to an implementation that is as fast and space-efficient as any stream-based implementation based on SAX filters or finite state machines. Furthermore, the coding is far simpler and extensible since its based on XML trees, rather than SAX events. For example, an XQuery against the DBLP XML database (420MB) runs in 1.5 minutes. You can get more information at: http://lambda.uta.edu/HXQ/ Leonidas Fegaras U. of Texas at Arlington http://lambda.uta.edu/ From dons at galois.com Mon Mar 24 17:05:38 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 24 17:02:11 2008 Subject: Announce: HXQ: A Compiler from XQuery to Haskell In-Reply-To: <1206392479.3688.17.camel@functor.uta.edu> References: <1206392479.3688.17.camel@functor.uta.edu> Message-ID: <20080324210538.GB15485@scytale.galois.com> I think it would make sense to announce this on haskell-cafe@haskell.org too , which has a much broader readership. fegaras: > I would like to announce the release of HXQ: A Compiler from XQuery to > Haskell. > > HXQ is a fast and space-efficient translator from XQuery (the standard > query language for XML) to embedded Haskell code. The translation is > based on Haskell templates. HXQ takes full advantage of Haskell's lazy > evaluation to keep in memory only those parts of XML data needed at each > point of evaluation, thus performing stream-based evaluation. This > results to an implementation that is as fast and space-efficient as any > stream-based implementation based on SAX filters or finite state > machines. Furthermore, the coding is far simpler and extensible since > its based on XML trees, rather than SAX events. For example, an XQuery > against the DBLP XML database (420MB) runs in 1.5 minutes. > > You can get more information at: > http://lambda.uta.edu/HXQ/ > > Leonidas Fegaras > U. of Texas at Arlington > http://lambda.uta.edu/ > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From chak at cse.unsw.edu.au Tue Mar 25 02:12:22 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Mar 25 02:08:52 2008 Subject: Inconsistent .hi files with associated types? In-Reply-To: References: Message-ID: Niklas, > ===================== > $ runhaskell Setup build > Preprocessing library hsp-hjscript-0.3.4... > Building hsp-hjscript-0.3.4... > [1 of 1] Compiling HSP.HJScript ( HSP/HJScript.hs, > dist\build/HSP/HJScript.o ) > C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi > Declaration for $f35 > Unfolding of HSP.Monad.$f35: > Can't find interface-file declaration for type constructor or class > HSP.Monad.:CoF:R32XML > Probable cause: bug in .hi-boot file, or inconsistent .hi file > Use -ddump-if-trace to get an idea of which file caused the error > C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi > Declaration for $f6 > Unfolding of HSP.Monad.$f6: > Can't find interface-file declaration for type constructor or class > HSP.Monad.:CoF:R5SetResult > Probable cause: bug in .hi-boot file, or inconsistent .hi file > Use -ddump-if-trace to get an idea of which file caused the error > > C:\Program\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShsp- > hjscript-0.3.4.a > ===================== Could you check whether the problem also occurs with the current GHC 6.9 (development version)? There has been at least on bug that may cause this sort of problem been fixed in 6.9, which may not have been merged back to 6.8. (Remember that we unfortunately cannot support type families (and hence associated types) fully in 6.8 - this has been discussed previously on this and/or the Haskell lists.) Manuel From ganesh at earth.li Wed Mar 26 16:52:43 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed Mar 26 16:49:01 2008 Subject: flexible contexts and context reduction Message-ID: Hi, I'm a bit confused about why the following program doesn't compile (in any of 6.6.1, 6.8.1 and 6.9.20080316). Shouldn't the Ord (a, b) context be reduced? Cheers, Ganesh {-# LANGUAGE FlexibleContexts #-} module Test2 where foo :: Ord (a, b) => (a, b) -> (a, b) foo = bar bar :: (Ord a, Ord b) => (a, b) -> (a, b) bar = id From ross at soi.city.ac.uk Wed Mar 26 17:07:18 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Mar 26 17:03:38 2008 Subject: flexible contexts and context reduction In-Reply-To: References: Message-ID: <20080326210701.GA9467@soi.city.ac.uk> On Wed, Mar 26, 2008 at 08:52:43PM +0000, Ganesh Sittampalam wrote: > I'm a bit confused about why the following program doesn't compile (in > any of 6.6.1, 6.8.1 and 6.9.20080316). Shouldn't the Ord (a, b) context > be reduced? > > {-# LANGUAGE FlexibleContexts #-} > > module Test2 where > > foo :: Ord (a, b) => (a, b) -> (a, b) > foo = bar > > bar :: (Ord a, Ord b) => (a, b) -> (a, b) > bar = id To use bar, you need (Ord a, Ord b). You're assuming that Ord (a, b) implies that, but it's the other way round. From ganesh at earth.li Wed Mar 26 17:36:36 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed Mar 26 17:32:54 2008 Subject: flexible contexts and context reduction In-Reply-To: <20080326210701.GA9467@soi.city.ac.uk> References: <20080326210701.GA9467@soi.city.ac.uk> Message-ID: On Wed, 26 Mar 2008, Ross Paterson wrote: > On Wed, Mar 26, 2008 at 08:52:43PM +0000, Ganesh Sittampalam wrote: >> I'm a bit confused about why the following program doesn't compile (in >> any of 6.6.1, 6.8.1 and 6.9.20080316). Shouldn't the Ord (a, b) context >> be reduced? > > To use bar, you need (Ord a, Ord b). You're assuming that Ord (a, b) > implies that, but it's the other way round. Oh yes, I see. Thanks. Ganesh From Tom.Schrijvers at cs.kuleuven.be Thu Mar 27 02:59:18 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Mar 27 02:57:06 2008 Subject: flexible contexts and context reduction In-Reply-To: References: <20080326210701.GA9467@soi.city.ac.uk> Message-ID: On Wed, 26 Mar 2008, Ganesh Sittampalam wrote: > On Wed, 26 Mar 2008, Ross Paterson wrote: > >> On Wed, Mar 26, 2008 at 08:52:43PM +0000, Ganesh Sittampalam wrote: >>> I'm a bit confused about why the following program doesn't compile (in >>> any of 6.6.1, 6.8.1 and 6.9.20080316). Shouldn't the Ord (a, b) context >>> be reduced? >> >> To use bar, you need (Ord a, Ord b). You're assuming that Ord (a, b) >> implies that, but it's the other way round. Logically, the implication holds. There's an equivalence: Ord a /\ Ord b <=> Ord (a,b) Why it does or doesn't work in a Haskell impelmentation iss an implementation issue / language design issue.. There's a paper by Martin Sulzmann about extensible superclasses, which shows how this can be implemented if you don't use dictionaries for your typeclasses, but the type-passing scheme. The problem with dictionaries is that you have to store the superclass dictionaries, here Ord a and Ord b, in the dictionary, here Ord (a,b). However, what superclass dictionaries you have to store depends on the instance, e.g. Ord Int doesn't have any superclass and Ord [a] has superclass Ord a. There maybe wasn't an easy solution, but here is my idea of how to to it with data or type families. The dictionary type would be: data OrdDict a = { (<) :: a -> a -> Bool , ... , super :: Super a } type family Super a :: * type instance Super Int = () type instance Super [a] = OrdDict a type instance Super (a,b) = (OrdDict a, OrdDict b) A similar solution is possible with a data family Super (but obviously I'm in favor of type families :) The openness of the family matches the openness of the type classes. There is a little overhead in carrying around the superclasses. Now ask your favorite Haskell system to implement this feature :) Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From simonpj at microsoft.com Thu Mar 27 04:43:58 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 27 04:40:20 2008 Subject: flexible contexts and context reduction In-Reply-To: References: <20080326210701.GA9467@soi.city.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9EF21F9@EA-EXMSG-C334.europe.corp.microsoft.com> | >> To use bar, you need (Ord a, Ord b). You're assuming that Ord (a, b) | >> implies that, but it's the other way round. | | Logically, the implication holds. There's an equivalence: | | Ord a /\ Ord b <=> Ord (a,b) | ... | The problem with dictionaries is that you have to store the superclass | dictionaries, here Ord a and Ord b, in the dictionary, here Ord (a,b). | However, what superclass dictionaries you have to store depends on the | instance, e.g. Ord Int doesn't have any superclass and Ord [a] has | superclass Ord a. In Haskell the "superclass(es)", if any, are declared in the class decl. Thus class Eq a => Ord a where ... Here Eq is the superclass of Ord. You're talking about something else: the dictionaries (Ord a, Ord b) from which the Ord (a,b) dictionary were constructed. We don't have a very good name for these guys, but "superclass" isn't a good one. Otherwise I agree with all you say. Your idea of using type families is cool. | data OrdDict a = | { (<) :: a -> a -> Bool | , ... | , super :: Super a | } | | type family Super a :: * | type instance Super Int = () | type instance Super [a] = OrdDict a | type instance Super (a,b) = (OrdDict a, OrdDict b) | | A similar solution is possible with a data family Super (but obviously I'm | in favor of type families :) Can you say why? A data family would work fine here. But it's not a big deal. So the other question is whether this is useful. How often do people write stuff like this? f :: Ord [a] => a -> a -> Bool f x y = x>y Nevertheless, I hadn't realised it was possible before, and now I can see it is. Simon From Tom.Schrijvers at cs.kuleuven.be Thu Mar 27 04:55:08 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Mar 27 04:52:39 2008 Subject: flexible contexts and context reduction In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9EF21F9@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080326210701.GA9467@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AB9EF21F9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: > You're talking about something else: the dictionaries (Ord a, Ord b) from which the Ord (a,b) dictionary were constructed. We don't have a very good name for these guys, but "superclass" isn't a good one. > > Otherwise I agree with all you say. Your idea of using type families is cool. > > | data OrdDict a = > | { (<) :: a -> a -> Bool > | , ... > | , super :: Super a > | } > | > | type family Super a :: * > | type instance Super Int = () > | type instance Super [a] = OrdDict a > | type instance Super (a,b) = (OrdDict a, OrdDict b) > | > | A similar solution is possible with a data family Super (but obviously I'm > | in favor of type families :) > > Can you say why? A data family would work fine here. But it's not a big deal. Just a matter of taste, and familiarity. > So the other question is whether this is useful. How often do people write stuff like this? > f :: Ord [a] => a -> a -> Bool > f x y = x>y This paper has some examples, I believe: Modular Generic Programming with Extensible Superclasses Martin Sulzmann and Meng Wang In Workshop on Generic Programming (WGP'06) http://www.comp.nus.edu.sg/~sulzmann/publications/wgp06-modulargeneric.ps > Nevertheless, I hadn't realised it was possible before, and now I can see it is. I'd be nice to know of people who need or would like to have this feature. Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From ganesh.sittampalam at credit-suisse.com Thu Mar 27 04:56:46 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Mar 27 04:54:49 2008 Subject: flexible contexts and context reduction Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F5E8@elon12p32001.csfp.co.uk> > So the other question is whether this is useful. How often do people write stuff like this? > f :: Ord [a] => a -> a -> Bool > f x y = x>y > Nevertheless, I hadn't realised it was possible before, and now I can see it is. A closer example to what I was actually doing was this: {-# LANGUAGE GADTs #-} module Foo where data Foo a where Foo1 :: a -> Foo a Foo2 :: Foo a -> Foo b -> Foo (a, b) unFoo :: Ord a => Foo a -> a unFoo (Foo1 a) = a unFoo (Foo2 x y) = (unFoo x, unFoo y) [in the real code I did actually use the Ord constraint in the base case] The error I get is this: Foo.hs:10:20: Could not deduce (Ord a2) from the context () arising from a use of `unFoo' at Foo.hs:10:20-26 Possible fix: add (Ord a2) to the context of the constructor `Foo2' In the expression: unFoo x In the expression: (unFoo x, unFoo y) In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) Foo.hs:10:29: Could not deduce (Ord b1) from the context () arising from a use of `unFoo' at Foo.hs:10:29-35 Possible fix: add (Ord b1) to the context of the constructor `Foo2' In the expression: unFoo y In the expression: (unFoo x, unFoo y) In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) Which suggests that GHC has also lost track of the fact that Ord (a, b) is true. But it would certainly be necessary to get from Ord (a, b) to (Ord a, Ord b) to get that to work. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ganesh.sittampalam at credit-suisse.com Thu Mar 27 05:00:25 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Mar 27 04:59:15 2008 Subject: flexible contexts and context reduction Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F5E9@elon12p32001.csfp.co.uk> Tom Schrijvers wrote: > On Wed, 26 Mar 2008, Ganesh Sittampalam wrote: >> On Wed, 26 Mar 2008, Ross Paterson wrote: >> >>> On Wed, Mar 26, 2008 at 08:52:43PM +0000, Ganesh Sittampalam wrote: >>>> I'm a bit confused about why the following program doesn't compile >>>> (in any of 6.6.1, 6.8.1 and 6.9.20080316). Shouldn't the Ord (a, b) >>>> context be reduced? >>> >>> To use bar, you need (Ord a, Ord b). You're assuming that Ord (a, b) >>> implies that, but it's the other way round. > Logically, the implication holds. There's an equivalence: > > Ord a /\ Ord b <=> Ord (a,b) Unfortunately, GHC accepts the following: {-# LANGUAGE FlexibleInstances #-} module Foo2 where data Foo = Foo deriving Eq instance Ord (Foo, Foo) where (Foo, Foo) < (Foo, Foo) = False Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Thu Mar 27 05:05:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 27 05:01:29 2008 Subject: flexible contexts and context reduction In-Reply-To: <8C984B4799C04D4B8F80F746537145E116F4F5E9@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E116F4F5E9@elon12p32001.csfp.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9EF2226@EA-EXMSG-C334.europe.corp.microsoft.com> Why "unfortunately"? Looks fine to me. Simon | | Unfortunately, GHC accepts the following: | | {-# LANGUAGE FlexibleInstances #-} | module Foo2 where | | data Foo = Foo | deriving Eq | | instance Ord (Foo, Foo) where | (Foo, Foo) < (Foo, Foo) = False From ganesh.sittampalam at credit-suisse.com Thu Mar 27 05:06:52 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Mar 27 05:04:00 2008 Subject: flexible contexts and context reduction Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F5EA@elon12p32001.csfp.co.uk> Well, Ord Foo doesn't hold, does it? So Ord (a, b) isn't equivalent to (Ord a, Ord b). Ganesh -----Original Message----- From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] Sent: 27 March 2008 09:05 To: Sittampalam, Ganesh; 'Tom Schrijvers'; Ganesh Sittampalam Cc: glasgow-haskell-users@haskell.org; Martin Sulzmann Subject: RE: flexible contexts and context reduction Why "unfortunately"? Looks fine to me. Simon | | Unfortunately, GHC accepts the following: | | {-# LANGUAGE FlexibleInstances #-} | module Foo2 where | | data Foo = Foo | deriving Eq | | instance Ord (Foo, Foo) where | (Foo, Foo) < (Foo, Foo) = False ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Thu Mar 27 05:14:52 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 27 05:11:11 2008 Subject: flexible contexts and context reduction In-Reply-To: <8C984B4799C04D4B8F80F746537145E116F4F5EA@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E116F4F5EA@elon12p32001.csfp.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9EF2239@EA-EXMSG-C334.europe.corp.microsoft.com> | Well, Ord Foo doesn't hold, does it? So Ord (a, b) isn't equivalent to (Ord a, Ord b). Indeed not. But that was not what Tom was suggesting (although he was not very explicit). What he meant was this: If you write the instance instance Theta => Foo (T a b) where ... where Theta is an arbitrary context, then, given a dictionary for (Foo (T a b)), you can get dictionaries for each constraint in Theta. Or in logic Theta <=> Foo (T a b) In your example, Theta is empty. If you'd written instance (Show a, Ix b) => Ord (a,b) then you could get a Show a and Ix b dictionaries from an Ord (a,b) dictionary. (But not an Ord a or Ord b one.) S | | Ganesh | | -----Original Message----- | From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] | Sent: 27 March 2008 09:05 | To: Sittampalam, Ganesh; 'Tom Schrijvers'; Ganesh Sittampalam | Cc: glasgow-haskell-users@haskell.org; Martin Sulzmann | Subject: RE: flexible contexts and context reduction | | Why "unfortunately"? Looks fine to me. | | Simon | | | | | Unfortunately, GHC accepts the following: | | | | {-# LANGUAGE FlexibleInstances #-} | | module Foo2 where | | | | data Foo = Foo | | deriving Eq | | | | instance Ord (Foo, Foo) where | | (Foo, Foo) < (Foo, Foo) = False | | ============================================================================== | Please access the attached hyperlink for an important electronic communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ============================================================================== From Tom.Schrijvers at cs.kuleuven.be Thu Mar 27 05:28:24 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Mar 27 05:25:38 2008 Subject: flexible contexts and context reduction In-Reply-To: <8C984B4799C04D4B8F80F746537145E116F4F5EA@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E116F4F5EA@elon12p32001.csfp.co.uk> Message-ID: On Thu, 27 Mar 2008, Sittampalam, Ganesh wrote: > Well, Ord Foo doesn't hold, does it? So Ord (a, b) isn't equivalent to > (Ord a, Ord b). It seems you (can) throw logic out of the window with flexible instances. So there's no point in talking about equivalences any more. We could still capture the operational aspect of it, but we'd need the type/data family counterpart of flexible instances. Considering overlapping instances, there is still a logic, but it's implicit in the notation. You'd get for your example: (a /= Foo \/ b \= Foo) ==> (Ord a /\ Ord b <=> Ord (a,b)) Again, an overlapping type/data family would be needed for encoding this in dictionaries. Cheers, Tom > -----Original Message----- > From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] > Sent: 27 March 2008 09:05 > To: Sittampalam, Ganesh; 'Tom Schrijvers'; Ganesh Sittampalam > Cc: glasgow-haskell-users@haskell.org; Martin Sulzmann > Subject: RE: flexible contexts and context reduction > > Why "unfortunately"? Looks fine to me. > > Simon > > | > | Unfortunately, GHC accepts the following: > | > | {-# LANGUAGE FlexibleInstances #-} > | module Foo2 where > | > | data Foo = Foo > | deriving Eq > | > | instance Ord (Foo, Foo) where > | (Foo, Foo) < (Foo, Foo) = False > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From ganesh.sittampalam at credit-suisse.com Thu Mar 27 05:29:17 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Mar 27 05:26:33 2008 Subject: flexible contexts and context reduction Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F5EB@elon12p32001.csfp.co.uk> > If you write the instance > instance Theta => Foo (T a b) where ... > where Theta is an arbitrary context, then, given a dictionary for (Foo (T a b)), you can get dictionaries for each constraint in Theta. Or in logic > > Theta <=> Foo (T a b) > > In your example, Theta is empty. >If you'd written > instance (Show a, Ix b) => Ord (a,b) then you could get a Show a and Ix b dictionaries from an Ord (a,b) dictionary. (But not an Ord a or Ord b > one.) I sort of see, but then what is Tom actually proposing? Replacing the body of the Ord declaration with something like OrdDict, thus forcing any possible instance for Ord (a, b) to provide OrdDict a and OrdDict b because of the definition of Super? In the current world, the possibility of instances like (Foo, Foo) make it impossible to write the code I originally asked about, so something would have to change, either with Ord or with my code, to be able to do anything like it. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From claus.reinke at talk21.com Thu Mar 27 08:25:13 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Mar 27 08:21:34 2008 Subject: flexible contexts and context reduction References: <8C984B4799C04D4B8F80F746537145E116F4F5E8@elon12p32001.csfp.co.uk> Message-ID: <00d001c89005$9ce775b0$df028351@cr3lt> perhaps i'm missing something but, instead of trying to deduce conditions from conclusions, why can't you just follow ghc's suggestion, and add the constraints to the constructor? data Foo a where Foo1 :: a -> Foo a Foo2 :: (Ord a,Ord b) => Foo a -> Foo b -> Foo (a, b) (possibly with another constraint on Foo1) claus > A closer example to what I was actually doing was this: > > {-# LANGUAGE GADTs #-} > module Foo where > > data Foo a where > Foo1 :: a -> Foo a > Foo2 :: Foo a -> Foo b -> Foo (a, b) > > unFoo :: Ord a => Foo a -> a > unFoo (Foo1 a) = a > unFoo (Foo2 x y) = (unFoo x, unFoo y) > > [in the real code I did actually use the Ord constraint in the base case] > > The error I get is this: > > Foo.hs:10:20: > Could not deduce (Ord a2) from the context () > arising from a use of `unFoo' at Foo.hs:10:20-26 > Possible fix: add (Ord a2) to the context of the constructor `Foo2' > In the expression: unFoo x > In the expression: (unFoo x, unFoo y) > In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) > > Foo.hs:10:29: > Could not deduce (Ord b1) from the context () > arising from a use of `unFoo' at Foo.hs:10:29-35 > Possible fix: add (Ord b1) to the context of the constructor `Foo2' > In the expression: unFoo y > In the expression: (unFoo x, unFoo y) > In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) > > Which suggests that GHC has also lost track of the fact that Ord (a, b) is true. But > it would certainly be necessary to get from Ord (a, b) to (Ord a, Ord b) to get that > to work. From ganesh.sittampalam at credit-suisse.com Thu Mar 27 08:29:03 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Mar 27 08:33:20 2008 Subject: flexible contexts and context reduction Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F5F4@elon12p32001.csfp.co.uk> Because I want to be able to make Foo values where the parameter type isn't in Ord, too. I just want unFoo to work on specific Foo values where it is. -----Original Message----- From: Claus Reinke [mailto:claus.reinke@talk21.com] Sent: 27 March 2008 12:25 To: Sittampalam, Ganesh; Ganesh Sittampalam Cc: glasgow-haskell-users@haskell.org Subject: Re: flexible contexts and context reduction perhaps i'm missing something but, instead of trying to deduce conditions from conclusions, why can't you just follow ghc's suggestion, and add the constraints to the constructor? data Foo a where Foo1 :: a -> Foo a Foo2 :: (Ord a,Ord b) => Foo a -> Foo b -> Foo (a, b) (possibly with another constraint on Foo1) claus > A closer example to what I was actually doing was this: > > {-# LANGUAGE GADTs #-} > module Foo where > > data Foo a where > Foo1 :: a -> Foo a > Foo2 :: Foo a -> Foo b -> Foo (a, b) > > unFoo :: Ord a => Foo a -> a > unFoo (Foo1 a) = a > unFoo (Foo2 x y) = (unFoo x, unFoo y) > > [in the real code I did actually use the Ord constraint in the base > case] > > The error I get is this: > > Foo.hs:10:20: > Could not deduce (Ord a2) from the context () > arising from a use of `unFoo' at Foo.hs:10:20-26 > Possible fix: add (Ord a2) to the context of the constructor `Foo2' > In the expression: unFoo x > In the expression: (unFoo x, unFoo y) > In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) > > Foo.hs:10:29: > Could not deduce (Ord b1) from the context () > arising from a use of `unFoo' at Foo.hs:10:29-35 > Possible fix: add (Ord b1) to the context of the constructor `Foo2' > In the expression: unFoo y > In the expression: (unFoo x, unFoo y) > In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) > > Which suggests that GHC has also lost track of the fact that Ord (a, > b) is true. But it would certainly be necessary to get from Ord (a, b) > to (Ord a, Ord b) to get that to work. ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From claus.reinke at talk21.com Thu Mar 27 11:43:19 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Mar 27 11:39:40 2008 Subject: flexible contexts and context reduction References: <8C984B4799C04D4B8F80F746537145E116F4F5F4@elon12p32001.csfp.co.uk> Message-ID: <012301c89021$4998a480$df028351@cr3lt> > Because I want to be able to make Foo values where the parameter type isn't in Ord, too. I just > want unFoo to work on specific Foo values where it is. but your recursive function requires a recursive constraint, which your data type does not guarantee by construction, and which the Ord instances do not guarantee due to lack of closed classes. a rather pedestrian approach would record during construction whether or not all parts are in Ord (see below). i really wanted to record that information only in the leaf, using the type family and the commented-out parts to propagate the information through Foo2, but unfortunately, ghc does not see that the only case for which And returns True requires both parameters to be True (closed families/classes would help, again?), so i had to split up Foo2 as well. not pretty, but might get you a step further? perhaps some of Oleg's workarounds for closed classes and context-based overloading might help to merge the four constructors into two again. that would get rid of the junk (you can't promise too much, but you can promise too little by using the wrong constructor version below). claus {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module Foo where data True = T data False = F type family And a b :: * type instance And True True = True type instance And True False = False type instance And False True = False type instance And False False = False data Foo ord a where Foo1 :: a -> Foo False a Foo1o :: Ord a => a -> Foo True a -- Foo2 :: And oa ob ~ ord => ord -> Foo oa a -> Foo ob b -> Foo ord (a, b) Foo2 :: Foo oa a -> Foo ob b -> Foo False (a, b) Foo2o :: Foo True a -> Foo True b -> Foo True (a, b) unFoo :: Foo True a -> a unFoo (Foo1o a) = if a>a then a else a -- unFoo (Foo2 T x y) = (unFoo x, unFoo y) unFoo (Foo2o x y) = (unFoo x, unFoo y) >> A closer example to what I was actually doing was this: >> >> {-# LANGUAGE GADTs #-} >> module Foo where >> >> data Foo a where >> Foo1 :: a -> Foo a >> Foo2 :: Foo a -> Foo b -> Foo (a, b) >> >> unFoo :: Ord a => Foo a -> a >> unFoo (Foo1 a) = a >> unFoo (Foo2 x y) = (unFoo x, unFoo y) >> >> [in the real code I did actually use the Ord constraint in the base >> case] From ganesh.sittampalam at credit-suisse.com Thu Mar 27 11:48:05 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Mar 27 11:45:05 2008 Subject: flexible contexts and context reduction Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F5FA@elon12p32001.csfp.co.uk> > > Because I want to be able to make Foo values where the parameter type > > isn't in Ord, too. I just want unFoo to work on specific Foo values where it is. > but your recursive function requires a recursive constraint, which your data > type does not guarantee byconstruction, and which the Ord instances do not guarantee > due to lack of closed classes. Yeah. As you imply, I'm probably out of luck. > a rather pedestrian approach would record during construction whether or not > all parts are in Ord (see below). Unfortunately I need a (fully) polymorphic construction function, so this isn't possible. I'm trying to generalise the trick described at http://hsenag.livejournal.com/11803.html to arrows, but getting stuck with the "first" combinator. Thanks, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From tora at zonetora.co.uk Thu Mar 27 12:14:46 2008 From: tora at zonetora.co.uk (Tristan Allwood) Date: Thu Mar 27 12:10:56 2008 Subject: flexible contexts and context reduction In-Reply-To: <8C984B4799C04D4B8F80F746537145E116F4F5F4@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E116F4F5F4@elon12p32001.csfp.co.uk> Message-ID: <20080327161446.GB18930@doc.ic.ac.uk> Hi, Would passing around witnesses help? Of course you need to know about the witness you want when creating the Foo's, but I'm not sure about your needs... {-# LANGUAGE TypeOperators, GADTs, RankNTypes #-} data Foo a where Foo1 :: Witness a -> a -> Foo a Foo2 :: Witness a -> Witness b -> Foo a -> Foo b -> Foo (a,b) unFoo :: (forall x y . Witness x -> Witness y -> Witness (x,y)) -> Foo a -> (a, Witness a) unFoo f (Foo1 w x) = (x, w) unFoo f (Foo2 wa wb fa fb) = ((ra, rb), f wa' wb') where (ra,wa') = unFoo f fa (rb,wb') = unFoo f fb data Witness a where OrdW :: Ord a => Witness a IdW :: Witness a unFooOrd :: (Ord a) => Foo a -> a unFooOrd = fst . unFoo (\OrdW OrdW -> OrdW) Regards, Tris On Thu, Mar 27, 2008 at 08:29:03AM -0400, Sittampalam, Ganesh wrote: > Because I want to be able to make Foo values where the parameter type isn't in Ord, too. I just want unFoo to work on specific Foo values where it is. > > -----Original Message----- > From: Claus Reinke [mailto:claus.reinke@talk21.com] > Sent: 27 March 2008 12:25 > To: Sittampalam, Ganesh; Ganesh Sittampalam > Cc: glasgow-haskell-users@haskell.org > Subject: Re: flexible contexts and context reduction > > perhaps i'm missing something but, instead of trying to deduce conditions from conclusions, why can't you just follow ghc's suggestion, and add the constraints to the constructor? > > data Foo a where > Foo1 :: a -> Foo a > Foo2 :: (Ord a,Ord b) => Foo a -> Foo b -> Foo (a, b) > > (possibly with another constraint on Foo1) > > claus > > > A closer example to what I was actually doing was this: > > > > {-# LANGUAGE GADTs #-} > > module Foo where > > > > data Foo a where > > Foo1 :: a -> Foo a > > Foo2 :: Foo a -> Foo b -> Foo (a, b) > > > > unFoo :: Ord a => Foo a -> a > > unFoo (Foo1 a) = a > > unFoo (Foo2 x y) = (unFoo x, unFoo y) > > > > [in the real code I did actually use the Ord constraint in the base > > case] > > > > The error I get is this: > > > > Foo.hs:10:20: > > Could not deduce (Ord a2) from the context () > > arising from a use of `unFoo' at Foo.hs:10:20-26 > > Possible fix: add (Ord a2) to the context of the constructor `Foo2' > > In the expression: unFoo x > > In the expression: (unFoo x, unFoo y) > > In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) > > > > Foo.hs:10:29: > > Could not deduce (Ord b1) from the context () > > arising from a use of `unFoo' at Foo.hs:10:29-35 > > Possible fix: add (Ord b1) to the context of the constructor `Foo2' > > In the expression: unFoo y > > In the expression: (unFoo x, unFoo y) > > In the definition of `unFoo': unFoo (Foo2 x y) = (unFoo x, unFoo y) > > > > Which suggests that GHC has also lost track of the fact that Ord (a, > > b) is true. But it would certainly be necessary to get from Ord (a, b) > > to (Ord a, Ord b) to get that to work. > > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Tristan Allwood PhD Student Department of Computing Imperial College London From igloo at earth.li Fri Mar 28 10:43:14 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Mar 28 10:39:27 2008 Subject: building against gmp in a nonstandard location In-Reply-To: References: <20080320143110.GB22737@matrix.chaos.earth.li> <20080320201127.GA7181@matrix.chaos.earth.li> Message-ID: <20080328144314.GA27693@matrix.chaos.earth.li> On Fri, Mar 21, 2008 at 01:44:37AM -0400, Paul Jarc wrote: > > There are no --with-* flags for ncurses, so the only ways I can see to > say where ncurses is are the ones I'm already using, and which are > apparently insufficient - $CPPFLAGS/$LDFLAGS in the environment, and > SRC_HC_OPTS/SRC_HSC2HC_OPTS/SRC_CC_OPTS/GHC_CC_OPTS in mk/build.mk. I think the right thing to do is to add --with-* flags for (n)curses/termcap; the alternative would be to put the whole of $LDFLAGS into the Cabal buildinfo, but that feels wrong to me. We should probably also be undefining variables like LDFLAGS in configure, as the autoconf macros will be using them to check if libraries exist, but we don't use them when compiling. Thanks Ian From conal at conal.net Fri Mar 28 21:53:15 2008 From: conal at conal.net (Conal Elliott) Date: Fri Mar 28 21:49:37 2008 Subject: simple CSE? Message-ID: I'd like to know if it's possible to get GHC to perform some simple CSE for function-level programming. Here's a simple example: liftA2 (*) sin sin :: Double -> Double which inlines and simplifies to \ t -> sin t * sin t A more realistic, equivalent, example: let b = sin <$> id in liftA2 (*) b b Can GHC be nudged into computing 'sin t' once rather than twice? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080328/42f53198/attachment.htm From dons at galois.com Fri Mar 28 22:23:44 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 28 22:19:57 2008 Subject: simple CSE? In-Reply-To: References: Message-ID: <20080329022344.GC20301@scytale.galois.com> conal: > I'd like to know if it's possible to get GHC to perform some simple CSE > for function-level programming. Here's a simple example: > > liftA2 (*) sin sin :: Double -> Double > > which inlines and simplifies to > > \ t -> sin t * sin t > > A more realistic, equivalent, example: > > let b = sin <$> id in liftA2 (*) b b > > Can GHC be nudged into computing 'sin t' once rather than twice? > So GHC does do some light CSE, but not in this case, as far as I could see. I had a go with a rewrite rule that I felt should have matched, but it didn't seem to want to fire. Possibly the dictionaries were getting in the way. import System.Environment import Prelude hiding (sin) import qualified Prelude sin :: Double -> Double sin x = Prelude.sin x {-# NOINLINE sin #-} times :: Double -> Double -> Double times x y = x * y {-# NOINLINE times #-} {-# RULES "sin/cse" forall x. times (sin x) (sin x) = case Prelude.sin x of y -> y * y #-} main = do [x] <- getArgs let n = read x print $ sin n `times` sin n From lennart at augustsson.net Sat Mar 29 05:19:16 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Mar 29 05:15:28 2008 Subject: simple CSE? In-Reply-To: <20080329022344.GC20301@scytale.galois.com> References: <20080329022344.GC20301@scytale.galois.com> Message-ID: GHC is bad at CSE. Of course, in general CSE might not be a good idea, but with strict computations it is. So someone needs to add a CSE pass. On Sat, Mar 29, 2008 at 2:23 AM, Don Stewart wrote: > conal: > > I'd like to know if it's possible to get GHC to perform some simple > CSE > > for function-level programming. Here's a simple example: > > > > liftA2 (*) sin sin :: Double -> Double > > > > which inlines and simplifies to > > > > \ t -> sin t * sin t > > > > A more realistic, equivalent, example: > > > > let b = sin <$> id in liftA2 (*) b b > > > > Can GHC be nudged into computing 'sin t' once rather than twice? > > > > So GHC does do some light CSE, but not in this case, as far as I could > see. > > I had a go with a rewrite rule that I felt should have matched, but it > didn't seem to want to fire. Possibly the dictionaries were getting in > the way. > > > import System.Environment > import Prelude hiding (sin) > import qualified Prelude > > sin :: Double -> Double > sin x = Prelude.sin x > {-# NOINLINE sin #-} > > times :: Double -> Double -> Double > times x y = x * y > {-# NOINLINE times #-} > > {-# RULES > > "sin/cse" forall x. > times (sin x) (sin x) = case Prelude.sin x of y -> y * y > > #-} > > > main = do > [x] <- getArgs > let n = read x > print $ sin n `times` sin n > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080329/99650b9c/attachment.htm From jay at satirist.org Sun Mar 30 14:14:01 2008 From: jay at satirist.org (Jay Scott) Date: Sun Mar 30 14:10:15 2008 Subject: 64-bit breakdown Message-ID: <20080330181401.77859069@mail.satirist.org> I have a MacBook (which is a Core 2 Duo) running Mac OS X 10.4. On this platform, gcc makes 32-bit executables by default, but if you give it - m64 it makes them 64-bit. I've tried it, and it works. gcc gives its version as "i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)" But 64-bit doesn't work with my ghc installation (6.8.2 from the binary distribution on the downloads page). If I compile a "Hello World" program with -fvia-c -optc-m64, it fails, saying -- Warning: retaining unknown function `_siC_entry.eh' in output from C compiler Warning: retaining unknown function `_Main_main_entry.eh' in output from C compiler Warning: retaining unknown function `_ZCMain_main_entry.eh' in output from C compiler Prologue junk?: _siC_entry: LFB142: subq $8, %rsp LCFI0: -- I don't need to solve this, but I thought I should make sure it's known. Jay From prj at po.cwru.edu Sun Mar 30 15:37:35 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Sun Mar 30 15:33:45 2008 Subject: building against gmp in a nonstandard location In-Reply-To: <20080328144314.GA27693@matrix.chaos.earth.li> (Ian Lynagh's message of "Fri\, 28 Mar 2008 14\:43\:14 +0000") References: <20080320143110.GB22737@matrix.chaos.earth.li> <20080320201127.GA7181@matrix.chaos.earth.li> <20080328144314.GA27693@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > the alternative would be to put the whole of $LDFLAGS into the Cabal > buildinfo, but that feels wrong to me. Why so? By setting LDFLAGS, isn't the user asking for exactly that - that those flags be used when linking? paul From igloo at earth.li Sun Mar 30 15:47:44 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Mar 30 15:43:50 2008 Subject: building against gmp in a nonstandard location In-Reply-To: References: <20080320143110.GB22737@matrix.chaos.earth.li> <20080320201127.GA7181@matrix.chaos.earth.li> <20080328144314.GA27693@matrix.chaos.earth.li> Message-ID: <20080330194744.GA25539@matrix.chaos.earth.li> On Sun, Mar 30, 2008 at 03:37:35PM -0400, Paul Jarc wrote: > Ian Lynagh wrote: > > the alternative would be to put the whole of $LDFLAGS into the Cabal > > buildinfo, but that feels wrong to me. > > Why so? By setting LDFLAGS, isn't the user asking for exactly that - > that those flags be used when linking? Perhaps, but readline is only 1 component of what is being built. I guess it would be unlikely to do any harm to use linker flags intended for another component, though. If we want to go this route then I think Cabal should pick up $LDFLAGS automatically when building packages, though. Thanks Ian From Christian.Maeder at dfki.de Mon Mar 31 04:34:25 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Mar 31 05:30:33 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: <47E4F4C8.9040606@dfki.de> References: <47E227AE.3080305@dfki.de> <47E2A64E.6030700@dfki.de> <47E4F4C8.9040606@dfki.de> Message-ID: <47F0A211.8@dfki.de> Christian Maeder wrote: > Conal Elliott wrote: >> The type argument I ran into trouble with represents a value as a list >> of increasing lower bounds, ending in the exact value. min produces >> lower bounds from lower bounds and so is immediately productive before >> even knowing which argument is the lesser one. > > Is this only a matter of efficiency? Can it be compared with a faster > equality check that does not need to evaluate terms always, because it > compares the internal pointers first (and returns True for equal ones)? > Because min returns one of its arguments, "<=" could be defined in terms of "min" and equality. a <= b = min a b == a "==" would cause further evaluations, but if an equality could look up pointers (to unevaluated thunks) no further evaluation might be necessary, so that min and <= do basically the same. > Cheers Christian > > P.S. Maybe it is still a good idea to have a separate user defined class > Min for your purpose, because then you don't have to hand-write compare > functions, but then I don't know the nesting of your data types, though > a generic instance Ord a => Min a may help. > From Christian.Maeder at dfki.de Mon Mar 31 06:41:26 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Mar 31 06:37:31 2008 Subject: patch-applied messages In-Reply-To: <20080326020302.GA26263@haskell.galois.com> References: <20080326020302.GA26263@haskell.galois.com> Message-ID: <47F0BFD6.5070804@dfki.de> (resent this request for cvs-ghc@haskell.org to glasgow-haskell-users) Hi, could the actual change-diff of patches also be posted via this list (or a web-link to the change)? I think this was the case with the old cvs repository. This would teach a bit Haskell programming and how to write expressive log messages. Currently I never look up changes, although the log messages make me curious sometimes. (I rarely use darcs.) Cheers Christian This is just an example (with an uninteresting diff) > Tue Mar 25 17:49:32 PDT 2008 Ian Lynagh > * Remove a redundant type sig > > M ./compiler/ghci/InteractiveUI.hs -1 From conal at conal.net Mon Mar 31 12:45:09 2008 From: conal at conal.net (Conal Elliott) Date: Mon Mar 31 12:41:18 2008 Subject: Expected behavior of "deriving Ord"? In-Reply-To: <47F0A211.8@dfki.de> References: <47E227AE.3080305@dfki.de> <47E2A64E.6030700@dfki.de> <47E4F4C8.9040606@dfki.de> <47F0A211.8@dfki.de> Message-ID: The issue is more than just efficiency. It's vital that these improving values get evaluated as little as possible. In my use for functional reactivity, they represent the times of future event occurrences. Your (<=)-via-min idea might work in some cases, though useful pointer equality can be pretty tricky in the presence of laziness. It's one thing to use pointer equality in lazy memo functions, where false negatives are okay, but in this case, a false negative (pointer inequality between semantically equal values) would give the wrong answer for min. Also, the assumption that min returns one of its arguments is questionable. It's certainly not the case in Warren Burton's implementation of improving values (refs in previous mail). Instead, min merges the lower bounds from each argument into the result. Of course min returns a value semantically equal to one of its arguments, but a pointer-equality test would fail, and a semantic equality test would block. Cheers, - Conal On Mon, Mar 31, 2008 at 1:34 AM, Christian Maeder wrote: > Christian Maeder wrote: > > Conal Elliott wrote: > >> The type argument I ran into trouble with represents a value as a list > >> of increasing lower bounds, ending in the exact value. min produces > >> lower bounds from lower bounds and so is immediately productive before > >> even knowing which argument is the lesser one. > > > > Is this only a matter of efficiency? Can it be compared with a faster > > equality check that does not need to evaluate terms always, because it > > compares the internal pointers first (and returns True for equal ones)? > > > > Because min returns one of its arguments, "<=" could be defined in terms > of "min" and equality. > > a <= b = min a b == a > > "==" would cause further evaluations, but if an equality could look up > pointers (to unevaluated thunks) no further evaluation might be > necessary, so that min and <= do basically the same. > > > Cheers Christian > > > > P.S. Maybe it is still a good idea to have a separate user defined class > > Min for your purpose, because then you don't have to hand-write compare > > functions, but then I don't know the nesting of your data types, though > > a generic instance Ord a => Min a may help. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080331/1597cb47/attachment.htm From simonmar.work at gmail.com Mon Mar 31 19:16:34 2008 From: simonmar.work at gmail.com (Simon Marlow) Date: Mon Mar 31 19:12:44 2008 Subject: 64-bit breakdown In-Reply-To: <20080330181401.77859069@mail.satirist.org> References: <20080330181401.77859069@mail.satirist.org> Message-ID: <47F170D2.30208@gmail.com> Jay Scott wrote: > I have a MacBook (which is a Core 2 Duo) running Mac OS X 10.4. On this > platform, gcc makes 32-bit executables by default, but if you give it - > m64 it makes them 64-bit. I've tried it, and it works. gcc gives its > version as "i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, > Inc. build 5367)" > > But 64-bit doesn't work with my ghc installation (6.8.2 from the binary > distribution on the downloads page). If I compile a "Hello World" > program with -fvia-c -optc-m64, it fails, saying > > -- > Warning: retaining unknown function `_siC_entry.eh' in output from C compiler > Warning: retaining unknown function `_Main_main_entry.eh' in output from > C compiler > Warning: retaining unknown function `_ZCMain_main_entry.eh' in output > from C compiler > Prologue junk?: _siC_entry: > LFB142: > subq $8, %rsp > LCFI0: > -- > > I don't need to solve this, but I thought I should make sure it's known. GHC is built up front to generate either 32-bit or 64-bit code, there's no way to change this for a given GHC build. You should be able to install two versions of GHC side-by-side, but if you need to pass -m64 to gcc to get it to generate 64-bit code, then you will need to invoke ghc with something like ghc -optc-m64 -opta-m64 -optl-m64 ... Cheers, Simon