- Glasgow-haskell-users

RE: Running a "final" finaliser
by Simon Marlow 29 Dec '03

29 Dec '03

> Thanks for your reply. I'm afraid it's left me even > more confused about which way to go with this :-( > > If it's possible that future Haskell FFI's don't guarantee > that all finalisers are run then this more or less rules > out the use of the reference counting solution (which > wasn't particularly attractive anyway because it needs to > be done in C AFAICS :-). If users who want this behaviour > are required to code it themselves, it seems to require that > they maintain a global list of all allocated ForeignPtrs. > But doing that naively will stop them being garbage collected > at all, unless it's possible to do something clever using weak > pointers. Perhaps it is possible (or maybe some tricks at the > C level could be used) but I think it's a significant extra > burden for FFI users. Yes, it would have to be a global list of weak pointers to ForeignPtrs. This topic has come up before, though not on this list. See this message, and the rest of the thread: http://www.haskell.org/pipermail/cvs-ghc/2003-January/016651.html the thread also moved on to ffi(a)haskell.org: http://www.haskell.org/pipermail/ffi/2003-January/001041.html and be sure to check out the paper by Hans Boehm referenced in that message, it's a good summary of the issues involved. > Also, while we're talking about this, maybe the semantics > of performGC should be clarified. Does it block until > all GC (and finalisation of garbage ForeignPtrs) is complete? > I would guess this was the original intention, but this > doesn't seem to be consistent with non-stop Haskell. If > it does block, are all Haskell threads blocked, or just > the calling thread? performGC doesn't do anything that you can rely on :-) In practice, it probably starts all the finalizers that are ready to run, but it certainly doesn't wait for their termination. > Also, I could you explain what you mean by a suitable > exception handler? I don't really understand this at all. > I'd expected I may well end up using bracket or similar, > but I'm not sure how exception handling is relevant to > this problem. Start your program something like this: import Control.Exception (finally) main = my_main `finally` clean_up my_main = ... put your program here ... clean_up = ... all the cleanup code goes here ... You can additionally use finalizers to perform incremental cleanup during program execution, but the right way to clean up at the end is to use an exception handler as above. Cheers, Simon

4 6

ghc-6-2-1.msi broken?
by Gour 28 Dec '03

28 Dec '03

After having problem in building ghc-6.2 from source tarball, I installed ghc-6-2-1.msi build and then tried to compile darcs with it, but, strangely enough, configure script fails when trying to compile "Hello world!" program. I tried to compile: bash-2.05b# cat main.hs module Main(main) where main = putStrLn "Hello world!\n" but ghc only produces main.hi file - no output file "main". The same result within MSYS & MSDOS prompt. However, the same 'program' compiles and produces executable on my Gentoo box. It looks like Win32 build of ghc-6.2 is broken or am I missing something (being still a ghc newbie in the begining stages of learning Haskell :-( Sincerely, Gour -- Gour gour(a)mail.inet.hr Registered Linux User #278493

1 0

ghc 6.2 build problem (MinGW/MSYS)
by Gour 28 Dec '03

28 Dec '03

I'm pretty new with GHC and I have prblem building ghc 6.2 with MinGW compiler in MSYS environment. After running "configure --prefix=/mingw ; make" make fails with: [snip] copying ./mpn/generic/gmp-mparam.h to gmp-mparam.h gcc -E -mno-cygwin -undef -traditional -I../includes -x c -DHAVE_LIBMINGWEX package.conf.in \ | sed 's/^#.*$//g' >package.conf.inplace gcc -E -mno-cygwin -undef -traditional -I../includes -DINSTALLING -x c -DHAVE_LIBMINGWEX package.conf.in \ | sed 's/^#.*$//g' >package.conf.installed ../utils/ghc-pkg/ghc-pkg-inplace --update-package <package.conf.inplace ../utils/ghc-pkg/ghc-pkg-inplace: /ghc/utils/ghc-pkg/ghc-pkg.exe: No such file or directory ../utils/ghc-pkg/ghc-pkg-inplace: exec: /ghc/utils/ghc-pkg/ghc-pkg.exe: cannot execute: No such file or directory make[2]: *** [../driver/stamp-pkg-conf-rts] Error 126 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/gour/ghc-6.2/ghc' make: *** [build] Error 1 I have tried to modify the script by changing paths, but then I broke another thing. The same source tarball builds normally under Gentoo Linux with appropriate ebuild. Question: does anyone built ghc 6.2 with MinGW & MSYS (via configure)? (Since on Win98 I compile everything with MinGW/MSYS and install all the packages under /mingw tree,I'd like to do the same with ghc, and not to use binary installer since it comes with its own Perl ...) I'm using binary ghc-6.0.1 in building process. Sincerely, Gour -- Gour gour(a)mail.inet.hr Registered Linux User #278493

1 0

GHC Warning Request
by Ashley Yakeley 28 Dec '03

28 Dec '03

When -fwarn-unused-imports is switched on, "import M()" should not issue a warning. In 6.2, it does. The idea is that I only wish to import instance declarations here, and that's the obvious way of making that explicit. I'm using -Werror (new in 6.2, thanks), and most of the time I'm interested in knowing about superfluous imports. -- Ashley Yakeley, Seattle WA

1 0

GHC 6.2 breaks multiline string literals
by Stefan Reich 28 Dec '03

28 Dec '03

This worked in GHC 6.0.1: multilineLiteral = " line1 line2" But doesn't work in GHC 6.2. Is this a bug or rather a bugfix? Anyway, I found it very convenient to embed verbatim string blocks this way. Is there maybe another way to achieve the same thing? Thanks in advance, -Stefan

4 4

ANNOUNCE: GHC version 6.2
by Simon Marlow 27 Dec '03

27 Dec '03

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 6.2 ============================================================ We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 6.2. Highlights include: * Arrows syntax * New pragma: UNPACK for selectively unpacking strict constructor fields. * New option -e for giving an expression to evaluate on the command-line. * Portability improvements. GHC has been ported to a few new platforms. * Removal of obsolete features: _ccall_, _casm_, ``...''. * Many bugs fixed See the release notes for a full list of the changes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6.2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

9 12

RE: ghc-6.2 compilation problems
by Simon Marlow 23 Dec '03

23 Dec '03

> > > The build output is like so: > > [snip] > > > Fail: does not exist > > > Action: openFileEx > > > Reason: No such file or directory > > > File: base/base.haddock > > > > Hmmm. It's possible the gentoo ebuild is trying to 'make > install-docs' > > without building the docs in the first place. > > This has indeed been the problem and is hopefully fixed by now. > However, the question remains what exactly the use of the variable > NO_HADDOCK_DOCS is if it can be set to yes and haddock is still > called at least once it in the libraries dir (I think to create > the file index.html). Could you perhaps explain the intention behind > the NO_HADDOCK_DOCS variable? Oops, the libraries Makefile should really check NO_HADDOCK_DOCS. Thanks for pointing it out. Cheers, Simon

1 0

RE: ghc-6.2 compilation problems
by Simon Marlow 22 Dec '03

22 Dec '03

> I'm getting problems building ghc 6.2. It fails building the > documentation (which I didn't really want anyway). I'm using > the gentoo ebuild script. > > I've got haddock 0.6 installed. (That was my first error!) > I'm hoping someone might know what is going wrong here. I'll > report back > to the gentoo ghc package maintainer. > > The build output is like so: [snip] > Fail: does not exist > Action: openFileEx > Reason: No such file or directory > File: base/base.haddock Hmmm. It's possible the gentoo ebuild is trying to 'make install-docs' without building the docs in the first place. Cheers, Simon

2 1

RE: Concurrency problems with Handle
by Simon Marlow 22 Dec '03

22 Dec '03

> Now, if I let one side of the connection send some characters: > sequence_ $ take 10 $ repeat $ (writeChan outputChan 's') > and I let the other side consume them: > sequence_ $ take 10 $ repeat $ (putChar =<< readChan inputChan) > then the characters are sent and received correctly, but the > receiving side > shows the characters only after the connection is closed. This looks correct: stdout is probably buffered. To see the characters as they are written, hSetBuffering stdout NoBuffering. If this doesn't work, then there is probably some other buffereing going on somewhere (don't run it in emacs, for example). > If I let both sides send and consume characters in turn, like this: > sequence_ $ take 10 $ repeat $ threadDelay 250 >> > (writeChan outputChan > 's') >> (putChar =<< readChan inputChan) > and > sequence_ $ take 10 $ repeat $ (putChar =<< readChan inputChan) >> > threadDelay 250 >> (writeChan outputChan 'c') > , one character is sent, and the other end waits indefinitely before > sending his character. Could be a bug. Can you construct a complete program which illustrates the problem, and send it to us? > Could it have anything to with this? > "One final note: the aaaa bbbb example may not work too well > on GHC.... I suspect that this is not the problem, since the case being referred to in the docs here is where two running threads are competing for the same resource, which doesn't seem to be the case in your code. Cheers, Simon

1 0

GHC and UNICODE...
by MR K P SCHUPKE 22 Dec '03

22 Dec '03

Whilst I appreciate the topic of show is not directly related to GHC, what I would like to know is how to handle UNICODE properly... If I assume I have a good unicode terminal, so stdin and stdout are in unicode format, and all my text files are in unicode, how do I deal with this properly in GHC... what is the current state of affairs? Regards, Keean.

3 2