Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Manuel M T Chakravarty wrote: jutaro: This is the first answer I got from the gtk2hs mailing list. Please consider this issue seriously. Well there is a simple fix as Simon Marlow wrote, The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a foreign import. In fact, if as Axel writes, these finalisers are Haskell functions that are exported using foreign import wrapper, then using Foreign.Concurrent.mkForeignPtr is actually the *simpler* thing to do (you don't need any wrapping and exporting). Right. Admittedly we hadn't realised that this would affect gtk2hs when we decided to bring this change into 6.10.2, and if we had, perhaps we would have decided to wait until 6.12.1. Patchlevel releases are not supposed to break existing working code - however in this case the code that is broken is using undocumented features. So we *could* back out the change. let's talk about whether that's the right course of action. There's a GHC meeting this afternoon, come long to #ghc on Freenode at 1600 UTC (in just under 2.5 hours). To summarise the issues: * gtk2hs is broken by this change, and possibly others. Unfortunately we can't easily find out whether code is affected, because this is a dynamic property. * gtk2hs can be fixed, but that means doing a new release etc. * the error message is pretty clear (not a crash) * there was some demand for the new feature (e.g Conal Elliot). If we back out, then these people will have to wait until 6.12.1 (~ 6 months). * backing out now will delay the GHC release. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
This is the first answer I got from the gtk2hs mailing list. Please consider this issue seriously. Jürgen Axel Simon wrote: Phew, I think we're doomed. We have many, many little methods that take a user-given function, wrap it into a foreign export wrapper which is freed by using an on-destroy callback to Haskell. These functions are most likely installed into some widgets (or other reference-counted objects) that will be eventually destroyed by the Haskell garbage collector. So, basically, we can't easily change Gtk2Hs. It will involve many modifications. I can understand that not allowing callbacks during GC is a great simplification in the runtime but it seemed to be common practice to free Stable and function pointers from within Haskell using a callback. So, unless I'm wrong on why finalizers call back into Haskell land, then this means that Gtk2Hs is fundamentally broken for the foreseeable future. Axel. -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22691289.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
jutaro: This is the first answer I got from the gtk2hs mailing list. Please consider this issue seriously. Well there is a simple fix as Simon Marlow wrote, The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a foreign import. In fact, if as Axel writes, these finalisers are Haskell functions that are exported using foreign import wrapper, then using Foreign.Concurrent.mkForeignPtr is actually the *simpler* thing to do (you don't need any wrapping and exporting). Manuel Axel Simon wrote: Phew, I think we're doomed. We have many, many little methods that take a user-given function, wrap it into a foreign export wrapper which is freed by using an on-destroy callback to Haskell. These functions are most likely installed into some widgets (or other reference-counted objects) that will be eventually destroyed by the Haskell garbage collector. So, basically, we can't easily change Gtk2Hs. It will involve many modifications. I can understand that not allowing callbacks during GC is a great simplification in the runtime but it seemed to be common practice to free Stable and function pointers from within Haskell using a callback. So, unless I'm wrong on why finalizers call back into Haskell land, then this means that Gtk2Hs is fundamentally broken for the foreseeable future. Axel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello, On Thursday 19 March 2009 18:03, Ian Lynagh wrote: On Wed, Mar 18, 2009 at 12:35:01PM +0100, Thorkil Naur wrote: ... 1. An important property of such installers is that you are told, right from the start, that all the information you are presented with during the installation process can be accessed at any time, after completion of the installation, and you are told how. In case of GHC, something like a reference to a suitable spot, given as part of the output from ghc --help. I don't see any trace of such a facility on the introduction screen. (I know that other installers don't do this either, which is part of the reason why I try to avoid them.) I didn't follow that; can you say exactly what text you want where, please? The point of this item is to avoid the uneasiness that I often feel when running though such a sequence of screens, that some piece of information that I am given is not available anywhere else and that it is forever gone, once the screen that contains it has been replaced by the next in the sequence. Hence also my interest in being able to copy and paste the contents of these screens. A suggested way to reduce this uneasiness would be: 1a. Add this text to the Introduction screen: The complete text of the installation session will be available after installation at /usr/share/doc/ghc/INSTALL_SESSION_MACOSX.txt [say]. Invoking the command 'ghc --help' in a Terminal window will mention the location of this file. So, all I have to remember now is 'ghc --help'. 1b. And, of course, now we have to produce this file INSTALL_SESSION_MACOSX.txt, somehow, and include it in the installation. I am not sure what this file should be, but let me say first that I am not thinking of an installation log or something like that, I am thinking of something that can be produced statically, as part of producing the installation package. Ideally, if the package is produced by some tool, it would be possible to extract the contents of various screens in text form and use that. Or perhaps there is some script for generating the installation package that could be used directly or with a few edits. In any case, the file should contain, in text form, whatever text is presented to the user during installation. So a list of header, contents, in the order used during installation. 1c. And 'ghc --help' should be extended to mention the INSTALL_SESSION_MACOSX.txt file. Not necessarily a trivial change, I admit, but I would consider it very useful. ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Bulat Ziganshin wrote: Hello Don, Friday, March 20, 2009, 2:34:09 AM, you wrote: the question is wider - how many other programs already used this behavior? it may be asked on main haskell list. what is the cost of reverting it back for 6.10.*? We could revert it, but lots of people asked for this feature (predictable finalizers), which is why we put it in 6.10.2. The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a foreign import. Cheers, Simon We must have the gtk2hs team invovled in this discussion. They were using an undocumented feature. It may be trivial to fix. --Don jnf: Hello Simon, I've put a request about the issue on the gtk2hs users mailing list: I've tried a gtk2hs app on ghc 6.10.2 release candidate. It crashes frequently and Simon (as you can read down here) assumes it is gtk2hs problem. My question is: Is this problem known to gtk2hs developers? Is it really a gtk2hs problem? How difficult is it to fix the problem? When will we have a patch to use gtk2hs with 6.10.2, is it already in the repo? However, I'm a little surprised that a little version upgrade from 6.10.1 to 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps are affected because of this change? What's about wxhaskell e.g.? Well, maybe we have only few Haskell applications around, but usually I wouldn't expect such a dramatic effect from such a moderate upgrade. Is this fix so important to introduce it now? What does it help when it was never officially supported if it causes such troubles? Jürgen Simon Marlow-7 wrote: jutaro wrote: I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. This will need to be fixed in gtk2hs. Previously GHC allowed finalizers to call back into Haskell, but this was never officially supported. Now it is officially unsupported, because finalizers created via Foreign.mkForeignPtr are run directly by the garbage collector. See http://hackage.haskell.org/trac/ghc/ticket/1364 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello Don, Friday, March 20, 2009, 2:34:09 AM, you wrote: the question is wider - how many other programs already used this behavior? it may be asked on main haskell list. what is the cost of reverting it back for 6.10.*? We must have the gtk2hs team invovled in this discussion. They were using an undocumented feature. It may be trivial to fix. --Don jnf: Hello Simon, I've put a request about the issue on the gtk2hs users mailing list: I've tried a gtk2hs app on ghc 6.10.2 release candidate. It crashes frequently and Simon (as you can read down here) assumes it is gtk2hs problem. My question is: Is this problem known to gtk2hs developers? Is it really a gtk2hs problem? How difficult is it to fix the problem? When will we have a patch to use gtk2hs with 6.10.2, is it already in the repo? However, I'm a little surprised that a little version upgrade from 6.10.1 to 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps are affected because of this change? What's about wxhaskell e.g.? Well, maybe we have only few Haskell applications around, but usually I wouldn't expect such a dramatic effect from such a moderate upgrade. Is this fix so important to introduce it now? What does it help when it was never officially supported if it causes such troubles? Jürgen Simon Marlow-7 wrote: jutaro wrote: I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. This will need to be fixed in gtk2hs. Previously GHC allowed finalizers to call back into Haskell, but this was never officially supported. Now it is officially unsupported, because finalizers created via Foreign.mkForeignPtr are run directly by the garbage collector. See http://hackage.haskell.org/trac/ghc/ticket/1364 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
On Thu, Mar 19, 2009 at 01:43:26PM -0700, jutaro wrote: Is this fix so important to introduce it now? What does it help when it was never officially supported if it causes such troubles? The reason it's now not allowed is that 6.10.2 provides guarantees about running C finalizers that 6.10.1 did not. See http://hackage.haskell.org/trac/ghc/ticket/1364 for more details. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 6.10.2 Release Candidate 1
I've tried the 6.10.2 RC with some performance-sensitive work code. The code uses the non-threaded runtime, and makes extensive use of signals. The results look very good. The slightly funny (but useful to us) benchmark measures bandwidth communicating between multiple unix processes. Here's a graph of how much better 6.10.2 is doing: http://galois.com/~dons/images/bandwidth.png Note we're over a 1G/s bandwidth now with 6.10.2 for the first time :) Thanks guys! (Note also we use a slightly modified runtime that has thread deadlock detection disabled). There have been quite a few runtime patches, enough that 6.10.2 is really quite a different runtime now: http://galois.com/~dons/rts.patches http://galois.com/~dons/6101-6102.diff Anyway, all those signal and thread handling changes are looking good. Looking back through what has gone into 6.10.2, I think the credit probably goes to the patch below. It's nice to hear this improves performance too - that was an unexpected benefit. If you're able to test with the HEAD, I'd be very interested to see your results there too. Cheers, Simon Fri Feb 20 14:32:00 GMT 2009 Ian Lynagh ig...@earth.li * MERGED: Rewrite of signal-handling (ghc patch; see also base and unix patches) Simon Marlow marlo...@gmail.com**20090219103142 Ignore-this: aca7c3e258224fadc6f0f2fee86b2971 The API is the same (for now). The new implementation has the capability to define signal handlers that have access to the siginfo of the signal (#592), but this functionality is not exposed in this patch. #2451 is the ticket for the new API. The main purpose of bringing this in now is to fix race conditions in the old signal handling code (#2858). Later we can enable the new API in the HEAD. Implementation differences: - More of the signal-handling is moved into Haskell. We store the table of signal handlers in an MVar, rather than having a table of StablePtrs in the RTS. - In the threaded RTS, the siginfo of the signal is passed down the pipe to the IO manager thread, which manages the business of starting up new signal handler threads. In the non-threaded RTS, the siginfo of caught signals is stored in the RTS, and the scheduler starts new signal handler threads. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
jutaro wrote: I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. This will need to be fixed in gtk2hs. Previously GHC allowed finalizers to call back into Haskell, but this was never officially supported. Now it is officially unsupported, because finalizers created via Foreign.mkForeignPtr are run directly by the garbage collector. See http://hackage.haskell.org/trac/ghc/ticket/1364 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hi Ian, Ian Lynagh wrote: The buildbot is putting SplitObjs=NO in mk/build.mk. The above log has object splitting enabled, which means that there are a lot more .o files, which is presumably causing some problem with your ar. If you have both a GNU ar and a Solaris ar then it might be worth seeing if the other one works. Otherwise, putting SplitObjs=NO in mk/build.mk will work, but at the expense of larger binaries. I put just GNU ar into my PATH, so GHC build is using Sun ld and GNU ar and the build runs for much longer and breaks on: Building hsc2hs-0.67... [1 of 2] Compiling Paths_hsc2hs ( dist-install/build/autogen/Paths_hsc2hs.hs, dist-install/build/hsc2hs/hsc2hs-tmp/Paths_hsc2hs.o ) [2 of 2] Compiling Main ( Main.hs, dist-install/build/hsc2hs/hsc2hs-tmp/Main.o ) Linking dist-install/build/hsc2hs/hsc2hs ... gmake[3]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils/hsc2hs' gmake -C haddock install-inplace gmake[3]: Entering directory `/var/tmp/ghc-6.10.1.20090314/utils/haddock' /var/tmp/ghc-6.10.1.20090314/utils/installPackage/install-inplace/bin/installPackage install '/var/tmp/ghc-6.10.1.20090314/utils/ghc-pkg/install-inplace/bin/ghc-pkg' '/var/tmp/ghc-6.10.1.20090314/inplace-datadir/package.conf' '' \ '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ '$prefix/bin' \ '$prefix/lib' \ '$prefix/libexec' \ '$prefix/dynlib' \ '$prefix/share' \ '$prefix/doc' \ '$prefix/html'\ '$prefix/haddock' \ --distpref dist-install\ --enable-shell-wrappers Installing library in /var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace/lib/haddock-2.4.2 Installing executable(s) in /var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace/bin internal error: error_message(28) gmake[3]: *** [install-inplace] Error 100 gmake[3]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils/haddock' gmake[2]: *** [with-stage-2] Error 2 gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314' gmake: *** [bootstrap2] Error 2 The message `internal error: error_message(28)' looks suspiciously, is there any Sun ar invoked behind the scene? Or isn't this message from the AR but coming from something else? Thanks, Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
On Thu, Mar 19, 2009 at 11:31:33AM +0100, Karel Gardas wrote: /var/tmp/ghc-6.10.1.20090314/utils/installPackage/install-inplace/bin/installPackage install '/var/tmp/ghc-6.10.1.20090314/utils/ghc-pkg/install-inplace/bin/ghc-pkg' '/var/tmp/ghc-6.10.1.20090314/inplace-datadir/package.conf' '' \ '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ '$prefix/bin' \ '$prefix/lib' \ '$prefix/libexec' \ '$prefix/dynlib' \ '$prefix/share' \ '$prefix/doc' \ '$prefix/html'\ '$prefix/haddock' \ --distpref dist-install\ --enable-shell-wrappers The message `internal error: error_message(28)' looks suspiciously, is there any Sun ar invoked behind the scene? Or isn't this message from the AR but coming from something else? Try running the above command but with -v2 or -v3 appended, and it should show you what is being run. Looks like strip is probably the culprit. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
On Wed, Mar 18, 2009 at 12:35:01PM +0100, Thorkil Naur wrote: I have tried the Intel Mac installer and the source package on both FreeBSD and PPC Mac OS X. Some comments follow Thanks! 1. An important property of such installers is that you are told, right from the start, that all the information you are presented with during the installation process can be accessed at any time, after completion of the installation, and you are told how. In case of GHC, something like a reference to a suitable spot, given as part of the output from ghc --help. I don't see any trace of such a facility on the introduction screen. (I know that other installers don't do this either, which is part of the reason why I try to avoid them.) I didn't follow that; can you say exactly what text you want where, please? 2. The introduction screen says This package must be installed on the system volume which seems to imply that there is some kind of choice involved at a later stage. But I don't recall having to perform any choice that related to this. So perhaps this should be This package will be installed on the system volume instead. Good point, done. 3. I can copy and paste the text of the introduction screen, excellent. I cannot copy and paste the header. I don't think there's anything we can do about this. 4. On the License screen, GMP is denoted GNU MP Bignum Library in two places. I suggest using GNU Multiple Precision Arithmetic Library (from http://gmplib.org/) instead. The title of that page is The GNU MP Bignum Library, and the docs seem to be mostly consistent in calling it the GNU MP Library, so I'm going to leave it as it is unless there's consensus for a change. 5. On the License screen, replace licence by license, twice. Thanks, changed to make it consistent. 6. The License screen explains that by default the GMP will be statically linked into any binary produced by GHC. Software with a non-GPL compatible licence [sic] will have to ensure that the conditions of the LGPL are met; for example, by forcing GMP to link dynamically instead. Some details or a reference to an explanation of how to do this would be nice. I don't think we want details in the installer, but we should have something in the docs somewhere. Also, shouldn't non-GPL compatible be plain non-GPL? No, I believe (IANAL etc) any license that provides the appropriate freedoms is OK. 7. I may very well be wrong, but as far as I have been able to tell, the ghc executable itself that is distributed (/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc) contains GMP, statically linked. For example: thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES /usr/bin/ghc --version dyld: loaded: /bin/sh dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib dyld: loaded: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc dyld: loaded: /usr/lib/libedit.2.dylib dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib The Glorious Glasgow Haskell Compilation System, version 6.10.1.20090314 thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where I fail to observe anything that seems to relate to GMP. This is in contrast to the corresponding information for an earlier GHC installation thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES ghc --version dyld: loaded: /bin/sh dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib dyld: loaded: /Users/thorkilnaur/tn/install/ghc-6.8.3/lib/ghc-6.8.3/ghc-6.8.3 dyld: loaded: /opt/local/lib/libreadline.5.2.dylib dyld: loaded: /opt/local/lib/libncurses.5.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /opt/local/lib/libgmp.3.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib The Glorious Glasgow Haskell Compilation System, version 6.8.3 thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where one observes the presence of dyld: loaded: /opt/local/lib/libgmp.3.dylib that loads the separately installed dynamic GMP library. Hmm, I'm note sure why that changed. Manuel, do you know? 9. I cannot copy and paste the text or the header of the Installation Type screen, the one that says This will take 448 MB of space on your computer. Click Install to perform a standard
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
On Mon, Mar 16, 2009 at 04:00:09PM +0100, Christian Maeder wrote:
Under Solaris grep does not understand -q in configure:
checkMake380() {
if $1 --version 21 | head -1 | grep -q 'GNU Make 3\.80'
it fails with:
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
OK, I'll just redirect stdout to /dev/null then.
Presumably these print 0 and 1 respectively?
echo foo | grep foo /dev/null; echo $?
echo foo | grep bar /dev/null; echo $?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Ian Lynagh wrote:
On Mon, Mar 16, 2009 at 04:00:09PM +0100, Christian Maeder wrote:
Under Solaris grep does not understand -q in configure:
checkMake380() {
if $1 --version 21 | head -1 | grep -q 'GNU Make 3\.80'
it fails with:
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
OK, I'll just redirect stdout to /dev/null then.
Presumably these print 0 and 1 respectively?
echo foo | grep foo /dev/null; echo $?
echo foo | grep bar /dev/null; echo $?
Yes, Christian
-bash-3.00$ echo foo | grep foo /dev/null; echo $?
0
-bash-3.00$ echo foo | grep bar /dev/null; echo $?
1
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello Simon, I've put a request about the issue on the gtk2hs users mailing list: I've tried a gtk2hs app on ghc 6.10.2 release candidate. It crashes frequently and Simon (as you can read down here) assumes it is gtk2hs problem. My question is: Is this problem known to gtk2hs developers? Is it really a gtk2hs problem? How difficult is it to fix the problem? When will we have a patch to use gtk2hs with 6.10.2, is it already in the repo? However, I'm a little surprised that a little version upgrade from 6.10.1 to 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps are affected because of this change? What's about wxhaskell e.g.? Well, maybe we have only few Haskell applications around, but usually I wouldn't expect such a dramatic effect from such a moderate upgrade. Is this fix so important to introduce it now? What does it help when it was never officially supported if it causes such troubles? Jürgen Simon Marlow-7 wrote: jutaro wrote: I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. This will need to be fixed in gtk2hs. Previously GHC allowed finalizers to call back into Haskell, but this was never officially supported. Now it is officially unsupported, because finalizers created via Foreign.mkForeignPtr are run directly by the garbage collector. See http://hackage.haskell.org/trac/ghc/ticket/1364 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
We must have the gtk2hs team invovled in this discussion. They were using an undocumented feature. It may be trivial to fix. --Don jnf: Hello Simon, I've put a request about the issue on the gtk2hs users mailing list: I've tried a gtk2hs app on ghc 6.10.2 release candidate. It crashes frequently and Simon (as you can read down here) assumes it is gtk2hs problem. My question is: Is this problem known to gtk2hs developers? Is it really a gtk2hs problem? How difficult is it to fix the problem? When will we have a patch to use gtk2hs with 6.10.2, is it already in the repo? However, I'm a little surprised that a little version upgrade from 6.10.1 to 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps are affected because of this change? What's about wxhaskell e.g.? Well, maybe we have only few Haskell applications around, but usually I wouldn't expect such a dramatic effect from such a moderate upgrade. Is this fix so important to introduce it now? What does it help when it was never officially supported if it causes such troubles? Jürgen Simon Marlow-7 wrote: jutaro wrote: I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. This will need to be fixed in gtk2hs. Previously GHC allowed finalizers to call back into Haskell, but this was never officially supported. Now it is officially unsupported, because finalizers created via Foreign.mkForeignPtr are run directly by the garbage collector. See http://hackage.haskell.org/trac/ghc/ticket/1364 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
On Thu, 2009-03-19 at 16:34 -0700, Don Stewart wrote: We must have the gtk2hs team invovled in this discussion. They were using an undocumented feature. It may be trivial to fix. This will need to be fixed in gtk2hs. Previously GHC allowed finalizers to call back into Haskell, but this was never officially supported. Now it is officially unsupported, because finalizers created via Foreign.mkForeignPtr are run directly by the garbage collector. I had a quick look but so far I cannot see where any callback into Haskell is happening. The only interesting case I've found is one finaliser which is implemented in C and uses hs_free_stable_ptr. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello, On Sunday 15 March 2009 16:51, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.10.2: ... Please test as much as possible; bugs are much cheaper if we find them before the release! ... I have tried the Intel Mac installer and the source package on both FreeBSD and PPC Mac OS X. Some comments follow, first on GHC-6.10.1.20090314-i386.pkg: 1. An important property of such installers is that you are told, right from the start, that all the information you are presented with during the installation process can be accessed at any time, after completion of the installation, and you are told how. In case of GHC, something like a reference to a suitable spot, given as part of the output from ghc --help. I don't see any trace of such a facility on the introduction screen. (I know that other installers don't do this either, which is part of the reason why I try to avoid them.) 2. The introduction screen says This package must be installed on the system volume which seems to imply that there is some kind of choice involved at a later stage. But I don't recall having to perform any choice that related to this. So perhaps this should be This package will be installed on the system volume instead. 3. I can copy and paste the text of the introduction screen, excellent. I cannot copy and paste the header. 4. On the License screen, GMP is denoted GNU MP Bignum Library in two places. I suggest using GNU Multiple Precision Arithmetic Library (from http://gmplib.org/) instead. 5. On the License screen, replace licence by license, twice. 6. The License screen explains that by default the GMP will be statically linked into any binary produced by GHC. Software with a non-GPL compatible licence [sic] will have to ensure that the conditions of the LGPL are met; for example, by forcing GMP to link dynamically instead. Some details or a reference to an explanation of how to do this would be nice. Also, shouldn't non-GPL compatible be plain non-GPL? 7. I may very well be wrong, but as far as I have been able to tell, the ghc executable itself that is distributed (/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc) contains GMP, statically linked. For example: thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES /usr/bin/ghc --version dyld: loaded: /bin/sh dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib dyld: loaded: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc dyld: loaded: /usr/lib/libedit.2.dylib dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib The Glorious Glasgow Haskell Compilation System, version 6.10.1.20090314 thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where I fail to observe anything that seems to relate to GMP. This is in contrast to the corresponding information for an earlier GHC installation thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES ghc --version dyld: loaded: /bin/sh dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib dyld: loaded: /Users/thorkilnaur/tn/install/ghc-6.8.3/lib/ghc-6.8.3/ghc-6.8.3 dyld: loaded: /opt/local/lib/libreadline.5.2.dylib dyld: loaded: /opt/local/lib/libncurses.5.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /opt/local/lib/libgmp.3.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib The Glorious Glasgow Haskell Compilation System, version 6.8.3 thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where one observes the presence of dyld: loaded: /opt/local/lib/libgmp.3.dylib that loads the separately installed dynamic GMP library. I am no expert in these matters, but this seems to activate requirement d) 0) under section 4. Combined Works of the LGPL GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007 (http://www.fsf.org/licensing/licenses/lgpl.html) which talks about providing material and giving instructions about how to re-link with a new version of the library and all that. If this material and the instructions are present in the installation package, I have failed to notice it. Alternatively, if the ghc executable links to GMP dynamically, requirement d) 1) of the LGPL comes into effect and that talks about a mechanism ...that ... uses at run time a copy of the Library already present on the user's computer
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hi Karel, On Mon, Mar 16, 2009 at 11:26:05AM +0100, Karel Gardas wrote: interesting but I'm not able to build this on SunOS 5.11/x86. The build fails with: (echo dist/build/cbits/PrelIOUtils.p_o dist/build/cbits/WCsubst.p_o dist/build/cbits/Win32Utils.p_o dist/build/cbits/consUtils.p_o dist/build/cbits/dirUtils.p_o dist/build/cbits/inputReady.p_o dist/build/cbits/selectUtils.p_o `find dist/build -name *_stub.p_o -print`; find dist/build/Foreign/Concurrent_split dist/build/GHC/Arr_split dist/build/GHC/Base_split [...] dist/build/Text/Show/Functions_split dist/build/Unsafe/Coerce_split -name '*.p_o' -print) | xargs /usr/bin/ar q dist/build/libHSbase-4.1.0.0_p.a ar: creating dist/build/libHSbase-4.1.0.0_p.a internal error: error_message(58) gmake[3]: *** [dist/build/libHSbase-4.1.0.0_p.a] Error 100 gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries/base' gmake[1]: *** [make.library.base] Error 2 gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries' gmake: *** [stage1] Error 2 I've configure with simple: ./configure --prefix=/tmp/ghc-6.10.1.20090314 and build with: gmake The interesting thing is that GHC stable builds on my buildbot well: http://darcs.haskell.org/buildbot/all/builders/kgardas%20stable The buildbot is putting SplitObjs=NO in mk/build.mk. The above log has object splitting enabled, which means that there are a lot more .o files, which is presumably causing some problem with your ar. If you have both a GNU ar and a Solaris ar then it might be worth seeing if the other one works. Otherwise, putting SplitObjs=NO in mk/build.mk will work, but at the expense of larger binaries. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. Any idea about this? Jürgen Nicklisch-Franken Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.10.2: http://www.haskell.org/ghc/dist/6.10.2-rc1/ This includes two source bundles: ghc-6.10.1.20090314-src.tar.bz2 ghc-6.10.1.20090314-src-extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. More may appear later. 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 -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22592804.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.10.2: http://www.haskell.org/ghc/dist/6.10.2-rc1/ This includes two source bundles: ghc-6.10.1.20090314-src.tar.bz2 ghc-6.10.1.20090314-src-extralibs.tar.bz2 Awesome! This release candidate is also available for testing purposes through the gentoo haskell overlay. http://code.haskell.org/gentoo/gentoo-haskell/ You can use the overlay either through layman (overlay called haskell) http://www.gentoo.org/proj/en/overlays/userguide.xml or by yourself a la old school, PORTDIR_OVERLAY in make.conf. We don't yet have any ebuilds for the extralibs. GHC is hard masked, meaning only available for testing purposes, use caution :) $ echo dev-lang/ghc /etc/portage/package.unmask It's also keyworded ~amd64 ~x86, meaning you'll have to allow potentially unstable packages: $ echo dev-lang/ghc /etc/portage/package.keywords Last but not least, the ebuild does not provide any bootstrapping binary to compile ghc, so you need to already have a version of ghc installed to bootstrap with. Then emerge with $ USE=ghcbootstrap -binary emerge dev-lang/ghc Please report any issues in #gentoo-haskell @ freenode. Cheers, Lennart Kolmodin -- Gentoo Dev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello, interesting but I'm not able to build this on SunOS 5.11/x86. The build fails with: (echo dist/build/cbits/PrelIOUtils.p_o dist/build/cbits/WCsubst.p_o dist/build/cbits/Win32Utils.p_o dist/build/cbits/consUtils.p_o dist/build/cbits/dirUtils.p_o dist/build/cbits/inputReady.p_o dist/build/cbits/selectUtils.p_o `find dist/build -name *_stub.p_o -print`; find dist/build/Foreign/Concurrent_split dist/build/GHC/Arr_split dist/build/GHC/Base_split dist/build/GHC/Classes_split dist/build/GHC/Conc_split dist/build/GHC/ConsoleHandler_split dist/build/GHC/Desugar_split dist/build/GHC/Enum_split dist/build/GHC/Environment_split dist/build/GHC/Err_split dist/build/GHC/Exception_split dist/build/GHC/Exts_split dist/build/GHC/Float_split dist/build/GHC/ForeignPtr_split dist/build/GHC/Handle_split dist/build/GHC/IO_split dist/build/GHC/IOBase_split dist/build/GHC/Int_split dist/build/GHC/List_split dist/build/GHC/Num_split dist/build/GHC/PArr_split dist/build/GHC/Pack_split dist/build/GHC/Ptr_split dist/build/GHC/Read_split dist/build/GHC/Real_split dist/build/GHC/ST_split dist/build/GHC/STRef_split dist/build/GHC/Show_split dist/build/GHC/Stable_split dist/build/GHC/Storable_split dist/build/GHC/TopHandler_split dist/build/GHC/Unicode_split dist/build/GHC/Weak_split dist/build/GHC/Word_split dist/build/System/Timeout_split dist/build/Control/Applicative_split dist/build/Control/Arrow_split dist/build/Control/Category_split dist/build/Control/Concurrent_split dist/build/Control/Concurrent/Chan_split dist/build/Control/Concurrent/MVar_split dist/build/Control/Concurrent/QSem_split dist/build/Control/Concurrent/QSemN_split dist/build/Control/Concurrent/SampleVar_split dist/build/Control/Exception_split dist/build/Control/Exception/Base_split dist/build/Control/OldException_split dist/build/Control/Monad_split dist/build/Control/Monad/Fix_split dist/build/Control/Monad/Instances_split dist/build/Control/Monad/ST_split dist/build/Control/Monad/ST/Lazy_split dist/build/Control/Monad/ST/Strict_split dist/build/Data/Bits_split dist/build/Data/Bool_split dist/build/Data/Char_split dist/build/Data/Complex_split dist/build/Data/Dynamic_split dist/build/Data/Either_split dist/build/Data/Eq_split dist/build/Data/Data_split dist/build/Data/Fixed_split dist/build/Data/Foldable_split dist/build/Data/Function_split dist/build/Data/HashTable_split dist/build/Data/IORef_split dist/build/Data/Int_split dist/build/Data/Ix_split dist/build/Data/List_split dist/build/Data/Maybe_split dist/build/Data/Monoid_split dist/build/Data/Ord_split dist/build/Data/Ratio_split dist/build/Data/STRef_split dist/build/Data/STRef/Lazy_split dist/build/Data/STRef/Strict_split dist/build/Data/String_split dist/build/Data/Traversable_split dist/build/Data/Tuple_split dist/build/Data/Typeable_split dist/build/Data/Unique_split dist/build/Data/Version_split dist/build/Data/Word_split dist/build/Debug/Trace_split dist/build/Foreign_split dist/build/Foreign/C_split dist/build/Foreign/C/Error_split dist/build/Foreign/C/String_split dist/build/Foreign/C/Types_split dist/build/Foreign/ForeignPtr_split dist/build/Foreign/Marshal_split dist/build/Foreign/Marshal/Alloc_split dist/build/Foreign/Marshal/Array_split dist/build/Foreign/Marshal/Error_split dist/build/Foreign/Marshal/Pool_split dist/build/Foreign/Marshal/Utils_split dist/build/Foreign/Ptr_split dist/build/Foreign/StablePtr_split dist/build/Foreign/Storable_split dist/build/Numeric_split dist/build/Prelude_split dist/build/System/Console/GetOpt_split dist/build/System/CPUTime_split dist/build/System/Environment_split dist/build/System/Exit_split dist/build/System/IO_split dist/build/System/IO/Error_split dist/build/System/IO/Unsafe_split dist/build/System/Info_split dist/build/System/Mem_split dist/build/System/Mem/StableName_split dist/build/System/Mem/Weak_split dist/build/System/Posix/Internals_split dist/build/System/Posix/Types_split dist/build/Text/ParserCombinators/ReadP_split dist/build/Text/ParserCombinators/ReadPrec_split dist/build/Text/Printf_split dist/build/Text/Read_split dist/build/Text/Read/Lex_split dist/build/Text/Show_split dist/build/Text/Show/Functions_split dist/build/Unsafe/Coerce_split -name '*.p_o' -print) | xargs /usr/bin/ar q dist/build/libHSbase-4.1.0.0_p.a ar: creating dist/build/libHSbase-4.1.0.0_p.a internal error: error_message(58) gmake[3]: *** [dist/build/libHSbase-4.1.0.0_p.a] Error 100 gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries/base' gmake[1]: *** [make.library.base] Error 2 gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries' gmake: *** [stage1] Error 2 I've configure with simple: ./configure --prefix=/tmp/ghc-6.10.1.20090314 and build with: gmake The interesting thing is that GHC stable builds on my buildbot well: http://darcs.haskell.org/buildbot/all/builders/kgardas%20stable Any idea what I'm doing wrong? Thanks, Karel ___
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 6.10.2:
http://www.haskell.org/ghc/dist/6.10.2-rc1/
Under Solaris grep does not understand -q in configure:
checkMake380() {
if $1 --version 21 | head -1 | grep -q 'GNU Make 3\.80'
it fails with:
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
C.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 6.10.2 Release Candidate 1
We are pleased to announce the first release candidate for GHC 6.10.2: http://www.haskell.org/ghc/dist/6.10.2-rc1/ This includes two source bundles: ghc-6.10.1.20090314-src.tar.bz2 ghc-6.10.1.20090314-src-extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. More may appear later. 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
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
On Sun, Mar 15, 2009 at 03:51:42PM +, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.10.2: http://www.haskell.org/ghc/dist/6.10.2-rc1/ This includes two source bundles: ghc-6.10.1.20090314-src.tar.bz2 ghc-6.10.1.20090314-src-extralibs.tar.bz2 Could you add a testsuite tarball too please? -- Exherbo KDE, X.org maintainer ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
On Sun, Mar 15, 2009 at 10:49:20PM +, Ingmar Vanhassel wrote: http://www.haskell.org/ghc/dist/6.10.2-rc1/ Could you add a testsuite tarball too please? There's already one there. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
