August 2005 - Glasgow-haskell-users

RE: Installation problem
by Simon Marlow 03 Aug '05

03 Aug '05

On 02 August 2005 20:00, Dieter Büttner wrote: > I have a X86_64 architecture. So you may be right. In which lib > directory ghc-6.4-1 is looking for libgmp? There I could install the > 32 bit version. It depends on which flavour of Linux you have, but for example on our Fedora Core 3 box here: > locate libgmp /usr/lib64/libgmpxx.so.3 /usr/lib64/libgmpxx.so.3.0.5 /usr/lib64/libgmp.so.3.3.3 /usr/lib64/libgmp.a /usr/lib64/libgmpxx.so /usr/lib64/libgmpxx.a /usr/lib64/libgmp.so.3 /usr/lib64/libgmp.so /usr/lib/libgmpxx.so.3 /usr/lib/libgmpxx.so.3.0.5 /usr/lib/sse2/libgmpxx.so.3 /usr/lib/sse2/libgmpxx.so.3.0.5 /usr/lib/sse2/libgmp.so.3.3.3 /usr/lib/sse2/libgmp.so.3 /usr/lib/libgmp.so.3.3.3 /usr/lib/libgmp.so.3 Cheers, Simon

1 0

RE: making ghc-6.4.1-august-1
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 08:06, Serge D. Mechveliani wrote: > I tried to make ghc-6.4.1.20050801-src.tar.bz2 > > with ghc-cvs-6.4.1-july-12 on Debian Linux. > > ( > uname -m > i686 > > uname -r > 2.4.27-2-686-smp > ). > > It reports > > --------------------------------- > ... > System/Directory/Internals.hs:1:0: > conflict: module `System.Directory.Internals' > belongs to the current program/library and also to package > base-1.0 <<ghc: 19592712 bytes, 5 GCs, 79280/79280 avg/max bytes > residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.11 MUT > (0.33 elapsed), > 0.10 GC (0.09 elapsed) :ghc>> > make[4]: *** [System/Directory/Internals.o] Error 1 > --------------------------------- > > Should I install ghc-6.4.1.20050801-binary and then compile its > source? Yes, please try building with either 6.4 or the latest 6.4.1. There may be intermediate stages that have problems. Cheers, Simon

1 0

making ghc-6.4.1-august-1
by Serge D. Mechveliani 03 Aug '05

03 Aug '05

I tried to make ghc-6.4.1.20050801-src.tar.bz2 with ghc-cvs-6.4.1-july-12 on Debian Linux. ( > uname -m i686 > uname -r 2.4.27-2-686-smp ). It reports --------------------------------- ... System/Directory/Internals.hs:1:0: conflict: module `System.Directory.Internals' belongs to the current program/library and also to package base-1.0 <<ghc: 19592712 bytes, 5 GCs, 79280/79280 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.11 MUT (0.33 elapsed), 0.10 GC (0.09 elapsed) :ghc>> make[4]: *** [System/Directory/Internals.o] Error 1 --------------------------------- Should I install ghc-6.4.1.20050801-binary and then compile its source? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Installation problem
by Simon Marlow 02 Aug '05

02 Aug '05

On 30 July 2005 12:58, Dieter wrote: > I'm using Linux 9.3 on a PC with a 64-architecture. > > I'd like to install GHC and thought the easiest way would be to take > an appropriate rpm-file.So I downloaded an rpm file, it was said to > running with SUSE 9.2 without problems. > But when starting rpm -i ghc.-6.4-1.i386.rpm I got the message: > > error: Failed dependencies: > libgmp.so.3 is needed by ghc-6.4-1 > > But it is installed on my systems. I downloaded it again and > installed it again and copied it (3 files: - the symlink libgmp.so, > the symlink libgmp.so.3 and the file the libgmp.so.3.3.3) into > several lib directories. NO SUCCESS > > What is wrong? > Has anyone an idea? Are you running an x86_64 OS, or just a plain i386 one? If you're running x86_64, then perhaps you only have the 64-bit version of libgmp installed? Cheers, Simon

2 1

RE: 6.4.1 release candidate testing
by Simon Marlow 02 Aug '05

02 Aug '05

On 01 August 2005 15:07, Simon Marlow wrote: > This is to announce that testing for 6.4.1 has begun. Snapshots from > 20050730 onwards are release candidates - please test if you can. > Snapshots are available from here: > > http://www.haskell.org/ghc/dist/stable/dist/ > > we have source snapshots, and binaries for Linux/x86 (RH 9.1 era), > Linux/x86_64 (FC3 era), and Windows. > > A *huge* number of fixes have gone in since 6.4. Also, big news is > that Linux/x86_64 will have a new native code generator and GHCi > support (including Template Haskell), so we'd especially like to hear > from anyone that can test on Linux/x86_64. The GHCi support isn't > complete: the interpreter can't currently handle FFI, and there are > problems with data references to shared libraries from > dynamically-loaded .o files, but otherwise it should be functional. I forgot to mention: 6.4.1 will also have some big changes to the package system. Primarily: - A local module can shadow a package module with the same name, as long as the conflicting package is not otherwise depended upon somehow. - If two modules are in scope with the same name, the conflict will not be reported until you try to import the module. these together mean it is much less likely that you can render your GHC installation unusable by installing packages. Also, as discussed on the libraries list recently: - specifying -package P without an explicit version number on P gets you the most recent version of P, instead of an error. - if multiple versions of a package are exposed, then GHC takes the one with the latest version in the absence of any -package options that specify otherwise. We'd like to hear from anyone involved in packaging libraries whether these changes work for you. The new version of Cabal will *not* be in 6.4.1, but it'll be easy to upgrade. Cheers, Simon

1 0

problems building trhsx-0.2 with ghc-6.5.20050723
by Konovalov, Vadim 01 Aug '05

01 Aug '05

I built and installed ghc-6.5.20050723 on Linux from sources successfully, and it looks quite normally-working. I've stepped into a problem building trhsx from a package haskell-src-exts-0.2.tar.gz with a quite unexpected (for me) message: Preprocessing executables for trhsx-0.2... Building trhsx-0.2... hsSourceDirs: ["."] Chasing modules from: Hsx.hs Hsx.hs:6:7: Could not find module `Data.List': it is a member of package base-1.0, which is hidden Lines in error is quite innocent-looking: import Data.List (intersperse, isPrefixOf) GHC version 6.4 builds that module okay. Is that error is due to beta version of ghc-6.5.20050723, or I am misunderstanding some configuration issues? TIA, Vadim.

2 1

RE: Bug in placing _stub.o files with HEAD
by Simon Marlow 01 Aug '05

01 Aug '05

On 30 July 2005 01:21, Einar Karttunen wrote: > I noticed the following behaviour using GHC 6.5.20050728: > If compiling a Cabal package containing hs-source-dirs it > places the _stub.o under dist/build/<source-dir>/path/to/Module > when Cabal expects it in dist/build/path/to/Module. Things > appear to work without hs-source-dirs. > > For example with "hs-source-dirs: src" > Network/GnuTLS/IOWrap.hs contains foreign export declarations. > runnning Setup build creates the files: > dist/build/src/Network/GnuTLS/IOWrap_stub.o > src/Network/GnuTLS/IOWrap_stub.h > src/Network/GnuTLS/IOWrap_stub.c > > But Cabal fails to include the IOWrap_stub.o as it is > expected as dist/build/Network/GnuTLS/IOWrap_stub.o I thought I fixed this in CVS recently (rev. 1.54 of Distribution.Simple.Build to be exact). Are you running Cabal from CVS, or some other version? Cheers, Simon

2 1

RE: Performance week 25/6-29/6
by Simon Marlow 01 Aug '05

01 Aug '05

[ duh, hit send by mistake, that's twice today :-( ] Ok, we made some progress on performance last week, but there's still plenty to do. Here's a summary: - Simon PJ found an O(n^2) case in the simplifier that appears to be the cause of most, if not all, of the cases of GHC going out to lunch when compiling certain modules. However, while testing the fix we discovered that it caused worse code to be generated for some programs, so we're still looking into this. - I added a hack in GHC's back end to do some lightweight buffering of the output, which results in about a 10% speedup in compilation time. The C output was also using the full pretty printer, when it doesn't really need to do indentation. - I tweaked the garbage collector in a few places, to get some modest speedup. - A nasty space leak in the native code generator was found & fixed. The space usage of GHC in general remains worse than we'd like. - A few other minor optimisations were made in the compiler. We plan to put the simplifier fix into 6.4.1, and the NCG space-leak fix is already in. The other fixes are a little too intrusive with 6.4.1 being so close, so we'll hold off on those (possibly for 6.4.2). Cheers, Simon

1 0

RE: Performance week 25/6-29/6
by Simon Marlow 01 Aug '05

01 Aug '05

Ok, we made some progress on performance last week, but there's still plenty to do. Here's a summary: - Simon PJ found an O(n^2) case in the simplifier that appears to be the cause of most, if not all, of the cases of GHC going out to lunch when compiling certain modules. However, while testing the fix we discovered that it caused worse code to be generated for some programs, so we're still looking into this. - I added a hack in GHC's back end to do some lightweight buffering of the

1 0

RE: Re[2]: C--
by Simon Marlow 01 Aug '05

01 Aug '05

On 01 August 2005 14:25, Bulat Ziganshin wrote: > Monday, August 01, 2005, 4:13:16 PM, you wrote: > >> On 31 July 2005 08:10, Bulat Ziganshin wrote: > >>> can you please say about value of using C-- in GHC? will this > >> It should reduce compile time compared to compiling via C, though I >> It should improve the speed of compiled programs, because C-- will be > > great. and when this will be implemented? I'll let those who are implementing it answer that :-) Cheers, Simon

1 0