- Libraries - Haskell.org

RE: Data.* collections maintenance
by Simon Marlow 24 Oct '05

24 Oct '05

On 24 October 2005 11:17, Sebastian Sylvan wrote: > On 10/24/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> On 22 October 2005 11:58, Adrian Hey wrote: >> >>> One problem with AVL is the complexity of most of the code means >>> producing specialised unboxed implementations manually is not an >>> attractive proposition. Hopefully compilers will do this sort of >>> thing for us one day. >>> >>> But in reality I expect this sort of thing to be more of an issue >>> for benchmark style code using Ints. For more complex keys and >>> comparisons the indirection cost will be relatively insignificant >>> I think. For polymorpic implementations counting the actual number >>> of comparisons required by some function is just as important IMO. >> >> It's not just benchmark code - in GHC we use Int-based maps all over >> the place for speed. Given your promising results for polymorphic >> AVL trees, it's a fair bet that you could beat Data.IntMap with a >> specialised Int version. If you did, we would be forced to use >> Data.Tree.AVL in GHC :) > > Wouldn't an Array (or DiffArray) based HashMap be even better? DiffArray as it stands isn't very efficient. It's an interesting idea, though. We should really have a DiffUArray, for one thing. Cheers, Simon

2 1

RE: Darcs supports pre-checkin hooks was Re: Controlled anarchy
by Simon Marlow 24 Oct '05

24 Oct '05

On 23 October 2005 13:10, Sven Panne wrote: > I see a dire need for more Haskell *maintainers*, not for more > developers or brand new shiny version control systems. With > "maintainers" I mean people accepting/testing/merging patches, > discussing with people about APIs, kicking coders to write tests for > their code, collecting opinions and writing down API proposals, > keeping existing APIs stable/sane/usable, etc. This is a lot of work, > it's difficult, time-consuming and much less fun than coding, but we > need those people. Darcs won't help with this at all... Here here... However, my impression is that moving to darcs is not purely an attempt at a technical solution to a social problem. Many of the people we want to attract as maintainers are the kind of people who appreciate good tools, an enjoy working with them. Adopting a better VC system would increase the Fun Factor for working with our code, which in turn will encourage more people to contribute. Maintaining libraries is quite boring. We need to make it more enjoyable. Cheers, Simon

1 0

RE: Data.* collections maintenance
by Simon Marlow 24 Oct '05

24 Oct '05

On 23 October 2005 16:19, Jean-Philippe Bernardy wrote: > Also, what's the current story on moving fptools/libraries to darcs? > While I agree with Sven that its not the solution to everything, I > would still prefer to use it over cvs. I think we have a plan, it's stalled a bit because I've been busy hacking on GHC's multiprocessor support to the exclusion of everything else. I'll try to send another email shortly and get the process moving again. Cheers, Simon

1 0

Re: Data.* collections maintenance
by Jean-Philippe Bernardy 23 Oct '05

23 Oct '05

Hello, I've outlined plans for the collections libraries at http://haskell.org/hawiki/StandardCollectionLibraries I've tried to find a reasonable compromise between the various opinions expressed. Also, what's the current story on moving fptools/libraries to darcs? While I agree with Sven that its not the solution to everything, I would still prefer to use it over cvs. Cheers, JP.

2 1

Re: [Haskell] Read Instances for Data.Map and Data.Set
by Christian Maeder 21 Oct '05

21 Oct '05

Georg Martius wrote: > Anyway since there was no response to S. Alexander Jacobson post [1], I > decided to write these instances at least for GHC in the style of the other > instances in GHC.Read. Who feels responsible for including something into Data.Set and Data.Map (recently I've proposed a change for Set.intersection and others also made suggestions)? The Read instances should be in "their" modules (to avoid "orphans"). But Set and Map should also remain "portable"! > import GHC.Read This module isn't even listed under http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Cheers Christian Simon, clicking on any module does not work, currently Not Found The requested URL /ghc/docs/latest/html/libraries/base/Control.Arrow.html was not found on this server. Apache/2.0.46 (Red Hat) Server at www.haskell.org Port 80

8 18

RE: Data.* collections maintenance
by Simon Peyton-Jones 21 Oct '05

21 Oct '05

Excellent thank you! If you fill in the Maintainer: field of the source files, then others will know who to contact (it appears in the Haddock docs). Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Jean- | Philippe Bernardy | Sent: 21 October 2005 08:37 | To: libraries(a)haskell.org | Subject: Data.* collections maintenance | | Hello, | | As some demand seem to exist for the job, I volunteer to take | over/resume maintenance of Data.Map and friends. In the hope that will | alleviate the heavy load on the compiler maintainers :) | | | Pending issues include : | - Better integration of Map and Set (proposed by John Meacham) | - More performance tests and QuickCheck properties (Christian Maeder) | - Monoid instances (is this still current ?) | | Surely I have missed something, please state your unaddressed bug | reports and wish list items. | | Cheers, | JP. | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Reason of OpenAL uses ccall, even on WinDoze ....
by shelarcy 20 Oct '05

20 Oct '05

Hello. I am chceking OpenAL CVS Log. Because I'm waiting that my patch is applied. And I saw this message: http://www.haskell.org//pipermail/cvs-libraries/2005-October/004551.html > Log: > For some obscure/unknown reason, OpenAL uses ccall, even on WinDoze... So I send again below message, and I notice where is the problem on windows. OpenAL uses ccall on Windows, because OpenAL's aclocal.m4 and configure.ac don't use AC_CANONICAL_*, so $host_os variable has no parameter, then 'ifeq "$(TARGETPLATFORM)" "i386-unknown-mingw32"' doen't work. I noticed this problem 2. of below message. On Mon, 26 Sep 2005 22:41:11 +0900, shelarcy <shelarcy(a)gmail.com> wrote: > I tried to build CVS HEAD, build is success on Windows. > But build is failure on Mac OS X, because you missunderstood my patch's > Mac OS X support part. > > > OpenAL/autoconf.ac must change two point. > > 1. AC_SEARCH_LIBS doesn't find framework's Library, Mac OS X can use > "-framework OpenAL" flag instead of "-l openal" option, and > FP_HEADER_AL > FP_HEADER_ALC can find headers. So you must change to declare > AC_SUBST([AL_FRAMEWORKS]) before checking to find library instead > of before checking to find header. > 2. OpenAL doesn't inherit platform parameter and dosen't declare > AC_CANONICAL_*, > so $host_os variable has no parameter and "case $host_os in" doesn't > work. > (I forgot this point earlier patch.) > > I send patch to fix these points. This patch tested on both Windows and > Mac OS X > platform. > >> If things go wrong, I need a log of the configuration and >> building + the generated config.log in fptools/libraries/OpenAL. > > And I send Mac OS X's config.log by CVS HEAD. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 0

RE: AVL Trees
by Simon Marlow 20 Oct '05

20 Oct '05

Duh. This is a case where moderation of the mailing list by looking at subject lines alone let some spam through. Sorry everyone. Simon On 20 October 2005 10:37, Cale Gibbard wrote: > Heh, not only is this not a Haskell library, it seems that it is only > available for AU$200, most likely not under a free license. It's not > even clear if the download includes the source code for the library, > where the algorithms could then be translated into Haskell, or if it > just includes headers and binaries. > > In this context, this appears to just be targetted spam. > > - Cale Gibbard > > On 19/10/05, Ben McNamara <tsoft(a)5trees.com> wrote: >> >> To Adrian Hey, >> >> I am emailing you to let you know about the release of a highly >> advanced C++ Tree Class Library (AVL) at www.5trees.com. >> >> This class library contains a number of different tree related >> classes. For example, dynamic arrays. The theory of finite, ordered >> sets is also explored. Concepts such as associative arrays (Maps or >> Dictionaries) are implemented within the tree class. >> >> In addition to trees, 5Trees has lists, stacks, queues, pools, heaps >> etc. >> >> 5Trees is highly advanced and very professional. It will save you >> time in your programming efforts and allow you to create highly >> advanced systems. >> >> Kind Regards, >> Ben McNamara. >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

1 0

AVL Trees
by Ben McNamara 20 Oct '05

20 Oct '05

To Adrian Hey, I am emailing you to let you know about the release of a highly advanced C++ Tree Class Library (AVL) at www.5trees.com. This class library contains a number of different tree related classes. For example, dynamic arrays. The theory of finite, ordered sets is also explored. Concepts such as associative arrays (Maps or Dictionaries) are implemented within the tree class. In addition to trees, 5Trees has lists, stacks, queues, pools, heaps etc. 5Trees is highly advanced and very professional. It will save you time in your programming efforts and allow you to create highly advanced systems. Kind Regards, Ben McNamara.

2 1

RE: [Haskell] Read Instances for Data.Map and Data.Set
by Simon Marlow 20 Oct '05

20 Oct '05

On 20 October 2005 09:18, Christian Maeder wrote: > Georg Martius wrote: >> Anyway since there was no response to S. Alexander Jacobson post >> [1], I decided to write these instances at least for GHC in the >> style of the other instances in GHC.Read. > > Who feels responsible for including something into Data.Set and > Data.Map (recently I've proposed a change for Set.intersection and > others also made suggestions)? It's not clear who has ownership for these libraries. They were authored by Daan Leijen, and modified for inclusion in the base package by Jean-Philippe Bernardy, neither of whom has been actively maintaining them. I'm happy to commit small obvious improvements, but I'm not familiar enough with the code to judge the quality of non-trivial changes. Any volunteers? Cheers, Simon

1 0