Re: Template Haskell: dataToExpQ and constructor mis-match
On Tue, Jan 24, 2012 at 09:55:35AM -0800, Conal Elliott wrote: I'm looking for a reliable way to turn values into Template Haskell expressions. I thought dataToExpQ from Language.Haskell.TH.Quote was the ticket, but it appears to produce constructors different from those produced by [| ... |], including [], (:), (), and (,). I've fixed this in the HEAD. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Documentation Bug?
On Wed, Dec 14, 2011 at 05:39:15PM +, Dominic Steinitz wrote: The link on http://www.haskell.org/ghc/docs/latest/html/users_guide/hpc.html to http://www.haskell.org/hpc seems to be broken. Thanks for the report. This has been fixed. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4370: Bring back monad comprehensions
On Fri, Jan 07, 2011 at 12:42:58PM -, GHC wrote: context as we a) don't need () anymore since we're already at the last statements Wow, I hadn't realised RebindableSyntax lets you rebind () etc in the middle of a do block. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 7.0.1: x86_64 build failure
On Wed, Nov 17, 2010 at 09:44:59AM +1300, Alexander McPhail wrote: I get the following error when building from 7.0.1 source tarball on linux x86_64: Can you please say exactly how you are building GHC, e.g. what commands you are running, what you have in mk/build.mk (if anything)? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: making 7.01-pre
On Sat, Oct 30, 2010 at 03:43:42PM +0400, Serge D. Mechveliani wrote: Then, making it from source by itself reports /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Irts -DGEN_HASKELL -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o ... ... ... utils/genprimopcode/dist/build/Lexer.o: In function `s2yT_info': (.text+0x1e1d): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' Thanks for the report. Now fixed. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: unused record fields
On Fri, Oct 15, 2010 at 09:04:20PM +0400, Serge D. Mechveliani wrote:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unused value of t2.
Thanks for the report; filed as:
http://hackage.haskell.org/trac/ghc/ticket/4404
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: report on 7.01-pre
On Thu, Sep 30, 2010 at 07:34:25PM +0400, Serge D. Mechveliani wrote: http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc701preBug.zip contains a bug report on ghc-7.0.0.20100924 tested on Debian Linux, i386-family. Thanks. I've boiled it down and filed a ticket here: http://hackage.haskell.org/trac/ghc/ticket/4361 Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Fwd: Re: [Haskell-cafe] Missing documentation in Haskell Platform on Windows
On Thu, Sep 02, 2010 at 09:01:37PM +0200, Daniel Fischer wrote: On Thursday 02 September 2010 20:54:23, Don Stewart wrote: I don't think GHC intends to install utf8-string, does it? (It's an internal package, like those other 2). I think so too, but it shouldn't haddock them then. I've just pushed a patch to stop GHC needlessly haddocking the libraries it's not going to install. If there was another problem too, can someone file a ticket please? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3400: OS X: ghc broken on Snow Leopard
On Sat, Apr 24, 2010 at 06:07:53PM +0100, Malcolm Wallace wrote: Uh-oh. We've started to get comment-spam on the trac. We get it occasionally, and delete it from trac as it comes in. Please don't quote it, as then another copy ends up in the mailing list archives, which in turn get spidered by the search engines etc. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: mkdirhier fails on Ubuntu Hardy i686 with dash shell
On Mon, Oct 19, 2009 at 12:49:44PM -0600, Zooko Wilcox-O'Hearn wrote: Replacing the contents of mkdirhier and mkdirhier.sh with mkdir -p $* works-around the problem. Does anyone know why we don't just call mkdir -p normally? Are there portability problems with it? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in 6.12.1-pre
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 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Inter-module links with Haddock broken?
On Tue, Apr 28, 2009 at 05:52:08PM +0200, David Waern wrote: I'm not sure if we can do Haddock fixes for 6.10.3. Can we? No, you are right. 6.10.3 will have very few changes, to minimise the amount of breakage that can occur. We really don't want to have to do a 6.10.4 :-) Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Hi Sigbjorn, On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. By new build system do you mean http://darcs.haskell.org/ghc-new-build-system/ ? The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. Do you mean that building GHC fails, or that building other things using the built GHC fails? If the latter, can you give a testcase please? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: seg-fault in 6.10.1
On Sat, Jan 24, 2009 at 01:15:40AM +, Simon Peyton-Jones wrote: | Segmentation fault. | | Then, I noted that in a few places the compiler warned about skipping | some class member implementations in some instances. | I added these implementations, and now it works correct. If you aren't using the FFI or unsafe things, you should not get a seg fault. It's possible it's a C stack overflow caused by cyclic default method definitions. But worth checking, anyway. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build difficulties with HEAD
On Sun, Jan 11, 2009 at 09:42:22AM -0800, Conal Elliott wrote: Thanks, Ian. That tweak helped. Now make succeeds, but sudo make install dies, as shown below. - Conal /home/conal/downloads/ghc-6.11.20090109/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg --global-conf /usr/local/lib/ghc-6.11.20090109/package.conf update - --force ghc-pkg: /usr/local/lib/ghc-6.11.20090109/package.conf: openFile: does not exist (No such file or directory) Now fixed. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build difficulties with HEAD
On Sat, Jan 10, 2009 at 11:47:15AM +, Ross Paterson wrote: On Fri, Jan 09, 2009 at 09:33:09PM -0800, Conal Elliott wrote: I was also unable to build from the HEAD darcs repo. after sh boot, and ./ configure, make aborts with installPackage: You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.6.0.1, now Cabal-1.7.0). in build.stage.1. I just had the same problem building the 6.10.1 source distribution on a system with GHC 6.8.2 and Cabal 1.7.0. This happens in ghc-prim. The ghc-prim problem was fixed by: [We need to tell cabal-bin which version of Cabal to use Ian Lynagh ig...@earth.li**20081203123208 Otherwise, if the bootstrapping compiler has a newer version, we get a mismatch between the version used to compile ghc-prim's Setup.hs and the version that installPackage uses. after 6.10.1 was released. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build difficulties with HEAD
On Fri, Jan 09, 2009 at 09:33:09PM -0800, Conal Elliott wrote: I grabbed the snapshot ghc-6.11.20090109, with extra-libs. After ./configure, make aborts with ghc-pkg: /home/conal/downloads/ghc-6.11.20090109/ghc/inplace-datadir/package.conf: openFile: does not exist (No such file or directory), wile registering haddock-2.5.0 . Did I miss something? There is no inplace-datadir there. Is there a fix? I've just pushed a patch to fix this one: hunk ./Makefile 36 -INPLACE_PKG_CONF = $(FPTOOLS_TOP_ABS)/ghc/inplace-datadir/package.conf +INPLACE_PKG_CONF = $(INPLACE_DATA_DIR)/package.conf in utils/haddock. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2012: compiling via-C does not work on ppc
Hi Christian, On Tue, Sep 30, 2008 at 10:07:41AM +0200, Christian Maeder wrote: I don't think we're likely to fix this before -fvia-C is removed in 6.12. The workaround is just to use `-fasm`, of course. I wonder how porting to other platforms will be achieved in the future without going via C. Porting uses the unregisterised via C route, not the -fvia-C evil mangler route. The unregisterised route will still be supported. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.8.3 against DoCon
Hi Serge, On Wed, Jun 18, 2008 at 04:39:57PM +0400, Serge D. Mechveliani wrote: But as ghc-6.8.2 handles DoCon all right, why do not you investigate this difference in 6.8.3 ? We did investigate it - the details are in this trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2328 but the conclusion was that overall it was best to leave things as they are. Unfortunately, this means that performance with GHC 6.8.3 is worse for DoCon; hopefully things will be better with 6.10.1! Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANNOUNCE: GHC 6.8.3 Release Candidate
Hi Serge, On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote: This is a bug report for the ghc candidate of May 27, 2008 for ghc-6.8.3. A short program example for this bug candidate is on http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip Thanks, I've finally tracked this down. The problem is that when you evaluate something like f ^ 10 in 6.8.2 the result was res while in 6.8.3 it is 1 * res I think this is actually a bug in your class instances, but I will try to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 which should, as a side-effect, make it work again. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hs-boot types in 6.8.2
Hi Serge, On Mon, Jan 07, 2008 at 06:56:13PM +0300, Serge D. Mechveliani wrote: In many situations, GHC reports first what namely is the type disagreement between *.hs and *.hs-boot. We can't look for differences between Reduce.hs-boot and Reduce.hs until we have typechecked Reduce.hs, and we can't do that until we have compiled Split.hs. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
Hi Christian, On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote: Judah's framework (2342543 Bytes) http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip should replace (my old one) http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip Done! Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
You can now register a trac user for yourself
Hi all, It is now possible to register a new user account for yourself on the GHC trac. To do so, make sure you are logged out and then click the register link at the top-right, or go to this URL: http://hackage.haskell.org/trac/ghc/register Making your own account preferred over using the guest account, as it means we know who to contact if we have a query about a bug report you make, e.g. if we are unable to reproduce it. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1894: Add a total order on type constructors
On Thu, Nov 15, 2007 at 03:59:46PM -0800, Stefan O'Rear wrote: On Thu, Nov 15, 2007 at 11:52:31PM -, GHC wrote: * cc: sorear (added) * difficulty: = Unknown Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1894#comment:2 Something is going crazy. I know there was one name in the CC before, That name is still there: trac is now cleverer and will report the minimal changes to the CC list rather than telling you the complete old and new lists, so it is telling you that it has added sorear to the list. and I know I didn't modify Difficulty. The guest account isn't allowed to set the difficulty. When you followed up difficulty was set to its default value. (it would be nicer if not allowed to set = set to default value, but sadly that's not how it works). Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug 1711 revisited
Hi Hal, On Tue, Oct 16, 2007 at 09:54:32PM -0700, Hal Perkins wrote: Sorry to revive a dead horse, but there's still a bit of a problem with building ghc on os x because of missing files that need to be created by happy. I downloaded the current stable sources yesterday (ghc-6.8.0.20071015-src.tar.bz2 and ghc-6.8.0.20071015-src- extralibs.tar.bz2) OK, ghc-6.8.0.20071015-src-extralibs.tar.bz2 definitely includes libraries/haskell-src/Language/Haskell/Parser.hs Preprocessing library haskell-src-1.0.1... Setup: happy command not found make[1]: *** [haskell-src/GNUmakefile] Error 1 Does the above file still exist at this point? If so, does cd libraries touch haskell-src/Language/Haskell/Parser.hs make rebuild.library.haskell-src work? If that doesn't do it, what about if you delete haskell-src/Language/Haskell/Parser.y and then try make rebuild.library.haskell-src ? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc for docon-2.10
On Mon, Oct 15, 2007 at 10:10:12PM +0400, Serge D. Mechveliani wrote: Dear GHC developers, please try any appropriate ghc-6.8* candidate for making the public docon-2.10 and running its test module. Looks good to me with 6.8.0.20071016. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.8 fails to make
Hi Serge, On Thu, Sep 13, 2007 at 12:58:03PM +0400, Serge D. Mechveliani wrote: I tried to `make' http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src.tar.bz2 main/InteractiveEval.hs:349:16: parse error on input `Exception.throwIO' Thanks for the report! This has since been fixed. The fix should be in tonight's snapshot. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug: wrong ghc location in package.conf
On Tue, Sep 11, 2007 at 09:52:18PM +0100, Ian Lynagh wrote: On Tue, Sep 11, 2007 at 09:17:32AM +0200, Sven Panne wrote: On Tuesday 11 September 2007 05:58, Conal Elliott wrote: In ghc-6.8 20070909, my package.conf contains some strange and incorrect paths, such as haddockInterfaces = [/usr/local/doc/ghc/libraries\\html\\containers\\containers.haddock], haddockHTMLs = [/usr/local/doc/ghc/libraries\\html\\containers] In fact, the installation location is c:/ghc/ghc-6.8.20070909/, not /usr/local. I do have a failed partial ghc build (from darcs HEAD) at /usr/local from last week. Perhaps there's some sticky info somewhere. [...] There was some confusion regarding build paths vs. installation paths in GHC's build system. I think I've fixed most of this in the last few days, at least I get a nice RPM on Linux now. Could you try to update to the bleeding edge and rebuild? It would be good to have some Windows feedback. I think Conal is using the Windows bindist, which ought to be relocatable but the doc paths weren't. I'm looking into this. Should work in tomorrow's build. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug: wrong ghc location in package.conf
On Tue, Sep 11, 2007 at 09:17:32AM +0200, Sven Panne wrote: On Tuesday 11 September 2007 05:58, Conal Elliott wrote: In ghc-6.8 20070909, my package.conf contains some strange and incorrect paths, such as haddockInterfaces = [/usr/local/doc/ghc/libraries\\html\\containers\\containers.haddock], haddockHTMLs = [/usr/local/doc/ghc/libraries\\html\\containers] In fact, the installation location is c:/ghc/ghc-6.8.20070909/, not /usr/local. I do have a failed partial ghc build (from darcs HEAD) at /usr/local from last week. Perhaps there's some sticky info somewhere. [...] There was some confusion regarding build paths vs. installation paths in GHC's build system. I think I've fixed most of this in the last few days, at least I get a nice RPM on Linux now. Could you try to update to the bleeding edge and rebuild? It would be good to have some Windows feedback. I think Conal is using the Windows bindist, which ought to be relocatable but the doc paths weren't. I'm looking into this. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci :browse! and type of class methods ([GHC] #1617)
On Thu, Sep 06, 2007 at 10:51:05AM +0100, Simon Peyton-Jones wrote: (I'm not sure why -fglasgow-exts switches on forall-printing; that seems odd. I think it's because it turns on things like rank-n types. Is it really what GHC does? We should surely have a flag for that.) -f(no-)print-explicit-foralls controls whether or not they're printed (the flag isn't in GHC 6.7). Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data.HashTable.hashInt seems somewhat sub-optimal
On Wed, Aug 29, 2007 at 08:08:51PM -0400, Jan-Willem Maessen wrote: Recall that we're using the low-order bits of the hash code to index into the table. Aha, I see, thanks. OK, I'll push your patch after validating. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data.HashTable.hashInt seems somewhat sub-optimal
Hi, On Tue, Aug 28, 2007 at 11:41:22AM -0400, Jan-Willem Maessen wrote: golden :: Int32 golden = 1013904242 -- = round ((sqrt 5 - 1) * 2^32) :: Int32 -- was -1640531527 = round ((sqrt 5 - 1) * 2^31) :: Int32 -- but that has bad mulHi properties (even adding 2^32 to get its inverse) -- Whereas the above works well and contains no hash duplications for -- [-32767..65536] hashInt32 :: Int32 - Int32 hashInt32 x = mulHi x golden + x This gives map hashInt [0..16] [0,1,2,3,4,6,7,8,9,11,12,13,14,16,17,18,19] -- (length $ group $ sort $ map hashInt [-32767..65536]) == 65536 + 32768 This test also passes for the golden :: Int32 golden = -1640531527 hashInt :: Int - Int32 hashInt x = fromIntegral x * golden implementation, which has a very pretty distribution; graph at the bottom of http://www.brpreiss.com/books/opus4/html/page214.html hashString :: String - Int32 hashString = foldl' f golden where f m c = fromIntegral (fromEnum c) * magic + hashInt32 m magic = 0xdeadbeef Why use magic rather than golden? This makes sense to me: hashString :: String - Int32 hashString = foldl' f golden where f m c = (fromIntegral (ord c) `xor` m) * golden Is anything obviously wrong with it? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data.HashTable.hashInt seems somewhat sub-optimal
On Mon, Aug 20, 2007 at 02:49:59PM +0100, Simon Marlow wrote: [EMAIL PROTECTED] wrote: I tried submitting this bug through the tracker, but it seemed to give me permissions errors - probably a firewall issue here. :( Apologies. Anyway... Prelude Data.HashTable.hashInt 0 0 Prelude Data.HashTable.hashInt 1 -1 Prelude Data.HashTable.hashInt 2 -1 FYI, this was a bug that has since been fixed. It doesn't look fixed to me. Are you confusing it with http://hackage.haskell.org/trac/ghc/ticket/1137 (poor hashString results)? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: data package
Hi Ian, On Thu, Aug 02, 2007 at 11:10:47AM -0400, Ian Johnston wrote: ghc-6.6.1: unknown package: data I have searched all over for this data package, but I have not found anything. Do you know how I can fix this problem? It sounds like you're trying to compile something very old that uses the data package from hslibs, which is no more. If no later version is available then you'll probably need to update the code to use modern libraries instead. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: crash in ghc.exe while exiting ghci.exe
Hi Gopi, On Thu, Aug 09, 2007 at 05:16:23PM -0700, Gopi Krishna Madabhushi wrote: Here's the crash, probably accessing deleted critical section? Please let me know how can I send more information. Can you please let us know what version of GHC you have, what version of Windows and how to reproduce the crash? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1491: Extension RecordWildCards is broken
On Thu, Jul 05, 2007 at 04:20:59AM -0400, Augustsson, Lennart wrote: But at the moment I can't even download the darcs repo for ghc. That might be a problem at our end that is currupting one of the patches. (We can't download the packed up version of the source tree because .bz2 files seem to be blocked in our firewall.) Are .gz files allowed? I've created http://darcs.haskell.org/ghc-HEAD-2007-07-19-ghc-corelibs-testsuite.tar.gz Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: The Glasgow-haskell-bugs Archives seems to end at April 2007
On Wed, Jul 11, 2007 at 12:34:47PM +0200, Thorkil Naur wrote: On Sunday 08 July 2007 19:59, Ian Lynagh wrote: Hmm, I can't see anything obviously wrong in the settings. I've just re-applied them so let's see if this appears in the archives. It didn't, as far as I can tell ... No, but unfortunately I have no idea what the problem is. If anyone has any ideas then let me know; otherwise I'll try to debug it some time. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1488: Code that won't ever be executed should not give rise to constraints
On Tue, Jul 03, 2007 at 07:57:02PM -0400, Isaac Dupree wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Augustsson wrote: And ghci gives the only sensible answer. Once you start trying to be clever you're on the slippery slope to undecidability. How would one know where to stop? I would be most perturbed if Haskell were to try and ignore unused variables. Since deciding whether a certain variable is used is very easy in this setting(for example CPP macros that expand into if debugging, where debugging will have a constant value. (I don't expect you to solve the Halting Problem). Does this make CPP-usage put you on the slippery slope to undecidability? just a thought... It only would if we tried to type check code with CPP in, rather than type checking it after CPP has been run. Although CPP should be avoided where possible precisely because the typechecker can't check that you haven't made a mistake, e.g. broken the code for a different platform. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -keep-hc-files or -keep-hc-file?
On Thu, Jun 28, 2007 at 03:46:31PM +0200, Christian Maeder wrote: Christian Maeder schrieb: I'm currently confused if it must be plural or singular (or any) http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates shows plural options whereas http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3131928 shows them in singular (except -keep-tmp-files) Well spotted; thanks for reporting it! The plural options work! So flag-reference.html should be corrected. In actual fact the flag reference was exactly right, except the flags could take any argument, which they then ignore (so the ss were being treated as an argument when you gave the flags as plurals). This meant that things like -keep-s-file=no would also result in the .s file being kept, so I've changed the code to accept only -keep-foo (makes sense when using ghc -c) and -keep-foos (makes sense when using ghc --make). -keep-tmp-files is still plural-only. Everything should be consistent now. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1468: :browse should browse currently loaded module
On Fri, Jun 29, 2007 at 12:48:33PM +0200, Josef Svenningsson wrote: to do some tweaking to my user account my id is: josef. I've tweaked your account. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1384: Exporting a module that isn't imported doesn't fail
On Sun, May 27, 2007 at 02:16:15PM -0700, John Meacham wrote:
On Sun, May 27, 2007 at 08:28:25PM -, GHC wrote:
Exporting a module that isn't imported doesn't fail.
An example is, from rnfail028:
{{{
-- !!! illegal to export a module we haven't imported.
module ShouldFail ( module List ) where
}}}
Actually, I don't think this is a bug
The report says, in section 5.2, point 5, last paragraph
It is an error to use module M in an export list unless M is the
module bearing the export list, or M is imported by at least one
import declaration (qualified or unqualified).
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in GHC master Makefile
On Fri, Dec 15, 2006 at 01:26:50PM +, Simon Marlow wrote: Norman Ramsey wrote: 'make uninstall' silently does nothing: I'm not aware of 'make uninstall' ever working, in fact I don't think I've ever tried it. Probably we should just disable it, I'm not sure it's worth the trouble to get it right. Ian, what do you think? Removed, somewhat belatedly! Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1275: ghci debugger is broken in the HEAD
On Sat, Apr 14, 2007 at 05:36:57PM -, GHC wrote: #1275: ghci debugger is broken in the HEAD Thanks, we are aware of this, we believe it is related to Wolfgang' patches changing the symbol names of datacons. But Bernie will be out for the next two weeks or so, and I haven't looked at his code for datacon recovery yet. I might give a look anyway, with an eye open for an easy fix. It's not particularly urgent; I was just sorting out the testsuite unexpected failures and it's nice to be able to point at a bug when marking a test as expected to be broken, so that when you come back to it in a couple of months time you know what's going on. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1210: Unimplemented opcode error while running ZFS
On Wed, Mar 14, 2007 at 09:42:36AM +, Pasqualino 'Titto' Assini wrote: are you sure that this is the same bug? Bug 1013 appears to have been fixed in GHC 6.6. while this bug is still present in 6.6. 1013 has been fixed in the 6.6 branch (so 6.6.1 will be fixed), but 6.6 itself is broken. I can't reproduce the ZFS bug here, so I can't confirm the branch fixes it. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: question about expected and inferred types in error messages
On Sun, Mar 11, 2007 at 08:43:51PM +, Frederik Eaton wrote: I am looking at version 6.6. (is there a newer one in Debian?) (no) Thanks for the bug report and testcase; I've filed a trac bug for it: http://hackage.haskell.org/trac/ghc/ticket/1221 I hope that this isn't again something which has been fixed recently, Nope: still broken in the HEAD and 6.6 branch. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: no location info when module name is omitted
On Tue, Feb 27, 2007 at 06:55:03PM +, Frederik Eaton wrote: If I try to compile a program which depends on a file which omits the module X where line, then I get an error message from ghc: no location info: file name does not match module name `Main' This is not very helpful, since it doesn't tell me which file the error is in, or what the error is. This is already fixed in the 6.6 branch and the HEAD, and thus should work in 6.6.1 and 6.8. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Compiler bug
Hi Paul,
On Sun, Jan 28, 2007 at 12:49:44PM +0300, Paul wrote:
Chasing modules from: hask1.hs
Compiling Main ( hask1.hs, hask1.o )
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
ds_app_type Main.Tree{tc r16z} [a{tv a1a9}]
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Thanks for the report. I think the problem is fixed in newer versions of
GHC (I've tried 6.4.2 and 6.6), which give the error
hask1.hs:24:1:
Class `Tree' used as a type
In the class declaration for `Tree'
when using data Node ... and
Multiple declarations of `Main.Tree'
Declared at: hask1.hs:12:5
hask1.hs:14:6
when using data Tree
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #985: Memory Leak in freeHaskellFunPtr
On Sat, Feb 03, 2007 at 01:04:41PM +0100, Sven Panne wrote:
Am Donnerstag, 1. Februar 2007 14:56 schrieb GHC:
Fixed. Patch to merge (from 6.6 to HEAD):
{{{
Thu Feb 1 13:53:33 GMT 2007 Simon Marlow [EMAIL PROTECTED]
* fix memory leak in allocExec/freeExec (see bug #985)
}}}
Hmmm, I think I haven't seen this patch in the HEAD yet.
I haven't seen it anywhere; I think Simon forgot to push it (either that
or I'm just being dopier than normal).
Is there an automatic way to see which patches
should still be merged into which direction?
The http://cvs.haskell.org/trac/ghc/wiki/6.6_Branch page describes how
to check that there are no patches in 6.6 only that should be in the
HEAD (although I haven't been actively keeping the list of exceptions
up-to-date; I think it'll be easier to do a bulk update when checking
that the HEAD is not missing anything, as there shouldn't be many new
patches missing from the head, and most of them should be called
MERGED.*).
For patches in the HEAD that should be in 6.6, the number of exceptions
would make the same system impractical. To make sure a patch doesn't get
missed, open a trac ticket of type merge and put the patch name in it.
(Noting that it should be merged in the patch description or sending an
e-mail to ask for it to be merged are also OK, but obviously if I miss
them then there is no easy way of noticing).
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: profiling option issues
On Mon, Jan 15, 2007 at 03:20:02PM +, Frederik Eaton wrote: /tmp/ghc4721_0/ghc4721_0.s:4185:0: Error: symbol `Mainmain_CAF_cc_ccs' is already defined = '-auto-all' and '-caf-all' can't be used together? Actually, sorry, I get the same error when I just use -caf-all by itself... Thanks for the report; this is a long-standing bug, I'm afraid: http://hackage.haskell.org/trac/ghc/ticket/249 Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: test case for -xc incompleteness
On Mon, Jan 15, 2007 at 03:43:47PM +, Frederik Eaton wrote: Here is a test case showing poor results with '+RTS -xc'. Excellent, thanks! The program dies with error message: Wrappers.unsingleton,Main.CAFsparse-test: Wrappers.hs:218:4-9: Assertion failed Clearly, the 'stack trace' is incomplete, since Wrappers is not imported directly by the main module (so I think there should be a few intervening levels as well). This sounds like it could be the same problem as http://hackage.haskell.org/trac/ghc/ticket/948 I've added your instructions to the bug log so we can check that your case is also fixed when the bug is looked at. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.6 under sparc-sun-solaris
On Fri, Jan 26, 2007 at 01:23:05PM +0100, Christian Maeder wrote: Christian Maeder schrieb: http://www.haskell.org/ghc/download_ghc_66.html#sparcsolaris Ian, could you remove the out-dated first line from this page? cite NOTE: you must use GCC 2.95 or 3.4+ on Sparc. There is a known bug with GCC versions between 3.0-3.3 which causes incorrect code to be generated. /cite And add that also libm.so.2 is needed. Done. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.6 under sparc-sun-solaris
On Thu, Jan 25, 2007 at 02:35:50PM +0100, Winfried Kung wrote: == make all -wr -f Makefile; in /global/HOME/kung/install/ghc-6.6/libraries/base ../../compiler/ghc-inplace -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc -H16m -O -H16m -O -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base-2.0 -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /usr/ccs/bin/ld: illegal option -- x usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) [-64] enforce a 64-bit link-edit ... ... [-z verbose]generate warnings for suspicious processings collect2: ld returned 1 exit status It seems strange to me that /usr/ccs/bin/ld is called here, instead of /usr/local/bin/ld which I have in my path, but calling ghc-inplace with option -pgml /usr/local/bin/ld did not help either. Does anyone have a suggestion? Can you show the output of the above command with the following extra arguments please?: -v -pgml /usr/local/bin/ld Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Fix ghc-6.6 darcs-all for Mac OS X 10.4
On Thu, Nov 23, 2006 at 02:31:16PM +0100, Thorkil Naur wrote: The following patch fixes ghc-6.6 darcs-all for Mac OS X 10.4. Applied, thanks! Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] help with threadDelay
[moving to glasgow-haskell-bugs] On Wed, Nov 15, 2006 at 11:40:12PM +, Neil Davies wrote: however when -threaded is used you get some interesting effects, including returning too early: Tgt/Actual = 0.000125/0.34s, diff = -0.91s Thanks for the report; I can reproduce it on Linux/amd64. OK, so the bug here is that threadDelay n might return after less than n microseconds. This looks like it's caused by truncation problems when converting times to ticks (where a tick is 1/50 of a second), e.g. while trying to sleep for 1.953125s one run started at 1164157960.773726s which is (Int) 1164157960 * 50 + 773726 * 50 / 100 = (Int) 58207898038.6863 = 58207898038 ticks and woke the thread up at 1164157962.708609s which is (Int) 1164157962 * 50 + 708609 * 50 / 100 = (Int) 58207898135.4305 = 58207898135 ticks The difference is 58207898135 - 58207898038 = 97 ticks. Meanwhile we're trying to sleep for (Int) 50 * 1.953125 = (Int) 97.65625 = 97 ticks However, 1164157962.708609s - 1164157960.773726s = 1.93488311767578s which is 0.0182418823242201s too short. The problem is that we have counted 0.6863 ticks before the start time, not counted 0.4305 ticks before the finish time and have been waiting 0.65625 ticks too short a time. Thus we have counted (0.6863-0.4305 + 0.65625) / 50 == 0.018241 too much time. I think the answer is that let target = now + usecs `quot` tick_usecs in GHC/Conc.lhs should be let target = 1 + now + (usecs + tick_usecs - 1) `quot` tick_usecs I'm also a bit dubious about the use of the constant 50 for the number of ticks per second, but the results with +RTS -V0.001 don't look any more wrong so perhaps I just need to get some sleep. You can get the same symptoms with the non-threaded RTS with +RTS -V0.001, although they are less frequent. I suspect we need a similar fix to target = (R1 / (TO_W_(RtsFlags_MiscFlags_tickInterval(RtsFlags))*1000)) + time; in delayzh_fast in PrimOps.cmm. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Thu, Sep 28, 2006 at 09:07:33AM +0200, Tomasz Zielonka wrote: On Thu, Sep 28, 2006 at 01:57:18AM +0100, Ian Lynagh wrote: I've found a machine which had the same problem. I think I've fixed it with Thu Sep 28 00:46:30 BST 2006 Ian Lynagh [EMAIL PROTECTED] * Handle clock_gettime failing Great! Which snapshot can I use to test this change? Tonight's or later - there isn't one yet. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Thu, Sep 21, 2006 at 08:03:53PM +0200, Tomasz Zielonka wrote: Hello! I am getting nonsensical execution statistics (+RTS -Sstderr) when running programs in SMP mode (+RTS -N2). I've found a machine which had the same problem. I think I've fixed it with Thu Sep 28 00:46:30 BST 2006 Ian Lynagh [EMAIL PROTECTED] * Handle clock_gettime failing Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
Hi Tomasz, On Thu, Sep 21, 2006 at 08:03:53PM +0200, Tomasz Zielonka wrote: I am getting nonsensical execution statistics (+RTS -Sstderr) when running programs in SMP mode (+RTS -N2). Example: Task 0 (worker) : MUT time: 401572821.14s ( 21.89s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 3 (worker) : MUT time: 401583421.14s ( 21.91s elapsed) GC time: 0.00s ( 0.00s elapsed) I am using ghc-6.5.20060919-i386-unknown-linux.tar.bz2 on Intel(R) Pentium(R) D CPU 3.20GHz (dual core) with kernel 2.6.16-2-686-smp (Debian 2.6.16-17). I couldn't reproduce this with a simple program that forked off 4 threads to do computation on a single CPU machine, and neither could someone on IRC with head from Sep 15 on a Core Duo. Is it possible to send us a small example program along with exactly what flags you used to compile and run it please? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
On Wed, Sep 13, 2006 at 12:23:27PM -0500, Brian Smith wrote: I finished re-running the test suite with all the necessary libraries installed. Cool, thanks! * utf8_002, utf8_003, utf8_004, utf8_005: These tests all fail the same way, outputing: utf8_002.hs:2:0: lexical error at end of input instead of: utf8_002.hs:2:0: lexical error (UTF-8 decoding error) This is just due to different alex's giving different errors. * conc023(ghci) This test only fails when run via GHCi. This test runs out of memory. The error message to stderr is: conc023: failed to create OS thread: Not enough storage is available to process this command. When I came back to the computer I saw that Windows was warning me that I was out of virtual memory and that it was increasing my page file size. I have 1GB of RAM which I think should be sufficient to run the testsuite successfully. Does that happen repeatably? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #875: assert fails on HEAD
On Wed, Aug 23, 2006 at 11:55:06PM -, GHC wrote: [EMAIL PROTECTED] should_run]$ cat dsrun014.hs module Main where import Control.Exception ( assert ) main = assert Hello True $ print World [EMAIL PROTECTED] should_run]$ $GHC66 dsrun014.hs dsrun014.hs:5:7: Couldn't match expected type `GHC.Prim.Addr#' against inferred type `[Char]' In the first argument of `GHC.Err.assertError', namely `dsrun014.hs:5:7-12' In the call (GHC.Err.assertError dsrun014.hs:5:7-12 Hello True) In the first argument of `($)', namely `GHC.Err.assertError dsrun014.hs:5:7-12 Hello True' I think hunk ./compiler/rename/RnExpr.lhs 974 + +srcSpanPrimLit :: SrcSpan - HsExpr Name +srcSpanPrimLit span = HsLit (HsStringPrim (mkFastString (showSDoc (ppr span hunk ./compiler/rename/RnExpr.lhs 992 -(L sloc (srcSpanLit sloc)) +(L sloc (srcSpanPrimLit sloc)) should fix this, but I haven't been able to test it yet. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
The make problem
Hi, It looks like the make problem is not going to be fixed in the next release of make (and the current release only works because of a bug): https://savannah.gnu.org/bugs/?func=detailitemitem_id=15584 I'm afraid I haven't followed carefully enough to know what the problem is exactly, or how to fix it. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Space leak
Hi, When compiling with ghc 6.4.1 -O, and with randomLines exported, this program leaks memory (possibly because we get a randomRs CAF sitting waiting for a generator hanging around in memory, but I'm not sure). It looks fixed in the CVS snapshot I have, but I thought I'd report it anyway in case either it isn't fixed in the STABLE branch, or there is still a problem lurking but this case doesn't trigger it any more. Originally reported here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350443 Thanks Ian module Main (main, randomLines) where import System.Random (StdGen, getStdGen, split, randomRs) import Data.Char (chr) randomLines :: StdGen - [String] randomLines g = splits splitPoints toSplit where toSplit = map (chr . (65 +)) $ randomRs (0, 9) g1 splitPoints = randomRs (30, 50) g2 (g1, g2)= split g splits :: [Int] - String - [String] splits (s:ss) xs = case splitAt s xs of (ys, zs) - ys:splits ss zs splits [] _ = [] main :: IO () main = do g - getStdGen mapM_ putStr $ take 60 $ randomLines g ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Sparc/Linux bitrotted
Hi all, Just to let you know it looks like Sparc/Linux has bitrotted: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341797 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342227 I assume this is a mangler problem, so I'll probably just switch to building it unregisterised. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Erroneous warning with n+k patterns
Hi all, This function: g :: Int - Int g (x+1) = 1 g _ = 0 (erroneously) gives this warning: Warning: Pattern match(es) are overlapped In the definition of `g': g _ = ... I'm not sure if this is covered by the first item on http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html but if so (well, probably even if not; I've grown quite attached to -Wall -Werror) then I'd like to add my voice to those who would like to see the mentioned overhaul done. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Compilation error with -prof
On Thu, Aug 18, 2005 at 05:28:37PM +0200, Jan Christiansen wrote: If I add the -prof option to the call of ghc I get a compilation error like Could not find module `System.Environment': use -v to see a list of the files searched for (imported from Prof.hs) although the compilation is successful without the option. ghc version is 6.4 You probably need to install a package like ghc6-prof with the profiling versions of the standard libraries. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Fwd: [Bug#319086: -help output goes to stderr] [EMAIL PROTECTED]
I've also found this annoying in the past, but never quite enough so to get around to e-mailing about it :-) Thanks Ian ---BeginMessage--- Package: ghc6 Version: 6.4-4 Severity: minor It's a little annoying that ghc6 sends its (voluminous) --help output to stderr, thus requiring extra redirections to get it into a pager. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | You mean, you'll drop your rock and | | I'll drop my sword and we'll just try to | | kill one another like civilized people? | | -- The Princess Bride | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ ---End Message--- ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Recompiling doesn't notice re-exports being removed
Recompiling doesn't notice re-exports being removed: $ cat A.hs module A where foo :: Int foo = 4 $ cat B.hs module B (foo) where import A (foo) $ cat C.hs module Main (main) where import B (foo) main :: IO () main = print foo $ ghc --make C -o c Chasing modules from: C Compiling A( ./A.hs, ./A.o ) Compiling B( ./B.hs, ./B.o ) Compiling Main ( C.hs, C.o ) Linking ... $ sed -i s/foo// B.hs $ cat B.hs module B () where import A () $ ghc --make C -o c Chasing modules from: C Skipping A( ./A.hs, ./A.o ) Compiling B( ./B.hs, ./B.o ) Skipping Main ( C.hs, C.o ) Linking ... $ # compilation above should have failed, as below $ rm *.o *.hi c $ ghc --make C -o c Chasing modules from: C Compiling A( ./A.hs, ./A.o ) Compiling B( ./B.hs, ./B.o ) Compiling Main ( C.hs, C.o ) C.hs:4:10: Module `B' does not export `foo' $ Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc's hPutBuf doesn't obey the buffering mode
If I run this program: -- import System.Cmd (system) import Foreign.C.String (castCharToCChar) import Foreign.Marshal.Array (newArray) import System.IO (hSetBinaryMode, hPutBuf, stdout, hSetBuffering, BufferMode(..)) main = do hSetBinaryMode stdout True hSetBuffering stdout LineBuffering p - newArray (map castCharToCChar foo\n) hPutBuf stdout p 4 system sleep 5 putStr bar\n -- compiled by GHC then it waits 5 seconds and then prints foo and bar together. With hugs, foo is printed and then 5 seconds later bar is printed, as I would expect. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: calling MacOS X experts
On Fri, Mar 04, 2005 at 04:37:27PM +, Malcolm Wallace wrote: I am having problems with getting nhc98 to work under Mac OS 10.3.x. It builds just fine with ghc (6.2.2), and appears to compile programs just fine, but the resulting executables sometimes crash with Bus Error. (make test gives 55 runtime failures + 55 successes, out of 110 tests.) The evidence is that there is some incompatibility between Apple's latest gcc (3.3) and nhc98, because if I set the configuration to use gcc2 (2.95.2) instead, there are no failures and all 110 tests succeed. FWIW I also had problems on powerpc Linux (Debian). IME compiling with ghc rather than gcc tends to have a better chance of succeeding, but if compiling with gcc wouldn't have succeeded then the ghc-compiled nhc98 doesn't work properly either. Compiling with gcc 3 I got a segfault compiling DErrNo.hs: http://buildd.debian.org/fetch.php?pkg=nhc98ver=1.16-12arch=powerpcstamp=1099697591file=logas=raw For now I just use gcc-2.95 on powerpc. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: happy documentation fails to build
On Mon, Jan 31, 2005 at 08:39:50PM +0100, Sven Panne wrote: that my PostScript is generated via fop (version 0.20.5) and Ian's via the PassiveTeX route. I have seen varying versions of DocBook + PassiveTeX breaking in various wonderful arcane ways in the past, so I recommend installing fop. The configure process will prefer fop if it finds it, just for that reason, BTW. fop is not an option for me(Debian) as it apparently requires non-free Java stuff. The xmltex bug looks well-known (e.g. Debian bugs #170477, #181444, #184072, #184086, #234884), and the reports point out that running pdfxmltex happy.fo; pdftops happy.pdf works (although the output doesn't look /quite/ right, e.g. - -4pc - -4pc appears at the top of each page). Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
happy documentation fails to build
Hi all, The happy 1.15 documentation fails to build for me. The interesting looking bits of the build log are: [...] checking for xmllint... /usr/bin/xmllint checking for DocBook DTD... ok checking for xsltproc... /usr/bin/xsltproc checking for DocBook XSL stylesheet directory... /usr/share/xml/docbook/stylesheet/nwalsh checking for fop... no checking for fop.sh... no checking for xmltex... /usr/bin/xmltex checking for dvips... /usr/bin/dvips [...] /usr/bin/make -C happy/doc ps html make[1]: Entering directory `/home/igloo/happy/new/happy-1.15/happy/doc' /usr/bin/xsltproc --output happy.fo \ --stringparam toc.section.depth 3 --stringparam section.autolabel 1 --stringparam section.label.includes.component.label 1 \ /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl happy.xml Making portrait pages on USletter paper (8.5inx11in) /usr/bin/xmltex happy.fo This is TeX, Version 3.14159 (Web2C 7.4.5) [...] ! LaTeX Error: Something's wrong--perhaps a missing \item. See the LaTeX manual or LaTeX Companion for explanation. Type H return for immediate help. ... l.31 ...o:block1./fo:block/fo:list-item-label fo:list-item-body start-i... ? Output written on happy.dvi (5 pages, 97888 bytes). Transcript written on happy.log. make[1]: *** [happy.dvi] Error 1 make[1]: *** Deleting file `happy.dvi' make[1]: Leaving directory `/home/igloo/happy/new/happy-1.15/happy/doc' make: *** [build-stamp] Error 2 If I reformat it a bit then the error is in this bit of happy.fo: fo:list-block id=id2529507 space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2em space-after.optimum=1em space-after.minimum=0.8em space-after.maximum=1.2em provisional-label-separation=0.2em provisional-distance-between-starts=2em fo:list-item id=item-default-backend space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2em fo:list-item-label end-indent=label-end() fo:block1./fo:block !-- foo --/fo:list-item-label fo:list-item-body start-indent=body-start() fo:block fo:block`standard' Haskell 98 (should work with any compiler that compiles Haskell 98)./fo:block /fo:block /fo:list-item-body /fo:list-item and now looks like this: ! LaTeX Error: Something's wrong--perhaps a missing \item. See the LaTeX manual or LaTeX Companion for explanation. Type H return for immediate help. ... l.1801 !-- foo --/fo:list-item-label Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.2.1 and FedoraCore2: ar-related build problem, looked like readline problem
On Fri, Sep 03, 2004 at 07:34:42PM +0200, Sven Panne wrote: Henrik Nilsson wrote: [...] So, in summary, there were two problems: * The configuration tools somehow thinks the system's ar supports -input. Hmmm, it should have been detected by configure that this is not the case for your platform. Could you please send a log of the configuration step and the resulting config.log? I think you've already fixed this in CVS: http://www.haskell.org/pipermail/cvs-ghc/2004-April/020585.html I haven't looked to see if the fix was merged to the stable branch or not, though. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: charToUtf8 1883885648 panic on sparc
On Thu, Jun 17, 2004 at 10:01:06AM +0100, Simon Marlow wrote: After recent testing, this bug goes away when gcc-2.95 is used, so I claim it is a bug in the gcc version being used (3.3.2-debian). GCC versions prior to 3.3.3 are known to have problems with register variables. Hmm, I was told the bug was fixed in the version I was using, although it could have been a different bug. Sorry for the wasted time :-( Anyway, the good news is everything looks rosy with 3.3.4 :-) Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc IA64 Linux unaligned accesses
Hi guys,
I thought the unaligned accesses I had with GHC on IA64 had magically
gone away when I compiled with a more recent GHC and gcc, but it turns
out they were still happening on another machine. When I tried to
compile a debugging RTS on the first machine to debug on the second
with, I found the newly compiled GHC was again giving unaligned accesses
on the first machine.
This is GHC 6.2.1, gcc version 3.3.4 (Debian). I've stuck a load of
debugging info below; if there's anything else you need please ask.
Thanks
Ian
$ ../ghc6-6.2.1/ghc/compiler/stage2/ghc-inplace -O Foo.hs -o foo +RTS
-D{s,i,c,w,G,g,b,S,t,p,r,P,l} 2 out
ghc-6.2.1(28878): unaligned access to 0x4201c80f, ip=0x409dafd1
$
out is at
http://merulo.debian.org/~igloo/out
or
http://merulo.debian.org/~igloo/out.gz
--88--
$ prctl --unaligned=signal gdb
/home/igloo/debug_rts/ghc6-6.2.1/ghc/compiler/stage2/ghc-6.2.1
[...]
(gdb) run -B/home/igloo/debug_rts/ghc6-6.2.1 -O Foo.hs -o foo
Starting program: /home/igloo/debug_rts/ghc6-6.2.1/ghc/compiler/stage2/ghc-6.2.1
-B/home/igloo/debug_rts/ghc6-6.2.1 -O Foo.hs -o foo
stg_fun_gc_gen(ARG_GEN)stg_gc_fun_ret(ARG_GEN)
[previous line repeated lots]
Program received signal SIGBUS, Bus error.
0x409dafd1 in s3RF_1_alt ()
(gdb) bt
#0 0x409dafd1 in s3RF_1_alt ()
#1 0x409dab10 in s2ON_entry ()
#2 0x in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb) disassemble
Dump of assembler code for function s3RF_1_alt:
0x409daf30 s3RF_1_alt+0: [MMI] mov r63=r1;;
0x409daf31 s3RF_1_alt+1: adds r59=16,r59
0x409daf32 s3RF_1_alt+2: nop.i 0x0;;
0x409daf40 s3RF_1_alt+16: [MFB] cmp.ltu p7,p6=r60,r59
0x409daf41 s3RF_1_alt+17: nop.f 0x0
0x409daf42 s3RF_1_alt+18: (p06) br.cond.dptk.few
0x409dafb0 s3RF_1_alt+128
0x409daf50 s3RF_1_alt+32: [MMI] addl r15=7704,r1;;
0x409daf51 s3RF_1_alt+33: ld8 r14=[r15]
0x409daf52 s3RF_1_alt+34: nop.i 0x0;;
0x409daf60 s3RF_1_alt+48: [MMI] adds r14=16,r14;;
0x409daf61 s3RF_1_alt+49: adds r14=176,r14
0x409daf62 s3RF_1_alt+50: mov r15=2;;
0x409daf70 s3RF_1_alt+64: [MFI] st8 [r14]=r15
0x409daf71 s3RF_1_alt+65: nop.f 0x0
0x409daf72 s3RF_1_alt+66: addl r16=7704,r1;;
0x409daf80 s3RF_1_alt+80: [MMI] ld8 r14=[r16];;
0x409daf81 s3RF_1_alt+81: ld8 r14=[r14]
0x409daf82 s3RF_1_alt+82: nop.i 0x0;;
0x409daf90 s3RF_1_alt+96: [MMI] ld8 r15=[r14],8;;
0x409daf91 s3RF_1_alt+97: nop.m 0x0
0x409daf92 s3RF_1_alt+98: mov b6=r15
0x409dafa0 s3RF_1_alt+112:[MFB] ld8 r1=[r14]
0x409dafa1 s3RF_1_alt+113:nop.f 0x0
0x409dafa2 s3RF_1_alt+114:br.few b6;;
0x409dafb0 s3RF_1_alt+128:[MFI] adds r15=-8,r59
0x409dafb1 s3RF_1_alt+129:nop.f 0x0
0x409dafb2 s3RF_1_alt+130:addl r16=10992,r1;;
0x409dafc0 s3RF_1_alt+144:[MMI] ld8 r14=[r16];;
0x409dafc1 s3RF_1_alt+145:st8 [r15]=r14
0x409dafc2 s3RF_1_alt+146:addl r14=283768,r1;;
0x409dafd0 s3RF_1_alt+160:[MMI] ld8 r14=[r14];;
0x409dafd1 s3RF_1_alt+161:ldfs f6=[r14]
0x409dafd2 s3RF_1_alt+162:adds r14=16,r12;;
0x409dafe0 s3RF_1_alt+176:[MMB] stfs [r14]=f6
0x409dafe1 s3RF_1_alt+177:ldfs f6=[r14]
0x409dafe2 s3RF_1_alt+178:nop.b 0x0;;
0x409daff0 s3RF_1_alt+192:[MII] stfs [r59]=f6
0x409daff1 s3RF_1_alt+193:adds r48=-8,r59
0x409daff2 s3RF_1_alt+194:adds r56=8,r56
0x409db000 s3RF_1_alt+208:[MMI] addl r16=4976,r1;;
0x409db001 s3RF_1_alt+209:ld8 r14=[r16]
0x409db002 s3RF_1_alt+210:nop.i 0x0;;
0x409db010 s3RF_1_alt+224:[MMI] ld8 r14=[r14];;
0x409db011 s3RF_1_alt+225:ld8 r15=[r14],8
0x409db012 s3RF_1_alt+226:nop.i 0x0;;
0x409db020 s3RF_1_alt+240:[MFI] nop.m 0x0
0x409db021 s3RF_1_alt+241:nop.f 0x0
0x409db022 s3RF_1_alt+242:mov b6=r15
0x409db030 s3RF_1_alt+256:[MFB] ld8 r1=[r14]
0x409db031 s3RF_1_alt+257:nop.f 0x0
0x409db032 s3RF_1_alt+258:br.few b6;;
End of assembler dump.
(gdb) info registers
r0 0x0 0
r1 0x600a8c60 6917529027641773152
charToUtf8 1883885648 panic on sparc
Hi all,
On sparc, GHC is failing when building hmake as below:
-
/usr/bin/haskell-compiler-package lang -c -o
/build/buildd/hmake-3.08/targets/sparc-Linux/obj/hmake/QSort.o QSort.hs
/usr/bin/haskell-compiler-package lang -c -o
/build/buildd/hmake-3.08/targets/sparc-Linux/obj/hmake/Unlit.o Unlit.hs
ghc-6.2.1: panic! (the `impossible' happened, GHC version 6.2.1):
charToUtf8 1883885648
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
-
ghc-package lang -c Unlit.hs -v9 2 /dev/null ends like this in
the Desugar section:
lit_aWG :: GHC.Base.Int
lit_aWG = lit_aVV
classify :: GHC.Base.Int - [GHC.Base.String] - [Unlit.Classified]
classify = \ ds_dYb :: GHC.Base.Int ds_dY9 :: [GHC.Base.String] -
let {
fail_dYk :: [Unlit.Classified]
fail_dYk = GHC.Err.patError
(no final newline) whereas on x86 it continues:
lit_aWG :: GHC.Base.Int
lit_aWG = lit_aVV
classify :: GHC.Base.Int - [GHC.Base.String] - [Unlit.Classified]
classify = \ ds_dYb :: GHC.Base.Int ds_dY9 :: [GHC.Base.String] -
let {
fail_dYk :: [Unlit.Classified]
fail_dYk = GHC.Err.patError
@ [Unlit.Classified] Unlit.hs:22|function classify } in
let {
fail_d102 :: [Unlit.Classified]
fail_d102 = let {
fail_dYs :: [Unlit.Classified]
fail_dYs = case ds_dY9 of wild_B1 {
I would guess this is a problem where an 8-bit character is converted to
a unicode character without the high bits being zeroed somewhere?
I've put a copy of Unlit.hs at http://urchin.earth.li/~ian/Unlit.hs
and the sparc output at http://urchin.earth.li/~ian/Unlit.sparc_out
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: PATCH: implementation for TH PprLib.hs punctuate function
On Tue, Mar 02, 2004 at 07:02:18PM +, Duncan Coutts wrote: I noticed that the 6.3 version of the PprLib.hs is not fully implemented so pretty printing some things calls Prelude.undefined. Thanks - looks like something I forgot to go back to. Attached patch typechecks but I've not rebuilt yet so I've not tested it I've just used the punctuate text from Text.PrettyPrint.HughesPJ (but with refering to the monadic one now). Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
\s at the end of lines and cpp
Hi guys, Presumably as one of the gcc 3.3 changes, cpp now treats all '\'s at the end of a line as a line continuation character (at least I imagine that's what is happening, but it doesn't seem to be actually eating a '\n'). This means that when Helium says infixl 9 \\ in ../../lvm/src/lib/common/Set.hs, which is compiled with -cpp, ghc says ../../lvm/src/lib/common/Set.hs:137: parse error on input `\' as it is seeing infixl 9 \ Adding a ';' to the end of the line is one way to fix this. I'm not sure if the GHC guys consider this a bug; it could possibly be worked around by protecting trailing '\'s (just appending a space is sufficient) on lines cpp shouldn't be looking at, but for macro calling lines that might not be possible. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
biographical profiling bug
In a fairly recent CVS (I don't have 5.04* easily available to check it): igloo@userpc15:bug$ ghc --make Foo -o Foo -prof -auto-all -O Chasing modules from: Foo Compiling Inflate ( Inflate.lhs, ./Inflate.o ) Compiling Main ( Foo.lhs, ./Foo.o ) Linking ... igloo@userpc15:bug$ ./Foo +RTS -hb Foo: internal error: Invalid object in processHeapClosureForDead(): 17260 Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ igloo@userpc15:bug$ Source at http://urchin.earth.li/~ian/bug.tar.gz Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Confused by FFI
On Mon, Jul 08, 2002 at 10:19:20PM +0100, Alastair Reid wrote: For what it's worth, I ran Ian's program on Hugs (with minor changes: Hugs gets confused by the use of type synonyms in ffi decls) Is this a hugs bug or am I being non-portable? I'd class it as a reflection of the immaturity of Hugs' new ffi implementation - but others might reasonably call it a Hugs bug :-) Sorry if my language was too strong, I just wanted to check I was working within the FFI spec. For them that care, the problems in Hugs are: [snip] Thanks. I reached this point having discovered that the Haskell equivalent of keypad(stdscr, TRUE) (insert digression/rant about having to assume bool is a numerical type in curses here) had no effect but using the result of initscr worked fine. I presume the rant would be to the effect that it's painful that the ffi doesn't handle macros such as TRUE or perhaps the plausible but not always correct use of 0/1 to marshall False/True? It was more directed at the lack of assumptions curses allows you to make than the Haskell side, but even so the answer is not really. The short answer is that GreenCard and friends exist for that very purpose. I'm currently using hsc2hs and have code like this: type NBool = #type bool cTRUE :: NBool cTRUE = #const TRUE The problem comes when bool is, say, a 72bit structure and #type can't provide a suitable Haskell type. I'm happy to be corrected on this, particularly if it makes my life easier :-) I'll have a better look at GreenCard (I think I decided it was more complex than hsc2hs for what I was doing at the time, but I might need the extra complexity now) some time and see if it can help me out. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: global random number generator initialisation
On Fri, Jul 05, 2002 at 07:11:11AM -0700, Sigbjorn Finne wrote: You don't say, but I'm assuming you're using a recent'ish GHC snapshot. Yes, sorry. A wibble that prevented the system/standard RNG from being seeded with a time-varying value was fixed sometime last week, so 5.04 will have it included. Cool, thanks. Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: incorrect parsing
On Thu, Jan 03, 2002 at 05:10:56PM +, Malcolm Wallace wrote: This program: module Main where f = map (++a++b) g = map (a++b++) main = do print (f [x,y,z]) print (g [x,y,z]) gives the following error messages with ghc (versions 4.08.2 and 5.02): plusplus.hs:3: The operator `++' [infixr 5] of a section must have lower precedence than the operand `++' [infixr 5] In the section: `(++ (a ++ b))' I believe this is the wrong behaviour - the first (right) section is perfectly valid Haskell'98 because the operator is right associative. Hugs, hbc, and nhc98 all accept it. Check also section 3.5 (p.17) of the Report. The context free grammar in appendix B (and at the start of section 3) defines right sections as ( qop(a,i) expi+1 ) which contradicts 3.5. The additional production to ( qop(r,i) rexpi ) could be added, and similarly for left sections. The brackets added to the error would make the section valid anyway which should perhaps be fixed regardless. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Failed to find interface decl for `Offside.a1' with -O2
Hi guys, I'm afraid I haven't got a simple test case for this one. ghc is giving me the error Failed to find interface decl for `Offside.a1' in a rather large program. I have shown how to reproduce the problem below (indenting the output). The code, compiled as shown below, is at http://c93.keble.ox.ac.uk/~ian/igl-0.0.8-b1.tar.gz $ hmake -ghc Project -package lang -O2 ghc -package lang -O2 -c -o Tokens.o Tokens.lhs ghc -package lang -O2 -c -o Tree.o Tree.lhs ghc -package lang -O2 -c -o Subject.o Subject.lhs ghc -package lang -O2 -c -o PPTeX.o PPTeX.lhs ghc -package lang -O2 -c -o Position.o Position.lhs ghc -package lang -O2 -c -o Either.o Either.lhs ghc -package lang -O2 -c -o PCbase.o PCbase.lhs ghc -package lang -O2 -c -o PC.o PC.lhs ghc -package lang -O2 -c -o Parser.o Parser.lhs ghc -package lang -O2 -c -o Mangle.o Mangle.lhs ghc -package lang -O2 -c -o Sort.o Sort.lhs ghc -package lang -O2 -c -o FiniteMap.o FiniteMap.lhs ghc -package lang -O2 -c -o IA.o IA.lhs ghc -package lang -O2 -c -o Offside.o Offside.lhs Offside.lhs:116: Warning: Pattern match(es) are overlapped In the definition of `step': step _ pos [] _ = ... ghc -package lang -O2 -c -o Scanner.o Scanner.lhs ghc -package lang -O2 -c -o Args.o Args.lhs ghc -package lang -O2 -c -o Project.o Project.lhs Project.lhs:4: Failed to find interface decl for `Offside.a1' from module `Offside' Project.lhs:4: Failed to find interface decl for `Offside.a3' from module `Offside' $ ghc -package lang -O -c -o Project.o Project.lhs Project.lhs:4: Failed to find interface decl for `Offside.a1' from module `Offside' Project.lhs:4: Failed to find interface decl for `Offside.a3' from module `Offside' $ ghc -package lang -c -o Project.o Project.lhs $ Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC doesn't accept data types with 0 fielddecls
Hi guys,
With the module
data Foo = Foo {}
ghc tells me
tt.lhs:2: parse error on input `}'
while the report allows this.
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Incorrect parse errors
Hiyas
With the module
{
main = undefined
foo = 5
}
and with the module
module Foo where {
foo = 5
bar = 6
}
I get
tt.hs:4: parse error on input `='
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Incorrect parse errors
On Tue, Dec 11, 2001 at 06:10:11AM -0800, Simon Peyton-Jones wrote:
quite right too. The explicit { suppress the implicit layout.
Yes, sorry, my bad.
IAn
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Thanks for your help Simon. Unfortunately I think I have spent enough time on this, and not enough on what I would like it for, without getting there - I may try again in the future if the porting process becomes better documented/tested. Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Doh, I have several times got further than I thought but didn't realise
it as I didn't notice it had made a ghc-5.02 binary!
Here's my latest problem, anyway - I don't suppose it could be caused by
the hc files being generated under a different OS with different magic
numbers could it?
m99igl@booth33:rts$
LD_LIBRARY_PATH=/auto/ecslab/m99igl/scratch/local/readline/lib truss -o
truss.out ../../ghc/compiler/ghc-inplace -optc-O -optc-O2
-optc-fomit-frame-pointer -optc-Wall -optc-W -optc-Wstrict-prototypes
-optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline
-optc-Waggregate-return -optc-Wbad-function-cast -optc-Wcast-align
-optc-DCOMPILING_RTS -ldl -I../includes -I. -Iparallel -O2
-DCOMPILING_RTS -static-c Adjustor.c -o Adjustor.o
inappropriate type
Action: hFileSize
Handle:
{loc=/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace,type=readable,binary=False,buffering=block
(8192)}
Reason: not a regular file
File:
/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace
m99igl@booth33:rts$
-rw--- 1 m99igl 7270 Oct 26 23:40
/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace
truss says:
[...]
xstat(2, /tmp/foo/ghc-5.02/package.conf, 0x500BB020) Err#2 ENOENT
xstat(2, , 0x500BB0B8)= 0
open(/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace,
O_RDONLY|O_CREAT|O_NOCTTY, 0666) = 3
fcntl(3, F_GETFL, 0x01B6) = 0
fstat64(3, 0x0804569C) = 0
fstat64(3, 0x0804569C) = 0
fcntl(3, F_SETFL, 0x0800) = 0
fxstat(2, 3, 0x500BB190)= 0
ioctl(3, TCGETA, 0x0804575C)Err#25 ENOTTY
fxstat(2, 3, 0x500BB1F0)= 0
write(2, i, 1) = 1
write(2, n, 1) = 1
[spells out appropriate type etc]
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Building GHC 5.02 on Solaris x86
I am trying to build GHC 5.02 on an x86 Solaris machine (with the x86 HC
stuff) and I am getting this error:
gcc -x c MArray.hc -o MArray.raw_s -S -O -fno-defer-pop -fomit-frame-pointer
-DDONT_WANT_WIN32_DLL_SUPPORT -D__GLASGOW_HASKELL__=502 -O
-I/tmp/foo/ghc-5.02/ghc/includes -I/tmp/foo/ghc-5.02/ghc/lib/std/cbits
-I/tmp/foo/ghc-5.02/hslibs/lang/cbits -I/tmp/foo/ghc-5.02/hslibs/posix/cbits
-I/tmp/foo/ghc-5.02/hslibs/util/cbits -I/tmp/foo/ghc-5.02/hslibs/text/cbits
-I/tmp/foo/ghc-5.02/hslibs/hssource/cbits -I../../ghc/lib/std/cbits
-I../../ghc/includes -Icbits-I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'`
MArray.hc: In function `sbMI_ret':
MArray.hc:5292: fixed or forbidden register 3 (bx) was spilled for class GENERAL_REGS.
MArray.hc:5292: This may be due to a compiler bug or to impossible asm
MArray.hc:5292: statements or clauses.
MArray.hc:5292: This is the instruction:
(insn 28 26 31 (set (mem/s:DI (plus:SI (plus:SI (mult:SI (reg:SI 25)
(const_int 8 [0x8]))
(reg:SI 26))
(const_int 8 [0x8])) 0)
(reg/v:DI 24)) 79 {movdi+1} (insn_list 16 (insn_list 24 (insn_list 26 (nil
(expr_list:REG_DEAD (reg/v:DI 24)
(expr_list:REG_DEAD (reg:SI 25)
(expr_list:REG_DEAD (reg:SI 26)
(nil)
make[1]: *** [MArray.raw_s] Error 1
make: *** [all] Error 1
make: Leaving directory `/tmp/foo/ghc-5.02/hslibs'
I have also fount it neccesary to add
/tmp/foo/ghc-5.02/ghc/driver/mangler to the path for ghc-asm - should
this be needed?
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc misreports the error line
On Tue, Oct 23, 2001 at 03:24:56PM -0400, Sengan wrote: module Test where chars = foo bar Try this instead: module Test where chars = \n\ \foo\n\ \bar Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
On Tue, Oct 23, 2001 at 02:10:52PM +0100, Simon Marlow wrote: I am trying to build GHC 5.02 on an x86 Solaris machine (with the x86 HC stuff) and I am getting this error: [...] You need to add the line MArray_HC_OPTS += -monly-3-regs to fptools/hslibs/lang/Makefile. Thanks I have also fount it neccesary to add /tmp/foo/ghc-5.02/ghc/driver/mangler to the path for ghc-asm - should this be needed? I don't know, we haven't tested the bootstrapping process very thoroughly due to lack of time. I'll be happy to look through any patches you come up with, though. I've attached a diff of the changes I've made so far - they are changes to make it work rather than the correct way to fix it, though. I'm not quite there yet. It's currently doing this when linking everything together into ghc-5.02: [...] lHSconcurrent -lHSlang -lHSlang_cbits -lHSstd -lHSstd_cbits -lHSrts -lgmp -lm -L/auto/ecslab/m99igl/scratch/local/readline/lib -lreadline -lhistory -ltermcap -ldl Undefined first referenced symbol in file Readline_addzuhistory_closure ghci/InteractiveUI.o Readline_readline_fast2 ghci/InteractiveUI.o Readline_readline_closure ghci/InteractiveUI.o __stginit_Readline ghci/InteractiveUI.o ld: fatal: Symbol referencing errors. No output written to ghc-5.02 collect2: ld returned 1 exit status make[1]: *** [ghc-5.02] Error 1 make: *** [all] Error 1 make: Leaving directory `/tmp/foo/ghc-5.02/ghc' I'm doing something like: bunzip2 -c ghc-5.02-src-2.tar.bz2 | tar -xf - bunzip2 -c ghc-5.02-i386-hc-1.tar.bz2 | tar -xf - tar -zxf happy-1.11-src.tar.gz cd ghc-5.02 ln -s ../happy-1.11/happy/ happy make the changes export PATH=$PATH:/tmp/foo/ghc-5.02/ghc/driver/mangler CPPFLAGS=-I/auto/ecslab/m99igl/scratch/local/readline/include/ distrib/hc-build --prefix=/auto/ecslab/m99igl/scratch/local/ghc --includedir=/auto/ecslab/m99igl/scratch/local/readline/include/ If anyone spots anything obviously stupid I'm doing, please let me know :-) Thanks Ian diff -ur ghc-5.02x/ghc/lib/std/Makefile ghc-5.02/ghc/lib/std/Makefile --- ghc-5.02x/ghc/lib/std/Makefile Tue Oct 23 10:24:45 2001 +++ ghc-5.02/ghc/lib/std/Makefile Tue Oct 23 22:54:04 2001 @@ -113,14 +113,14 @@ ifneq $(TARGETPLATFORM) i386-unknown-mingw32 # Standard rule HSstd.o :: $(GHCI_LIBOBJS) - ld -r -x -o $@ $(GHCI_LIBOBJS) + ld -r -o $@ $(GHCI_LIBOBJS) else # Rule for Win32 platform # Keep HSstd.o as a pseudo-target (I think) HSstd.o :: $(GHCI_LIBOBJS) - ld -r -x -o HSstd1.o $(filter Prel%, $(GHCI_LIBOBJS)) - ld -r -x -o HSstd2.o $(filter-out Prel%, $(GHCI_LIBOBJS)) + ld -r -o HSstd1.o $(filter Prel%, $(GHCI_LIBOBJS)) + ld -r -o HSstd2.o $(filter-out Prel%, $(GHCI_LIBOBJS)) endif # TARGETPLATFORM = i386-unknown-mingw32 diff -ur ghc-5.02x/ghc/rts/StgCRun.c ghc-5.02/ghc/rts/StgCRun.c --- ghc-5.02x/ghc/rts/StgCRun.c Tue Oct 23 10:24:46 2001 +++ ghc-5.02/ghc/rts/StgCRun.c Tue Oct 23 22:57:20 2001 @@ -138,7 +138,7 @@ movl %2,%%eax\n\t jmp *%%eax\n\t - .global STG_RETURN \n + .globl STG_RETURN \n STG_RETURN :\n\t movl %%esi, %%eax\n\t /* Return value in R1 */ diff -ur ghc-5.02x/hslibs/lang/Makefile ghc-5.02/hslibs/lang/Makefile --- ghc-5.02x/hslibs/lang/Makefile Tue Oct 23 10:24:47 2001 +++ ghc-5.02/hslibs/lang/Makefile Tue Oct 23 22:54:14 2001 @@ -20,6 +20,7 @@ CTypes_HC_OPTS += -monly-3-regs ArrayBase_HC_OPTS += -monly-3-regs ForeignObj_HC_OPTS+= -monly-3-regs +MArray_HC_OPTS+= -monly-3-regs StorableArray_HC_OPTS += -funbox-strict-fields include $(TOP)/mk/target.mk diff -ur ghc-5.02x/hslibs/win32/Makefile ghc-5.02/hslibs/win32/Makefile --- ghc-5.02x/hslibs/win32/Makefile Tue Oct 23 10:24:47 2001 +++ ghc-5.02/hslibs/win32/Makefile Tue Oct 23 22:54:18 2001 @@ -58,9 +58,9 @@ HACKY_ALLOBJS = $(sort $(LIBOBJS) $(STUBOBJS) \ Win32Dialogue_stub.o Win32Window_stub.o) HSwin32.o :: $(HACKY_ALLOBJS) - ld -r -x -o HSwin321.o $(filter Win32M% Win32N% Win32R% Win32W%, \ + ld -r -o HSwin321.o $(filter Win32M% Win32N% Win32R% Win32W%, \ $(HACKY_ALLOBJS)) - ld -r -x -o HSwin322.o $(filter-out Win32M% Win32N% Win32R% Win32W%, \ + ld -r -o HSwin322.o $(filter-out Win32M% Win32N% Win32R% Win32W%, \ $(HACKY_ALLOBJS)) diff -ur ghc-5.02x/mk/bootstrap.mk ghc-5.02/mk/bootstrap.mk --- ghc-5.02x/mk/bootstrap.mk Tue Oct 23 10:24:44 2001 +++ ghc-5.02/mk/bootstrap.mkTue Oct 23 22:56:00 2001 @@ -114,7 +114,7 @@ -u PrelMain_mainIO_closure\ -u __stginit_PrelMain -HC_BOOT_LIBS = -lHStext -lHStext_cbits -lHSutil -lHSposix -lHSposix_cbits -lHSconcurrent -lHSlang -lHSlang_cbits
Bug with -h and -c together
Here's another one, using GHC 5.02 [ian@urchin current]$ cat W.lhs module Main where main :: IO() main = putStrLn $ show $ last [1..10] [ian@urchin current]$ ghc W.lhs -prof -auto-all -o W [ian@urchin current]$ ./W +RTS -h 10 [ian@urchin current]$ ./W +RTS -c 10 [ian@urchin current]$ ./W +RTS -h -c Segmentation fault (core dumped) [ian@urchin current]$ In a rather larger piece of code I get [ian@urchin current]$ ./Project -d +RTS -M350M -h -c PP.lhs Project: fatal error: scavenge_mark_stack: unimplemented/strange closure type 29 @ 0x500c22a0 which is hopefully caused by the same bug. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O.
On Mon, Oct 01, 2001 at 10:52:32AM +0100, Simon Marlow wrote: This is a known bug, but thanks for reporting it anyway. The workaround is as suggested, try compiling with -O. I *was* compiling with -O. IIRC the problem occured with any level of optimisation I tried if and only if profiling was enabled. Any other suggestions? You could try breaking up the structure into smaller pieces. If you have a local GHC build, you can also bump the BLOCK_SIZE to 8k in ghc/rts/Constants.h. Did you mean ghc/includes/Constants.h? Changing #define BLOCK_SIZE 0x1000 to #define BLOCK_SIZE 0x2000 in there and rebuilding produced a build which produces code that segfaults. Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O.
On Mon, Oct 01, 2001 at 09:39:51AM +0100, Simon Marlow wrote: On Sun, Sep 30, 2001 at 03:29:44PM +0100, Ian Lynagh wrote: $ ghc -O -fvia-C -O2-for-C -Wall -package lang -prof -auto -c -o Tokens.o Tokens.lhs $ ghc -O -fvia-C -O2-for-C -Wall -package lang -prof -auto -c -o IA.o IA.lhs ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O. Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Just tried with 5.02 and the same thing happens: ghc-5.02: panic! (the `impossible' happened, GHC version 5.02): Oversize heap check detected. Please try compiling with -O. This is a known bug, but thanks for reporting it anyway. The workaround is as suggested, try compiling with -O. I *was* compiling with -O. IIRC the problem occured with any level of optimisation I tried if and only if profiling was enabled. Any other suggestions? It tends to happen particularly when a module contains a large static data structure. This is indeed the case. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghci problem parsing where
Using GHC Interactive, version 5.02: Prelude x where x = 5 interactive:1: parse error on input `where' let works fine: Prelude let x = 5 in x 5 Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghci buffering
Can the default in ghci be no buffering? If I am working with ghci or hugs I normally want to see results as they are produced. Also, is there a way to use the IO functions without making a module just to import IO? Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci problem parsing where
On Mon, Oct 01, 2001 at 11:38:33AM +0100, Simon Marlow wrote: Using GHC Interactive, version 5.02: Prelude x where x = 5 interactive:1: parse error on input `where' let works fine: Prelude let x = 5 in x 5 'where' clauses aren't allowed on an arbitrary expression. They are allowed as part of a declaration only - see the 'rhs' production in the Haskell grammar. Ah, yes, thanks, I'm just used to it working in hugs :-) Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O.
Hiyas, $ ghc -O -fvia-C -O2-for-C -Wall -package lang -prof -auto -c -o Tokens.o Tokens.lhs $ ghc -O -fvia-C -O2-for-C -Wall -package lang -prof -auto -c -o IA.o IA.lhs ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O. Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. The files are at http://c93.keble.ox.ac.uk/~ian/Tokens.lhs http://c93.keble.ox.ac.uk/~ian/IA.lhs Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O.
On Sun, Sep 30, 2001 at 03:29:44PM +0100, Ian Lynagh wrote: $ ghc -O -fvia-C -O2-for-C -Wall -package lang -prof -auto -c -o Tokens.o Tokens.lhs $ ghc -O -fvia-C -O2-for-C -Wall -package lang -prof -auto -c -o IA.o IA.lhs ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O. Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Just tried with 5.02 and the same thing happens: ghc-5.02: panic! (the `impossible' happened, GHC version 5.02): Oversize heap check detected. Please try compiling with -O. Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Literate scripts not handled correctly
Hi all
My understanding is that the following script:
- cut here -
foo :: Int - Int
foo _ = 2
\begin{code}
bar :: Int - Int
bar _ = 1
\end{code}
- cut here -
should be valid and define foo and bar (although the report does say It
is not advisable to mix these two styles in the same file).
However, in hugs:
ERROR Q.lhs:7 - Syntax error in input (unexpected symbol bar)
% ghc -c -o Q.o Q.lhs
Q.lhs:7: parse error on input `bar'
% nhc98 -c -o Q.o Q.lhs
In file ./Q.lhs:
7:1 Found bar but expected a {-EOF-}
Secondly, in the following script (which I think should define main
according to the report):
- cut here -
\begin{code}
module Main where
main :: IO()
main = putStrLn Foo
\end{code}
- cut here -
hugs:
ERROR W.lhs:12 - Empty script - perhaps you forgot the `'s?
% nhc98 -c -o W.o W.lhs
Warning: Can not find main in module Main.
ghc -c -o W.o W.lhs
W.lhs line 11: unlit: missing \end{code}
Interestingly it works in GHC if you remove the white space before the
end but not before the begin.
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Erroneous warning
If Q.lhs is module Q where foo :: Int - Int foo (i+1) = i foo 0 = -10 then % ghc -c -o Q.o Q.lhs Q.lhs:5: Warning: Pattern match(es) are overlapped in the definition of function `foo': foo 0 = ... Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Erroneous warning
On Mon, Sep 17, 2001 at 12:52:32PM +0100, Ian Lynagh wrote: Q.lhs:5: Warning: Pattern match(es) are overlapped in the definition of function `foo': foo 0 = ... Oh, along similar lines, should the warning not be Pattern match(es) are hidden in [...] or similar? Overlapping patterns are OK, e.g. foo 5 = 0 foo _ = 2 but the problem comes when they are the other way round so the first one hides the second. Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
