- Glasgow-haskell-users

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

ByteString-backed Handles, and another couple of questions
by Bryan O'Sullivan 16 Dec '09

16 Dec '09

Hi, Simon - I just added support to Data.Text for your new Unicode-based Handle implementation, and I'd like to write some tests. The natural way to do this would be to create Handles that will write to, and read from, ByteStrings. Does any such code exist at the moment? I don't see it in base or bytestring, though all the necessary abstractions appear to be present. Also, the place I hooked into the new I/O machinery was at the next level up from CharBuffer. Because the implementation of CharBuffer isn't abstract, I had no opportunity to put a text array in there, so there's an extra amount of copying that happens when going from byte buffer to char buffer to Text. It's a bit of a shame, but I don't see a way around it at the moment. Would you be interested in trying to remove that extra copy, or is the current interface set in stone? Many thanks for your great work on this, Bryan.

3 4

Porting to DragonFly BSD
by Colin Adams 15 Dec '09

15 Dec '09

When GHC 6.12.1 is released, I'm going to have a go at porting it to DragonFly BSD (32-bit incarnation). Is the porting page on the wikiup-to-date? -- Colin Adams Preston, Lancashire, ENGLAND

9 19

RE: ANNOUNCE: GHC version 6.12.1
by Jost Berthold 15 Dec '09

15 Dec '09

Luca, to use Control.Parallel, you need to download and install two packages, deepseq and parallel, from hackage.haskell.org. Most likely this will work with cabal, or you just download the two tarballs . The reason is, when packaging "parallel", this package has been removed from the GHC core libraries. BTW I am unsure whether this is at all clever, since it needs specific GHC support (at least for now - am I right here?) In addition, be informed that Control.Parallel.Strategies has been heavily restructured just last month (splitting it into deepseq and parallel is one of the changes, but not the most fundamental). If you want to try examples from GpH publications, you will certainly have some problems. parallel-1.x versions containing the original definitions are on hackage as well and should work for experiments. Cheers Jost Berthold PS: Loading Control.Parallel into ghci is a handy debugging procedure for the sequential parts of your program without any hassle, but if you do not compile and link your program, it will not use any parallelism (and run slow anyway). > From: Luca Ciciriello <luca_ciciriello(a)hotmail.com> > Subject: RE: ANNOUNCE: GHC version 6.12.1 > To: <marco-oweber(a)gmx.de>, <glasgow-haskell-users(a)haskell.org> > Message-ID: <SNT128-W3217F8C02C7EAA2723E4339A890(a)phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > > Installed 6.12.1 on MacOS X 10.6Now I'm unable to load in GHCi of that > modules containing "import Control.Parallel"I'm missing something? > Luca > >> From: marco-oweber(a)gmx.de >> To: glasgow-haskell-users(a)haskell.org >> Date: Mon, 14 Dec 2009 15:24:48 +0100 >> Subject: RE: ANNOUNCE: GHC version 6.12.1 >> >> Excerpts from Luca Ciciriello's message of Mon Dec 14 15:12:45 +0100 >> 2009: >> > I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to >> uninstall >> > this version of GHC before installing the Mac .pkg for the 6.12.1? >> >> Hi Luca, >> >> You should be able to get some hints by looking at where ghc is >> installed. >> >> By default ghc puts its libraries into directory which contains the ghc >> release name. So libs can be installed at the same time. >> There are also ghc(i)-pkg-$GHC_VERSION executables. >> So it should be possible. However I don't know about Mac details. >> >> But maybe someone else can give you a more accurate answer. >> >> Sincerly >> Marc Weber

6 6

Re: Porting to DragonFly BSD
by Colin Paul Adams 15 Dec '09

15 Dec '09

>>>>> "Karel" == Karel Gardas <karel.gardas(a)centrum.cz> writes: Karel> Seeing DragonFly BSD and `make' together with your make Karel> error messages rings an alarm here with a suggestion to use Karel> GNU make. That's a good alarm you have :-) gmake works much better. Thanks. -- Colin Adams Preston Lancashire

1 0

Initial ghc-6.12 + hackage build results
by Duncan Coutts 14 Dec '09

14 Dec '09

All, I've tried building 1324 out of the ~1700 packages from hackage using ghc-6.10.4 and ghc-6.12.0. This is the subset of packages that I could build in one go. Compared to the subset that I could build with ghc-6.10.4, I had to chuck out 125 packages because their build dependency constraints precluded them from building with ghc-6.12. Of the remaining 1324 packages, 113 packages that built OK previously now do not build. Amongst that 113, the ones that cause most knock-on failures are: (16,"packedstring-0.1.0.1") (12,"MissingH-1.1.0.1") (11,"syb-with-class-0.5.1") (6,"uvector-0.1.0.5") (3,"stringtable-atom-0.0.6") (3,"bindings-common-1.3.4") (3,"binary-strict-0.4.6") (3,"base64-string-0.1") packedstring fails because it needs base 4, but only says "build-depends: base", so cabal uses its compatibility tricks and builds it against base 3. It should specify "build-depends: base == 4.*". I need to investigate MissingH further. It failed because a dependency of its non-buildable test program was not found. That should not have been a problem. syb-with-class has type errors, I'm guessing due to changes in template-haskell package uvector does not compile because of the changes in GHC's Handle implementation. stringtable-atom now fails with a type error for reasons I don't quite understand: src/StringTable/AtomMap.hs:320:0: Occurs check: cannot construct the infinite type: a = (Int, a) When generalising the type(s) for `findMax' Perhaps some change in a containers function? bindings-common and c2hs fail because the CLDouble FFI type has been removed. binary-strict fails because the export of Control.Applicative.many now clashes with a local definition. base64-string fails because it sets -Werror in it's .cabal file (a practise which has been banned for some time for just this reason). Of the remaining 113: 2 failed at the configure step: MissingH-1.1.0.1 -- this needs investigation, I smell a cabal bug lax-0.1.0.0 52 failed at the build step (including those singled out above): ArrayRef-0.1.3.1 -- ghc Handle changes Boolean-0.0.0 -- name clash with Control.Applicative.<* CCA-0.1.1 -- TH changes, missing Lift instances ChasingBottoms-1.2.4 -- name clash with Data.Sequence.partition ChristmasTree-0.1.2 -- TH changes (Name vs TyVarBndr) HCodecs-0.1 -- Data.Array.Diff disappeared HList-0.2 -- change in GADT syntax (context) MonadLab-0.0.2 -- Some API change, not immediately obvious base64-string-0.1 -- described above binary-strict-0.4.6 -- described above bindings-common-1.3.4 -- described above bindings-gsl-0.1.1.6 -- CLDouble bloomfilter-1.2.6 -- declaration of a type or class operator `:*' bytestringparser-0.3 -- -Werror c2hs-0.16.0 -- CLDouble cabal2arch-0.6 -- Cabal API changes cabal2doap-0.2 -- Cabal API changes compact-map-2008.11.9 -- GHC Handle changes conjure-0.1 -- Data.Array.Diff disappeared flock-0.1 -- -Werror fail gtk2hs-cast-gtk-0.10.1.2-- type error, not immediately obvious hask-home-2009.3.18 -- Cabal lib API changes hgalib-0.2 -- Data.Array.Diff disappeared hircules-0.3.92 -- ambiguity GHC.IO.liftIO vs C.M.State.liftIO hnop-0.1 -- -Werror fail hommage-0.0.5 -- GHC.IO changes hxt-filter-8.3.0 -- name clash System.IO.utf8 and local name ideas-0.5.8 -- A pattern match on a GADT requires -XGADT ieee-0.6 -- CLDouble ivor-0.1.9 -- 'rec' now a keyword loch-0.2 -- -Werror fail nano-hmac-0.2.0 -- -Werror fail nanocurses-1.5.2 -- package specifies non-existant config.h (which used to accidentally pick up ghc's config.h) this happens because the package needs to run ./configure but does not say so. network-fancy-0.1.4 -- GHC Handle changes pkggraph-0.1 -- Cabal lib API changes plugins-1.4.1 -- Cabal lib API changes posix-realtime-0.0.0.1 -- type of internal IOError constructor printf-mauke-0.3 -- CLDouble pugs-HsSyck-0.41 -- mdo syntax removed? random-fu-0.0.3 -- type error, not immediately obvious rdtsc-1.1.1 -- -Werror fail repr-0.3.1 -- same as random-fu safe-lazy-io-0.1 -- GHC Handle changes sendfile-0.5 -- GHC Handle changes sessions-2008.7.18 -- needs -XTypeOperators stringtable-atom-0.0.6 -- described above syb-with-class-0.5.1 -- described above type-settheory-0.1.2 -- TH lib API changes uu-parsinglib-2.3.0 -- scoped type var changes? uuagc-0.9.12 -- 'rec' now a keyword uvector-0.1.0.5 -- GHC Handle changes word24-0.1.0 -- Not in scope: `divZeroError' The remaining 59 are knock-on failures, ie packages that depended on one of the failed packages. Duncan

1 0