- Glasgow-haskell-users

making 6.6-candidate
by Serge D. Mechveliani 04 Sep '06

04 Sep '06

Dear GHC team, I am trying to make ghc-6.5.20060831 from source by ghc-6.4.1 under Linux, i386-unknown. It has got to /home/mechvel/ghc/6.4.1/inst/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -i../compat -ignore-package Cabal -funbox-strict-fields -c parser/Lexer.hs -o stage1/parser/Lexer.o -ohi stage1/parser/Lexer.hi and looped at this point during about 50 minutes, without any report. Finally, it was done, and now, I hope, it will make the rest. But I wonder whether this loop is suspicious. The command `top' has been showing CPU %MEM 20633 mechvel ... 99.9 2.1 ... ghc-asm for 50 minutes (`as' is assembly, and who is ghc-asm, I wonder). The machine is i-686, 512 Mb RAM, vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 3 cpu MHz : 601.371 cache size : 256 KB autoreconf has reported it could not find this and that, but it is, probably, all right (?) config.log is --------------------------------------- ... It was created by The Glorious Glasgow Haskell Compilation System configure 6.5.20060831, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --prefix=/home/mechvel/ghc/6.6.pre/inst uname -m = i686 uname -r = 2.4.27-2-686-smp uname -s = Linux uname -v = #1 SMP Mon May 16 16:55:31 JST 2005 ... ------------------------------------ Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

FW: [Haskell-cafe] Haskell for hp-ux (ia64)
by Green Bryan - bgreen 02 Sep '06

02 Sep '06

This bounced so I am resending it..... -----Original Message----- From: Green Bryan - bgreen Sent: Fri 9/1/2006 7:08 AM To: glasgow-haskell-users(a)haskell.org Subject: FW: [Haskell-cafe] Haskell for hp-ux (ia64) Greetings, So, If I understand correctly I need to find a ia64 build and copy the HC files files over a fresh install. Is that correct? Bryan Green -----Original Message----- From: Donald Bruce Stewart [mailto:dons@cse.unsw.edu.au] Sent: Thu 8/31/2006 7:07 PM To: Green Bryan - bgreen Subject: Re: [Haskell-cafe] Haskell for hp-ux (ia64) Bryan.Green: > > Does anyone know of a binary for hp-ux (ia64)? I have > permission from my company to try and go forward with using > Haskell for development with my team. But, we are running > hp-ux on a 16 processor(ia64) box and I can't find a build > for it. There have been ports to the ia64/linux platform. But I've not heard of anything for hp-ux. You'll have to follow the porting guide: http://www.haskell.org/ghc/docs/latest/html/building/index.html http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html You can get further advice on glasgow-haskell-users(a)haskell.org, as you proceed with the port. Cheers, Don ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. *************************************************************************

2 1

FW: [GHC] #729 Build system uses wrong version of include files.
by Simon Marlow 01 Sep '06

01 Sep '06

Shaun Lippy reports that #729 is happening for him too (I previously closed this bug assuming driver error). Can someone on MacOS X reproduce and possibly diagnose this please? Cheers, Simon ________________________________ From: Shaun Lippy [mailto:shaunlippy@gmail.com] Sent: 30 August 2006 05:22 To: simonmarhaskell(a)gmail.com Subject: Re: [GHC] #729 Build system uses wrong version of include files. Hi Simon - I am seeing this error as well, building for Tiger. I simply ran 'sudo port install ghc'. This proceeded to go get the GMP libs, built them successfully; it then gets the Perl that it needs, successfully builds that; it gets something called Readline, successfully builds that. Then it gets GHC and starts to build that; it is in stage 1 build. Here's the entire output of the sudo command mentioned: adsl-64-109-253-64:~ slippy$ sudo port install ghc Password: ---> Fetching gmp ---> Attempting to fetch gmp-4.2.1.tar.bz2 from ftp://ftp.gnu.org/gnu/gmp ---> Verifying checksum(s) for gmp ---> Extracting gmp ---> Configuring gmp ---> Building gmp with target all ---> Staging gmp into destroot running ranlib on static libraries ---> Installing gmp 4.2.1_4+test ---> Activating gmp 4.2.1_4+test ---> Cleaning gmp ---> Fetching perl5.8 ---> Attempting to fetch perl-5.8.8.tar.bz2 from http://www.cpan.org/src/5.0/ ---> Verifying checksum(s) for perl5.8 ---> Extracting perl5.8 ---> Applying patches to perl5.8 ---> Configuring perl5.8 ---> Building perl5.8 with target all ---> Staging perl5.8 into destroot ---> Installing perl5.8 5.8.8_0+darwin_8 ---> Activating perl5.8 5.8.8_0+darwin_8 ---> Cleaning perl5.8 ---> Fetching readline ---> Attempting to fetch readline51-001 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/ ---> Attempting to fetch readline51-002 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/ ---> Attempting to fetch readline51-003 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/ ---> Attempting to fetch readline51-004 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/ ---> Attempting to fetch readline-5.1.tar.gz from ftp://ftp.gnu.org/gnu/readline ---> Verifying checksum(s) for readline ---> Extracting readline ---> Applying patches to readline ---> Configuring readline ---> Building readline with target all ---> Staging readline into destroot ---> Installing readline 5.1.004_0 ---> Activating readline 5.1.004_0 ---> Cleaning readline ---> Fetching ghc ---> Attempting to fetch ghc-6.4.2-src.tar.bz2 from http://www.haskell.org/ghc//dist/6.4.2/ ---> Attempting to fetch happy-1.15-src.tar.gz from http://www.haskell.org/happy/dist/1.15 ---> Attempting to fetch ghc-6.4-darwin-bootstrap-tiger.tar.bz2 from http://www.haskell.org/ghc//dist/6.4/MacOSX/ ---> Verifying checksum(s) for ghc ---> Extracting ghc ---> Applying patches to ghc ---> Configuring ghc ---> Building ghc with target all Error: Target com.apple.build returned: shell command "DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make all" returned error 2 Command output: ------------------------------------------------------------------------ /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rs ync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include " hschooks.h"' -i../lib/compat -ignore-package Cabal -c basicTypes/OccName.lhs-boot -o stage1/basicTypes/OccName.o-boot -ohi stage1/basicTypes/OccName.hi-boot <<ghc: 28500036 bytes, 8 GCs, 2406298/4716080 avg/max bytes residency (2 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.14 MUT (0.27 elapsed), 0.14 GC (0.21 elapsed) :ghc>> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rs ync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include " hschooks.h"' -i../lib/compat -ignore-package Cabal -c basicTypes/Module.lhs-boot -o stage1/basicTypes/Module.o-boot -ohi stage1/basicTypes/Module.hi-boot <<ghc: 28498768 bytes, 8 GCs, 2406274/4716080 avg/max bytes residency (2 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.14 MUT (0.35 elapsed), 0.13 GC (0.18 elapsed) :ghc>> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rs ync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include " hschooks.h"' -i../lib/compat -ignore-package Cabal -c utils/PrimPacked.lhs -o stage1/utils/PrimPacked.o -ohi stage1/utils/PrimPacked.hi utils/PrimPacked.lhs:250:0: Warning: foreign declaration uses deprecated non-standard syntax utils/PrimPacked.lhs:254:0: Warning: foreign declaration uses deprecated non-standard syntax utils/PrimPacked.lhs:257:0: Warning: foreign declaration uses deprecated non-standard syntax utils/PrimPacked.lhs:260:0: Warning: foreign declaration uses deprecated non-standard syntax utils/PrimPacked.lhs:263:0: Warning: foreign declaration uses deprecated non-standard syntax In file included from /tmp/ghc16873.hc:5: /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rs ync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc- 6.4/include/HsUnix.h: In function `__hsunix_rtldNext': /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rs ync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc- 6.4/include/HsUnix.h:103: error: `RTLD_NEXT' undeclared (first use in this function) /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rs ync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc- 6.4/include/HsUnix.h:103: error: (Each undeclared identifier is reported only once /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rs ync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc- 6.4/include/HsUnix.h:103: error: for each function it appears in.) <<ghc: 55036388 bytes, 12 GCs, 3366910/6779028 avg/max bytes residency (3 samples), 17M in use, 0.00 INIT (0.00 elapsed), 0.40 MUT (1.13 elapsed), 0.33 GC (0.41 elapsed) :ghc>> make[2]: *** [stage1/utils/PrimPacked.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 Error: Status 1 encountered during processing. -- Shaun Lippy slippy(a)acm.org The things that we fear are a weapon to be held against us.

2 1

tickets that important for me
by Bulat Ziganshin 01 Sep '06

01 Sep '06

Hello Bulat, Can you please fix the following problems in GHC 6.6.* (uncertainly in 6.6, 6.6.1 will be also good enough) http://hackage.haskell.org/trac/ghc/ticket/814 http://hackage.haskell.org/trac/ghc/ticket/637 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 3

RE: Coverage Condition woes
by Simon Peyton-Jones 31 Aug '06

31 Aug '06

| The following code (coming from Vertigo), which compiles OK with | ghc-6.4.2, is rejected by ghc in HEAD (from this week-end) : | | data Range = Range String Float Float Float | | class AsRange nrs ns | nrs -> ns where | asRange :: nrs -> (ns, [Range]) | | instance (AsRange rsa nsa, AsRange rsb nsb) | => AsRange (rsa, rsb) (nsa, nsb) where | asRange (a, b) = ((nsa, nsb), rsa++rsb) | where | (nsa, rsa) = asRange a | (nsb, rsb) = asRange b | | produces: | Illegal instance declaration for `AsRange (rsa, rsb) (nsa, nsb)' | (the Coverage Condition fails for one of the functional | dependencies) | In the instance declaration for `AsRange (rsa, rsb) (nsa, nsb)' | | Is it normal ? Yes, this is exactly as expected. (The fact that 6.4.2 allowed it was really a bug.) The behaviour is documented here: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions .html#instance-decls (in 7.4.4.1). You can find the background here http://research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/ However, if you add -fallow-undecidable-instances it'll be allowed (see section 7.4.4.2). Simon

1 0

Windows API - GetLastError woes
by Esa Ilari Vuokko 29 Aug '06

29 Aug '06

Hi, My "use case" is in Win32-package, where we simply call a FFI imported call and on failures call GetLastError to get extended error code. GetLastError of course only works on same OS thread and contains sensible results only before next Windows API call. It's much like C/posix errno. So, we *must* call GetLastError in the same OS thread, and there must not be any Windows API calls in between, including those caused by, say, rts' memory allocation or calls to lock mutexes. Unless the error code is saved via Get/SetLastError. Also, I'd like not to run the code in a another OS thread (and that won't fix the rts-caused Windows API calls), because the calls are supposed to be fast, and OS-level context switch isn't fast. Is this problem real, or did I miss some magic feature of rts? The only way to solve this problem seems to be to wrap all calls in C-functions that take care of reading GetLastError. Not that it's impossible, just very annoying. Best regards, --Esa Ilari Vuokko

4 4

6.6 Release Candidate delayed
by Simon Marlow 29 Aug '06

29 Aug '06

We previously announced that there would be a release candidate of 6.6 out on 25 August. However, we are experiencing some stability problems with the current 6.6 sources on some platforms, so the 6.6 RC is delayed until we can straighten things out. On x86/Linux and x86_64/Linux things seem relatively stable though, so if you felt brave enough to have a go with the current snapshot on one of those platforms, please go ahead. Snapshots as usual can be grabbed from http://www.haskell.org/ghc/dist/current/dist/ and the release notes (still subject to changes before the release) are here: http://www.haskell.org/ghc/dist/current/docs/users_guide/release-6-6.html Cheers, The GHC Team

1 0

using ghc with make
by Frederik Eaton 26 Aug '06

26 Aug '06

Hi all, I have a project which currently uses Cabal, and I would like to switch to using a plain Makefile. I have two examples of projects that use Makefiles, darcs and jhc, but they both appear to hand-code the list of dependencies for executables. The "-M" option to ghc should let us do this automatically, but either because of a deficiency in GHC or in GNU Make, that looks to be impossible or difficult. Does anyone have experience with this? Since I'm not using the multi-compiler features of Cabal, I think it shouldn't be too hard to get the project-specific part of my Makefile down to the size of the .cabal file. Many thanks, Frederik P.S. I want to use 'make' rather than Cabal because: - I want to be able to rebuild specific targets, rather than building everything every time - I want better dependency inference, for instance I don't want to relink every executable every time I do a build (I think this is fixed in newer versions of ghc, but not the one I use) - I ultimately want to be able to use a more sophisticated build system than Cabal's. GNU Make is a good first start, because it allows me to run several jobs simultaneously, for instance potentially utilizing multiple processors. In the future, I want to write a build system that does result caching as well. There are a lot of tricks that can be done in build systems, so in general I think it would be good to have a build system which is separable from the domain-specific configuration and compiler logic, rather than coupling them as Cabal and "ghc --make" do. The compile / fix compiler errors cycle is an important part of the development process for me, and so I want recompilation to go as quickly as possible. By the way, the GHC user manual claims that using --make is much faster than using a Makefile, but in a test on a small program, the difference was not significant (16 seconds vs. 18 seconds). Furthermore, some build systems are able to combine targets, e.g. running "ghc -c Bar.hs -c Foo.hs" instead of "ghc -c Bar.hs; ghc -c Foo.hs", which should eliminate the already small difference. -- http://ofb.net/~frederik/

9 23

A registerised mips-linux port of GHC
by Thiemo Seufer 25 Aug '06

25 Aug '06

Hello All, I currently try to get a ghc port on mips-linux going. I understand Igloo does the same ATM, and things look promising so far. However, the port is currently unregisterised, and I would like to improve it a bit. A registerised port seems to be achievable with a moderate amount of work. I looked a bit around in the code, and have now a few questions: - The example of other ports suggests the useful maximum of general purpose registers for GHC is 8. I also presume that unmentioned registers aren't touched by haskell code. Is this correct? - The comments in the source suggest that callee-saved registers are preferable, without further explanation. I would expect a mix of caller- and callee-saved registers to be potentially better. Any advice on this? - The mips ABI defines 8 (or 9 when including the frame pointer) registers as callee-saved, and more than 9 caller-saved temporaries. With four registers taken for stack/heap pointers this leaves a 5/3 split of callee-saved/caller-saved registers, if all my assumptions above are ok. Are there other considerations to take into account for the register layout? Thiemo

3 7

`let' for comprehension
by Serge D. Mechveliani 25 Aug '06

25 Aug '06

Who can advise, please, is this for sure that the program \ x -> [f y | y <- g x] is not more expensive in computation than \ x -> let ys = g x in [f y | y <- ys] ? May the difference depend on Haskell implementation? (I suspect that compilers convert one of these programs to another). Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2