- Glasgow-haskell-users

x64 linux, x86 program and libgmp shared library
by Bulat Ziganshin 22 Dec '09

22 Dec '09

Hello glasgow-haskell-users, i compile my program for linux using ghc 6.6.1 (32-bit) user of my program asks: "any plans of making a static build for linux? that one does not work under x86-64 due to dependencies, missing libgmp which it seems is not available under 64bit. i could be wrong tho." how this may be resolved? should libgmp be available in x64 linux, or i should change compile options? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 4

Re: cabal-install-0.8 final testing
by Duncan Coutts 22 Dec '09

22 Dec '09

On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote: > Hi Duncan, > > Installation was easy (I typed "cabal-install HTTP zlib > cabal-install" ;-). Thanks for testing it. I've uploaded it to hackage. > Overall, seems to work fine. I couldn't build darcs, but I couldn't do > that by hand either; I used their binary installer. I don't think they > build yet under GHC 6.12.1. > > One oddity, I tried to use cabal install to install mmap, and it > failed because the HUnit package was missing. I then installed HUnit > without incident, went back and installed mmap without incident. No > idea why this didn't work in one pass, but I have "sandbox" systems if > you'd like me to see if I can reliably reproduce this. Mm. This is a worse bug than I thought. It's not trivial to fix. I'll have to think about it. The problem is mmap uses: Executable mmaptest Main-is: tests/mmaptest.hs if flag(mmaptest) Buildable: True else Buildable: False Build-depends: base<5, bytestring, HUnit, directory Now the question is what does this mean exactly. The previous version of Cabal said essentially "well the executable needs HUnit thus the package needs HUnit". This despite the fact that we're not going to actually built this test executable! The current Cabal code takes a slightly different approach. It says at the end "oh this exe isn't buildable, so its deps do not contribute to the deps of the package". The problem is what it was doing before that. It sees the dependency on HUnit and checks that it can be satisfied. It's only at the end that it ends up discarding it. So if it was not actually available then it fails earlier. The reason it's then inconsistent between configuring a package and what the cabal install planner is doing is that the planner assumes all the packages on hackage are available (sort of) while when we get to actually configuring a package to install it, only the other installed packages are available. So that's why the same solver gives us different answers, because we're making different assumptions about the available packages. So the issue is we need to treat "Buildable: False" specially in the solver because if we end up picking a configuration with "Buildable: False" for a component then have to have not already required the dependencies for that component. Essentially we want to reinterpret it as something like: if flag(test) Buildable: True Build-depends: base<5, bytestring, HUnit, directory else Buildable: False So that the dependencies themselves are conditional on the component being buildable. Then the solver would do the right thing. In general I guess the transformation would look like: if A1 Buildable: False if A2 Buildable: False ... if B1 Build-depends: blah if B2 Build-depends: blah where A1,A2,... and B1,B2,... are arbitrary conditions (including none) then this becomes: if A1 Buildable: False if A2 Buildable: False ... if B1 && ! (A1 || A2 || ...) Build-depends: blah if B2 && ! (A1 || A2 || ...) Build-depends: blah ... I don't especially like this though. It makes the meaning of buildable rather magic. In the short term I may have to revert the change in behaviour so that these dependencies become unconditional again, even though they're not used. Sigh. Duncan

3 4

Static linking and linker search paths
by Duncan Coutts 22 Dec '09

22 Dec '09

All, Conor's problems on OSX with libiconv reminds me of something I've been thinking about for a little while. So the problem is that the semantics of static linking does not at all match what we really want. We can easily accidentally "interpose" a wrong library in place of the one we wanted. In the iconv case people have hit recently we've got this situation: libHSbase-4.2.0.0.a contains references to _iconv_open, _iconv, _iconv_close ${system}/libiconv.a ${macports}/libiconv.a When the code for libHSbase was built, it was against the header files for the standard system version of iconv on OSX. Thus it is intended that we link against the system version of iconv. No suppose by default that the system is set up such that only the system iconv is found by default. So I am assuming there is no LD_LIBRARY_PATH or similar set. Then when we link something then we correctly resolve the references in base to the system iconv lib. When we call gcc to link we're doing something like: -L${ghclibdir} -lHSbase-4.2.0.0.a -liconv Now suppose we build some FFI package (libHSfoo-1.0.a) that provides a binding to a C lib installed via macports (libfoo.a). When we link a program that depends indirectly on this FFI package then the gcc linker line is like: -L${ghclibdir} -L/opt/local/lib -lHSfoo-1.0.a -lfoo -lHSbase-4.2.0.0.a -liconv and now it all breaks. We're asking the linker to look in /opt/local/lib first for *all the remaining libraries* and that includes iconv, so we pick up the wrong iconv. Our intention was just to look for -lfoo using /opt/local/lib, but we cannot express that to the linker. The problem is that our notion of library dependencies is hierarchical but for the system linker it is linear. We know that package foo-1.0 needs the C library libfoo.a and that it should be found by looking in /opt/local/lib. But we end up asking the linker to look there first for all other libs too, including for the -liconv needed by the base package. The registration for the base package never mentioned /opt/local/lib of course. What we'd really like to say is something like: link HSfoo-1.0.a push search path /opt/local/lib link foo pop search path If we think we know enough about the behaviour of the system linker and its search path then we could do just: -L${ghclibdir} -lHSfoo-1.0.a /opt/local/lib/libfoo.a -lHSbase-4.2.0.0.a -liconv that is, specify the .a file exactly by fully resolved path and not add anything to the linker search path. (Actually we'd do it for the libHS*.a ones too since we know precisely where they live) The possible danger is that how we search for the library and how the system linker searches for it might not match exactly and we could end up sowing confusion. Worth thinking about anyway. Note that some of this is different for shared libs. Duncan

1 0

Haskell @ USENIX HotPar?
by Don Stewart 21 Dec '09

21 Dec '09

Hey Haskellers, Looks like a great opportunity to talk about parallel Haskell to other communities: Second USENIX Workshop on Hot Topics in Parallelism http://gpgpu.org/2009/12/20/cfp-hotpar-2010 Following the tremendous success of HotPar ‘09, the Second USENIX Workshop on Hot Topics in Parallelism (HotPar ‘10) will once again bring together researchers and practitioners doing innovative work in the area of parallel computing. Anyone planning on submitting a position paper? It would be a real shame not to show our faces. -- Don

1 0

parList implementation question
by Marcus D. Gabriel 21 Dec '09

21 Dec '09

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

3 6

How does forkIO and par interact?
by Marcus D. Gabriel 21 Dec '09

21 Dec '09

Hello, How does forkIO (forkOS) and par interact with one another? Here is why I ask. I have a GUI application that has something like this: th <- forkIO (guiCode + longRunningPureSerialCode) Later, a user interaction invokes killThread th and the guiCode plus the longRunningPureSerialCode suspends quite nicely. Now I have th <- forkIO (guiCode + longRunningPureParallelCode) Later a user interaction invokes killThread th again but I have observed under 6.10.4 that not all is suspended. From what I have observed, I believe that if longRunningPureParallelCode = ... 1stPart `par` 2ndPart ... the 2ndPart is suspended by killThread th along with the guiCode, and the 1stPart happily continues calcualting. (I believe this is correct but it could be the other way around.) For my little application, having everything suspend would have been nice, but that's my app. So, under ghc, how is forkIO (forkOS) and par supposed to operationally interact with one another? Cheers, - Marcus

3 3

openFd under -threaded gets interrupted
by Mitar 21 Dec '09

21 Dec '09

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

2 1

Re: openFd under -threaded gets interrupted
by Donn Cave 18 Dec '09

18 Dec '09

Quoth Mitar <mmitar(a)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

2 1

cabal-install-0.8 final testing
by Duncan Coutts 18 Dec '09

18 Dec '09

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

1 0

ANNOUNCE: GHC version 6.12.1
by Ian Lynagh 18 Dec '09

18 Dec '09

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.12.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Considerably improved support for parallel execution. GHC 6.10 would execute parallel Haskell programs, but performance was often not very good. Simon Marlow has done lots of performance tuning in 6.12, removing many of the accidental (and largely invisible) gotchas that made parallel programs run slowly. * As part of this parallel-performance tuning, Satnam Singh and Simon Marlow have developed ThreadScope, a GUI that lets you see what is going on inside your parallel program. It's a huge step forward from "It takes 4 seconds with 1 processor, and 3 seconds with 8 processors; now what?". ThreadScope will be released separately from GHC, but at more or less the same time as GHC 6.12. * Dynamic linking is now supported on Linux, and support for other platforms will follow. Thanks for this most recently go to the Industrial Haskell Group who pushed it into a fully-working state; dynamic linking is the culmination of the work of several people over recent years. One effect of dynamic linking is that binaries shrink dramatically, because the run-time system and libraries are shared. Perhaps more importantly, it is possible to make dynamic plugins from Haskell code that can be used from other applications. * The I/O libraries are now Unicode-aware, so your Haskell programs should now handle text files containing non-ascii characters, without special effort. * The package system has been made more robust, by associating each installed package with a unique identifier based on its exposed ABI. Now, cases where the user re-installs a package without recompiling packages that depend on it will be detected, and the packages with broken dependencies will be disabled. Previously, this would lead to obscure compilation errors, or worse, segfaulting programs. This change involved a lot of internal restructuring, but it paves the way for future improvements to the way packages are handled. For instance, in the future we expect to track profiled packages independently of non-profiled ones, and we hope to make it possible to upgrade a package in an ABI-compatible way, without recompiling the packages that depend on it. This latter facility will be especially important as we move towards using more shared libraries. * There are a variety of small language changes, including * Some improvements to data types: record punning, declaring constructors with class constraints, GADT syntax for type families etc. * You can omit the "$" in a top-level Template Haskell splice, which makes the TH call look more like an ordinary top-level declaration with a new keyword. * We're are deprecating mdo for recursive do-notation, in favour of the more expressive rec statement. * We've concluded that the implementation of impredicative polymorphism is unsustainably complicated, so we are re-trenching. It'll be deprecated in 6.12 (but will still work), and will be either removed or replaced with something simpler in 6.14. The full release notes are here: http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

13 23