August 2006 - Glasgow-haskell-users

Lookup module and package defining <<x>?
by Marc Weber 08 Aug '06

08 Aug '06

Has somene already implemented something like: $ghc-pkg --where-from ParseError package parsec: defining modules: Text.ParserCombinators.Parsec.Error, Text.ParserCombinators.Parsec ? lambdabot @index does what I want, but not with my libs installed only locally.. This might be used by any developement system for easily importing modules.. If not I'll start working on this and I'll post again after needing help ;) or finishing It can't be that hard because there is already ghc-pkg list and ghc --show-iface ... Marc

6 7

wislist item: more control over branch prediction
by Duncan Coutts 08 Aug '06

08 Aug '06

So now that GHC is so good at producing really fast low level code (see ByteString benchmarks) we start to encounter low level gubbins where to get the fastest possible code we need slightly more influence over branch prediction. In the code for ByteString's 'writeStrUp/Dn' functions we're doing a tight loop writing bytes to memory. The first version looks much like this: loop fp n off s = case next s of Done -> return $! PS fp 0 off Skip s' -> loop fp n off s' Yield x s' -> do withForeignPtr fp $ \p -> pokeByteOff p off x loop fp n (off+1) s' When we get to the end of a memory block we need to double the size of the memory block and carry on. So this adds an additional conditional test into this loop. loop fp n off s = case next s of Done -> trimUp fp n off Skip s' -> loop fp n off s' Yield x s' | n == off -> realloc fp n off s' x | otherwise -> do withForeignPtr fp $ \p -> pokeByteOff p off x loop fp n (off+1) s' There are dramatic differences between equivalent forms of code. Just by reversing the order of the (n==off) test one form I can process 50Mb of data in 0.20 seconds and in the other it takes 0.34 seconds. That is: | n == off -> realloc fp n off s' x | otherwise -> do ... vs | n /= off -> do ... | otherwise -> realloc fp n off s' x I think that this is all down to branch prediction and the arrangement of basic blocks. On a modern CPU correctly predicted branches are nearly free while mis-predicted branches are very costly due to stalled pipelines etc. In gcc they have a branch prediction framework. It annotates conditionals with prediction information. It then uses that during code generation to do things like arranging basic blocks so that unlikely blocks are moved out of line. It gets the prediction information from a few sources. One is a simple static branch predictor, for example branches back to to the beginning of a loop are likely to be taken and branches to error functions are not. gcc even has a profile feedback system to find the real probabilities of branches from a sample run of the program. It also has a user annotation __builtin_expect() which many C projects use in the form of a macro: if (unlikely(x==0)) { ... The Linux kernel uses this fairly heavily to move error handling code out of the main 'fast path' code. Anyway, so what I wish is that I could write something like: loop fp n off s = case next s of Done -> {-# UNLIKELY #-} trimUp fp n off Skip s' -> loop fp n off s' Yield x s' | n == off -> {-# UNLIKELY #-} realloc fp n off s' x | otherwise -> do withForeignPtr fp $ \p -> pokeByteOff p off x loop fp n (off+1) s' The best approximating effect that I can use at the moment is to make the unlikely realloc branch a local function in a where clause but mark it with {-# NOINLINE #-} so that the code for the realloc case doesn't pollute the tight loop for the normal fast case. Then the other approximation is fiddling with the logic of the binary test and looking at the benchmarks. The combination of these two techniques makes a dramatic difference to the speed. However I do need more control to do it reliably, while I was able to make it work for writeStrUp, I could not find a combination to work for writeStrDn - we loose about 50% performance when we add the realloc branch. So a slightly more reliable method to hint at the likelihood of conditionals would make this kind of low level code faster and easier to write. Some time ago as a quick hack I did add a branch prediction annotation to the CMM conditional constructor. I only used it in the C backend to turn it into uses of gcc's __builtin_expect(). I also didn't connect it to the front end so I didn't have any high level static branch prediction (which could be done by looking for branches with recursive calls or calls to error etc). The only place I did actually use it was in the heap check and stack check. I assumed that it would be advantageous to predict heap and stack overflow branches as not taken. It was only a quick hack - I didn't do any benchmarks to see if it had any effect. Anyway, just a thought, and of course not something we should be thinking about 'til post 6.6. Duncan

1 0

Evaluating expressions in Visual Haskell
by Vyacheslav Akhmechet 08 Aug '06

08 Aug '06

Hi, I apologize if this question has been asked before, but I couldn't find an FAQ or the answer online. Does Visual Haskell have support for evaluating expressions? I tried a few things (like highlighting an expression, rightclicking, and looking for "evaluate" option) but couldn't find anything. If this feature is missing, is it planned? Also, what is a good way to do this together with Visual Haskell? I could, of course, open an interpreter in a command window, load appropriate modules, and evaluate expressions from there but is there a more "integrated" way? Thanks, - Slava Akhmechet

2 1

Graphics library very slow
by Vyacheslav Akhmechet 08 Aug '06

08 Aug '06

The latest stable release seems to have some sort of a problem with the graphics library (the general one as well as the wrapper used in SOE). Opening a window takes more than a couple of minutes (on Windows XP). When I run an identical version of the code through Hugs, the window opens immediately. Am I doing something wrong? Thanks, - Slava.

4 4

default declarations
by Daniel Fischer 07 Aug '06

07 Aug '06

Hi, apparently ghci doesn't take default declarations into account. Inspired by a question on the hugs-users list I wrote module BoolNum where default (Bool, Rational) instance Num Bool where (+) = (/=) (-) = (/=) (*) = (&&) negate x = x abs x = x signum x = x fromInteger = odd and in hugs, as expected I get BoolNum> 1 True but in ghci, it's *BoolNum> 1 1, no defaulting apparently takes pkace. Why? Bug or feature ? Cheers, Daniel -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton

2 1

Re: GHC 6.4.3 is stalled
by Simon Marlow 04 Aug '06

04 Aug '06

I just realised I sent the following only to cvs-ghc(a)haskell.org, not glasgow-hasell-users: Simon Marlow wrote: > Just a quick note to say thanks for all the offers of help on 6.4.3 - > it's very encouraging to see so many people willing to offer their time > and machines. > > The state of play so far: > > On FreeBSD, reports suggest that there's are one or possibly two > problems exposed by the threaded RTS. The timeout program in the > testsuite sometimes hangs, and GHC itself may hang when linked against > the threaded RTS. This looks like a tricky one, so I'm going to try to > look into it myself. I've installed FreeBSD 6.1 on an old laptop and > I'm currently building 6.4.2 on it. > > On MacOS X / PPC, we have a crashing stage2 when linked against the > threaded RTS. Gregory Wright is trying to reproduce the problem on a > smaller scale (with something other than GHC). > > The "timeout hanging" problem apparently happens on MacOS X/Intel too > (according to Joel Reymont). If I find the cause on FreeBSD, we can > test the fix on MacOS X/Intel. I have an update on FreeBSD. I built the CVS 6.4 branch on a fresh install of FreeBSD, and ran the testsuite: OVERALL SUMMARY for test run started at Thu 3 Aug 2006 09:42:30 BST 1365 total tests, which gave rise to 4157 test cases, of which 0 caused framework failures 583 were skipped 3505 expected passes 46 expected failures 2 unexpected passes 21 unexpected failures Unexpected passes: cholewo-eval(optasm) ffi009(optasm) Unexpected failures: arith011(opt) barton-mangler-bug(normal,opt,ghci,threaded) cabal01(normal) galois_raytrace(ghci) ioref001(normal,threaded) joao-circular(normal,opt,optasm,threaded) newtype(opt) queryfdoption01(normal,opt,optasm,threaded) rn.prog006(normal) seward-space-leak(ghci) signals002(threaded) Some of those failures are probably due to running out of memory on this laptop (which only has 128M + 256M swap, I should have given it more swap). But I don't see any evidence of hanging timeout processes and stage2 apparently works fine. That means the problem only shows up on a dual proc/dual core (Gregory reported seeing this on a dual proc build of FreeBSD). Greg - can you give me SSH access to your box, and I'll take a look? Cheers, Simon

2 1

returning to cost of Integer
by Serge D. Mechveliani 02 Aug '06

02 Aug '06

Dear GHC developers, Long ago you wrote that GHC has made Integer only about 3/2 times slower than Int. I tested this once, and then all this time I have been relying on this. Now, with ghc-6.4.1 compiled for Linux - i386-unknown, running under Debian Linux, Intel Pentium III under ghc -O, I have an occasion to repeat the test on a certain simple program for processing lists of length 7 over Integer. And Integer shows 2.55 times slower (11.2 sec against 4.4). Showld we somehow agree that cost(Integer)/cost(Int) in GHC is about 2.55 or maybe we are missing something? ----------------- Serge Mechveliani mechvel(a)botik.ru

8 13

Replacement for GMP
by Peter Tanski 02 Aug '06

02 Aug '06

Esa, In the July thread, (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; OS X and OpenSSL, you wrote: > In past, I tried to get rid of GMP by replacing it with libtommath > http://math.libtomcrypt.com/ > But I have given up for now - because of related and unrelated > problems. Since I had no prior experience with LibTomMath I decided to take a look at it. The most recent release version of LibTomMath seems to be 0.39. Were some of the "related problems" you ran into due to bugs in an earlier version of LibTomMath? Maybe it is premature for me to go looking at replacing Integer when GHC has already moved so far ahead of itself I have to service the source code just to get it to build on OS X, but I figure that while I have the hood up I might as well take a look at the rest of the engine... If you have any old notes on the problems you encountered, I would greatly appreciate it. -Pete Tanski

5 12

Re: Glasgow-haskell-users Digest, Vol 35, Issue 23
by p.tanski＠gmail.com 01 Aug '06

01 Aug '06

Brian, The standard method of skirting the LGPL restriction and saving your source code is to link dynamically in a separate step and then distribute your program along with the dynamically linked LGPL'd library. Compile with ghc -c (or with ghc -c -odir 'separate directory where you want to store the object files') and pass specific lines to the linker through gcc with -optc. Then link the object files for your program separately using ld and distribute the ghc runtime libraries you need to dynamically link along with your program. Some of these runtime libraries are big but on average libHSrts_dyn, libHSbase_dyn and libHSbase_cbits_dyn do the trick (I have needed cbits up for programs that use -ffi). Bulgat, Yes, GMP allows the fastest implementation but the problem I posed with GHC concerned "native" Integers, meaning that the actual implementation of Integer would be internal to the language implementation--i.e., not written in Haskell. I guess--I don't know GHC's internals apart from reading papers, such as "Haskell on a Shared-Memory Multiprocessor"--the memory problem would involve adding "carry" tag to chain thunks and allow lazy arbitrary precision arithmetic without resorting to program-level constructs like lists or big arrays. My point concerning other functional languages (OCaml and ML through MLton) was that gmp (or gmp-style) programs seem to be a common way of implementing the representation. Evolution means getting beyond that: is there another possibility? Esa, > I think the idea is to get rid of annoying dependencies (GMP), and not to > create new ones (C++). There's few other big ifs with APREC as far as I > see: Fiddling with FPU precision regs in x86 and possibly problems in > Windows environment. It might require a bit fiddling to get memory > handling right when using APREC, as well. Right on. I like ARPREC for some programs; it is easy and fast but I can imagine encountering problems when building it on Windows. ARPREC also keeps its own internal memory representation: to use it from c you essentially have to pass the numbers to its own runtime system (i.e., you have to initialise ARPREC and allocate memory for a variable using c_mpnew() before you can use it). It was just a suggestion to think about... -Peter On 7/30/06, glasgow-haskell-users-request(a)haskell.org <glasgow-haskell-users-request(a)haskell.org> wrote: > Send Glasgow-haskell-users mailing list submissions to > glasgow-haskell-users(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > or, via email, send a message with subject or body 'help' to > glasgow-haskell-users-request(a)haskell.org > > You can reach the person managing the list at > glasgow-haskell-users-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Glasgow-haskell-users digest..." > > > Today's Topics: > > 1. Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL (Seth Kurtzberg) > 2. (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; OS > X and OpenSSL (p.tanski(a)gmail.com) > 3. Re: Re: Rebuilding GHC on Mac OSX PPC (p.tanski(a)gmail.com) > 4. Re: (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; > OS X and OpenSSL (Bulat Ziganshin) > 5. Re: (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; > OS X and OpenSSL (Esa Ilari Vuokko) > 6. Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL (Brian Hulley) > 7. Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL (Esa Ilari Vuokko) > 8. Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL (Duncan Coutts) > 9. Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL (Brian Hulley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 29 Jul 2006 22:09:45 -0400 > From: Seth Kurtzberg <seth(a)cql.com> > Subject: Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL > To: p.tanski(a)gmail.com > Cc: glasgow-haskell-users(a)haskell.org > Message-ID: <20060729220945.92f3f263.seth(a)cql.com> > Content-Type: text/plain; charset=US-ASCII > > On Sat, 29 Jul 2006 21:45:21 -0400 > p.tanski(a)gmail.com wrote: > > > GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN. > > I have two questions concerning this: > > > > (1) Why not use the ARbitrary PRECision Computation Package (ARPREC) > > by David Bailey, Yozo Hida, Karthik Jeyabalan, Xiaoye Li and Brandon > > Thompson? Here is a reference web page: > > http://crd.lbl.gov/~dhbailey/mpdist/ > > > > ARPREC is written in C++ but supports calls from C (see > > include/arprec/c_mp.h in the distribution directory). ARPREC is very > > fast and supports more complex mathematics than BN. The Licensing for > > ARPREC is not a problem: essentially similar to BSD3. > > > > Note that there would be a basic configuration fix for building > > OpenSSL's BN library on OS 10.4: you would probably--I had to, > > myself--have to temporarily move the default installation of > > /usr/lib/libssl0.9.dylib (and variants) if you want to create a shared > > (.a) library because Apple's ln links dynamic libraries in preference > > to shared libraries. > > I think you meant "if you want to create a static (.a) library", not "if you want to create a shared (.a) library" > > Those of you who have some experience with > > Apple's gcc also know that Apple's gcc does not recognise the -shared > > flag. > > > > (2) A much more aesthetic solution would be to replace any external > > Bignum library with a pure Haskell library. There are many problems > > with building a truly efficient and fast Bignum library in Haskell but > > challenges like that are how languages evolve... > > > > -Peter Tanski > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > ------------------------------ > > Message: 2 > Date: Sat, 29 Jul 2006 23:21:07 -0400 > From: p.tanski(a)gmail.com > Subject: (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; OS > X and OpenSSL > To: glasgow-haskell-users(a)haskell.org > Message-ID: > <f501497f0607292021w43160d44t3b4dc11a0478cdf7(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > (Sorry for the repost: I needed to correct a few typos--thanks > Seth--and clarify a few things.) > > GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN. > I have two questions concerning this: > > (1) Why not use the ARbitrary PRECision Computation Package (ARPREC) > by David Bailey, Yozo Hida, Karthik Jeyabalan, Xiaoye Li and Brandon > Thompson? Here is a reference web page: > http://crd.lbl.gov/~dhbailey/mpdist/ > > ARPREC is written in C++ but supports calls from C (see > include/arprec/c_mp.h in the distribution directory). ARPREC is very > fast and supports more complex mathematics than BN. The Licensing for > ARPREC is not a problem: essentially similar to BSD3. > > Note that there would be a basic configuration fix for building > OpenSSL's BN library on OS 10.4: you would probably--I had to, > myself--have to temporarily move the default installation of > /usr/lib/libssl0.9.dylib (and variants) if you want to create a static > (.a) library because Apple's ln links dynamic libraries in preference > to static libraries. > > (2) A much more aesthetic solution would be to replace any external > Bignum library with a pure Haskell library. There are many problems > with building a truly efficient and fast Bignum library in Haskell but > challenges like that are how languages evolve... Both GHC and nhc98 > seem to use GMP, OCaml uses a custom bignum library written by Xavier > Leroy and even MLton uses GMP. Robert Dockins wrote a type-based > library for arbitrary that can (slowly) handle big numbers (up to > 10^15), see http://www.eecs.tufts.edu/~rdocki01/typenats.html I don't > know what the constraints on making such native Integer support work > in GHC but my comment on the evolution of Haskell was not meant badly: > native Integer support would require modifications to how Integers are > handled in memory. (I would be glad to lend whatever support I could > on this, but it seems like a big project.) > > -Peter Tanski > > > ------------------------------ > > Message: 3 > Date: Sun, 30 Jul 2006 00:29:43 -0400 > From: p.tanski(a)gmail.com > Subject: Re: Re: Rebuilding GHC on Mac OSX PPC > To: glasgow-haskell-users(a)haskell.org > Message-ID: > <f501497f0607292129m2387ebbejbb3f9540fc3841d2(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Sorry to flood your mailboxes with my junk, but I had a few questions > on the configuration and Makefiles for building GHC on OS 10.4: > > The odd memory bugs (wierd malloc errors) seem to remind me of errors > using pthreads... > > in Joel Reymont's email, I noticed that ghc is given the -threaded option: > > ../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.3 ... > ... -threaded -package readline -DUSE_READLINE - > > I have not had any luck using -threaded with GHC on my own programs, > but I do not know what options GHC passes to gcc with -threaded. If > GHC -threaded means it passes gcc > the -pthread option when compiling -fvia-C, the problem might be that > Apple's gcc does not recognize the -pthread flag (you have to link > -lpthread manually, preferably after the object files). > > If I can get the configuration correct--or whatever parameters you > think you might want--I will get a clean distribution and try to build > ghc-6.4.3 tomorrow (I am using a 1.25 MHz PPC). > > -Peter Tanski > > > ------------------------------ > > Message: 4 > Date: Sun, 30 Jul 2006 10:35:20 +0400 > From: Bulat Ziganshin <bulat.ziganshin(a)gmail.com> > Subject: Re: (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; > OS X and OpenSSL > To: p.tanski(a)gmail.com > Cc: glasgow-haskell-users(a)haskell.org > Message-ID: <664568392.20060730103520(a)gmail.com> > Content-Type: text/plain; charset=us-ascii > > Hello p, > > Sunday, July 30, 2006, 7:21:07 AM, you wrote: > > > Leroy and even MLton uses GMP. Robert Dockins wrote a type-based > > library for arbitrary that can (slowly) handle big numbers (up to > > 10^15), see http://www.eecs.tufts.edu/~rdocki01/typenats.html I don't > > this don't have anything common with our problem of implementing > efficient runtime library > > > know what the constraints on making such native Integer support work > > in GHC but my comment on the evolution of Haskell was not meant badly: > > native Integer support would require modifications to how Integers are > > handled in memory. (I would be glad to lend whatever support I could > > on this, but it seems like a big project.) > > imho, you are wrong. current representation allows fastest operations. > but anyway Haskell code will be several times slower than C one - even > for GHC, much more for Haskell interpreters > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > > > ------------------------------ > > Message: 5 > Date: Sun, 30 Jul 2006 13:00:24 +0300 > From: "Esa Ilari Vuokko" <eivuokko(a)gmail.com> > Subject: Re: (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; > OS X and OpenSSL > To: "p.tanski(a)gmail.com" <p.tanski(a)gmail.com> > Cc: glasgow-haskell-users(a)haskell.org > Message-ID: > <cd4c8b540607300300m7dbd4359q1aea51d723500cf0(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi > > On 7/30/06, p.tanski(a)gmail.com <p.tanski(a)gmail.com> wrote: > > (Sorry for the repost: I needed to correct a few typos--thanks > > Seth--and clarify a few things.) > > > > GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN. > > I have two questions concerning this: > > > > (1) Why not use the ARbitrary PRECision Computation Package (ARPREC) > > by David Bailey, Yozo Hida, Karthik Jeyabalan, Xiaoye Li and Brandon > > Thompson? Here is a reference web page: > > http://crd.lbl.gov/~dhbailey/mpdist/ > > > > ARPREC is written in C++ but supports calls from C (see > > include/arprec/c_mp.h in the distribution directory). ARPREC is very > > fast and supports more complex mathematics than BN. The Licensing for > > ARPREC is not a problem: essentially similar to BSD3. > > I think the idea is to get rid of annoying dependencies (GMP), and not to > create new ones (C++). There's few other big ifs with APREC as far as I > see: Fiddling with FPU precision regs in x86 and possibly problems in > Windows environment. It might require a bit fiddling to get memory > handling right when using APREC, as well. > > In past, I tried to get rid of GMP by replacing it with libtommath > http://math.libtomcrypt.com/ > But I have given up for now - because of related and unrelated problems. > > But, whoever starts the work probably gets to pick their lib, so OpenSSL's > BN, APREC, LibTomMath or anything else...it's open :-) > > Best regards, > Esa > > > ------------------------------ > > Message: 6 > Date: Sun, 30 Jul 2006 11:53:30 +0100 > From: "Brian Hulley" <brianh(a)metamilk.com> > Subject: Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL > To: <p.tanski(a)gmail.com>, <glasgow-haskell-users(a)haskell.org> > Message-ID: <002801c6b3c7$5cab93d0$c8ec2950@osmet> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=response > > p.tanski(a)gmail.com wrote: > > GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum > > library, BN. I have two questions concerning this: > > >From the ticket, this looks very scary: > > but its LGPL license is problematic for users of GHC > (it prohibits static linking of GHC-compiled programs, for > example). > > Does this mean I can't distribute my Haskell app as a commercial > application? I certainly don't want to distribute source code and I've got > no idea how to compile a Haskell app other than using ghc --make, which > creates a single exe ie with static linkage. > > If I only use Int's (not Integer's) in my code, is there a way to get rid of > GMP so that I won't have an impossible licencing problem when trying to > distribute my application binary? If not, then it would seem absolutely > vital to get rid of GMP as soon as possible or else try to persuade the > authors to add the usual static linking exception to their LGPL licence for > it. > > Thanks, Brian. > > -- > Logic empowers us and Love gives us purpose. > Yet still phantoms restless for eras long past, > congealed in the present in unthought forms, > strive mightily unseen to destroy us. > > http://www.metamilk.com > > > > ------------------------------ > > Message: 7 > Date: Sun, 30 Jul 2006 14:18:30 +0300 > From: "Esa Ilari Vuokko" <eivuokko(a)gmail.com> > Subject: Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL > To: "Brian Hulley" <brianh(a)metamilk.com> > Cc: p.tanski(a)gmail.com, glasgow-haskell-users(a)haskell.org > Message-ID: > <cd4c8b540607300418s744b3972w4cf3230083e8ac77(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 7/30/06, Brian Hulley <brianh(a)metamilk.com> wrote: > > p.tanski(a)gmail.com wrote: > > > GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum > > > library, BN. I have two questions concerning this: > > > > >From the ticket, this looks very scary: > > > > but its LGPL license is problematic for users of GHC > > (it prohibits static linking of GHC-compiled programs, for > > example). > > > > Does this mean I can't distribute my Haskell app as a commercial > > application? I certainly don't want to distribute source code and I've got > > I am not a lawyer, and you should consult lawyer if you want real > advice about licensing issues. > > Strict answer to first question: No. You can distribute statically compiled > binaries. > > > no idea how to compile a Haskell app other than using ghc --make, which > > creates a single exe ie with static linkage. > > But in this case, yes, you can't. You need to provide way to > relink gmp in you program. As far as I know, this is simply possible > by taking all the objs --make generates, other objs and libs and giving > them on - users need to have ghc distro+their own gmp set in. > > > If I only use Int's (not Integer's) in my code, is there a way to get rid of > > GMP so that I won't have an impossible licencing problem when trying to > > I am fairly certain you cannot force or rely GMP getting dropped by > linker. > > > distribute my application binary? If not, then it would seem absolutely > > vital to get rid of GMP as soon as possible or else try to persuade the > > authors to add the usual static linking exception to their LGPL licence for > > it. > > GMP being rather GNU ;-) replacing is probably the only option. > > There's other reason for dropping GMP as well: The ghc rts steals GMP > memory allocation (sort of integrating it with garbage collector) which > makes it impossible for other parts of program use GMP (in practice). > > HTH, > --Esa > > > ------------------------------ > > Message: 8 > Date: Sun, 30 Jul 2006 12:58:09 +0100 > From: Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> > Subject: Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL > To: Brian Hulley <brianh(a)metamilk.com> > Cc: p.tanski(a)gmail.com, glasgow-haskell-users(a)haskell.org > Message-ID: <1154260689.14437.26.camel@localhost> > Content-Type: text/plain > > On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote: > > p.tanski(a)gmail.com wrote: > > > GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum > > > library, BN. I have two questions concerning this: > > > > >From the ticket, this looks very scary: > > > > but its LGPL license is problematic for users of GHC > > (it prohibits static linking of GHC-compiled programs, for > > example). > > > > Does this mean I can't distribute my Haskell app as a commercial > > application? I certainly don't want to distribute source code and I've got > > no idea how to compile a Haskell app other than using ghc --make, which > > creates a single exe ie with static linkage. > > GHC only statically links Haskell code. It dynamically links to GMP and > the system C library and other C libs. > > So you're fine. > > On unix you can check for yourself with ldd. It lists all the shared > libs that your program needs. For example: > > $ ldd /usr/lib/ghc-6.4.2/ghc-6.4.2 > libreadline.so.5 => /lib/libreadline.so.5 (0x00002b568fca6000) > libncurses.so.5 => /lib/libncurses.so.5 (0x00002b568fde3000) > libdl.so.2 => /lib/libdl.so.2 (0x00002b568ff3f000) > libm.so.6 => /lib/libm.so.6 (0x00002b5690042000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00002b569019a000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00002b56902cf000) > libc.so.6 => /lib/libc.so.6 (0x00002b56903e4000) > /lib64/ld-linux-x86-64.so.2 (0x00002b568fb8e000) > > Duncan > > > > ------------------------------ > > Message: 9 > Date: Sun, 30 Jul 2006 13:21:12 +0100 > From: "Brian Hulley" <brianh(a)metamilk.com> > Subject: Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and > OpenSSL > To: "Esa Ilari Vuokko" <eivuokko(a)gmail.com> > Cc: glasgow-haskell-users(a)haskell.org > Message-ID: <003901c6b3d2$a6c01cb0$c8ec2950@osmet> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=response > > Esa Ilari Vuokko wrote: > > On 7/30/06, Brian Hulley <brianh(a)metamilk.com> wrote: > >> p.tanski(a)gmail.com wrote: > >>> GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum > >>> library, BN. I have two questions concerning this: > >> > >>> From the ticket, this looks very scary: > >> > >> but its LGPL license is problematic for users of GHC > >> (it prohibits static linking of GHC-compiled programs, for > >> example). > [snip] > > But in this case, yes, you can't. You need to provide way to > > relink gmp in you program. As far as I know, this is simply possible > > by taking all the objs --make generates, other objs and libs and > > giving them on - users need to have ghc distro+their own gmp set in. > > Hi Esa - > Thanks for reminding me about the distinction between source and object > files. I keep forgetting that object files exist (!) and that it's > sufficient for LGPL to just make them available. > > Still, a slight problem is that since there is one object file per source > file, the names of the object files give quite a lot of information away > about the structure of the program especially when they are arranged in a > module hierarchy, so I'll be glad when GMP is replaced by something without > such a burdensome licence. (Although perhaps I can bundle my object files > into a single library file but I don't know how to do this yet, or if it > would really help in the goal to make the code completely obfuscated, > impenetrable, and unavailable to any rival company... ;-) ) > > Thanks again, > Brian. > -- > Logic empowers us and Love gives us purpose. > Yet still phantoms restless for eras long past, > congealed in the present in unthought forms, > strive mightily unseen to destroy us. > > http://www.metamilk.com > > > > ------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > End of Glasgow-haskell-users Digest, Vol 35, Issue 23 > ***************************************************** >

7 13

RE: Internships on GHC and Haskell at MSR Cambridge
by Simon Peyton-Jones 01 Aug '06

01 Aug '06

| MSR Cambridge now takes interns *year-round*, not just in the summer months. Simon Marlow and I | are keen to attract motivated and well-qualified folk to work with us on our research, and on improving | or developing GHC. PS: concerning the enclosed, if you are interested in an internship at MSR for the October-December 2006 period, you'll need to get weaving very quickly. Because of summer holidays etc, we'll be taking decisions in the week of 14 August, so you'll need to get your application (including references) in by 13 August. Simon | -----Original Message----- | From: Simon Peyton-Jones | Sent: 25 July 2006 10:56 | To: haskell-cafe(a)haskell.org; haskell(a)haskell.org; glasgow-haskell-users(a)haskell.org | Subject: Internships on GHC and Haskell at MSR Cambridge | | Gentle Haskellers | | Would you be interested in working for three months at Microsoft Research, Cambridge, on a project | related to GHC or Haskell? | | MSR Cambridge now takes interns *year-round*, not just in the summer months. Simon Marlow and I | are keen to attract motivated and well-qualified folk to work with us on our research, and on improving | or developing GHC. | | If you or one of your students is interested, you can find more details here | http://hackage.haskell.org/trac/ghc/wiki/Internships | | Our next empty slot is the Oct-Dec period, but you are welcome to apply for some later period. | | Simon PJ | | PS: There are lots of other programming-language folk at MSR (F#, security, probabilistic | languages...), and stuff beyond that (machine learning, systems and networks...); see | http://research.microsoft.com/aboutmsr/labs/cambridge/

1 0