October 2005 - Libraries

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

minimal complete definition (Data.Monoid)
by Marc A. Ziegert 18 Oct '05

18 Oct '05

i've just played a bit with monoids, especially with Ross Paterson's nice version of "class (Monoid b)=>Monoid(a->b)" mapped to Arrows, and Implicit Parameters (i tried to simulate dynamic instances). for me, i came to the conclusion, that it is easier and nicer to generalise some functions, to be able to set the used monoid-functions via parameter. (not implicit parameter!) minimizing the overhead, i read this in the libraries: [docu] class Monoid a where The monoid class. A minimal complete definition must supply mempty and mappend, and these should satisfy the monoid laws. [/docu] is that really the only minimal complete definition, that is implemented? how about mconcat? [code] mempty = mconcat [] mappend a b = mconcat [a,b] [/code] the mconcat may be not optimised, if there are only the "minimal complete definition" mempty and mappend; so, it is good, that mconcat is one of the class-functions... but writing only the optimized mconcat is a "minimal complete definition", too. by the way: instead of Ross Paterson's "Data.Monoid"(Date: 2005-09-13 15:52:31 GMT), i would prefer another class: [code] import Prelude hiding (sequence) import qualified Control.Monad import Control.Arrow class Sequence m where sequence :: [m a] -> m [a] instance Monad m => Sequence m where sequence = Control.Monad.sequence instance (Arrow f) => Sequence (f a) where sequence [] = pure (const []) sequence [f] = f >>> pure (:[]) sequence (f:fr) = (f &&& sequence fr) >>> pure (uncurry (:)) --Ross Paterson's Monoid: rp_concat :: (Monoid b) => [a->b] -> a->b rp_concat = mconcat . sequence rp_concat' :: (Arrow f,Monoid b) => [f a b] -> f a b rp_concat' fs = sequence fs >>> pure mconcat [/code]

1 0

RE: Cabal doesn't echo commands with -v on Windows
by Simon Peyton-Jones 18 Oct '05

18 Oct '05

Windows GHC 6.4.1 is definitely seg-faulting when it runs Cabal. (Cabal outputs less trace stuff than it should, but that's a separate and less urgent matter.) We're investigating. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Bayley, | Alistair | Sent: 18 October 2005 10:21 | To: 'Krasimir Angelov' | Cc: Haskell libraries | Subject: RE: Cabal doesn't echo commands with -v on Windows | | > From: Krasimir Angelov [mailto:kr.angelov@gmail.com] | > | > Cabal passes -v flag to the executed external commands only when the | > verbose level is > 4. | | I posted this to ghc-users yesterday, and asked how I could get it to | produce GHC -v output. | | sh-2.04$ runhaskell Setup.hs build -v5 | Preprocessing library haskell-src-exts-0.2... | c:\happy\happy-1.13\bin\happy.exe -agc -oLanguage\Haskell\Hsx\Parser.hs | Language\Haskell\Hsx\Parser.ly | shift/reduce conflicts: 5 | Building haskell-src-exts-0.2... | [segfault: instruction at 0 ref'd memory at 0] | sh-2.04$ | | | Do you think it might still be a flushing problem? | | Alistair. | | ----------------------------------------- | ***************************************************************** | Confidentiality Note: The information contained in this message, and any | attachments, may contain confidential and/or privileged material. It is | intended solely for the person(s) or entity to which it is addressed. Any | review, retransmission, dissemination, or taking of any action in | reliance upon this information by persons or entities other than the | intended recipient(s) is prohibited. If you received this in error, please | contact the sender and delete the material from any computer. | ***************************************************************** | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Cabal doesn't echo commands with -v on Windows
by Bayley, Alistair 18 Oct '05

18 Oct '05

> From: Krasimir Angelov [mailto:kr.angelov@gmail.com] > > Cabal passes -v flag to the executed external commands only when the > verbose level is > 4. I posted this to ghc-users yesterday, and asked how I could get it to produce GHC -v output. sh-2.04$ runhaskell Setup.hs build -v5 Preprocessing library haskell-src-exts-0.2... c:\happy\happy-1.13\bin\happy.exe -agc -oLanguage\Haskell\Hsx\Parser.hs Language\Haskell\Hsx\Parser.ly shift/reduce conflicts: 5 Building haskell-src-exts-0.2... [segfault: instruction at 0 ref'd memory at 0] sh-2.04$ Do you think it might still be a flushing problem? Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

Cabal doesn't echo commands with -v on Windows
by Simon Peyton-Jones 18 Oct '05

18 Oct '05

Cabal with -v should echo the commands it is executing. But on Windows it doesn't. See the error log below. (This is when compiling the FastPackedString Cabal package, in fact.) Simon M thinks it might be a buffering issue. Flush before calling any command? Simon sh-2.04$ runghc Setup.hs -v build Preprocessing library fps-0.1... Building fps-0.1... <Windows pops up the GHC-has-crashed window>

2 1

holy frijoles: constant factors matter.
by John Meacham 13 Oct '05

13 Oct '05

these differences in jhc runtimes were the result of a single line change. < total time = 44.32 secs (2216 ticks @ 20 ms) < total alloc = 9,372,965,276 bytes (excludes profiling overheads) --- > total time = 36.74 secs (1837 ticks @ 20 ms) > total alloc = 6,621,233,076 bytes (excludes profiling overheads) the odd thing is, the change should not have changed the order of the algorithm at all. the change was (effectivly) Map.fromAscList . map f . Map.toAscList being changed to Map.map f both are O(n). but those constant factors matter. a lot. in any case, the reason I mention it is because if there were routines for converting between Set and Map that preserved the binary tree structure, I think their use could dramatically speed up many routines. In jhc (and other programs), I convert between them all the time and I'd hate to have to fall back on type Set a = Map a (). Map already has a keysSet, but it does the same inefficient thing building an intermediate list. all that is needed is a setToMap :: (a -> b) -> Set a -> Map a b the keysSet could be made more efficient in the next point release, but I guess adding setToMap would have to wait til the next major one. John -- John Meacham - ⑆repetae.net⑆john⑈

3 3