- Libraries - Haskell.org

Re: Nothing can link with gtk on Snow Leopard
by John Lato 11 Nov '10

11 Nov '10

> > Message: 5 > Date: Thu, 11 Nov 2010 12:43:40 +1030 > From: Mark Spezzano <mark.spezzano(a)chariot.net.au> > Subject: Nothing can link with gtk on Snow Leopard > To: libraries(a)haskell.org > Message-ID: <E68B9F5E-2EBF-43E5-B72E-BEA044DFF948(a)chariot.net.au> > Content-Type: text/plain; charset=us-ascii > > Hi, > > I'm running Mac OS X Snow Leopard. I've done a "sudo cabal install gtk > --global" on my system, and it warns me that "file was built for unsupported > file format which is not the architecture being linked (i386)". What does > this refer to? > > Subsequently, nothing else _links_ properly with gtk. > > For example, hp2any-manager (or other tools) all fail during linking with > gtk. > > Am I doing something wrong? > At one point I had this problem due to hsc2hs attempting to build 64-bit. What happens if you try running: cabal install gtk --global --hsc2hs-flags=--cflags=-m32 (I think that's the incantation I used). Apologies for not remembering more details, but I'm strongly suspicious that the issue lies in hsc2hs. John

1 0

Re: Nothing can link with gtk on Snow Leopard
by Axel Simon 11 Nov '10

11 Nov '10

Mark, On 11.11.2010, at 08:27, Mark Spezzano wrote: > Hi Axel, > > The error "file was build for unsupported file format which is not > the architecture being linked (i386)" comes up soon after starting > to install gtk via cabal. > > gtk is "installed" (at least, it comes up in ghc-pkg as installed) > but then when linking threadscope or another gtk-reliant tool it > fails during the final linking phase. > > It spits out a long list of functions that it can't link to. > Before we move this discussion to gtk2hs-devel(a)lists.sourceforge.net , I'd like to confirm that this is our problem. - what version of Gtk+ do you have? (run "pkg-config --modversion gtk +-2.0") - are the functions that cannot be linked to part of Gtk+ or of the Haskell gtk package (i.e. send us some of the error messages containing the function names) - what ghc are you using ("ghc --version") I suspect that the Gtk+ libraries and ghc do not agree on the architecture. Cheers, Axel > Mark > > > On 11/11/2010, at 5:40 PM, Axel Simon wrote: > >> Hi Mark, >> >> On 11.11.2010, at 03:13, Mark Spezzano wrote: >> >>> Hi, >>> >>> I'm running Mac OS X Snow Leopard. I've done a "sudo cabal install >>> gtk --global" on my system, and it warns me that "file was built >>> for unsupported file format which is not the architecture being >>> linked (i386)". What does this refer to? >>> >>> Subsequently, nothing else _links_ properly with gtk. >>> >> >> This might be a gtk problem. Does this happen very early or only >> during linking? Could you check what >> >> cabal build -v >> >> throws up? (Also: Did you install gtk2hs-buildtools first?) >> >> Cheers, >> Axel >> >>> For example, hp2any-manager (or other tools) all fail during >>> linking with gtk. >>> >>> Am I doing something wrong? >>> >>> Thanks, >>> >>> >>> Mark _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >> >> >

3 3

Nothing can link with gtk on Snow Leopard
by Mark Spezzano 11 Nov '10

11 Nov '10

Hi, I'm running Mac OS X Snow Leopard. I've done a "sudo cabal install gtk --global" on my system, and it warns me that "file was built for unsupported file format which is not the architecture being linked (i386)". What does this refer to? Subsequently, nothing else _links_ properly with gtk. For example, hp2any-manager (or other tools) all fail during linking with gtk. Am I doing something wrong? Thanks, Mark

2 1

Splittable random numbers
by Simon Peyton-Jones 10 Nov '10

10 Nov '10

Hi Cafe A while back there was a thread<http://www.mail-archive.com/haskell-cafe@haskell.org/msg79633.html> about a good implementation of a (pseudo) random number generator with a good "split" operation. There's lots of material on generators that generate a linear sequence of random numbers, but much less on how to generate a tree of random numbers, which is what Haskell's System.Random API requires. I happened to meet Burton Smith recently, who wrote some early papers about this stuff (eg "Pseudo random trees in Monte-Carlo<http://portal.acm.org/citation.cfm?id=1746034>"), so I asked him. His reply is below, along with some follow-up comments from his colleagues Tolga Acar and Gideon Yuval. The generator uses crypto functions, so it's probably more computationally expensive than common linear-sequence generators, but in exchange you get robust splitting. Does anyone feel like taking the idea and turning it into a Haskell library? (Or even a Haskell Wiki page?) I'm taking the liberty of cross-posting to the libraries list. Simon From: Burton Smith Sent: Tuesday, November 02, 2010 3:58 PM To: Simon Peyton-Jones Cc: Gideon Yuval (Gideon Yuval); Tolga Acar Subject: Random number generation With some help from Gideon and Tolga, I think the solution to the "arbitrary tree of random numbers problem" is as follows: The generator G is a pair comprising a crypto key G.k and an integer counter (the "message") G.c. The (next G) operation returns a pair: 1. a random integer r obtained by encrypting G.c with G.k, and 2. a new generator G' such that G'.k = G.k and G'.c = G.c + 1. The (split G) operation is similar, returning the same G', except that instead of returning a random integer r it returns a third generator G'' such that G''.k = r and G''.c = 0. A suitable block cipher system might be 128-bit AES (Rijndael). Unencumbered implementations exist in a variety of languages, and performance is pretty good and will improve dramatically as hardware support improves. I'd pick both crypto key size and the size of the result r to be 128 bits, and employ a 64 bit counter c. Other crypto options exist. From: Simon Peyton-Jones Sent: Wednesday, November 03, 2010 3:11 AM To: Burton Smith; Gideon Yuval (Gideon Yuval) Cc: Tolga Acar; Simon Peyton-Jones Subject: RE: Random number generation Burton, Gideon, Tolga Aha, that's interesting. I'd never seen a random number generator based on crypto, but it seems like an attractive idea. As I understand it, successive calls to 'next' will give you encrypt(0), encrypt(1), encrypt(2), encrypt(3),.... Is this standard? Does it have provably good randomness properties, (cycle length, what else?) like other RNGs? Or does it simply seem very plausible? Can I send it round to the Haskell mailing list, in the hope that someone will turn the idea into a library? (Ideally I'd like to make claims about the randomness properties in doing so, hence my qns above.) From: Gideon Yuval (Gideon Yuval) Sent: Wednesday, November 03, 2010 7:15 AM To: Simon Peyton-Jones; Burton Smith Cc: Tolga Acar Subject: RE: Random number generation As long as the key, and the non-counting part of the counter, are kept" secret", anyone who can distinguish these pseudorandoms from real random, in less than 2^128 steps, has a nice paper for crypto-2011 (this is known as "provable security") concerning a weakness in AES128. One exception: real randoms have a birthday paradox; the pseudorandoms suggested do not. If you care, you can: (1) Limit the counter to 2^32 steps (paradox has 2^-64 probability) or even 2^16 (2^-96), then rekey; or (2) XOR 2 such encrypted counters, with different keys; or (3) XOR 3 successive values for the same counter (just possibly cheaper; top-of-head idea). More hard-core: swap the position of key & message: encrypting a constant "secret" with 1,2,3,4.... Gives pseudorandoms with no birthday paradox. From: Tolga Acar Sent: 03 November 2010 15:50 To: Gideon Yuval (Gideon Yuval); Simon Peyton-Jones; Burton Smith Subject: RE: Random number generation Simon, The general idea is not really that new in the crypto area with constraints Gideon describes, of course. That is typically called a PRNG - Pseudo Random Number Generator, or in another parlance, Deterministic Random Bit Generators (DRBG). The DRBG constructions based on hash functions and block ciphers are even standardized in NIST publication SP800-90 (even though I may not recommend every one of them). As for the construction below, that is based on the AES block cipher, that essentially takes advantage of the PRP (Pseudo Random Permutation) property of the AES block cipher, as each block cipher ought to be. So, as Gideon outlines below, if you fix the key, the PRP gives you a random-looking (or, in other terms, indistinguishable from random) output that no one without the secret key and the "state" can generate or easily predict. Assuming an ideal cipher (and AES is a close approximation to it), the probability is believed to be the birthday paradox - no counterexample or a proof exists without assumptions; so we stick to the birthday bound. There ought to be papers on this somewhere. If not, that condensed information is spread across many papers and is part of the crypto folklore, I'd say. From: Burton Smith Sent: 03 November 2010 19:03 To: Simon Peyton-Jones Cc: Gideon Yuval (Gideon Yuval); Tolga Acar Subject: RE: Random number generation Just two points of further clarification: 1. All PRNGs used in the technical computing space fail the birthday paradox criterion (i.e. have full period), so we really need not worry about this. Also, there are other mitigating factors, e.g. suppose we are using the PRNG to generate pseudorandom residues mod n << 2^128; the paradox is happily present there. 2. The big innovation in this scheme is that the rekeying operation done by split creates a new generator with independence guaranteed by "provable security" in the sense Gideon mentioned - if someone can find something nonrandom in the correlation between G' and G'', say, then it amounts to a weakness in AES128 and is publishable. So it's yet another example of reducibility, common in our field: "if you can easily transform a known/famous hard problem P into this other problem Q, Q must be hard".

5 6

Re: Libraries Digest, Vol 87, Issue 16
by John Lato 10 Nov '10

10 Nov '10

> > > Message: 10 > Date: Mon, 8 Nov 2010 09:42:33 +1100 > From: Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> > Subject: Re: Haskell Platform Proposal: HLint > To: "Bryan O'Sullivan" <bos(a)serpentine.com> > Cc: libraries <libraries(a)haskell.org> > Message-ID: > <AANLkTimOMxX2TjxnO0a+20=NgJW2iGym46yrNO8iX7Y3(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 8 November 2010 08:35, Bryan O'Sullivan <bos(a)serpentine.com> wrote: > > Hlint isn't a library, right? And as an application, it presumably > doesn't for any practical reason need its dependencies in the platform in > order to itself be included? > > As I stated earlier, the policy seems to state that they do need to be > there (to be able to build the platform if nothing else): > > http://trac.haskell.org/haskell-platform/wiki/AddingPackages#PackageRequire… Well, the policy can be changed if necessary (not that I'm proposing that here). While packages may need to be present to build an application in the platform, they don't necessarily need to be exposed as part of the platform. Rationale-8.5 seems to be targeted at libraries specifically. That is, it claims there's no technical means to differentiate between blessed and non-blessed packages, which is why non-blessed packages can't be included. But since an application doesn't expose libraries, there is a simple means to make this distinction. If you think of an application in the HP as maintaining a private fork of non-HP libraries, it makes sense. Of course, this also brings up one of my concerns. That is, the potential for future maintenance of depended-upon libraries should be considered as part of potential for maintenance of the application as a whole. If the libraries are already part of HP this is simpler. For HLint specifically, my personal opinion is that library dependencies shouldn't prevent hlint's inclusion in the HP. I'm confident that haskell-src-exts will continue to be well-maintained (and I'm glad to see that it's working towards HP inclusion as well), and since Neil maintains both uniplate and hlint I don't have any concern there. John Lato

4 7

HTTP 4000.1.0 release
by Ganesh Sittampalam 09 Nov '10

09 Nov '10

Hi, I've just released HTTP 4000.1.0 to hackage: - Fixed a bug that caused infinite loops for some URLs on some platforms (whether the URL was a trigger is probably related to the size of the returned data, and the affected platforms. Based on a patch by Daniel Wagner. - This is technically a breaking change (and hence there is an API version bump) as the fix introduces a new member to the HStream class which can be used to define a new payload type instead of String/ByteString, but I scanned hackage and noone actually seems to be doing that. - Applied a patch by Antoine Latter to fix a bug in the handling of 301 and 307 response codes. Here's his description of the change: *** The Network.Browser module is a convenience layer over the Network.Http modules offering many of the niceties one would expect in a web-browser - cookies, user authentication, and transparent handling of redirects. When using Network.Browser, previously (since version 4000.0.8) a redirect response code of 301 or 307 from the server would force the redirected request to be sent as a GET, even if the original request was of some other HTTP method. This behavior is only appropriate for a response code of 302 or 303 and has been fixed. *** The upstream repo is now on github: https://github.com/haskell/HTTP, though I may well switch back to darcs if I remain maintainer for long. I'd like to emphasise that I have no particular desire to maintain HTTP and if anyone else would like to take over they would be very welcome! Cheers, Ganesh

1 0

Re: Haskell Platform decision: time to bless parsec 3?
by Christian Maeder 09 Nov '10

09 Nov '10

Am 08.11.2010 18:55, schrieb Carlton Mills: > I am a newbie. Nearly 50 years of imperative programming has > miss-trained my neurons. I am trying to retrain them. > > 1. Compatibility layers are good. They enable progress and reliability. The compatibility layer is good to compile existing code (and support testing). Using Text.ParserCombinators.Parsec from parsec 3 is no good idea, because it does not guarantee compatibility with parsec 2 (because type names like ParsecT are added.) Whenever you write a new parser and know that you will need features from parsec 3 you should (and easily can) directly use Text.Parsec. If you want to extend a parser written with parsec 2 with features not available in parsec 2 you may first try to use parsec 3. But changing your imports then, will be your least problem. In many cases you may even want to investigate other parser libraries, like attoparsec, polyparse or uulib. I think a new package parsec3 (without compatibility layer) belongs into this league of more advanced parser libraries (without blessing). Parsec 2 feels to be the right base library for the HP. Otherwise I agree with your points made. Christian > A good compiler will inline them away. > 2. The Haskell Platform should ensure that programming examples in the > leading text books can compile. A section of the release notes might > note the exceptions and provide example alternatives. > 3. Sticking to Haskell 98 when one can is probably virtuous, but ... > 4. The big mainframe vendors like IBM and Unisys have this problem > continually - big customers may need the latest version of the OS and a > 5yr old Data Base system. In the 1970's, when I worked with Unisys > systems (Burroughs then) they had rules and expectations: > a) All programs would be recompiled eventually. No object code older > than 2 release cycles would be allowed to execute. The OS would issue > warnings and make log entries when you ran programs that were about to > expires. The file search utility had a command line option to list > expiring code. > b) The customer could plan on using older compilers and older versions > of the Data Base system on new OS releases. The customer accepted the > obligation to upgrade by recompiling. > - The vendors rules/customer expectations are probably more precise > and explicit now. > > Finally, I would like to thank the people who make HP possible. When I > tried to learn Haskell (pre HP) I gave up on trying to install > interesting packages. Now, with HP, the base packages all install with > their proper compiler quickly and simply. I don't have enough experience > to help out, other than test installation of pre-releases on my Macs. > But we all should do what we can to support the HP. > > Thank you, Carlton Mills, Urbana, Illinois > > ------------------------------------------------------------------------ > *From:* Christian Maeder <Christian.Maeder(a)dfki.de> > *To:* Don Stewart <dons(a)galois.com> > *Cc:* haskell-platform(a)projects.haskell.org; libraries(a)haskell.org > *Sent:* Mon, November 8, 2010 6:51:38 AM > *Subject:* Re: Haskell Platform decision: time to bless parsec 3? > > I still favor parsec 2 over parsec 3 because > > a) parsec 3 is no longer haskell98 (as major parts of parsec 2 are) > > b) I don't like the compatibility layer (modules with re-exports) of > parsec 3 for parsec 2 > > Without the compatibility layer (b) and making the package a new major > version of parsec, we would probably not discuss this issue. > > I think the maintainers of "parsec 3" should create new package > "parsec3" without the compatibility layer. A new package parsec2 was > already created. > > There are simply no blessed parser packages! > > The problem is that so many package simply have "parsec" as dependency, > otherwise I would vote for removing parsec from HP (or vote for parsec2). > > Christian > > Am 06.11.2010 16:18, schrieb Don Stewart: >> Hey all, >> >> This is a loose end in the package policy situation: when the HP has a >> major upgrade, the policy is to do all major upgrades for any packages >> contained in the HP, as long as they don't add new dependencies. >> >> One exception to this rule has been parsec, where parsec 2 was >> considered "blessed" on an ad hoc basis. >> >> I propose we agree to remove this ad hoc rule, and thus the HP will ship >> with parsec 3. >> >> Does anyone have concerns with this? >> >> -- Don > > _______________________________________________ > Haskell-platform mailing list > Haskell-platform(a)projects.haskell.org > <mailto:Haskell-platform@projects.haskell.org> > http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform >

1 0

Template Haskell: Unresolved infix expressions
by Reiner Pope 09 Nov '10

09 Nov '10

Hi, I'm currently working on Trac #4430 [1], to improve Template Haskell's support for unresolved infix expressions. I need to add a constructor to the Exp datatype in the template-haskell library, but it is not obvious to me what the best definition of this constructor should be. I've written up the proposal on the GHC Trac wiki [2]. I would appreciate comments. Thanks. Reiner [1] http://hackage.haskell.org/trac/ghc/ticket/4430 [2] http://hackage.haskell.org/trac/ghc/wiki/UnresolvedInfixExpressions

1 0

Data.Functor module naming?
by Daniel Peebles 08 Nov '10

08 Nov '10

Hi all, I was wondering if anyone knew the rationale behind naming the module Data.Functor instead of the (seemingly) more natural Control.Functor. Thanks! Daniel

3 2

Re: Data.Functor module naming?
by Louis Wasserman 08 Nov '10

08 Nov '10

The Functor type class generalizes Applicative and Monad, but it also generalizes Foldable and Traversable, which are in Data.Foldable and Data.Traversable. Since some Applicative functors are also "data" (as opposed to operators), like the list functor, it seems like a reasonable compromise to put it in Data.Functor. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

1 0