RE: (alpha) stick shift cabal install for GHC 6.12.1
Dave Bayer wrote: There's clearly something wrong with this picture. A Rorschach blot test as to what's wrong, but I see people overreaching, if I have to wait weeks for a simple install tool, then months for the Haskell Platform to be ready. Hopefully future GHC releases will go more smoothly as far as having cabal-install ready is concerned. But generally I think it's right to have a gap between a GHC major release and the corresponding HP release, in which to plan and manage any migration required. In that gap only library authors and users who don't mind some breakage would be expected to use the new GHC. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (alpha) stick shift cabal install for GHC 6.12.1
On Thu, Dec 17, 2009 at 4:00 PM, Dave Bayer ba...@cpw.math.columbia.edu wrote: Background: I never got cabal install to work on OS X 10.5 with GHC 6.10.4, basically because zlib wouldn't work. Odd, because a perfectly good version of gunzip already exists on most platforms, and the code doesn't fall back to this version if needed. Do you have any more information about this failure? It seems like it would be easier to get zlib to work than to replicate cabal-install. My painful story of getting zlib to work on 10.6 is chronicled here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-November/018068.html But my problem should only have been an issue on OS X 10.6, not any version lower. Antoine ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (alpha) stick shift cabal install for GHC 6.12.1
On Thu, 2009-12-17 at 14:00 -0800, Dave Bayer wrote: Background: I never got cabal install to work on OS X 10.5 with GHC 6.10.4, basically because zlib wouldn't work. Odd, because a perfectly good version of gunzip already exists on most platforms, and the code doesn't fall back to this version if needed. Do you mean OSX 10.5 or 10.6. I've never heard of major problems on 10.5 and lots of problems on 10.6. The latter are all fixable. The issue on 10.6 was that gcc defaults to compiling 64bit, but ghc expects 32bit. The hack for ghc-6.10.4 was to change the wrapper script to pass -optc-m32 -optl-m32. That's enough to get ghc working, but for other packages that bind to foreign libs you also need to apply the same trick to hsc2hs. That's why so many people bumped into zlib not working, it was because their hsc2hs was thinking it should be using 64bit when everything else was expecting 32bit. That manifested in a zlib initialisation error (because the structure size check fails). So in short, the problems are not with cabal or zlib, you just need a fully working ghc installation. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (alpha) stick shift cabal install for GHC 6.12.1
On Dec 18, 2009, at 5:27 AM, Antoine Latter wrote: Do you have any more information about this failure? It seems like it would be easier to get zlib to work than to replicate cabal-install. From http://www.reddit.com/r/haskell/comments/afz6n/cabalinstallpy/ : dcoutts BTW, the reason you could not get cabal-install working on your OSX 10.6 is because you did not have a fully working GHC installation and zlib (a dep of cabal-install) was the first thing to trip over this. Since GHC-6.10.4 does not work out of the box on OSX 10.6 you followed some hints to modify the ghc wrapper script to pass the gcc flags -m32. The bit you missed is that you need to do the same for hsc2hs. Otherwise hsc2hs generates code that assumes you're targeting the 64bit ABI. That's why the zlib initialisation check fails, because the code calling zlib has been compiled for the wrong size of everything. Syzygies Bingo, that sounds right, it's a relief to know what happened. There's plenty of advice on the web to just modify the ghc script itself for GHC-6.10.4 on OSX 10.6. I knew to modify more scripts, but I missed hsc2hs. I had gotten as far as figuring out that zlib itself was broken, and I had set up some sandbox clean development volume images for testing, when I noticed that GHC-6.12.1 was out. And that cabal-install wasn't ready yet.___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
openFd under -threaded gets interrupted
Hi!
I have written about this to Haskell cafe and they advised me to write it here.
I have a problem that I cannot open /dev/rfcomm0 device if I compile
my program with -threaded option. Like:
fd - openFd /dev/rfcomm0 ReadWrite Nothing OpenFileFlags { append =
False, noctty = True, exclusive = False, nonBlock = True, trunc =
False }
If I compile my program with -threaded option I always get such error:
interrupted (Interrupted system call)
But without -threaded it works flawlessly. I am using Linux 2.6.30
amd64, GHC 6.10.4. It was the same with 6.8. And I have tested it also
on 6.12.1.
After some testing I have discovered that the problem is only with
/dev/rfcomm0 as a device, that is with Bluetooth serial connection.
The problem is that rfcomm Linux kernel code contains:
if (signal_pending(current)) {
err = -EINTR;
break;
}
So if during open call some signal comes it returns EINTR. As it has
to open a connection to a Bluetooth device opening a /dev/rfcomm0 file
requires some time and during that time obviously there is some signal
sent by GHC with -threaded option which is not sent without it.
So please tell me what is the difference between open with and without
-threaded option in GHC as I would like to make a simple C test case.
I am not really sure if this is a feature or a bug in Linux Bluetooth
kernel implementation. But in combination with threaded GHC it makes
not working.
Also is there any workaround possible in Haskell/GHC? For example
making time while openFd is in progress without interrupts?
I have found very similar bug reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=161314
but code from the patch does not seem to be included in official
kernel source code (but it is also a long time ago so many things have
probably changed). But the workaround mentioned there is working also
here. If I open /dev/rfcomm0 with some other program (so that
Bluetooth connection is made) before I run Haskell program then it
works in both cases, with or without -threaded option. Of course this
is not really useful workaround in my case, I would like to make a
stand-alone Haskell program. So if it is similar to that bug then
maybe it is a bug in Linux kernel.
So please help me solve this problem.
Mitar
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cabal-install-0.8 final testing
All, If you'd like to help test the new cabal-install-0.8 release then grab it here: http://haskell.org/cabal/release/cabal-install-0.8.0/ It should work with ghc-6.10 and 6.12 (and indeed 6.8 and 6.6). If nobody reports any major show stoppers then I'll upload this to hackage. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: openFd under -threaded gets interrupted
Quoth Mitar mmi...@gmail.com, Also is there any workaround possible in Haskell/GHC? For example making time while openFd is in progress without interrupts? You might try something like this: import System.Posix.Signals ... setSignalMask fullSignalSet fd - openFd ... setSignalMask emptySignalSet I'm not in a position to try it in exactly the same situation, but I see that when I run with all signals blocked as above, after a while I have a SIGALRM pending (with -threaded or not), so I reckon that might be the signal used by the runtime thread manager. If it works, I would recommend blocking only that signal during the openFd, so for example you'll be able to abort normally with SIGINT if the device is stuck. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
parList implementation question
Hello, In Control.Parallel.Strategies, parList is defined as parList strat [] = () parList strat (x:xs) = strat x `par` (parList strat xs) with parMap strat f xs = map f xs `using` parList strat. I have recently found that if I define forceParMap strat f xs = map f xs `using` forceParList strat where forceParList strat = foldl (\done - (done||) . strat) () then to date, forceParList via forceParMap gives faster results than parList via parMap. For example, in one experiment, parMap with parList run at 0.81 the time of the serial solution whereas forceParMap with forceParList run at 0.58 the time of the serial solution. This is to say, forceParList completed in 0.72 the time of parList. So, 1. Why is forceParList faster than parList? 2. Is this generic to the ghc runtime model or a particularity of the ghc implementation? Thanks in advance for the clarification, - Marcus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: openFd under -threaded gets interrupted
Hi! On Fri, Dec 18, 2009 at 7:15 PM, Donn Cave d...@avvanta.com wrote: setSignalMask fullSignalSet fd - openFd ... setSignalMask emptySignalSet Thanks! This did it. At the end it is enough to block just virtualTimerExpired signal and it works. Probably it is something RTS is using internally? Mitar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parList implementation question
On Fri, Dec 18, 2009 at 11:31, Marcus D. Gabriel mar...@gabriel.name wrote: than parList via parMap. For example, in one experiment, parMap with parList run at 0.81 the time of the serial solution whereas forceParMap with forceParList run at 0.58 the time of the serial solution. This is to say, forceParList completed in 0.72 the time of parList. So, I don't know your application, so it's hard to interpret your numbers. Are you sure those measurements are statistically significant? -- Denis ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC-6.12.1: broken configure
I want to build ghc for i586-alt-linux-gnu. ./configure --host=i586-alt-linux-gnu --build=i586-alt-linux-gnu checking for gfind... no checking for find... /bin/find checking for sort... /bin/sort checking for ghc... /usr/bin/ghc checking version of ghc... 6.10.1 Target platform inferred as: i386-unknown-linux Unknown arch i586 Why i586 is unknown? It's a valid architecture. Why does it check vendor? Many of distribution define own vendor. Why do not use config.guess to guess correct host/target/build instead of reinvent wheel? Please fix it. It will simplify packaging GHC for distributions. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
