Re: Re[2]: bug: unstable myThreadId in GHC 6.6.1
On Sat, 2009-04-11 at 21:07 +0400, Bulat Ziganshin wrote: Hello Bertram, Saturday, April 11, 2009, 8:09:46 PM, you wrote: What does same thread mean? I'll risk a guess. well, that's possible - i'll ask on gtk2hs list too currently, i believe that mainGUI just runs endless loop processing queue of GUI events You are both right. mainGUI does just run an endless event processing loop but callbacks for events (like button clicks) are indeed ffi wrapper callbacks and so do get run in a fresh thread. Your 'guiThread' is blocked in the mainGUI call, so nothing ever happens in that Haskell thread until the even loop terminates. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bug: unstable myThreadId in GHC 6.6.1
Bulat Ziganshin wrote: Hello glasgow-haskell-users, i've looked for this bug in Trac but don't found anything. so: startGUI action = runInBoundThread $ do unsafeInitGUIForThreadedRTS myThreadId = writeIORef guiThread action = widgetShowAll mainGUI guiThread = unsafePerformIO$ newIORef$ error undefined GUI::guiThread Later in the same thread i ask for myThreadId and get different value. What does same thread mean? I'll risk a guess. mainGUI is a safe foreign call that executes a loop on the C side; all future actions that you see and consider to be in the same thread are actually callbacks from C to Haskell. But in GHC's RTS, a new Haskell thread is created for each such callback, with a new thread id. So myThreadId returns varying numbers, leading to the effect that you described. So it's not a bug, although it should be better documented. It's not possible for the RTS to track which Haskell thread a callback was originally registered from (at best it could remember which thread created the original wrapper), and in any case that thread may be dead already, or running Haskell code at the time the callback comes, so I think that the current behaviour is quite sane. regards, Bertram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: bug: unstable myThreadId in GHC 6.6.1
Hello Bertram, Saturday, April 11, 2009, 8:09:46 PM, you wrote: What does same thread mean? I'll risk a guess. well, that's possible - i'll ask on gtk2hs list too currently, i believe that mainGUI just runs endless loop processing queue of GUI events -- 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
bug: unstable myThreadId in GHC 6.6.1
Hello glasgow-haskell-users, i've looked for this bug in Trac but don't found anything. so: startGUI action = runInBoundThread $ do unsafeInitGUIForThreadedRTS myThreadId = writeIORef guiThread action = widgetShowAll mainGUI guiThread = unsafePerformIO$ newIORef$ error undefined GUI::guiThread Later in the same thread i ask for myThreadId and get different value. interesting that value returned in startGUI is 23 while later values are about 7000. probably this reflects total amount of threads created so far so that's the problem. Win API call returns constant thread number (that looks natural since the thread is bound). so either: 1) it's feature - please mention this in docs 2) it was fixed since 6.6.1 3) we need full-scale bugreport using 6.10.2 -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bug: unstable myThreadId in GHC 6.6.1
Could you send a full example we can compile and test? This is only a fragment. bulat.ziganshin: Hello glasgow-haskell-users, i've looked for this bug in Trac but don't found anything. so: startGUI action = runInBoundThread $ do unsafeInitGUIForThreadedRTS myThreadId = writeIORef guiThread action = widgetShowAll mainGUI guiThread = unsafePerformIO$ newIORef$ error undefined GUI::guiThread Later in the same thread i ask for myThreadId and get different value. interesting that value returned in startGUI is 23 while later values are about 7000. probably this reflects total amount of threads created so far so that's the problem. Win API call returns constant thread number (that looks natural since the thread is bound). so either: 1) it's feature - please mention this in docs 2) it was fixed since 6.6.1 3) we need full-scale bugreport using 6.10.2 -- Best regards, Bulat mailto:bulat.zigans...@gmail.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[2]: bug: unstable myThreadId in GHC 6.6.1
Hello Don, Friday, April 10, 2009, 8:36:32 PM, you wrote: unfortunately, full example is my whole program. i will try to make short example if someone will say that it looks like a bug and it was not fixed in intermediate versions. basically, scenario is simple - myThreadId changed due the life of (bound) thread Could you send a full example we can compile and test? This is only a fragment. bulat.ziganshin: Hello glasgow-haskell-users, i've looked for this bug in Trac but don't found anything. so: startGUI action = runInBoundThread $ do unsafeInitGUIForThreadedRTS myThreadId = writeIORef guiThread action = widgetShowAll mainGUI guiThread = unsafePerformIO$ newIORef$ error undefined GUI::guiThread Later in the same thread i ask for myThreadId and get different value. interesting that value returned in startGUI is 23 while later values are about 7000. probably this reflects total amount of threads created so far so that's the problem. Win API call returns constant thread number (that looks natural since the thread is bound). so either: 1) it's feature - please mention this in docs 2) it was fixed since 6.6.1 3) we need full-scale bugreport using 6.10.2 -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ 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
Building ghc-6.10 with ghc-6.6.1
Hi,
I've successfully built ghc-6.10 with ghc-6.6.1; there was one minor
problem:
Building extensible-exceptions-0.1.0.0...
Control/Exception/Extensible.hs:2:13: cannot parse LANGUAGE pragma
ghc 6.6.1 does not know about DeriveDataTypeable - I just removed that
line.
Software used:
ghc-6.6.1
alex 2.2
happy 1.17
Cabal 1.4.0.1 (not relevant, I believe)
gcc 4.1.2 (may be relevant because of cpp)
linux 2.6.24.4
I'm not sure what Magicloud's problem is, but it's related to alex;
the contents of .../alex-2.3/AlexTemplate-ghc (whereever alex was
installed) would be interesting -- does it contain any lines
starting with # ?
This template is generated from templates/GenericTemplate.hs while
building alex.
Another idea is that {-# OPTIONS -fglasgow-exts -cpp #-} is somehow
missing from the generated utils/genprimopcode/Lexer.hs file in
the ghc tree - but I can't really see how that would happen.
Bertram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.6.1 -optl bug?
Hello GHC, sorry, i'm still user of 6.6.1 version the following command: ghc --make -optl-s strips the executable while the following command ghc --make -optl--strip-all has no effect. i made some experiments and it seems that options starting with -- are not sent to ld at all (you can write -optl--unexisting-option but not -optl-#) -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6.1 -optl bug?
Bulat Ziganshin wrote: Hello GHC, sorry, i'm still user of 6.6.1 version the following command: ghc --make -optl-s strips the executable while the following command ghc --make -optl--strip-all has no effect. i made some experiments and it seems that options starting with -- are not sent to ld at all (you can write -optl--unexisting-option but not -optl-#) Does adding -optl-Xlinker help you? ghc --make Hello.hs -fforce-recomp -optl-Xlinker -optl--strip-all [1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello ... /usr/bin/ld: unknown flag: --strip-all collect2: ld returned 1 exit status (I've use version 6.8.2 though) Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: ghc 6.6.1 -optl bug?
Hello Christian, Friday, January 11, 2008, 4:10:36 PM, you wrote: Does adding -optl-Xlinker help you? ghc --make Hello.hs -fforce-recomp -optl-Xlinker -optl--strip-all thank you - it works! -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building GHC 6.6.1 on Leopard/PPC
Hello,
First of all: Welcome to the club. I hope you will find it enjoyable. And then
to your questions:
I have never tried to bootstrap GHC from C, so I am not really able to help
with your specific problem. However, if you just want a running GHC, the
binary distributions should provide an easy path.
I have installed several binary GHC packages on various PPC Mac OS X machines
and, generally, they work. You should, however, be aware of several,
relatively recent, problems that have popped up that seem connected with GHC
6.8.1 and Leopard. See for example
http://hackage.haskell.org/trac/ghc/ticket/1958.
For example, I have a GHC 6.6.1 running on both 10.4 (Tiger) and 10.5
(Leopard) that I installed from
http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-powerpc-apple-darwin.tar.bz2 (see
http://haskell.org/ghc/download_ghc_661.html#macosxppc).
Once you have a running binary GHC, you can start building (newer) GHC's from
source distributions or darcs repositories.
Feel free to write back, if this is not the right answer to your questions.
Best regards
Thorkil
On Wednesday 19 December 2007 23:25, jcharum wrote:
I've been trying to get a working GHC 6.6.1 build on my Leopard box with
little success. I am trying to follow the Booting/porting from C (.hc)
files instructions here:
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
When I build the HC file bundle, I get errors about rts/AutoApply_* stuff,
but I've read that they are not necessary fatal.
When I try to build on the target system after unpacking the HC files
('distrib/hc-build --prefix=dir'), I get the following error:
== make boot -f Makefile;
in /Users/jjc/Downloads/ghc-6.6.1/libraries/readline
make[1]: *** No rule to make target `System/Console/Readline_hsc.c', needed
by `depend'. Stop.
Failed making boot in readline: 1
make: *** [boot] Error 1
Any help is much appreciated. Not only would I like to get this building
for myself, but I would also like to contribute a bootstrap build for other
Leopard/MacPorts/PPC users. Let me know if I can provide any more
information to help diagnose the problem.
--
View this message in context:
http://www.nabble.com/Building-GHC-6.6.1-on-Leopard-PPC-tp14426649p14426649.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: Building GHC 6.6.1 on Leopard/PPC
Hello, On Thursday 20 December 2007 20:15, Jerry Charumilind wrote: ... Besides getting a working compiler, my other goal is to get contribute a working build process on Leopard back to MacPorts, since they continue to have no solution right now (http://trac.macports.org/projects/macports/ticket/13039 ). You may wish to consult http://hackage.haskell.org/trac/ghc/ticket/1540 and, more generally, the GHC trac tickets with Operating System = Mac OS X. The bootstrap compiler that they used in Tiger (http://www.haskell.org/ghc/dist/6.4/MacOSX/ghc-6.4-darwin-bootstrap-tiger.tar.bz2 ) does not seem to work in Leopard. I have been unable to find the origin of this bootstrap build. However, it has no dependencies on GMP.framework or GNUreadline.framework, which are nice properties. I tend to agree with this. ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Building GHC 6.6.1 on Leopard/PPC
I've been trying to get a working GHC 6.6.1 build on my Leopard box with
little success. I am trying to follow the Booting/porting from C (.hc)
files instructions here:
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
When I build the HC file bundle, I get errors about rts/AutoApply_* stuff,
but I've read that they are not necessary fatal.
When I try to build on the target system after unpacking the HC files
('distrib/hc-build --prefix=dir'), I get the following error:
== make boot -f Makefile;
in /Users/jjc/Downloads/ghc-6.6.1/libraries/readline
make[1]: *** No rule to make target `System/Console/Readline_hsc.c', needed
by `depend'. Stop.
Failed making boot in readline: 1
make: *** [boot] Error 1
Any help is much appreciated. Not only would I like to get this building
for myself, but I would also like to contribute a bootstrap build for other
Leopard/MacPorts/PPC users. Let me know if I can provide any more
information to help diagnose the problem.
--
View this message in context:
http://www.nabble.com/Building-GHC-6.6.1-on-Leopard-PPC-tp14426649p14426649.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
problem compiling an older Haskell program with GHC 6.6.1
hi, I really appreciate the amazingly fast and helpful feedback to my previous message. that problem (FiniteMap not found) is solved. but a new problem came up... I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). now I get the error Data.hs:760:20: Not in scope: 'bounds' Data.hs is one of the files in the program. here is the nearby code: updateTable :: Hash a = a - IO b - Table a b - IO b updateTable x my (MkTable ref) = do MkHTab n arr - readIORef ref let (_,size) = bounds arr hashx= hash x i= hashx `mod` size ... in case it's helpful, the entire paradox source code is at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz just delete -package lang from the Makefile before running make. any advice would be greatly appreciated. best regards, scott ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problem compiling an older Haskell program with GHC 6.6.1
On Sat, Jul 07, 2007 at 03:59:48PM -0400, Scott Stoller wrote: hi, I really appreciate the amazingly fast and helpful feedback to my previous message. that problem (FiniteMap not found) is solved. but a new problem came up... I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). now I get the error Data.hs:760:20: Not in scope: 'bounds' Data.hs is one of the files in the program. here is the nearby code: updateTable :: Hash a = a - IO b - Table a b - IO b updateTable x my (MkTable ref) = do MkHTab n arr - readIORef ref let (_,size) = bounds arr hashx= hash x i= hashx `mod` size ... in case it's helpful, the entire paradox source code is at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz just delete -package lang from the Makefile before running make. Bounds was removed in 6.4.x to allow for dynamically sized arrays; it should work as: updateTable :: Hash a = a - IO b - Table a b - IO b updateTable x my (MkTable ref) = do MkHTab n arr - readIORef ref (_,size) - getBounds arr let hashx= hash x i= hashx `mod` size Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problem compiling an older Haskell program with GHC 6.6.1
Could not find module `Data.FiniteMap': is this a backwards-compatibility issue between GHC 6.6.1 and older versions of GHC? the module has just vanished from libraries. is there a simple workaround? ugly, but workable: http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/lib/Autolib/Data/Map.hs?rev=1.6 best regards, j.w. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problem compiling an older Haskell program with GHC 6.6.1
Hi http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/lib/Autolib/Data/Map.hs?rev=1.6 Or easier: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap-0.1 Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problem compiling an older Haskell program with GHC 6.6.1
hi, I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). in case anyone else wants to try it, I put the paradox source code at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz in the Makefile, I deleted -package lang from HFLAGS, and added -v to it. then I typed make. I got the following error message: Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1 Using package config file: /usr/local/lib/ghc-6.6.1/package.conf wired-in package base mapped to base-2.1.1 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.1 Hsc static flags: -static Created temporary directory: /tmp/ghc13306_0 *** Chasing dependencies: Set.hs:26:7: Could not find module `Data.FiniteMap': locations searched: Data/FiniteMap.hs Data/FiniteMap.lhs *** Deleting temp files: Deleting: /tmp/ghc13306_0/ghc13306_0.dep *** Deleting temp dirs: Deleting: /tmp/ghc13306_0 make: *** [depend.mak] Error 1 is this a backwards-compatibility issue between GHC 6.6.1 and older versions of GHC? is there a simple workaround? I can't easily use an older version of GHC, because I don't see binary distributions of older versions of GHC for Solaris x86. any advice would be greatly appreciated. best regards, scott ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Build failure on plain vanilla linux i686 build
On Thu, Jun 28, 2007 at 03:58:32PM -0300, Robin Bate Boerop wrote: On 28/06/07, Ian Lynagh [EMAIL PROTECTED] wrote: What does /sec/bin/ghc --version say? I suspect it'll be 6.4.2.20060331 rather than 6.4.2. Ian, indeed ghc --version was what you expected. Thank you for the advice. My build continues Was my 6.4.2 installed or configured improperly, so that the --version string was wrong? It wasn't actually 6.4.2, it was one of the nightly snapshots (from 3 weeks before the 6.4.2 release). The code was probably almost identical to 6.4.2, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Build failure on plain vanilla linux i686 build
Hi Robin, On Fri, Jun 22, 2007 at 01:21:00AM -0300, Robin Bate Boerop wrote: My build dies very soon after issuing make. Here are the last few lines. Does anyone know what is happening and how to fix it? (The floating constant of which the error message speaks is __GHC_PATCHLEVEL__, which is set to 2.20060331.) I have a working GHC 6.4 installed, BTW. What does /sec/bin/ghc --version say? I suspect it'll be 6.4.2.20060331 rather than 6.4.2. The simplest thing to do is just to remove all the content of compat/cbits/unicode.c (assuming you do have something 6.4; if you have 6.4 itself (or something older) then you'll need to leave the #include line in the file, but remove the #if and #endif). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Build failure on plain vanilla linux i686 build
Ian, indeed ghc --version was what you expected. Thank you for the advice. My build continues Was my 6.4.2 installed or configured improperly, so that the --version string was wrong? On 28/06/07, Ian Lynagh [EMAIL PROTECTED] wrote: Hi Robin, On Fri, Jun 22, 2007 at 01:21:00AM -0300, Robin Bate Boerop wrote: My build dies very soon after issuing make. Here are the last few lines. Does anyone know what is happening and how to fix it? (The floating constant of which the error message speaks is __GHC_PATCHLEVEL__, which is set to 2.20060331.) I have a working GHC 6.4 installed, BTW. What does /sec/bin/ghc --version say? I suspect it'll be 6.4.2.20060331 rather than 6.4.2. The simplest thing to do is just to remove all the content of compat/cbits/unicode.c (assuming you do have something 6.4; if you have 6.4 itself (or something older) then you'll need to leave the #include line in the file, but remove the #if and #endif). -- Robin Bate Boerop http://robin.bateboerop.name ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6.1 Build failure on plain vanilla linux i686 build
My build dies very soon after issuing make. Here are the last few lines. Does anyone know what is happening and how to fix it? (The floating constant of which the error message speaks is __GHC_PATCHLEVEL__, which is set to 2.20060331.) I have a working GHC 6.4 installed, BTW. /sec/bin/ghc -optc-O -optc-I. -optc-Iinclude -optc-D__GHC_PATCHLEVEL__=2.20060331 -optc-I../libraries/base/cbits -optc-I../libraries/base/include -H16m -O -I. -Iinclude -Rghc-timing -ignore-package Cabal -I../libraries -fglasgow-exts -no-recomp-c cbits/unicode.c -o cbits/unicode.o cbits/unicode.c:1:63: error: floating constant in preprocessor expression ghc: 13597044 bytes, 3 GCs, 103440/103440 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.17 elapsed), 0.01 GC (0.02 elapsed) :ghc make[2]: *** [cbits/unicode.o] Error 1 make[1]: *** [boot] Error 2 make: *** [stage1] Error 1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
Wagner Ferenc [EMAIL PROTECTED] writes: Stefan O'Rear [EMAIL PROTECTED] writes: On Tue, Jun 05, 2007 at 10:13:41PM +0200, Wagner Ferenc wrote: what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? Yes. Install the binary .tar.gz bundle *without creating a stub package* It installs in /usr/local, so dpkg must not know about it. Hmm, you have got a point, but then I can't uninstall/upgrade later easily, I'm afraid. I poked a little further down this road. For creating a package, it would be useful if I could ./configure --prefix=/usr and later DESTDIR=/tmp/stage make install (or similar, you got the idea) so that I can gather the would-be-installed files into a package for later installation. If no pathes are wired into the binaries during make install, then setting prefix to /tmp/stage/usr would do the trick, but it's not the case, I guess. Something similar must be necessary for Igloo to create the Debian Sid packages, so I find it somewhat surprising that it's not present in Makefile.in (or Makefile-bin.in?) On the other hand, he must be working with the source distribution, which may have this infrastructure... Anyway, it would be simple to add this by augmenting the install commands, but before I dive into this, I wanted to ask for your opinions. -- Thanks, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
In the end I created a new ghc6 package from the binary bundle by slight modifications and shameless theft from Ian Lynagh control file. It seems to work together with libreadline4 from Sarge. I'm willing to share it with anybody interested. -- Regards, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
Stefan O'Rear [EMAIL PROTECTED] writes: On Tue, Jun 05, 2007 at 10:13:41PM +0200, Wagner Ferenc wrote: what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? Yes. Install the binary .tar.gz bundle *without creating a stub package* It installs in /usr/local, so dpkg must not know about it. Hmm, you have got a point, but then I can't uninstall/upgrade later easily, I'm afraid. -- Thanks, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi Gregory, On Wed, May 30, 2007 at 05:56:31PM -0400, Gregory Wright wrote: On May 30, 2007, at 4:05 PM, Simon Marlow wrote: Gregory Wright wrote: I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 Great, thanks! yay! Ian will supply a link from the download page in due course, I'm sure. Now done. I still owe you some source patches to make the compiler build out of the box. If 6.6.1 is the end of the line, would you prefer that these be against HEAD? Yup, HEAD is best. darcs send route (now possible, since darcs builds on x86_64)? darcs send is fine. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6.1 on Debian Etch?
Hi, what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? -- Thanks, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
On Tue, Jun 05, 2007 at 10:13:41PM +0200, Wagner Ferenc wrote: Hi, what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? Yes. Install the binary .tar.gz bundle *without creating a stub package* It installs in /usr/local, so dpkg must not know about it. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Gregory Wright wrote: The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug: http://hackage.haskell.org/trac/ghc/ticket/781 the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi. Hmm. I would have thought that the absolute addresses of static data in the shared library would have been resolved by the run time loader and written into the global offset table. It seems that all of the shared libraries on FreeBSD/amd64 are loaded at addresses above 2 GB, e.g., above 0x8. Perhaps rtld allocates space below 2GB and fills in adjusts the GOT to point to the data in lower memory. (There's not very much of it). I'll have to think about this a while. The linker allocates space for the data in the .data or .bss of the binary. e.g. this is what I get when I refer to environ from a C function: 00500aa8 wO .bss 0008 environ@@GLIBC_2.2.5 so at runtime, the linker must use this as the location for environ, and links the references from libc to here. In order to do this, the data must have been annotated with a .size directive in the shared library, so the linker knows how much space to allocate for it. In fact it does this for all static data references from the main program; this is the dreaded R_COPY relocation type. I don't really know if its possible to check whether a particular reference is to code or data in GHC's linker - how did you do this? Currently the linker just assumes they're all code, and allocates a jump table in the low 2Gb and re-route jumps through it (see x86_64_high_symbol() in rts/Linker.c). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
On Tue, May 29, 2007 at 04:15:29PM +0100, Simon Marlow wrote: What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. No ringing bells here I'm afraid. What you're seeing is a failure from the code that checks for memory leaks, which is only enabled by -debug (the threaded1 test way uses -threaded -debug). It reckons you have 508 blocks allocated from the OS, but can only account for 255 of them. You could try enabling some more debugging options, e.g. +RTS -DSb will enable sanity-checking and debugging messages from the block allocator. This, and with some more debugging output and gdb sessions, helped. The problem is that in hs_init(), initAdjustor() is called *before* initStorage(). initAdjustor() is a NOOP everywhere except for OpenBSD/i386, where it calls allocateExec(). Later in hs_init(), when initStorage() is invoked, the free_list is reset, but mblocks_allocated is still 1 = bummer. Now my GHC knowledge is still very rusty (I didn't look at it for years), so I really don't know wether that initAdjustor() is still needed nor what it's good for, or if its invocation can be moved after initStorage(). Any hint appreciated. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
Matthias Kilian wrote: On Tue, May 29, 2007 at 04:15:29PM +0100, Simon Marlow wrote: What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. No ringing bells here I'm afraid. What you're seeing is a failure from the code that checks for memory leaks, which is only enabled by -debug (the threaded1 test way uses -threaded -debug). It reckons you have 508 blocks allocated from the OS, but can only account for 255 of them. You could try enabling some more debugging options, e.g. +RTS -DSb will enable sanity-checking and debugging messages from the block allocator. This, and with some more debugging output and gdb sessions, helped. The problem is that in hs_init(), initAdjustor() is called *before* initStorage(). initAdjustor() is a NOOP everywhere except for OpenBSD/i386, where it calls allocateExec(). Later in hs_init(), when initStorage() is invoked, the free_list is reset, but mblocks_allocated is still 1 = bummer. Now my GHC knowledge is still very rusty (I didn't look at it for years), so I really don't know wether that initAdjustor() is still needed nor what it's good for, or if its invocation can be moved after initStorage(). Any hint appreciated. Nice catch. Looks to me like initAdjustor() can be moved after initStorage(). Please test the fix, if it works for you then send us the patch and we'll commit. You've been wasting 1Mb in every single executable on OpenBSD! In fact, I'm not even sure why OpenBSD needs that code, and it isn't commented. You might like to try removing obscure_ccall_ret_code_dyn and associated cruft and see what happens (i.e. try the ccall/should_run tests). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi, I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary. The binary works well enough to build itself and darcs. There are only sixteen unexpected test suite failures thus far. I am ignoring these for the moment while I get back to thinking about ghci. Note that you need to install libgmp to use the compiler. libgmp from the ports collection works fine. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Gregory Wright wrote: I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-freebsd.tar.bz2 yay! Ian will supply a link from the download page in due course, I'm sure. No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary. The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug: http://hackage.haskell.org/trac/ghc/ticket/781 the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi. Fortunately most code doesn't reference static data from shared libraries, so we get away with it most of the time. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi Simon, On May 30, 2007, at 4:05 PM, Simon Marlow wrote: Gregory Wright wrote: I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 yay! Ian will supply a link from the download page in due course, I'm sure. I still owe you some source patches to make the compiler build out of the box. If 6.6.1 is the end of the line, would you prefer that these be against HEAD? Should I ask for push permission or just send these via the usual darcs send route (now possible, since darcs builds on x86_64)? The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug: http://hackage.haskell.org/trac/ghc/ticket/781 the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi. Hmm. I would have thought that the absolute addresses of static data in the shared library would have been resolved by the run time loader and written into the global offset table. It seems that all of the shared libraries on FreeBSD/amd64 are loaded at addresses above 2 GB, e.g., above 0x8. Perhaps rtld allocates space below 2GB and fills in adjusts the GOT to point to the data in lower memory. (There's not very much of it). I'll have to think about this a while. Fortunately most code doesn't reference static data from shared libraries, so we get away with it most of the time. FreeBSD/amd64 seems to make a lot of references to static data. When I edited the Linker to ignore out of range relocations and print a message I got dozens while starting GHCi. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
Matthias Kilian wrote: I'm currently working on updating the GHC port to 6.6.1 for OpenBSD, and when I run the testsuite (ghc-regress), all test cases for the way threaded1, i.e. debug + threaded bail out with an assertion failure: Blocks: 132 live + 123 free = 255 total (508 around) conc010: internal error: ASSERTION FAILED: file Storage.c, line 1174 The numbers vary slightly, but there's always a total of 255 and 508 blocks around, except for one test case (con012), where there are a total of 763 blocks (1016 around). What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. No ringing bells here I'm afraid. What you're seeing is a failure from the code that checks for memory leaks, which is only enabled by -debug (the threaded1 test way uses -threaded -debug). It reckons you have 508 blocks allocated from the OS, but can only account for 255 of them. You could try enabling some more debugging options, e.g. +RTS -DSb will enable sanity-checking and debugging messages from the block allocator. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
Hi, I'm currently working on updating the GHC port to 6.6.1 for OpenBSD, and when I run the testsuite (ghc-regress), all test cases for the way threaded1, i.e. debug + threaded bail out with an assertion failure: Blocks: 132 live + 123 free = 255 total (508 around) conc010: internal error: ASSERTION FAILED: file Storage.c, line 1174 The numbers vary slightly, but there's always a total of 255 and 508 blocks around, except for one test case (con012), where there are a total of 763 blocks (1016 around). What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Sparc-Solaris / ghc docs Was: Re: ghc-6.6.1 Mac (Darwin) Binary Dists
Ian Lynagh schrieb: On Mon, May 14, 2007 at 02:07:11PM +0200, Christian Maeder wrote: Ian, could you add and upload these dists to http://www.haskell.org/ghc/download_ghc_661.html, too? Thanks for making them! They're now added, along with your Solaris builds. http://www.haskell.org/ghc/download_ghc_661.html#sparcsolaris This is a complete build, with profiling libraries and docs Sorry, the docs are not included here (only i386 Solaris made them). Maybe docs could be made available separately (they are missing for the macs, too.) Since, make binary-dist already packed everything I did not repack to include the docs. http://www.haskell.org/ghc/docs/latest/html/libraries/index.html misses the OpenAL documentation, or is there none for it? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 RPM packages for i386 and x86_64 architectures on RHEL 4 and 5
Hello group, Starting with Jens Peterson's packages for Fedora Core, I have built up the latest GHC RPMs for i386 and x86_64 on both RHEL4 and RHEL5. You can check them out at http://forte-intl.com/~ronald/haskell/ghc/. It was a fairly straightforward job due in large part to the very nice spec file written by Jens. Please add them to the Distribution Packages page at haskell.org/ghc. Thank you! Ronald Cole ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 Mac (Darwin) Binary Dists
On Mon, May 14, 2007 at 02:07:11PM +0200, Christian Maeder wrote: Ian, could you add and upload these dists to http://www.haskell.org/ghc/download_ghc_661.html, too? Thanks for making them! They're now added, along with your Solaris builds. I wonder what the build bots said to the testsuite. Even my i386-linux build had 10 failures: amd64/Linux and i386/Windows were both clean. Unexpected failures: conc019(ghci) conc024(ghci) conc049(opt) concprog001(opt,optasm,prof,profasm,threaded1) galois_raytrace(optasm,profasm) The galois_raytrace failures will just be floating point differences. The concurrency failures are something we'll have to look into for 6.8. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 Mac (Darwin) Binary Dists
I've made binary distributions for powerpc and intel macs that rely on a GNUreadline.framework and a GMP.framework that can be found (for both architectures) here: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac_e.htm http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/GNUreadline-framework.zip http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/GMP.framework.zip My ghc-6.6.1 distributions can be found here: i386: (41776873 Byte without documentation) http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/ghc-6.6.1-i386-apple-darwin.tar.bz2 powerpc: (49468070 Byte without documentation) http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/versions/ghc-6.6.1-powerpc-apple-darwin.tar.bz2 Ian, could you add and upload these dists to http://www.haskell.org/ghc/download_ghc_661.html, too? Further details see below. I wonder what the build bots said to the testsuite. Even my i386-linux build had 10 failures: OVERALL SUMMARY for test run started at Fr Mai 4 15:41:37 CEST 2007 1488 total tests, which gave rise to 7079 test cases, of which 2 caused framework failures 1246 were skipped 5773 expected passes 48 expected failures 0 unexpected passes 10 unexpected failures Unexpected failures: conc019(ghci) conc024(ghci) conc049(opt) concprog001(opt,optasm,prof,profasm,threaded1) galois_raytrace(optasm,profasm) Cheers Christian Remarks for both mac architectures: LD and SRC_HC_OPTS in libraries/readline/config.mk and compiler/Makefile.ghcbin have been adapted manually to point to the readline framework. config.mk: READLINE_BUILD_PACKAGE=yes LD=/usr/bin/ld -F/home/maeder/Library/Frameworks -framework GNUreadline SRC_HC_OPTS += -optc-I/home/maeder/Library/Frameworks/GNUreadline.framework/Headers -optl-F/home/maeder/Library/Framework -optl-framework -optlGNUreadline SRC_HSC2HS_OPTS += -I/home/maeder/Library/Frameworks/GNUreadline.framework/Headers For 'ghci -package X11' (or -package HGL) DYLD_LIBRARY_PATH has to be set to include /usr/X11R6/lib (although is lib-path is listed in package.conf). ghc-6.6.1-i386-apple-darwin was build using i686-apple-darwin8-gcc-4.0.1 required libraries: $ otool -L lib/i386-apple-darwin/ghc-6.6.1 lib/i386-apple-darwin/ghc-6.6.1: GNUreadline.framework/Versions/A/GNUreadline (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7) GMP.framework/Versions/A/GMP (compatibility version 7.0.0, current version 7.0.0) provided packages: ghc-6.6.1/lib/i386-apple-darwin/package.conf: Cabal-1.1.6.2, GLUT-2.1.1, HGL-3.1.1, HUnit-1.1.1, OpenAL-1.3.1, OpenGL-2.2.1, QuickCheck-1.0.1, X11-1.2.1, base-2.1.1, cgi-3001.1.1, fgl-5.4.1, filepath-1.0, (ghc-6.6.1), haskell-src-1.0.1, haskell98-1.0, html-1.0.1, mtl-1.0.1, network-2.0.1, parsec-2.0, readline-1.0, regex-base-0.72, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.1, time-1.1.1, unix-2.1, xhtml-3000.0.2 testsuite summary created by 'gmake stage=2' in testsuite: OVERALL SUMMARY for test run started at Fri May 11 17:15:13 CEST 2007 1488 total tests, which gave rise to 7079 test cases, of which 4 caused framework failures 1246 were skipped 5757 expected passes 48 expected failures 0 unexpected passes 24 unexpected failures Unexpected failures: conc019(ghci) conc024(normal,optasm,ghci) concprog001(normal,opt,optasm,prof,profasm) ffi009(threaded1) ffi012(normal,opt,optasm,prof,profasm,threaded1,threaded2) ffi016(normal,opt,optasm,prof) galois_raytrace(optasm,profasm) memo001(threaded2) ghc-6.6.1-powerpc-apple-darwin was build using powerpc-apple-darwin8-gcc-4.0.1 required libraries: $ otool -L lib/powerpc-apple-darwin/ghc-6.6.1 lib/powerpc-apple-darwin/ghc-6.6.1: GNUreadline.framework/GNUreadline (compatibility version 5.0.0, current version 5.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.9) GMP.framework/Versions/A/GMP (compatibility version 7.0.0, current version 7.3.0) provided packages: lib/powerpc-apple-darwin/package.conf: Cabal-1.1.6.2, GLUT-2.1.1, HGL-3.1.1, HUnit-1.1.1, OpenAL-1.3.1, OpenGL-2.2.1, QuickCheck-1.0.1, X11-1.2.1, base-2.1.1, cgi-3001.1.1, fgl-5.4.1, filepath-1.0, (ghc-6.6.1), haskell-src-1.0.1, haskell98-1.0, html-1.0.1, mtl-1.0.1, network-2.0.1, parsec-2.0, readline-1.0, regex-base-0.72, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.1, time-1.1.1, unix-2.1, xhtml-3000.0.2 testsuite summary created by 'gmake stage=2' in testsuite: OVERALL SUMMARY for test run started at Fri May 4 17:41:03 CEST 2007 1488 total tests, which gave rise to 7079 test cases
Re: ghc-6.6.1 under i386 Solaris
Christian Maeder schrieb: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. [New LWP 3] Loading package base ... linking ... done. Program received signal SIGSEGV, Segmentation fault. This segmentation fault does not happen for a distribution that I made using gcc-3.4.6 instead of gcc-4.1.2. Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Simon Marlow wrote: shelarcy wrote: Hi On Thu, 10 May 2007 18:36:22 +0900, Neil Mitchell [EMAIL PROTECTED] wrote: I've attached the installer source to this message, for you to play with/patch to your hearts content. I sent a copy to Ian a few days, so it should be appearing in the GHC tree at some point. I succeed to build installer with C++ files by it. include/mingw/c++/ doesn't cause any problem. So, now we're ready to include C++ files. Ok, I'm building a new tarball with GLUT and C++. The OpenAL/ALUT stuff looks a bit daunting at the moment. If someone tells me exactly what I need to install to make it work, then I'll do that. This tarball has GLUT and C++: http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-unknown-mingw32.tar.bz2 (48M) GLUT doesn't actually work for me, becuase I apparently don't have the right DLL, but the package built without any problems after I copied the missing glut.h header over. If someone could update the installer using that tarball, that'd be great. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi Ok, I'm building a new tarball with GLUT and C++. The OpenAL/ALUT stuff looks a bit daunting at the moment. If someone tells me exactly what I need to install to make it work, then I'll do that. This tarball has GLUT and C++: http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-unknown-mingw32.tar.bz2 (48M) GLUT doesn't actually work for me, becuase I apparently don't have the right DLL, but the package built without any problems after I copied the missing glut.h header over. If someone could update the installer using that tarball, that'd be great. New installer uploaded, as the standard Windows installer. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 win32 msi available
On Tue, May 08, 2007 at 03:25:31PM -0700, Sigbjorn Finne wrote: In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; Thanks Sigbjorne, I've added it to the download page! Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi. On Sat, 12 May 2007 00:44:15 +0900, Neil Mitchell [EMAIL PROTECTED] wrote: Ok, I'm building a new tarball with GLUT and C++. The OpenAL/ALUT stuff looks a bit daunting at the moment. If someone tells me exactly what I need to install to make it work, then I'll do that. OK, I see, This tarball has GLUT and C++: http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-unknown-mingw32.tar.bz2 (48M) GLUT doesn't actually work for me, becuase I apparently don't have the right DLL, but the package built without any problems after I copied the missing glut.h header over. I confirmed GLUT works with this dll. http://www.xmission.com/~nate/glut.html On Thu, 10 May 2007 22:50:05 +0900, shelarcy [EMAIL PROTECTED] wrote: But MinGW continues to use old one now. http://www.mingw.org/MinGWiki/index.php/Glut Above URL links that page, so I think that is right one, If someone could update the installer using that tarball, that'd be great. New installer uploaded, as the standard Windows installer. Neil, Simon, thank you very much for discussing binary distribution with me and providing new better binary and installer. Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi, On Wed, 09 May 2007 17:31:51 +0900, Simon Marlow [EMAIL PROTECTED] wrote: So to summarise, the following are missing from the binary distribution that Neil used as the basis for his installer: * readline * ALUT * OpenAL * GLUT * C++ support in the bundled GCC right? Yes. And Sigbjorn's one provides these packages. It lacks just C++ files. http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012538.html There is no C++ files in your installer. But if anyone want to build C++ source code by GHC, he disappoint about that. http://hackage.haskell.org/trac/ghc/ticket/1024 http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/thread.html#12408 The reason I didn't enable C++ support in prep-bin-dist-mingw is because of that comment, and because I don't know how to test it. Basically I chickened out. Are you saying it should just be uncommented in prep-bin-dist-mingw? Yes, and if new installer also cause that problem, I want to know it. I don't have InstallerShield, so I don't fix its problem. But Inno Setup is OpenSource, so, although Neil doesn't fix this problem on current time, we can fix this (Of cource, installer's source must be available). And I think it's good time to fix installer's problem when someone release binary distribution. Because we aren't insterested in chanaging installer source before release time. I think a few of its reason is we can't fix installer easily, and if someone want to use development version, she can build binary herself or download snapshot build. And she want to use installer only at that very moment when new version is released. Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
On Wed, 09 May 2007 17:31:51 +0900, Simon Marlow [EMAIL PROTECTED] wrote: You forgot to include GLUT and readline packages. I think you can't build these packages, so you don't include it. This is well-known problem, if build GHC your self. Because MInGW doesn't have these headers and library files in its directory. http://www.haskell.org/pipermail/glasgow-haskell-users/2006-October/011253.html http://www.haskell.org/pipermail/haskell/2006-December/018919.html So you must copy these files from old GHC's directory first, and then building new GHC. That sounds scary - what about incompatible versions? OpenGL is just Rendering Engine, and it doesn't provide any UI. So if someone want to use OpenGL, he must install other packages. GLUT or wxHaskell, Gtk2HS, HSDL, etc So I think GLUT is important package, before we get caball-install. I don't know about readline package. Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
On Wed, 09 May 2007 17:42:11 +0900, Neil Mitchell [EMAIL PROTECTED] wrote: Custom/complete: yes, typical: no. What on earth does typical mean? The user has no idea whether it will install the features they need or not, so it's a meaningless option. From all I can tell, GHC 6.6 has all these options, but they all do the same thing! If you select custom you can choose whether or not to install GHC, but thats as fine-grained as the control gets. The options I was thinking off were: * GHC (always required) * Profiling libraries * HTML documentation * Register .hs and .lhs extensions * Set the GHC %PATH% * Set the Cabal %PATH% With the Complete (recommended and default) install being all of them, Minimal (lacking HTML and profiling) and custom for anything else. I think we can also ignore theirs on future. * all extra libraries (we don't have caball-install now) * C++ files (if someone doesn't want to compile C++. But we don't support these yet) Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
shelarcy wrote: Hi, On Wed, 09 May 2007 17:31:51 +0900, Simon Marlow [EMAIL PROTECTED] wrote: So to summarise, the following are missing from the binary distribution that Neil used as the basis for his installer: * readline * ALUT * OpenAL * GLUT * C++ support in the bundled GCC right? Yes. And Sigbjorn's one provides these packages. Ok, but I don't know how to build these libraries. You mentioned copying the files from the old GHC distribution, but that sounds exceedingly dodgy, since they're from a different version of mingw. And I can't find these libraries to download on the mingw site. Any ideas? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi On Thu, 10 May 2007 18:36:22 +0900, Neil Mitchell [EMAIL PROTECTED] wrote: I've attached the installer source to this message, for you to play with/patch to your hearts content. I sent a copy to Ian a few days, so it should be appearing in the GHC tree at some point. I succeed to build installer with C++ files by it. include/mingw/c++/ doesn't cause any problem. So, now we're ready to include C++ files. Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 win32 msi available
Hi Sigbjorn, On Wed, 09 May 2007 07:25:31 +0900, Sigbjorn Finne [EMAIL PROTECTED] wrote: In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; most (all?) libraries/ are in there; no C++ bits (sorry.) It looks that your openal32.dll is very old. So openal32.dll doesn't have alGetSurceiv function. C:\home\ghc\libraries\ALUT\examples\BasicC:\home\ghc-6.6.1\bin\ghc.exe HelloWor ld.hs --make [1 of 1] Compiling Main ( HelloWorld.hs, HelloWorld.o ) Linking HelloWorld.exe ... C:/home/ghc-6.6.1/libHSOpenAL.a(Source__100.o):: undefined reference to `alGetSo urceiv' collect2: ld returned 1 exit status How about use newer version? You can download OpenAL 1.1 version dll from OpenAL site's links. http://www.openal.org/downloads.html Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
On Thu, 10 May 2007 18:11:52 +0900, Simon Marlow [EMAIL PROTECTED] wrote: So to summarise, the following are missing from the binary distribution that Neil used as the basis for his installer: (snip) right? Yes. And Sigbjorn's one provides these packages. Ok, but I don't know how to build these libraries. You mentioned copying the files from the old GHC distribution, but that sounds exceedingly dodgy, since they're from a different version of mingw. And I can't find these libraries to download on the mingw site. Any ideas? * ALUT and OpenAL We can download freeALUT and OpenAL SDK (and runtime) from OpenAL site's link. http://www.openal.org/downloads.html MinGW supports to link .dll files (yes, we know that) and .lib files directory now. So I belive that we can use these library. http://www.mingw.org/MinGWiki/index.php/FAQ http://hackage.haskell.org/trac/ghc/ticket/1243 * GLUT MinGW has GLUT library files, but ... distributor forgot to include GLUT header. So this problem is solved by just copying glut.h file. Now we can use newer extention of GLUT - freeGLUT. http://freeglut.sourceforge.net/ http://www.haskell.org/pipermail/hopengl/2006-December/000679.html But MinGW continues to use old one now. http://www.mingw.org/MinGWiki/index.php/Glut * readline I don't know about readline library. When I use newer version form WebSite (I forgot where that is), but I can't build readline package by it. I think Sigbjorn can answer that. Best Reards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 under i386 Solaris
Hi, the stage2 compiler I've created from the official sources almost works, but ghci crashes with seg-fault. Any ideas? -bash-3.1$ gdb --args /localdisk/maeder/haskell/ghc-6.6.1/compiler/stage2/ghc-6.6.1 -B/localdisk/maeder/haskell/ghc-6.6.1 --interactive GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-pc-solaris2.10... (gdb) run Starting program: /localdisk/maeder/haskell/ghc-6.6.1/compiler/stage2/ghc-6.6.1 -B/localdisk/maeder/haskell/ghc-6.6.1 --interactive warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 [New LWP 1] [New LWP 2] ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. [New LWP 3] Loading package base ... linking ... done. Program received signal SIGSEGV, Segmentation fault. 0x08cd0980 in ?? () (gdb) where #0 0x08cd0980 in ?? () #1 0xfd90 in ?? () #2 0xa39cbf6c in ?? () #3 0x00010980 in ?? () #4 0x0004 in ?? () #5 0x0001433c in ?? () #6 0x08a5f448 in MainCapability () #7 0x0001 in ?? () #8 0x08cd0980 in ?? () #9 0x9b726b40 in ?? () #10 0x9b726ab8 in ?? () #11 0x08a5f448 in MainCapability () #12 0x in ?? () (gdb) quit The program is running. Exit anyway? (y or n) y -bash-3.1$ uname -a SunOS isaac 5.10 Generic_118855-36 i86pc i386 i86pc ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
shelarcy wrote: Hi On Thu, 10 May 2007 18:36:22 +0900, Neil Mitchell [EMAIL PROTECTED] wrote: I've attached the installer source to this message, for you to play with/patch to your hearts content. I sent a copy to Ian a few days, so it should be appearing in the GHC tree at some point. I succeed to build installer with C++ files by it. include/mingw/c++/ doesn't cause any problem. So, now we're ready to include C++ files. Ok, I'm building a new tarball with GLUT and C++. The OpenAL/ALUT stuff looks a bit daunting at the moment. If someone tells me exactly what I need to install to make it work, then I'll do that. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: problems using ghc-6.6.1 (due to fgl-5.4.1)
Aha! So the problem is a library change rather than a compiler change. That's a relief. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Christian Maeder | Sent: 08 May 2007 22:33 | To: [EMAIL PROTECTED]; GHC Users Mailing List; [EMAIL PROTECTED] | Subject: problems using ghc-6.6.1 (due to fgl-5.4.1) | | I wrote: | Dear Hets- and GHC-Developers, | | we have a problem using ghc-6.6.1. The created hets binary runs a | couple | of times slower than the one created using ghc-6.6. | | This problem is gone when I install and use fgl-5.3 (where hiding | (indices) needs to be deleted in Data.Graph.Inductive.Monad.IOArray). | | I strongly suspect the new functions context1l' and context4l' in | Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic | slow down. | | In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic | edge (an edge from and to the very same node) was only returned as | ingoing edge and not as outgoing one. (a design decision documented | elsewhere). | | I think, the change in fgl-5.4.1 now returns a cyclic edge also as | outgoing edge (and possibly twice as ingoing one). | | Our application heavily uses in- and outgoing edges that may be cyclic. | | Christian | | P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 | | ___ | 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: GHC 6.6.1 Windows installer, test version
So to summarise, the following are missing from the binary distribution that Neil used as the basis for his installer: * readline * ALUT * OpenAL * GLUT * C++ support in the bundled GCC right? I can try to roll another binary distribution, but I don't know much about these packages or C++ support so I'm guessing a bit. shelarcy wrote: You forgot to include GLUT and readline packages. I think you can't build these packages, so you don't include it. This is well-known problem, if build GHC your self. Because MInGW doesn't have these headers and library files in its directory. http://www.haskell.org/pipermail/glasgow-haskell-users/2006-October/011253.html http://www.haskell.org/pipermail/haskell/2006-December/018919.html So you must copy these files from old GHC's directory first, and then building new GHC. That sounds scary - what about incompatible versions? There is no C++ files in your installer. But if anyone want to build C++ source code by GHC, he disappoint about that. http://hackage.haskell.org/trac/ghc/ticket/1024 http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/thread.html#12408 The reason I didn't enable C++ support in prep-bin-dist-mingw is because of that comment, and because I don't know how to test it. Basically I chickened out. Are you saying it should just be uncommented in prep-bin-dist-mingw? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
shelarcy wrote: GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. Custom/complete: yes, typical: no. What on earth does typical mean? The user has no idea whether it will install the features they need or not, so it's a meaningless option. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. Custom/complete: yes, typical: no. What on earth does typical mean? The user has no idea whether it will install the features they need or not, so it's a meaningless option. From all I can tell, GHC 6.6 has all these options, but they all do the same thing! If you select custom you can choose whether or not to install GHC, but thats as fine-grained as the control gets. The options I was thinking off were: * GHC (always required) * Profiling libraries * HTML documentation * Register .hs and .lhs extensions * Set the GHC %PATH% * Set the Cabal %PATH% With the Complete (recommended and default) install being all of them, Minimal (lacking HTML and profiling) and custom for anything else. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems using ghc-6.6.1
Christian Maeder wrote: Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Very strange. The performance has decreased dramatically, but the profile looks the same: that is, performance has degraded more or less consistently across the whole code. I have to ask: did you turn on -O? Cheers, Simon Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_signCASL.Sublogic 5.33.7 compInclusion Logic.Grothendieck 3.23.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.51.6 isSubOpMap CASL.Sign 1.20.9 primCoerce Logic.Coerce 0.81.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_signCASL.Sublogic 6.84.2 compInclusion Logic.Grothendieck 3.73.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.83.1 isSubOpMap CASL.Sign 1.61.1 sublogics_join CASL.Sublogic 1.51.1 primCoerce Logic.Coerce 1.31.4 isSameTranslation Proofs.Local 1.20.9 ___ 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: problems using ghc-6.6.1
Simon Marlow schrieb: Christian Maeder wrote: Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Very strange. The performance has decreased dramatically, but the profile looks the same: that is, performance has degraded more or less consistently across the whole code. I have to ask: did you turn on -O? -O was turned off in both cases. (Optimization usually only accounts for a factor of 3 -- and not 8 or even more.) Sorry for my panic. The slow down is caused by the last change described in http://web.engr.oregonstate.edu/~erwig/fgl/haskell/CHANGES The additional loops in Data.Graph.Inductive.Graph (also added at the end of a possibly long list) make our algorithm slower. context1l' :: Context a b - Adj b context1l' (p,v,_,s) = p++filter ((==v).snd) s context4l' :: Context a b - Adj b context4l' (p,v,_,s) = s++filter ((==v).snd) p Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 win32 msi available
[My apologies for the long'ish e-mail, for Win9x users mostly..] Someone sent an e-mail querying about Win9x compatibility, which is something I forgot to take into account when building the 6.6.1 installer. To remedy, I've refreshed the installer to include a new version that ought to work across a wider spectrum of MS OS versions releases -- http://galois.com/~sof/msi/ghc-6-6-1.msi Notice that since the GHC binary is now being linked with a 'threaded' RTS, some non-Win9x compatible portions of the Win32 API is being used depended upon, causing DLL resolution at startup to miserably fail. To counter and workaround this, I've included bin/ghc-u.exe with the refreshed installer, which is an unthreaded (and faster..) version of the compiler (= GHCi.) So, to get a working system under Win9x, you'll need to either use ghc-u directly, or rename it as ghc.exe (and, as a result, enable 'ghci.exe' usage.) Also, as with ghc-6.6, if you intend to distribute your 6.6.1-compiled code that uses the Win32 package, and have it work on Win9x platforms, you'll need to include the Unicode API layer DLL, which you'll find in bin/ as unicows.dll hth --sigbjorn On 5/8/2007 15:25, Sigbjorn Finne wrote: In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; most (all?) libraries/ are in there; no C++ bits (sorry.) enjoy --sigbjorn [And, if it's your preference, a ghc-6-6-1.zip is also available from that same dir.] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi You forgot to include GLUT and readline packages. I think you can't build these packages, so you don't include it. I have built an installer for the binary package produced by the GHC Team, including whatever they included, and excluding whatever they excluded. If the GHC Team change their build so these are built, I will happily include whatever they tell me. And can you add Installation Mode to your installer? There is already a silent install mode, /SILENT or /VERYSILENT do something - but I have no idea what. Is that what you meant by Installation Mode? There is no C++ files in your installer. But if anyone want to build C++ source code by GHC, he disappoint about that. As before, what goes in the package is someone elses choice. This installer is intended as something quick to get a working installer out the door. I'd like to think about beefing it up, offering extra options (possibly C++ support) in the next version (i.e. 6.8, 6.6.2) So I think we will become happy, if adding Installation Mode and maintain that on GHC's darcs repository. I'm still not entirely sure what you mean by this? Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
On Tue, 08 May 2007 19:04:33 +0900, Neil Mitchell [EMAIL PROTECTED] wrote: You forgot to include GLUT and readline packages. I think you can't build these packages, so you don't include it. I have built an installer for the binary package produced by the GHC Team, including whatever they included, and excluding whatever they excluded. If the GHC Team change their build so these are built, I will happily include whatever they tell me. It's wrong about buildable packages and C++ files. First, make binary-dist includes these packages in binary distribution if you can build theirs. GHC 6.4 and GHC 6.6.1 or above installers include theirs. And if you can build OpenAL and ALUT, you can include these packages to your installer. Second, I can include C++ files (except header files) in binary by make binary-dist command with MinGW-4.1.1. http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/012410.html http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/012413.html So I want to know What version of MinGW do you use? and Is your MinGW has C++ files? If you don't find C++ files in your MinGW directory, I think you probably choice not to install C++/g++ things. So if you find your MinGW doesn't include C++ files, you must install these files first. And then you try to use make binary-dist command and make installer again. There is no C++ files in your installer. But if anyone want to build C++ source code by GHC, he disappoint about that. As before, what goes in the package is someone elses choice. This installer is intended as something quick to get a working installer out the door. I'd like to think about beefing it up, offering extra options (possibly C++ support) in the next version (i.e. 6.8, 6.6.2) So above tasks will be complete just checking and correcting your build enviornment. An lack is C++ header files, but you can fix this problem by changing to comment out or remove dist/prep-bin-dist-mingw's below line. rm -rf include/mingw/c++/ || echo c++/ not there I think these tasks are easy, and they don't become bottleneck to release installer. And can you add Installation Mode to your installer? There is already a silent install mode, /SILENT or /VERYSILENT do something - but I have no idea what. Is that what you meant by Installation Mode? GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. I want to say that. But that is difficult task, so I wait that for the next version. Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problems using ghc-6.6.1
Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_signCASL.Sublogic 5.33.7 compInclusion Logic.Grothendieck 3.23.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.51.6 isSubOpMap CASL.Sign 1.20.9 primCoerce Logic.Coerce 0.81.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_signCASL.Sublogic 6.84.2 compInclusion Logic.Grothendieck 3.73.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.83.1 isSubOpMap CASL.Sign 1.61.1 sublogics_join CASL.Sublogic 1.51.1 primCoerce Logic.Coerce 1.31.4 isSameTranslation Proofs.Local 1.20.9 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems using ghc-6.6.1
You seem to be generating 8x the garbage with the 6.6.1 version which could account for the 2x slowdown. On May 8, 2007, at 2:19 PM, Christian Maeder wrote: ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi So I want to know What version of MinGW do you use? and Is your MinGW has C++ files? None, I don't have it installed. I took the binaries straight from the GHC 6.6.1 .tar.bz on haskell.org, I guess Ian would know how they build that. I think these tasks are easy, and they don't become bottleneck to release installer. As before, its not something I have any power over. GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. I'll add that, its not overly hard, but I want something functional, robust and now. For the next version you'll have options over what to install. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problems using ghc-6.6.1 (due to fgl-5.4.1)
I wrote: Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where hiding (indices) needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 win32 msi available
In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; most (all?) libraries/ are in there; no C++ bits (sorry.) enjoy --sigbjorn [And, if it's your preference, a ghc-6-6-1.zip is also available from that same dir.] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Neil Mitchell wrote: Hi, I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as an official installer, could people please test it? http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe Thanks Neil, This works perfectly! Best regards, Brian. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Neil Mitchell wrote: Hi, I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as an official installer, could people please test it? http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe Thanks for that. It seems to install and compile the collections package OK so I guess it's working. Regards -- Adrian Hey ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6.1 Release Candidate
On Apr 11, 2007, at 19:39 , Thorkil Naur wrote: Hello, On Tuesday 10 April 2007 16:41, Ian Lynagh wrote: We are pleased to announce the Release Candidate phase for GHC 6.6.1. ... A few comments to the source bundles http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410- src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src- extralibs.tar.bz2 1. There are binary (.p_o and .p_hi) files present in libraries/HGL/Graphics/HGL/X11 and below. 2. On my PPC Mac OS X 10.4, configure reports checking for DocBook XSL stylesheet directory... no configure: WARNING: cannot find DocBook XSL stylesheets, you will not be able to build the documentation Some time ago, I installed docbook-xsl from mac/darwinports and this complaint disappeared from the HEAD, but not from the 6.6 branch. The relevant HEAD change is this: diff ghc-6.6-for-buildbot-20070221_1000/ghc/configure.ac ghc-HEAD-for-669-20070324_1621/ghc/configure.ac ... 931c976 FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/ current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/ docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/ share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/ docbook /sw/share/xml/xsl/docbook-xsl]) --- FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/ current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/ docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/ share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/ docbook /sw/share/xml/xsl/docbook-xsl /opt/local/share/xsl/d ocbook-xsl]) ... I suppose it would be useful for this change to be merged to 6.6.1. This is the relevant darcs patch: Mon Sep 18 16:28:31 PDT 2006 [EMAIL PROTECTED] * Added Darwinports path to DocBook XSL stylesheets to configure. M ./configure.ac -1 +1 /Björn___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6.1 Release Candidate
Thorkil Naur wrote: Hello, On Tuesday 10 April 2007 16:41, Ian Lynagh wrote: We are pleased to announce the Release Candidate phase for GHC 6.6.1. ... A few comments to the source bundles http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src-extralibs.tar.bz2 1. There are binary (.p_o and .p_hi) files present in libraries/HGL/Graphics/HGL/X11 and below. Thanks, this should now be fixed (from tomorrow's snapshot onwards). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6.1 Release Candidate
Hello, On Tuesday 10 April 2007 16:41, Ian Lynagh wrote: We are pleased to announce the Release Candidate phase for GHC 6.6.1. ... A few comments to the source bundles http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src-extralibs.tar.bz2 1. There are binary (.p_o and .p_hi) files present in libraries/HGL/Graphics/HGL/X11 and below. 2. On my PPC Mac OS X 10.4, configure reports checking for DocBook XSL stylesheet directory... no configure: WARNING: cannot find DocBook XSL stylesheets, you will not be able to build the documentation Some time ago, I installed docbook-xsl from mac/darwinports and this complaint disappeared from the HEAD, but not from the 6.6 branch. The relevant HEAD change is this: diff ghc-6.6-for-buildbot-20070221_1000/ghc/configure.ac ghc-HEAD-for-669-20070324_1621/ghc/configure.ac ... 931c976 FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/docbook /sw/share/xml/xsl/docbook-xsl]) --- FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/docbook /sw/share/xml/xsl/docbook-xsl /opt/local/share/xsl/d ocbook-xsl]) ... I suppose it would be useful for this change to be merged to 6.6.1. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 6.6.1 Release Candidate
We are pleased to announce the Release Candidate phase for GHC 6.6.1. Snapshots beginning with 6.6.20070409 are release candidates for 6.6.1 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070409-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070409-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 currently binary distributions for x86_64/Linux and i386/Linux. More may appear later. The Windows (mingw) binary distributions are currently broken, but we hope to have this resolved soon. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope to release in a couple of weeks, but of course that may slip if problems are uncovered. 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: ghc 6.6.1?
C.M.Brown wrote: I was wondering when ghc-6.6.1 will be released? I am asking because a patch has been made to the ghc repo to allow multple calls to the ghc.newSession within the API and HaRe depends on this. We haven't fixed a deadline yet, since there are a large number of outstanding bugs milestoned for 6.6.1. I'd expect a release within a couple of months, something like that. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.6.1?
Hi, I was wondering when ghc-6.6.1 will be released? I am asking because a patch has been made to the ghc repo to allow multple calls to the ghc.newSession within the API and HaRe depends on this. Regards, Chris. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
