- Glasgow-haskell-users

RE: bug with definition at top-level:
by Simon Peyton-Jones 12 Jun '03

12 Jun '03

This embarrassing bug in GHC 6.0 has been reported several times now. There's a good workaround: just say :t GHC.Err.error as your first command in GHCi. Then it'll be happy with your subsequent definition. Simon | -----Original Message----- | From: glasgow-haskell-bugs-admin(a)haskell.org [mailto:glasgow-haskell-bugs-admin@haskell.org] On | Behalf Of Hal Daume III | Sent: 11 June 2003 23:56 | To: glasgow-haskell-bugs(a)haskell.org | Subject: bug with definition at top-level: | | 3:54pm moussor:handalign/ ghci | ___ ___ _ | / _ \ /\ /\/ __(_) | / /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98. | / /_\\/ __ / /___| | http://www.haskell.org/ghc/ | \____/\/ /_/\____/|_| Type :? for help. | | Loading package base ... linking ... done. | Loading package lang ... linking ... done. | Prelude> let f s = let (p1:_:p2:_:r1:_:f2:_) = map read (words s) in show | ((2*p1*r1)/(p1+r1)) ++ " & " ++ show ((2*p2*f2)/(p2+f2)) | ghc-6.0: panic! (the `impossible' happened, GHC version 6.0): | getLinkDeps No iface for [<pkg>]GHCziErr | | Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, | or http://sourceforge.net/projects/ghc/. | | | | -- | Hal Daume III | hdaume(a)isi.edu | "Arrest this man, he talks in maths." | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

Conditions on deriving Typeable
by George Russell 11 Jun '03

11 Jun '03

Please satisfy my curiosity, what is it about data WrappedDisplayType = forall displayType . DisplayType displayType => WrappedDisplayType displayType deriving (Typeable) that causes GHC 6.0 to utter DisplayTypes.hs:135: Can't make a derived instance of `Typeable WrappedDisplayType' (`WrappedDisplayType' has existentially-quantified constructor(s)) When deriving instances for type `WrappedDisplayType' Obviously it doesn't like the existential quantifier, but why should that be a problem for Typeable?

1 0

RE: Problems building GHC 6.0 with gcc 3.3
by Simon Marlow 10 Jun '03

10 Jun '03

> I'm having problems building GHC 6.0 with GCC 3.3. I've fixed a couple > of problems with comments in CPP macros as seen elsewhere, and then > everything seemed to be going fine until it came to create > stage2/ghc-6.0 and it failed with a huge number of things like > > stage2/utils/Util.o(.text+0xb8): In function `r4c8_entry': > : undefined reference to `GHCziBase_True_closure' > stage2/utils/Util.o(.text+0xc8): In function `r4c8_entry': > : undefined reference to `GHCziBase_False_closure' Fixed in CVS, thanks for the report. Workaround: don't use GCC 3.3 (yet). Cheers, Simon

1 0

RE: directories not closed?
by Simon Marlow 10 Jun '03

10 Jun '03

> I regularly call getDirectoryContents on a certain directory > looking for > changes, when I 'lsof' my process (list open files) it has an absurd > number of open descriptors to said directory open. I didn't see an > obvious bug in getDirectoryContents, does anyone know what is > going on? Hmm. It looks fine to me: I just tried a test doing getDirectoryContents repeatedly on the same directory and it re-uses the same descriptor each time. An strace might be useful... > Also, did the fixes for sockets not getting properly closed all the > time make it into 6.00? I am trying to track down some out of > descriptor problems. Yes, all the fixes to Network are in 6.0. Cheers, Simon

1 0

RE: happy, ghc and {# OPTIONS #} pragma
by Simon Marlow 10 Jun '03

10 Jun '03

> Martin Norbäck <d95mback(a)dtek.chalmers.se> writes: > > > {-# OPTIONS -fglasgow-exts -cpp #-} > > -- parser produced by Happy Version 1.13 > > {-# OPTIONS -fno-warn-unused-matches #-} > > Generally, it'd be nice to be able to occasionally suppress warnings > for sections of code (with better than module granularity), where you > know the code is safe. > > Any chance of something like that? Yes, it would indeed be useful. I doubt we'll get around to it in the near future, though. Cheers, Simon

1 0

Bom dia glasgow-haskell-users
by kandrak 10 Jun '03

10 Jun '03

Message to glasgow-haskell-users(a)haskell.org Ola!!!! glasgow-haskell-users GANHAMOS O PRÊMIO DE MELHOR SITE DO RAMO ======Estamos operando em Novo Formato====== Confira em: escuta21.kit.net ou http://www.escuta21.kit.net ei.... glasgow-haskell-users Cuidado com o que fala ao Celular... ele tb tem ouvidos... para remover o glasgow-haskell-users(a)haskell.org de nossa lista responda este e-mail e coloque remover nos perdoe o transtorno...ok? kandrak

1 0

happy, ghc and {# OPTIONS #} pragma
by Martin Norbäck 10 Jun '03

10 Jun '03

I am trying to get an {-# OPTIONS #-} pragma to appear in my Happy generated file, since I use warnings and want to disable them for this file. I'm putting the pragma first in the module header section of my Happy file. My problem is that the generated file starts like this (the first pragma is generated by Happy): {-# OPTIONS -fglasgow-exts -cpp #-} -- parser produced by Happy Version 1.13 {-# OPTIONS -fno-warn-unused-matches #-} This means that GHC will only see the first one. Is there a way to make Happy put the pragma above the comment, or not produce the comment at all? Or is there a way to make GHC recognise the pragma even though it is after a comment? Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

2 1

irg.ssu.ac.kr
by Helen Baker 10 Jun '03

10 Jun '03

Hi, I thought you might be interested in getting in-depth knowledge about your web audience and web traffic patterns in a reliable and cost-effective way. Stop Guessing - Start Knowing! - CoolStats measures web site traffic and online behavior of your visitors. - CoolStats will help you understand how to optimize your site to meet the needs of your visitors. - You get access to detailed, real-time statistical analysis of your web pages - 24 hours a day. Click at http://www.coolstats.com/viewdemo/index.html to view Online Demo. - CoolStats is the ultimate real-time tracking solution for small and mid-sized businesses. - 100% accuracy by measuring activity at the client, not via server based log files. - The fee of $24.95 is minimal compared to what it would cost you to run a tracking service yourself! Why CoolStats? - no programming to do - no servers to maintain - no software applications to install Click at http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000027294.2552.15.$DVMso4hjPjrNd to Sign Up now! "We needed to make business sense out of our web visitor behavior - CoolStats delivers first-class graphical reports that help us continuously improve and optimize our website to match the requirements of our target audience." BRYAN KASHILIN, BOSTON Click at http://www.coolstats.com/product/customerref.html to check what other customers say about us! For more information about our website tracking services, please visit our website or contact me directly at the below email. I look forward to hearing from you soon. Best regards, Helen Baker CoolStats Support Email: helen_baker(a)coolstats.com Http://www.coolstats.com Don't be the last one to know! ----------------------------------------------------------------------- This message has been brought to glasgow-haskell-users(a)haskell.org. If you do not wish to receive anymore emails, please follow the opt-out instruction below. We apologize for any inconvenience.

1 0

directories not closed?
by John Meacham 09 Jun '03

09 Jun '03

I regularly call getDirectoryContents on a certain directory looking for changes, when I 'lsof' my process (list open files) it has an absurd number of open descriptors to said directory open. I didn't see an obvious bug in getDirectoryContents, does anyone know what is going on? Also, did the fixes for sockets not getting properly closed all the time make it into 6.00? I am trying to track down some out of descriptor problems. thanks. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 0

Problems building GHC 6.0 with gcc 3.3
by Ian Lynagh 09 Jun '03

09 Jun '03

I'm having problems building GHC 6.0 with GCC 3.3. I've fixed a couple of problems with comments in CPP macros as seen elsewhere, and then everything seemed to be going fine until it came to create stage2/ghc-6.0 and it failed with a huge number of things like stage2/utils/Util.o(.text+0xb8): In function `r4c8_entry': : undefined reference to `GHCziBase_True_closure' stage2/utils/Util.o(.text+0xc8): In function `r4c8_entry': : undefined reference to `GHCziBase_False_closure' In fact, even building hello world with stage1/ghc-inplace failed, starting with ./Foo.o(.text+0x28): In function `sxG_srt': : undefined reference to `GHCziBase_unpackCStringzh_closure' ./Foo.o(.text+0x85): In function `sxG_entry': : undefined reference to `GHCziBase_unpackCStringzh_closure' /home/igloo/ghc6/attempt1/ghc6-6.0/libraries/base/libHSbase.a(Prelude__1.o)(.text+0xa): In function `__stginit_Prelude_': : undefined reference to `_module_registered' /home/igloo/ghc6/attempt1/ghc6-6.0/libraries/base/libHSbase.a(Prelude__1.o)(.text+0x17): In function `__stginit_Prelude_': : undefined reference to `_module_registered' Looking at the first of these I discovered that the split libraries thought that GHCziBase_unpackCStringzh_closure is a local symbol, so ld -x was discarding it. $ ghc6-6.0/ghc/driver/split/ghc-split Base.split_s Base.split Base.split $ gcc -c -o Base.o Base.s $ gcc -c -o Base__131.o Base.split__131.s $ objdump -t Base.o | grep GHCziBase_unpackCStringzh_closure 00000378 g O .data 00000004 GHCziBase_unpackCStringzh_closure $ objdump -t Base__131.o | grep GHCziBase_unpackCStringzh_closure 00000000 l .data 00000000 GHCziBase_unpackCStringzh_closure $ Compiling these files with gcc 2.95 has the same problem. I'm out of my depth here, but I would guess the assembler generated has changed and the evil mangler now goes wrong? I've put the GHC build log, the result of compiling hello world with -v, Base.s, Base.split_s, Base.split, Base.split__131.s at http://urchin.earth.li/~ian/gcc3.3/ Thanks Ian

1 1