Re: #4034: GHC 6.12.2 fails to build on PowerPC / MacOS X Leopard
Hi, was someone able to compile ghc-6.12.3 on PowerPC / MacOS X? My attempt failed with: /usr/bin/ld -r -o compiler/stage2/build/HSghc-6.12.3.o ... `/usr/bin/find compiler/stage2/build -name *_stub.o -print` ld: scattered reloc r_address too large for inferred architecture ppc make[1]: *** [compiler/stage2/build/HSghc-6.12.3.o] Error 1 make: *** [all] Error 2 Cheers Christian GHC schrieb: #4034: GHC 6.12.2 fails to build on PowerPC / MacOS X Leopard --+- Reporter: PHO | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.14.1 Component: Compiler |Version: 6.12.2 Resolution: fixed| Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: powerpc Failure: Building GHC failed | --+- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Closing, as it doesn't happen in the HEAD. ___ 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
Serge D. Mechveliani wrote: Dear GHC team, let me answer as a plain ghc user. I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, run the executable, and obtain 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. Segmentation fault should not result from missing method definitions. So please report a bug if it can be reproduced. Cheers Christian Are you interested in the bug report on the above part of Segmentation fault ? - Serge Mechveliani mech...@botik.ru ___ 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
Changes (by igloo): * milestone: 6.10.1 = 6.12 branch Comment: 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. Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANN: ghc 6.8.2 from MacPorts
Thanks Chris! This should fix http://hackage.haskell.org/trac/ghc/ticket/1958 http://hackage.haskell.org/trac/ghc/ticket/2117 Thorkil, you called your patch illustrative only. I suggest to commit it. Any objections? Thanks for the patch, anyway. Cheers Christian My built can be found at: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2 It uses static libs for gmp, ncurses and readline, but should run on tiger and leopard ppc. (#1845, #2031 are still problems) C.M.Brown wrote: Hi Christian, The build went without any problems, the log can be found here: http://www.cs.kent.ac.uk/people/rpg/cmb21/inst.log.gz kind regards, Chris. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.8.2 overflows stack
Chad Scherrer wrote: Hello, I'm trying to compile stream-fusion-0.1.1 with profiling enabled, and it's overflowing the stack. $ runghc Setup.lhs configure -pO Configuring stream-fusion-0.1.1... $ runghc Setup.lhs build Preprocessing library stream-fusion-0.1.1... Building stream-fusion-0.1.1... [2 of 3] Compiling Data.List.Stream ( Data/List/Stream.hs, dist/build/Data/List/Stream.o ) stack overflow: use +RTS -Ksize to increase it Has anyone seen this before? Is it a known bug? Why bug? I also had to increase the stack size when compiling with profiling. It's a plain, though big, binary: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/daily/hets.bz2 I use the additional flags: -prof -auto-all -osuf p_o +RTS -K100m -RTS HTH Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris
Hi Simon, could you please supply a testsuite.tgz for ghc-6.8.2 so that I can test it? (Or say how to easily get the testsuite only). I hope ghc-6.8.2 is sufficient for testing. Cheers Christian see also http://hackage.haskell.org/trac/ghc/ticket/2025 GHC wrote: #1015: regex001(ghci,threaded1) seg-faults under Solaris ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: bug| Status: new Priority: normal | Milestone: _|_ Component: Compiler |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Solaris| ---+ Comment (by simonmar): Christian - is this bug still relevant? ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Integrating editline with ghc
Malcolm Wallace wrote: I think I am persuaded that this is the most important goal: stability of the API and package interface, for existing clients of readline. If individual projects would like to migrate from using readline to using editline, then those are the ones that should pay the small amount of pain (in using CPP, package configurations, etc) to manage the change. Anyone else should be totally unaffected. I would like to know from package maintainers if there packages can be easily ported from libreadline to libedit. The best indication for this would be if the package is also happy with a restricted interface of readline (i.e. readline-compat) or requires the full GNU readline. At least testing this compatibility makes sense using a readline package with a temporarily reduced interface (without the need to change the packages depending on readline.) Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell package installation problem
Brian Park wrote: Hi, I was installing various haskell packages from hackage. When I was installing HaXml, I think it was complaining about Text.PrettyPrint.HughesPJ not installed or something. (can't remember the specific message and I can't reproduce now...) HaXml-1.13.2 needs pretty and containers as additional build-depends in HaXml.cabal for ghc-6.8.x (HaXml-1.13.3 should work). I don't know about http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml-1.19.1 So I installed pretty-1.0.0.0 package as well. bad move, Cabal itself depends on (this) pretty (package). Reinstalling pretty failed and spoiled you're installation. Maybe such kind of (re-)installation should be prohibited somehow. Cheers Christian Ever since then, when I try to install other haskell packages, I get the following error message: [EMAIL PROTECTED]:~/Download/mtl-1.1.0.0$ runghc Setup.hs configure interactive: /usr/local/lib/ghc-6.8.2/lib/Cabal-1.2.3.0/HSCabal-1.2.3.0.o http://1.2.3.0/HSCabal-1.2.3.0.o: unknown symbol `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl18_closure' ghc-6.8.2: unable to load package `Cabal-1.2.3.0 http://1.2.3.0' Does anyone know what the problem is? Currently installed packages are: = /usr/local/lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, HTTP-3001.0.4, HUnit-1.2.0.0, X11-1.4.1, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, containers-0.1.0.1, directory-1.0.0.0, filepath-1.1.0.0, (ghc-6.8.2), haskell98-1.0.1.0 , hpc-0.5.0.0, hxt-7.4, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parsec-2.1.0.0, polyparse-1.1, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0 , rts-1.0, template-haskell-2.2.0.0, unix-2.3.0.0, xmonad-0.5, xmonad-contrib-0.5 = Thank you, - Brian ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ 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
(Let's discuss this openly on glasgow-haskell-users) I'm not happy about this framework hick-hack either. I've only pushed it, because we needed a readline solution on macs. The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs. Nobody supplied a binary distribution so far, though. I only supplied the binary distributions that I (naively) made anyway. Regarding this actual GNUreadline-framework.zip replacement, this is harmless and seems to matter only for those who build ghc with frameworks (as only the inclusion of header files changed) In any case we should strive to fix the frameworks issues _and_ add support for static linking of gmp, readline and possibly other libs (plus license issues). HTH Christian Thorkil Naur wrote: Hello, Thanks everybody. However, I believe that using a modified readline library is debatable, mainly because it adds the burden of keeping this library up-to-date to the GHC maintenance process. Having a renamed library is one thing and it does not seem that also modifying the contents of the library is an improvement. For me to consider this idea, it should be the very last solution, every other stone having been turned. And I certainly believe that stones remain to be turned in this case. I would very much like to hear your comments to this. In addition, if you must replace this framework with another with different contents, I would suggest the use of some versioning scheme. Otherwise is seems that a lot of confusion could result. Thanks and best regards Thorkil On Thursday 03 January 2008 16:18, Ian Lynagh wrote: 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
Re: Problem building hdbc-sqlite3 with ghc 6.8.2
manu wrote: hello, has anybody managed to build hdbc-sqlite3 with ghc 6.8.2 ? I get the following error : Macintosh:HDBC-sqlite3-1.1.3.0 manu$ runhaskell Setup.lhs build Preprocessing library HDBC-sqlite3-1.1.3.0... ghc-6.8.2: unrecognised flags: -F/Users/manu/Library/Frameworks Usage: For basic information, try the `--help' option. compiling dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.c failed command was: /usr/local/bin/ghc -c -package base-3.0.1.0 -package mtl-1.1.0.0 -package HDBC-1.1.3 -I. -F/Users/manu/Library/Frameworks dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.c -o dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.o if somebody has an idea... I seems you used my binary dist that I made with a modified utils/hsc2hs/Main.hs http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13583 http://hackage.haskell.org/trac/ghc/ticket/1395 hsc2hs only worked for me when gcc was used instead ghc (when bootstrapping ghc-6.8.2 itself). Maybe I should build new binary-dists. Is it for ppc or x86? Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1609: spurious gcc warnings with non-english language setting
GHC wrote: #1609: spurious gcc warnings with non-english language setting ---+ Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: new Priority: low |Milestone: Component: Compiler| Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | ---+ Comment (by [EMAIL PROTECTED]): Your gcc seems to emit english messages. I've attached a log of my ghc invocation. The warning does not have further consequences - the programs compile and run normally. The problem is entirely harmless - just very irritating. Right, more and more programs come with translated messages. After one upgrade I was slightly shocked that 'process killed' was translated to `Prozess getötet` (with the umlaut wrongly displayed). Although matching literate messages is no good idea (I saw programs fail because they expected yes instead of ja) the simplest fix, Simon Marlow, is to internally set LANG to C or wait for a gcc that allows to disable this warning properly. Cheers Christian ___ 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?
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) The plural options work! So flag-reference.html should be corrected. C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-keep-hc-files or -keep-hc-file?
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) Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Darcs on Solaris x86
Rich Collins schrieb: It was a problem with the linking for ghc. I hacked LD_LIBRARY_PATH for my user account and it worked. You might want to add /opt/csw/lib/ when compiling ghc. Setting LD_LIBRARY_PATH only helps to find missing libs like libgmp.so (or libreadline.so). But the directory /opt/csw/lib/ is not part of every installation (in particular it does not exist on our machines.) For the linker error, that you reported, configure:2718: ghc -o conftest conftest.hs ld: fatal: symbol `GHC_ZCCReturnable_static_info' in file /opt/local/lib/ghc-6.6.1/libHSrts.a(PrimOps.o): section [1] .text: size 8212: symbol (address 0x2014, size 4) lies o did you not need to update the ghc-binary? Thanks Christian This bug has recently been fixed. http://hackage.haskell.org/trac/ghc/ticket/1421 Download the new binary dist: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/versions/new-ghc-6.6.1-i386-unknown-solaris2.tar.bz2 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1367: GHC[i] 6.6.1 can't find GNUreadline on PPC mac
Hal Perkins schrieb: One suggestion (request?) for the future: would it be possible to fix the pre-built os-x packages so they are self-contained, as they were for GHC 6.6? The problem with the ghc-6.6 binary dist was, that it required root rights and also installed libreadline.so for you somewhere (silently). A framework is much more mac-like (or standard) and either belongs under /Library/Frameworks or $HOME/Library/Frameworks. The frameworks under /Library/Frameworks are much more convenient (for your own developments) but require root rights (furthermore an existing framework should not be simply overwritten without interaction.) Or at least add a note to the instructions on the download page (http://www.haskell.org/ghc/download_ghc_661.html) In fact, I wanted Ian to do that. and/or maybe in the dmg file describing what needs to be done to install the necessary frameworks? I don't know how to compose dmg files, but I hope to find time to look into it. (I mainly see the mac as a remote unix machine and rarely do any double clicking directly.) Thanks again, and at least from my end, this bug seems resolved. Thanks for your feedback Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Hi, I've created a ticket on this matter: http://hackage.haskell.org/trac/ghc/ticket/1437 (Add further comments as you think fit) Deborah Goldsmith schrieb: 2. Move in mk/build.mk to work around splitter incompatibility with Leopard Does mk/build.mk only contain SplitObjs = NO? I suggest to make the stage1 compiler by putting also a line GhcStage1HcOpts = -O0 -DDEBUG into mk/build.mk (as suggested on http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking) Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Stefan Parvu schrieb: This is with the original linker from S11 and it *works* [EMAIL PROTECTED]env LD_LIBRARY_PATH=/opt/csw/lib ghc --make hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... Great, the problem is gone. I could confirm Simon's fix using Rod's linker. I'll update http://hackage.haskell.org/trac/ghc/ticket/1421 Thanks for all your help. Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Simon Marlow schrieb: Christian Maeder wrote: Simon Marlow schrieb: [...] I guess we should just eliminate the .size directives if the linker is going to be picky about them. In ghc-asm.lprl you'll find $T_COPY_DIRVS = '^\s*\.(globl|type|size|local)'; if you change it to $T_COPY_DIRVS = '^\s*\.(globl|local)'; [...] Should be ok, yes. The .size and .type information is only used when linking dynamically (at least on platforms I'm familiar with, which doesn't include Solaris), and we're only using static libraries here. It might be more correct for _info symbols to get .type function, since they're followed by code. I don't think we should worry about this though. Ok, I've created a binary dist with this change, but I cannot test it with Solaris 11 linkers, currently. http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/versions/new-ghc-6.6.1-i386-unknown-solaris2.tar.bz2 Rod (or Stefan) could you try to test this distribution with your various linkers as follows: cd ghc-6.6.1 ./configure --prefix=$HOME/ghc-6.6.1 gmake install export PATH=$HOME/ghc-6.6.1/bin:$PATH ghc --make hello.hs where hello.hs contains: main = putStrLn hello I expect Rod's modified linker to just emit a warning and the Solaris 11 linker (ld 5.11-1.555) still to fail. Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Simon Marlow schrieb: Christian Maeder wrote: [...] In PrimOps.s it looks (wrongly mangled?) like this: .text .align 4 .type GHC_ZCCReturnable_static_info, @object .size GHC_ZCCReturnable_static_info, 4 .zero 4 .globl GHC_ZCCReturnable_static_info GHC_ZCCReturnable_static_info: [...] I guess we should just eliminate the .size directives if the linker is going to be picky about them. In ghc-asm.lprl you'll find $T_COPY_DIRVS = '^\s*\.(globl|type|size|local)'; if you change it to $T_COPY_DIRVS = '^\s*\.(globl|local)'; Now it looks like: .text .align 4 .zero 4 GHC_ZCCCallable_static_info: .text .align 4 .zero 4 .globl GHC_ZCCReturnable_static_info and elfdump shows: Section Header[1]: sh_name: .text sh_addr: 0 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] sh_size: 0x213c sh_type:[ SHT_PROGBITS ] and size 0! [...] [206] 0x213c 0x NOTY GLOB D0 .text GHC_ZCCReturnable_static_info Is this going to work? Rod, I've no root permission on our machines (and no pkgadd and pkgrm). Could you send me the ld as plain binary (or can I unpack the package SUNWonld somehow)? Stefan, could you send me your ld 5.11-1.555, too? (I was able to link with GNU ld version 2.17) Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Simon Marlow schrieb: The only reason we keep the .size directives around at all is because certain tools (like Valgind for example) don't work without .size information. GHC itself, including our dynamic linker, works fine without it. I can't tell exactly what has gone wrong in this particular instance - you'll need to compile the offending module with -keep-raw-s-file -keep-s-file and inspect those .size directives. At the end of PrimOps.raw_s there (probably correctly) is: .globl GHC_ZCCReturnable_static_info .align 4 .type GHC_ZCCReturnable_static_info, @object .size GHC_ZCCReturnable_static_info, 4 GHC_ZCCReturnable_static_info: .zero 4 All .text blocks are followed by p2align 2,,3 and typically look like: .string delayzh_fast .text .p2align 2,,3 In PrimOps.s it looks (wrongly mangled?) like this: .text .align 4 .type GHC_ZCCReturnable_static_info, @object .size GHC_ZCCReturnable_static_info, 4 .zero 4 .globl GHC_ZCCReturnable_static_info GHC_ZCCReturnable_static_info: Files are attached under http://hackage.haskell.org/trac/ghc/ticket/1421 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Rod Evans schrieb: If this solves your problem ghc has a problem with object splitting under some solaris linkers Are you talking about the size issue we're presently discussing, or another issue in which the Solaris linkers fail you? We'd be happy to work with you directly to investigate things. I'm only talking about this size issue. The size problem occurs already in PrimOps.o (that is created from C-- sources PrimOps.cmm). Object splitting created the original file Utils__90.o with the size problem. http://www.opensolaris.org/jive/thread.jspa?threadID=32325tstart=0 (I don't now yet if the original Utils.o has a size problem, too.) I suppose creating object files from plain C should not result in object files with a size problem. Simon, do you have any idea why PrimOps.o has this problem (although only for a picky new linker)? I'm going to checkout Utils__90.o too, perhaps our validation can be loosened a little to forgive this files inconsistency. Good Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Deborah Goldsmith schrieb: I kind of doubt this is the problem, but I could try it. I assume I can fiddle with the configuration variables and have it use gcc-3.3 instead of gcc? I usually make a link to another gcc and let it find first in the path. ln -s /usr/bin/gcc-3.3 ~/bin export PATH=~/bin:$PATH C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Deborah Goldsmith schrieb: OK, I was able to build 6.6.1 successfully on 10.4 (Intel Core Duo) with both the standard configuration and with SplitObjs = NO. The build was done with the same binary 6.6.1 release, GMP, and GNU readline as on 10.5. So this is definitely something about 10.5 (not a surprise). The messages about .dSYM are due to a change in the default debugging file format for 10.5. I can't say any more than that. Is there anything else you would like me to try? Do you have another gcc (like gcc-3.3) that you can try out? Would it help to switch on debugging flags (how and which?) for gcc to find out the cause of the crash? Cheers Christian m29:~ maeder$ ll /usr/bin/gcc-3.3 -r-xr-xr-x 1 root wheel 260616 Sep 12 2006 /usr/bin/gcc-3.3 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Deborah Goldsmith schrieb: I'm also going to try building on 10.4.x to see if this is 10.5-specific. Yes, do so. One more variable is that the build on 10.5 was done on a machine with an Intel Core 2 Duo processor. I don't know if that's relevant. No idea, the GMP framework should be ok, since we have the same one, too. Cheers Christian P.S. In your configure log are spurious messages: rm: conftest.dSYM: is a directory that I don't have (attached) log.conf.bz2 Description: application/bzip ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Christian Maeder schrieb: I can only offer to make a rebuild with any options that might help. May it be a problem with the GMP framework? The one for downloading (gmp-4.2.1) might be different from the one that's globally installed here (gmp-4.2). GMP (v7) used by ghc $ otool -L ghc-6.6.1/lib/i386-apple-darwin/ghc-6.6.1 ghc-6.6.1/lib/i386-apple-darwin/ghc-6.6.1: GNUreadline.framework/Versions/A/GNUreadline (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7) GMP.framework/Versions/A/GMP (compatibility version 7.0.0, current version 7.0.0) versus GMP (v8) on our download page: $ otool -L ~/Library/Frameworks/GMP.framework/Versions/A/GMP /home/maeder/Library/Frameworks/GMP.framework/Versions/A/GMP: GMP.framework/Versions/A/GMP (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7) but. I've no problem with either GMP frameworks C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
make binary-dist for ghc-6.6.1 shows latex error
When making a binary distribution from the official ghc-6.6.1 sources, I
get the latex error below for core.tex. I have to skip this error by
typing ^D (EOF) explicitly. (I did not find out how to fix this error on
line 528 of core.tex, though)
The final documentation lacks a core.ps file. But such a file is also
missing in:
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-unknown-linux.tar.bz2
What should happen with core.tex?
Cheers Christian
Underfull \hbox (badness 1) in paragraph at lines 511--528
! You can't use `macro parameter character #' in horizontal mode.
argument ... b} \par {\tt par x y = case (par##
x) of \_ - lazy y}
\par ...
l.528 ...boxed type. }{\primoptions{}{}{}{}{}{}{}}
?
! Emergency stop.
argument ... b} \par {\tt par x y = case (par##
x) of \_ - lazy y}
\par ...
l.528 ...boxed type. }{\primoptions{}{}{}{}{}{}{}}
Output written on core.dvi (34 pages, 104288 bytes).
Transcript written on core.log.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1157: hxt cannot be compiled with optimization level 2 (-O2)
Could it be documented at: http://www.haskell.org/ghc/download_ghc_66.html#macosxppc that at least gcc 3.3.1 is required GHC schrieb: #1157: hxt cannot be compiled with optimization level 2 (-O2) ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: bug| Status: closed Priority: normal | Milestone: 6.6.1 Component: libraries (other) |Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X| ---+ Changes (by igloo): * resolution: = invalid * status: new = closed Comment: This looks like an internal compiler error from gcc. The web has similar reports that it claims are fixed in gcc 3.3.1, so upgrading may fix the problem. If not, you'll have to file a bug against gcc. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
trac-ticket/955
For some reason I cannot login using guest guest http://hackage.haskell.org/trac/ghc/ticket/955 I only want to suggest to change the milestone to 6.8. Although the code-bloat is not nice, we could live with it. Christian ___ 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
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. Christian ___ 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
Winfried Kung schrieb: I also had to set explicitely SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc as Duncan Coutts already pointed out. I did nothing special. My build.mk (in mk/) says: BIN_DIST=1 Project=Ghc SRC_HC_OPTS += -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc Note the += when setting SRC_HC_OPTS! C. ___ 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
Winfried, could you also try my binary distribution? 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 Winfried Kung schrieb: Hello, when trying to build ghc-6.6 under Sparc Solaris (SunOS 5.9), the build fails with /usr/ccs/bin/ld: illegal option -- x I use gcc version 3.4.4 and GNU ld version 2.11.2 (with BFD 2.11.2). My configure recognizes them and sets an ld option -x as expected. But when it comes to make, I get the message: ghc-6.6 can cope with the solaris linker. So if you call ./configure when /usr/ccs/bin is first in your path, this should avoid using the -x option. == 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. This seems strange to me, too, sorry. Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1116: Error building ghc on Solaris 9
try gmake instead of make GHC schrieb: #1116: Error building ghc on Solaris 9 -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.6.2 Component: Compiler | Version: 6.6 Severity: major |Keywords: Make error Difficulty: Unknown |Testcase: Architecture: sparc | Os: Solaris -+-- I'm new to ghc - trying to build v6.6 on Solaris 9, gcc v3.2.1. After './configure' I type 'make' and get the following error: make: Fatal error in reader: ./mk/boilerplate.mk, line 22: Unexpected end of line seen Any hints? ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: BUG in HAskell! Help! Bad interface file: IO.hi
How did you call ghci? Maybe some *.hi files build on another platform were lying around. Cheers Christian Loading IO works for me (on the same machine): Loading package base ... linking ... done. Prelude :m IO Prelude IO [EMAIL PROTECTED] schrieb: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. interactive:1:84: Bad interface file: IO.hi IO.hi: openBinaryFile: does not exist (No such file or directory) ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-solaris2): interactiveUI:flush ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #993: threaded RTS under pc-solaris does not work
Indeed, that avoided the immediate crash. I'll try a completely new
ghc-6.6 build now.
GHC schrieb:
#993: threaded RTS under pc-solaris does not work
+---
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.6.1
Component: Runtime System |Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: N/A | Architecture: x86
Os: Solaris |
+---
Comment (by simonmar):
Looking at the manual for GNU as, it doesn't say anything about using a
slash (/) between the prefix and instruction mnemonic, so you might try
changing that code to
{{{
#if i386_HOST_ARCH || x86_64_HOST_ARCH
__asm__ __volatile__ (
lock cmpxchg %3,%1
:=a(o), =m (*(volatile unsigned int *)p)
:0 (o), r (n));
return o;
}}}
in fact, I don't know where that slash came from!
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1002: ghc-6.6 sometimes hangs under Solaris
Claus Reinke schrieb: #1002: ghc-6.6 sometimes hangs under Solaris After compiling 643 modules (in 5 minutes) ghc-6.6 did not finish its batch job. .. I have often seen problems like this with the Solaris linker. (I suspect it must have a super-linear algorithm for resolving symbol references.) It's not a linker problem, ghc-6.6 hangs on other occasions, too. I've tried both linkers, they link with the same speed nowadays. Thanks anyway, Christian Maybe that section should simply be removed? http://haskell.org/haskellwiki/GHC/FAQ#Why_does_linking_take_so_long.3F ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
no happy
Bulat Ziganshin schrieb:
may be this will be useful:
-- This equalizer routine required because MArray interface was changed in
GHC 6.6
#if defined(__GLASGOW_HASKELL__) (__GLASGOW_HASKELL__ = 605)
getMBounds arr = getBounds arr
#else
getMBounds arr = return (bounds arr)
#endif
usage example:
putMArrayWith write h arr= do bounds - getMBounds arr
loop 0 (rangeSize(bounds)-1)
(\i - unsafeRead arr i = write h)
Hi Bulat, thanks for your answer, but the code in LALR.lhs:626:34
(happy-1.15) lacks a monad for getBounds (or I'm blind):
countConflicts :: ActionTable - (Array Int (Int,Int), (Int,Int))
countConflicts action
= (conflictArray, foldr (\(a,b) (c,d) - (a+c, b+d)) (0,0) conflictList)
where
conflictArray = listArray (bounds action) conflictList
conflictList = map countConflictsState (assocs action)
countConflictsState (state, actions)
= foldr countMultiples (0,0) (elems actions)
where
countMultiples (LR'Multiple (_:_) (LR'Shift{})) (sr,rr)
= (sr + 1, rr)
countMultiples (LR'Multiple (_:_) (LR'Reduce{})) (sr,rr)
= (sr, rr + 1)
countMultiples (LR'Multiple as a) (sr,rr)
= error bad conflict representation
countMultiples _ c = c
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
cabal, extralibs, no happy
1. The VERSION = 5.2 in libraries/fgl/Makefile does not correspond to libraries/fgl/fgl.cabal version:5.3 Probably VERSION should always be extracted from the .cabal file. 2. When installing libraries/network via cabal (under solaris) the 'extraLibraries = [nsl,socket]' have not been put into the package.conf file 3. the happy-1.15 sources can not be compiled due to http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html # The HasBounds class has been removed from Data.Array.Base, and its bounds method is now in the IArray class. The MArray class has also gained a method getBounds. # Is there any easy fix? Cheers Christian ___ 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
Duncan Coutts schrieb: Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Yes! I get exactly the same under sparc linux for ghc-6.6. I've tried the same on a different machine (with another gcc) and now it works! It works with gcc_4.0.3_s10 on SunOS leo 5.10 Generic_118833-20 sun4u sparc SUNW,Sun-Fire-280R -bash-3.00$ compiler/stage2/ghc-6.6 ghc-6.6: missing -Bdir option -bash-3.00$ ldd compiler/stage2/ghc-6.6 librt.so.1 =/lib/librt.so.1 libdl.so.1 =/lib/libdl.so.1 libreadline.so.5 = /usr/local/lib/libreadline.so.5 libncurses.so.5 = /usr/local/lib/libncurses.so.5 libm.so.2 = /usr/local/lib/libm.so.2 libgmp.so.3 = /usr/local/lib/libgmp.so.3 libpthread.so.1 = /lib/libpthread.so.1 libc.so.1 = /lib/libc.so.1 libaio.so.1 = /lib/libaio.so.1 libmd5.so.1 = /lib/libmd5.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-280R/lib/libmd5_psr.so.1 It crashes as above on SunOS cni 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-V240 with gcc_3.4.4_s10. -bash-3.00$ compiler/stage2/ghc-6.6 ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? -bash-3.00$ ldd compiler/stage2/ghc-6.6 librt.so.1 =/lib/librt.so.1 libdl.so.1 =/lib/libdl.so.1 libreadline.so.5 = /usr/local/lib/libreadline.so.5 libncurses.so.5 = /usr/local/lib/libncurses.so.5 libm.so.2 = /usr/local/lib/libm.so.2 libgmp.so.3 = /usr/local/lib/libgmp.so.3 libpthread.so.1 = /lib/libpthread.so.1 libc.so.1 = /lib/libc.so.1 libaio.so.1 = /lib/libaio.so.1 libmd5.so.1 = /lib/libmd5.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote: Looks like the file OSMem.o is missing from your RTS build somehow. It should be in ghc/rts/posix. Ah, posix is a new directory that I did not check out. C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
The stage2 compiler non-deterministically crashes with segmentation fault (and even works some times) C. -bash-3.00$ ghc/compiler/stage2/ghc-inplace --interactive ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude :q Leaving GHCi. -bash-3.00$ ghc/compiler/stage2/ghc-inplace --interactive ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linSegmentation Fault ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Hi Simon, I've recompiled ghc-6.4.2 from cvs again without -threaded. The regression test looks much better now (below). The conc-cases go through now, but the following problems do still exist: cc04 (and ffi012) reported: 'calling convention not supported on this architecture: stdcall' ffi004 (arr016, ffi009 and maessen-hashtab) produced 'Segmentation Fault' with Wrong exit code (expected 0 , actual 139 ) Let me know if you want to see the whole log. I've circumvented the too few arguments to function 'ctime_r'-problem now by simply deleting ctime_r from the configure file. I've also created an improved binary solaris distribution (including OpenGL, but without ps docs): http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/versions/ghc-6.4.2-20060529-sparc-sun-solaris2.tar.bz2 Cheers Christian OVERALL SUMMARY for test run started at Wed May 31 19:27:09 CEST 2006 1365 total tests, which gave rise to 4157 test cases, of which 0 caused framework failures 580 were skipped 3469 expected passes 51 expected failures 0 unexpected passes 57 unexpected failures Unexpected failures: IOError001(normal,opt,prof,threaded) arr016(normal,prof,threaded) barton-mangler-bug(normal,opt,prof,ghci,threaded) ffi004(normal,opt,prof,threaded) ffi009(normal,opt,prof,threaded) galois_raytrace(prof) ghciprog004(normal) hGetLine002(normal,opt,prof,ghci,threaded) hGetPosn001(normal,opt,prof,ghci,threaded) hSeek004(normal,opt,prof,ghci,threaded) ioref001(normal,prof,threaded) joao-circular(normal,opt,prof,threaded) maessen_hashtab(opt,prof) openFile003(normal,opt,prof,ghci,threaded) readFile001(normal,opt,prof,ghci,threaded) seward-space-leak(ghci) ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote: Do you know if the stage2 compiler works with -threaded? Or does it still crash? The stage2 compiler created with -threaded seg-faulted even for a simple hello.hs. That's the reason I've switched off -threaded. That needs to be investigated. I've no clue how to go about this. Ok, but that doesn't help me find a fix. Any chance you could investigate why my fix didn't work? It apparently worked on the machine I tried it on, but I think that was Solaris 9. Well. at least Florenz reported independently the same ctime_r problem under Solaris 10 in http://hackage.haskell.org/trac/ghc/ticket/775 Maybe the configure test needs an update for Solaris 10. Our (Solaris 10) ctime_r function needs three arguments and thus is not standard-conforming, but has the same functionality as ctime. Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Christian Maeder wrote: Well. at least Florenz reported independently the same ctime_r problem under Solaris 10 in http://hackage.haskell.org/trac/ghc/ticket/775 Ok, he used the original 6.4.2 sources that did not have your fix. What file was supposed to fix the problem? C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote: Ach, my fault. Somehow I forgot to merge that fix into the 6.4 branch. Sorry :-( It should be there now. The file RtsUtils.c has changed. Ok, I'm recompiling and RtsUtils.c has been compiled by ghc-inplace now (so your fix works) C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote: It looks like every GHCi test failed (the TH tests use GHCi internally, so they failed too). Does GHCi fail? If so, in what way? simply doing gmake in tests/ghc-regress is no good idea, because the stage1 compiler is used. the stage2 compiler is unusable: Cheers Christian -bash-3.00$ ghc/compiler/stage1/ghc-inplace --interactive ghc-6.4.2: not built for interactive use -bash-3.00$ ghc/compiler/stage2/ghc-inplace --interactive ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Segmentation Fault ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Duncan Coutts wrote: file /usr/lib/ghc-6.4.2/HSbase.o /usr/lib/ghc-6.4.2/HSbase.o: ELF 32-bit MSB relocatable, SPARC32PLUS, V8 + Required, version 1 (SYSV), not stripped I don't think that is my problem. Possibly my stage1 compiler isn't that bad (as it only lacked ghci support), whereas my stage2 compiler still has a problem because it is compiled with -threaded. Christian -bash-3.00$ file libraries/base/HSbase.o libraries/base/HSbase.o:ELF 32-bit MSB relocatable SPARC Version 1 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Building GHC 6.4.2 on Solaris 10 SPARC
Hi Florian, it seems, that you fall over the same problems I had under solaris. GHC-6.4.2 does not work under solaris, currently. I've build a binary distribution (without -threaded) that seems to work at least as good as the ghc-6.4.1 version did. You may try out: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/versions/ghc-6.4.2-sparc-sun-solaris2.tar.bz2 Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Christian Maeder wrote: I'm currently running the ghc-regression test (with stage1/ghc-inplace), but that does not look good (although it does not hang) here is the frustrating summary: OVERALL SUMMARY for test run started at Mon May 22 18:30:30 CEST 2006 1365 total tests, which gave rise to 4157 test cases, of which 0 caused framework failures 580 were skipped 3051 expected passes 51 expected failures 0 unexpected passes 475 unexpected failures Unexpected failures: 10queens(ghci) CPUTime001(ghci) Chan001(ghci) IOError001(normal,opt,prof,threaded) IOError002(ghci) MVar001(ghci,threaded) QSem001(ghci) QSemN001(ghci) SampleVar001(ghci) TH_bracket1(normal) TH_bracket2(normal) TH_bracket3(normal) TH_class1(normal) TH_dupdecl(normal) TH_fail(normal) TH_genEx(normal) TH_reifyDecl1(normal) TH_reifyType1(normal) TH_reifyType2(normal) TH_repE1(normal) TH_repE2(normal) TH_repE3(normal) TH_repGuard(normal) TH_repGuardOutput(normal) TH_repPatSig(normal) TH_repPrim(normal) TH_repPrimOutput(normal) TH_spliceDecl1(normal) TH_spliceDecl2(normal) TH_spliceDecl3(normal) TH_spliceDecl4(normal) TH_spliceE1(normal) TH_spliceE3(normal) TH_spliceE4(normal) TH_spliceE5(normal) TH_spliceExpr1(normal) TH_spliceInst(normal) TH_tuple1(normal) TH_where(normal) addr001(ghci) andre_monad(ghci) andy_cherry(ghci) arith001(ghci) arith002(ghci) arith003(ghci) arith004(ghci) arith005(ghci) arith006(ghci) arith007(ghci) arith008(ghci) arith009(ghci) arith010(ghci) arith011(ghci) arith012(ghci) arith013(ghci) arith014(ghci) arith015(ghci) arith016(ghci) arith017(ghci) arr001(ghci) arr002(ghci) arr003(ghci) arr004(ghci) arr005(ghci) arr006(ghci) arr007(ghci) arr008(ghci) arr009(ghci) arr010(ghci) arr011(ghci) arr012(ghci) arr013(ghci) arr014(ghci) arr015(ghci) arr016(normal,opt,ghci,threaded) arr017(ghci) arrowrun001(ghci) arrowrun002(ghci) arrowrun003(ghci) arrowrun004(ghci) barton-mangler-bug(normal,opt,prof,ghci,threaded) bits(ghci) cg001(ghci) cg002(ghci) cg003(ghci) cg004(ghci) cg005(ghci) cg006(ghci) cg007(ghci) cg008(ghci) cg009(ghci) cg010(ghci) cg011(ghci) cg012(ghci) cg013(ghci) cg014(ghci) cg015(ghci) cg016(ghci) cg017(ghci) cg018(ghci) cg019(ghci) cg020(ghci) cg021(ghci) cg022(ghci) cg024(ghci) cg025(ghci) cg026(ghci) cg027(ghci) cg028(ghci) cg031(ghci) cg032(ghci) cg033(ghci) cg034(ghci) cg035(ghci) cg036(ghci) cg037(ghci) cg038(ghci) cg039(ghci) cg040(ghci) cg043(ghci) cg044(ghci) cg045(ghci) cg046(ghci) cg047(ghci) cg048(ghci) cg049(ghci) cg050(ghci) cg051(ghci) cg053(ghci) cg054(ghci) cg055(ghci) cg056(ghci) char001(ghci) char002(ghci) cholewo-eval(ghci) church(ghci) conc001(ghci) conc002(ghci) conc003(ghci) conc006(ghci) conc007(ghci) conc008(ghci) conc009(ghci) conc010(ghci) conc012(ghci) conc013(ghci) conc014(ghci) conc015(ghci) conc016(ghci) conc017(ghci) conc018(ghci) conc019(ghci) conc020(ghci) conc022(ghci) conc023(ghci) conc024(ghci) conc025(ghci) conc026(ghci) conc027(ghci) conc028(ghci) conc029(ghci) conc030(ghci) conc032(ghci) conc035(ghci) conc041(ghci) conc042(ghci) conc043(ghci) conc044(ghci) conc045(ghci) conc046(ghci) conc049(ghci) conc051(ghci,ghci) conc052(ghci) conc055(ghci) concprog001(ghci) currentDirectory001(ghci) cvh_unboxing(ghci) datatype(ghci) diffArray001(ghci) directory001(ghci) doesDirectoryExist001(ghci) drvrun001(ghci) drvrun002(ghci) drvrun003(ghci) drvrun004(ghci) drvrun005(ghci) drvrun006(ghci) drvrun007(ghci) drvrun008(ghci) drvrun009(ghci) drvrun010(ghci) drvrun011(ghci) drvrun012(ghci) drvrun013(ghci) drvrun014(ghci) drvrun015(ghci) drvrun016(ghci) drvrun017(ghci) drvrun018(ghci) dsrun001(ghci) dsrun002(ghci) dsrun003(ghci) dsrun004(ghci) dsrun005(ghci) dsrun006(ghci) dsrun007(ghci) dsrun008(ghci) dsrun009(ghci) dsrun010(ghci) dsrun011(ghci) dsrun012(ghci) dsrun013(ghci) dynamic001(ghci) dynamic002(ghci) echo001(ghci) enum01(ghci) enum02(ghci) enum03(ghci) exceptions001(ghci) exceptions002(ghci) exitWith001(ghci) ext1(ghci) fast2haskell(ghci) fed001(ghci) ffi003(ghci) ffi004(normal,opt,prof,ghci,threaded) ffi006(ghci) ffi007(ghci) ffi008(ghci) ffi009(normal,opt,prof,ghci,threaded) ffi010(ghci) ffi011(ghci) ffi013(ghci) fileexist01(ghci) finalization001(ghci) foldTree(ghci) forkprocess01(ghci) freeNames(ghci) fun_insts(ghci
Re: 6.4.2 under solaris
Simon Marlow wrote: I've fixed the cause of the hangs on Solaris, I believe. Yes, hanging is gone, but the binary segfaults now immediately (with hello.hs) Also, the ctime_r() and -lrt problems are both fixed. Only the -lrt problem is fixed. I'd be interested to know if it works for you, and if you could do a testsuite run too that would be great. I'm currently running the ghc-regression test (with stage1/ghc-inplace), but that does not look good (although it does not hang) Christian -bash-3.00$ ldd /local/home/maeder/ghc-6.4.3-pre/ghc/compiler/stage1/ghc-6.4.2 libdl.so.1 =/lib/libdl.so.1 libm.so.2 = /usr/local/lib/libm.so.2 libgmp.so.3 = /usr/local/lib/libgmp.so.3 libc.so.1 = /lib/libc.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 -bash-3.00$ ldd /local/home/maeder/ghc-6.4.3-pre/ghc/compiler/stage2/ghc-6.4.2 librt.so.1 =/lib/librt.so.1 libreadline.so.5 = /usr/local/lib/libreadline.so.5 libncurses.so.5 = /usr/local/lib/libncurses.so.5 libdl.so.1 =/lib/libdl.so.1 libm.so.2 = /usr/local/lib/libm.so.2 libgmp.so.3 = /usr/local/lib/libgmp.so.3 libpthread.so.1 = /lib/libpthread.so.1 libc.so.1 = /lib/libc.so.1 libaio.so.1 = /lib/libaio.so.1 libmd5.so.1 = /lib/libmd5.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-280R/lib/libmd5_psr.so.1 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote: I've fixed the cause of the hangs on Solaris, I believe. Also, the ctime_r() and -lrt problems are both fixed. If you grab the ghc-6-4-branch from CVS you'll get the code with these fixes. This problem still exists: RtsUtils.c: In function 'time_str': RtsUtils.c:197: error: too few arguments to function 'ctime_r' gmake[3]: *** [RtsUtils.p_o] Error 1 gmake[2]: *** [all] Error 1 I'll switch of HAVE_CTIME_R in ghc/includes/ghcautoconf.h and continue Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote: I've fixed the cause of the hangs on Solaris, I believe. Also, the ctime_r() and -lrt problems are both fixed. If you grab the ghc-6-4-branch from CVS you'll get the code with these fixes. I'd be interested to know if it works for you, and if you could do a testsuite run too that would be great. Yes, I've started the job. Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote: In GHC 6.4.2, the stage 2 compiler is built with -threaded, this is a change from previous versions. If -threaded isn't working properly, then the stage 2 compiler will be affected - that seems to be the case on Solaris. To get going, you could just disable -threaded in stage 2 (see ghc/compiler/Makefile). Right, without -threaded I was able to create a useable compiler. My binary distribution can be found at: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/versions/ghc-6.4.2-sparc-sun-solaris2.tar.bz2 It does not include the ps-documentation (under share) and also not the OpenGL package (although I should be able to build it, but a minor configure error in GLUT stopped me to do so) The build was done under solaris 10 using gcc-4.0.3. The used libraries are as follows: bash-3.00$ ldd /local/home/maeder/ghc-6.4.2/lib/ghc-6.4.2/ghc-6.4.2 libreadline.so.5 = /usr/local/lib/libreadline.so.5 libncurses.so.5 = /usr/local/lib/libncurses.so.5 libdl.so.1 =/lib/libdl.so.1 libm.so.2 = /usr/local/lib/libm.so.2 libgmp.so.3 = /usr/local/lib/libgmp.so.3 libc.so.1 = /lib/libc.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Simon Marlow wrote:
The best way to proceed would be to run the testsuite with the stage 1
compiler. Grab the test suite from here:
http://www.haskell.org/ghc/dist/6.4.2/ghc-testsuite-6.4.2.tar.gz
unpack it into your 6.4.2 build tree, cd testsuite, make boot, cd
tests/ghc-regress, make 21 | tee log.
the timeout binary created by the stage1 compiler went to sleep (like
the stage2 compiler) after some tests. (the truss output was the same.)
I've attached the output at:
http://hackage.haskell.org/trac/ghc/ticket/752
Maybe array indexing is broken?
- arr003: Ix{Int}.index: Index (4) out of range ((1,3))
- arr007: Ix{Int}.index: Index (1) out of range ((1,0))
Trying to compile timeout.hs with ghc-6.4.1 ended with:
timeout.hs:14:33:
Module `System.Process.Internals' does not export `mkProcessHandle'
I've circumvented the ctime_r problem by commenting out
#define HAVE_CTIME_R 1
in ghc/includes/ghcautoconf.h
Maybe you could also add the square brackets to the top-level Makefile
around A-Z and a-z following tr for a future binary-dist. Also the
branch for GreenCard could be removed (it seems it was left over when
the directory was green-card)
Cheers Christian
P.S. I'll be away for the next 2 weeks
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Strafunski/overlapping instances in ghc-6.5
Christopher Brown wrote: Christian, Did you try the switch -fallow-overlapping-instances when compiling? Yes, but it doesn't seem to make much difference. Maybe a couple of more library files have not been translated with the above flag. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/3625 In fact I became a problem with a Show instance and ghc-6.5.20060211 Christian OMDoc/HetsDefs.hs:649:0: Overlapping instances for Show AllMaps arising from use of `GHC.Show.$dmshowList' at OMDoc/HetsDefs.hs:649:0 Matching instances: instance (Show a, Show b, Show c, Show d, Show e, Show f) = Show (a, b, c, d, e, f) -- Imported from GHC.Show instance [overlap ok] Show AllMaps -- Defined at OMDoc/HetsDefs.hs:649:0 In the expression: GHC.Show.$dmshowList In the definition of `showList': showList = GHC.Show.$dmshowList In the definition for method `showList' ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: overlapping instances in ghc-6.5
The attached 4 files compile with ghc-6.4.1 and fail with ghc-6.5.20060201 (see below). Also, if I delete the Int and Integer instances in Common/ATerm/Conversion.hs the error remains the same for ghc-6.5 whereas ghc-6.4.1 correctly complains about No instance for (ShATermConvertible Int) arising from use of `fromShATerm'' at Common/ATerm/ConvInstances.hs:39:25-36 (Common.Lib.Graph is basically the same as Data.Graph.Inductive.Tree) Cheers Christian ghc --make -no-recomp -fglasgow-exts -fallow-overlapping-instances Common/ATerm/ConvInstances.hs Chasing modules from: Common/ATerm/ConvInstances.hs [1 of 4] Compiling Common.ATerm.AbstractSyntax ( Common/ATerm/AbstractSyntax.hs, Common/ATerm/AbstractSyntax.o ) [2 of 4] Compiling Common.ATerm.Conversion ( Common/ATerm/Conversion.hs, Common/ATerm/Conversion.o ) [3 of 4] Compiling Common.Lib.Graph ( Common/Lib/Graph.hs, Common/Lib/Graph.o ) [4 of 4] Compiling Common.ATerm.ConvInstances ( Common/ATerm/ConvInstances.hs, Common/ATerm/ConvInstances.o ) Common/ATerm/ConvInstances.hs:31:0: Overlapping instances for Typeable (Common.Lib.Graph.Gr a b) arising from the superclasses of an instance declaration at Common/ATerm/ConvInstances.hs:31:0 Matching instances: instance (Typeable1 s, Typeable a) = Typeable (s a) -- Imported from Data.Typeable instance [overlap ok] (Typeable a, Typeable b) = Typeable (Common.Lib.Graph.Gr a b) -- Defined at Common/ATerm/ConvInstances.hs:26:0 In the instance declaration for `ShATermConvertible (Common.Lib.Graph.Gr a b)' Common.tgz Description: GNU Unix tar archive ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: object code blow up by optimization
Simon Peyton-Jones wrote:
Just to let you know, I can reproduce this problem nicely (thank you for
setting up the repro case). It turns out to be caused by the
simplifier's inlining policy which goes if not exponential then
something very like it. It's made dramatically worse by the fact that
$$ and + are left-associative. If you change them to right-assoc the
problem disappears I think.
Thanks, for looking into it. For our code bloat, related to the
ShATermConvertible instances, there are no associative operations. I've
included the basic class and a few instances that pose no problem until
very late in our final big binary (with many more instances).
Currently, I simply set -fvia-C -O0 in parts of our code and hope that
-optc-O1 helps a bit.
Cheers Christian
P.S. I've changed infixl to infixr
infixr 6
infixr 6 +
infixr 5 $$, $+$
Not much difference in code size but a bit faster compared to the
numbers I've posted before:
http://hackage.haskell.org/trac/ghc/ticket/490
Linking ...
real7m37.899s
user6m45.562s
sys 0m11.161s
[EMAIL PROTECTED]:~/haskell/examples ll a.out HasCASL/PrintLe.o
-rwxr-xr-x 1 maeder wimi 6468124 2006-01-26 19:48 a.out
-rw-r--r-- 1 maeder wimi 2010772 2006-01-26 19:46 HasCASL/PrintLe.o
{- |
Module : $Header: /repository/HetCATS/Common/ATerm/AbstractSyntax.hs,v 1.33 2006/01/20 13:27:46 2maeder Exp $
Copyright : (c) Klaus Lüttich, C. Maeder, Uni Bremen 2002-2006
License : similar to LGPL, see HetCATS/LICENSE.txt or LIZENZ.txt
Maintainer : [EMAIL PROTECTED]
Stability : provisional
Portability : non-portable(imports System.Mem.StableName and GHC.Prim)
data types and utilities for shared ATerms and the ATermTable
-}
module Common.ATerm.AbstractSyntax
(ShATerm(..),
ATermTable,
emptyATermTable,
addATerm,
getATerm, toReadonlyATT,
getTopIndex,
getATerm', setATerm', getShATerm,
Key(..), newATermTable, getKey, setKey, mkKey,
getATermByIndex1, str2Char, integer2Int
) where
import qualified Data.Map as Map
import qualified Data.IntMap as IntMap
import Data.Dynamic
import Data.Array
import System.Mem.StableName
import GHC.Prim
import qualified Data.List as List
import Data.Maybe
data ShATerm = ShAAppl String [Int] [Int]
| ShAList [Int][Int]
| ShAInt Integer [Int]
deriving (Eq, Ord)
data IntMap = Updateable !(IntMap.IntMap ShATerm)
| Readonly !(Array Int ShATerm)
empty :: IntMap
empty = Updateable $ IntMap.empty
insert :: Int - ShATerm - IntMap - IntMap
insert i s t = case t of
Updateable m - Updateable $ IntMap.insert i s m
_ - error ATerm.insert
find :: Int - IntMap - ShATerm
find i t = case t of
Updateable m - IntMap.findWithDefault (ShAInt (-1) []) i m
Readonly a - a ! i
data EqKey = EqKey (StableName ()) TypeRep deriving Eq
data Key = Key Int EqKey
mkKey :: Typeable a = a - IO Key
mkKey t = do
s - makeStableName t
return $ Key (hashStableName s) $ EqKey (unsafeCoerce# s) $ typeOf t
data ATermTable = ATT
(IntMap.IntMap [(EqKey, Int)])
!(Map.Map ShATerm Int) !IntMap Int
!(IntMap.IntMap [Dynamic])
toReadonlyATT :: ATermTable - ATermTable
toReadonlyATT (ATT h s t i dM) = ATT h s
(case t of
Updateable m - Readonly $ listArray (0, i) $ IntMap.elems m
_ - t ) i dM
emptyATermTable :: ATermTable
emptyATermTable = ATT IntMap.empty Map.empty empty (-1) IntMap.empty
newATermTable :: IO ATermTable
newATermTable = return $ emptyATermTable
addATermNoFullSharing :: ShATerm - ATermTable - (ATermTable, Int)
addATermNoFullSharing t (ATT h a_iDFM i_aDFM i1 dM) = let j = i1 + 1 in
(ATT h (Map.insert t j a_iDFM) (insert j t i_aDFM) j dM, j)
addATerm :: ShATerm - ATermTable - (ATermTable, Int)
addATerm t at@(ATT _ a_iDFM _ _ _) =
case Map.lookup t a_iDFM of
Nothing - addATermNoFullSharing t at
Just i - (at, i)
setKey :: Key - Int - ATermTable - IO (ATermTable, Int)
setKey (Key h e) i (ATT t s l m d) =
return (ATT (IntMap.insertWith (++) h [(e, i)] t) s l m d, i)
getKey :: Key - ATermTable - IO (Maybe Int)
getKey (Key h k) (ATT t _ _ _ _) =
return $ List.lookup k $ IntMap.findWithDefault [] h t
getATerm :: ATermTable - ShATerm
getATerm (ATT _ _ i_aFM i _) = find i i_aFM
getShATerm :: Int - ATermTable - ShATerm
getShATerm i (ATT _ _ i_aFM _ _) = find i i_aFM
getTopIndex :: ATermTable - Int
getTopIndex (ATT _ _ _ i _) = i
getATermByIndex1 :: Int - ATermTable - ATermTable
getATermByIndex1 i (ATT h a_iDFM i_aDFM _ dM) = ATT h a_iDFM i_aDFM i dM
getATerm' :: Typeable t = Int - ATermTable - Maybe t
getATerm' i (ATT _ _ _ _ dM) =
listToMaybe $ mapMaybe fromDynamic $ IntMap.findWithDefault [] i dM
setATerm' :: Typeable t = Int - t - ATermTable - ATermTable
setATerm' i t (ATT h a_iDFM i_aDFM m dM) =
ATT h a_iDFM i_aDFM m $ IntMap.insertWith (++) i [toDyn t] dM
-- | conversion of a string in double quotes to a character
str2Char :: String - Char
Re: object code blow up by optimization
Sorry, I forgot to save my changes. The numbers are much better with infixr: Linking ... real5m30.666s user4m56.950s sys 0m9.262s [EMAIL PROTECTED]:~/haskell/examples ll a.out HasCASL/PrintLe.o -rwxr-xr-x 1 maeder wimi 4812378 2006-01-26 20:01 a.out -rw-r--r-- 1 maeder wimi 139828 2006-01-26 19:58 HasCASL/PrintLe.o Christian Maeder wrote: P.S. I've changed infixl to infixr infixr 6 infixr 6 + infixr 5 $$, $+$ Not much difference in code size but a bit faster compared to the numbers I've posted before: http://hackage.haskell.org/trac/ghc/ticket/490 Linking ... real7m37.899s user6m45.562s sys 0m11.161s [EMAIL PROTECTED]:~/haskell/examples ll a.out HasCASL/PrintLe.o -rwxr-xr-x 1 maeder wimi 6468124 2006-01-26 19:48 a.out -rw-r--r-- 1 maeder wimi 2010772 2006-01-26 19:46 HasCASL/PrintLe.o ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: object code blow up by optimization
When I also swap the corresponding equations the code bloat comes back: above_ p _ Empty = p above_ Empty _ q = q beside_ p _ Empty = p beside_ Empty _ q = q Linking ... real7m10.727s user6m25.456s sys 0m10.698s [EMAIL PROTECTED]:~/haskell/examples ll a.out HasCASL/PrintLe.o -rwxr-xr-x 1 maeder wimi 6213885 2006-01-26 20:11 a.out -rw-r--r-- 1 maeder wimi 1762784 2006-01-26 20:09 HasCASL/PrintLe.o Christian Maeder wrote: Sorry, I forgot to save my changes. The numbers are much better with infixr: Linking ... real5m30.666s user4m56.950s sys 0m9.262s [EMAIL PROTECTED]:~/haskell/examples ll a.out HasCASL/PrintLe.o -rwxr-xr-x 1 maeder wimi 4812378 2006-01-26 20:01 a.out -rw-r--r-- 1 maeder wimi 139828 2006-01-26 19:58 HasCASL/PrintLe.o ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Space leak
Tomasz Zielonka wrote: On Tue, Dec 27, 2005 at 08:12:20PM +0100, Christian Maeder wrote: Already the following bit exhibits unexpected memory consumption: main = mapM_ print $ take (n * 5) $ drop (n * 3) [1..] n = 10 I think it's the (succ (succ (succ ...))) thunk. When you change it to [1..] there is no space leak - here every produced element must be examined before producing the next list node or []. ok, I could also fix the space leak by defining my own iterate function: myiterate :: (a - a) - a - [a] myiterate f a = a : (myiter f $! f a) main = mapM_ print $ take (n * 5) $ drop (n * 3) $ myiterate succ 1 is also ok. The next problem occurs when I try to use splitAt as in the original DNA example: main = do let (s1, s2) = splitAt (n * 3) $ myiterate succ 1 mapM_ print s1 mapM_ print $ take (n * 5) s2 The above code leaks space! But main = do let s1 = take (n * 3) $ myiterate succ 1 s2 = drop (n * 3) $ myiterate succ 1 mapM_ print s1 mapM_ print $ take (n * 5) s2 does not leak, as long as it is compiled without optimization. (Eliminating the CSE myiterate succ 1 makes it leak.) Could optimization be improved? Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Space leak
Chris Kuklewicz wrote: Greg Buchholz wrote: True. But there are some tests like fasta that appear to have a laziness induced space leak that presumably could be fixed. http://shootout.alioth.debian.org/benchmark.php?test=fastalang=all Already the following bit exhibits unexpected memory consumption: main = mapM_ print $ take (n * 5) $ drop (n * 3) [1..] n = 10 Dropping the elements is more expensive than printing them. Somehow the dropped elements are kept in memory. With profiling (compiled with -prof -auto-all and called with +RTS -p) the memory consumption is not reported, at least the total alloc bytes are not much different with and without the $ drop (n * 3) part. Only my /usr/bin/time -v shows: Minor (reclaiming a frame) page faults: 4745 for the code above (compiled with optimization) and about ten times less without drop. Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in GHC type system
Hi Baltasar,
maybe it's GHC's inliner. See
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc
and the russel example is similar enough to yours. (I have not
checked, though.)
I apologize, again, for the wrong spelling, It must be Russell with
two l!
Cheers Christian
Baltasar Trancon y Widemann wrote:
Hi,
I have found a three-line program that will cause recent GHC type
checker to diverge. The program is admittedly pathological, so here's
the story:
As part of my PhD thesis I am investigating a backend virtual machine
for functional programs where
* beta reduction is explicit,
* consequently, (-) is a free type constructor that can be mixed with
(*) and (+) in arbitrary mutual recursion.
In such a system, is possible to define a well-typed, effective Y
combinator. Of course, the reduction strategy has to be hand-coded
explicitly. Since the lazy strategy is not the worst choice, I tried to
abuse the Haskell type system for an experiment:
y f = w w
where w x = f (x x)
This is, naturally, rejected by the type checker because of recursive
type equations of the form:
t = t - u
But one can put a datatype constructor in between:
newtype Auto a = { self :: Auto a - a }
y f = self w w
where w = Auto (\x - f (self x x))
Sadly, I cannot load this program into GHCi or compile it with GHC. HUGS
(as of November 2003) has no such problem, and computes the factorial
function:
let fac f x = if x == 0 then 1 else x * f (x - 1)
in y fac 10
Technical details:
x86 PC with AMD Athlon XP CPU
SuSE 9.0 Linux with kernel 2.6.10
ghc-6.2.2
also observed for 6.4 on a different machine
The log of `ghc -v -C Ups.hs` is attached. The compiler hangs after the
*** Simplify:
line, slowly consuming unbounded amounts of heap (presumably due to a
divergent type unification). The last two log lines are issued only
after a ^C signal. If 'newtype' is replaced by 'data', one more line of
statistics
Result size = 17
is issued before the compiler hangs, too.
Greetings,
Baltasar Trancon y Widemann
module Ups where
-- y f = w w where w x = f (x x)
newtype Auto a = Auto {self :: Auto a - a}
y f = self w w
where w = Auto (\x - f (self x x))
Glasgow Haskell Compiler, Version 6.2.2, for Haskell 98, compiled by GHC
version 5.04.3
Using package config file: /usr/local/lib/ghc-6.2.2/package.conf
Packages
Package
{name = data,
auto = False,
import_dirs = [/usr/local/lib/ghc-6.2.2/hslibs-imports/data],
source_dirs = [],
library_dirs = [/usr/local/lib/ghc-6.2.2],
hs_libraries = [HSdata],
extra_libraries = [],
include_dirs = [],
c_includes = [],
package_deps = [haskell98, lang, util],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = rts,
auto = False,
import_dirs = [],
source_dirs = [],
library_dirs = [/usr/local/lib/ghc-6.2.2],
hs_libraries = [HSrts],
extra_libraries = [m, gmp, dl],
include_dirs = [/usr/local/lib/ghc-6.2.2/include],
c_includes = [Stg.h],
package_deps = [],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts =
[-u,
GHCziBase_Izh_static_info,
-u,
GHCziBase_Czh_static_info,
-u,
GHCziFloat_Fzh_static_info,
-u,
GHCziFloat_Dzh_static_info,
-u,
GHCziPtr_Ptr_static_info,
-u,
GHCziWord_Wzh_static_info,
-u,
GHCziInt_I8zh_static_info,
-u,
GHCziInt_I16zh_static_info,
-u,
GHCziInt_I32zh_static_info,
-u,
GHCziInt_I64zh_static_info,
-u,
GHCziWord_W8zh_static_info,
-u,
GHCziWord_W16zh_static_info,
-u,
GHCziWord_W32zh_static_info,
-u,
GHCziWord_W64zh_static_info,
-u,
GHCziStable_StablePtr_static_info,
-u,
GHCziBase_Izh_con_info,
-u,
GHCziBase_Czh_con_info,
-u,
GHCziFloat_Fzh_con_info,
-u,
GHCziFloat_Dzh_con_info,
-u,
GHCziPtr_Ptr_con_info,
-u,
GHCziPtr_FunPtr_con_info,
-u,
GHCziStable_StablePtr_con_info,
-u,
GHCziBase_False_closure,
-u,
GHCziBase_True_closure,
-u,
GHCziPack_unpackCString_closure,
-u,
GHCziIOBase_stackOverflow_closure,
-u,
GHCziIOBase_heapOverflow_closure,
-u,
GHCziIOBase_NonTermination_closure,
-u,
GHCziIOBase_BlockedOnDeadMVar_closure,
-u,
GHCziIOBase_Deadlock_closure,
-u,
GHCziWeak_runFinalizzerBatch_closure,
-u,
__stginit_Prelude],
framework_dirs = [],
extra_frameworks = []}
Package
{name = base,
Re: GHC-6.4.1 much slower than GHC-6.4
Mirko Rahn wrote: I've found a way to speed up your code for ghc-6.4.1. Replace the where with a case in PCP.Suc.suc_rules (see below) Okay, thanks, that works fine. Yes, It's even quite fast without optimization (I did not check with ghc-6.4, though) (Maybe that is a good idea in PCP.Rules.Suc, too) Seems to be unimportant whether the replacement is done in PCP.Rules.Suc Yes, it is unimportant. Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4 profiling bug
this bug is fixed in ghc-6.4.1 (see my attached profile) Christian Daniel Fischer wrote: Hello, I have encountered some strange behaviour with David Tweeds LaTeX-preprocessor (slightly modified code attached). When I compile it for profiling (-prof -auto-all) and run it on a .tex-file containing some math-environment, it segfaults. Files without math are processed properly. All .tex-files are processed correctly (except for the weaknesses inherent in the code) when the code is compiled not for profiling or with ghc-6.2.2 -prof -auto-all, so I'm rather convinced, it's a 6.4-bug. If you could explain this behaviour, I'd be grateful. Cheers, Daniel Fischer ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs Wed Sep 21 17:23 2005 Time and Allocation Profiling Report (Final) lpp +RTS -p -RTS Triv total time =0.00 secs (0 ticks @ 20 ms) total alloc = 112,836 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc trieLkpTrie 0.08.9 relate Trie 0.0 14.1 normTrie LPPTries 0.02.6 mathTrie LPPTries 0.06.1 lineCatTrieLPPTries 0.06.2 envNames LPPTries 0.04.7 CAFGHC.Handle 0.07.8 writeOutFile Main 0.0 17.9 main Main 0.0 12.5 format Main 0.02.3 expEnd Main 0.01.0 expBegin Main 0.01.8 doMacs Main 0.01.1 concRevMain 0.02.0 break' Main 0.06.5 individualinherited COST CENTRE MODULE no.entries %time %alloc %time %alloc MAIN MAIN 1 0 0.00.0 0.0 100.0 CAF Main 172 3 0.00.1 0.0 71.6 formParas Main 181 1 0.01.0 0.03.0 lineType Main 185 7 0.00.0 0.02.0 trieLkp Trie 186 22 0.01.0 0.02.0 relate Trie 201 65 0.01.1 0.01.1 con2tag_RelRes# Trie 200 65 0.00.0 0.00.0 con2tag_LineCat# LPPTries 184 46 0.00.0 0.00.0 main Main 178 1 0.0 12.5 0.0 68.4 expContSeqsNSymbols Main 182 1 0.00.5 0.0 35.7 doMacs Main 192 13 0.01.1 0.0 29.3 concRev Main 198 19 0.02.0 0.02.0 break' Main 193 60 0.06.5 0.0 26.2 trieLkpTrie 194 66 0.07.5 0.0 19.6 relateTrie 197 582 0.0 12.2 0.0 12.2 con2tag_RelRes# Trie 196 582 0.00.0 0.00.0 expCSMain 187 7 0.01.0 0.05.5 expEnd Main 209 2 0.01.0 0.01.0 expBeginMain 202 2 0.01.8 0.02.7 getAbbrTrie 203 2 0.00.0 0.00.9 compAbbr Trie
Re: Compiling ghc 6.4 with ghc 5.04.3
If that's any confort? I get a similar error (with ghc-5.04.2 and the ghc-6.4.1.20050517 sources) Cheers Christian stage1/nativeGen/AsmCodeGen.o(.text+0xc2b6): In function `smsr_ret': : undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o(.text+0x8472): In function `smI1_dflt': : undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o(.text+0x85c8): In function `smI8_1_alt': : undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o(.text+0x85d0): In function `smIa_1_alt': : undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o(.text+0x88a0): In function `smif_1_alt': : undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o(.text+0x88a8): more undefined references to `GHCziP rim_zdwZ2H_entry' follow collect2: ld returned 1 exit status Axel Simon wrote: Hi, I'm trying to bootstrap 6.4 with a binary 5.04.3 on Debian Linux. I get the following during linking: stage1/nativeGen/AsmCodeGen.o: In function `slZu_dflt': stage1/nativeGen/AsmCodeGen.o(.text+0x7ebe): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slZB_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x7ffc): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slZD_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x8004): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slAj_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x82bc): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slZL_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x82c4): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o(.text+0xb0bc): more undefined references to `GHCziPrim_zdwZ2H_entry' follow collect2: ld returned 1 exit status ghc: 4414788 bytes, 2 GCs, 155432/155432 avg/max bytes residency (1 samples), 5M in use, 0.01 INIT (0.00 elapsed), 0.01 MUT (10.98 elapsed), 0.02 GC (0.02 elapsed) :ghc make[2]: *** [stage1/ghc-6.4] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/part3/cur/as49/gonzo/source/ghc-6.4/ghc' make: *** [build] Error 1 Can anyone tell me a) if 6.4 is supposed to compile with 5.04.3. b) if not, via what other version can I get from 5.04.3 to 6.4. c) if there is a newer binary package of ghc that works with glibc 2.2 Thanks, Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Compiling ghc 6.4.1.20050705 with ghc 5.04.2
Axel Simon wrote: I'm using gcc 2.95.4, maybe that's the oddity. ld is GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux I have: gcc (GCC) 3.3.4 (pre 3.3.5 20040809) GNU ld version 2.15.91.0.2 20040727 (SuSE Linux) and my config.log and gmake.log files can be found at: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/ghc-6.4.1.20050705-gmake-with-ghc-5.04.2.config.log http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/ghc-6.4.1.20050705-gmake-with-ghc-5.04.2.log ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building ghc-6.4-branch on Solaris
Axel Simon wrote: Warning: retaining unknown function `getgrnam_r' in output from C compiler I haven't overridden anything in build.mk, so I assume SplitObjs=YES. When would I observe these warnings? the first time when the inplace compiler translates System/Posix/Resour ce.hs I just see that it only happened with gcc-2.95.3 and not with gcc-3.4.4 Christian rm -f System/Posix/Resource.o; if [ ! -d System/Posix/Resource_split ]; then mkdi r System/Posix/Resource_split; else /usr/local/bin/find System/Posix/Resource_spl it -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -Iinclude -ignore-package unix -O -Rghc- timing -fgenerics -package base -fgenerics -split-objs-c System/Posix/Resour ce.hs -o System/Posix/Resource.o -ohi System/Posix/Resource.hi Warning: retaining unknown function `getpwuid_r' in output from C compiler Warning: retaining unknown function `getpwnam_r' in output from C compiler Warning: retaining unknown function `getgrgid_r' in output from C compiler Warning: retaining unknown function `getgrnam_r' in output from C compiler ghc: 78796436 bytes, 14 GCs, 2716618/5477444 avg/max bytes residency (3 samples ), 19M in use, 0.00 INIT (0.00 elapsed), 1.12 MUT (8.16 elapsed), 0.41 GC (0.66 e lapsed) :ghc ( cd System/Posix/Resource_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /home/maeder/bin/ld -r -x -o ../Resource.o ld.script; ); ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building ghc-6.4-branch on Solaris
Axel Simon wrote: gcc -O -Wall -I../../../ghc/includes -I../../../ghc/rts -I/core/include-c env.c -o env.p_o cc1: /core/include: Not a directory My gcc does not complain about that missing directory. I was able to create a working installation under solaris with: ./configure --disable-opengl --disable-glut --disable-openal The directory /core/include doesn't exist, what the makefile says is ./hslibs/posix/cbits/Makefile: -I$(GHC_LIB_DIR)/core/include however, I can't find GHC_LIB_DIR in any of the config files. Is it dead? I have the same situation and it was no problem. But I cannot answer your question about GHC_LIB_DIR. Christian P.S. if I compile the ghc without SplitObjs=NO in mk/build.mk I get annoying but probably harmless warnings during compilations: Warning: retaining unknown function `getpwuid_r' in output from C compiler Warning: retaining unknown function `getpwnam_r' in output from C compiler Warning: retaining unknown function `getgrgid_r' in output from C compiler Warning: retaining unknown function `getgrnam_r' in output from C compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1198393 ] Program aborts with segmentation fault when profiling used
Hi, I also have (a rather large) program (not included) that segfaults when compiled with profiling. I use the ghc-6.4 linux binary distribution from the web. It is not even necessary to call the program with +RTS -p -RTS. There is no problem with ghc-6.2.2, except that the old version uses its own copy of the fgl, Data.Map and Data.Set. If I let my Map and Set module reexport the ghc-6.4 library modules Data.Map and Data.Set then the program does not terminate if compiled without profiling and without optimization (with optimization it terminates, profiling segfaults in all cases). Any idea what I should do (and is not too time consuming)? Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.4.20050220: panic! eval_data2tag...
This happens when partially recompiling with -O (I thing I've send a
similar bug-report that was kept in the moderator's queue because it was
to slightly too large - over 40K )
Christian
Thomas Hallgren wrote:
Hi,
I managed to distill my program into to the following small example that
still exhibits the problem:
module Bug where
data S e = A | B | C | D | E | F | G | H | I deriving (Eq)
newtype R = T (S R) deriving (Eq)
The output from 'ghc -c -O Bug.hs' is:
ghc-6.4.20050220: panic! (the `impossible' happened, GHC version
6.4.20050220):
eval_data2tag
GHCziPrim.dataToTagzh{(w) v 95f}
@ (Bug.S{tc r14v} recntBug.R{tc r14r})
(__coerce (Bug.S{tc r14v} recntBug.R{tc r14r}) a{v s1Cm})
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.4.20050220: panic! eval_data2tag...
Simon Peyton-Jones wrote:
Should be fixed now -- can you try with the HEAD?
yes, it work now! Thanks
Christian
| ghc-6.4.20050220: panic! (the `impossible' happened, GHC version
| 6.4.20050220):
| eval_data2tag
| GHCziPrim.dataToTagzh{(w) v 95f}
| @ (Bug.S{tc r14v} recntBug.R{tc r14r})
| (__coerce (Bug.S{tc r14v} recntBug.R{tc r14r}) a{v s1Cm})
|
| Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: unused import not always reported
Despite some changes in various parts of the cvs tree, the bug is still reproducable: do the following (on a linux machine with a bash): export CVSROOT=:pserver:[EMAIL PROTECTED]:/repository cvs checkout uni cvs checkout HetCATS cd uni ./configure make boot make all cd ../HetCATS make make hetdg ./testUnusedImport.sh I'll be in the weekend now. Cheers Christian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
unused import not always reported
How is it possible that an unused import warning is not always emitted? Below I get a warning when I recompile everything, but no warning when I only recompile the Main module (that contains the unused import). In fact Main.hi changes. Cheers Christian Compiling GUI.ConvertDevToAbstractGraph ( GUI/ConvertDevToAbstractGraph.hs, GUI/ConvertDevToAbstractGraph.o ) Compiling Main ( GUI/hetdg.hs, GUI/hetdg.o ) GUI/hetdg.hs:1: Warning: Module `Data.IORef' is imported, but nothing from it is used (except perhaps to re-export instances visible in `Data.IORef') ghc: linking ... [EMAIL PROTECTED]:~/haskell/HetCATS ll GUI/Main.hi [EMAIL PROTECTED]:~/haskell/HetCATS ll GUI/Main.hi -rw-r--r--1 maeder wimi 5272 2003-03-21 16:47 GUI/Main.hi [EMAIL PROTECTED]:~/haskell/HetCATS rm GUI/Main.hi [omitted the list of Skipping after ghc --make -fglasgow-exts -fwarn-unused-imports ...] Skipping GUI.ConvertDevToAbstractGraph ( GUI/ConvertDevToAbstractGraph.hs, GUI/ConvertDevToAbstractGraph.o ) Compiling Main ( GUI/hetdg.hs, GUI/hetdg.o ) ghc: linking ... [EMAIL PROTECTED]:~/haskell/HetCATS ll GUI/Main.hi -rw-r--r--1 maeder wimi 5840 2003-03-21 16:48 GUI/Main.hi ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
dead link
On http://www.haskell.org/ghc/ the link to the Users' Guide is missing. Cheers Christian GHC Features This is a summary of GHC's main features. They are all described in more detail in the Users' Guide. The requested URL /ghc/docs/latest/html/users_guide/book-users-guide.html was not found on this server. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc/ghci version 5.04 under SunOS 5.8
Hi, ghci seems to use a lot of cpu-time without doing something at the prompt. Furthermore ghc -O2 ... still creates binaries that yield a Bus Error with gcc-3.1. Can't that be fixed? Cheers, Christian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
broken link
on http://haskell.org/ghc/docs/latest/set/book-hslibs.html The requested URL /ghc/docs/latest/set/book-hslibs.html was not found on this server. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
typo in error message: duplicate the
The following error message just contains a typo before existential context. Cheers Christian Compiling Syntax ( Syntax.hs, ./Syntax.o ) Syntax.hs:56: Could not deduce (Institution id1 basic_spec1 local_env1, Institution id basic_spec local_env) from the context (Syntax id basic_spec, Syntax id1 basic_spec1) Probable fix: Add (Institution id1 basic_spec1 local_env1, Institution id basic_spec local_env) to the the existential context of a data constructor ^^^ arising from use of `basic_analysis' at Syntax.hs:56 In the definition of `analyse': (basic_analysis l1 b1, basic_analysis l2 b2) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Pretty.lhs
Hi, in our (latest) installation (ghc-5.02.3 on solaris) the module Pretty (from the package text) did not export Style-related functions due to an (old/wrong) interface file ../imports/text/Pretty.hi (with size 10909). When translating Pretty.lhs ourselves it seems to work correctly (and the size of Pretty.hi is only 2479). Regards Christian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
