- Libraries - Haskell.org

Floating point and RealFrac
by Daniel Fischer 15 May '11

15 May '11

Looking at the old bug list again, there are a couple of tickets I might be able to do something about. Since library submissions are somewhat painful, though, and I'm not bitten by the issues, I'd like to know if there's general interest to do something about them. 1) http://hackage.haskell.org/trac/ghc/ticket/2269 Feature request: add primops word2Double#, double2Word#, word2Float#, float2Word# Well, I don't know how to create primops, but I could twiddle a few bits in C to produce a hopefully faster conversion than we have now. 2) http://hackage.haskell.org/trac/ghc/ticket/2281 a fast 'fraction' function for Double Although fraction x = snd (properFraction x :: (Integer, TYPE_OF_x)) , when compiled with optimisations, is not as slow as it used to be, it's still not very fast. A binding to modf/modff or some bit-twiddling in C should be faster. If there's demand for this, should a `fraction' function be added to RealFrac, should standalone functions fractionFloat and fractionDouble be added to GHC.Float with rewrite rules snd (properFraction x) -> fractionTYPE x ? 3) http://hackage.haskell.org/trac/ghc/ticket/3676 realToFrac misbehaves on NaNs, -0.0 and infinities (for Float -> Double) when the rewrite rule doesn't fire. As long as the realToFrac conversion [without rewrite rules] goes through Rational, this is basically unfixable. So a real fix would necessitate a language change. Some ideas have been shortly discussed in http://www.haskell.org/pipermail/haskell-prime/2010-February/003139.html and replies. The most reasonable candidates IMO are - a dedicated floating point conversion, with * a type alias FloatMax for the largest (real + infinities + NaNs) Floating point type, currently Double * methods toFloatMax and fromFloatMax added to RealFloat * the conversion function floatConvert :: (RealFloat a, RealFloat b) => a -> b - adding a type specifically for conversions between different number types that caters for special values, something along the lines of data NumRep = NegativeZero | Infinity Bool -- to indicate sign | NaN -- possibly with a parameter to encode different NaNs | BinExp Integer Int -- m*2^e | Rat Rational | Entire Integer -- ? and let realToFrac convert via this type. The BinExp constructor would allow a more efficient conversion between base-2 floating point types than fromRational . toRational can be. If such a type would also be used for the Read instances, instead of Rational, adding a constructor for base-10 representations would be useful (cf. http://hackage.haskell.org/trac/ghc/ticket/3897 ) [and Rational could be freed from the invalid values 0:%0, ±1:%0]. Both candidates would be major undertakings and have their downsides. I can live with the current state of affairs, what bugs me most about it is the open ticket.

1 0

Proposal: Tidy up and export PSQ from base
by Edward Z. Yang 15 May '11

15 May '11

The new IO event manager implements a priority search queue internally. This is a kind of handy data structure; in particular, some algorithmic improvements in Hoopl would require a decent priority queue implementation. I propose that we move GHC.Event.PSQ to Data.PSQ, cleaning up the dependency on GHC.Event.Unique, and export it unconditionally (right now it is only available on non-Windows.) Discussion period: 1 week. Cheers, Edward

8 20

test-suite type: detailed-1.0
by Guy 14 May '11

14 May '11

The user guide for Cabal 1.10.1.0 specifies "detailed-1.0" as an acceptable test-suite type, but cabal reports Warning: 'detailed-1.0' is not a supported test suite version. The known test suite types are: exitcode-stdio-1.0

2 1

cabal test = permission denied?
by Guy 13 May '11

13 May '11

I can successfully run cabal test, and my test suite passes. Cabal's output it: Running 1 test suites... Test suite tests: RUNNING... Test suite tests: PASS Test suite logged to: dist\test\foo-0.1-tests.log cabal: permission denied foo-0.1-tests.log is present and correct. There is also an empty file cabal-test-4513.log. I am on Windows 7 x64, cabal 1.10.1.0. Running as Admin makes no difference.

2 1

cabal-latest
by Guy 12 May '11

12 May '11

http://www.haskell.org/cabal/release/cabal-latest/ points to version 1.8.0.4. Is this correct?

1 0

ANN: version 2.0.0 of protocol-buffers, protocol-buffers-descriptor, hprotoc
by haskell＠list.mightyreason.com 12 May '11

12 May '11

A new major version of the Haskell implementation of Google's protocol buffers is done. The new code is in the usual three packages at http://hackage.haskell.org/package/protocol-buffers http://hackage.haskell.org/package/protocol-buffers-descriptor http://hackage.haskell.org/package/hprotoc The darcs repository is still at http://code.haskell.org/protocol-buffers/ This is the first release where performance was tested and improved: specifically parsing messages from the wire protocol. The new library now defaults to using strict fields for generated messages. This vastly improves the memory usage when getting messages from the binary format. The old lazy fields can still be generated by hprotoc with a new command line option. On "OS X" with 64-bit ghc the C++ loading is 0.5 seconds and Haskell is 1.6 seconds (128 MB memory usage). This is down from 8.3 seconds (1597 MB memory usage). A related change in version 2.0.0 is that 'mergeEmpty' no longer exists. With strict messages and required fields this would have been a dangerous value to keep. If you used this, then please use 'defaultValue' instead. The Haskell code has been compiled against Google's version 2.4.0a proto files. But the Haskell code is only compatible up to Google's version 2.3.0, and in particular the new default message syntax is not yet supported in the 'hprotoc' parser. -- Chris

2 1

Messed up with Cabal on Mac
by Harad 08 May '11

08 May '11

Hello everybody, I was trying to install `snap` but I was getting this error: <command line>: cannot satisfy -package-id haskell98-1.1.0.1-6c0d823d8a0fe4966441285c9ec0b534: I still don't fully understand why was this happening but, reading here and there, I ended up running `ghc-pkg unregister --user haskell98`. Some of you may be facepalming at this point, because then if I ran `ghc-pkg check` I got a really, really long list of broken packages. So I decided to throw it all away, removed the whole Haskell Platform from my computer as told here <http://bit.ly/jHBzEk> (I know, pretty Mac-ish solution), installed it back... but I continue getting the same error when installing `snap`, and `ghc-pkg check` still throws me this infinite list: http://pastebin.com/duTC4rqX . I searched but I didn't find any posible solution. Do you have any idea of how can I clean up all that mess? Thanks in advance! (If my English is awful is because I'm Spanish and Spanish people are the worse language learners in the world, so I'm sorry for that.)

2 2

ANN: stm-chans 1.2.0
by wren ng thornton 07 May '11

07 May '11

-------------------------------------------- -- stm-chans 1.2.0 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.TChan but with additional features. -------------------------------------------- -- Changes (since 1.0.0) -------------------------------------------- * (Version 1.1.0) Added tryWriteTBChan. * (Version 1.1.0) Added tryWriteTBMChan. * Some major performance improvements in TBChan and TBMChan, thanks to Thomas DuBuisson. In particular, these improvements reduce contention between readers and writers, improving throughput by up to 2--3 times when producers and consumers are running in separate OS threads. The cost for non-parallel programs is trivial (<1% worst-case running time, per Criterion). * Added estimateFreeSlotsTBChan, freeSlotsTBChan, estimateFreeSlotsTBMChan, and freeSlotsTBMChan. These functions return either the exact number or a lower-bound on the number of free slots available before the channels will block/retry. * Some other minor optimizations and code improvements. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers these types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. This is like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. This combines the capabilities of TBChan and TMChan. In addition, the stm-chans package offers a (partial) compatibility layer for some recent API improvements to the stm package (see ticket #5104 [1]). These new functions include: * tryReadTChan :: TChan a -> STM (Maybe a) A version of readTChan which does not retry. Instead it returns Nothing if no value is available. * peekTChan :: TChan a -> STM a Get the next value from the TChan without removing it, retrying if the channel is empty. * tryPeekTChan :: TChan a -> STM (Maybe a) A version of peekTChan which does not retry. Instead it returns Nothing if no value is available. [1] http://hackage.haskell.org/trac/ghc/ticket/5104 -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

1 0

Re: Proposal: Tidy up and export PSQ from base
by wren ng thornton 06 May '11

06 May '11

On 5/1/11 7:58 PM, Edward Z. Yang wrote: > OK, to summarize the current discussion: > - It would be nice to have a general-purpose priority queue in containers. > I'm not interested in this goal per se, but I do view it as the cleanest way > to get what I want. With regards to this point, is there any reason why the following does not suffice (albeit not in base)? http://code.google.com/p/priority-queues/ They're not priority *search* queues, but I'm not sure how much to read into your leaving out that word... -- Live well, ~wren

4 4

Proposal: add Int indexing functions to Data.Set
by Luis Casillas 02 May '11

02 May '11

Hi everybody. First time proposer here, so bear with me. While I was looking at the Haddock documentation for Data.Map, I noticed that it has a section with "Indexed" operations that address the map with Int indexes: http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.h… The relevant functions' signatures are these: lookupIndex :: Ord k => k -> Map k a -> Maybe Int findIndex :: Ord k => k -> Map k a -> Int elemAt :: Int -> Map k a -> (k, a) updateAt :: (k -> a -> Maybe a) -> Int -> Map k a -> Map k a deleteAt :: Int -> Map k a -> Map k a Now, the Data.Set module, which is a near carbon-copy of Data.Map, does not have any counterparts to these functions. My proposal is to add such counterparts to Data.Set (I'm writing some code that could benefit from them). The proposed functions' signatures: lookupIndex :: Ord a => a -> Set a -> Maybe Int findIndex :: Ord a => a -> Set a -> Int elemAt :: Int -> Set a -> a deleteAt :: Int -> Set a -> Set a I attach a patch to add these to Data.Set. Note that the implementation of the Set functions is basically a copy-paste-and-edit of their counterparts in Data.Map. That seems to be the convention in those two modules; Data.Set is really just like Data.Map but with no "value" field in the datatype's constructor. Since I am a noob, I mistakenly created a Trac ticket before figuring out the correct library proposal process (#5162, which promptly got closed; my apologies). There have been a couple of responses there, which I will summarize here: 1. Concern over the efficiency of the code in my patch (Trac comment by tibbe). At my present skill level with Haskell, frankly, the most intelligent response I can give to this is that I'm copying the Data.Map implementation from darcs to the best of my ability, and that the most I hope is to make the Set versions no worse than the Map versions. 2. Concern that Int-based indexing breaks the set abstraction by exposing a specific ordering (Trac comment by Malcolm Wallace). My assumption when I decided to submit this patch was that if it's OK for Data.Map to have these operations, then it should also be ok for Data.Set to have them. But Malcolm's concern makes me wonder if some people will find the original Data.Map functions objectionable and dislike the idea of "spreading the infection" to Data.Set. Discussion period: 2 weeks.

10 20