August 2010 - Libraries

ANN: Protocol-buffers 1.7.9
by Chris Kuklewicz 30 Aug '10

30 Aug '10

Hello, This is a bug fix release of the three Protocol Buffers parts: protocol-buffers, protocol-buffers-descriptor, and hprotoc. The new versions are all 1.7.9 and are on hackage. I thank George van den Driessche and Daniel Mischler for the bug reports and patches. One bug has to do with needing to occasionally mangle the name of an Enum value that has been set as the default for some field. The generated code would die with a failed "read" when reflection was used at run time. The second bug had to do with compiling generated code that used the new packed field format. The documentation has been updated to point to the new darcs repository at http://code.haskell.org/protocol-buffers/ There may be another bug that Geroge reported and I am trying to understand. If there is a problem then it will soon be fixed in another update. Cheers, Chris Kuklewicz

1 0

Permissions trouble installing Haskell Platform on Ubuntu Lucid
by Craig Citro 28 Aug '10

28 Aug '10

Hi, I tried to install the Haskell Platform on my Ubuntu machine today, but ran into trouble trying to read the PPA suggested on the Linux install page (http://hackage.haskell.org/platform/linux.html) Trying to do an apt-get update after adding ppa:justinbogner/haskell-platform gives a 403: W: Failed to fetch http://ppa.launchpad.net/justinbogner/haskell-platform/ubuntu/dists/lucid/m… 403 Forbidden I filed a ticket on the haskell-platform trac, but I'm not sure if people just peruse the timeline on there or not. ;) I figured a quick email would get this noticed faster -- if there's a better mailing list to send this to, just let me know. -cc

2 1

Re: Crypto-API is stabilizing (Thomas DuBuisson)
by John Lato 27 Aug '10

27 Aug '10

> > From: Thomas DuBuisson <thomas.dubuisson(a)gmail.com> > > >>class (Binary p, Serialize p) => AsymCipher p where > >> generateKeypair :: RandomGen g => g -> BitLength -> Maybe ((p,p),g) > >> encryptAsym :: p -> B.ByteString -> B.ByteString > >> decryptAsym :: p -> B.ByteString -> B.ByteString > >> asymKeyLength :: p -> BitLength > > > > Regarding AsymCipher: > > Some algorithms do not lend themselves to encryption/decryption or have > > special properties which differentiate their use in enc/dec an > > signing/verifying. > > > > I propose the following two additions for the class: > > signAsym :: p -> B.ByteString -> B.ByteString > > verifyAsym :: p -> B.ByteString -> Bool > > > > This way algorithms can leave parts undefined which do not apply to > > them or hide their different behaviour. > > I am strongly against classes for which we already know instanes will > need a good deal of undefined routines. > I agree. However, you could just make separate type class for these methods. John Lato

1 0

regex-tdfa issue with large regexps
by Simon Michael 24 Aug '10

24 Aug '10

Hi and thanks again Christopher.. I just used regex-tdfa for the first time. I'm looking for a native haskell regex lib that's installable and reliable on all platforms. Perl-style regexps would be ideal. I know regex-tdfa doesn't support these (yet ?) but it did install easily on windows which is promising. I noticed it's quite sensitive to regexp size; it will eat all ram on my 1G mac with regexps larger than 500 chars or so. With pcre-light, I could get up to about 32K before a runtime error. Is there an issue tracker for the regex packages ? Best, -Simon

3 2

regex-base repo, usage ?
by Simon Michael 23 Aug '10

23 Aug '10

Hi Christopher.. thanks for regex-base. I have a couple of quick questions: http://hackage.haskell.org/package/regex-base reports home page as http://sourceforge.net/projects/lazy-regex . Is there a newer, non-sourceforge repo ? If not.. the sourceforge checkout instructions didn't work for me. My guess of modulename failed, and cvs co -c didn't list any. So I downloaded the tarball. This was all to get at Example*hs mentioned in the haddock; I'm looking for actual examples of setting regex options like (?i) ? Best, -Simon

1 0

Folds over Data.Map
by Johan Tibell 23 Aug '10

23 Aug '10

Hi all, After working on optimizing the folds defined in Data.Map, I'm not sure that the current definitions are correct. In particular, `fold` is defined as -- | /O(n)/. Fold the values in the map, such that -- @'fold' f z == 'Prelude.foldr' f z . 'elems'@. -- For example, -- -- > elems map = fold (:) [] map -- -- > let f a len = len + (length a) -- > fold f 0 (fromList [(5,"a"), (3,"bbb")]) == 4 It's not true that fold f z == foldr f z . elems in general. It only holds if `z` is an identity for `f` as `z` is used at every leaf in the tree. Using a none identity element for `z` doesn't really work in practice as a user cannot tell how many times `z` will be used, as it depends on the shape of tree which in turn depends on how balanced it is at any given point. Is there a better way to define folds over maps or should we just change the documentation to say that you most likely want `z` to be an identity? Cheers, Johan

2 2

Another API stability plea
by John Goerzen 23 Aug '10

23 Aug '10

Hi folks, Recently, I received this bug report against testpack: http://github.com/jgoerzen/testpack/issues#issue/1 The program worked fine with QuickCheck 2.1.0.2 but failed to compile against 2.1.0.3, producing the error message listed. The fix is at http://github.com/jgoerzen/testpack/commit/7a8e30d419a52c96e212c6df48799c73… if you're curious. I'm writing because there was an API change in a point release. This is violating our convention and the Platform policy. As a practical matter, it makes life more difficult for me because: * If I were to add an upper bound to a dependency in .cabal, with the intent to prevent compilation errors due to API changes, this would break that. * I can't use CPP macros to support both the old and new versions because Cabal assumes that in a package named a.b.c.d, the .d component isn't relevant to API changes (since that's the policy and convention). * I get bug reports from users that can't install my software at an unexpected time. So, please take this as a polite request and reminder to make a more significant version change in your .cabal when you change the API. Here is a link to the versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy A.B.C should uniquely identify an API. Also I would like to remind everyone that adding or removing instances is an API change and can break code, as with the added instances in time a little while back. I generally try to support as wide a range of library versions as possible with my code, so that it can be readily installed on machines ranging from Debian stable to bleeding-edge Hackage libraries. Having API changes untestable with CPP breaks that. Thanks for your time. I'll exit the "get off my lawn" mode now ;-) -- John

6 11

Proposal: Add a strict version of foldlWithKey to Data.Map
by Johan Tibell 22 Aug '10

22 Aug '10

Hi, The current API doesn't offer any efficient way to do something simple as e.g. summing the values in a map. I suggest we add a foldlWithKey' function: http://hackage.haskell.org/trac/ghc/ticket/4261 Discussion deadline: 2 weeks Cheers, Johan

2 7

Re: xformat feedback
by Simon Michael 20 Aug '10

20 Aug '10

Sean - thanks very much! That helps a lot. haskell-libs was a misspelling of the libraries(a)haskell.org list, which I've taken the liberty of cc'ing once again. It's on gmane.org too. Best, -Simon On Aug 20, 2010, at 3:36 AM, Sean Leather wrote: > Ha! :) Yes, I was "asking for it," wasn't I? And you're absolutely > right. I gave examples in the announcement email when I asked for > feedback, but I didn't include any in the documentation. I will fix > that. > > I found out more at http://github.com/spl/xformat/tree/master/ > tests/ . What I was hoping for was a way to do printf, without the > variable arguments which make reuse troublesome, but still using > standard printf format strings. Does this lib do that ? > > Hmm. Let me see if I can try to answer that question. > > Here's a basic example: > > *Text.XFormat.Show> showf ("Hello " % String % " #" % Num % "!") > "World" 1 > "Hello World #1!" > > As you can see, this does not use the "standard printf format > string." Instead, it uses a type-indexed function 'showf' to produce > a new function 'showf ("Hello " % String % " #" % Num % "!")' that > allows only certain types for arguments. To help see this, here is > that type: > > *Text.XFormat.Show> :t showf ("Hello " % String % " #" % Num % "!") > showf ("Hello " % String % " #" % Num % "!") :: (Num a) => String -> > a -> String > > Thus, we have a type-safe printf. > > One option that I have considered is writing a quasiquoter to allow > you to do standard printf format strings, but I haven't found a > round tuit for that, yet. > > Hope this answers your question. Thanks for bringing this up. > xformat needs some TLC after a long time. I just didn't know how it > would be used and what direction to take it in. > > BTW, what is haskell-libs(a)haskell.org ? I've never seen that before. > > Regards, > Sean

1 0

Bringing the IntMap API up to par with the Map API
by Johan Tibell 20 Aug '10

20 Aug '10

There are a few functions on Maps that could be implemented on IntMaps but aren't: - deleteAt - elemAt - updateAt - findIndex - lookupIndex The above 5 functions can be efficiently implemented on Maps in O(log n) time, as the size of the subtrees are known, but not not on IntMaps. We could still provide O(n) versions for IntMap. What's the use case for indexed lookup in maps? I've never seen it in other languages. - foldlWithKey - foldrWithKey - insertWith' - insertWithKey' - mapKeys - mapKeysMonotonic - mapKeysWith - toDescList I believe these should these should be straightforward to implement. I suggest we add these functions to IntMap so one doesn't it's a "no brainer" to switch from Maps to IntMaps for int keys. Are there any other functions that should be added to both APIs e.g. strict updateWith functions? Cheers, Johan

8 16