From simonpj at microsoft.com Fri Oct 2 07:16:50 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 2 06:54:42 2009 Subject: Malformed class assertion with GHCi's output (a -> a ~ T a) In-Reply-To: <3c6288ab0909150450u836b6ebpb152813b41fa4ed9@mail.gmail.com> References: <3c6288ab0909150450u836b6ebpb152813b41fa4ed9@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C367C6C4B69F@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks. I've fixed this. Ian: pls merge if time. Simon Fri Oct 2 12:15:49 BST 2009 simonpj@microsoft.com * Fix pretty-printing precedence for equality constraints M ./compiler/types/TypeRep.lhs -1 +7 From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Sean Leather Sent: 15 September 2009 12:51 To: GHC Users List Subject: Malformed class assertion with GHCi's output (a -> a ~ T a) I queried (:t) the type of something in GHCi, and it told me the value should have the constraint (a -> a ~ T a) among others. When I tried to use this in code, I got a "malformed class assertion." So, I put parentheses around the function type, ((a -> a) ~ T a), and everybody is happy again. Is there something off about the precedence of (~) vs. (->)? Should GHCi print the parentheses? I'm using GHC 6.10.1, so this might already be fixed. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091002/8901cb12/attachment-0001.html From paolo.losi at gmail.com Fri Oct 2 08:51:58 2009 From: paolo.losi at gmail.com (Paolo Losi) Date: Fri Oct 2 08:29:48 2009 Subject: [Haskell-cafe] Ghci dynamic linking (Was: C++ libraries and GHCI) In-Reply-To: <9d4d38820909300529r4deb4a98j6a669c4ba1b6a4ce@mail.gmail.com> References: <2af4014d0909290736l110908f4vaf058c6efdfd0f86@mail.gmail.com> <9d4d38820909300529r4deb4a98j6a669c4ba1b6a4ce@mail.gmail.com> Message-ID: <2af4014d0910020551ib2cac02m70b0f13b0485183b@mail.gmail.com> Thanks for the reply, Max. If it's not something overly complex, I'll try to hack ghc to see if I can produce a working patch... probably that symbol type can be safely ignored by ghci linker. Thanks again for your help Paolo On Wed, Sep 30, 2009 at 2:29 PM, Max Bolingbroke wrote: > (Moving to ghc-users) > > I'd never seen V in nm output before: > > """ > The symbol is a weak object. ?When a weak defined symbol is linked > with a normal defined symbol, the normal defined symbol is used with > no error. ?When a weak undefined symbol is linked and the symbol is > not defined, the value of the ?weak symbol becomes zero with no error. > ?On some systems, uppercase indicates that a default value has been > specified. > """" From luca_ciciriello at hotmail.com Fri Oct 2 12:16:49 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Fri Oct 2 11:54:40 2009 Subject: STM experiment Message-ID: Hi All. I'm very new using Concurrency and STM in Haskell. I'm trying some basic example using STM like this one: module Main where import IO import Control.Concurrent import Control.Concurrent.STM main :: IO () main = do forkIO (hPutStr stdout "Hello") hPutStr stdout " world\n" Loading this module in GHCi and running main, the result is: wHoerllldo On MacOs X 10.5.8 and on WindowsXp Compiling this module with: ghc --make Main.hs -o Main and launcing ./Main the result is just: Terminal> world Am I doing something wrong? My expected result was Hello world (or world Hello) Thanks in advance for any answer. Luca. From pumpkingod at gmail.com Fri Oct 2 12:28:08 2009 From: pumpkingod at gmail.com (Daniel Peebles) Date: Fri Oct 2 12:05:55 2009 Subject: STM experiment In-Reply-To: References: Message-ID: Hi Luca, Just in case you weren't aware of it, your example didn't actually contain any STM (beyond the import), just regular Haskell IO-based concurrency. But the answer to your question is that there's no synchronization on writing to a file descriptor, so both threads are "simultaneously" writing to stdout (hPutStr stdout "...\n" === putStrLn "..." by the way) and result in the interleaved results you see. One solution is to have a thread that effectively owns stdout, and instead of writing to stdout, you write to a Chan (Control.Concurrent.Chan) to talk to the stdout owner, who will then write out your messages. This approach will give you the "Hello world" or "world Hello" output that you were after. Hope this helps, Dan On Fri, Oct 2, 2009 at 12:16 PM, Luca Ciciriello wrote: > Hi All. > I'm very new using Concurrency and STM in Haskell. I'm trying some basic > example using STM like this one: > > module Main > ? ? ? ?where > > import IO > import Control.Concurrent > import Control.Concurrent.STM > > main :: IO () > main = do > ? ? ? ? ? ? ? ? forkIO (hPutStr stdout "Hello") > ? ? ? ? ? ? ? ? hPutStr stdout " world\n" > > > Loading this module in GHCi and running main, the result is: > > wHoerllldo > > On MacOs X 10.5.8 and on WindowsXp > > Compiling this module with: > > ghc --make Main.hs -o Main > > and launcing ./Main the result is just: > > Terminal> world > > Am I doing something wrong? My expected result was Hello world (or world > Hello) > > Thanks in advance for any answer. > > Luca. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From luca_ciciriello at hotmail.com Fri Oct 2 12:42:30 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Fri Oct 2 12:20:26 2009 Subject: STM experiment In-Reply-To: References: Message-ID: Thanks Dan. I understand, your explanation is clear. I just need to study more Haskell. Im' just a beginner but very enthusiastic learning this "think-different" language (I'm a 12-year experienced C++ programmer). Thanks again. Luca. On Oct 2, 2009, at 6:28 PM, Daniel Peebles wrote: > Hi Luca, > > Just in case you weren't aware of it, your example didn't actually > contain any STM (beyond the import), just regular Haskell IO-based > concurrency. > > But the answer to your question is that there's no synchronization on > writing to a file descriptor, so both threads are "simultaneously" > writing to stdout (hPutStr stdout "...\n" === putStrLn "..." by the > way) and result in the interleaved results you see. One solution is to > have a thread that effectively owns stdout, and instead of writing to > stdout, you write to a Chan (Control.Concurrent.Chan) to talk to the > stdout owner, who will then write out your messages. This approach > will give you the "Hello world" or "world Hello" output that you were > after. > > Hope this helps, > Dan > > On Fri, Oct 2, 2009 at 12:16 PM, Luca Ciciriello > wrote: >> Hi All. >> I'm very new using Concurrency and STM in Haskell. I'm trying some >> basic >> example using STM like this one: >> >> module Main >> where >> >> import IO >> import Control.Concurrent >> import Control.Concurrent.STM >> >> main :: IO () >> main = do >> forkIO (hPutStr stdout "Hello") >> hPutStr stdout " world\n" >> >> >> Loading this module in GHCi and running main, the result is: >> >> wHoerllldo >> >> On MacOs X 10.5.8 and on WindowsXp >> >> Compiling this module with: >> >> ghc --make Main.hs -o Main >> >> and launcing ./Main the result is just: >> >> Terminal> world >> >> Am I doing something wrong? My expected result was Hello world (or >> world >> Hello) >> >> Thanks in advance for any answer. >> >> Luca. >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > From byorgey at seas.upenn.edu Fri Oct 2 13:34:06 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Fri Oct 2 13:11:54 2009 Subject: STM experiment In-Reply-To: References: Message-ID: <20091002173406.GA11237@seas.upenn.edu> On Fri, Oct 02, 2009 at 06:16:49PM +0200, Luca Ciciriello wrote: > > Compiling this module with: > > ghc --make Main.hs -o Main > > and launcing ./Main the result is just: > > Terminal> world Also, the reason you only get "world" here is likely because the main thread prints "world" and exits before the forked thread even gets a chance to run. If you want the main thread to wait for the forked thread you must explicitly synchronize them; the most common way to do this is to set up an MVar (or a TVar in STM code) which the main thread reads from, and the forked thread writes to when it is finished in order to signal the main thread. -Brent From igloo at earth.li Sat Oct 3 20:48:19 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Oct 3 20:26:04 2009 Subject: Malformed class assertion with GHCi's output (a -> a ~ T a) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C367C6C4B69F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <3c6288ab0909150450u836b6ebpb152813b41fa4ed9@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C367C6C4B69F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20091004004819.GA30299@matrix.chaos.earth.li> On Fri, Oct 02, 2009 at 12:16:50PM +0100, Simon Peyton-Jones wrote: > Thanks. I've fixed this. > > Ian: pls merge if time. > > Fri Oct 2 12:15:49 BST 2009 simonpj@microsoft.com > * Fix pretty-printing precedence for equality constraints Merged. Thanks Ian From dave at zednenem.com Tue Oct 6 22:37:08 2009 From: dave at zednenem.com (David Menendez) Date: Tue Oct 6 22:14:43 2009 Subject: GHC on Snow Leopard: best practices? Message-ID: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> Is there any consensus about what needs to be done to get a working ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS X wiki page[1] currently links to a blog post[2] that recommends manually patching /usr/bin/ghc, but I have also seen recommendations that people patch ghci, runhaskell, runghc, and hsc2hs. Is that also recommended? If so, there should probably be an updated how-to on the wiki. I expect most Haskell users are capable of patching the scripts themselves, given instructions, but it's hardly convenient. Would it be practical to repackage the current ghc installer with updated scripts for Snow Leopard? If not, will there be updated scripts available for the forthcoming releases of GHC or the Haskell Platform? [1] http://www.haskell.org/haskellwiki/Mac_OS_X [2] http://obvioushints.blogspot.com/2009/09/running-haskell-ghc-on-snow-leopard.html -- Dave Menendez From barney_stratford at fastmail.fm Wed Oct 7 16:58:01 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Wed Oct 7 16:35:36 2009 Subject: GHC on Snow Leopard: best practices? In-Reply-To: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> References: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> Message-ID: <2E75061D-0968-41D2-A0C1-0F237BBDD9D0@fastmail.fm> I'm back in Cambridge now. Snowdonia was great, and just as wet as expected. As far as I'm aware, nobody's got a fully functioning Snow Leopard GHC yet. Just before going away, I tried to use my partly-functioning 64- bit GHC to build 6.10, but found that the stage 1 compiler segfaulted. My plan now is to get 6.8.3 fully working so that we all have something, if a little old, that works. (This is because I need it for another project.) Once I've managed this, I'll post a full set of instructions to get everyone else going too. Then I plan to attempt to get 6.12 working, and provide a binary that can be used for bootstrapping. (I may need some pointers for this.) Incidentally, 6.12 doesn't appear to be in http://www.haskell.org/ghc/dist/ , only in the Darcs repo. Was that intentional? So far, the sticking point has been getting the interactive linker to work. Snow Leopard has much tighter security than its predecessors, so we have to use mmap. Unfortunately, the mmap version of GHC's linker also requires mremap, which is a Linux-only extension that Snow Leopard doesn't have. See you, Barney. From barney_stratford at fastmail.fm Wed Oct 7 17:11:18 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Wed Oct 7 16:48:52 2009 Subject: Snow Leopard GHC In-Reply-To: <36179667-AECA-4CAE-94B7-410ABA15F5EE@cse.unsw.edu.au> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> <4ABB3BD3.8050002@gmail.com> <4ABC7EA1.7000603@gmail.com> <36179667-AECA-4CAE-94B7-410ABA15F5EE@cse.unsw.edu.au> Message-ID: > I am happy to take care of funnelling Barney's changes into the main > repo. However, I think there was at least one more mentioned in > another email. The other change is already in the repo. That's where I borrowed it from in the first place. Barney. From bulat.ziganshin at gmail.com Thu Oct 8 01:59:11 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Oct 8 01:37:29 2009 Subject: GHC on Snow Leopard: best practices? In-Reply-To: <2E75061D-0968-41D2-A0C1-0F237BBDD9D0@fastmail.fm> References: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> <2E75061D-0968-41D2-A0C1-0F237BBDD9D0@fastmail.fm> Message-ID: <14410065559.20091008095911@gmail.com> Hello Barney, Thursday, October 8, 2009, 12:58:01 AM, you wrote: > Incidentally, 6.12 doesn't appear to be in http://www.haskell.org/ghc/dist/ > , only in the Darcs repo. Was that intentional? it's not yet released: http://haskell.org/ghc/ -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From chak at cse.unsw.edu.au Thu Oct 8 02:20:03 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Oct 8 01:57:48 2009 Subject: GHC on Snow Leopard: best practices? In-Reply-To: <2E75061D-0968-41D2-A0C1-0F237BBDD9D0@fastmail.fm> References: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> <2E75061D-0968-41D2-A0C1-0F237BBDD9D0@fastmail.fm> Message-ID: Barney Stratford: > So far, the sticking point has been getting the interactive linker > to work. Snow Leopard has much tighter security than its > predecessors, so we have to use mmap. Unfortunately, the mmap > version of GHC's linker also requires mremap, which is a Linux-only > extension that Snow Leopard doesn't have. Did you mean to say that Snow Leopard in 64-bit mode has tighter security? After all, a Leopard-compiled 32-bit version of ghci works just fine on SL. Manuel From chak at cse.unsw.edu.au Thu Oct 8 03:32:56 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Oct 8 03:10:37 2009 Subject: GHC on Snow Leopard: best practices? In-Reply-To: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> References: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> Message-ID: <0AF0519A-AA33-4123-9C1B-3941C4FA9A30@cse.unsw.edu.au> David Menendez: > Is there any consensus about what needs to be done to get a working > ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS > X wiki page[1] currently links to a blog post[2] that recommends > manually patching /usr/bin/ghc, but I have also seen recommendations > that people patch ghci, runhaskell, runghc, and hsc2hs. Is that also > recommended? If so, there should probably be an updated how-to on the > wiki. Patching /usr/bin/ghc is sufficient to get a version of GHC that passes the regression tests suite in "fast" mode (the same setting that the validate script uses). If you want to use hsc2hs, you need to patch that, too. I haven't found a need to patch the interpreter, though. Manuel From duncan.coutts at googlemail.com Thu Oct 8 05:04:40 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu Oct 8 05:26:25 2009 Subject: GHC on Snow Leopard: best practices? In-Reply-To: <0AF0519A-AA33-4123-9C1B-3941C4FA9A30@cse.unsw.edu.au> References: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> <0AF0519A-AA33-4123-9C1B-3941C4FA9A30@cse.unsw.edu.au> Message-ID: <1254992680.28525.3463.camel@localhost> On Thu, 2009-10-08 at 18:32 +1100, Manuel M T Chakravarty wrote: > David Menendez: > > Is there any consensus about what needs to be done to get a working > > ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS > > X wiki page[1] currently links to a blog post[2] that recommends > > manually patching /usr/bin/ghc, but I have also seen recommendations > > that people patch ghci, runhaskell, runghc, and hsc2hs. Is that also > > recommended? If so, there should probably be an updated how-to on the > > wiki. > > Patching /usr/bin/ghc is sufficient to get a version of GHC that > passes the regression tests suite in "fast" mode (the same setting > that the validate script uses). If you want to use hsc2hs, you need > to patch that, too. I haven't found a need to patch the interpreter, > though. And they almost certainly do want hsc2hs (even if they don't know it) because it's used by all sorts of other libs. The first one people hit is the zlib binding which is used by cabal-install. It appears to compile ok but then fails the version check performed by the zlib C library (eg when someone does cabal update). Duncan From barney_stratford at fastmail.fm Thu Oct 8 05:57:33 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Thu Oct 8 05:35:06 2009 Subject: Snow Leopard GHC In-Reply-To: <4AC0B0C8.9010002@gmail.com> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <4ABC7EA1.7000603@gmail.com> <200909251215.55609.daniel.is.fischer@web.de> <318B6841-BEE2-4636-AF74-25C3854B7DE9@fastmail.fm> <4AC0B0C8.9010002@gmail.com> Message-ID: <960A909D-E70C-497A-8CC2-5E44BDA39297@fastmail.fm> Latest set of problems. I've tried using the i386 build of GHC 6.10.4 to build the x86_64 version in the manner that I described in an earlier post. I'm not getting any segfaults now, but instead it says the following during make: /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal-bin /usr/bin/ ghc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/ bootstrapping.conf 1.6.0.3 build --distpref dist-install --ghc- option=-H32m --ghc-option=-O --ghc-option=-I/sw/include --ghc-option=- L/sw/lib --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-install/ build/installPackage/installPackage-tmp/Main.o ) /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3616:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3677:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3709:0: Bignum number illegal. Absolute 0 assumed. etc... Looking in the assembler file, I get stuff like: Lc4a1: jmp *-16(%r13) .long _s3j4_info - _s3j4_info_dsp .text .align 3 _s3lv_info_dsp: .quad _Main_a1_srt-(_s3lv_info)+72 .quad 3 .quad 37590000000000174587920 _s3lv_info: Lc4bb: leaq -16(%rbp),%rax cmpq %r14,%rax (That bignum is at line 3616.) Any ideas what might be causing this? Cheers, Barney. From red5_2 at hotmail.com Thu Oct 8 09:46:08 2009 From: red5_2 at hotmail.com (C Rodrigues) Date: Thu Oct 8 09:25:14 2009 Subject: Ghci dynamic linking (Was: C++ libraries and GHCI) In-Reply-To: <20091008053728.CF0B832493C@www.haskell.org> References: <20091008053728.CF0B832493C@www.haskell.org> Message-ID: I've encountered the problem with weak symbols also, and filed a bug report against ghc (#3333). Weak symbols are used by gcc (with elf) to accommodate C++'s compilation model. In C++, it's permitted to define class methods and template code in header files. Because header files can be included in many source files, the same object code will appear in many object files. It's the linker's job to merge these definitions. There's no standard way of handling C++ linking, unfortunately, so handling weak symbols won't necessarily solve the problem for every compiler. If there will be no cross-references involving weak symbols between different .a files, such as when you have a C++ library that doesn't depend on other C++ libraries, then it should be sufficient to treat a weak defined symbol as 'defined' and a weak undefined symbol as NULL. However, I don't know if this is really a common case; most C++ code depends on libstdc++, in which case there may be multiple weak symbol definitions. --heatsink > > Thanks for the reply, Max. > > If it's not something overly complex, I'll try to hack ghc > to see if I can produce a working patch... > > probably that symbol type can be safely ignored by > ghci linker. > > Thanks again for your help > Paolo > > > On Wed, Sep 30, 2009 at 2:29 PM, Max Bolingbroke > wrote: > > (Moving to ghc-users) > > > > I'd never seen V in nm output before: > > > > """ > > The symbol is a weak object. When a weak defined symbol is linked > > with a normal defined symbol, the normal defined symbol is used with > > no error. When a weak undefined symbol is linked and the symbol is > > not defined, the value of the weak symbol becomes zero with no error. > > On some systems, uppercase indicates that a default value has been > > specified. > > """" > _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091008/db879bbc/attachment.html From marlowsd at gmail.com Thu Oct 8 09:57:31 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 8 09:35:14 2009 Subject: GHC on Snow Leopard: best practices? In-Reply-To: <2E75061D-0968-41D2-A0C1-0F237BBDD9D0@fastmail.fm> References: <49a77b7a0910061937h3e9dc7c8v92965dc9f0a92405@mail.gmail.com> <2E75061D-0968-41D2-A0C1-0F237BBDD9D0@fastmail.fm> Message-ID: <4ACDEFCB.2030908@gmail.com> On 07/10/2009 21:58, Barney Stratford wrote: > I'm back in Cambridge now. Snowdonia was great, and just as wet as > expected. > > As far as I'm aware, nobody's got a fully functioning Snow Leopard GHC > yet. Just before going away, I tried to use my partly-functioning 64-bit > GHC to build 6.10, but found that the stage 1 compiler segfaulted. > > My plan now is to get 6.8.3 fully working so that we all have something, > if a little old, that works. (This is because I need it for another > project.) Once I've managed this, I'll post a full set of instructions > to get everyone else going too. Then I plan to attempt to get 6.12 > working, and provide a binary that can be used for bootstrapping. (I may > need some pointers for this.) > > Incidentally, 6.12 doesn't appear to be in > http://www.haskell.org/ghc/dist/ , only in the Darcs repo. Was that > intentional? > > So far, the sticking point has been getting the interactive linker to > work. Snow Leopard has much tighter security than its predecessors, so > we have to use mmap. Unfortunately, the mmap version of GHC's linker > also requires mremap, which is a Linux-only extension that Snow Leopard > doesn't have. I believe we fixed the mremap dependency in 6.10, and that was also when we added support for libffi. I expect you'll have a much easier time getting GHCi to work with 6.10 or 6.12, so use 6.8.x for bootstrapping only. Cheers, Simon From marlowsd at gmail.com Thu Oct 8 10:03:00 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 8 09:40:38 2009 Subject: Snow Leopard GHC In-Reply-To: <960A909D-E70C-497A-8CC2-5E44BDA39297@fastmail.fm> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <4ABC7EA1.7000603@gmail.com> <200909251215.55609.daniel.is.fischer@web.de> <318B6841-BEE2-4636-AF74-25C3854B7DE9@fastmail.fm> <4AC0B0C8.9010002@gmail.com> <960A909D-E70C-497A-8CC2-5E44BDA39297@fastmail.fm> Message-ID: <4ACDF114.4010902@gmail.com> On 08/10/2009 10:57, Barney Stratford wrote: > Latest set of problems. I've tried using the i386 build of GHC 6.10.4 to > build the x86_64 version in the manner that I described in an earlier > post. I'm not getting any segfaults now, but instead it says the > following during make: > > /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal-bin /usr/bin/ghc > /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf > 1.6.0.3 build --distpref dist-install --ghc-option=-H32m --ghc-option=-O > --ghc-option=-I/sw/include --ghc-option=-L/sw/lib --ghc-option=-Wall > Preprocessing executables for installPackage-1.0... > Building installPackage-1.0... > [1 of 1] Compiling Main ( installPackage.hs, > dist-install/build/installPackage/installPackage-tmp/Main.o ) > > /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3616:0: > > Bignum number illegal. Absolute 0 assumed. > > /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3677:0: > > Bignum number illegal. Absolute 0 assumed. > > /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3709:0: > > Bignum number illegal. Absolute 0 assumed. > > etc... > > > Looking in the assembler file, I get stuff like: > > Lc4a1: > jmp *-16(%r13) > .long _s3j4_info - _s3j4_info_dsp > .text > .align 3 > _s3lv_info_dsp: > .quad _Main_a1_srt-(_s3lv_info)+72 > .quad 3 > .quad 37590000000000174587920 > _s3lv_info: > Lc4bb: > leaq -16(%rbp),%rax > cmpq %r14,%rax > > (That bignum is at line 3616.) Any ideas what might be causing this? Almost certainly a misconfiguration somewhere, but it's hard to tell where. Something thinks that words are 32 bits when they are in fact 64, or vice versa. So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? Cheers, Simon From barney_stratford at fastmail.fm Thu Oct 8 10:07:32 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Thu Oct 8 09:45:06 2009 Subject: Snow Leopard GHC In-Reply-To: <4ACDF114.4010902@gmail.com> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <4ABC7EA1.7000603@gmail.com> <200909251215.55609.daniel.is.fischer@web.de> <318B6841-BEE2-4636-AF74-25C3854B7DE9@fastmail.fm> <4AC0B0C8.9010002@gmail.com> <960A909D-E70C-497A-8CC2-5E44BDA39297@fastmail.fm> <4ACDF114.4010902@gmail.com> Message-ID: <51711A91-3D46-4101-9F46-67CB7E476644@fastmail.fm> > So which compiler is generating the bogus code here? Is this the > stage1 x86-64 compiler, or the i386 compiler? It's the stage1 x86_64 compiler. The problem here is that 37590000000000174587920 doesn't even fit into 64 bits, hence the assembler's complaint. Cheers, Barney. From marlowsd at gmail.com Thu Oct 8 11:12:28 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 8 10:50:02 2009 Subject: Snow Leopard GHC In-Reply-To: <51711A91-3D46-4101-9F46-67CB7E476644@fastmail.fm> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <4ABC7EA1.7000603@gmail.com> <200909251215.55609.daniel.is.fischer@web.de> <318B6841-BEE2-4636-AF74-25C3854B7DE9@fastmail.fm> <4AC0B0C8.9010002@gmail.com> <960A909D-E70C-497A-8CC2-5E44BDA39297@fastmail.fm> <4ACDF114.4010902@gmail.com> <51711A91-3D46-4101-9F46-67CB7E476644@fastmail.fm> Message-ID: <4ACE015C.2090904@gmail.com> On 08/10/2009 15:07, Barney Stratford wrote: >> So which compiler is generating the bogus code here? Is this the >> stage1 x86-64 compiler, or the i386 compiler? > It's the stage1 x86_64 compiler. The problem here is that > 37590000000000174587920 doesn't even fit into 64 bits, hence the > assembler's complaint. Yes, I see that. GHC keeps these values as Integers internally, so it's possible that some misconfiguration has caused it to produce a values that's out of range, although I agree that the fact that it is bigger than even 2^64 is quite suspicious. I suggest dumping out some intermediate code, e.g. -dppr-cmm -dppr-opt-cmm. If that fails to narrow it down, then you may need to add some debug traces the native code generator to find out where these values are coming from. Cheers, Simon From colin at colina.demon.co.uk Thu Oct 8 14:27:45 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Thu Oct 8 14:05:16 2009 Subject: Ghci fails to load modules, but ghc compiles OK Message-ID: I've been using ghc 6.10.3 on 64-bit Linux to compile my application, and it runs OK, modulo bugs. I want to debug a problem, so I load it in ghci, but when i type main I get: Loading package network-2.2.1.1 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol my_inet_ntoa whilst processing object file /usr/lib64/ghc-6.10.3/network-2.2.1.1/HSnetwork-2.2.1.1.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. Why would ghci have a problem, but not ghc? -- Colin Adams Preston Lancashire From duncan.coutts at googlemail.com Fri Oct 9 07:37:26 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Oct 9 07:30:52 2009 Subject: Ghci fails to load modules, but ghc compiles OK In-Reply-To: References: Message-ID: <1255088246.28525.6507.camel@localhost> On Thu, 2009-10-08 at 19:27 +0100, Colin Paul Adams wrote: > I've been using ghc 6.10.3 on 64-bit Linux to compile my application, > and it runs OK, modulo bugs. > > I want to debug a problem, so I load it in ghci, but when i type main > I get: > > Loading package network-2.2.1.1 ... > > GHCi runtime linker: fatal error: I found a duplicate definition for symbol > my_inet_ntoa > whilst processing object file > /usr/lib64/ghc-6.10.3/network-2.2.1.1/HSnetwork-2.2.1.1.o > This could be caused by: > * Loading two different object files which export the same symbol > * Specifying the same object file twice on the GHCi command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > GHCi cannot safely continue in this situation. Exiting now. Sorry. > > Why would ghci have a problem, but not ghc? Because the system linker does not care about duplicate definitions for symbols. It just merrily picks the first one and resolves all references to point that first one. The GHCi linker is a tad more careful. What you're probably doing is loading two versions of the network package (eg indirectly as a dependencies of other packages) and they both have an unversioned C symbol in them. The Haskell symbols are all versioned which is why they do not clash. Duncan From igloo at earth.li Sun Oct 11 16:41:53 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Oct 11 16:19:19 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 Message-ID: <20091011204153.GA5338@matrix.chaos.earth.li> Hi all, We are pleased to (finally!) announce the first release candidate for GHC 6.12.1: http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ As well as the source tarball: ghc-6.12.0.20091010-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team From philip.weaver at gmail.com Mon Oct 12 03:17:15 2009 From: philip.weaver at gmail.com (Philip Weaver) Date: Mon Oct 12 02:54:34 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: On Sun, Oct 11, 2009 at 1:41 PM, Ian Lynagh wrote: > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > Thanks! I have been eager to try out 6.12. Unlike many of the recent snapshots, this one built and installed fine on Mac OS X 10.6 :). Is there an extralibs tarball that I should use with this? I installed the release candidate without said tarball. First, I noticed that my old version of cabal-install could not parse the output from ghc-pkg-6.12.0.20091010: cabal: failed to parse output of 'ghc-pkg dump' Then, when I tried to build the network package manually, I got this: Building network-2.2.1.4... [1 of 5] Compiling Network.URI ( Network/URI.hs, dist/build/Network/URI.o ) [2 of 5] Compiling Network.Socket.Internal ( dist/build/Network/Socket/Internal.hs, dist/build/Network/Socket/Internal.o ) [3 of 5] Compiling Network.Socket ( dist/build/Network/Socket.hs, dist/build/Network/Socket.o ) Network/Socket.hsc:1707:45: Not in scope: data constructor `System.Posix.Internals.Stream' - Philip > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > 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/20091012/d77e82cc/attachment.html From mechvel at botik.ru Mon Oct 12 04:04:16 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Oct 12 03:51:34 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <20091012080416.GA1106@scico.botik.ru> I have downloaded ghc-6.12.0.20091010-src.tar.bz2. But where to read the release notes? ANNOUNCE shows ``version 6.10.1'', and lists the old features. What is the difference of 6.12.1 w.r.to 6.10.4 ? Regards, ----------------- Serge Mechveliani mechvel@botik.ru On Sun, Oct 11, 2009 at 09:41:53PM +0100, Ian Lynagh wrote: > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From marlowsd at gmail.com Mon Oct 12 04:32:05 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 12 04:09:29 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091012080416.GA1106@scico.botik.ru> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> Message-ID: <4AD2E985.1070201@gmail.com> On 12/10/2009 09:04, Serge D. Mechveliani wrote: > I have downloaded ghc-6.12.0.20091010-src.tar.bz2. > But where to read the release notes? > ANNOUNCE shows ``version 6.10.1'', and lists the old features. > What is the difference of 6.12.1 w.r.to 6.10.4 ? Release notes here, for now: http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1.html Cheers, Simon > > Regards, > > ----------------- > Serge Mechveliani > mechvel@botik.ru > > > > On Sun, Oct 11, 2009 at 09:41:53PM +0100, Ian Lynagh wrote: >> >> Hi all, >> >> We are pleased to (finally!) announce the first release candidate >> for GHC 6.12.1: >> >> http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ >> >> As well as the source tarball: >> ghc-6.12.0.20091010-src.tar.bz2 >> there are installers for Windows (i386) and OS X (i386), and binary >> distributions for x86_64/Linux and i386/Linux. For the Linux binary >> distributions, the "linux-n" tarballs are recommended over the "linux" >> tarballs. >> >> >> Please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> >> Thanks >> Ian, on behalf of the GHC team >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Mon Oct 12 04:34:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 12 04:12:05 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <4AD2EA1C.5050303@gmail.com> On 12/10/2009 08:17, Philip Weaver wrote: > > > On Sun, Oct 11, 2009 at 1:41 PM, Ian Lynagh > wrote: > > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > > As well as the source tarball: > ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks! I have been eager to try out 6.12. Unlike many of the recent > snapshots, this one built and installed fine on Mac OS X 10.6 :). > > Is there an extralibs tarball that I should use with this? I installed > the release candidate without said tarball. First, I noticed that my > old version of cabal-install could not parse the output from > ghc-pkg-6.12.0.20091010: > > cabal: failed to parse output of 'ghc-pkg dump' Yes, work is in progress on cabal-install to update it to work with GHC 6.12.1. For now you have to use Cabal manually (runhaskell Setup configure, etc.). > Then, when I tried to build the network package manually, I got this: > > Building network-2.2.1.4... > [1 of 5] Compiling Network.URI ( Network/URI.hs, > dist/build/Network/URI.o ) > [2 of 5] Compiling Network.Socket.Internal ( > dist/build/Network/Socket/Internal.hs, > dist/build/Network/Socket/Internal.o ) > [3 of 5] Compiling Network.Socket ( dist/build/Network/Socket.hs, > dist/build/Network/Socket.o ) > > Network/Socket.hsc:1707:45: > Not in scope: data constructor `System.Posix.Internals.Stream' I think you may need the darcs version of the network package. Cheers, Simon From bulat.ziganshin at gmail.com Mon Oct 12 05:07:33 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Oct 12 04:54:58 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <4AD2E985.1070201@gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> <4AD2E985.1070201@gmail.com> Message-ID: <456141384.20091012130733@gmail.com> Hello Simon, Monday, October 12, 2009, 12:32:05 PM, you wrote: > Release notes here, for now: > http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1.html 1. it says >The following options are all described in Section 4.15.3, ?RTS >options to control the garbage collector?. > * The flag +RTS -N now automatically determines how many threads to > use, based on the number of CPUs in your machine. actually -N is decribed in "4.13.2. RTS options for SMP parallelism" also, i propose to enable +RTS -N by default. Haskell is very popular as multithreaded language, don't fool novices! > "The -gn RTS option has been removed, except that -g1 is still > accepted for backwards compatibility. " why not ignore whole option for a 6.12.*? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Mon Oct 12 07:20:42 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Oct 12 06:58:02 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <20091012112042.GA7220@matrix.chaos.earth.li> Hi Philip, Thanks for the feedback! On Mon, Oct 12, 2009 at 12:17:15AM -0700, Philip Weaver wrote: > > > Thanks! I have been eager to try out 6.12. Unlike many of the recent > snapshots, this one built and installed fine on Mac OS X 10.6 :). Interesting, I thought there were still problems there. Does ghci work too? > Is there an extralibs tarball that I should use with this? No; extralibs no longer exist. Instead, we'll be recommending that most users wait until a Haskell Platform release is available that comes with the compiler. Thanks Ian From barney_stratford at fastmail.fm Mon Oct 12 07:23:16 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Mon Oct 12 07:00:38 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091012112042.GA7220@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012112042.GA7220@matrix.chaos.earth.li> Message-ID: <118132FF-6B81-48AD-B846-98CCEF29EF20@fastmail.fm> >> this one built and installed fine on Mac OS X 10.6 :). > Interesting, I thought there were still problems there. I assume that's a 32-bit version. The problems manifest themselves only when you compile a 64-bit GHC. I'm still trying to get mine working - no luck yet, but will keep you posted. Barney. From marlowsd at gmail.com Mon Oct 12 08:02:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 12 07:39:58 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <456141384.20091012130733@gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> <4AD2E985.1070201@gmail.com> <456141384.20091012130733@gmail.com> Message-ID: <4AD31AD8.4050307@gmail.com> On 12/10/2009 10:07, Bulat Ziganshin wrote: > Hello Simon, > > Monday, October 12, 2009, 12:32:05 PM, you wrote: > >> Release notes here, for now: >> http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1.html > > 1. it says > >> The following options are all described in Section 4.15.3, ?RTS >> options to control the garbage collector?. >> * The flag +RTS -N now automatically determines how many threads to >> use, based on the number of CPUs in your machine. > > actually -N is decribed in "4.13.2. RTS options for SMP parallelism" > > also, i propose to enable +RTS -N by default. Haskell is very popular > as multithreaded language, don't fool novices! I don't think we're ready for that yet. The current implementation assumes that it has access to the given number of cores, and performance degrades severely if it doesn't. So for example, using -N2 on a 2-core machine may perform badly unless the machine is otherwise very quiet. I've been working on improving this, but it's quite difficult: using spinlocks and busy-waiting is a lot faster than using sleep/wakeup synchronisation when you really have all the cores, but when you lose a core things go haywire. I've tried the usual "spin for a bit and then go to sleep" technique, but even that can adversely affect performance when you really do have all the cores, because sometimes we do have to spin for quite a long time. The only proper solution is not to synchronise at all, which is what we're looking at now (CPU-independent GC). You may notice this effect more with 6.12.1 because we turned on the parallel GC for generation 0 by default. This improves performance for parallel programs a lot (see ICFP paper), but also means there are many more all-core synchronisation points, which in turn will really hurt if any of our threads is descheduled by the OS. So right now, on a dual-core I'd recommend using -N2 -qg1 (don't use parallel GC in gen 0), or -N2 -H. >> "The -gn RTS option has been removed, except that -g1 is still >> accepted for backwards compatibility. " > > why not ignore whole option for a 6.12.*? Because people might be using -g1? Cheers, Simon From Christian.Maeder at dfki.de Mon Oct 12 08:12:55 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Oct 12 07:50:16 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <4AD31D47.7020203@dfki.de> This new version of ghc can no longer read ISO-8859 text. Text is cut off after the first non-ascii character (ie. ?). Is this somewhere documented? What is the recommended way to handle such text? Cheers Christian Ian Lynagh wrote: > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team From carsten at codimi.de Mon Oct 12 07:34:36 2009 From: carsten at codimi.de (Carsten Schultz) Date: Mon Oct 12 07:57:22 2009 Subject: STM experiment In-Reply-To: <20091002173406.GA11237@seas.upenn.edu> References: <20091002173406.GA11237@seas.upenn.edu> Message-ID: Brent Yorgey schrieb: > On Fri, Oct 02, 2009 at 06:16:49PM +0200, Luca Ciciriello wrote: >> Compiling this module with: >> >> ghc --make Main.hs -o Main >> >> and launcing ./Main the result is just: >> >> Terminal> world > > Also, the reason you only get "world" here is likely because the main > thread prints "world" and exits before the forked thread even gets a > chance to run. If you want the main thread to wait for the forked > thread you must explicitly synchronize them; the most common way to do > this is to set up an MVar (or a TVar in STM code) which the main > thread reads from, and the forked thread writes to when it is > finished in order to signal the main thread. For example, using a utility function I wrote some time ago: module Main(main) where import IO import Control.Concurrent parallel :: [IO a] -> IO [a] parallel = foldr (\a c -> do v <- newEmptyMVar forkIO (a >>= putMVar v) xs <- c x <- takeMVar v return (x:xs)) (return []) main = parallel [hPutStr stdout "Hello", hPutStr stdout " world\n"] There might be better ways to do this, but I hope that this will also be interesting because of the functional abstractions that are used. Note that this will execute two forkIOs, not one as the original code. If that is not desirable, foldr1 could have been used. Best Carsten From marlowsd at gmail.com Mon Oct 12 08:28:42 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 12 08:06:20 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <4AD31D47.7020203@dfki.de> References: <20091011204153.GA5338@matrix.chaos.earth.li> <4AD31D47.7020203@dfki.de> Message-ID: <4AD320FA.1050404@gmail.com> On 12/10/2009 13:12, Christian Maeder wrote: > This new version of ghc can no longer read ISO-8859 text. Text is cut > off after the first non-ascii character (ie. ?). > > Is this somewhere documented? What is the recommended way to handle such > text? Take a look at this: http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know-about-unicode-io-in-ghc-6-12-1/ and if you have any more questions, please post them here. Cheers, Simon From luca_ciciriello at hotmail.com Mon Oct 12 08:42:46 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Mon Oct 12 08:20:05 2009 Subject: STM experiment In-Reply-To: References: <20091002173406.GA11237@seas.upenn.edu> Message-ID: Thanks Carsten, I've compiled your example and all works as expected. Just a note. If I load the module in GHCi (intead of compiling it) and launch main function the result is quite strange. I obtain: He lwloorld [(),()] Luca. > To: glasgow-haskell-users@haskell.org > From: carsten@codimi.de > Date: Mon, 12 Oct 2009 13:34:36 +0200 > Subject: Re: STM experiment > > Brent Yorgey schrieb: > > On Fri, Oct 02, 2009 at 06:16:49PM +0200, Luca Ciciriello wrote: > >> Compiling this module with: > >> > >> ghc --make Main.hs -o Main > >> > >> and launcing ./Main the result is just: > >> > >> Terminal> > > > > Also, the reason you only get "world" here is likely because the main > > thread prints "world" and exits before the forked thread even gets a > > chance to run. If you want the main thread to wait for the forked > > thread you must explicitly synchronize them; the most common way to do > > this is to set up an MVar (or a TVar in STM code) which the main > > thread reads from, and the forked thread writes to when it is > > finished in order to signal the main thread. > > For example, using a utility function I wrote some time ago: > > > module Main(main) where > > import IO > import Control.Concurrent > > parallel :: [IO a] -> IO [a] > parallel = foldr (\a c -> > do > v <- newEmptyMVar > forkIO (a >>= putMVar v) > xs <- c > x <- takeMVar v > return (x:xs)) > (return []) > > main = parallel [hPutStr stdout "Hello", hPutStr stdout " world\n"] > > > > There might be better ways to do this, but I hope that this will also be > interesting because of the functional abstractions that are used. Note > that this will execute two forkIOs, not one as the original code. If > that is not desirable, foldr1 could have been used. > > Best > > Carsten > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _________________________________________________________________ Learn how to add other email accounts to Hotmail in 3 easy steps. http://clk.atdmt.com/UKM/go/167688463/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091012/822d273d/attachment-0001.html From carsten at codimi.de Mon Oct 12 09:30:16 2009 From: carsten at codimi.de (Carsten Schultz) Date: Mon Oct 12 09:07:58 2009 Subject: STM experiment In-Reply-To: References: <20091002173406.GA11237@seas.upenn.edu> Message-ID: Luca Ciciriello schrieb: > Thanks Carsten, I've compiled your example and all works as expected. > > Just a note. > If I load the module in GHCi (intead of compiling it) and launch main > function the result is quite strange. I obtain: > > He lwloorld So we actually observe the concurrency here, nice. > [(),()] The result of the computation: Both instances of hPutStr return (), and parallel assembles these into [(),()]. The intersesting thing is that ghci suppresses an IO result if it is of type (), but not otherwise. Prelude> return () :: IO () Prelude> return [(),()] :: IO [()] [(),()] Prelude> I did not know this. Carsten >> module Main(main) where >> >> import IO >> import Control.Concurrent >> >> parallel :: [IO a] -> IO [a] >> parallel = foldr (\a c -> >> do >> v <- newEmptyMVar >> forkIO (a >>= putMVar v) >> xs <- c >> x <- takeMVar v >> return (x:xs)) >> (return []) >> >> main = parallel [hPutStr stdout "Hello", hPutStr stdout " world\n"] From duncan.coutts at googlemail.com Mon Oct 12 10:58:43 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Oct 12 10:57:52 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <456141384.20091012130733@gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> <4AD2E985.1070201@gmail.com> <456141384.20091012130733@gmail.com> Message-ID: <1255359523.8777.795.camel@localhost> On Mon, 2009-10-12 at 13:07 +0400, Bulat Ziganshin wrote: > also, i propose to enable +RTS -N by default. Haskell is very popular > as multithreaded language, don't fool novices! Note that you'd also have to enable -threaded by default. This would have other surprising effects (like breaking most GUI progs). Duncan From bulat.ziganshin at gmail.com Mon Oct 12 11:29:04 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Oct 12 11:06:36 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <1255359523.8777.795.camel@localhost> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> <4AD2E985.1070201@gmail.com> <456141384.20091012130733@gmail.com> <1255359523.8777.795.camel@localhost> Message-ID: <1423889684.20091012192904@gmail.com> Hello Duncan, Monday, October 12, 2009, 6:58:43 PM, you wrote: >> also, i propose to enable +RTS -N by default. Haskell is very popular >> as multithreaded language, don't fool novices! > Note that you'd also have to enable -threaded by default. This would > have other surprising effects (like breaking most GUI progs). afair, it's on by default for a few years and yes, i had SERIOUS problems with it in my GUI program :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Christian.Maeder at dfki.de Mon Oct 12 12:43:51 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Oct 12 12:21:13 2009 Subject: haddock problem. Was: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <4AD35CC7.3060807@dfki.de> Hi, with http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ghc-6.12.0.20091010-i386-unknown-linux-n.tar.bz2 installed (under /local/maeder/) I get the following "internal Haddock or GHC error". I have no file /local/maeder/lib/ghc-6.12.0.20091010/html/haddock.css but a file /local/maeder/share/doc/ghc/html/html/haddock.css and I run: ./Setup configure -O --prefix=/local/maeder ./Setup build ./Setup haddock ./Setup install Cheers Christian P.S. I wonder why "Registering" is done twice Configuring packedstring-0.1.0.1... Preprocessing library packedstring-0.1.0.1... Building packedstring-0.1.0.1... [1 of 1] Compiling Data.PackedString ( Data/PackedString.hs, dist/build/Data/PackedString.o ) Registering packedstring-0.1.0.1... Running Haddock for packedstring-0.1.0.1... Preprocessing library packedstring-0.1.0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: ffi-1.0, rts-1.0 haddock: internal Haddock or GHC error: /local/maeder//lib/ghc-6.12.0.20091010/html/haddock.css: openFile: does not exist (No such file or directory) Installing library in /local/maeder/lib/packedstring-0.1.0.1/ghc-6.12.0.20091010 Registering packedstring-0.1.0.1... From duncan.coutts at googlemail.com Mon Oct 12 13:02:40 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Oct 12 12:39:58 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <1423889684.20091012192904@gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> <4AD2E985.1070201@gmail.com> <456141384.20091012130733@gmail.com> <1255359523.8777.795.camel@localhost> <1423889684.20091012192904@gmail.com> Message-ID: <1255366960.8777.799.camel@localhost> On Mon, 2009-10-12 at 19:29 +0400, Bulat Ziganshin wrote: > Hello Duncan, > > Monday, October 12, 2009, 6:58:43 PM, you wrote: > > >> also, i propose to enable +RTS -N by default. Haskell is very popular > >> as multithreaded language, don't fool novices! > > > Note that you'd also have to enable -threaded by default. This would > > have other surprising effects (like breaking most GUI progs). > > afair, it's on by default for a few years With runghc and ghci you get the threaded rts by default. For compiled standalone programs the single threaded rts is still the default. You have to link using the -threaded flag to get the threaded rts. > and yes, i had SERIOUS problems with it in my GUI program :) Yeah, it's a long-standing tricky issue. Duncan From luca_ciciriello at hotmail.com Mon Oct 12 13:16:20 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Mon Oct 12 12:53:41 2009 Subject: replace GHC 6.6 with 6.10.4 in VisualHaskell In-Reply-To: References: <20091002173406.GA11237@seas.upenn.edu> Message-ID: Is there a way to use VisualHaskel with GHC 6.10.4? Luca From mechvel at botik.ru Mon Oct 12 13:31:41 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Oct 12 13:18:56 2009 Subject: bug in 6.12.1-pre Message-ID: <20091012173141.GA30001@scico.botik.ru> Dear GHC team, I tried ghc-6.12.0.20091010-src.tar.bz2 on Linux, Debian, i386-* And it cannot compile my Dumatel project. It fails at the segment: module Bug where compose :: [a -> a] -> a -> a compose = foldr (.) id class Compose a where compose1 :: a -> a -> a ghc -c -O Bug.hs reports /tmp/ghc29984_0/ghc29984_0.s: Assembler messages: /tmp/ghc29984_0/ghc29984_0.s:23:0: Error: symbol `Bug_compose1_closure' is already defined /tmp/ghc29984_0/ghc29984_0.s:102:0: Error: symbol `Bug_compose1_info' is already defined `-O' is essential here. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From igloo at earth.li Mon Oct 12 14:28:52 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Oct 12 14:06:11 2009 Subject: bug in 6.12.1-pre In-Reply-To: <20091012173141.GA30001@scico.botik.ru> References: <20091012173141.GA30001@scico.botik.ru> Message-ID: <20091012182852.GA9095@matrix.chaos.earth.li> On Mon, Oct 12, 2009 at 09:31:41PM +0400, Serge D. Mechveliani wrote: > Dear GHC team, > > I tried ghc-6.12.0.20091010-src.tar.bz2 > on Linux, Debian, i386-* > And it cannot compile my Dumatel project. It fails at the segment: Great bug report, thanks. I've filed a ticket for it here: http://hackage.haskell.org/trac/ghc/ticket/3579 Thanks Ian From byorgey at seas.upenn.edu Mon Oct 12 16:04:23 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Mon Oct 12 15:41:40 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <20091012200423.GA4836@seas.upenn.edu> What's the canonical way to install a version of ghc but not have it be the default? i.e., I'd like to try testing this release candidate but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg' etc. to still be aliases to ghc-6.10.4, instead of being overwritten by the 6.12.1 install. -Brent On Sun, Oct 11, 2009 at 09:41:53PM +0100, Ian Lynagh wrote: > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ben.franksen at online.de Mon Oct 12 17:31:41 2009 From: ben.franksen at online.de (Ben Franksen) Date: Mon Oct 12 17:09:35 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> <4AD2E985.1070201@gmail.com> Message-ID: Simon Marlow wrote: > On 12/10/2009 09:04, Serge D. Mechveliani wrote: >> I have downloaded ghc-6.12.0.20091010-src.tar.bz2. >> But where to read the release notes? >> ANNOUNCE shows ``version 6.10.1'', and lists the old features. >> What is the difference of 6.12.1 w.r.to 6.10.4 ? > > Release notes here, for now: > > http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1.html In section 1.5.2. Warnings there is a duplication: """ * There are two new warnings if a monadic result of type other than m () is used in a do block, but its result is not bound. The flags -fwarn-unused-do-bind and -fwarn-wrong-do-bind control these warnings. * There is a new warning if a monadic result of type other than m () is not bound. The flag -fwarn-unused-do-bind controls this warning. """ Cheers Ben From ben.franksen at online.de Mon Oct 12 17:39:17 2009 From: ben.franksen at online.de (Ben Franksen) Date: Mon Oct 12 17:17:14 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012200423.GA4836@seas.upenn.edu> Message-ID: Brent Yorgey wrote: > What's the canonical way to install a version of ghc but not have it > be the default? i.e., I'd like to try testing this release candidate > but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg' > etc. to still be aliases to ghc-6.10.4, instead of being overwritten > by the 6.12.1 install. AFAIK think the answer is: compile from source and use --prefix option to ./configure. Cheers Ben From duncan.coutts at googlemail.com Mon Oct 12 18:16:23 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Oct 12 18:45:32 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091012200423.GA4836@seas.upenn.edu> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012200423.GA4836@seas.upenn.edu> Message-ID: <1255385783.8777.991.camel@localhost> On Mon, 2009-10-12 at 16:04 -0400, Brent Yorgey wrote: > What's the canonical way to install a version of ghc but not have it > be the default? i.e., I'd like to try testing this release candidate > but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg' > etc. to still be aliases to ghc-6.10.4, instead of being overwritten > by the 6.12.1 install. What I do is keep my default as /usr/bin/ghc, then when I install testing versions I just rm the unversioned ghc scripts that get installed in /usr/local/bin/ (because /usr/local/bin appears on my $PATH first). Duncan From duncan.coutts at googlemail.com Mon Oct 12 18:19:24 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Oct 12 18:45:39 2009 Subject: haddock problem. Was: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <4AD35CC7.3060807@dfki.de> References: <20091011204153.GA5338@matrix.chaos.earth.li> <4AD35CC7.3060807@dfki.de> Message-ID: <1255385964.8777.997.camel@localhost> On Mon, 2009-10-12 at 18:43 +0200, Christian Maeder wrote: > P.S. I wonder why "Registering" is done twice It's Cabal's fault. It's a new feature to let components within a package depend on each other. To do that it needs to register the lib into a local inplace package db. At the moment it's always doing it, even when it's not strictly necessary. At some point we'll probably tidy that up so that it only does so when it's needed. On the other hand, always doing so during the testing phase has already caught a couple configuration bugs so I'm not in any great rush to add the optimisation. Duncan From mauricio.antunes at gmail.com Mon Oct 12 20:21:15 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Mon Oct 12 19:58:59 2009 Subject: Should ghci understand this pthread library? Message-ID: After using ghci to load a library I'm working in, I got this message: can't load .so/.DLL for: pthread (/usr/lib/libpthread.so: invalid ELF header) Then I did 'cat /usr/lib/libpthread.so' and, much to my surprise, it's a text file with the following contents: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) Is this a standard file? Should ghci be able to understand it and, maybe, use the listed libraries instead? Thanks, Maur?cio From alexander.dunlap at gmail.com Mon Oct 12 20:49:17 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon Oct 12 20:26:53 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <57526e770910121749o58d88353u4fdbfe835bb99fc5@mail.gmail.com> When compiling, I get lots of "No such file or directory" errors. The compilation process continues, but should I be concerned about this? Alex On Sun, Oct 11, 2009 at 1:41 PM, Ian Lynagh wrote: > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > ? ?http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ? ?ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From mauricio.antunes at gmail.com Mon Oct 12 23:20:03 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Mon Oct 12 22:57:46 2009 Subject: Should ghci understand this pthread library? In-Reply-To: References: Message-ID: > After using ghci to load a library I'm working in, I got this > message: > > can't load .so/.DLL for: pthread (/usr/lib/libpthread.so: > invalid ELF header) Sorry. Just found ticket on that issue and previous discussion. Please ignore. Thanks, Maur?cio From chak at cse.unsw.edu.au Tue Oct 13 00:43:32 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Oct 13 00:21:19 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <118132FF-6B81-48AD-B846-98CCEF29EF20@fastmail.fm> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012112042.GA7220@matrix.chaos.earth.li> <118132FF-6B81-48AD-B846-98CCEF29EF20@fastmail.fm> Message-ID: <0709D59A-4580-4B9D-BE39-74D834731D64@cse.unsw.edu.au> Barney Stratford: >>> this one built and installed fine on Mac OS X 10.6 :). >> Interesting, I thought there were still problems there. > I assume that's a 32-bit version. The problems manifest themselves > only when you compile a 64-bit GHC. That's incorrect. The 32-bit version is only partially working. GHCi dies with a bus error (after package loading) and various features that need the interpreter/dynamic loading (such as TH and annotations) die under certain circumstances. Disclaimer: I didn't actually test this with 6.12.1RC1, but with 6.13. However, there shouldn't be any difference as I am not aware of any 6.12.1-specific Mac fixes. Manuel PS: I am chasing these bugs, but I don't have a lot of time for that at the moment, they are tricky bugs, and my Mac-fu is still pretty limited. So, if anybody else likes to have a go with gdb and dtrace, please do so. From igloo at earth.li Tue Oct 13 03:58:27 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 13 03:35:44 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091012200423.GA4836@seas.upenn.edu> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012200423.GA4836@seas.upenn.edu> Message-ID: <20091013075827.GA5813@matrix.chaos.earth.li> On Mon, Oct 12, 2009 at 04:04:23PM -0400, Brent Yorgey wrote: > What's the canonical way to install a version of ghc but not have it > be the default? i.e., I'd like to try testing this release candidate > but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg' > etc. to still be aliases to ghc-6.10.4, instead of being overwritten > by the 6.12.1 install. If you want to install the OSX .pkg then I don't know of a way to do this. Installing one seems to uninstall the previous one for no good reason. If you're installing the Windows installer then you can choose the installation directory, but you'll have to make the aliases yourself. If you're installing one of the Linux bindists then you can use ./configure --prefix=/your/path and again you will have to set up the aliases yourself. And if installing from source you can likewise use ./configure --prefix=/your/path and set up aliases yourself. Thanks Ian From igloo at earth.li Tue Oct 13 04:00:08 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 13 03:37:25 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <57526e770910121749o58d88353u4fdbfe835bb99fc5@mail.gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <57526e770910121749o58d88353u4fdbfe835bb99fc5@mail.gmail.com> Message-ID: <20091013080008.GB5813@matrix.chaos.earth.li> On Mon, Oct 12, 2009 at 05:49:17PM -0700, Alexander Dunlap wrote: > When compiling, I get lots of "No such file or directory" errors. The > compilation process continues, but should I be concerned about this? It's normal to get this for various *.mk files, *.depend* files, etc. Thanks Ian From igloo at earth.li Tue Oct 13 04:01:08 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 13 03:38:24 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012080416.GA1106@scico.botik.ru> <4AD2E985.1070201@gmail.com> Message-ID: <20091013080108.GC5813@matrix.chaos.earth.li> On Mon, Oct 12, 2009 at 11:31:41PM +0200, Ben Franksen wrote: > > > http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1.html > > In section 1.5.2. Warnings there is a duplication: Thanks for the report; fixed. Thanks Ian From marlowsd at gmail.com Tue Oct 13 06:14:04 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 13 05:51:25 2009 Subject: replace GHC 6.6 with 6.10.4 in VisualHaskell In-Reply-To: References: <20091002173406.GA11237@seas.upenn.edu> Message-ID: <4AD452EC.3080509@gmail.com> On 12/10/2009 18:16, Luca Ciciriello wrote: > Is there a way to use VisualHaskel with GHC 6.10.4? Unfortunately no, Visual Haskell is bitrotted and unmaintained. Cheers, Simon From nccb2 at kent.ac.uk Tue Oct 13 06:17:53 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Tue Oct 13 05:55:09 2009 Subject: Attempts to install libraries with GHC 6.12.1rc1 Message-ID: <4AD453D1.4010501@kent.ac.uk> Hi, I downloaded the new GHC release candidate. It compiled and installed first time, which was great. However, this is not true of all the libraries. I'm posting here in the hope that it helps other users trying to get it to work, or library maintainers to see what breaks in the new compiler. I know most people should wait for the Haskell platform, but I'm happy to jump through hoops to try the release candidate. So, after installing GHC, I tried to bootstrap cabal-install with the bootstrap.sh script, but that told me it required parsec and network. (I have since seen a post on this list that cabal-install won't work, but anyway....) Parsec (and mtl, which it needed) installed fine with 6.12.1-rc1. The network package said: Network/Socket.hsc:1707:45: Not in scope: data constructor `System.Posix.Internals.Stream' (I also tried the latest version of network from the darcs repository, but that said: Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.4... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. Setup.hs: Missing dependency on a foreign library: * Missing header file: HsNet.h Even though HsNet.h is in the include directory already... odd. ) Anyway, it looked like that Posix module was in the unix library, so I thought I'd install that. That said: Preprocessing library unix-2.3.2.0... gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010/base-4.2.0.0' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010/integer-gmp-0.2.0.0' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010/ghc-prim-0.2.0.0' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010' #... Above 5 lines repeated a lot of times #gcc --version is 4.3.3 Building unix-2.3.2.0... dist/build/System/Posix/Signals.hs:127:0: error: Signals.h: No such file or directory I searched for Signals.h on my file system: /home/nccb2/ghc-6.10.4/includes/Signals.h /home/nccb2/lib/ghc-6.10.4/include/Signals.h /home/nccb2/lib/ghc-6.12.0.20091010/include/rts/Signals.h /home/nccb2/ghc-6.12.0.20091010/includes/rts/Signals.h /home/nccb2/ghc-6.12.0.20091010/rts/posix/Signals.h So I tried configuring with --extra-include-dirs=/home/nccb2/lib/ghc-6.12.0.20091010/include/rts which got further, but that said: [13 of 21] Compiling System.Posix.IO ( dist/build/System/Posix/IO.hs, dist/build/System/Posix/IO.o ) System/Posix/IO.hsc:217:11: Not in scope: `haFD' System/Posix/IO.hsc:218:2: Not in scope: `flushWriteBufferOnly' System/Posix/IO.hsc:219:2: Not in scope: `unlockFile' System/Posix/IO.hsc:223:13: `haFD' is not a (visible) constructor field name These functions seem to have gone in base-4, so I changed the unix.cabal file's base-depends to base < 4. That takes away the unlockFile error, but the others remain. Which is odd, because flushWriteBufferOnly is in GHC.Handle in base-3, which System/Posix/IO.hsc imports. So now I'm stuck. Can anyone say what the fix is that I need to apply to the unix package to get it working? Thanks, Neil. P.S. parallel, stm, HUnit and QuickCheck-2 all installed fine too. From marlowsd at gmail.com Tue Oct 13 06:50:47 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 13 06:28:09 2009 Subject: Attempts to install libraries with GHC 6.12.1rc1 In-Reply-To: <4AD453D1.4010501@kent.ac.uk> References: <4AD453D1.4010501@kent.ac.uk> Message-ID: <4AD45B87.6040300@gmail.com> On 13/10/2009 11:17, Neil Brown wrote: > Hi, > > I downloaded the new GHC release candidate. It compiled and installed > first time, which was great. However, this is not true of all the > libraries. I'm posting here in the hope that it helps other users trying > to get it to work, or library maintainers to see what breaks in the new > compiler. I know most people should wait for the Haskell platform, but > I'm happy to jump through hoops to try the release candidate. > > So, after installing GHC, I tried to bootstrap cabal-install with the > bootstrap.sh script, but that told me it required parsec and network. (I > have since seen a post on this list that cabal-install won't work, but > anyway....) Parsec (and mtl, which it needed) installed fine with > 6.12.1-rc1. The network package said: > > Network/Socket.hsc:1707:45: > Not in scope: data constructor `System.Posix.Internals.Stream' > > (I also tried the latest version of network from the darcs repository, > but that said: > > Warning: defaultUserHooks in Setup script is deprecated. > Configuring network-2.2.1.4... > Warning: The 'build-type' is 'Configure' but there is no 'configure' > script. > Setup.hs: Missing dependency on a foreign library: > * Missing header file: HsNet.h > > Even though HsNet.h is in the include directory already... odd. > ) network is one of those packages that has a configure script, but the configure script is generated by autoconf from configure.ac, so it is not stored in the darcs repository. When you get the network package from darcs, you need to $ autoreconf $ runhaskell Setup configure etc. > Anyway, it looked like that Posix module was in the unix library, so I > thought I'd install that. That said: unix is supplied with GHC 6.12, you shouldn't need to install it yourself. > Preprocessing library unix-2.3.2.0... > gcc: unrecognized option > '-R/home/nccb2/lib/ghc-6.12.0.20091010/base-4.2.0.0' > gcc: unrecognized option > '-R/home/nccb2/lib/ghc-6.12.0.20091010/integer-gmp-0.2.0.0' > gcc: unrecognized option > '-R/home/nccb2/lib/ghc-6.12.0.20091010/ghc-prim-0.2.0.0' > gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010' > gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010' > #... Above 5 lines repeated a lot of times > #gcc --version is 4.3.3 > Building unix-2.3.2.0... Fascinating ... I also get these complaints about -R. I'll look into it. > dist/build/System/Posix/Signals.hs:127:0: > error: Signals.h: No such file or directory Again I suspect this is because you need to run 'autoreconf' before configuring. Cheers, Simon From nccb2 at kent.ac.uk Tue Oct 13 07:04:33 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Tue Oct 13 06:41:50 2009 Subject: Attempts to install libraries with GHC 6.12.1rc1 In-Reply-To: <4AD45B87.6040300@gmail.com> References: <4AD453D1.4010501@kent.ac.uk> <4AD45B87.6040300@gmail.com> Message-ID: <4AD45EC1.5080702@kent.ac.uk> Simon Marlow wrote: > network is one of those packages that has a configure script, but the > configure script is generated by autoconf from configure.ac, so it is > not stored in the darcs repository. When you get the network package > from darcs, you need to > > $ autoreconf > $ runhaskell Setup configure > etc. > Great -- thanks. I can confirm that with the latest darcs version of the network library, doing that step allowed the library to build and install successfully (though still with the GCC spam I mentioned). (The latest hackage version of network still did not install properly even if I used autoreconf.) My next failing package install attempt was uvector, which fails with messages like those I got with the unix package: Data/Array/Vector/Prim/BUArr.hs:851:26: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/Vector/Prim/BUArr.hs:851:35: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/Vector/Prim/BUArr.hs:851:49: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/Vector/Prim/BUArr.hs:852:10: Not in scope: data constructor `Buffer' Data/Array/Vector/Prim/BUArr.hs:852:19: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/Vector/Prim/BUArr.hs:852:33: `bufWPtr' is not a (visible) field of constructor `Buffer' The latest darcs version of uvector is no different. Will these problems need to be fixed in the code on a per-package basis, or is there a cabal fix that can overcome them? Thanks, Neil. From marlowsd at gmail.com Tue Oct 13 07:10:27 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 13 06:47:48 2009 Subject: Attempts to install libraries with GHC 6.12.1rc1 In-Reply-To: <4AD45EC1.5080702@kent.ac.uk> References: <4AD453D1.4010501@kent.ac.uk> <4AD45B87.6040300@gmail.com> <4AD45EC1.5080702@kent.ac.uk> Message-ID: <4AD46023.90304@gmail.com> On 13/10/2009 12:04, Neil Brown wrote: > My next failing package install attempt was uvector, which fails with > messages like those I got with the unix package: > > Data/Array/Vector/Prim/BUArr.hs:851:26: > `haFD' is not a (visible) field of constructor `Handle__' > > Data/Array/Vector/Prim/BUArr.hs:851:35: > `haBuffer' is not a (visible) field of constructor `Handle__' > > Data/Array/Vector/Prim/BUArr.hs:851:49: > `haIsStream' is not a (visible) field of constructor `Handle__' > > Data/Array/Vector/Prim/BUArr.hs:852:10: > Not in scope: data constructor `Buffer' > > Data/Array/Vector/Prim/BUArr.hs:852:19: > `bufBuf' is not a (visible) field of constructor `Buffer' > > Data/Array/Vector/Prim/BUArr.hs:852:33: > `bufWPtr' is not a (visible) field of constructor `Buffer' > > The latest darcs version of uvector is no different. Will these problems > need to be fixed in the code on a per-package basis, or is there a cabal > fix that can overcome them? This is something that needs to be fixed in the uvector package - it is using internals from the IO library which changed in base-4.2. Cheers, Simon From nad at Cs.Nott.AC.UK Tue Oct 13 08:17:16 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Tue Oct 13 07:56:25 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091013075827.GA5813@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012200423.GA4836@seas.upenn.edu> <20091013075827.GA5813@matrix.chaos.earth.li> Message-ID: <4AD46FCC.2000309@cs.nott.ac.uk> On 2009-10-13 08:58, Ian Lynagh wrote: > If you're installing one of the Linux bindists then you can use > ./configure --prefix=/your/path > and again you will have to set up the aliases yourself. > > And if installing from source you can likewise use > ./configure --prefix=/your/path > and set up aliases yourself. I install GHC under /usr/local/stow/ghc-/, and use Stow (http://www.gnu.org/software/stow/) to create symlinks to my preferred version from /usr/local/?. -- /NAD This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From byorgey at seas.upenn.edu Tue Oct 13 11:13:38 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Tue Oct 13 10:50:54 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <4AD46FCC.2000309@cs.nott.ac.uk> References: <20091011204153.GA5338@matrix.chaos.earth.li> <20091012200423.GA4836@seas.upenn.edu> <20091013075827.GA5813@matrix.chaos.earth.li> <4AD46FCC.2000309@cs.nott.ac.uk> Message-ID: <20091013151338.GA633@seas.upenn.edu> On Tue, Oct 13, 2009 at 01:17:16PM +0100, Nils Anders Danielsson wrote: > On 2009-10-13 08:58, Ian Lynagh wrote: >> If you're installing one of the Linux bindists then you can use >> ./configure --prefix=/your/path >> and again you will have to set up the aliases yourself. >> >> And if installing from source you can likewise use >> ./configure --prefix=/your/path >> and set up aliases yourself. > > I install GHC under /usr/local/stow/ghc-/, and use Stow > (http://www.gnu.org/software/stow/) to create symlinks to my preferred > version from /usr/local/?. Fantastic! I'd never heard of stow before. -Brent From johan.tibell at gmail.com Tue Oct 13 16:35:51 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Oct 13 16:13:24 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <90889fe70910131335g6c066045wfd0f9aede6c30c7a@mail.gmail.com> On Mon, Oct 12, 2009 at 9:17 AM, Philip Weaver wrote: > Then, when I tried to build the network package manually, I got this: > > Building network-2.2.1.4... > [1 of 5] Compiling Network.URI????? ( Network/URI.hs, > dist/build/Network/URI.o ) > [2 of 5] Compiling Network.Socket.Internal ( > dist/build/Network/Socket/Internal.hs, dist/build/Network/Socket/Internal.o > ) > [3 of 5] Compiling Network.Socket?? ( dist/build/Network/Socket.hs, > dist/build/Network/Socket.o ) > > Network/Socket.hsc:1707:45: > ??? Not in scope: data constructor `System.Posix.Internals.Stream' Please try the darcs version at http://code.haskell.org/network. If that builds fine I can make a new release of network shortly. Cheers, Johan From aslatter at gmail.com Tue Oct 13 23:43:49 2009 From: aslatter at gmail.com (Antoine Latter) Date: Tue Oct 13 23:21:04 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <694519c50910132043i3e9c2b1bx4bda03fcf670aaa4@mail.gmail.com> On Sun, Oct 11, 2009 at 3:41 PM, Ian Lynagh wrote: > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > ? ?http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ? ?ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > Here is my tale of woe. I'm running this on Mac OS X 10.6. I tried to install the syb-with-class package off of hackage, which initially failed because of the changes to the template-haskell package installed with 6.12.1rc1. So I think to myself "Oh! I'll just put an upper bound on the version of template-haskell used in the .cabal file for syb, and install the old version off of hackage". The current version of template-haskell installs fine on 6.12.1rc1 with a couple minor tweaks (to compensate for StringConstr not being present in Data.Data anymore). But then when I try to build syb-with-class against the old template-haskell lib I get the following error: >>>>> $ ./Setup build Preprocessing library syb-with-class-0.5.1... Building syb-with-class-0.5.1... [3 of 4] Compiling Data.Generics.SYB.WithClass.Derive ( Data/Generics/SYB/WithClass/Derive.hs, dist/build/Data/Generics/SYB/WithClass/Derive.o ) Data/Generics/SYB/WithClass/Derive.hs:23:0: Bad interface file: /Users/alatter/.cabal/lib/template-haskell-2.3.0.1/ghc-6.12.0.20091010/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.3.0.1:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH <<<<< Has anyone seen this before? Are there any tools I can use to peer into .hi files to get more information about what could be wrong? Thanks, Antoine From luca_ciciriello at hotmail.com Wed Oct 14 02:26:10 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Wed Oct 14 02:03:23 2009 Subject: beginner question In-Reply-To: <4AD452EC.3080509@gmail.com> References: <20091002173406.GA11237@seas.upenn.edu> <4AD452EC.3080509@gmail.com> Message-ID: Just a Haskell beginner question. If I load in GHCi the code below all works fine, I load a file and its content is shown on screen. But if I use the second version of my "load_by_key" (the commented one) no error is reported loading and executing this code, but nothing is shown on screen. Where is my mistake? I'm using GHC 6.10.4 on MacOS X 10.5.8 Thanks in advance. Luca. module BackEnd where import IO load_by_key :: String -> String -> IO () load_by_key table key = do inh <- openFile table ReadMode contents <- hGetContents inh get_record (get_string contents) key hClose inh {- load_by_key table key = do contents <- getTableContent table get_record (get_string contents) key -} get_string :: String -> String get_string = (\x -> x) get_record :: String -> String -> IO () get_record contents key = putStr( contents ) getTableContent :: String -> IO String getTableContent table = bracket (openFile table ReadMode) hClose (\h -> (hGetContents h)) _________________________________________________________________ Did you know you can get Messenger on your mobile? http://clk.atdmt.com/UKM/go/174426567/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091014/60cb0175/attachment-0001.html From p.k.f.holzenspies at utwente.nl Wed Oct 14 04:26:49 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Wed Oct 14 04:01:56 2009 Subject: beginner question In-Reply-To: References: <20091002173406.GA11237@seas.upenn.edu> <4AD452EC.3080509@gmail.com> Message-ID: <1255508809.20505.31.camel@ewi1043> Dear Luca, The problem in your alternative code is that hGetContents lazily reads the contents of the handle it is passed. You've run into a cognitive bootstrap problem; the documentation for System.IO [1] does explain it, but I can see that you need to understand it to be able to read it ;) These are the important bits for your example: - hGetContents h puts handle h into a "semi-closed" state, but doesn't actually read anything (yet). - Any other function that gets a semi-closed handle (except hClose) will see it as a closed handle. - When a semi-closed handle becomes closes, the contents of the associated list becomes fixed. In other words; the actual reading from the handle doesn't happen until you evaluate the resulting list (and then still only the part that you evaluate). In your bracket, you open a handle, then you "convert" the handle into a lazy list that would evaluate to the contents of the file, but then you close the handle, fixing the list you got to an empty list. If you want to do this, you would want something like this: withTableContents :: String -> (String -> IO a) -> IO a withTableContents table cont = bracket (openFile table ReadMode) hClose (\h -> hGetContents h >>= cont) Hope this helps. By the way, this type of question should probably go to haskell-cafe@haskell.org which will usually give you a lot of explanation quite quickly. Regards, Philip [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v:hGetContents On Wed, 2009-10-14 at 07:26 +0100, Luca Ciciriello wrote: > Just a Haskell beginner question. > If I load in GHCi the code below all works fine, I load a file and its > content is shown on screen. But if I use the second version of my > "load_by_key" (the commented one) no error is reported loading and > executing this code, but nothing is shown on screen. Where is my > mistake? > I'm using GHC 6.10.4 on MacOS X 10.5.8 > > Thanks in advance. > > Luca. > > > module BackEnd > where > > import IO > > load_by_key :: String -> String -> IO () > > load_by_key table key = do > inh <- openFile table ReadMode > contents <- hGetContents inh > get_record (get_string contents) key > hClose inh > > {- > load_by_key table key = do > contents <- getTableContent table > get_record (get_string contents) key > -} > > get_string :: String -> String > get_string = (\x -> x) > > get_record :: String -> String -> IO () > get_record contents key = putStr( contents ) > > getTableContent :: String -> IO String > getTableContent table = bracket (openFile table ReadMode) > hClose > (\h -> (hGetContents h)) > > > ______________________________________________________________________ > Did you know you can get Messenger on your mobile? Learn more. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From daniel.is.fischer at web.de Wed Oct 14 04:37:24 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Oct 14 04:23:40 2009 Subject: beginner question In-Reply-To: References: <4AD452EC.3080509@gmail.com> Message-ID: <200910141037.25111.daniel.is.fischer@web.de> Am Mittwoch 14 Oktober 2009 08:26:10 schrieb Luca Ciciriello: > Just a Haskell beginner question. This sort of generic question has a higher probability of receiving a quick answer on haskell-cafe@haskell.org or beginners@haskell.org, where more people are reading. > > If I load in GHCi the code below all works fine, I load a file and its > content is shown on screen. But if I use the second version of my > "load_by_key" (the commented one) no error is reported loading and > executing this code, but nothing is shown on screen. Where is my mistake? You're bitten by laziness. It's a very common problem you're having. In the working version, you explicitly open the file, lazily get its contents, then print it out and after that is done, close the file. > > load_by_key table key = do > inh <- openFile table ReadMode > contents <- hGetContents inh > get_record (get_string contents) key > hClose inh > > Here you use bracket, which doesn't interact well with hGetContents. hGetContents is lazy and returns immediately, without reading any of the file's contents yet. Once hGetContents returns, bracket performs its exit action, here it closes the file - before you've read anything from it. Then you try to print the file contents and hGetContents tries to read the file. That is now closed, hence hGetContents can't read anything and returns "", which then is output. Don't mix bracket and hGetContents. Consider using readFile instead. > > {- > load_by_key table key = do > contents <- getTableContent table > get_record (get_string contents) key > -} > > > > get_string :: String -> String > get_string = (\x -> x) > > > > get_record :: String -> String -> IO () > get_record contents key = putStr( contents ) > > > > getTableContent :: String -> IO String > getTableContent table = bracket (openFile table ReadMode) > hClose > (\h -> (hGetContents h)) > From luca_ciciriello at hotmail.com Wed Oct 14 05:13:31 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Wed Oct 14 04:50:45 2009 Subject: beginner question In-Reply-To: <200910141037.25111.daniel.is.fischer@web.de> References: <4AD452EC.3080509@gmail.com> Message-ID: Thanks Philip and Daniel for your help. Your explanation is clear. Thanks also for direct me on the right news letters :-) Luca. _________________________________________________________________ Chat to your friends for free on selected mobiles http://clk.atdmt.com/UKM/go/174426567/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091014/672a0c2c/attachment.html From marlowsd at gmail.com Wed Oct 14 05:34:27 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Oct 14 05:11:51 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <694519c50910132043i3e9c2b1bx4bda03fcf670aaa4@mail.gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <694519c50910132043i3e9c2b1bx4bda03fcf670aaa4@mail.gmail.com> Message-ID: <4AD59B23.4010306@gmail.com> On 14/10/2009 04:43, Antoine Latter wrote: > On Sun, Oct 11, 2009 at 3:41 PM, Ian Lynagh wrote: >> >> Hi all, >> >> We are pleased to (finally!) announce the first release candidate >> for GHC 6.12.1: >> >> http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ >> >> As well as the source tarball: >> ghc-6.12.0.20091010-src.tar.bz2 >> there are installers for Windows (i386) and OS X (i386), and binary >> distributions for x86_64/Linux and i386/Linux. For the Linux binary >> distributions, the "linux-n" tarballs are recommended over the "linux" >> tarballs. >> >> >> Please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> > > Here is my tale of woe. I'm running this on Mac OS X 10.6. > > I tried to install the syb-with-class package off of hackage, which > initially failed because of the changes to the template-haskell > package installed with 6.12.1rc1. > > So I think to myself "Oh! I'll just put an upper bound on the version > of template-haskell used in the .cabal file for syb, and install the > old version off of hackage". > > The current version of template-haskell installs fine on 6.12.1rc1 > with a couple minor tweaks (to compensate for StringConstr not being > present in Data.Data anymore). > > But then when I try to build syb-with-class against the old > template-haskell lib I get the following error: > >>>>>> > $ ./Setup build > Preprocessing library syb-with-class-0.5.1... > Building syb-with-class-0.5.1... > [3 of 4] Compiling Data.Generics.SYB.WithClass.Derive ( > Data/Generics/SYB/WithClass/Derive.hs, > dist/build/Data/Generics/SYB/WithClass/Derive.o ) > > Data/Generics/SYB/WithClass/Derive.hs:23:0: > Bad interface file: > /Users/alatter/.cabal/lib/template-haskell-2.3.0.1/ghc-6.12.0.20091010/Language/Haskell/TH.hi > Something is amiss; requested module > template-haskell-2.3.0.1:Language.Haskell.TH differs from name found > in the interface file template-haskell:Language.Haskell.TH > <<<<< > > Has anyone seen this before? Are there any tools I can use to peer > into .hi files to get more information about what could be wrong? template-haskell is a one of the packages that we call "wired-in", because GHC needs to generate references to some of the things that it defines. To make GHC independent of the version of the template-haskell package, we internally strip off the version number when referring to template-haskell. Now, this doesn't completely explain the error you're seeing. When it starts up, GHC has to decide which template-haskell package is the "wired-in" one, and my guess is that it picked the other one (because it is newer). You could find out by running GHC with the -v flag. I think GHC is assuming that when you have multiple versions of a wired-in package that the older ones are wrappers around the newer ones (like base-3 and base-4), but that assumption doesn't hold in your case. Installing a new version of a wired-in package is going to be problematic, but we ought to be able to at least improve the diagnostics. Cheers, Simon From aslatter at gmail.com Wed Oct 14 18:51:13 2009 From: aslatter at gmail.com (Antoine Latter) Date: Wed Oct 14 18:28:25 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <4AD59B23.4010306@gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <694519c50910132043i3e9c2b1bx4bda03fcf670aaa4@mail.gmail.com> <4AD59B23.4010306@gmail.com> Message-ID: <694519c50910141551w1fa5c1d2yffe08ac122924ac2@mail.gmail.com> On Wed, Oct 14, 2009 at 4:34 AM, Simon Marlow wrote: > > template-haskell is a one of the packages that we call "wired-in", because > GHC needs to generate references to some of the things that it defines. ?To > make GHC independent of the version of the template-haskell package, we > internally strip off the version number when referring to template-haskell. > > Now, this doesn't completely explain the error you're seeing. ?When it > starts up, GHC has to decide which template-haskell package is the > "wired-in" one, and my guess is that it picked the other one (because it is > newer). ?You could find out by running GHC with the -v flag. ?I think GHC is > assuming that when you have multiple versions of a wired-in package that the > older ones are wrappers around the newer ones (like base-3 and base-4), but > that assumption doesn't hold in your case. > > Installing a new version of a wired-in package is going to be problematic, > but we ought to be able to at least improve the diagnostics. > Does it make sense to do releases of the template-haskell package on to hackage? It's a bit misleading if I can't then do anything to the package that doesn't leave me broken. (I guess I can `cabal unpack` into my GHC source directory to get a different version ...) Antoine From johan.tibell at gmail.com Thu Oct 15 14:58:27 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Oct 15 14:35:56 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <90889fe70910131335g6c066045wfd0f9aede6c30c7a@mail.gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <90889fe70910131335g6c066045wfd0f9aede6c30c7a@mail.gmail.com> Message-ID: <90889fe70910151158h3ace7b84sba3e4365b3f0d139@mail.gmail.com> On Tue, Oct 13, 2009 at 10:35 PM, Johan Tibell wrote: > On Mon, Oct 12, 2009 at 9:17 AM, Philip Weaver wrote: >> Then, when I tried to build the network package manually, I got this: >> >> Building network-2.2.1.4... >> [1 of 5] Compiling Network.URI????? ( Network/URI.hs, >> dist/build/Network/URI.o ) >> [2 of 5] Compiling Network.Socket.Internal ( >> dist/build/Network/Socket/Internal.hs, dist/build/Network/Socket/Internal.o >> ) >> [3 of 5] Compiling Network.Socket?? ( dist/build/Network/Socket.hs, >> dist/build/Network/Socket.o ) >> >> Network/Socket.hsc:1707:45: >> ??? Not in scope: data constructor `System.Posix.Internals.Stream' > > Please try the darcs version at http://code.haskell.org/network. If > that builds fine I can make a new release of network shortly. I've made a new release of network that should work on 6.12 -- Johan From nccb2 at kent.ac.uk Fri Oct 16 11:17:11 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Fri Oct 16 10:54:16 2009 Subject: 6.12.1 Release Candidate: profiling and libHSffi_p.a Message-ID: <4AD88E77.7070802@kent.ac.uk> Hi, I tried profiling a program with the GHC 6.12 release candidate. I got this: $ ghc -O1 -prof -auto-all --make CommsTime.hs [1 of 1] Compiling Main ( CommsTime.hs, CommsTime.o ) Linking CommsTime ... /usr/bin/ld: cannot find -lHSffi_p collect2: ld returned 1 exit status Googling turned up this link, which suggests this problem was fixed earlier this year: http://www.mail-archive.com/cvs-ghc@haskell.org/msg13546.html However: $ find ~ -iname "libHSffi*" /home/nccb2/lib/ghc-6.12.0.20091010/libHSffi.a /home/nccb2/lib/ghc-6.12.0.20091010/libHSffi-ghc6.12.0.20091010.so /home/nccb2/ghc-6.11.20090915/libffi/libHSffi.a /home/nccb2/ghc-6.11.20090915/libffi/libHSffi-ghc6.11.20090915.so /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi-ghc6.12.0.20091010.so /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi.a /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi_p.a This seems to indicate that the library is built (/home/nccb2/ghc-6.12.0.20091010 is where I built GHC) but not installed on my system. This is a Debian 32-bit system, and I don't remember passing any options to the GHC configure command besides --prefix. Neil. From christosc at me.com Sun Oct 18 06:17:40 2009 From: christosc at me.com (Chryssochoidis Christos) Date: Sun Oct 18 05:54:46 2009 Subject: 6.12.1rc1: non-Latin filenames in GHCi Message-ID: <4AA6432E-14EE-41A9-B9F2-26E306C629EE@me.com> I've noticed that when I load in GHCi a file that has a non-latin name, although it gets loaded, its name appears garbled in the message after the loading: > Prelude> :load ?????????.hs > [1 of 1] Compiling Main ( ????? > ???????????????.hs, interpreted ) > Ok, modules loaded: Main. > *Main> Is this expected, or something is wrong with my setup? It's a rather insignificant issue, but I thought to ask about it. I'm using GHC 6.12.1rc1 on Mac OS X 10.6.1. Thanks very much, Christos Chryssochoidis From dons at galois.com Sun Oct 18 11:11:29 2009 From: dons at galois.com (Don Stewart) Date: Sun Oct 18 10:48:31 2009 Subject: 6.12.1rc1: non-Latin filenames in GHCi In-Reply-To: <4AA6432E-14EE-41A9-B9F2-26E306C629EE@me.com> References: <4AA6432E-14EE-41A9-B9F2-26E306C629EE@me.com> Message-ID: <20091018151129.GA32018@whirlpool.galois.com> christosc: > I've noticed that when I load in GHCi a file that has a non-latin name, > although it gets loaded, its name appears garbled in the message after > the loading: > >> Prelude> :load ?????????.hs >> [1 of 1] Compiling Main ( ????????????????????.hs, >> interpreted ) >> Ok, modules loaded: Main. >> *Main> > > Is this expected, or something is wrong with my setup? It's a rather > insignificant issue, but I thought to ask about it. > I'm using GHC 6.12.1rc1 on Mac OS X 10.6.1. > Perhaps you're seeing the GHC support for locales in 6.12. http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know-about-unicode-io-in-ghc-6-12-1/ From marcot at riseup.net Sun Oct 18 13:58:10 2009 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Sun Oct 18 13:37:43 2009 Subject: Broken link in GHC page Message-ID: <1255888690.17404.200.camel@zezinho> Hi. The link to the mailing list on the GHC page is not correct. It should link to http://www.haskell.org/ghc/docs/latest/html/users_guide/mailing-lists-GHC.html instead of http://www.haskell.org/ghc/docs/latest/html/users_guide/introduction-GHC.html#mailing-lists-GHC . Greetings. -- marcot http://marcot.iaaeee.org/ From marcot at riseup.net Sun Oct 18 14:01:12 2009 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Sun Oct 18 13:40:49 2009 Subject: [Fwd: Re: [Gtk2hs-devel] Help with build on Alpha] Message-ID: <1255888872.17404.203.camel@zezinho> Hi. I sent a mail to gtk2hs-devel about this bug, and I'm forwarding it's response to here. Greetings. -------- Mensagem encaminhada -------- De: Axel Simon (...) On Sep 27, 2009, at 18:02, Marco T?lio Gontijo e Silva wrote: (...) > I don't have a clue about this bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540879 . Do you have > any idea about what could be causing this? (...) This is a limitation of ghc. So you should ask the ghc people if they can fix this. Then we could think of a work-around. But the only workaround there is is not to bind functions that are affected by the limitation. That would pretty much rule out all modules in ModelView/ which is a rather important part of Gtk2Hs. (...) -- marcot http://marcot.iaaeee.org/ From christosc at me.com Sun Oct 18 15:15:57 2009 From: christosc at me.com (Chryssochoidis Christos) Date: Sun Oct 18 14:53:24 2009 Subject: 6.12.1rc1: non-Latin filenames in GHCi In-Reply-To: <20091018151129.GA32018@whirlpool.galois.com> References: <4AA6432E-14EE-41A9-B9F2-26E306C629EE@me.com> <20091018151129.GA32018@whirlpool.galois.com> Message-ID: <36C3DA46-CCAB-4013-948D-736CBCD4C9F6@me.com> Thanks Don for your reply. I may have overlooked something in the blog post you gave, but my understanding is that it talks about the user's input/output to and from GHCi and the file system. The user IO with non-Latin chars seems to work fine in GHC 6.12.1; e.g.: > > *Main> putStrLn "?????????.hs" > ?????????.hs > *Main> getLine >>= putStrLn > ?????????.hs > ?????????.hs > *Main> It's only when GHCi attempts to print a diagnostic message containing a filename with non-Latin chars that the garbling occurs: > *Main> :load ?????????.hs > [1 of 1] Compiling Main ( ????? > ???????????????.hs, interpreted ) > > ????????????????????.hs:1:23: > Not in scope: type constructor or class `Boo' > Failed, modules loaded: none. > Prelude> It would be nice if the error messages at least showed correctly the filename. Maybe this has something to do with Haskeline? Anyway thanks again, Christos On 18 ??? 2009, at 6:11 ?.?., Don Stewart wrote: > christosc: >> I've noticed that when I load in GHCi a file that has a non-latin >> name, >> although it gets loaded, its name appears garbled in the message >> after >> the loading: >> >>> Prelude> :load ?????????.hs >>> [1 of 1] Compiling Main ( ????? >>> ???????????????.hs, >>> interpreted ) >>> Ok, modules loaded: Main. >>> *Main> >> >> Is this expected, or something is wrong with my setup? It's a rather >> insignificant issue, but I thought to ask about it. >> I'm using GHC 6.12.1rc1 on Mac OS X 10.6.1. >> > > Perhaps you're seeing the GHC support for locales in 6.12. > > http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know-about-unicode-io-in-ghc-6-12-1/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From aslatter at gmail.com Sun Oct 18 16:20:21 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Oct 18 15:57:22 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091011204153.GA5338@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> Message-ID: <694519c50910181320y130eb60jf08e0bab0341c4d4@mail.gmail.com> On Sun, Oct 11, 2009 at 3:41 PM, Ian Lynagh wrote: > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > ? ?http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ? ?ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team I'll try to get this up in a bug report on trac as soon as it's back up, but in case I forget, here's the problem: The attached Demo.hs compiles on 6.10, but not on 6.12rc1 The output --ddump-splices for 6.10: >>> Demo.hs:1:0: Demo.hs:1:0: Splicing declarations test ======> Demo.hs:6:2-5 myFunction[aLQ] = Demo2.testFun [] Ok, modules loaded: Demo2, Main. <<< In 6.12rc1: >>> Demo.hs:1:0: Demo.hs:1:0: Splicing declarations test ======> Demo.hs:6:2-5 myFunction[aNX] = testFun "" Demo.hs:6:2: Couldn't match expected type `[Char]' against inferred type `Char' Expected type: [String] Inferred type: [Char] In the first argument of `testFun', namely `""' In the expression: testFun "" Failed, modules loaded: Demo2. <<< Note that what was spliced in as [] is now being spliced in as "", which is incorrect. Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: Demo.hs Type: application/octet-stream Size: 56 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091018/5b958b4c/Demo.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Demo2.hs Type: application/octet-stream Size: 317 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091018/5b958b4c/Demo2.obj From duncan.coutts at googlemail.com Sun Oct 18 18:03:02 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sun Oct 18 17:40:05 2009 Subject: [Fwd: Re: [Gtk2hs-devel] Help with build on Alpha] In-Reply-To: <1255888872.17404.203.camel@zezinho> References: <1255888872.17404.203.camel@zezinho> Message-ID: <1255903382.8777.3501.camel@localhost> On Sun, 2009-10-18 at 16:01 -0200, Marco T?lio Gontijo e Silva wrote: > Hi. > > I sent a mail to gtk2hs-devel about this bug, and I'm forwarding it's > response to here. This limitation might be different now that ghc is using libffi. Duncan > > I don't have a clue about this bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540879 . Do you have > > any idea about what could be causing this? > (...) > This is a limitation of ghc. So you should ask the ghc people if they > can fix this. Then we could think of a work-around. But the only > workaround there is is not to bind functions that are affected by the > limitation. That would pretty much rule out all modules in ModelView/ > which is a rather important part of Gtk2Hs. > (...) > From avatar at hot.ee Mon Oct 19 00:17:09 2009 From: avatar at hot.ee (Misha Aizatulin) Date: Sun Oct 18 23:54:44 2009 Subject: ghc search paths (like CPATH for gcc) Message-ID: <4ADBE845.4040008@hot.ee> Hello, is there a mechanism for ghc similar to setting the CPATH variable for gcc? I'd like ghc to look in the given list of paths every time it compiles something, without me having to retype the flags. For ghci there is .ghci, but it gets ignored when I run ghc. Best, Misha From marlowsd at gmail.com Mon Oct 19 05:42:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 19 05:19:18 2009 Subject: [Fwd: Re: [Gtk2hs-devel] Help with build on Alpha] In-Reply-To: <1255903382.8777.3501.camel@localhost> References: <1255888872.17404.203.camel@zezinho> <1255903382.8777.3501.camel@localhost> Message-ID: <4ADC3479.5030309@gmail.com> On 18/10/2009 23:03, Duncan Coutts wrote: > On Sun, 2009-10-18 at 16:01 -0200, Marco T?lio Gontijo e Silva wrote: >> Hi. >> >> I sent a mail to gtk2hs-devel about this bug, and I'm forwarding it's >> response to here. > > This limitation might be different now that ghc is using libffi. Wow, that's an ancient error message on an architecture I haven't used in over 10 years :-) It looks like we're not using libffi on Alpha at the moment. If someone with an Alpha would like to try building GHC with UseLibFFIForAdjustors=YES in mk/build.mk and test whether it works, we could change it over. Cheers, Simon From marlowsd at gmail.com Mon Oct 19 05:44:58 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 19 05:21:58 2009 Subject: ghc search paths (like CPATH for gcc) In-Reply-To: <4ADBE845.4040008@hot.ee> References: <4ADBE845.4040008@hot.ee> Message-ID: <4ADC351A.6090200@gmail.com> On 19/10/2009 05:17, Misha Aizatulin wrote: > Hello, > > is there a mechanism for ghc similar to setting the CPATH variable for > gcc? I'd like ghc to look in the given list of paths every time it > compiles something, without me having to retype the flags. > > For ghci there is .ghci, but it gets ignored when I run ghc. We don't have anything like that right now. Please submit a feature request: http://hackage.haskell.org/trac/ghc/newticket?type=feature+request (when hackage.haskell.org comes back up, that is) Cheers, Simon From mka19 at hw.ac.uk Tue Oct 20 08:01:36 2009 From: mka19 at hw.ac.uk (Aswad, Mustafa) Date: Tue Oct 20 07:39:35 2009 Subject: TAG IN 6.8 Message-ID: <9D12E3B7122E214F92BE5E82ABACAC4603D3EA9B@ex5.mail.win.hw.ac.uk> Hi I am try update GUM But I have problem with Tagging and Untagging closures any can direct me to a document to understand the tagging procedure. best washes -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091020/e5c44688/attachment-0001.html From marlowsd at gmail.com Tue Oct 20 08:08:15 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 20 07:45:20 2009 Subject: 6.12.1rc1: non-Latin filenames in GHCi In-Reply-To: <36C3DA46-CCAB-4013-948D-736CBCD4C9F6@me.com> References: <4AA6432E-14EE-41A9-B9F2-26E306C629EE@me.com> <20091018151129.GA32018@whirlpool.galois.com> <36C3DA46-CCAB-4013-948D-736CBCD4C9F6@me.com> Message-ID: <4ADDA82F.8090806@gmail.com> On 18/10/2009 20:15, Chryssochoidis Christos wrote: > Thanks Don for your reply. > I may have overlooked something in the blog post you gave, but my > understanding is that it talks about the user's input/output to and from > GHCi and the file system. The user IO with non-Latin chars seems to work > fine in GHC 6.12.1; e.g.: > >> >> *Main> putStrLn "?????????.hs" >> ?????????.hs > >> *Main> getLine >>= putStrLn >> ?????????.hs >> ?????????.hs >> *Main> > > It's only when GHCi attempts to print a diagnostic message containing a > filename with non-Latin chars that the garbling occurs: > >> *Main> :load ?????????.hs >> [1 of 1] Compiling Main ( ????????????????????.hs, interpreted ) >> >> ????????????????????.hs:1:23: >> Not in scope: type constructor or class `Boo' >> Failed, modules loaded: none. >> Prelude> > > It would be nice if the error messages at least showed correctly the > filename. > > Maybe this has something to do with Haskeline? It's not to do with Haskeline. The real underlying problem is that our filesystem APIs on Unix interpret FilePath as [Word8] without doing any encoding/decoding; they just strip off all but the low 8 bits of each Char. This is a long-standing problem, and won't be solved properly until we switch to an abstract FilePath type, but that's a big change that will break lots of code. Lots more good discussion here: http://hackage.haskell.org/trac/ghc/ticket/3456 If there were a filePathToString function we could use it in GHC to fix the above glitch. Cheers, Simon From marlowsd at gmail.com Tue Oct 20 08:17:46 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 20 07:54:43 2009 Subject: TAG IN 6.8 In-Reply-To: <9D12E3B7122E214F92BE5E82ABACAC4603D3EA9B@ex5.mail.win.hw.ac.uk> References: <9D12E3B7122E214F92BE5E82ABACAC4603D3EA9B@ex5.mail.win.hw.ac.uk> Message-ID: <4ADDAA6A.8070207@gmail.com> On 20/10/2009 13:01, Aswad, Mustafa wrote: > I am try update GUM But I have problem with Tagging and Untagging > closures any can direct me to a document to understand the tagging > procedure. The details are documented here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging Cheers, Simon From marlowsd at gmail.com Tue Oct 20 09:12:50 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 20 08:49:49 2009 Subject: Broken link in GHC page In-Reply-To: <1255888690.17404.200.camel@zezinho> References: <1255888690.17404.200.camel@zezinho> Message-ID: <4ADDB752.7060908@gmail.com> On 18/10/2009 18:58, Marco T?lio Gontijo e Silva wrote: > Hi. > > The link to the mailing list on the GHC page is not correct. It should > link to > http://www.haskell.org/ghc/docs/latest/html/users_guide/mailing-lists-GHC.html instead of > http://www.haskell.org/ghc/docs/latest/html/users_guide/introduction-GHC.html#mailing-lists-GHC > . Fixed, thanks! Simon From stryder100 at gmail.com Tue Oct 20 09:54:41 2009 From: stryder100 at gmail.com (Ralph Crawford) Date: Tue Oct 20 09:31:34 2009 Subject: how can I get a listing of everything that's done in a program Message-ID: Hi. I'm working with GHC 6.10.4 on Solaris. I'm new at Haskell and have inherited a rather large and complex program to maintain and modify. I'd like to get a listing of everything - every single step - that's done in a run of the program. Something similar to the output of the :step command, but I'd like the entire run (which would involve tens of thousands of steps). Is there a way to just do this - have it run and print everything it does to the screen? I've tried doing the following, after starting a "script" to capture all of the screen output... ghci -fglasgow-exts parsequery.hs :break 36 main which takes me to this prompt... Loading package mtl-1.1.0.2 ... linking ... done. Stopped at lesearch.hs:36:13-39 _result :: IO SearchState = _ input :: [String] = _ st :: SearchState = _ [lesearch.hs:36:13-39] *Main> This takes me to the call before the one that I want to output each step of so that I can then manually, with hardcopy, read it and get an idea of what happened. So I start a step through the next call. [lesearch.hs:36:13-39] *Main> :step process_query_loop st input Stopped at lesearch.hs:(46,0)-(69,39) _result :: IO SearchState = _ ... [lesearch.hs:(46,0)-(69,39)] *Main> So far so good. This is what I want to see - a listing like this for every (interpreted of course) line of haskell code that runs, all the way to the end. Since this is a very large program, at this point I started pasting this to the terminal - 4 steps at a time... :step :step :step :step This gave me the listing I wanted. But after a certain point, it inevitably fails with a core dump, and what I capture from the screen is garbled up to that point anyway. I'm hoping there's a simpler way to do this. Thanks for taking the time to read this. Ralph -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091020/58360055/attachment.html From simonpj at microsoft.com Tue Oct 20 10:37:57 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Oct 20 10:14:54 2009 Subject: The template-haskell@haskell.org mailing list In-Reply-To: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1061B628D@DB3EX14MBXC310.europe.corp.microsoft.com> Question: is the template-haskell@haskell.org mailing list still useful? * It has 250 subscribers compared to 850 for ghc-users. * It has low traffic * template-haskell is the only GHC-specific mailing list associated with a particular language feature. Eg type functions, ghci, etc do not have their own list * The traffic on ghc-users is not dauntingly high. I suggest we abolish it in favour of ghc-users. Any dissenters? (I'd emit a warning, so that people could check they are subscribed to ghc-users.) Simon From simonpj at microsoft.com Tue Oct 20 10:38:33 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Oct 20 10:15:30 2009 Subject: [Template-haskell] How to extract name and type of exported functions in modules In-Reply-To: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1061B62A1@DB3EX14MBXC310.europe.corp.microsoft.com> [ccing ghc-users] | I'm trying to extract the names and types of exported functions in a module. Quite a reasonable request. But it's not conveniently possible at the moment. Here's what you can do in the Q monad: class (Monad m, Functor m) => Quasi m where -- Fresh names qNewName :: String -> m Name -- Error reporting and recovery qReport :: Bool -> String -> m () -- Report an error (True) or warning (False) -- ...but carry on; use 'fail' to stop qRecover :: m a -> m a -> m a -- Recover from the monadic 'fail' -- The first arg is the error handler -- Inspect the type-checker's environment qReify :: Name -> m Info qLocation :: m Loc -- Input/output (dangerous) qRunIO :: IO a -> m a But you want one more function: qReifyModule :: String -> m ModuleInfo where ModuleInfo is something like: data ModuleInfo = MI { mi_exports :: [Name] , ... instances,rules, etc } Then you could use qReify to get info about a particular thing. This would not be hard in principle, the details need thought. For example, if module exports T( C1, C2), where C1, C2 are constructors of T which also has constructors C3, C4, what should appear in mi_exports? Should mi_exports reflect the structure of the export list (see the AvailInfo type in GHC). What is the info for an instance? Do we need a way to ask for all the instances of a class (or rules for a function) regardless of what module those instances come from? etc Does this ring bells for anyone else? Would someone like to write the spec? Are there other reify-related things that we need? Simon | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell- | bounces@haskell.org] On Behalf Of Oscar Finnsson | Sent: 16 October 2009 18:47 | To: template-haskell@haskell.org | Subject: [Template-haskell] How to extract name and type of exported functions in | modules | | Hi, | | I'm trying to extract the names and types of exported functions in a module. | | At the moment I've managed to get a list of all functions in a module | but I can't seem to figure out how to get their types. | | Lets say I got the module | | module Foo where | | foo1 :: String -> String | foo1 value = value | | foo2 = "hej" | | and then in anothor module... | | module Bar where | | bar = $(getAllFunctions "/Foo.hs") | | At the moment I got getAllFunctions returning ["foo1","foo2"], but I | would really like to get it to return [("foo1",AppT (ConT "String") | (ConT "String")), ("foo2",ConT "String")] | | Using "parseModuleWithMode" from Language.Haskell.Exts I can get hold | of the names and the type signature of foo1 (since it's specified in | the source code) but I cannot get hold of the type signature of foo2 | (since it's not specified in the source code). | | Is there another way to get the names/signatures of exported functions | from a module other than using parseModuleWithMode so the developer | writing the Foo-module isn't forced to explicitly supply type | signatures of the exported functions? | | If I try "reify" to get information about the functions I get the error message: | "foo1 is not in scope at a reify" | | This seems to be a known bug about reify (reported here | http://hackage.haskell.org/trac/ghc/ticket/2339). My problem is that I | cannot use the workaround since I don't know the name of the | functions. | | Another disadvantage with this approach is that "getAllFunctions" must | have access to the source code of the module and that I must supply | the path the the module. If possible I would like to have code such as | | bar = $(getAllFunctions "Foo") | | instead of "/Foo.hs". | | Regards, | Oscar Finnsson | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell From leather at cs.uu.nl Tue Oct 20 11:03:53 2009 From: leather at cs.uu.nl (Sean Leather) Date: Tue Oct 20 10:41:08 2009 Subject: [Template-haskell] The template-haskell@haskell.org mailing list In-Reply-To: <59543203684B2244980D7E4057D5FBC1061B628D@DB3EX14MBXC310.europe.corp.microsoft.com> References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> <59543203684B2244980D7E4057D5FBC1061B628D@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <3c6288ab0910200803g6aa085ebp93f81767ca373507@mail.gmail.com> On Tue, Oct 20, 2009 at 16:37, Simon Peyton-Jones wrote: > Question: is the template-haskell@haskell.org mailing list still useful? > My gut reaction: probably not. > * It has 250 subscribers compared to 850 for ghc-users. > * It has low traffic > * template-haskell is the only GHC-specific mailing list associated with a > particular > language feature. Eg type functions, ghci, etc do not have their own > list > * The traffic on ghc-users is not dauntingly high. > Also telling is the fact that so many threads are begun and left to rot (i.e. questions remain unanswered). My impression is that very few people actually pay attention to the template-haskell list. I suggest we abolish it in favour of ghc-users. Any dissenters? (I'd emit > a warning, so that people could check they are subscribed to ghc-users.) > Not here. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091020/432d8143/attachment-0001.html From christosc at me.com Tue Oct 20 11:55:50 2009 From: christosc at me.com (Chryssochoidis Christos) Date: Tue Oct 20 11:33:09 2009 Subject: 6.12.1rc1: non-Latin filenames in GHCi In-Reply-To: <4ADDA82F.8090806@gmail.com> References: <4AA6432E-14EE-41A9-B9F2-26E306C629EE@me.com> <20091018151129.GA32018@whirlpool.galois.com> <36C3DA46-CCAB-4013-948D-736CBCD4C9F6@me.com> <4ADDA82F.8090806@gmail.com> Message-ID: <60A9234D-A4F4-4D1E-82A1-47860D0F4E9A@me.com> On 20 ??? 2009, at 3:08 ?.?., Simon Marlow wrote: > > It's not to do with Haskeline. The real underlying problem is that > our filesystem APIs on Unix interpret FilePath as [Word8] without > doing any encoding/decoding; they just strip off all but the low 8 > bits of each Char. This is a long-standing problem, and won't be > solved properly until we switch to an abstract FilePath type, but > that's a big change that will break lots of code. > > Lots more good discussion here: > > http://hackage.haskell.org/trac/ghc/ticket/3456 > > If there were a filePathToString function we could use it in GHC to > fix the above glitch. > > Cheers, > Simon Understood. Thank you very much for the pointer and your response. -- C. Chryssochoidis From redcom at fedoms.com Tue Oct 20 12:24:27 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Tue Oct 20 12:01:22 2009 Subject: The template-haskell@haskell.org mailing list In-Reply-To: <59543203684B2244980D7E4057D5FBC1061B628D@DB3EX14MBXC310.europe.corp.microsoft.com> References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> <59543203684B2244980D7E4057D5FBC1061B628D@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: Hi, would that move preserve the archive? G?nther Am 20.10.2009, 16:37 Uhr, schrieb Simon Peyton-Jones : > Question: is the template-haskell@haskell.org mailing list still useful? > > * It has 250 subscribers compared to 850 for ghc-users. > * It has low traffic > * template-haskell is the only GHC-specific mailing list associated > with a particular > language feature. Eg type functions, ghci, etc do not have their > own list > * The traffic on ghc-users is not dauntingly high. > > I suggest we abolish it in favour of ghc-users. Any dissenters? (I'd > emit a warning, so that people could check they are subscribed to > ghc-users.) > > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From kahl at cas.mcmaster.ca Tue Oct 20 14:20:33 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Tue Oct 20 13:57:31 2009 Subject: [Template-haskell] How to extract name and type of exported functions in modules In-Reply-To: <59543203684B2244980D7E4057D5FBC1061B62A1@DB3EX14MBXC310.europe.corp.microsoft.com> (message from Simon Peyton-Jones on Tue, 20 Oct 2009 14:38:33 +0000) References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> <59543203684B2244980D7E4057D5FBC1061B62A1@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <20091020182033.23437.qmail@schroeder.cas.mcmaster.ca> Simon Peyton Jones wrote: > What is the info for an instance? > Do we need a way to ask for all the instances of a class > (or rules for a function) > regardless of what module those instances come from? etc > > > Does this ring bells for anyone else? It does --- but completely outside the context of Template-Haskell. I have been trying to do things via the GHC API (the full API, not just module GHC), and found it surprisingly hard to obtain all exports for a given module (whether source or compiled library module): -- If it exports any prelude indentifiers (not only the Prelude itself, but also for example Data.List), I have no idea how to get at their types --- lookupGlobalName does not find them. -- I cannot find any re-exported instances. The ``package InstEnv'' obtained from tcGetInstEnvs after loading a library module interface (via findAndReadIface) seems to contain only the module's own exported instances, which are the same instances I also find via mi_insts. (For source modules, where I use typeCheckModule, I've only been able to find the module's own exported instances via hptInstances). Even while not counting the missing Prelude instances, Data.Map is still re-exporting the Data.Set instances from the same package --- where does GHC keep those? And where does it keep those from different packages? my current understanding of the ``home InstEnv'' is that it contains instances encountered during ``ghc --make'' that may not be visible in the current module, so if I ever do find instances there, how would I filter the visible ones? > Do we need a way to ask for all the instances of a class > (or rules for a function) > regardless of what module those instances come from? etc As long as a module re-exports an instance, I'd like to be able to find it from that module. > For example, if module exports T( C1, C2), where C1, C2 are constructors > of T which also has constructors C3, C4, what should appear in > mi_exports? Should mi_exports reflect the structure of the export list > (see the AvailInfo type in GHC). Applications that look at a module ``from the outside'' should, in my opinion, not be able see C3 and C4. I think they also do not need to be able to know that there are additional constructors. There is always _|_ that doesn't match C1 nor C2, even if there are no C3 nor C4. Applications that need to know more will want an interface that allows to ``look at all the insides'' of a module, i.e., they want access to all items defined and imported inside, and may of course also want to know which of these items are exported. Since there are other interfaces to find out that C1 and C2 belong to T, I don't think it is essential to know the structure of the export list. It may be convenient, though... (By the way, IIRC, sometimes I can import C1 as ``C1'', and sometimes I need to import it as ``T(C1)''. Is this a side effect of some LANGUAGE extension?) Wolfram From simonpj at microsoft.com Wed Oct 21 07:40:21 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 21 07:17:14 2009 Subject: [Template-haskell] How to extract name and type of exported functions in modules In-Reply-To: <20091020182033.23437.qmail@schroeder.cas.mcmaster.ca> References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> <59543203684B2244980D7E4057D5FBC1061B62A1@DB3EX14MBXC310.europe.corp.microsoft.com> <20091020182033.23437.qmail@schroeder.cas.mcmaster.ca> Message-ID: <59543203684B2244980D7E4057D5FBC1061B6B91@DB3EX14MBXC310.europe.corp.microsoft.com> | -- If it exports any prelude indentifiers (not only the Prelude itself, | but also for example Data.List), I have no idea how to get at | their types --- lookupGlobalName does not find them. Well, it claims that it should find them. Would you like to make a reproducible test case and file a Trac bug report? | -- I cannot find any re-exported instances. The ``package InstEnv'' | obtained from tcGetInstEnvs after loading a library module interface | (via findAndReadIface) seems to contain only the module's own exported | instances, which are the same instances I also find via mi_insts. | (For source modules, where I use typeCheckModule, | I've only been able to find the module's own exported instances via | hptInstances). Hmm. GHC does not read every interface file for every module in every package that is transitively visible from the current module. Instead it relies on the fact that before an instance (C T) is useful, you must have a hold of Class C and TyCon T. So you'll have loaded *their* interfaces, and thereby loaded their instances. (Except for orphan instances, which *are* loaded eagerly.) I can see that this is inconvenient; on the other hand, do you really want ALL the instances of Ord, say? Perhaps there should be an interface for load instances that relate to the following Names Indeed, there is: LoadIface.loadInterfaceForName. Does that help? What's the desired behaviour? I really wish there was someone who took ownership for the GHC API, as seen by "customers" of the API. At the moment it grows incrementally, without proper design. Maybe no one feels able to, because they think GHC HQ will do it, but (a) we are too busy and (b) we represent the suppliers of the API, not the customers. Any volunteeers? Simon From marlowsd at gmail.com Wed Oct 21 08:04:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Oct 21 07:41:27 2009 Subject: how can I get a listing of everything that's done in a program In-Reply-To: References: Message-ID: <4ADEF8CE.7090003@gmail.com> On 20/10/2009 14:54, Ralph Crawford wrote: > Hi. I'm working with GHC 6.10.4 on Solaris. I'm new at Haskell and > have inherited a rather large and complex program to maintain and > modify. I'd like to get a listing of everything - every single step - > that's done in a run of the program. Something similar to the output of > the :step command, but I'd like the entire run (which would involve tens > of thousands of steps). Is there a way to just do this - have it run > and print everything it does to the screen? > > I've tried doing the following, after starting a "script" to capture all > of the screen output... > > ghci -fglasgow-exts parsequery.hs > :break 36 > main > > which takes me to this prompt... > > Loading package mtl-1.1.0.2 ... linking ... done. > Stopped at lesearch.hs:36:13-39 > _result :: IO SearchState = _ > input :: [String] = _ > st :: SearchState = _ > [lesearch.hs:36:13-39] *Main> > > This takes me to the call before the one that I want to output each step > of so that I can then manually, with hardcopy, read it and get an idea > of what happened. > > So I start a step through the next call. > > [lesearch.hs:36:13-39] *Main> :step process_query_loop st input > Stopped at lesearch.hs:(46,0)-(69,39) > _result :: IO SearchState = _ > ... [lesearch.hs:(46,0)-(69,39)] *Main> > > So far so good. This is what I want to see - a listing like this for > every (interpreted of course) line of haskell code that runs, all the > way to the end. Since this is a very large program, at this point I > started pasting this to the terminal - 4 steps at a time... > > :step > :step > :step > :step > > This gave me the listing I wanted. But after a certain point, it > inevitably fails with a core dump, and what I capture from the screen is > garbled up to that point anyway. I'm hoping there's a simpler way to do > this. Thanks for taking the time to read this. If you get a core dump, that's obviously a bug. If you can supply us with a small program that illustrates the bug, please submit a bug report at http://hackage.haskell.org/trac/ghc/wiki/ReportABug As for getting a list of the evaluation steps, we don't have anything that does exactly what you want at the moment, but it probably wouldn't be hard to implement on top of the existing debugging functionality. Feel free to make a feature request, describing exactly what functionality you'd like to see: http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Cheers, Simon From csvanefalk at hushmail.me Wed Oct 21 08:06:05 2009 From: csvanefalk at hushmail.me (Christopher Svanefalk) Date: Wed Oct 21 07:42:56 2009 Subject: IP issues in writing a ghci adaption? Message-ID: <20091021120605.AD68EB00B6@smtp.hushmail.com> Hey everyone, If one wants to write a ghci-like application for the C++ language (and/or other languages as well FTM), which is not a derivative work of the ghci source, are there any intellectual property issues that need to be addressed? For example, would this tool be allowed to use similar syntax and commands as those in ghci (:r, :l etc), have a similar name (gcci?), carry some specific license, etc, or is the field clear? The reason I am asking is of course that I am currently working on something like this (although it will probably differ from ghci in terms of design, implementation, features etc) so I am thankful for any answers! kind regards, Christopher Svanefalk, Student (comp.sc.), Univeristy of Gothenburg, Sweden. From marlowsd at gmail.com Wed Oct 21 08:08:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Oct 21 07:45:21 2009 Subject: The template-haskell@haskell.org mailing list In-Reply-To: References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> <59543203684B2244980D7E4057D5FBC1061B628D@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <4ADEF9B3.50802@gmail.com> On 20/10/2009 17:24, G?nther Schmidt wrote: > Hi, > > would that move preserve the archive? It's possible to remove the mailing list facility itself without removing the archive, I believe. I'm not sure whether it leaves the web page for the mailing list in place, and if not, how the archives could be found. Cheers, Simon From marlowsd at gmail.com Wed Oct 21 08:09:39 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Oct 21 07:46:45 2009 Subject: IP issues in writing a ghci adaption? In-Reply-To: <20091021120605.AD68EB00B6@smtp.hushmail.com> References: <20091021120605.AD68EB00B6@smtp.hushmail.com> Message-ID: <4ADEFA03.2000404@gmail.com> On 21/10/2009 13:06, Christopher Svanefalk wrote: > If one wants to write a ghci-like application for the C++ language > (and/or other languages as well FTM), which is not a derivative > work of the ghci source, are there any intellectual property issues > that need to be addressed? For example, would this tool be allowed > to use similar syntax and commands as those in ghci (:r, :l etc), > have a similar name (gcci?), carry some specific license, etc, or > is the field clear? > > The reason I am asking is of course that I am currently working on > something like this (although it will probably differ from ghci in > terms of design, implementation, features etc) so I am thankful for > any answers! No IP issues. GHC is covered by a 3-clause BSD license. Cheers, Simon From marlowsd at gmail.com Thu Oct 22 05:15:26 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 22 04:52:19 2009 Subject: 6.12.1 release Message-ID: <4AE022AE.6090700@gmail.com> The current dilemma we're facing with the 6.12.1 release is this: cabal-install still needs to be ported to the new version of Cabal, Duncan is snowed under and doesn't have time to work on it, but without cabal-install people can't easily test 6.12.1 RC and we can't test it with Hackage. We've come to rely on cabal-install quite a lot. So, one option is just to release 6.12.1 as is, with the caveat that cabal-install doesn't work, and large portions of Hackage probably do not work (but we don't know what exactly). The platform isn't due to release with GHC 6.12.x until February 2010, and by then we could make a 6.12.2 to fix any problems that we discover when cabal-install is working. One potential problem is that having made the 6.12.1 release we wouldn't be able to make any further API changes, only bug fixes. Or, we could just make a 6.12.1 RC2, and advertise it with the same caveats, putting out 6.12.1 when cabal-install works and we've had a chance to see the state of Hackage and alert package authors. Simon and I favour the RC2 option. What do others think? Cheers, Simon From ganesh.sittampalam at credit-suisse.com Thu Oct 22 05:49:27 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Oct 22 05:26:29 2009 Subject: 6.12.1 release In-Reply-To: <4AE022AE.6090700@gmail.com> References: <4AE022AE.6090700@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FBC8@ELON17P32001A.csfb.cs-group.com> Simon Marlow wrote: > The current dilemma we're facing with the 6.12.1 release is this: > cabal-install still needs to be ported to the new version of Cabal, > Duncan is snowed under and doesn't have time to work on it, but > without cabal-install people can't easily test 6.12.1 RC and we can't > test it with Hackage. We've come to rely on cabal-install quite a > lot. Do we know how hard it is to make it work? > Simon and I favour the RC2 option. What do others think? +1 Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From niklas.broberg at gmail.com Thu Oct 22 05:56:15 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Oct 22 05:33:02 2009 Subject: 6.12.1 release In-Reply-To: <4AE022AE.6090700@gmail.com> References: <4AE022AE.6090700@gmail.com> Message-ID: > Simon and I favour the RC2 option. ?What do others think? +1 Definitely preferable to the chaos that would otherwise ensue. /Niklas From athas at sigkill.dk Thu Oct 22 06:00:27 2009 From: athas at sigkill.dk (Troels Henriksen) Date: Thu Oct 22 05:37:15 2009 Subject: 6.12.1 release In-Reply-To: <4AE022AE.6090700@gmail.com> (Simon Marlow's message of "Thu, 22 Oct 2009 10:15:26 +0100") References: <4AE022AE.6090700@gmail.com> Message-ID: <87ws2ng344.fsf@lambda.athas.dyndns.dk> Simon Marlow writes: > Simon and I favour the RC2 option. What do others think? This sounds about right. There's no reason to not be conservative here. -- \ Troels /\ Henriksen From Christian.Maeder at dfki.de Thu Oct 22 06:09:52 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Oct 22 05:46:41 2009 Subject: 6.12.1 release In-Reply-To: <4AE022AE.6090700@gmail.com> References: <4AE022AE.6090700@gmail.com> Message-ID: <4AE02F70.3080907@dfki.de> Simon Marlow schrieb: > Simon and I favour the RC2 option. What do others think? +1 I've quite some trouble to port our old code to ghc-6.12 and did not test RC1 much. http://trac.informatik.uni-bremen.de:8080/hets/ticket/749 http://www.informatik.uni-bremen.de/htk/ Cheers Christian From greenrd at greenrd.org Thu Oct 22 06:31:06 2009 From: greenrd at greenrd.org (Robin Green) Date: Thu Oct 22 06:08:19 2009 Subject: 6.12.1 release In-Reply-To: <4AE022AE.6090700@gmail.com> References: <4AE022AE.6090700@gmail.com> Message-ID: At Thu, 22 Oct 2009 10:15:26 +0100, Simon Marlow wrote: > > The current dilemma we're facing with the 6.12.1 release is this: > cabal-install still needs to be ported to the new version of Cabal, > Duncan is snowed under and doesn't have time to work on it, but without > cabal-install people can't easily test 6.12.1 RC and we can't test it > with Hackage. We've come to rely on cabal-install quite a lot. Agreed. I've actually now got cabal-install building successfully locally on ghc 6.12 rc1, but it dies with "cabal: Prelude.undefined". I'm attempting to debug this now. So hopefully it shouldn't be too long before I/we get it working. -- Robin From marlowsd at gmail.com Thu Oct 22 06:33:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 22 06:10:10 2009 Subject: 6.12.1 release In-Reply-To: <4AE02F70.3080907@dfki.de> References: <4AE022AE.6090700@gmail.com> <4AE02F70.3080907@dfki.de> Message-ID: <4AE034ED.50301@gmail.com> On 22/10/2009 11:09, Christian Maeder wrote: > Simon Marlow schrieb: >> Simon and I favour the RC2 option. What do others think? > > +1 > > I've quite some trouble to port our old code to ghc-6.12 > and did not test RC1 much. > > http://trac.informatik.uni-bremen.de:8080/hets/ticket/749 > http://www.informatik.uni-bremen.de/htk/ If you just need hPutBuf and hGetBuf, then get them from System.IO. Cheers, Simon From phercek at gmail.com Thu Oct 22 06:52:25 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Oct 22 06:29:39 2009 Subject: how can I get a listing of everything that's done in a program In-Reply-To: <4ADEF8CE.7090003@gmail.com> References: <4ADEF8CE.7090003@gmail.com> Message-ID: <4AE03969.4020509@gmail.com> Simon Marlow wrote: > On 20/10/2009 14:54, Ralph Crawford wrote: >> So far so good. This is what I want to see - a listing like this for >> every (interpreted of course) line of haskell code that runs, all the >> way to the end. Since this is a very large program, at this point I >> started pasting this to the terminal - 4 steps at a time... >> >> :step >> :step >> :step >> :step >> >> This gave me the listing I wanted. But after a certain point, it >> inevitably fails with a core dump, and what I capture from the screen is >> garbled up to that point anyway. I'm hoping there's a simpler way to do >> this. Thanks for taking the time to read this. > > If you get a core dump, that's obviously a bug. If you can supply us > with a small program that illustrates the bug, please submit a bug > report at > > http://hackage.haskell.org/trac/ghc/wiki/ReportABug > > As for getting a list of the evaluation steps, we don't have anything > that does exactly what you want at the moment, but it probably > wouldn't be hard to implement on top of the existing debugging > functionality. If you want to execute one command more times you can do it by scripting ghci. Add something like this to your ~/.ghci file: :{ let { cmdHlp _ msg longMsg "--help" = let fullMsg = if null longMsg then msg++"\n" else msg ++ ('\n':longMsg) in return $ "putStr "++show fullMsg ; cmdHlp _ msg _ "-h" = return $ "putStrLn "++show msg ; cmdHlp action _ _ args = action args } :} :{ :def * cmdHlp ( \cntCmd -> case break Data.Char.isSpace cntCmd of { ( cnt, _:cmd ) -> return $unlines $replicate (read cnt) cmd ; _ -> return "putStrLn \"usage: :* ...\"" } ) ":* ... -- run times" "" :} Then you can use it like this: % ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :* -h :* ... -- run times Prelude> :* --help :* ... -- run times Prelude> :* 3 :type sqrt 2 sqrt 2 :: (Floating t) => t sqrt 2 :: (Floating t) => t sqrt 2 :: (Floating t) => t Prelude> :quit Leaving GHCi. % More information about ghci scripting: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html More examples of how can you script ghci: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16912 Peter. From pepeiborra at gmail.com Thu Oct 22 07:05:37 2009 From: pepeiborra at gmail.com (Jose Iborra) Date: Thu Oct 22 06:42:33 2009 Subject: how can I get a listing of everything that's done in a program In-Reply-To: <4AE03969.4020509@gmail.com> References: <4ADEF8CE.7090003@gmail.com> <4AE03969.4020509@gmail.com> Message-ID: <4F684F56-DF34-4C79-B882-BAC27ADA5514@gmail.com> On 22/10/2009, at 12:52, Peter Hercek wrote: >> >> As for getting a list of the evaluation steps, we don't have >> anything that does exactly what you want at the moment, but it >> probably wouldn't be hard to implement on top of the existing >> debugging functionality. > > If you want to execute one command more times you can do it by > scripting ghci. Yes! That's a great idea Peter, we always underestimate/forget what can be done with the scripting capabilities of ghci. In this case, Ralph can get what he wants (modulo core dumps) with: *Main> :def listStep (\_ -> return ":list\n :step") *Main> :set stop :listStep *Main> :step Cheers pepe From Christian.Maeder at dfki.de Thu Oct 22 08:05:38 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Oct 22 07:42:27 2009 Subject: GHC.IO was: Re: 6.12.1 release In-Reply-To: <4AE034ED.50301@gmail.com> References: <4AE022AE.6090700@gmail.com> <4AE02F70.3080907@dfki.de> <4AE034ED.50301@gmail.com> Message-ID: <4AE04A92.4020102@dfki.de> Simon Marlow schrieb: > On 22/10/2009 11:09, Christian Maeder wrote: >> Simon Marlow schrieb: >>> Simon and I favour the RC2 option. What do others think? >> >> +1 >> >> I've quite some trouble to port our old code to ghc-6.12 >> and did not test RC1 much. >> >> http://trac.informatik.uni-bremen.de:8080/hets/ticket/749 >> http://www.informatik.uni-bremen.de/htk/ > > If you just need hPutBuf and hGetBuf, then get them from System.IO. Thanks for this hint. I got further (also after replacing some non-ascii characters in comments, i.e. a broken bar "-- ? ..."). The next spot is: Posixutil/CopyFile.hs:124:19: Not in scope: `slurpFile' copyFileToCStringLen :: FilePath -> IO CStringLen copyFileToCStringLen file = do (ptr,len) <- slurpFile file return (castPtr ptr,len) Cheers Christian From chak at cse.unsw.edu.au Thu Oct 22 20:02:22 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Oct 22 19:39:12 2009 Subject: 6.12.1 release In-Reply-To: <4AE022AE.6090700@gmail.com> References: <4AE022AE.6090700@gmail.com> Message-ID: Simon Marlow: > Or, we could just make a 6.12.1 RC2, and advertise it with the same > caveats, putting out 6.12.1 when cabal-install works and we've had a > chance to see the state of Hackage and alert package authors. > > Simon and I favour the RC2 option. What do others think? I agree. I don't think anybody benefits from an earlier, but buggier release. Manuel From sanzhiyan at gmail.com Fri Oct 23 04:39:10 2009 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Fri Oct 23 04:15:56 2009 Subject: haddock problem. Was: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <4AD35CC7.3060807@dfki.de> References: <20091011204153.GA5338@matrix.chaos.earth.li> <4AD35CC7.3060807@dfki.de> Message-ID: <8625cd9c0910230139g568ede3ek1f0bc45374781fb8@mail.gmail.com> On Mon, Oct 12, 2009 at 6:43 PM, Christian Maeder wrote: > Hi, > > with > http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ghc-6.12.0.20091010-i386-unknown-linux-n.tar.bz2 > installed (under /local/maeder/) I get the following "internal Haddock > or GHC error". I have no file > ?/local/maeder/lib/ghc-6.12.0.20091010/html/haddock.css > but a file > ?/local/maeder/share/doc/ghc/html/html/haddock.css I've the same problem, it seems that haddock's data-files are not installed anywhere by ghc's build system, even if they are present in the tarball under utils/haddock. /local/maeder/share/doc/ghc/html/html/haddock.css seems to be the .css for the main documentation index, i don't think it makes sense for haddock to take the default files from there. A workaround could be a separate installation of haddock (assuming it'll look for the files where cabal will install them), but i couldn't find a ghc-paths updated for 6.12. > and I run: > ?./Setup configure -O --prefix=/local/maeder > ?./Setup build > ?./Setup haddock > ?./Setup install > > Cheers Christian > > P.S. I wonder why "Registering" is done twice > > Configuring packedstring-0.1.0.1... > Preprocessing library packedstring-0.1.0.1... > Building packedstring-0.1.0.1... > [1 of 1] Compiling Data.PackedString ( Data/PackedString.hs, > dist/build/Data/PackedString.o ) > > Registering packedstring-0.1.0.1... > > Running Haddock for packedstring-0.1.0.1... > > Preprocessing library packedstring-0.1.0.1... > > Warning: The documentation for the following packages are not installed. > No > links will be generated to these packages: ffi-1.0, rts-1.0 > > haddock: internal Haddock or GHC error: > /local/maeder//lib/ghc-6.12.0.20091010/html/haddock.css: openFile: does > not exist (No such file or directory) > Installing library in > > /local/maeder/lib/packedstring-0.1.0.1/ghc-6.12.0.20091010 > > Registering packedstring-0.1.0.1... > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From red5_2 at hotmail.com Fri Oct 23 21:12:14 2009 From: red5_2 at hotmail.com (C Rodrigues) Date: Fri Oct 23 20:48:57 2009 Subject: Type checker's expected and inferred types Message-ID: I came across a type error that misled me for quite a while, because the expected and inferred types were backwards (from my point of view). A simplified example is below. Can someone explain how GHC's type checker creates the error message? In this example, fun1 and fun2 are basically the same. The type error is because they try to run an IO () together with a Maybe (). > import Control.Monad>> foo :: Maybe ()> foo = return ()>> bar :: IO ()> bar = return ()>> fun1 = let fooThen m = foo >> m> in fooThen (bar >> undefined)>> fun2 = let fooThen m = foo >> m> in fooThen (do {bar; undefined}) With ghc 6.10.4, both functions attribute the error message to `bar'. However, the expected and inferred monads are swapped.fun1 produces the error message:Couldn't match expected type `Maybe a' against inferred type `IO ()'In the first argument of `(>>=)', namely `bar'fun2 produces the error message:Couldn't match expected type `IO ()' against inferred type `Maybe ()'In a stmt of a 'do' expression: bar It's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO (). _________________________________________________________________ New Windows 7: Find the right PC for you. Learn more. http://www.microsoft.com/windows/pc-scout/default.aspx?CBID=wl&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_pcscout:102009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091023/8a6f74b9/attachment.html From red5_2 at hotmail.com Fri Oct 23 21:30:26 2009 From: red5_2 at hotmail.com (C Rodrigues) Date: Fri Oct 23 21:07:09 2009 Subject: Type checker's expected and inferred types (reformatted) Message-ID: (Some formatting was apparently lost en route. ?Trying again with extra newlines.) I came across a type error that misled me for quite a while, because the expected and inferred types were backwards (from my point of view). ?A simplified example is below. ?Can someone explain how GHC's type checker creates the error message? In this example, fun1 and fun2 are basically the same. ?The type error is because they try to run an IO () together with a Maybe (). > import Control.Monad > > foo :: Maybe () > foo = return () > > bar :: IO () > bar = return () > > fun1 = let fooThen m = foo>> m > ? ? ? ?in fooThen (bar>> undefined) > > fun2 = let fooThen m = foo>> m > ? ? ? ?in fooThen (do {bar; undefined}) With ghc 6.10.4, both functions attribute the error message to `bar'. However, the expected and inferred monads are swapped. fun1 produces the error message: Couldn't match expected type `Maybe a' against inferred type `IO ()' In the first argument of `(>>=)', namely `bar' fun2 produces the error message: Couldn't match expected type `IO ()' against inferred type `Maybe ()' In a stmt of a 'do' expression: bar It's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO (). _________________________________________________________________ Windows 7: Simplify your PC. Learn more. http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen1:102009 From ml at isaac.cedarswampstudios.org Fri Oct 23 21:46:36 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Fri Oct 23 21:23:31 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: References: Message-ID: <4AE25C7C.4080701@isaac.cedarswampstudios.org> C Rodrigues wrote: > fun1 produces the error message: > Couldn't match expected type `Maybe a' against inferred type `IO ()' > In the first argument of `(>>=)', namely `bar' > > > fun2 produces the error message: > Couldn't match expected type `IO ()' against inferred type `Maybe ()' > In a stmt of a 'do' expression: bar > > > It's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO (). Which message do you prefer? I couldn't tell which it was. For myself, I never understood the difference between "expected" and "inferred": it works better for me to just think "there were at least two different ways that determined the 'type' of this expression, and the results contradicted each other, and here are two of those results. Now, dear user, go and look at your code to intuit *what* those ways of determining the type might have been" (or sometimes it's easier just to look for mistakes, ignoring the particular details of the error) -Isaac From daniel.is.fischer at web.de Fri Oct 23 22:50:11 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Oct 23 22:28:14 2009 Subject: Type checker's expected and inferred types In-Reply-To: References: Message-ID: <200910240450.12105.daniel.is.fischer@web.de> Am Samstag 24 Oktober 2009 03:12:14 schrieb C Rodrigues: > I came across a type error that misled me for quite a while, because the > expected and inferred types were backwards (from my point of view). A > simplified example is below. Can someone explain how GHC's type checker > creates the error message? In this example, fun1 and fun2 are basically the > same. The type error is because they try to run an IO () together with a > Maybe (). > > import Control.Monad foo :: Maybe () foo = return () bar :: IO () bar = return () fun1 = let fooThen m = foo >> m in fooThen (bar >> undefined) fun2 = let fooThen m = foo >> m in fooThen (do {bar; undefined}) > > With ghc 6.10.4, both functions attribute the error message to `bar'. > However, the expected and inferred monads are swapped.fun1 produces the > error message: > Couldn't match expected type `Maybe a' against inferred type `IO ()' > In the first argument of `(>>=)', namely `bar' > fun2 produces the error message: > Couldn't match expected type `IO ()' against inferred type `Maybe ()' > In a stmt of a 'do' expression: bar > It's confusing because 'bar' > is inferred to have type Maybe (), even though it's explicitly declared to > be an IO (). I don't know the intricate details, but the order in which type inference/type checking proceeds has something to do with it. In fun1, apparently first the type of fooThen is inferred to be `Maybe a -> Maybe a'. Then, in the body of the let-expression, fooThen *expects* a `Maybe a'. Thus the (>>) in fooThen's argument is inferred to have the type `Maybe a -> Maybe b -> Maybe b'. Hence the first argument of (>>) [or (>>=), apparently it has been expanded to that] is *expected* to have type `Maybe a'. But from bar's definition, its type is *inferred* to be `IO ()'. Perfectly clear and transparent (not really). Had the type of fooThen's argument been inferred before fooThen's type, it would've said that it expected fooThen to have type `IO a -> b', but inferred it to have type `Maybe a -> Maybe a'. The error for fun2 is baffling. I can't explain how ghci comes to *expect* bar to have type `IO ()'. Also intriguing is that if you swap bar and undefined in the do-expression, you get the error message you'd expect: Couldn't match expected type `Maybe b' against inferred type `IO ()' In the expression: bar In the first argument of `fooThen', namely `(do undefined bar)' In the expression: fooThen (do undefined bar) But if you sandwich bar between two actions which may have type `Maybe a', it's back to expecting `IO ()': Couldn't match expected type `IO ()' against inferred type `Maybe ()' In a stmt of a 'do' expression: bar In the first argument of `fooThen', namely `(do Just 1 bar Nothing)' In the expression: fooThen (do Just 1 bar Nothing) Seems typechecking do-expressions has some strange corners. From dave at zednenem.com Sat Oct 24 00:50:57 2009 From: dave at zednenem.com (David Menendez) Date: Sat Oct 24 00:27:42 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <4AE25C7C.4080701@isaac.cedarswampstudios.org> References: <4AE25C7C.4080701@isaac.cedarswampstudios.org> Message-ID: <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> On Fri, Oct 23, 2009 at 9:46 PM, Isaac Dupree wrote: > C Rodrigues wrote: >> >> fun1 produces the error message: >> Couldn't match expected type `Maybe a' against inferred type `IO ()' >> In the first argument of `(>>=)', namely `bar' >> >> >> fun2 produces the error message: >> Couldn't match expected type `IO ()' against inferred type `Maybe ()' >> In a stmt of a 'do' expression: bar >> >> >> It's confusing because 'bar' is inferred to have type Maybe (), even >> though it's explicitly declared to be an IO (). > > Which message do you prefer? I couldn't tell which it was. > > For myself, I never understood the difference between "expected" and > "inferred": it works better for me to just think "there were at least two > different ways that determined the 'type' of this expression, and the > results contradicted each other, and here are two of those results. ?Now, > dear user, go and look at your code to intuit *what* those ways of > determining the type might have been" (or sometimes it's easier just to look > for mistakes, ignoring the particular details of the error) The expected type is what the context wants (it's *ex*ternal). The inferred type is what the expression itself has (it's *in*ternal). So inferring the type Maybe () for bar seems wrong. I'm guessing it's a bug in the way do-expressions are handled. Note that this doesn't happen if the bar is last. Prelude> :t let fooThen m = foo >> m in fooThen (do undefined; bar) :1:51: Couldn't match expected type `Maybe b' against inferred type `IO ()' In the expression: bar In the first argument of `fooThen', namely `(do undefined bar)' In the expression: fooThen (do undefined bar) Prelude> :t do foo; bar :1:8: Couldn't match expected type `Maybe b' against inferred type `IO ()' In the expression: bar In the expression: do foo bar Prelude> :t do foo; bar; foo :1:8: Couldn't match expected type `IO ()' against inferred type `Maybe ()' In a stmt of a 'do' expression: bar In the expression: do foo bar foo -- Dave Menendez From red5_2 at hotmail.com Sat Oct 24 00:57:18 2009 From: red5_2 at hotmail.com (C Rodrigues) Date: Sat Oct 24 00:34:01 2009 Subject: Type checker's expected and inferred types (reformatted) Message-ID: > Which message do you prefer? I couldn't tell which it was. I prefer fun1. ?In my understanding, the 'inferred' type is gleaned by looking at theexpression itself,?while the 'expected' type is implied by the context. _________________________________________________________________ Windows 7: It works the way you want. Learn more. http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen2:102009 From bulat.ziganshin at gmail.com Sat Oct 24 01:34:23 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Oct 24 01:20:08 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> References: <4AE25C7C.4080701@isaac.cedarswampstudios.org> <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> Message-ID: <12982291.20091024093423@gmail.com> Hello David, Saturday, October 24, 2009, 8:50:57 AM, you wrote: > The expected type is what the context wants (it's *ex*ternal). The > inferred type is what the expression itself has (it's *in*ternal). heh, how long we will need to learn decryption rules for this simple message? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From trebla at vex.net Sat Oct 24 15:21:51 2009 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat Oct 24 14:58:34 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <12982291.20091024093423@gmail.com> References: <4AE25C7C.4080701@isaac.cedarswampstudios.org> <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> <12982291.20091024093423@gmail.com> Message-ID: <4AE353CF.7020200@vex.net> For the record, and to speak up as part of a possible silent majority, I completely understand the type error messages. I find enough information in them. I like them. I find it unnecessary to "decrypt" the two words "expected" and "inferred". They have their own definitions and they stand for themselves; "external" and "internal" are helpful mnemonics, useful approximation, but not decryption. I support work on ghc to prioritize professional use over pedagogical use, that is, if a proposed pedagogical improvement conflicts with professional use concerns, or even if simply no one has time to implement, I support sacrificing the pedagogical improvement. To mitigate the sacrifice, we users write tutorials for each other. From daniel.is.fischer at web.de Sat Oct 24 15:47:12 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Oct 24 15:25:12 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <4AE353CF.7020200@vex.net> References: <12982291.20091024093423@gmail.com> <4AE353CF.7020200@vex.net> Message-ID: <200910242147.12383.daniel.is.fischer@web.de> Am Samstag 24 Oktober 2009 21:21:51 schrieb Albert Y. C. Lai: > For the record, and to speak up as part of a possible silent majority, > > I completely understand the type error messages. Mostly, I do, too. But I can't get why IO () is *expected* and Maybe () is *inferred* for bar in fun2. Can you explain? > I find enough information in them. I like them. Generally, it's the same for me, though some are better than others. Even if one doesn't completely understand them, it's rare that one can't get enough out of them to start fixing the code. > > I find it unnecessary to "decrypt" the two words "expected" and > "inferred". They have their own definitions and they stand for > themselves; "external" and "internal" are helpful mnemonics, useful > approximation, but not decryption. > > I support work on ghc to prioritize professional use over pedagogical > use, that is, if a proposed pedagogical improvement conflicts with > professional use concerns, or even if simply no one has time to > implement, I support sacrificing the pedagogical improvement. Seconded. > To mitigate the sacrifice, we users write tutorials for each other. From ml at isaac.cedarswampstudios.org Sun Oct 25 13:37:33 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Oct 25 13:14:22 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> References: <4AE25C7C.4080701@isaac.cedarswampstudios.org> <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> Message-ID: <4AE48CDD.6020308@isaac.cedarswampstudios.org> David Menendez wrote: > The expected type is what the context wants (it's *ex*ternal). The > inferred type is what the expression itself has (it's *in*ternal). > > So inferring the type Maybe () for bar seems wrong. well, maybe GHC just gets it wrong enough of the time, that I got confused. Or maybe ... When there are bound variables interacting, on the inside and outside, it gets confusing. ghci: Prelude> \x -> (3+x) + (length x) :1:15: Couldn't match expected type `[a]' against inferred type `Int' In the second argument of `(+)', namely `(length x)' In the expression: (3 + x) + (length x) In the expression: \ x -> (3 + x) + (length x) Your explanation of "expected" and "inferred" could make sense to me if the error message followed the "Couldn't match" line with, instead, "In the first argument of `length', namely `x'" because 'length' gives the context of expected list-type, but we've found out from elsewhere (a vague word) that 'x' needs to have type Int. If we flip around the expression-order, we get Prelude> \x -> (length x) + (3+x) :1:20: Couldn't match expected type `Int' against inferred type `[a]' In the second argument of `(+)', namely `(3 + x)' In the expression: (length x) + (3 + x) In the expression: \ x -> (length x) + (3 + x) ...and yes, technically your explanation of expected/inferred works. But the location/parity depends on the evaluation-order that the type checker uses. The error messages don't seem to specify location precisely enough that I can easily use the information about which type is the 'expected' type and which type is the 'inferred' one. There are usually more chains of inference, let-clauses, etc. through which a contradiction is found, that muddy the issue. hmm. Yes, I think I would appreciate for error messages to tell me exactly which piece of the expression is expected/inferred to be those types. (Is this always a sensible question? or are there sometimes typing-conflicts that can't be / aren't reduced to the expected/inferred type of a particular expression in the code?) -Isaac From dave at zednenem.com Sun Oct 25 16:02:51 2009 From: dave at zednenem.com (David Menendez) Date: Sun Oct 25 15:39:29 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <4AE48CDD.6020308@isaac.cedarswampstudios.org> References: <4AE25C7C.4080701@isaac.cedarswampstudios.org> <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> <4AE48CDD.6020308@isaac.cedarswampstudios.org> Message-ID: <49a77b7a0910251302h12402a15u9de5fef0d11f4e96@mail.gmail.com> On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree wrote: > David Menendez wrote: >> >> The expected type is what the context wants (it's *ex*ternal). The >> inferred type is what the expression itself has (it's *in*ternal). >> >> So inferring the type Maybe () for bar seems wrong. > > well, maybe GHC just gets it wrong enough of the time, that I got confused. > > Or maybe ... When there are bound variables interacting, on the inside and > outside, it gets confusing. > > > ghci: > Prelude> \x -> (3+x) + (length x) > > :1:15: > ? ?Couldn't match expected type `[a]' against inferred type `Int' > ? ?In the second argument of `(+)', namely `(length x)' > ? ?In the expression: (3 + x) + (length x) > ? ?In the expression: \ x -> (3 + x) + (length x) > > Your explanation of "expected" and "inferred" could make sense to me if the > error message followed the "Couldn't match" line with, instead, > ? ?"In the first argument of `length', namely `x'" > because 'length' gives the context of expected list-type, but we've found > out from elsewhere (a vague word) that 'x' needs to have type Int. This had me confused for a while, but I think I've worked out what's happening. (+) is polymorphic, and GHC is giving it the type [a] -> [a] -> [a]. So the context is expecting [a], but we infer length x :: Int from the definition of length. In the alternate case, \x -> length x + (3+x), GHC gives the outer (+) the type Int -> Int -> Int, and the inner (+) the type [a] -> [a] -> [a], which is why we get the type mismatch complaint for 3+x instead of x. Note what happens if we use a monomorphic operator: Prelude> let (<>) = undefined :: Int -> Int -> Int Prelude> \x -> (3+x) <> length x :1:22: Couldn't match expected type `[a]' against inferred type `Int' In the first argument of `length', namely `x' In the second argument of `(<>)', namely `length x' In the expression: (3 + x) <> length x Prelude> \x -> (3+x) + length x Here, GHC has concluded that x must be an Int, and thus can't be passed to length. Prelude> \x -> length x <> (3+x) :1:19: Couldn't match expected type `Int' against inferred type `[a]' In the second argument of `(<>)', namely `(3 + x)' In the expression: length x <> (3 + x) In the expression: \ x -> length x <> (3 + x) Here, GHC has concluded that x must be [a], and thus 3+x must be [a], which can't be used with <>. -- Dave Menendez From ml at isaac.cedarswampstudios.org Sun Oct 25 17:23:51 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Oct 25 17:00:41 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <49a77b7a0910251302h12402a15u9de5fef0d11f4e96@mail.gmail.com> References: <4AE25C7C.4080701@isaac.cedarswampstudios.org> <49a77b7a0910232150x519930e4mb0fae68badeea703@mail.gmail.com> <4AE48CDD.6020308@isaac.cedarswampstudios.org> <49a77b7a0910251302h12402a15u9de5fef0d11f4e96@mail.gmail.com> Message-ID: <4AE4C1E7.7050109@isaac.cedarswampstudios.org> David Menendez wrote: > On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree > wrote: >> David Menendez wrote: >>> The expected type is what the context wants (it's *ex*ternal). The >>> inferred type is what the expression itself has (it's *in*ternal). >>> >>> So inferring the type Maybe () for bar seems wrong. >> well, maybe GHC just gets it wrong enough of the time, that I got confused. >> >> Or maybe ... When there are bound variables interacting, on the inside and >> outside, it gets confusing. >> >> >> ghci: >> Prelude> \x -> (3+x) + (length x) >> >> :1:15: >> Couldn't match expected type `[a]' against inferred type `Int' >> In the second argument of `(+)', namely `(length x)' >> In the expression: (3 + x) + (length x) >> In the expression: \ x -> (3 + x) + (length x) >> >> Your explanation of "expected" and "inferred" could make sense to me if the >> error message followed the "Couldn't match" line with, instead, >> "In the first argument of `length', namely `x'" >> because 'length' gives the context of expected list-type, but we've found >> out from elsewhere (a vague word) that 'x' needs to have type Int. > > This had me confused for a while, but I think I've worked out what's > happening. (+) is polymorphic, ... Oh darn, it sounds like you're right. And polymorphism is so common. I just came up with that example randomly as the first nontrivial type-error-with-a-lambda I could think of... I wonder if it would help for the message to also output what it thinks the complete type of the function is (so far). I wonder if it could look something like this: Couldn't match expected type `[a]' against inferred type `Int' In the second argument of `(+) :: [a] -> [a]', namely `(length x) :: Int' (always, at the risk/tradeoff of taking up space with lots of useless information. sadly. hmm.) Ideally I would like GHC to pick a location for the error that's more intuitive, but that sounds like an awfully vague desire :-) -Isaac From petersen at haskell.org Wed Oct 28 02:06:39 2009 From: petersen at haskell.org (Jens Petersen) Date: Wed Oct 28 01:43:09 2009 Subject: haddock problem. Was: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <8625cd9c0910230139g568ede3ek1f0bc45374781fb8@mail.gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <4AD35CC7.3060807@dfki.de> <8625cd9c0910230139g568ede3ek1f0bc45374781fb8@mail.gmail.com> Message-ID: <9436bffe0910272306r1fbe449emf242c65399c7254b@mail.gmail.com> 2009/10/23 Andrea Vezzosi : > On Mon, Oct 12, 2009 at 6:43 PM, Christian Maeder >> I get the following "internal Haddock or GHC error". I have no file >> /local/maeder/lib/ghc-6.12.0.20091010/html/haddock.css >> but a file >> /local/maeder/share/doc/ghc/html/html/haddock.css > > I've the same problem, it seems that haddock's data-files are not > installed anywhere by ghc's build system, even if they are present in > the tarball under utils/haddock. I think this is http://hackage.haskell.org/trac/ghc/ticket/3599 which was apparently fixed a few days ago by Ian. Jens From jwlato at gmail.com Wed Oct 28 08:14:46 2009 From: jwlato at gmail.com (John Lato) Date: Wed Oct 28 07:51:17 2009 Subject: Type checker's expected and inferred types (reformatted) Message-ID: <9979e72e0910280514o5b9e96eerfb23cbbea279b39d@mail.gmail.com> > From: Isaac Dupree > David Menendez wrote: >> On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree >> wrote: >>> David Menendez wrote: >>>> The expected type is what the context wants (it's *ex*ternal). The >>>> inferred type is what the expression itself has (it's *in*ternal). >>>> >>>> So inferring the type Maybe () for bar seems wrong. >>> well, maybe GHC just gets it wrong enough of the time, that I got confused. >>> >>> Or maybe ... When there are bound variables interacting, on the inside and >>> outside, it gets confusing. >>> >>> >>> ghci: >>> Prelude> \x -> (3+x) + (length x) >>> >>> :1:15: >>> ? ?Couldn't match expected type `[a]' against inferred type `Int' >>> ? ?In the second argument of `(+)', namely `(length x)' >>> ? ?In the expression: (3 + x) + (length x) >>> ? ?In the expression: \ x -> (3 + x) + (length x) >>> >>> Your explanation of "expected" and "inferred" could make sense to me if the >>> error message followed the "Couldn't match" line with, instead, >>> ? ?"In the first argument of `length', namely `x'" >>> because 'length' gives the context of expected list-type, but we've found >>> out from elsewhere (a vague word) that 'x' needs to have type Int. >> >> This had me confused for a while, but I think I've worked out what's >> happening. (+) is polymorphic, ? ... > > Oh darn, it sounds like you're right. And polymorphism is so common. ?I > just came up with that example randomly as the first nontrivial > type-error-with-a-lambda I could think of... I think this is a great example of why the current type errors are not as helpful as they could be. The code where the type checker determines 'x' has type [a] is several steps removed from where the error arises. This is how I understand this process (I've probably left out some details): 1. checker infers x :: [a] from 'length x' 2. checker infers (3 + x) :: [a] from (+) and step 1 3. checker infers the second (+) :: [a] -> [a] -> [a] from step 2 4. conflict - checker expects (length x) :: [a] from step 3 and infers (length x) :: Int from definition of 'length'. Even with this simple example the error message given doesn't directly point to the problem. I don't think it's uncommon for there to be more steps in practice. I frequently find myself adding explicit type signatures to let-bound functions to debug these. This is a pain because it also usually involves enabling ScopedTypeVariables. I personally would find it useful if error messages showed the sequence of how the type checker determined the given context. Especially if it would also do so for infinite type errors, which don't provide much useful information to me. Cheers, John From avatar at hot.ee Wed Oct 28 09:49:21 2009 From: avatar at hot.ee (Misha Aizatulin) Date: Wed Oct 28 09:25:57 2009 Subject: ghc search paths (like CPATH for gcc) In-Reply-To: <4ADC351A.6090200@gmail.com> References: <4ADBE845.4040008@hot.ee> <4ADC351A.6090200@gmail.com> Message-ID: <4AE84BE1.4080104@hot.ee> Simon Marlow wrote: > On 19/10/2009 05:17, Misha Aizatulin wrote: >> Hello, >> >> is there a mechanism for ghc similar to setting the CPATH variable for >> gcc? I'd like ghc to look in the given list of paths every time it >> compiles something, without me having to retype the flags. >> >> For ghci there is .ghci, but it gets ignored when I run ghc. > > We don't have anything like that right now. Please submit a feature > request: Done: http://hackage.haskell.org/trac/ghc/ticket/3619 Misha From wasserman.louis at gmail.com Wed Oct 28 16:23:16 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Wed Oct 28 16:00:05 2009 Subject: Coinductive proofs of type class instances Message-ID: Hey all, There was a discussiona while back about coinductive proofs of type class instances, discussing a problem I'd encountered independently, and worked out a rough solution to. I wanted to see if that solution had been reached by other people, and throw it into the mix. My problem is slightly different, though, so it may not generalize. First consider the problem that GHC doesn't allow type equality constraints in class definitions, so for example, > class (F a ~ b) => Foo a b In particular, if I wanted F a to be *uniquely* associated with A, I might say that > class (F a ~ b) => Foo a b | b -> a where > type F a As a result, F would be a *bijective type family*, enforced by the type system. Interestingly, the GHC docs suggest something like this as an implementation for functional dependencies in general: > class Foo a b | a -> b is equivalent to > class (F a ~ b) => Foo a b where > type Foo a except, of course, the latter isn't implemented in 6.10.4. All of this is idealized though: if GHC allowed equality constraints in superclass contexts, then this would be nice. Here was my workaround: a type class Foo is essentially a list of methods foo1 :: Foo a => ..... foo2 :: Foo a => ..... Of course, if there are superclass constraints on Foo a, those are implicitly included here. My thought was that > class (F a ~ b) => Foo a b where > foo1 :: (constraints1) => ... is essentially equivalent to > class Foo a b where > foo1 :: (F a ~ b, contraints1) => ... save that everywhere we encounter a (Foo a b) constraint, we replace it with (Foo a b, F a ~ b). Now, of course, we might have a (Foo a b) constraint in another superclass context, and have to recurse. That might even be fine, though I haven't worked it out. For this particular example, though, (Foo a (F a)) is equivalent to (F a ~ b, Foo a b). This approach actually, I think, works out some coinductive issues, if we apply this approach to issues besides type equality constraints. Louis Wasserman wasserman.louis@gmail.com http://profiles.google.com/wasserman.louis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091028/37a74c15/attachment.html From simonpj at microsoft.com Wed Oct 28 18:55:00 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 28 18:30:44 2009 Subject: Update on GHC 6.12.1 Message-ID: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> Folks This is an update on the status of GHC 6.12. FIRST, as you probably know, Hackage and the Haskell Platform is allowing GHC HQ to get out of the libraries business. So the plan is - We release GHC 6.12 with very few libraries - Bill Library Author downloads GHC 6.12 and tests his libraries - The next Haskell Platform release packages GHC 6.12 with these tested libraries - Joe User downloads the Haskell Platform. - Four months later there's a new HP release, still with GHC 6.12, but with more or better libraries. The HP release cycle is decoupled from GHC So if you are Joe User, you want to wait for the HP release. Don't grab the GHC 6.12 release. It'll be perfectly usable, but only if you use (an up to date) cabal-install to download libraries, and accept that they may not be tested with GHC 6.12. SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are about to produce RC2. However, before releasing 6.12 we'd like to compile all of Hackage, in case doing so reveals bugs in GHC's APIs (which are not supposed to change). But we can't do that until an update to cabal-install is ready. (We don't expect this dependency to happen all the time, but it does hold for 6.12.) Duncan has been working on the cabal-install update, and expects to release by end November. So the timetable looks like this: - Very soon: GHC 6.12.1 release candidate 2 - End Nov: cabal-install release - ...test GHC against Hackage... - Early Dec: release GHC 6.12 - ...library authors and HP folk get busy... - End Jan (?): Haskell Platform release - ...Joe User downloads HP... FINALLY, below I summarise a late change that's been pending for a long time, which I propose to sneak into RC2, for reasons explained below. If you can see a good reason not to do this, yell. Simon Recursive do-notation. ~~~~~~~~~~~~~~~~~~~~~~ The change is this. Instead of writing mdo { a <- getChar ; b <- f c ; c <- g b ; putChar c ; return b } you would write do { a <- getChar ; rec { b <- f c ; c <- g b } ; putChar c ; return b } That is, * 'mdo' is eliminated * 'rec' is added, which groups a bunch of statements into a single recursive statement See http://hackage.haskell.org/trac/ghc/ticket/2798 This 'rec' thing is already present for the arrow notation, so it makes the two more uniform. Moreover, 'rec' lets you say more precisely where the recursion is (if you want to), whereas 'mdo' just says "there's recursion here somewhere". Lastly, all this works with rebindable syntax (which mdo does not). Currently 'mdo' is enabled by -XRecursiveDo. So we propose to deprecate this flag, with another flag -XDoRec to enable the 'rec' keyword. The main question is not whether to make this change, but when. I'm inclined to do put it into GHC 6.12, even though it's late in the day because then we can take mdo out of 6.14 altogether. Another minor question is whether "-XDoRec" is a good name for the flag. We can't really use "-XRecursiveDo" because that's the one we are deprecating! From kahl at cas.mcmaster.ca Wed Oct 28 20:09:01 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed Oct 28 19:45:34 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> (message from Simon Peyton-Jones on Wed, 28 Oct 2009 22:55:00 +0000) References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <20091029000901.31502.qmail@schroeder.cas.mcmaster.ca> Simon Peyton Jones wrote: > > Recursive do-notation. > ~~~~~~~~~~~~~~~~~~~~~~ > The change is this. Instead of writing > > mdo { a <- getChar > ; b <- f c > ; c <- g b > ; putChar c > ; return b } > > you would write > > do { a <- getChar > ; rec { b <- f c > ; c <- g b } > ; putChar c > ; return b } > > That is, > * 'mdo' is eliminated > * 'rec' is added, which groups a bunch of statements > into a single recursive statement > See http://hackage.haskell.org/trac/ghc/ticket/2798 > > This 'rec' thing is already present for the arrow notation, so it > makes the two more uniform. Moreover, 'rec' lets you say more > precisely where the recursion is (if you want to), whereas 'mdo' just > says "there's recursion here somewhere". Lastly, all this works with > rebindable syntax (which mdo does not). > > The main question is not whether to make this change, but when. This last point notwithstanding, I find the scoping rules very unintuitive! (b and c appear to escape their apparently nested scope.) Wolfram From roland.zumkeller at gmail.com Thu Oct 29 00:54:59 2009 From: roland.zumkeller at gmail.com (Roland Zumkeller) Date: Thu Oct 29 00:31:48 2009 Subject: ghc hung by FunctionalDependencies/UndecidableInstances Message-ID: Hi, ghc seems to hang and eat memory when fed the following code: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-} class C a b | a -> b where f :: a -> b newtype T a = T a instance (C a b, Eq b) => Eq (T a) where (==) = undefined g x = (undefined :: a -> a -> a -> ()) (T x) (f x) (undefined :: Eq a => a) Is this a bug? Best, Roland -- http://alacave.net/~roland/ From bulat.ziganshin at gmail.com Thu Oct 29 03:33:04 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Oct 29 03:15:27 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <769092247.20091029103304@gmail.com> Hello Simon, Thursday, October 29, 2009, 1:55:00 AM, you wrote: > Currently 'mdo' is enabled by -XRecursiveDo. So we propose to > deprecate this flag, with another flag -XDoRec to enable the 'rec' > keyword. i think the best way is to support both in 6.12, marking mdo usage as deprecated, and remove it in one of next versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From kazu at iij.ad.jp Thu Oct 29 04:31:03 2009 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu Oct 29 04:08:08 2009 Subject: How to know data size in UDP? Message-ID: <20091029.173103.148260080.kazu@iij.ad.jp> Hello, I'm trying to implement DNS resolver without any external C libraries for my daemon program which uses DNS lookup. I know the "hsdns" library exists. But since it calls GNU asynchronous DNS resolver library by FFI, all threads of Haskell are blocked on non-threaded RTS. If the threaded RTS is used, forkProcess kills the IO thread. With the threaded RTS of at least GHC 6.10.4, we cannot make our program as a daemon nor use pre-fork mechanism. Thus, I decided to implement DNS resolver only with non-blocking Haskell functions. I use a *connected* UDP socket like this: proto <- getProtocolNumber "udp" let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_NUMERICHOST, AI_PASSIVE] , addrSocketType = Datagram , addrProtocol = proto } a:_ <- getAddrInfo (Just hints) (Just "An IP address of DNS server") (Just "domain") sock <- socket (addrFamily a) (addrSocketType a) (addrProtocol a) connect sock (addrAddress a) h <- socketToHandle sock ReadWriteMode hSetBuffering h NoBuffering hSetBinaryMode h True If my understating is correct, I cannot use recvFrom since it calls recvfrom() with FFI. So, I use socketToHandle to translate a socket to a handle. Since the handle is associated with UDP, the entire data size should be known when a UDP packet arrived. But I cannot find a way to know data size. (I want a function like hFileSize.) Note that hGetContents blocks. Without data size in advance, a program to handle network protocols on UDP becomes quite dirty or sometime cannot be implemented. So, please tell me how to know data size associated with a handler of UDP? --Kazu From kazu at iij.ad.jp Thu Oct 29 04:31:03 2009 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu Oct 29 04:08:14 2009 Subject: How to know data size in UDP? Message-ID: <20091029.173103.148260080.kazu@iij.ad.jp> Hello, I'm trying to implement DNS resolver without any external C libraries for my daemon program which uses DNS lookup. I know the "hsdns" library exists. But since it calls GNU asynchronous DNS resolver library by FFI, all threads of Haskell are blocked on non-threaded RTS. If the threaded RTS is used, forkProcess kills the IO thread. With the threaded RTS of at least GHC 6.10.4, we cannot make our program as a daemon nor use pre-fork mechanism. Thus, I decided to implement DNS resolver only with non-blocking Haskell functions. I use a *connected* UDP socket like this: proto <- getProtocolNumber "udp" let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_NUMERICHOST, AI_PASSIVE] , addrSocketType = Datagram , addrProtocol = proto } a:_ <- getAddrInfo (Just hints) (Just "An IP address of DNS server") (Just "domain") sock <- socket (addrFamily a) (addrSocketType a) (addrProtocol a) connect sock (addrAddress a) h <- socketToHandle sock ReadWriteMode hSetBuffering h NoBuffering hSetBinaryMode h True If my understating is correct, I cannot use recvFrom since it calls recvfrom() with FFI. So, I use socketToHandle to translate a socket to a handle. Since the handle is associated with UDP, the entire data size should be known when a UDP packet arrived. But I cannot find a way to know data size. (I want a function like hFileSize.) Note that hGetContents blocks. Without data size in advance, a program to handle network protocols on UDP becomes quite dirty or sometime cannot be implemented. So, please tell me how to know data size associated with a handler of UDP? --Kazu From p.k.f.holzenspies at utwente.nl Thu Oct 29 04:37:24 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Thu Oct 29 04:13:48 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <9979e72e0910280514o5b9e96eerfb23cbbea279b39d@mail.gmail.com> References: <9979e72e0910280514o5b9e96eerfb23cbbea279b39d@mail.gmail.com> Message-ID: <1256805444.28991.8.camel@ewi1043> Dear GHCers, On Wed, 2009-10-28 at 12:14 +0000, John Lato wrote: > >> This had me confused for a while, but I think I've worked out what's > >> happening. (+) is polymorphic, ... > > > > Oh darn, it sounds like you're right. And polymorphism is so common. I > > just came up with that example randomly as the first nontrivial > > type-error-with-a-lambda I could think of... > > I think this is a great example of why the current type errors are not > as helpful as they could be. The code where the type checker > determines 'x' has type [a] is several steps removed from where the > error arises. This is how I understand this process (I've probably > left out some details): I am a little ambiguous on this issue; I usually find GHC's type errors make me realize what I did wrong very quickly, i.e. until I start messing with combinations of GADTs, type classes and type families. When I've looked at an error for too long without understanding what's happening, I usually look for ways to express the same problem in simpler constructs. This case has me stumped, though. > 1. checker infers x :: [a] from 'length x' > 2. checker infers (3 + x) :: [a] from (+) and step 1 > 3. checker infers the second (+) :: [a] -> [a] -> [a] from step 2 Pardon? Judging from the error GHC gives, you must be right, but isn't *this* the point where things should go wrong? I'm not too intimately familiar with the type checker's internals, so this example leads me to speculate that "normal" types are inferred and checked *before* type class constraints are evaluated. However, I would have wanted this error: Prelude> [1] + [2] :1:0: No instance for (Num [t]) arising from a use of `+' at :1:0-8 Possible fix: add an instance declaration for (Num [t]) In the expression: [1] + [2] In the definition of `it': it = [1] + [2] In other words: isn't the problem in this case that the type checker does not gather all information (no instance of type class Num) to give the proper error? Is gathering type class information after "normal" types have already conflicted even possible? Regards, Philip From simonpj at microsoft.com Thu Oct 29 04:48:03 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 29 04:23:48 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <20091029000901.31502.qmail@schroeder.cas.mcmaster.ca> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <20091029000901.31502.qmail@schroeder.cas.mcmaster.ca> Message-ID: <59543203684B2244980D7E4057D5FBC1061BAB50@DB3EX14MBXC310.europe.corp.microsoft.com> | > do { a <- getChar | > ; rec { b <- f c | > ; c <- g b } | > ; putChar c | > ; return b } | This last point notwithstanding, | I find the scoping rules very unintuitive! | (b and c appear to escape their apparently nested scope.) well you are happy with do { z <- getChar ; let { b = f c ; c = g b } ; putChar c ; return b } It's just the same! Perhaps I should mention this in the user manual. (In haskell 'let' means 'letrec' of course.) Simon From simonpj at microsoft.com Thu Oct 29 05:53:59 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 29 05:29:44 2009 Subject: ghc hung by FunctionalDependencies/UndecidableInstances In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1061BAC18@DB3EX14MBXC310.europe.corp.microsoft.com> No, it's behaving exactly as expected. If you omit UndecidableInstances the program is rejected. If you add that flag you are saying "you are allowed to diverge if I screw up". And indeed you wrote a looping type problem. I added some comments below that may help explain. Simon {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-} module X() where class C a b | a -> b where f :: a -> b newtype T a = T a instance (C a b, Eq b) => Eq (T a) where (==) = undefined g x = (undefined :: d -> d -> d -> ()) (T x) (f x) (undefined :: Eq e => e) -- f :: C a b => a -> b -- x :: a -- b ~ T a -- C a b -- b ~ e -- Eq e {- Hence need (C a (T a), Eq (T a)) Apply instance for Eq = (C a (T a), C a g, Eq g) Apply functional dependency: g ~ T a = (C a (T a), C a (T a), Eq (T a)) And now we are back where we started -} | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Roland Zumkeller | Sent: 29 October 2009 04:55 | To: glasgow-haskell-users@haskell.org | Subject: ghc hung by FunctionalDependencies/UndecidableInstances | | Hi, | | ghc seems to hang and eat memory when fed the following code: | | {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, | UndecidableInstances #-} | class C a b | a -> b where f :: a -> b | newtype T a = T a | instance (C a b, Eq b) => Eq (T a) where (==) = undefined | g x = (undefined :: a -> a -> a -> ()) (T x) (f x) (undefined :: Eq a => a) | | Is this a bug? | | Best, | | Roland | | -- | http://alacave.net/~roland/ | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From jwlato at gmail.com Thu Oct 29 06:38:11 2009 From: jwlato at gmail.com (John Lato) Date: Thu Oct 29 06:14:38 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <1256805444.28991.8.camel@ewi1043> References: <9979e72e0910280514o5b9e96eerfb23cbbea279b39d@mail.gmail.com> <1256805444.28991.8.camel@ewi1043> Message-ID: <9979e72e0910290338t12129ddcse606138dabfc32b0@mail.gmail.com> On Thu, Oct 29, 2009 at 8:37 AM, Philip K.F. wrote: > Dear GHCers, > > > On Wed, 2009-10-28 at 12:14 +0000, John Lato wrote: >> >> This had me confused for a while, but I think I've worked out what's >> >> happening. (+) is polymorphic, ? ... >> > >> > Oh darn, it sounds like you're right. And polymorphism is so common. ?I >> > just came up with that example randomly as the first nontrivial >> > type-error-with-a-lambda I could think of... >> >> I think this is a great example of why the current type errors are not >> as helpful as they could be. ?The code where the type checker >> determines 'x' has type [a] is several steps removed from where the >> error arises. ?This is how I understand this process (I've probably >> left out some details): > > I am a little ambiguous on this issue; I usually find GHC's type errors > make me realize what I did wrong very quickly, i.e. until I start > messing with combinations of GADTs, type classes and type families. When > I've looked at an error for too long without understanding what's > happening, I usually look for ways to express the same problem in > simpler constructs. > > This case has me stumped, though. > >> 1. ?checker infers x :: [a] from 'length x' >> 2. ?checker infers (3 + x) :: [a] from (+) and step 1 >> 3. ?checker infers the second (+) :: [a] -> [a] -> [a] from step 2 > > Pardon? Judging from the error GHC gives, you must be right, but isn't > *this* the point where things should go wrong? I'm not too intimately > familiar with the type checker's internals, so this example leads me to > speculate that "normal" types are inferred and checked *before* type > class constraints are evaluated. This "(+) :: [a] -> [a] -> [a]" seems wrong from an intuitive sense, but the type checker doesn't know that. We know that (+) :: Num t => t -> t -> t It's completely legal (though maybe ill-advised) to construct a Num instance for [a]. Even if that instance isn't in scope when this code is compiled, it could be added later. I should probably wait for a GHC guru to respond to this one, because I'm in the realm of speculation here, but I expect that "normal" types need to be inferred, unified, and checked before type class constraints can be applied. In the case where a constraint is necessary, either the type is a concrete type, e.g. Int, Char, for which the class instance must be in scope, or the type is polymorphic, e.g. [a], in which case the constraint must be passed up to the context of where it's used. The compiler doesn't know which is the case (or exactly what context is necessary) until it's finished checking the "normal" types. > However, I would have wanted this > error: > > Prelude> [1] + [2] > > :1:0: > ? ?No instance for (Num [t]) > ? ? ?arising from a use of `+' at :1:0-8 > ? ?Possible fix: add an instance declaration for (Num [t]) > ? ?In the expression: [1] + [2] > ? ?In the definition of `it': it = [1] + [2] > > In other words: isn't the problem in this case that the type checker > does not gather all information (no instance of type class Num) to give > the proper error? Is gathering type class information after "normal" > types have already conflicted even possible? > Just because a type class isn't in scope doesn't mean it will never be in scope. In order for this to work, you'd need to distinguish between code that will never be linked to from elsewhere and code that will. I don't think this is possible without completely changing the compilation chain. Ghci can do it because, as an interpreter, it doesn't produce object code to be linked to anyway. John From simonpj at microsoft.com Thu Oct 29 06:41:45 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 29 06:18:15 2009 Subject: Update on GHC 6.12.1 In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <769092247.20091029103304@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1061BACB8@DB3EX14MBXC310.europe.corp.microsoft.com> | Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) Oh cruel, cruel, cruel! And unjustified to boot. My proposal (perhaps unclear) was exactly as Bulat suggests. However I'm sure we'll find some other way of breaking existing programs :-) Simon | -----Original Message----- | From: Lennart Augustsson [mailto:lennart.augustsson@gmail.com] | Sent: 29 October 2009 10:25 | To: Bulat Ziganshin | Cc: Simon Peyton-Jones; GHC users | Subject: Re: Update on GHC 6.12.1 | | Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) | | -- Lennart (iPhone) | | On 29 Oct 2009, at 03:33, Bulat Ziganshin | wrote: | | > Hello Simon, | > | > Thursday, October 29, 2009, 1:55:00 AM, you wrote: | > | >> Currently 'mdo' is enabled by -XRecursiveDo. So we propose to | >> deprecate this flag, with another flag -XDoRec to enable the 'rec' | >> keyword. | > | > i think the best way is to support both in 6.12, marking mdo usage as | > deprecated, and remove it in one of next versions | > | > -- | > Best regards, | > Bulat mailto:Bulat.Ziganshin@gmail.com | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From duncan.coutts at googlemail.com Thu Oct 29 06:57:24 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu Oct 29 06:33:51 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1256813844.2471.1641.camel@localhost> On Wed, 2009-10-28 at 22:55 +0000, Simon Peyton-Jones wrote: > SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are > about to produce RC2. However, before releasing 6.12 we'd like to > compile all of Hackage, in case doing so reveals bugs in GHC's APIs > (which are not supposed to change). But we can't do that until an > update to cabal-install is ready. (We don't expect this dependency to > happen all the time, but it does hold for 6.12.) > > Duncan has been working on the cabal-install update, and expects > to release by end November. So the timetable looks like this: > > - Very soon: GHC 6.12.1 release candidate 2 > - End Nov: cabal-install release > - ...test GHC against Hackage... An update on this: People can now grab the current darcs version of cabal-install and build and test it with ghc-6.12 (or indeed earlier ghc versions). Duncan From allbery at ece.cmu.edu Thu Oct 29 07:45:05 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Oct 29 07:21:46 2009 Subject: How to know data size in UDP? In-Reply-To: <20091029.173103.148260080.kazu@iij.ad.jp> References: <20091029.173103.148260080.kazu@iij.ad.jp> Message-ID: <0A10D308-E458-4212-BE23-F67DC2B5D7D7@ece.cmu.edu> On Oct 29, 2009, at 04:31 , Kazu Yamamoto (????) wrote: > Since the handle is associated with UDP, the entire data size should > be known when a UDP packet arrived. But I cannot find a way to know > data size. (I want a function like hFileSize.) Note that hGetContents > blocks. The short answer is: you can't. You need to find a way to make recv() work. Longer: read() is intended for streams. If you read() a datagram socket you may get a single packet or the system may combine packets; which one happens depends on the kernel implementation, and you are not guaranteed to have anything sane happen. The best case for you would be if the system returns a single packet per system call, in which case you read() into a maximally sized buffer and the returned length is that of the actual packet. However, many systems choose to retain the stream nature of read() and will return any information that comes in, losing the packet boundaries. In the case of DNS, you can almost get away with this anyway because the protocol specifies a maximum UDP request/response length of 255 octets sent as a single packet. If this is insufficient, you need to switch to TCP. In the case of a response, you will get a truncated response and will need to recognize it by parsing the data and retry the query over TCP. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091029/a31a1b02/PGP-0001.bin From kahl at cas.mcmaster.ca Thu Oct 29 10:07:19 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Thu Oct 29 09:43:49 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BAB50@DB3EX14MBXC310.europe.corp.microsoft.com> (message from Simon Peyton-Jones on Thu, 29 Oct 2009 08:48:03 +0000) References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <20091029000901.31502.qmail@schroeder.cas.mcmaster.ca> <59543203684B2244980D7E4057D5FBC1061BAB50@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <20091029140719.17905.qmail@schroeder.cas.mcmaster.ca> Simon Peyton Jones answered me: > | > do { a <- getChar > | > ; rec { b <- f c > | > ; c <- g b } > | > ; putChar c > | > ; return b } > > > | This last point notwithstanding, > | I find the scoping rules very unintuitive! > | (b and c appear to escape their apparently nested scope.) > > well you are happy with ^^^^^ (Let's say: I got used to it...) > > do { z <- getChar > ; let { b = f c > ; c = g b } > ; putChar c > ; return b } > > It's just the same! Indeed; I had not noticed that. (I am spoilt by layout, and had never ``seen'' those braces before.) However, if you write those braces, there is no reason anymore to omit the ``in do'' at the end! This variant of let is only motivated by layout... Analogously, is | > do { a <- getChar | > ; rec { b <- f c | > ; c <- g b } | > ; putChar c | > ; return b } equivalent to | > do { a <- getChar | > ; rec { b <- f c | > ; c <- g b } in do | > { putChar c | > ; return b } ? Is | > do { rec { b <- f c | > ; c <- g b } | > ; putChar c | > ; return b } equivalent to | > rec { b <- f c | > ; c <- g b } in do | > { putChar c | > ; return b } ? Would ``dorec'', in analogy with ``letrec'', perhaps be a better name? Wolfram From simonpj at microsoft.com Thu Oct 29 10:27:48 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 29 10:04:16 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <20091029140719.17905.qmail@schroeder.cas.mcmaster.ca> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <20091029000901.31502.qmail@schroeder.cas.mcmaster.ca> <59543203684B2244980D7E4057D5FBC1061BAB50@DB3EX14MBXC310.europe.corp.microsoft.com> <20091029140719.17905.qmail@schroeder.cas.mcmaster.ca> Message-ID: <59543203684B2244980D7E4057D5FBC1061BAFE0@DB3EX14MBXC310.europe.corp.microsoft.com> | Analogously, is | | | > do { a <- getChar | | > ; rec { b <- f c | | > ; c <- g b } | | > ; putChar c | | > ; return b } | | equivalent to | | | > do { a <- getChar | | > ; rec { b <- f c | | > ; c <- g b } in do | | > { putChar c | | > ; return b } No, there is no rec { ss } in e form; nor should there be since rec { ss } is monadic. | Is | | | > do { rec { b <- f c | | > ; c <- g b } | | > ; putChar c | | > ; return b } | | equivalent to | | | > rec { b <- f c | | > ; c <- g b } in do | | > { putChar c | | > ; return b } No. Same answer. Simon From garious at gmail.com Thu Oct 29 13:24:23 2009 From: garious at gmail.com (Greg Fitzgerald) Date: Thu Oct 29 13:01:08 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1f3dc80d0910291024x412a6111of6f51b5f835e4b3d@mail.gmail.com> > Another minor question is whether "-XDoRec" is a good > name for the flag. We can't really use "-XRecursiveDo" > because that's the one we are deprecating! "-XReDo" :) -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091029/d7df03df/attachment.html From scooter.phd at gmail.com Thu Oct 29 14:05:24 2009 From: scooter.phd at gmail.com (scooter.phd@gmail.com) Date: Thu Oct 29 13:41:44 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <1f3dc80d0910291024x412a6111of6f51b5f835e4b3d@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com><1f3dc80d0910291024x412a6111of6f51b5f835e4b3d@mail.gmail.com> Message-ID: <1234953703-1256839514-cardhu_decombobulator_blackberry.rim.net-1877815428-@bda437.bisx.prod.on.blackberry> Is there a good motivating example for recursive do? So far, I haven't grokked the various use cases, which are pretty terse. Maybe the syntax sugar gets in the way (dangling lets are a good case in point). It's a bit like grokking a Monad: it's the way to alter state, through a chain of binds, culminating in a return, where values can't escape outside the Monad itself. Using IO as the example w/the (hidden) realworld parameter makes the explanation more opaque than it need be. -scooter Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Greg Fitzgerald Date: Thu, 29 Oct 2009 10:24:23 To: Simon Peyton-Jones Cc: GHC users Subject: Re: Update on GHC 6.12.1 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Fri Oct 30 05:51:37 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 30 05:27:21 2009 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <1256813844.2471.1641.camel@localhost> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <1256813844.2471.1641.camel@localhost> Message-ID: <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> Friends One more update about GHC 6.12, concerning impredicative polymorphism. GHC has had an experimental implementation of impredicative polymorphism for a year or two now (flag -XImpredicativePolymorphism). But a) The implementation is ridiculously complicated, and the complexity is pervasive (in the type checker) rather than localized. I'm very unhappy about this, especially as we add more stuff to the type checker for type families. b) The specification (type system) is well-defined [1], but is also pretty complicated, and it's just too hard to predict which programs will typecheck and which will not. So it's time for a re-think. I propose to deprecate it in 6.12, and remove it altogether in 6.14. We may by then have something else to put in its place. (There is no lack of candidates [2,3,4]!) Fortunately, I don't think a lot of people use the feature in anger. Please yell if you *are* using impredicative polymorphism for something serious. But if you are, we need to think of a workaround. The current situation seems unsustainable. Simon [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/ [2] http://research.microsoft.com/en-us/um/people/crusso/qml/ [3] http://research.microsoft.com/en-us/um/people/daan/pubs.html [4] http://gallium.inria.fr/~remy/mlf/ From simonpj at microsoft.com Fri Oct 30 06:16:06 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 30 05:52:32 2009 Subject: [Template-haskell] How to extract name and type of exported functions in modules In-Reply-To: <1510d7310910291426q7b652c95jb3dbdb6a4d15c2c9@mail.gmail.com> References: <1510d7310910161047p87a9ec9wbc956ba1e246b5a5@mail.gmail.com> <59543203684B2244980D7E4057D5FBC1061B62A1@DB3EX14MBXC310.europe.corp.microsoft.com> <1510d7310910291426q7b652c95jb3dbdb6a4d15c2c9@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1061BB89D@DB3EX14MBXC310.europe.corp.microsoft.com> | First I thought I would examine the source code of template-haskell | (more specifically qLocation and qReify) to figure out how to do it | but got stuck. Obviously I have still much to learn when it comes to | Haskell. | | Could someone explain how Quasi works? Have you read the paper? Referred to from here http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html, the particular bit you want is Section 10 of http://research.microsoft.com/~simonpj/papers/meta-haskell/notes2.ps | The only way this can work (as fast as I can see) is if where is | another instance of Quasi than Q and IO but I cannot find that | instance in the source code. Yes indeed there is -- the type checker monad! See TcSplice line 819. Simon From ganesh.sittampalam at credit-suisse.com Fri Oct 30 06:22:45 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Oct 30 06:00:01 2009 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com><1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FC1F@ELON17P32001A.csfb.cs-group.com> Simon Peyton-Jones wrote: > Fortunately, I don't think a lot of people use the feature in anger. > Please yell if you *are* using impredicative polymorphism for > something serious. But if you are, we need to think of a workaround. > The current situation seems unsustainable. I think darcs is using it. At least, I had to enable ImpredicativePolymorphism to successfully build darcs with GHC 6.11 (a snapshot from about February), although the flag is not required with GHC 6.10. I haven't had a chance to try with the RC yet, but will do this weekend. I'll have to check the full details of why it's needed, but from memory I think it can be worked around at the cost of more verbosity by using some newtypes in appropriate places. 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 nccb2 at kent.ac.uk Fri Oct 30 13:17:16 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Fri Oct 30 12:53:41 2009 Subject: GHC, CPP and stringize Message-ID: <4AEB1F9C.30702@kent.ac.uk> Hi, The GHC manual says that if you pass -cpp to GHC, it runs the C preprocessor, "cpp" on your code before compilation (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor). But why, in that case, does stringize not seem to work when the -cpp flag is given? In my example, test.hs is using the C preprocessor with a simple macro to trace functions with their name. Running GHC with -cpp gives an error, but if I run cpp on the file directly then feed it to GHC, I get no error: ===== *$ ghc --version* The Glorious Glasgow Haskell Compilation System, version 6.10.3 *$ cat test.hs* import Debug.Trace #define TR(f) (trace #f f) main :: IO () main = TR(putStrLn) "Hello!" *$ ghc -cpp --make test.hs* [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:6:14: Not in scope: `#' *$ cpp test.hs* # 1 "test.hs" # 1 "" # 1 "" # 1 "test.hs" import Debug.Trace main :: IO () main = (trace "putStrLn" putStrLn) "Hello!" *$ cpp test.hs > test-cpp.hs* *$ ghc -cpp --make test-cpp.hs* [1 of 1] Compiling Main ( test-cpp.hs, test-cpp.o ) Linking test-cpp ... *$ ./test-cpp* putStrLn Hello! ===== What am I missing? Thanks, Neil. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091030/e735c89d/attachment.html From duncan.coutts at googlemail.com Fri Oct 30 13:52:52 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Oct 30 13:29:17 2009 Subject: GHC, CPP and stringize In-Reply-To: <4AEB1F9C.30702@kent.ac.uk> References: <4AEB1F9C.30702@kent.ac.uk> Message-ID: <1256925172.2471.3578.camel@localhost> On Fri, 2009-10-30 at 17:17 +0000, Neil Brown wrote: > Hi, > > The GHC manual says that if you pass -cpp to GHC, it runs the C > preprocessor, "cpp" on your code before compilation > (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor). But why, in that case, does stringize not seem to work when the -cpp flag is given? > #define TR(f) (trace #f f) > What am I missing? That ghc uses cpp in traditional mode so it does not grok new ANSI C things like cpp string concatenation. As I understand it we have to use traditional CPP because some modern features break Haskell code. Really we should all move over to cpphs. Duncan From ben_moseley at mac.com Fri Oct 30 14:44:06 2009 From: ben_moseley at mac.com (Ben Moseley) Date: Fri Oct 30 14:20:33 2009 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <72019503-77F1-4460-9CBA-2F9189D6BD9A@mac.com> Is there any difference between "-XImpredicativePolymorphism" and "- XImpredicativeTypes"? Hyena uses the latter, and we're using Hyena somewhat "in anger". --Ben On 30 Oct 2009, at 09:51, Simon Peyton-Jones wrote: > Friends > > One more update about GHC 6.12, concerning impredicative polymorphism. > > GHC has had an experimental implementation of impredicative > polymorphism for a year or two now (flag - > XImpredicativePolymorphism). But > > a) The implementation is ridiculously complicated, and the complexity > is pervasive (in the type checker) rather than localized. > I'm very unhappy about this, especially as we add more stuff to > the type checker for type families. > > b) The specification (type system) is well-defined [1], but is also > pretty > complicated, and it's just too hard to predict which programs will > typecheck and which will not. > > So it's time for a re-think. I propose to deprecate it in 6.12, and > remove it altogether in 6.14. We may by then have something else to > put in its place. (There is no lack of candidates [2,3,4]!) > > Fortunately, I don't think a lot of people use the feature in > anger. Please yell if you *are* using impredicative polymorphism > for something serious. But if you are, we need to think of a > workaround. The current situation seems unsustainable. > > Simon > > [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/ > [2] http://research.microsoft.com/en-us/um/people/crusso/qml/ > [3] http://research.microsoft.com/en-us/um/people/daan/pubs.html > [4] http://gallium.inria.fr/~remy/mlf/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ganesh at earth.li Sat Oct 31 10:14:00 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Oct 31 09:50:20 2009 Subject: array-0.2.0.0 doesn't build with 6.12rc1 Message-ID: [ 6 of 10] Compiling Data.Array.IO ( Data/Array/IO.hs, dist/build/Data/Array/IO.o ) Data/Array/IO.hs:73:13: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:22: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:36: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:74:5: Not in scope: data constructor `Buffer' Data/Array/IO.hs:74:13: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:25: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:36: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:75:4: Not in scope: `bufferEmpty' Data/Array/IO.hs:82:24: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:82:35: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:86:24: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:95:27: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:101:10: Not in scope: `readRawBuffer' Data/Array/IO.hs:125:22: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:31: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:45: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:127:18: Not in scope: data constructor `Buffer' Data/Array/IO.hs:127:26: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:42: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:53: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:135:30: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:142:7: Not in scope: data constructor `Buffer' Data/Array/IO.hs:142:15: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:27: `bufState' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:36: Not in scope: data constructor `WriteBuffer' Data/Array/IO.hs:143:8: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:19: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:34: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:151:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:151:43: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:35: Not in scope: type constructor or class `RawBuffer' From hdeyoung at cs.cmu.edu Sat Oct 31 14:27:05 2009 From: hdeyoung at cs.cmu.edu (Henry DeYoung) Date: Sat Oct 31 14:03:24 2009 Subject: Assembler errors when compiling nofib benchmarks with -optc-g Message-ID: <1966.71.60.115.140.1257013625.squirrel@webmail.cs.cmu.edu> Hi, I am working with another grad student on a course project on cache behavior of GHC programs. The first part of this project is to reproduce some of the measurements from Nethercote and Mycroft's "The Cache Behavior of Large Lazy Functional Programs on Stock Hardware". We've decided to use oprofile to sample cache misses recorded by the performance counters. To get reasonable information out of oprofile, I'd like to compile the nofib benchmarks via C with export of debugging symbols. As a first step toward this, I've changed the NoFibHcOpts variable in nofib/mk/boilerplate.mk to be: NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g However, when I do make in the nofib/real/compress directory, for example, I get the following error message: ==nofib== compress: time to compile BinConv follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinCon v.hs -o BinConv.o <> 1.27user 0.12system 0:01.39elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+21251minor)pagefaults 0swaps ==nofib== compress: size of BinConv.o follows... text data bss dec hex filename 6677 192 8 6877 1add BinConv.o ==nofib== compress: time to compile BinTest follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinTes t.hs -o BinTest.o /tmp/ghc14909_0/ghc14909_0.s: Assembler messages: /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: junk at end of line, first unrecognized character is `0' etc... Curiously, if I remove the -optc-g flag, but still use -fvia-C and -pgmc gcc, everything works fine. Do you have any ideas what might be causing these errors? Is there a fix or workaround to get the C compiler to export debugging symbols? Second, it appears that a make with -fvia-C -pgmc gcc removes the C source after it has been compiled. Is there a way to preserve this source so that it can be annotated line by line using oprofile? I apologize if these questions are rudimentary; this is my first experience with GHC and nofib. Also, if these questions should be directed toward a different mailing list, please let me know. Thanks for any help you can give with this! Henry From 1haskell at pkturner.org Sat Oct 31 15:54:52 2009 From: 1haskell at pkturner.org (Scott Turner) Date: Sat Oct 31 15:31:11 2009 Subject: Type checker's expected and inferred types (reformatted) In-Reply-To: <9979e72e0910280514o5b9e96eerfb23cbbea279b39d@mail.gmail.com> References: <9979e72e0910280514o5b9e96eerfb23cbbea279b39d@mail.gmail.com> Message-ID: <200910311554.52659.1haskell@pkturner.org> On Wednesday 28 October 2009 08:14:46 John Lato wrote: > >> Isaac Dupree wrote: > >>> ghci: > >>> Prelude> \x -> (3+x) + (length x) > >>> > >>> :1:15: > >>> Couldn't match expected type `[a]' against inferred type `Int' > >>> In the second argument of `(+)', namely `(length x)' > >>> In the expression: (3 + x) + (length x) > >>> In the expression: \ x -> (3 + x) + (length x) > > This is how I understand this process > > 1. checker infers x :: [a] from 'length x' > 2. checker infers (3 + x) :: [a] from (+) and step 1 > 3. checker infers the second (+) :: [a] -> [a] -> [a] from step 2 > 4. conflict - checker expects (length x) :: [a] from step 3 > and infers (length x) :: Int from definition of 'length'. > > Even with this simple example the error message given doesn't directly > point to the problem. I don't think it's uncommon for there to be > more steps in practice. I frequently find myself adding explicit type > signatures to let-bound functions to debug these. This is a pain > because it also usually involves enabling ScopedTypeVariables. I'll second that. On Saturday 24 October 2009 15:21:51 Albert Y. C. Lai wrote: >I find it unnecessary to "decrypt" the two words "expected" and >"inferred". They have their own definitions and they stand for >themselves; On the contrary, this is a perfect example of why the error message's choice of words is bad. One type is "expected" and the other is "inferred". In the example the contextual type [a] is inferred via steps 1-2-3, and the internal type Int is determined so trivially that the "inferred" designation is somewhere between confusing and misleading. I'd love to see "expected" kept, and "inferred" removed from the message.