- Glasgow-haskell-users

Strange GHC/STM behaviour
by Michael Lesniak 16 Mar '10

16 Mar '10

Hello, In one of my example programs I have a strange behaviour: it is a very simple taskpool using STM; in pseudocode it's 1. generate data structures 2. initialize data structures 3. fork threads 4. wait (using STM) until the pool is empty and all threads are finished 5. print a final message In very few cases, which depend on the number of threads spawned, the program hangs *after* the final message of step 5 has been printed. "Few cases" means, for example, 50.000 good, terminating runs before it hangs. If you increment the number of spawned threads (to a few hundred or thousands), it hangs much faster. Since forked threads terminate after the main thread terminates (which it should after printing the message), this behaviour is quite unexpected. Since I've experienced strange behaviour in the past which was the fault of my system configuration[1], I am a bit cautious before reporting a bug on GHC's bugtracker, especially since its reproduction is so difficult and random. So my question is how much circumspection is expected/needed before one should enter a bug in the bug tracker? I've tested the attached code on three different systems (with different linux systems, but always GHC 6.12.1 (since it's a bit costly to install the older versions)) and observed the mentioned behaviour. Is this enough to justify a bug report? Or, on the other hand, could someone spot the error in the attached code. Given my history with strange parallel behaviour, I am much more sure that it's the fault of my code, but I can't spot the error and the described behaviour (halting *after* the final message) is really strange. Addendum: Daniel Fischer could reproduce the problem and pointed out[2], that making the evaluation of the TVAR's value strict does not reproduce the behaviour. This is even stranger in this context; I don't see, how lazy evaluation can change the behaviour of my code. Cheers, Michael [1] http://www.haskell.org/pipermail/haskell-cafe/2010-March/073938.html [2] http://www.haskell.org/pipermail/haskell-cafe/2010-March/074520.html -- Dipl.-Inf. Michael C. Lesniak University of Kassel Programming Languages / Methodologies Research Group Department of Computer Science and Electrical Engineering Wilhelmshöher Allee 73 34121 Kassel Phone: +49-(0)561-804-6269

2 8

Documenting GHC
by Yitzchak Gale 16 Mar '10

16 Mar '10

In the thread "strictness of unused arguments", Max Bolingbroke wrote: > There is nothing *published* (Simon has a half-written one lying > around though)... > Unfortunately the weird behaviour you are seeing is due to... > one of the unpublished bits... There are various critical parts of the inner workings of GHC that are poorly understood outside of the GHC team. Strictness analysis and other optimizations, and the syntax and semantics of GHC Core, immediately come to my mind. There is much more. As a user of GHC, I would vote for a full two-month delay in the next release of GHC to allow the GHC team to devote two months of their time exclusively to writing documentation. Thanks, Yitz

3 2

Re: Proposed ghc-pkg and cabal feature - right list?
by Axel Simon 16 Mar '10

16 Mar '10

I'm replying to Simon M. and myself, as should have sent my first reply to the ghc users list, I guess. On 14.03.2010, at 10:54, Axel Simon wrote: > Hi Dan, > > I reply to libraries, I think that's the right list for Cabal. > > On 13.03.2010, at 21:39, Dan Knapp wrote: > >> There doesn't seem to be a mailing list for Cabal itself, so I'm >> posting here. I came up with an idea for a small feature that I >> believe would make a useful addition to ghc-pkg and Cabal. I'm >> willing to implement it myself, but I have had some previous >> experiences with other projects where I did some work and then the >> maintainers said "sorry, not interested", so I want to gauge interest >> before I start. Who should I talk to? >> >> The feature itself is this: Arbitrary key-value pairs in Cabal >> package files and the installed-package database. The use-case is >> for >> an application supporting plugins to discover installed plugins >> compatible with it, interrogating these fields through the GHC API. > > For Gtk2Hs I would like to have a similar feature. Gtk2Hs is a > wrapper for Gtk+. It evolves on its own (for which the package has a > version number) but it may wrap different versions of Gtk+. > I think people using Gtk2Hs need to be able to conditionally compile > certain code fragments, depending on which Gtk+ version Gtk2Hs > wraps. However, I had something simpler in mind than providing any > kind of key,value pairs: I would like to "export" certain Cabal > flags into the package, which could be as easy as specifying: > > Flag gtk_2_2 > Description: Build objects for Gtk+ version 2.2. > Exported: True > > Flag gtk_2_4 > Description: Build objects for Gtk+ version 2.4. > Exported: True > > Flag gtk_2_6 > Description: Build objects for Gtk+ version 2.6. > Exported: True > > where the 'Exported' would mean that this flag should be added to > the package data base. A package would then be > > gtk-0.10.4{gtk_2_2,gtk_2_4} > > if the first two flags would be set by Cabal. A package could then > depend on gtk-0.10.4 in which certain flags are set. Moreover, I > would then want cabal to compile a users package with -Dgtk_2_2 - > Dgtk_2_4 so the user can use CPP to conditionally compile code. > > You suggestion of using arbitrary key,value pairs is more general > and needs more thought. You would have to extend Cabal quite a bit > whereas my proposal is more lightweight in that it can build on top > of Cabal's Boolean flags. May I ask: > > - could you express your package properties using Boolean flags > (which are set by Cabal automatically)? > - if not, could you not express your plug-in concept using several > packages? > > Cheers, > Axel. > > >> For example, my content-management system FruitTart could enumerate >> the list of installed packages looking for packages which export a >> field "fruit-tart-plugin-interface-version" with a numeric value >> matching the interface version it's expecting. I'm not quite sure I understand the use case here. Are you saying you want to writing something within Cabal? Or do you want to use the Cabal API to find out if a certain package is available? If you're talking about dynamic plug-ins then I assume it must be the latter. Besides the technical difficulty of loading a GHC package dynamically (that I don't know anything about), what prevents you from looking for a package that contains just the plug in? On 15.03.2010, at 16:38, Simon Marlow wrote: >> > > My first thought was "hmm, there must be another way to do that", > but I can't think of one, or at least a good one. > > Perhaps having arbitrary key-value pairs in the package database > would be a good thing. It would help us to avoid breaking things > when we need to change the format, for one thing. We could start > using key-values for new fields rather than adding them to > InstalledPackageInfo. However, then we have a strange situation > where some fields get distinguished status in InstalledPackageInfo. > Of course, for some of those fields we have richer types (e.g. > License), so it makes sense. > > So for me, I can't see any serious objections to doing this, but I'd > also ask on the cabal-devel(a)haskell.org list (in particular we > should hear what Duncan Coutts thinks). Before implementing anything like general key,value pairs, I would like to see the exact usage of these fields? So Dan wants to query these dynamically using an API. I'm much more interested in having CPP macros defined so I can compile code conditionally. For this purpose, the key,value pairs are not necessarily suitable since Dan might want to define a pair that does not create a valid -Dkey=value instruction for CPP. Cheers, Axel.

1 0

Proposed ghc-pkg and cabal feature - right list?
by Dan Knapp 16 Mar '10

16 Mar '10

There doesn't seem to be a mailing list for Cabal itself, so I'm posting here. I came up with an idea for a small feature that I believe would make a useful addition to ghc-pkg and Cabal. I'm willing to implement it myself, but I have had some previous experiences with other projects where I did some work and then the maintainers said "sorry, not interested", so I want to gauge interest before I start. Who should I talk to? The feature itself is this: Arbitrary key-value pairs in Cabal package files and the installed-package database. The use-case is for an application supporting plugins to discover installed plugins compatible with it, interrogating these fields through the GHC API. For example, my content-management system FruitTart could enumerate the list of installed packages looking for packages which export a field "fruit-tart-plugin-interface-version" with a numeric value matching the interface version it's expecting. Once again, I'm not asking anyone to do this work for me - I'm eager to get my hands dirty and do it myself. I just want to find out what the process would be to get it accepted, once it works. Thanks in advance, -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

2 2

native threads vs. -threaded
by Donn Cave 15 Mar '10

15 Mar '10

I have been working on a Haskell interface to the platform API for Haiku (was BeOS.) It's C++, but the interesting thing at the moment is the use of threads - a UI window gets its own thread, and whatever Haskell code will be executed by callbacks from that thread. So it was surprising when this turned out to be incompatible with the -threaded link option. With that option, I get one callback from a non-main thread, and then that native thread will die, shortly after return from the callback. Results without -threaded are not really so good either (the application may run and work for a while, but inevitably fail with various errors that I suppose might be expected), so ... what do my threads need, to make -threaded work? The callbacks are `foreign "wrapper"' functions, which means rts_lock() is already getting called. It looks to me like that should work the same as if my thread had been invoked via forkOS, true? Is there anything else that I missed, that needs to be done to set the thread up for GHC? (I had been thinking this would not be a unique situation, rather there would be several other GUI toolkits out there that use threads in this obvious way, but after a brief review of the ones I usually hear about, not so sure. If there's another library that uses OS threads this way, with Haskell bindings already, that might be something I could steal a clue from.) thanks! Donn Cave, donn(a)avvanta.com

2 4

Annotations and Template Haskell
by Bertram Felgenhauer 15 Mar '10

15 Mar '10

Hello, I'm wondering whether annotations [1] could be made available to Template Haskell users as a ghc specific extension. Would that be feasible? Would it be useful? An example use would be annotating a type with a representation of a default value that could be used in generating instances for various type classes (like parsers that take the default value into account). The alternative would be to pass that representation explicitely to every single Template Haskell invocation that uses it. Regards, Bertram [1] http://hackage.haskell.org/trac/ghc/wiki/Annotations

2 2

strictness of unused arguments
by Roman Beslik 12 Mar '10

12 Mar '10

Hi all. I provide a sample program which causes a strange behavior of strictness analyzer. variant 1 {{{ module StrictUnusedArg (main) where f2 :: Int -> Int -> Int f2 x1 = if x1 == 0 then (\x0 -> x0) else let y = x1 - 1 in f3 y y f3 :: Int -> Int -> Int -> Int f3 x2 = if x2 == 0 then f2 else let y = x2 - 1 in f4 y y f4 :: Int -> Int -> Int -> Int -> Int f4 x3 = if x3 == 0 then f3 else let y = x3 - 1 in \x2 x1 x0 -> f4 y x2 x1 (y + x0) main = print (f2 100 0) }}} I expect that all arguments will be unboxed. "-ddump-simpl" reveals that actually types are {{{ f2 :: Int# -> Int -> Int f3 :: Int# -> Int -> Int -> Int }}} So when "f3" calls "f2" it unboxes the argument named "x1" and when "f2" calls "f3" it boxes the argument named "x1". "-ddump-stranal" knows strictness only for the "x2" of "f3" and "x1" of "f2". {{{ f2: [Arity 1 Str: DmdType U(L)] f3: [Arity 1 Str: DmdType U(L)] }}} I also can force the analyzer to think that "x1" and "x0" are strict by eta-expanding "f3": variant 2 {{{ f3 x2 x1 x0 = if x2 == 0 then f2 x1 x0 else let y = x2 - 1 in f4 y y x1 x0 }}} "-ddump-stranal" yields: {{{ f3: [Arity 3 Str: DmdType U(L)U(L)U(L)m] f2: [Arity 2 Str: DmdType U(L)U(L)m] }}} I even do not use ($!). So, the questions: Is it possible to change the strictness analyzer so it will treat "variant 1" as "variant 2"? Are these changes big? Compiled with options: $ ghc --make -fstrictness -fPIC -O3 -fforce-recomp blah-blah-blah $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 -- Best regards, Roman Beslik.

2 4

undocumented cost centres with -hd and -hy
by Soenke Hahn 12 Mar '10

12 Mar '10

When using the heap profiling options -hd (profiling by closure description) and -hy (profiling by type) there are some compiler-generated cost centres, for example "PAP", "MUT_ARR_PTRS_FROZEN" and "BLACKHOLE". I wasn't able to find documentation on them. Is there any? Thanks, Sönke

3 2

ghc ftp site
by Gregory Wright 09 Mar '10

09 Mar '10

Hi, Could someone tell me who is in charge of the ghc ftp site these days? I need to upload a bootstrap compiler to build MacPort's ghc on Snow Leopard and the permissions of the 6.10 - 6.1 directories have changed. I no longer can write there. Best Wishes, Greg

1 0

nasty things possible with generalized newtype deriving
by Wolfgang Jeltsch 09 Mar '10

09 Mar '10

Hello guys, are you following this Haskell Cafe thread: <http://www.mail-archive.com/haskell-cafe@haskell.org/msg72300.html> Seems that you can do ugly things with GHC’s current implementation of generalized newtype deriving. For example, you can easily construct sets with corrupted internal structure even if there are no bogus Ord instances. Best wishes, Wolfgang

1 0