- Libraries - Haskell.org

darcs patch: update for containers-0.4
by shelarcy 06 Sep '10

06 Sep '10

DarcsURL: http://darcs.haskell.org/packages/parallel MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_" --=_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 1 patch for repository http://darcs.haskell.org/packages/parallel: Mon Sep 6 18:21:47 =93=8C=8B=9E (=95W=8F=80=8E=9E) 2010 shelarcy <shelarc= y(a)gmail.com> * update for containers-0.4 --=_ Content-Type: text/x-darcs-patch; name="update-for-containers_0_4.dpatch" Content-Transfer-Encoding: quoted-printable Content-Description: A darcs patch for your repository! New patches: [update for containers-0.4 shelarcy <shelarcy(a)gmail.com>**20100906092147 Ignore-this: 54be1682179f96eba4313c62e71fc3b6 ] hunk ./parallel.cabal 25 extensions: CPP BangPatterns build-depends: base >=3D 4 && < 5, deepseq >=3D 1.1 && < 1.2, - containers >=3D 0.2 && < 0.4, + containers >=3D 0.2 && < 0.5, array >=3D 0.2 && < 0.4 ghc-options: -Wall = Context: [moved from the GHC testsuite Simon Marlow <marlowsd(a)gmail.com>**20100720090606 Ignore-this: 4c4f0658c08086b5ed7f47c02fe88932 ] = [TAG 3.1.0.0 Simon Marlow <marlowsd(a)gmail.com>**20100720103736 Ignore-this: 8bc739e7ed8cbb14fb1b4bdccd28c034 ] = Patch bundle hash: 5c9329cf6e5b43da65f3994ed81c501eeb2388ec --=_-- .

1 0

darcs patch: update for containers-0.4
by shelarcy 06 Sep '10

06 Sep '10

DarcsURL: http://darcs.haskell.org/packages/deepseq MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_" --=_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 1 patch for repository http://darcs.haskell.org/packages/deepseq: Mon Sep 6 18:16:49 =93=8C=8B=9E (=95W=8F=80=8E=9E) 2010 shelarcy <shelarc= y(a)gmail.com> * update for containers-0.4 --=_ Content-Type: text/x-darcs-patch; name="update-for-containers_0_4.dpatch" Content-Transfer-Encoding: quoted-printable Content-Description: A darcs patch for your repository! New patches: [update for containers-0.4 shelarcy <shelarcy(a)gmail.com>**20100906091649 Ignore-this: 3c636c18ca1a00910ba4d92860da78b9 ] hunk ./deepseq.cabal 21 library { exposed-modules: Control.DeepSeq build-depends: base >=3D 3 && < 5, = - containers >=3D 0.2 && < 0.4, + containers >=3D 0.2 && < 0.5, array >=3D 0.2 && < 0.4 ghc-options: -Wall } Context: [bump cabal version to 1.6 Simon Marlow <marlowsd(a)gmail.com>**20091120160204 Ignore-this: 55db39b0d7d870248151fcc44d37b007 ] = [bump to 1.1.0.0; add source-repository Simon Marlow <marlowsd(a)gmail.com>**20091120160108 Ignore-this: c15ca7c51d1b8f7ec5ac94ea81466cb1 ] = [Revert naming scheme: DeepSeq->NFData, deepseq->rnf Simon Marlow <marlowsd(a)gmail.com>**20091120160058 Ignore-this: 89225ddb9621dc96e6b8705ac76e82d5 = Also add = deepseq :: a -> b -> b ] = [TAG 1.0.0.0 Simon Marlow <marlowsd(a)gmail.com>**20091117105211 Ignore-this: c48b08cec1bc7e5de55bf3c01b07e01b ] = Patch bundle hash: 989559e0521b2c2d7a9e3f27abfbf7060aaa0bd8 --=_-- .

1 0

unix-compat _impure_ptr link error on windows
by Simon Michael 06 Sep '10

06 Sep '10

unix-compat (all versions) is failing to install for me on windows XP with current haskell platform. It succeeds in a wine shell with current HP. I've attached the log of "cabal install -v3 unix-compat". Best regards, -Simon

2 2

Hackage compilation problem
by Dominique Devriese 06 Sep '10

06 Sep '10

Hi all, I am working on a new package to be released on Hackage (grammar-combinators, release not yet announced). It compiles fine on my system (debian testing, special purpose test user with a pristine ~/.cabal), but the Hackage build log shows the below error message (full version on http://hackage.haskell.org/packages/archive/grammar-combinators/0.1/logs/fa…) It seems this error is caused by a transitive dependency (the random package) requiring two versions of the time package (?), which does not show in that package's .cabal file. I cannot reproduce the problem locally and have no idea what might be causing them. I would much appreciate it if anyone with some more cabal/hackage experience could take a look and comment on the issue. Thanks in advance for any help or comment, Dominique Devriese (...) Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package polyparse-1.4 requires haskell98-1.0.1.1 package uu-parsinglib-2.5.5 requires haskell98-1.0.1.1 package haskell98-1.0.1.1 requires random-1.0.0.2 package haskell98-1.0.1.1 requires random-1.0.0.2 package random-1.0.0.2 requires time-1.1.4 package random-1.0.0.2 requires time-1.2.0.3 (...) /usr/local/bin/ghc --make -package-name grammar-combinators-0.1 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id MaybeT-0.1.2-604a5b30a99ce43ac16f2d5b237f30f7 -package-id base-4.2.0.2-10bdacb430274706a59728e237e2bfb3 -package-id containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 -package-id enumerable-0.0.3-31d1bc40fd7c52b3d83d685e52627d98 -package-id fgl-5.4.2.3-347eeff6011a7f9285c305b00fea7a97 -package-id graphviz-2999.10.0.1-50e6cb683e6a2c39de754bd71e19785e -package-id mtl-1.1.0.2-336254fecf8a77054f76cb33671a5177 -package-id multirec-0.4.1-e036b72652c0c1f66e2511984d48035d -package-id parsec-3.1.0-53d2f726d0bc8967e0f6d7424588dca7 -package-id template-haskell-2.4.0.1-bf08798b1934e4d6a3f903f58e0d5159 -package-id uu-parsinglib-2.5.5-40a637b80a29d05a831a175c3f9a060e -O -Wall Text.GrammarCombinators.Base.Domain (...) <command line>: cannot satisfy -package-id uu-parsinglib-2.5.5-40a637b80a29d05a831a175c3f9a060e: uu-parsinglib-2.5.5-40a637b80a29d05a831a175c3f9a060e is unusable due to missing or recursive dependencies: haskell98-1.0.1.1-ca51ba62fed9074ccb8001cd642eb101 (use -v for more information) (...)

3 3

Crypto-API Final Release Candidate
by Thomas DuBuisson 05 Sep '10

05 Sep '10

To all who have provided feedback on crypto-api: (all BCCed - if you aren't on l(a)h.o ML you won't see the follow-up discussion). I intend to release crypto-api on Hackage Tuesday (Sept07). The proposed final version is on the darcs repo now [1]. I'm very appreciative for all the discussion and design ideas, you can see that many of the ideas have been used. This is the last opportunity for discussion before I upload (targeting 7 Sept). Hopefully I've given enough discussion time without being overly verbose (figured erring on the side of verbosity is best). Recent Changes: * Moved modules to Crypto.* from Data.Crypto.* (ML and IRC comments) * New 'getIVIO' function to get an IV using "getEntropy" then wrapping with the IV constructor. * Regarding the new Crypto.Random Module: * renamed 'generateKeypair' to 'buidKeyPair' for name consistency. * genBytesAI --> genBytesWithEntropy (based on a blog comment) * RandomGenerator --> CryptoRandomGen (based on Duncan's comment on reddit) * SplitableGenerator --> SplittableGen and now "split" can't fail (IRC comment) * newGenIO can't fail (for non-broken generators - broken generators might infinite loop) Likely future changes (please send comments!): * Fix Crypto.Random once a Windows user sends a patch. I never tested it and don't believe I got it right by chance. No (or 'few') Windows users seem to be involved in l(a)h.o discussion / steering. * Once a proposal to rework 'random' and move the CryptoRandomGen class into the 'random' package is out+accepted, I'll remove the related code from Crypto.Random. * a signature class (see ML, supporting non-encrypting algs like DSA): class (Binary k, Serialize k) => Signing k where sign :: k -> L.ByteString -> B.ByteString verify :: k -> L.ByteString -> B.ByteString -> Bool buildSigningKey :: (CryptoRandomGen g) => g -> Either GenError ((k,k), g) Less likely changes: * Expand the BlockCipher class to include mode functions like cbc, ctr, etc (for a performance win). Once I see how big the win is and am convinced we can't optimize to get it without bloating the class then I might add them to the class and provide default instances pointing at Crypto.Modes implementations. Not wanting to be a tyrant, here are some other thoughts people have brought up for discussion (which you can assume I don't like for this library, but some made me stop to think): * Using a data type instead of class for AsymCipher (see ML) * Using MPTC and allowing CryptoRandomGen instances to control the generated type (see reddit). This might be proposed for the reworked RandomGen class, but not likely for CryptoRandomGen. * Have a data type allowing named algorithms (data HashName = MD5 | SHA1 | SHA256 | ... | OtherHash String) include a new class routine (hashName :: dsgt -> HashName) (see ML 'cryptohash' thread) * Unified class for stream ciphers and other streaming algorithms (ex: compression) (ML) * use a semantics for BlockCipher and Hash that doesn't require blockSized inputs (see my original crypto overhaul e-mail which detailed 3 possible semantics) * a 'strength' field for each hash and cipher (also mine, but decide it would be more likely for absurd misuse than any type of correct use) * a "Key" class to which all Cipher class keys would belong. Rejected for "over typeclass-ification", no real benefit. Other TODO: * Crypto.Padding still needed * Expand test suite to other hashes, more test of current hashes, more algorithm specific tests (perhaps most notably, block ciphers). Contributers feel free to make more Test.* modules, perhaps one for each algorithm? * Expand test suite to include more properties (an encrypt . decrypt = id property of some sort? A stream cipher property checking correct operation for streams feed 1 byte at a time vs multi-byte? etc). * Improve benchmarks, use CryptoRandomGen class in benchmark. Yes, some of these changes means the version number will be inflating somewhat rapidly, but it will mostly be added functionality so most packages won't have to change anything be remain compatible (advise you selectively import: "import Crypto.Foo (...)"). Cheers, Thomas [1] code.haskell.org/~tommd/crypto

1 0

Crypto-API is stabilizing
by Thomas DuBuisson 05 Sep '10

05 Sep '10

All, Crypto-API - a unified interface to which I hope hash and cipher algorithms will adhere - has recently gotten a reasonable amount of polish work. I continue to welcome all comments! A blog on its current interface is online [1] as are darcs repositories of the crypto-api package [2]. Recent changes includes added block cipher modes, platform-independent RNG, tests, a simplistic benchmark framework, and minor tweaks of the classes. I've made experimental hash, block cipher and stream cipher instances. Almost no optimizations have been made as of yet! Thanks to everyone for their past comments! I have made numerous changes based on input received. If you feel I didn't respond properly to your suggestion then please ping me again - this is purely a spare time effort and things do fall through the cracks. Cheers, Thomas [1] http://tommd.wordpress.com/2010/08/23/a-haskell-api-for-cryptographic-algor… [2] http://community.haskell.org/~tommd/crypto/ (If you're wondering why you're BCCed its probably because you worked on a crypto-related Haskell package)

2 5

Re: [Haskell-cafe] Re: Crypto-API is stabilizing
by Sebastian Fischer 04 Sep '10

04 Sep '10

On Aug 27, 2010, at 11:12 AM, Heinrich Apfelmus wrote: > Is it actually necessary to use a type class here? The situation is > very similar to > > Luke Palmer. Haskell Antipattern: Existential Typeclass. > http://lukepalmer.wordpress.com/2010/01/24/ > > I suggest to use good old data types > > data Key = Key { > encrypt :: B.ByteString -> B.ByteString, > decrypt :: B.ByteString -> B.ByteString, > keyLength :: BitLength, > serialize :: B.ByteString} > > rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g) In general, I like this approach, but what are encrypt privateKey or decrypt publicKey supposed to do? A type-class solution also does not *prevent* programmers to perform such non-sensical calls, but the data-type solution *forces* programmers to provide non-sensical encrypt and decrypt functions when creating the public and private keys. >>>> 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 Why not use generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p)) where MonadRandom is from [1]. Sebastian [1]: http://hackage.haskell.org/package/MonadRandom -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

4 10

Proposal: Performance improvements for Data.Set
by Johan Tibell 03 Sep '10

03 Sep '10

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4280 Proposal: Performance improvements for Data.Set Following on from ticket #4277 here is a similar patch for Data.Set. This proposal provides a patch that improves performance for many parts of the API. Three standard techniques are applied to the code: * Worker/Wrapper transformations of recursive functions with constant arguments (aka. the static argument transformation). * Explicit inlining of wrapper functions. * Explicit strictness of keys to functions. Three complementary, but orthogonal patches are provided. * Add a testsuite, with coverage data (currently 51% of top level functions, and all core functions). * Add a micro-benchmark suite based on Criterion, for empirical evidence of improvements to each function. * The optimization patch itself. All 3 patches should be applied, under this proposal. The benchmark results are relatively clear: 32% faster on OS X 10.5.8 on 2 GHz Core 2 Duo The consideration period is 3 weeks (before ICFP). Work carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell and Don Stewart.

3 3

Installation question: cpphs, unix, and HEAD
by Kathleen Fisher 03 Sep '10

03 Sep '10

I am trying to install the cpphs package with the current HEAD version of Haskell. When I ask cabal to do the installation, I get the following error: > Babylon:/Users/kfisher/sw/ghc-head-libraries/cpphs-1.11> ~/.cabal/bin/cabal install cpphs -w ~/ghc-head/bin/ghc --with-haddock=/Users/kfisher/ghc-head/bin/haddock --package-db=/Users/kfisher/ghc-head/lib/ghc-6.13.20100831/package.conf.d > Resolving dependencies... > cabal: cannot configure unix-2.4.0.1. It requires base ==4.2.* > For the dependency on base ==4.2.* there are these packages: base-4.2.0.0, > base-4.2.0.1 and base-4.2.0.2. However none of them are available. > base-4.2.0.0 was excluded because base-4.3.0.0 was selected instead > base-4.2.0.0 was excluded because of the top level dependency base -any > base-4.2.0.1 was excluded because base-4.3.0.0 was selected instead > base-4.2.0.1 was excluded because of the top level dependency base -any > base-4.2.0.2 was excluded because base-4.3.0.0 was selected instead > base-4.2.0.2 was excluded because of the top level dependency base -any > Babylon:/Users/kfisher/sw/ghc-head-libraries/cpphs-1.11> This seems odd for multiple reasons: 1. I already have unix-2.4.0.1 installed (it was a boot library). So why is cabal trying to install it again? 2. Given that I already have unix-2.4.0.1 installed and my base is 4.3.0.0, why does unix-2.4.0.1 report that it needs base==4.2.*? 3. Given that the cabal file for cpphs says it needs base < 6 and haskell98 and my package database satisfies both of those constraints, why is cabal trying to install anything else? I include the listing of my installed packages below. What is going on is probably obvious to someone who knows more about the library installation process. Any ideas? Kathleen > Babylon:/Users/kfisher/sw/ghc-head-libraries/cpphs-1.11>~/ghc-head/bin/ghc-pkg list > /Users/kfisher/ghc-head/lib/ghc-6.13.20100831/package.conf.d: > Cabal-1.9.2 > HUnit-1.2.2.1 > array-0.3.0.0 > base-4.3.0.0 > bin-package-db-0.0.0.0 > (binary-0.5.0.2) > bytestring-0.9.1.7 > containers-0.3.0.0 > directory-1.0.1.2 > dph-base-0.4.0 > (dph-par-0.4.0) > (dph-prim-interface-0.4.0) > (dph-prim-par-0.4.0) > (dph-prim-seq-0.4.0) > (dph-seq-0.4.0) > extensible-exceptions-0.1.1.2 > ffi-1.0 > filepath-1.2.0.0 > (ghc-6.13.20100831) > ghc-prim-0.2.0.0 > (haskell2010-1.0.0.0) > haskell98-1.0.1.1 > hpc-0.5.0.5 > integer-gmp-0.2.0.0 > mtl-1.1.0.2 > old-locale-1.0.0.2 > old-time-1.0.0.5 > pretty-1.0.1.1 > process-1.0.1.3 > random-1.0.0.2 > regex-base-0.93.2 > regex-posix-0.94.4 > rts-1.0 > syb-0.2.1 > template-haskell-2.4.0.0 > time-1.2.0.3 > unix-2.4.0.1

2 1

installing cpphs, unix, in HEAD
by Kathleen Fisher 03 Sep '10

03 Sep '10

BTW, when I did the installation process by hand, unpacking cpphs, compiling Setup, then doing configure, install, and build, everything worked fine. The same basic thing happened when I tried to install parsec-3.1.0. Cabal failed to install, reporting a problem with base dependencies. But installation by hand succeeded. Kathleen

1 0