Hi Rob, On Jun 2, 2006, at 10:26 AM, Robert Dockins wrote:

On Jun 1, 2006, at 9:46 PM, Gregory Wright wrote:

...

Hi Robert,

Edison 1.2rc4 builds on OS X 10.4.6/powerpc with ghc 6.4.2 and passes the test suite with no errors.

Excellent.

...

I have packaged it for the darwinports system, where it can be obtained as hs-Edison and hs-EdisonAPI. (It's packaged as two separate ports so that EdisonAPI is automatically built as a dependent of Edison. Users need only install the hs-Edison port.) You might want to consider distributing Edison's API and core separately in the future, to make life a bit easier for package management system like darwinports and FreeBSD ports.

Even better! Thanks for doing this.

What would be the preferred format for separate distribution packages? The thing that immediately comes to mind is to just take the standard distribution and delete irrelevant subdirectories.

Package managers like darwinports prefer to have just one configure; make; make install cycle per distribution (or the cabal equivalent). The most important thing is that a build not try to install anything in its final location before the "make install" phase. The package manager has to make an inventory of the files to be installed so it never accidentally overwrites files already installed and the package can be uninstalled cleanly. A simple way to repackage the Edison library would be to split it into two tarballs, one name Edison-1.2.tar and the other named EdisonAPI-2.1.tar. The internal format is not so important. As you suggest, the existing tarball could be split into two with the irrelevant subdirectories removed. Best Wishes, Greg

...

I will update the port to the final release when it comes out.

Best Wishes, Greg

On May 14, 2006, at 5:36 PM, Robert Dockins wrote:

...

Fellow Haskellers!

I am pleased to announce the 4th (and with any luck, final) release candidate for Edison 1.2. Edison is a library of efficient data structures for Haskell.

Changes from RC3 include:

* introduce strict/strictWith operations for all APIs * add Ord* instances for PatriciaLoMap and TernaryTrie * add David F. Place's EnumSet implementation * complete the FiniteMap unit test coverage and fix a bunch of bugs in finite map implementations * add 'symmetricDifference' to Collection and Associated Collection APIs * add Ord instances for data structures * add Monoid instances for data structures * Edison now requires Cabal 1.1.4 to build

The project homepage is located at:

http://www.eecs.tufts.edu/~rdocki01/edison.html

API docs are located at:

http://www.eecs.tufts.edu/~rdocki01/docs/edison/index.html

And the darcs repository is located at:

http://www.eecs.tufts.edu/~rdocki01/edison/

As before, comments are welcome, particularly comments relating to the API. However, barring major disasters I may have overlooked, I hope to release RC4 as 1.2, essentially unchanged.

Thanks, Rob Dockins _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Rob Dockins

Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

On Jun 1, 2006, at 11:57 PM, Jim Apple wrote:

...

I am pleased to announce the 4th (and with any luck, final) release candidate for Edison 1.2. Edison is a library of efficient data structures for Haskell.

Based on Exercise 10.2 of Okasaki's book

Roughly: "Reimplement AltBinaryRandomAccessList so that cons, head, and tail all run in O(1) amortized time, using the type

data RList a = Nil | One a (RList (a,a)) | Two a a (RList (a,a)) | Three a a a (RList (a,a))"

and the source for BinaryRandList at http://www.eecs.tufts.edu/~rdocki01/edison/_darcs/current/edison- core/src/Data/Edison/Seq/BinaryRandList.hs , I don't think the constant time bounds in the documentation are correct for this sequence type.

Ah, I see. I know we've discussed this implementation before, but it didn't quite become apparent to me that the documentation was in error. Does Okasaki say what the bounds should be for this implementation? I imagine it's O(log n), but my lazy-amortized- complexity-analysis-fu isn't very good...

Jim

Thanks, Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

On Jun 2, 2006, at 10:31 AM, Jim Apple wrote:

On 6/2/06, Robert Dockins wrote:

...

Does Okasaki say what the bounds should be for this implementation? I imagine it's O(log n), but my lazy-amortized- complexity-analysis-fu isn't very good...

I don't have the book out from the library anymore. Anybody?

There's also a paper & a thesis he wrote covering much of the same material. Some of the bounds might be in there.

I'll look around and see what I can find. As I recall, he doesn't specifically mention the bounds for these operations for this implementation, but it's been a little while since I looked.

We should probably also check the other exercises in the book to make sure the other bounds listed in the Haddock documentation for the other data structures are correct.

That's a good idea. I'll do a quick audit before the release to see if I can spot any other obvious errors.

Jim

Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG