- Libraries - Haskell.org

Re: [Haskell-cafe] strange stack overflow with Data.Map
by David Roundy 04 Jan '06

04 Jan '06

On Thu, Dec 29, 2005 at 01:42:29PM +0100, Christian Maeder wrote: > David Roundy wrote: > >>stats elems = foldl add_elem Map.empty elems > >>add_elem m x = Map.insertWith (+) x 1 m > > > >>main = print $ stats $ take 1000000 $ repeat 1 > > > >This program has a space leak and runs out of stack space. I'm guessing > >that I'm being bit here by an unnatural amount of laziness in > >Map.insertWith, but I can't see how to fix this. :( I'm sure it's > >something elementary... > > try: > > stats = foldl' add_elem Map.empty > add_elem m x = myinsertWith (+) x 1 m > > myinsertWith f k v m = > case Map.lookup k m of > Nothing -> Map.insert k v m > Just w -> let r = f v w in r `seq` Map.insert k r m Thanks, that does it! I had tried something like that, but without the foldl', and had tried foldl', but without the myinsertWith. The reason I didn't spend much time using this implementation is that for large maps, it will take twice as long as Map.insertWith, so I assumed (incorrectly) that Map.insertWith should be written so that it behaves in a non-leaky manner. Should the Map modules have an additional Map.insertWith' that behaves strictly, or might it be the case that you always want strict behavior when using insertWith? -- David Roundy http://www.darcs.net

9 19

Cabal and Hooks?
by Dimitry Golubovsky 03 Jan '06

03 Jan '06

I am developing an extension to HSFFIG to create Haskell packages out of C header files. Before I start reinwenting the wheel, I would like to reuse as much of Cabal functionality as possible. I am trying to figure out whether the following can be done with user hooks using Distribution.Smple. 1. I need to extend the Setup command line syntax with custom options (esp. Setup configure). For example, I need to specify locations for the imported C headers and libraries they relate to. The package description file does not seem to be a good place for them because on different systems these locations may be totally arbitrary. Results of parsing of those options must be visible to subsequent package building phases. These options also must appear in the help message. 2. I need to override the build process completely. The package build process is pretty much straightforward [1], but differs from the "standard" ghc --make: module dependencies are pregenerated by running GHC -M; all source files are compiled with the split_objs option one by one (when compiling tens/hundreds of modules with --make, memory used by GHC exceeds reasonable limits). Does the buildHook do the job (looks like it does, but just to make sure...)? 2a Another problem with build/install is that while the names of exposed-modules are known in advance (basically there is only one module to expose which re-exports the rest), names of other-modules are only known after the build completes. The source splitter may leave tens or even hundreds of separate modules (see HSFFIG tutorial: for example, a single module is created for every structure/union). It is impossible to specify them all in the package description file. Provided that the location of those modules is known, is there any way to state in the package description file that all modules at the given location should be "other-modules" (kind of a regexp)? I see the possibility to use Distribution.Make as a last resort. However it delegates too much functionality to the make and configure utilities; I would be happy to have more Cabal on my side ;) Thanks for any ideas. --------------- [1] http://haskell.org/hawiki/HsffigLinkageOptimization -- Dimitry Golubovsky Anywhere on the Web

1 0

Data.Set clone available
by Adrian Hey 01 Jan '06

01 Jan '06

Hello folks, I've put and AVL tree based clone of Data.Set here.. http://homepages.nildram.co.uk/~ahey/HLibs/AvlSet/AvlSet.html This should make it easy to do comparitive test/measurements between the two and maybe experiment with any wishlist extensions you want for the revised API (which is WIP I believe), using the underlying AVL implementation. I'll do the same thing for Data.Map soon, though it'll probably have to wait until next weekend now. This module is completely untested but the underlying AVL library has been pretty thouroughly tested. So it should work OK. If you use it and find any problems please let me know. Regards -- Adrian Hey

1 0

Re: [Haskell] more newbie questions regarding do syntax, mondic context & Data.HashTable
by Jean-Philippe Bernardy 29 Dec '05

29 Dec '05

On 12/29/05, Hunter Kelly <retnuh(a)gmail.com> wrote: > Hi there, I'm having some trouble trying to get information out > of a HashTable. > > I'm using it to represent a set (I'm using a hash table for O(1) > speed reasons to compare against Data.Sets O(lgN) operations). > I don't think anyone has ever asked for a "pure" version of the hashtable. (It could be frozen and thawed in the same fashion as Arrays are). Maybe someone has written something like that and is willing to share? On the other hand, it's entirely possible that you can get away with either Data.Map or saying within the IO monad. Cheers, JP.

2 1

RE: cabal release (was: cabal experiences)
by Simon Peyton-Jones 27 Dec '05

27 Dec '05

| then. 1.2 might be a good version to get into ghc 6.6, though I | expect that it won't have configurations or shipments, since we won't | have much time to try those out. What's the schedule like for ghc 6.6? Well, the plan is for 6.6 to have impredicative types, and revised GADTs. I'd like to fix the interaction of type classes and GADTs too. And we'd like to have shaken down the parallel implementation a bit. The natural time for 6.6 feels like at least 3 months from now -- and we'd rather not get pinned down to any dates for a while yet. If the reason you want 6.6 is to get a new Cabal, why not download a new Cabal package? Or is there another reason you want 6.6? Bug-fixes to 6.4 are a much smaller deal. Simon

9 9

release of sha256/sha512 library
by David Mercer 27 Dec '05

27 Dec '05

We are pleased to announce Version 0.21a, the initial functioning release of Shaskell, our SHA2 library for (so far) ghc6. It supports sha256 and sha512 hashes in this version, and is "pure": no monads or C libraries are involved! Source and Ubuntu 5.04 binaries are at: http://davidmercer.nfshost.com/projects/shaskell/ (Shaskell-0.21a.hs is the current release). Project homepage is at: http://davidmercer.nfshost.com/projects/shaskell/shaskell.html Future releases will additionally support sha224, sha384, be Cabal-ized, and supply wrappers for hashing files and other data sources where the message length is not known in advance. Special thanks to Dominic Steinitz for invaluable suggestions. Any testing or feedback is of course welcome and appreciated! It is released under the (BSD compatible) MIT X license. Happy New Year, hopefully this will help improve the security of future crypto systems written in Haskell. Cheers, -David Mercer Tucson, AZ

1 0

RE: lawbreakers in Text.PrettyPrint.HughesPJ
by Simon Peyton-Jones 22 Dec '05

22 Dec '05

I had trouble parsing your message. Are you saying that (a) before changing the library you have a program that compiles ok (b) after changing the library, the program becomes gigantic and won't link ? Nothing to do with *running* the program? If I have understood right, what are the sizes of the .o files in (a) and (b)? Has one (or lots) gotten gigantic? Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Christian | Maeder | Sent: 30 November 2005 14:45 | To: Simon Peyton-Jones | Cc: libraries(a)haskell.org | Subject: Re: lawbreakers in Text.PrettyPrint.HughesPJ | | Christian Maeder wrote: | > I've tried both versions, without noticing a difference. So take the | > following patch (as suggested by Conal). | | I became a problem with my (Conal's) suggested patch on a mac. When | compiled with optimization the code was so blown up that it could no | longer be linked on a mac. (The problem does not occur if only isEmpty | is changed as suggested before.) | | Unfortunately the example is large and takes ages to be reproduced and | it took me an age to find that the cause was my change to our version of | HughesPJ.hs. | | Christian | | the link error shows up as: | | [...] | /usr/bin/ld: ./Logic/Logic.o relocation overflow for relocation entry | 5401 in se | ction (__TEXT,__text) (displacement too large) | collect2: ld returned 1 exit status | make: *** [hets] Error 1 | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 2

official Cabal / Hackage wiki
by Isaac Jones 15 Dec '05

15 Dec '05

The new Cabal / Hackage wiki and bug tracking system is at: http://hackage.haskell.org/trac/hackage [1] Please report any Cabal (or HackageDB, cabal-get, etc) bugs there with "new ticket". Trac is pretty neat, you can inter-like wiki pages and tickets, as well as source code. Please feel free to start editing pages and adding information about Cabal. peace, isaac [1] Why the hackage...hackage redundancy? Well I'm basically hoping to roll out the "hackage" server as a community development site. As such, we have http://hackage.haskell.org/trac/ghc as well :)

1 0

RE: cabal release
by Simon Marlow 15 Dec '05

15 Dec '05

On 14 December 2005 01:28, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I'd be rather happier if we could solve the versioning issue with >> Cabal, so that upgrading Cabal in the future doesn't automatically >> break code. It might not be possible to do this the first time >> around, but now is the time to design our way out of future >> problems. > > We need to experiment with stuff. People want to use the advanced > features like hooks on complex packages, but no one wants the > cabal-1.0 interface to hooks! We're trying to maintain a tension > between experimenting and providing something stabler for simple > programs (just like Haskell itself). It's bad if that breaks stuff, > but I don't want to end up in a situation where we tie ourselves to a > bad implementation because 3 packages used the old interface. I think > we just need to be better about explicitly stating what is stable and > what is not. Absolutely, I understand that. I'm not suggesting every tiny revision of the interface must be available for ever. But I think it would help a great deal if a Cabal release could support the previous, say, 1 or 2 major revisions of the interface, just to smooth the transition, so that a new release didn't automatically break a lot of packages. eg. Setup.lhs would do this: import Distribution_1_2.Simple main = defaultMain all we have to do is provide Distribution_1_2.*. When we freeze a version, we create a bunch of stubs under Distribution_<ver>, using explicit export lists everywhere. Sometimes we'll have to add some backwards compatibility code. The latest experimental version of the interface is always available as Distribution.* (or maybe Distribution_cur.*, or something), with appropriate warnings generated by DEPRECATED pragmas that the interface is subject to change. I've been thinking about adding support to Haddock to compare versions of interfaces and tell you what the changes are, this would be great for documentation and also to make sure that we aren't breaking interfaces. Cheers, Simon

1 0

RE: cabal release (was: cabal experiences)
by Simon Marlow 14 Dec '05

14 Dec '05

On 12 December 2005 15:31, Ian Lynagh wrote: > On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote: >> >> In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. >> That is after installing GHC 6.4.1 we unregister Cabal-1.0 and >> install Cabal-1.1.3. > > If all distributions and users are going to have to do this to get a > usable system[1] then it seems obvious to me that ghc should already > come this way. That it doesn't causes headaches for packagers IME. I tend to agree. I'm not against breaking the rules in this case, since shipping Cabal-1.0 in 6.4.2 would be distinctly sub-optimal. Shipping two versions of Cabal is possible, but the build system isn't really set up to do this, so it's non-trivial work, and it still requires the user to say 'ghc-pkg expose Cabal-1.1.4; ghc-pkg hide Cabal-1.0'. Cabal is something of a special case, because its use is pretty much restricted to Setup.lhs scripts, which can be considered part of the build system rather than the code of a library or application. So this is build system API breakage, not library API breakage, m'lud ;-) I'd be rather happier if we could solve the versioning issue with Cabal, so that upgrading Cabal in the future doesn't automatically break code. It might not be possible to do this the first time around, but now is the time to design our way out of future problems. Cheers, Simon

2 1