- Libraries - Haskell.org

Re: Data instance for Data.Version
by Administrator 15 Mar '13

15 Mar '13

I.e. move Distribution.Version code that is not deprecated and not parsing- or pretty printing related (these depend on other Cabal modules). On Fri, Mar 15, 2013 at 7:26 PM, Administrator <admin(a)rodlogic.net> wrote: >> Hi, >> >> Can we derive Data for Data.Version.Version? It would benefit Cabal. >> >> Thanks, >> David > > On a related note, what about also moving some (maybe all) of the nice > Distribution.Version related functions from the Cabal package to > Data.Version? I am sure other libraries would also be interested in > using this functionality without having to include Cabal as a whole. > One example is the Ghc runtime itself: this could be one small step in > removing dependencies from Ghc to Cabal.

1 0

Re: Advance notice that I'd like to make Cabal depend on parsec
by Roman Cheplyaka 15 Mar '13

15 Mar '13

* Heinrich Apfelmus <apfelmus(a)quantentunnel.de> [2013-03-15 10:38:37+0100] > Duncan Coutts wrote: > >Hi folks, > > > >I want to give you advance notice that I would like to make Cabal depend > >on parsec. The implication is that GHC would therefore depend on parsec > >and thus it would become a core package, rather than just a HP package. > >So this would affect both GHC and the HP, though I hope not too much. > > > >[..] > > > >Why did I choose parsec? Practicality dictates that I can only use > >things in the core libraries, and the nearest thing we have to that is > >the parser lib that is in the HP. I tried to use happy but I could not > >construct a grammar/lexer combo to handle the layout (also, happy is not > >exactly known for its great error messages). > > Reuse is good, but the implication I'm worried about is this: Can I > upgrade the parsec package installed on my system by doing a user > install from hackage ? Without an implementation of more flexible > package installations (multiple versions installed simultaneously), > any dependency of GHC has its version number essentially set into > stone. We've had that working for a long time. Right now I even have multiple installed versions of Cabal-the-library itself. It's not that Parsec would be automatically linked into each executable. It's just that ghc-the-program would have Parsec linked into it. Roman

2 2

RE: Advance notice that I'd like to make Cabal depend on parsec
by Simon Peyton-Jones 14 Mar '13

14 Mar '13

Yes I think that'd be a great plan. It's bizarre that GHC depends on *all* of Cabal, but only uses a tiny part of it (more or less the Package data type I think). Simon | -----Original Message----- | From: cabal-devel-bounces(a)haskell.org [mailto:cabal-devel-bounces@haskell.org] | On Behalf Of Administrator | Sent: 14 March 2013 15:23 | To: Duncan Coutts | Cc: Lentczner; cabal-devel; Haskell Libraries; ghc-devs(a)haskell.org | Subject: Re: Advance notice that I'd like to make Cabal depend on parsec | | This GHC dependency on Cabal is putting a rather troubling constraint | in Cabal's evolution, which in my opinion is a serious problem. When I | first took a look at the dependencies between GHC and Cabal I found it | a bit strange that GHC would depend on Cabal as I would expect GHC to | be as low in the dependency tree as possible to avoid exactly these | kinds of problems. | | These GHC dependencies on Cabal are in fact small (see | http://hackage.haskell.org/trac/ghc/attachment/ticket/7740/ghc-2.png | for a summary) and with a little bit of refactoring it would be | possible to split these dependencies into a very small shared package | with minimal or no further dependencies. This would liberate Cabal to | make the necessary refactoring. | | IMHO, the addition of these new dependencies to Cabal should go | together with splitting the GHC-Cabal shared dependencies into a | separate package so that there would be no additional coordination | needed from then on between these two development efforts (except when | dealing with this new package). | | | On Thu, Mar 14, 2013 at 12:12 PM, Duncan Coutts | <duncan.coutts(a)googlemail.com> wrote: | > On Thu, 2013-03-14 at 16:06 +0100, Gregory Collins wrote: | >> On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts | <duncan.coutts(a)googlemail.com | >> > wrote: | >> | >> > Hi folks, | >> > | >> > I want to give you advance notice that I would like to make Cabal depend | >> > on parsec. The implication is that GHC would therefore depend on parsec | >> > and thus it would become a core package, rather than just a HP package. | >> > So this would affect both GHC and the HP, though I hope not too much. | >> | >> | >> +1 from me, although the amount of potential knock-on work might be | >> discouraging. The current cabal-install bootstrap process (which is | >> currently pretty easy and is necessary at times) will get a bunch more deps | >> as a result of this change, no? | > | > Yes it will, but given that we do have a script it's not too bad I | > think. And overall I think its worth it to have the better error | > messages, performance and memory use. Do you have any idea how slow it | > is to parse all the .cabal files on hackage, and how much memory that | > takes? You'd be horrified :-) | > | > Duncan | > | > | > _______________________________________________ | > cabal-devel mailing list | > cabal-devel(a)haskell.org | > http://www.haskell.org/mailman/listinfo/cabal-devel | | _______________________________________________ | cabal-devel mailing list | cabal-devel(a)haskell.org | http://www.haskell.org/mailman/listinfo/cabal-devel

3 3

Re: Advance notice that I'd like to make Cabal depend on parsec
by Duncan Coutts 14 Mar '13

14 Mar '13

On Thu, 2013-03-14 at 12:22 -0300, Administrator wrote: > This GHC dependency on Cabal is putting a rather troubling constraint > in Cabal's evolution, which in my opinion is a serious problem. When I > first took a look at the dependencies between GHC and Cabal I found it > a bit strange that GHC would depend on Cabal as I would expect GHC to > be as low in the dependency tree as possible to avoid exactly these > kinds of problems. The problem is that a compiler is a rather sophisticated application and so though you'd like it to have minimal deps, it needs to do so much stuff that it ends up needing lots of deps to support its features. Things would be easier if that were not the case, and it's made harder by the fact that ghc is not just a program, but it's exposed as a library, which exposes all of its dependencies. > These GHC dependencies on Cabal are in fact small (see > http://hackage.haskell.org/trac/ghc/attachment/ticket/7740/ghc-2.png > for a summary) and with a little bit of refactoring it would be > possible to split these dependencies into a very small shared package > with minimal or no further dependencies. This would liberate Cabal to > make the necessary refactoring. Except that the bits of Cabal that ghc needs are exactly the bits that will now need parsec, text etc. The shared part would be the part that defines the InstalledPackageInfo and the parser for that. Also, though the ghc library has only relatively small dependencies on Cabal, the ghc build process uses Cabal extensively, and currently the system is that libraries that ghc needs to build get included as core libraries and shipped with ghc. That itself could change but it's also more work. > IMHO, the addition of these new dependencies to Cabal should go > together with splitting the GHC-Cabal shared dependencies into a > separate package so that there would be no additional coordination > needed from then on between these two development efforts (except when > dealing with this new package). So I would consider this if I thought it'd make a difference. In particular at some point we'll want to split the Cabal lib into the bit that just defines types and parsers etc, and the part that is a build system. But even that wouldn't save us any dependencies in this situation. Duncan

1 0

A more useful Monoid instance for Data.Map
by Daniel Peebles 13 Mar '13

13 Mar '13

Hi all, Currently Data.Map has a Monoid instance, but it's rather lossy and not as general as it could be: instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions The instance would be much nicer if it required a Monoid on v and used unionWith mappend instead of just union. The current behavior could be emulated by using First/Last as the Monoid (or ideally a semigroup, but that's or another discussion), but other more interesting Monoid instances could also be used for the values. I realize that changing instances could break code, but I'd be curious to see how many people even use the current monoid instance. Does anyone have any system for testing hypotheses like this (by typechecking a large randomized chunk of hackage or something)? It looks like the idea has been around for at least five years: http://hackage.haskell.org/trac/ghc/ticket/1460 but the proposal was abandoned, so I wanted to see if I could get people to start talking about it again. Thanks, Dan

13 29

Re: A more useful Monoid instance for Data.Map
by Gabriel Gonzalez 13 Mar '13

13 Mar '13

-1 on breaking the existing Monoid instance. I'd prefer either: a) A newtype for the additional Monoid instance, or b) providing an associative operator equivalent to the new Monoid instance I'm not convinced that the replacement instance is more useful, let alone useful enough to break everything depending on containers. A lot of packages both on and off Hackage depend on Edward's code, almost all of which would break as a result of this change.

3 2

Haskell Platform 2013.2 Kick-Off
by Mark Lentczner 10 Mar '13

10 Mar '13

*All: * It's Haskell Platform season again! Here's the time line the 2013.2 release: - *Today* — Announce start of process, call for proposals for additions and changes - *March 25th* — Call for proposals ends (no more proposals considered) - *April 8th* — Proposals decided, Initial version list - *April 22th* — First candidates - *April 29th* — Open issues resolved, Second candidates - *May 6th* — Final release candidates *Library Maintainers:* Beginning of April I'll be e-mailing all library maintainers asking for the version to include in this release of HP. This is a good time to get what you want tested against 7.6.2 and up on Hackage. Even if the answer "the latest version, x.y.z" or "same as last time, x.y.z", I'd still like to hear from you with the version number when I e-mail. This time around I'll be trying to run cabal tests for packages if they exist. The state of proposals hasn't changed much since my message from Feb. 9th, (see copy below). What is needed ASAP is: - *hashable* - we need a proposal for this - someone? - *OpenGL *&* GLUT* - I understand from Jason that he's agreed to do the module re-work the group asked for. We don't need a proposal, but I'd like to hear from Jason how's it goin'. I'd still like to see proposals for *unordered-containers*, and *asson*, but not essential. *Distro packagers:* I'll be improving the scripts some this round. I'm looking to a) incorporate tests from packages that have them, b) considering building GHC from source rather than using the built distribution (for Mac OS X). Let me know what you need from the scripts. — Mark "Chief Haskell Gift-Wrapper" Lentczner Proposal details, from Feb. 9th e-mail: Proposals in flight for 2013.2: - *case-insensitive:* looking good - will require *hashable* - *attoparsec: *looking good - *JuicyPixels:* people like the idea of having a library like this one, perhaps even this one, but there is concern that this API hasn't baked enough. - *OpenGL *&* GLUT:* there is a proposal to remove these. The HP versions are very stale, and the new versions would require inclusion of packages* ObjectName*, *StateVar* and *Tensor* which has not met with approval. I would like to see those three packages removed, the modules folded back into OpenGL, and put under Graphics.Rendering.OpenGL. Proposals we need for 2013.2: - *hashable:* required by case-insensitive, no proposal yet Proposals I'd like to see for 2013.2: - *unordered-containers: *though, perhaps Johan is going to meld that into*containers*? I'd like to see the development plan for this (and * hashable*) settled. - *aeson:* we need this in the platform, as JSON has become ubiquitous. It requires settling *hashable* and *unordered-containers*. Proposals that will take some more thought, hence not likely for 2013.2: - *test-framework* & friends: these require a number of other packages like *ansi-terminal* and *hostname*. I suspect they should all just go in, but it will take some time to review and prep all that. - *criterion* & *statistics:* both require a number of smaller packages we don't have like*erf* and *math-functions*. Again, will take time to sort out. Areas still looking for good candidates (if these are simple could make it this round): - simple db like dbm or sqlite support - file utils for common file system manipulations - logging - 2D graphics - perhaps gloss and/or diagrams?

1 0

ANNOUNCE: hF2-0.2
by Marcel Fourné 09 Mar '13

09 Mar '13

Hi, this is the second release of hF2, a F(2^e) backend for cryptographic code, to be found at http://hackage.haskell.org/package/hF2 (or simply by "cabal install hF2") This library is used in hecc for elliptic cryptography on binary field curves and came into existence during my master thesis. Since the code from back then some speedups and changes to data representation were made which lead to an increase in speed from the first correct protoype to this release by the factor 10^86 on my main development machine. Sadly, this is still slower than pure C or Assembler versions, but a lot more portable, (arguably) easier to read and easier to parallelize. The code does automatic bit slicing and uses mainly the vector library as a fast backend. Feats of this release: - Speed (256 bit curve point multiplication in hecc is now at about a second in time) - LINEAR speedup in threaded execution with the number of cores (up to the number of bits divided by the wordsize) - Manually tested - Prelude-like Interface (more in progress) - Mostly timing attack resistant (also in progress) Next up: Testing and fixing hecc for this release. Have a nice weekend, Marcel -- Marcel Fourné OpenPGP-Key-ID: 4991 8AA4 202F 12AC 41F7 6C77 CA83 BDF0 7454 5C72 I am a programmer. I want languages and libraries, not just huge tools.

1 0

How to avoid trailing whitespace generated by Text.PrettyPrint.HughesPJ?
by Peter Simons 09 Mar '13

09 Mar '13

Hi guys, it seems to me like the HughesPJ pretty printer has trouble dealing with empty lines in a nested environment. Consider the following example: > import Text.PrettyPrint.HughesPJ > test1 = putStrLn $ render $ nest 4 $ vcat $ map text [ "line 1", "", "line 2" ] The 'test1' function prints the following output, where blanks have been replaced by underscores to make them visible: *Main> test1 ____line_1 ____ ____line_2 Now, I would like to avoid this kind of trailing whitespace in the document I'm generated -- but how? My first thought was to replace text "" by empty, but that change effectively removes the empty line altogether: > test2 = putStrLn $ render $ nest 4 $ vcat $ [ text "line 1", empty , text "line 2" ] *Main> test2 ____line_1 ____line_2 Is there another way to accomplish what I want? Take care, Peter

3 3

Taking over maintenance for the NetSNMP library
by Pavlo Kerestey 08 Mar '13

08 Mar '13

Hi, we want to publish a chage to the NetSNMP library that would introduce a more ressource friendly snmpBulkWalk binding. We have contacted the current maintainer with the patch but did not get any answer since one week. The library was last updated in 2009, last compiled with ghc 7.0, and looks like it is abandoned. The function in question would be: snmpBulkWalk :: Hostname -> Community -> OID -> IO (Either String [SnmpResult]) The rest of the library would stay the same for now. After consulting #haskell and #hackage irc channels we've got a suggestion to take over the package and bump the version to 0.2.* so that if the original developer wants to pick it up later, we can do a merge or fix the bugs in the current 0.1.* branch without breaking anyone's code. We would wait for another week with this and if there are no objections, then we will do as suggested. We would like to publish the library on github as well, so that its becomes easier for the others to help. Greetings, Pavel. -- Pavlo Kerestey Software Engineer at Global Access Internet Services GmbH https://kerestey.net | http://www.global.de

1 0