June 2006 - Glasgow-haskell-users

partial x86_64 binary snapshots?
by Jens Petersen 22 Jun '06

22 Jun '06

I wanted to download a nightly binary stable snapshot for Linux x86_64 to test if the problem with selinux on Fedora Core has been fixed... but AFAICT recent snapshots (I tried too) are broken: % bunzip2 -t ghc-6.4.2.20060621-x86_64-unknown-linux.tar.bz2 bunzip2: ghc-6.4.2.20060621-x86_64-unknown-linux.tar.bz2: file ends unexpectedly You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. Just wondering what is up with this? Jens

1 1

RE: about threads (here: increasing thread IDs)
by Jost Berthold 21 Jun '06

21 Jun '06

Hi Seth, perhaps this will help you, some information from the implementation side concerning your question about threadIDs: Related code lived in rts/Schedule.c, has recently moved to rts/Threads.* in the head. The ThreadID assigned by the RTS is continuously increasing, and declared to be StgInt32 (32 bits usually). So you might get int overflows when running your server for a *fairly* long time. OTOH, depending on what you want to do with the ThreadIDs that forkIO returns, IMHO you could just *ignore* these overflows. From your short description of how the servers work, you know an upper bound on the no. of running threads (6), but not on their time to live. So IMHO the worst case scenario would be: a new thread for a client gets ID n ... 2^32 other server threads get spawned another new thread for a client gets the same ID n again ... one of the threads supposed to terminate (killThread n) AFAICT, the killThread action will arbitrarily choose one of the two. HTH Jost ------ you wrote ------ Date: Tue, 20 Jun 2006 23:22:26 -0400 From: Seth Kurtzberg <seth(a)cql.com> Subject: Re: FFI: number of worker threads? To: "Li, Peng" <ringer9cs+ghc(a)gmail.com> Cc: glasgow-haskell-users(a)haskell.org Another related question. I have some threaded applications running which are servers and run continuously. A thread is spawned for each new connection, and the thread exits when the client terminates. I've noticed that the thread ID increases. On one process I checked today I am up to thread number 3300. The number of running threads is not increasing; only six threads are running on this particular process. The threads are cleaned up and exit. The thread _ID_ is continually increasing. Is this going to cause a problem when the thread ID exceeds some value? Do I have to force the server process to recycle periodically? ...

2 1

The GHC hackathon: 14,15 September 2006, Portland
by Simon Peyton-Jones 21 Jun '06

21 Jun '06

Friends After some encouragement at last year's ICFP, Simon and I are going to run a GHC hackathon, in Portland, just before ICFP this September (14-15th). It'll be held at Galois's offices, in Beaverton; we're very grateful to Galois for hosting the meeting. The details are here: http://hackage.haskell.org/trac/ghc/wiki/Hackathon If you are interested in finding out a bit about how GHC works inside, then you should find the hackathon fun. It will certainly be informal and interactive. GHC is a 100% open-source project, and the more people that are involved the better it goes. If you think you might come, please take a look at the above page, and let us know by registering. See you soon! Simon

1 0

Would you like a job working on GHC?
by Simon Peyton-Jones 21 Jun '06

21 Jun '06

Would you like to be paid to work on GHC? The Glasgow Haskell Compiler (GHC) is now being used by so many people, on so many platforms, that at GHC HQ we've been struggling to keep up. We're delighted to say that we are now looking to hire a GHC support engineer to work with us. Here is how we envisage working together: * You would work 3-5 days a week on GHC (details flexible). * You don't need to live in Cambridge, but we would like you to visit every few months, so that we build up a face-to-face relationship. * You'll be a self-employed consultant, not a Microsoft employee. You bill us; we pay you. * The position is a one year fixed term contract in the first instance. * GHC is, and will remain, an open-source project with a BSD-style license. We are looking for help with the role of supporting GHC in the field. Specifically, here's what the job involves: * Investigating, prioritising and fixing bugs, improving the test suite * Managing the STABLE branch of the source tree * Managing the GHC release cycle * Keeping the GHC web site up to date * Answering questions from GHC users * Helping to support the open-source community that works on GHC itself We're particularly looking for someone who is experienced in a variety of operating system platforms and libraries. You should be able to deal with questions like "I try to build GHC on Solaris 2.3.4 and get `undefined symbol _readline'"; or "How do I link to DLLs on Windows?"; or "does the ByteString library in GHC 6.2.1 do XXX?". The role will not primarily involve working on GHC's core; it's the parts round the edges that you would mainly focus on. You must be able to read and write Haskell, but we don't expect that you'll need to write a great deal of Haskell code. C and 'make' experience are important too. Above all, we are looking for someone who is enthusiastic about Haskell, and fired up about the prospect of becoming a GHC expert. If you are interested, please send your CV and a statement of why you would be a good fit for the job, to our Human Resources Department at camjobop(a)microsoft.com We're happy to accept informal enquiries of course: please contact Simon Marlow (simonmar(a)microsoft.com) or Simon Peyton Jones (simonpj(a)microsoft.com) for further information. The rate of pay is dependent on qualifications and experience. It'll be fun! Simon Peyton Jones and Simon Marlow

1 1

Left-to-right bias in type checking GADT functions
by Stefan Holdermans 20 Jun '06

20 Jun '06

Hi all, I have to admit that I haven't checked if this is a known issue... The following is tested with both GHC 6.4.1 and 6.4.2; I have not checked the HEAD. Let me define a simple GADT |F|, -- a simple GADT data F :: * -> * where F :: Int -> F () and a more or less trivial function |g| operating on it: -- type checks g :: F a -> a -> Int g (F n) () = n No problems up to here. But then let me just flip the parameters of | g|---and call the resulting function |h|: -- does not type check h :: a -> F a -> Int h () (F n) = n -- !!! Now, this definition of h does not type check: Couldn't match the rigid variable `a' against `()' `a' is bound by the type signature for `h' Expected type: a Inferred type: () When checking the pattern: () In the definition of `h': h () (F n) = n So, it seems that there's a left-to-right bias in type checking functions over GADTs. I cannot imagine this being by design, for it certainly seems possible to type check functions of this sort in a conceptually unbiased fashion. Anyone to shine a light on this? TIA, Stefan ------------------------------------------ Bias.lhs: > {-# OPTIONS -fglasgow-exts #-} > -- a simple GADT > data F :: * -> * where F :: Int -> F () > -- type checks > g :: F a -> a -> Int > g (F n) () = n > -- does not type check > h :: a -> F a -> Int > h () (F n) = n -- !!!

2 2

[glasgow-haskell-users] Searchpath vs. Cabalfind (was: installing a Cabal package non-exposed)
by Dimitry Golubovsky 17 Jun '06

17 Jun '06

Alex, S. Alexander Jacobson wrote: > Searchpath allows you easily to give each application its own > namespace and automates import chasing accross the internet. It is a > work in progress and is definitely less refined than cabal, but if you > are having this sort of issue you might want to try it out. See > http://searchpath.org Looks very interesting. However I couldn't get anything like "https://hackage.org/modules.map" in a browser (nor with http: nor from www.hackage.org) it says "unknown host". I am just curious: instead of querying a centralized database, have you tried any way to get modules' locations from search engines? I wish I could see what "modules.map" looks like, then I could see better whether what Cabalfind gets from Google could be an alternative? Not that I am pushing for Cabalfind in any way; just curious. -- Dimitry Golubovsky Anywhere on the Web

2 1

"+RTS -A" parameter and CPU cache size
by Bulat Ziganshin 16 Jun '06

16 Jun '06

Hello glasgow-haskell-users, "+RTS -A" parameter sets up size of memory allocation area. by default it set to 256kb and this means that after each 256 kb allocated minor GC occurs and data from this block that is still alive are moved to main heap area (what is scanned only on major GCs) while rest of space is freed. also on each minor GC all mutable variables (IORef/STRef) and mutavle arrays (IOArray/STArray) are scanned and therefore programs that use them heavily (including GHC itself) works faster when value of "-A" parameter is increased. For example, by setting this parameter to 10mb you can decrease count of minor GCs in 40 times. The speed change depends on concrete program, for GHC itself it may be 20-50% faster. that is the example of using this option to speed up compilation: ghc --make main.hs +RTS -A10m well, but what if we don't have many global variables and therefore don't need to increase -A? in this case it's better to have such value of this parameter that all "local data" hold in L1+L2 CPU caches. that is especially important when program generates large number of temporary data cells with very short lifetime. i've found a good example of such program in my own vGetLine-testing code - it reads millions of 20-char lines in one loop. my CPU has 128k total data cache and for this task the most efficient -A value was about 100kb, what allows this benchmark to run 2x faster that with standard -A256k value in general, data cache should be enough to hold: 1) "nursery area", whose size is set by -A 2) part of data from this nursery area what remains alive after minor GC (it may be anything between 0 kb and whole nursery area) 3) all data outside of nursery area what program access between two minor GCs (unpredictable value, in general) knowing this all, we can try to calculate best size of nursery area (i.e., "-A" value), depended on CPU cache size. although we can't find exact optimum because some ratios in list above are unknown, we still can say that optimization should be done for cases where amount of "external" (outside nursery) data accessed between GCs is no more than size of nursery itself and that in typical cases more than 50% of data in nursery will be freed by minor GC. based on these assumptions, we can make conclusion that nursery size should be about 1/2 of cache size. if nursery size is greater or equal to cpu cache size, then it will work inefficient, overfilling L2 cache and "trashing" memory - just like the program that uses little more memory than physically available trashes the swap disk now let's analyze effective data cache size of today CPUs: celeron - 128k-256k sempron, athlon, athlon xp - 192k-320k (64k of L1 + 128k-256k of L2 cache) celeron d, athlon 64, pentium4, pentium d - 512k-2048k as you can see, most of cpus, used in today systems, don't have cache large enough to work efficiently with 256k nursery size (according to my calculations above, it requires 512k or larger cache). this results in sub-optimal performance of ghc-compiled programs. according to my tests, every algorithm tested can be made faster either by increasing -A to 10mb, or decreasing to 1/2 of my cpu cache! the only problem is to automatically decide what to do for each particular algorithm - increase or decrease? :) moreover, when decreasing -A to 64k. speed loss for some algorithms can be also significant - up to 1.5 times. of course, this is the same algorithms that take advantage when -A is significantly increased (see first paragraph for explanations). this problem don't allow me to recommend automatic decreasing of -A for low-level cpus with GHC 6.4, but fortunately it should almost gone in ghc 6.6 taking this all into account, i propose the following: 1) GHC faqs already suggests using of RTS -A/-H option to speed up compilation. i propose to move this suggestion right to compiler itself and add the line char *ghc_rts_opts = "-A10m"; to GHC 6.4 sources 2) i propose to write "L2 cache size detection" code and use it in GHC 6.6 RTS to setup initial value of "-A" option. in order to allow program tune itself to any cpu architecture, with cache sizes ranging from 128kb to 4mb. this will allow low-level cpus to run significantly faster on some algorithms (up to 2x, as i said above) and can give 5-10% speedup for high-level cpus, that is also not so bad :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 5

Re: installing a Cabal package non-exposed
by Christian Maeder 16 Jun '06

16 Jun '06

Simon Marlow schrieb: > Before we add support for this to Cabal, we should ask why it is needed. > The only reason (that I know of) to hide a package by default is > because its namespace conflicts with another exposed package. Is that > the case here? Yes, I had identical hierarchical module names in two packages, one was a HaXml-13-CVS Cabal package, the other an old uni-haxml package that's usually included via ghc's -package-conf option into our sources. Unfortunately both versions have been modified in different directions (and almost nobody wants to touch our old uni code). Nevertheless, I thought, it should be possible to install different hidden versions of libraries such that users (or user groups) are free to explicitly pick the version that suits them most (although they'll have to stick to that single version then). Cheers Christian

1 0

Any way to catch runtime errors in a DLL?
by Michael Marte 16 Jun '06

16 Jun '06

Hello *, if a runtime error occurs inside a DLL compiled by ghc (like "irrefutable pattern match failed" or exceptions caused by error), the application that called the DLL function dies. This is ok for development but unacceptable when it happens with a user sitting in front of the display. (It has not yet happened but it's only a question of time.) So my question is: Is there any way to catch and process runtime errors? I am looking for some way to map those errors to exceptions on the C++ side that can be caught if required. It would be ok to kill the Haskell runtime system and unload the DLL if necessary. Michael

5 6

installing a Cabal package non-exposed
by Christian Maeder 15 Jun '06

15 Jun '06

Hi, how can install a Cabal package hidden directly? Currently I simply install it and have to hide it afterwards, manually. (Meanwhile one could get a conflict with new exposed modules.) I've tried "./setup register --gen-script" and edit the file "register.sh", but that does not install the .a file. Thanks Christian

2 1