ANNOUNCE: GHC 6.12.3 Release Candidate 1
Hi all, We are pleased to announce the first release candidate for GHC 6.12.3: http://www.haskell.org/ghc/dist/6.12.3-rc1/ As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team
Hi Ian, I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. All concurrency demos work and the more complicated demos work that trigger several levels of callbacks (to C and back to Haskell). Cheers, Axel On May 23, 2010, at 20:42, Ian Lynagh wrote:
Hi all,
We are pleased to announce the first release candidate for GHC 6.12.3:
http://www.haskell.org/ghc/dist/6.12.3-rc1/
As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux.
Please test as much as possible; bugs are much cheaper if we find them before the release!
Thanks Ian, on behalf of the GHC team
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Axel Simon schrieb:
Hi Ian,
I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. All concurrency demos work and the more complicated demos work that trigger several levels of callbacks (to C and back to Haskell).
1. I could not install gtk2hs-0.11.0 under x86 Solaris. Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... Configuring glib-0.11.0... Preprocessing library glib-0.11.0... gtk2hsC2hs: Errors during expansion of binding hooks: ./System/Glib/GObject.chs:107: (column 22) [ERROR]
Unknown identifier! Cannot find a definition for `g_object_get_type' in the header file.
cabal: Error: some packages failed to install: 2. under a x86 Mac with a GTK-2.14 framework I got: Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... Configuring gtk-0.11.0... setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument cabal: Error: some packages failed to install: gtk-0.11.0 failed during the building phase. The exception was: ExitFailure 1 The packages cairo-0.11.0 gio-0.11.0 glib-0.11.0 pango-0.11.0 built fine. The GTK-2.14 framework is: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets... and originally came from http://r.research.att.com/ 3. Under linux we still have a problem with the new gtk2hs-0.11.0 version. http://trac.informatik.uni-bremen.de:8080/hets/ticket/794
Cheers, Axel
On May 23, 2010, at 20:42, Ian Lynagh wrote:
Hi all,
We are pleased to announce the first release candidate for GHC 6.12.3:
building and installing ghc-6.12.2.20100521, compiling and running our large hets binary (without gtk2hs) worked. Thanks Christian
As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux.
Please test as much as possible; bugs are much cheaper if we find them before the release!
Thanks Ian, on behalf of the GHC team
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hi Christian,
Christian Maeder
Axel Simon schrieb:
Hi Ian,
I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. All concurrency demos work and the more complicated demos work that trigger several levels of callbacks (to C and back to Haskell).
1. I could not install gtk2hs-0.11.0 under x86 Solaris.
Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... Configuring glib-0.11.0... Preprocessing library glib-0.11.0... gtk2hsC2hs: Errors during expansion of binding hooks:
./System/Glib/GObject.chs:107: (column 22) [ERROR]
Unknown identifier! Cannot find a definition for `g_object_get_type' in the header file.
cabal: Error: some packages failed to install: Looks, it's a problem that glib can't found header file. gtk2hs find header files base on pkg-config return.
Can you run "pkg-config --cflags gobject-2.0"?
2. under a x86 Mac with a GTK-2.14 framework I got:
Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ...
Configuring gtk-0.11.0...
setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument
cabal: Error: some packages failed to install:
gtk-0.11.0 failed during the building phase. The exception was:
ExitFailure 1
This is bug of Gtk2HsSetup.hs, has fix in darcs version. Cheers, -- Andy
The packages cairo-0.11.0 gio-0.11.0 glib-0.11.0 pango-0.11.0 built fine.
The GTK-2.14 framework is: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets... and originally came from http://r.research.att.com/
3. Under linux we still have a problem with the new gtk2hs-0.11.0 version. http://trac.informatik.uni-bremen.de:8080/hets/ticket/794
Cheers, Axel
On May 23, 2010, at 20:42, Ian Lynagh wrote:
Hi all,
We are pleased to announce the first release candidate for GHC 6.12.3:
building and installing ghc-6.12.2.20100521, compiling and running our large hets binary (without gtk2hs) worked.
Thanks Christian
As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux.
Please test as much as possible; bugs are much cheaper if we find them before the release!
Thanks Ian, on behalf of the GHC team
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
------------------------------------------------------------------------------
On 27.05.2010, at 16:28, Christian Maeder wrote:
Axel Simon schrieb:
Hi Ian,
I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. All concurrency demos work and the more complicated demos work that trigger several levels of callbacks (to C and back to Haskell).
1. I could not install gtk2hs-0.11.0 under x86 Solaris.
Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... Configuring glib-0.11.0... Preprocessing library glib-0.11.0... gtk2hsC2hs: Errors during expansion of binding hooks:
./System/Glib/GObject.chs:107: (column 22) [ERROR]
Unknown identifier! Cannot find a definition for `g_object_get_type' in the header file.
Yup, we didn't test on Solaris. However, this is a Gtk+ version problem. The above mentioned function does not exist in Gtk+ 2.14 because it would be equivalent to G_TYPE_OBJECT. I've fixed this in the darcs repository.
cabal: Error: some packages failed to install:
2. under a x86 Mac with a GTK-2.14 framework I got:
Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ...
Configuring gtk-0.11.0...
setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument
cabal: Error: some packages failed to install:
gtk-0.11.0 failed during the building phase. The exception was:
This bug occurs if you're running in anything else but UTF-8 locale. As Andy said, this is fixed in darcs.
The packages cairo-0.11.0 gio-0.11.0 glib-0.11.0 pango-0.11.0 built fine.
The GTK-2.14 framework is: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets... and originally came from http://r.research.att.com/
For the next point, it would really help us, if you could check out the darcs repo and build again. That would then also entail ironing out the problems with Gtk+ 2.14.
3. Under linux we still have a problem with the new gtk2hs-0.11.0 version. http://trac.informatik.uni-bremen.de:8080/hets/ticket/794
This would be very interesting to resolve. I assume: - you use -threaded to compile your program - you only use postGUISync and postGUIAsync from threads different to the Gtk2Hs thread Is this true? If yes, I'll give you an elaboration on how threads are supposed to work in Gtk+ (I think I finally understood this!) and what I've changed in 0.11.0. Cheers, Axel
Cheers, Axel
On May 23, 2010, at 20:42, Ian Lynagh wrote:
Hi all,
We are pleased to announce the first release candidate for GHC 6.12.3:
building and installing ghc-6.12.2.20100521, compiling and running our large hets binary (without gtk2hs) worked.
Thanks Christian
As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux.
Please test as much as possible; bugs are much cheaper if we find them before the release!
Thanks Ian, on behalf of the GHC team
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hello Axel, Thursday, May 27, 2010, 8:42:08 PM, you wrote:
- you use -threaded to compile your program - you only use postGUISync and postGUIAsync from threads different to the Gtk2Hs thread
Is this true? If yes, I'll give you an elaboration on how threads are supposed to work in Gtk+ (I think I finally understood this!) and what I've changed in 0.11.0.
i'm among (probably many) developers who interested to hear it. i believe that gtk2hs uses thread where it was initialized as main (this thread should be bound so it's either main thread or one created with runInBoundThread/forkOS) and the everything should either run in this thread directly, or in signal hadlers (that are executed in this thread) or via postGUISync/postGUIAsync. moreover postGUISync can't be used inside main GUI thread due to locking as you may remember, once i proposed to add wrapper that is equal to id in main GUI thread but equal to postGUISync in other threads. or even better, wrap all gtk2hs operations in this wrapper -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 27.05.2010, at 19:50, Bulat Ziganshin wrote:
Hello Axel,
Thursday, May 27, 2010, 8:42:08 PM, you wrote:
- you use -threaded to compile your program - you only use postGUISync and postGUIAsync from threads different to the Gtk2Hs thread
Is this true? If yes, I'll give you an elaboration on how threads are supposed to work in Gtk+ (I think I finally understood this!) and what I've changed in 0.11.0.
i'm among (probably many) developers who interested to hear it. i believe that gtk2hs uses thread where it was initialized as main (this thread should be bound so it's either main thread or one created with runInBoundThread/forkOS) and the everything should either run in this thread directly, or in signal hadlers (that are executed in this thread) or via postGUISync/postGUIAsync. moreover postGUISync can't be used inside main GUI thread due to locking
as you may remember, once i proposed to add wrapper that is equal to id in main GUI thread but equal to postGUISync in other threads. or even better, wrap all gtk2hs operations in this wrapper
Yes, I should perhaps dig that up and implement it. I actually suspect that Christian ran either into this problem or that he doesn't compile with -threaded. Hopefully it's one of those two options and not another concurrency bug in Gtk2Hs. So the story with the threads is as follows: You can use just a single thread. This is done when you compile without -threaded. You need to do the 'addIdle 50 >> yield' trick. You can use the -threaded option to ghc or you use ghci. Now there exists one lock for the whole of Gtk+. This lock must be acquired before gtk_init is called. (This is what I fixed before the release: without it, it worked on Unix but not on Windows.) The lock remains acquired by the OS thread that calls Gtk+. In particular, it remains acquire as long as signals are pending and dispatched. The only time this look is released is when Gtk+ enters its main loop. It may then block on input or run an idle handler. During this time, it is possible for a different OS thread (or any odd Haskell thread that may or may not run in a different OS thread) to acquire the lock, modify some widget state and release the lock. However, most widget methods call also to the OS and accessing the Win32 API from more than one OS thread is not possible due to Win32 using some thread-local state. Thus, using this method for concurrent updates is not recommended. Enter postGUIAsync. This method will add an idle handler to the Gtk+ main loop (this is done by glib in a thread safe way) which executes an action from the idle handler. This idle handler will be called from the main loop and thus be in the Gtk+ OS thread. The action can therefore safely access all widget methods. Since the action is performed in the Gtk+ OS thread, no expensive computation should be done, merely the widgets should be updated. I hope this helps to clarify the thread situation in Gtk+. Cheers, Axel
Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 6.12.3:
There's a small build problem, also present in earlier 6.12 versions. The gzip program uses the $GZIP environment variable, which I have set in my environment. This conflicts with the GZIP Makefile variable used in ghc. With GZIP=--best in my environment, the build ends with: "rm" -f -r libffi/build cat ghc-tarballs/libffi/libffi*.tar.gz | gzip -d | { cd libffi && /command/tar -xf - ; } gzip: gzip.gz: No such file or directory /command/tar: This does not look like a tar archive /command/tar: Exiting with failure status due to previous errors make[1]: *** [libffi/stamp.ffi.configure-shared] Error 2 make: *** [all] Error 2 Renaming the Makefile variable from GZIP to GZIP_CMD avoids this problem. The two instances I found were mk/config.mk.in:655 and libffi/ghc.mk:113. There may be other instances I haven't found, but changing those two is enough to get me past that error. paul
On Thu, Jun 03, 2010 at 09:25:16PM -0400, Paul Jarc wrote:
Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 6.12.3:
There's a small build problem, also present in earlier 6.12 versions. The gzip program uses the $GZIP environment variable, which I have set in my environment. This conflicts with the GZIP Makefile variable used in ghc.
Thanks for the report; fixed in 6.14. Thanks Ian
On 24 May 2010 04:42, Ian Lynagh
We are pleased to announce the first release candidate for GHC 6.12.3:
I did a test build for Fedora 14 (in development): http://koji.fedoraproject.org/koji/taskinfo?taskID=2208629 I also ran the current testsuite release fast on x86_64 without any problem. BTW Fedora 13 was released today with ghc-6.12.1, shared libraries, and haskell-platform-2010.1.0.0. Thank you, Jens
On Sun, May 23, 2010 at 07:42:21PM +0100, Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 6.12.3: [...] Please test as much as possible; bugs are much cheaper if we find them before the release!
Here are some test results on OpenBSD/amd64, with an 800 MB data
size liimit and with pthread support disabled (several people had
serious trouble with pthread support enabled for ghc-6.12.2, so I
disabled it in our port until I've time to debug that problem).
I've used the ghc-6.12 branch from the darcs repository for it; a
build with the official release candidate (plus the --with-gmp-*
patch recently pushed) is still running.
Executive summary: looks quite good. The only failure that *really*
puzzles me is the num009 one.
I've added some remarks to the list of unexpected failures below.
OVERALL SUMMARY for test run started at Thu May 27 19:11:36 CEST 2010
2383 total tests, which gave rise to
7689 test cases, of which
0 caused framework failures
1605 were skipped
5872 expected passes
178 expected failures
0 unexpected passes
34 unexpected failures
Unexpected failures:
concprog001(ghci)
==> out of memory (probably harmless)
getUserEntryForName(normal,optc,hpc,optasm,ghci)
==> known (by me) issue. probably a bug/incompatibility in OpenBSD
hClose003(normal,optc,hpc,optasm,ghci)
==> did not investigate yet. failure details (for the normal
way) below
hReady002(ghci)
==> did not investigate yet. failure details below
num009(normal,optc,hpc,optasm,ghci)
==> no idea. failure details below
openFile008(normal,optc,hpc,optasm,ghci)
==> too many open files. limits were too tight on my system,
I'll have to retest with higher limits
queryfdoption01(normal,optc,hpc,optasm)
==> unsupported operation. rings a bell here, I'll look at it
next weekend
signals002(normal,optc,hpc,optasm,ghci)
==> wrong exit code (150, expected 0). not yet investigated.
simpl015(optc,optasm)
==> out of memory (in the compiler). (probably harmless)
testblockalloc(normal)
==> out of memory. (probably harmless)
Details:
=====> hClose003(normal) 1002 of 2383 [0, 1, 0]
cd ./lib/IO && '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o hClose003 hClose003.hs -package unix >hClose003.comp.stderr 2>&1
cd ./lib/IO && ./hClose003 hClose003.run.stdout 2>hClose003.run.stderr
Actual stdout output differs from expected:
--- ./lib/IO/hClose003.stdout.normalised Thu May 27 19:35:14 2010
+++ ./lib/IO/hClose003.run.stdout.normalised Thu May 27 19:35:14 2010
@@ -1,4 +1,4 @@
Right ()
False
-Left <file descriptor: X>: hClose: resource vanished (Broken pipe)
+Right ()
False
*** unexpected failure for hClose003(normal)
=====> hReady002(ghci) 1015 of 2383 [0, 6, 0]
cd ./lib/IO && sleep 1 | '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output hReady002.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS
On 27/05/10 20:35, Matthias Kilian wrote:
Unexpected failures: concprog001(ghci) ==> out of memory (probably harmless)
getUserEntryForName(normal,optc,hpc,optasm,ghci) ==> known (by me) issue. probably a bug/incompatibility in OpenBSD
hClose003(normal,optc,hpc,optasm,ghci) ==> did not investigate yet. failure details (for the normal way) below
hReady002(ghci) ==> did not investigate yet. failure details below
This one is a known failure right now (I need to clean it up).
num009(normal,optc,hpc,optasm,ghci) ==> no idea. failure details below
Suspicious...
openFile008(normal,optc,hpc,optasm,ghci) ==> too many open files. limits were too tight on my system, I'll have to retest with higher limits
queryfdoption01(normal,optc,hpc,optasm) ==> unsupported operation. rings a bell here, I'll look at it next weekend
signals002(normal,optc,hpc,optasm,ghci) ==> wrong exit code (150, expected 0). not yet investigated.
Could be that signals are being delivered too quickly and overflowing the IO manager's pipe. We see this failure on our x86/Linux box too, but not on x86_64. Summary: if it's lost signals due to the pipe filling up, it's a known issue. Cheers, Simon
On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote:
hReady002(ghci) ==> did not investigate yet. failure details below
This one is a known failure right now (I need to clean it up).
Good to know. Thanks for the info.
num009(normal,optc,hpc,optasm,ghci) ==> no idea. failure details below
Suspicious...
If in doubt, suspect OpenBSD here; this is not the first time I've seen strange differences between our math and the math on other systems. But it's reall strange that there are different failures for different ways. I'll try to find what's going on.
signals002(normal,optc,hpc,optasm,ghci) ==> wrong exit code (150, expected 0). not yet investigated.
Could be that signals are being delivered too quickly and overflowing the IO manager's pipe. We see this failure on our x86/Linux box too, but not on x86_64. Summary: if it's lost signals due to the pipe filling up, it's a known issue.
Also good to know. I'll have a closer look wether it's the problem you mention (but I'm still short of time, so this may have to wait). As always, please don't let any problems specific to OpenBSD delay your release. Ciao, Kili
On 29/05/2010 15:07, Matthias Kilian wrote:
On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote:
hReady002(ghci) ==> did not investigate yet. failure details below
This one is a known failure right now (I need to clean it up).
Good to know. Thanks for the info.
num009(normal,optc,hpc,optasm,ghci) ==> no idea. failure details below
Suspicious...
If in doubt, suspect OpenBSD here; this is not the first time I've seen strange differences between our math and the math on other systems. But it's reall strange that there are different failures for different ways. I'll try to find what's going on.
It used to be the case that OpenBSD by default put the FPU on x86 machines into 64-bit precision mode, whereas other platforms tend to leave it in the default 80-bit mode. The advantage of OpenBSD's approach is that FP results are more robust to compiler optimisations and suchlike, without having to use gcc's -ffloat-store option. The disadvantage is that some precision has been discarded, and the results are different to those on other platforms. Also, I believe 32-bit float operations are done at 64-bit precision on OpenBSD, which is a bit strange. In GHC we support -msse2 which avoids these problems by using the correct precision consistently, as long as your processor supports SSE2. You'd have to build all the libraries with -msse2 to get the full benefit. Cheers, Simon
participants (9)
-
Andy Stewart -
Axel Simon -
Bulat Ziganshin -
Christian Maeder -
Ian Lynagh -
Jens Petersen -
Matthias Kilian -
prj＠po.cwru.edu -
Simon Marlow