- Libraries - Haskell.org

Proposal: POSIX process group API reform
by Favonia 26 May '11

26 May '11

I am proposing a POSIX process group API change in order to (1) make ProcessGroupID a newtype of CPid, and (2) make it possible to query the process group of an existing process. The motivation is that currently there is no way to query a process group of an existing process, but it seems needed for a proper implementation for ticket #3994. Also it seems nice if the compiler can do distinguish ProcessGroupID from ProcessID, just like Fd from CInt. The full proposal is at the wiki page http://www.haskell.org/haskellwiki/POSIX_process_groups_reform_proposal . The patches and test cases are all attached in the ticket http://hackage.haskell.org/trac/ghc/ticket/5167 . For backward compatibility the current patches preserv the current implementation if possible. In contrast the proposal on the wiki suggests a more aggressive reformation. Thanks, Favonia PS: Sorry but the patch to the package base is not fully tested, as I have not figured out the correct way to compile package base (even without the patch). However the patch to the package unix should work independently of the patch to the package base.

2 3

Policy for taking over a package on Hackage
by Ivan Lazar Miljenovic 25 May '11

25 May '11

With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I was thinking of doing so, and in such a case it would probably make the most amount of sense to actually then migrate the package back to the wl-pprint package instead of defining yet another package (and corresponding namespace), especially as I recalled from when I first started hacking on wl-pprint-text at the beginning of the year that the last (and only) upload had been in 2007 by Stefan O'Rear. As such, I was going to email Stefan and asked if he minded if I took over maintaining wl-pprint. However, when I went to the package page to get his email address, I saw that Otakar Smrz had released a new version about a month ago, and that the only change in the package that I could find was that OverlappingInstances was added to the .cabal file (which I thought wouldn't make a difference anyway). Now, for all I know, Otakar had already asked Stefan for permission to take over the package (I've CC'd both of them just in case). But even if he didn't, we don't officially have any policies set in place - especially ones that are enforced by requiring registering a package and specifying a maintainer - to indicate that such a thing shouldn't be done. Furthermore, if packages aren't announced then there's no way for people to know that there _is_ a new maintainer. This situation also arose last year [1], and was resolved by someone volunteering to take over a package. However, no formal policy was set in place (despite one being proposed). As such, I'd like to propose the following policy based upon the one Ben Millwood proposed last time on how to take over maintainership of a package that hasn't been updated for a while: 1. Email the current listed maintainer and wait a specified period of time (e.g. 2 weeks). 2. Email haskell-cafe, explicitly CC'ing maintainers of reverse dependencies (at least those that are themselves still active) and request permission to take over. This way, people who know the maintainer might point out that they are indeed still around, etc. 3. If no-one objects within another two weeks, announce that you have taken over maintainership with a new email (in case people are ignoring the previous thread). 4. Upload a point release of the previous package (assuming it follows the PVP) with yourself as the new maintainer (just to get it out there). Alternatively, if you already have a new version ready to go then upload that. Of course, having a policy like this is useless if there is no way to enforce it. Is it possible at the very least to have Hackage note when a new version of a package is uploaded with a new maintainer and require it to be approved by someone before it iis officially available? I think this would be the bare minimum (as opposed to requiring explicit logins on a per-package basis or some kind of signing) required for this kind of scheme to be effective. [1]: http://www.haskell.org/pipermail/haskell-cafe/2010-August/081353.html and http://www.haskell.org/pipermail/haskell-cafe/2010-August/082319.html -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

3 2

Re: Policy for taking over a package on Hackage
by Ivan Lazar Miljenovic 25 May '11

25 May '11

On 25 May 2011 23:23, Otakar Smrz <otakar.smrz(a)cmu.edu> wrote: > > I took over the maintenance of wl-pprint since Stefan suggested it > himself. I needed to include OverlappingInstances, because that was > required to make better use of the library (there is a difference having > this flag there, which is consistent with the GHC documentation on > OverlappingInstances). > > I was not aware that I have to announce this. I thought people would > know from checking Hackage that there is this maintainer change and a > new version of the package. Sorry. The whole email wasn't aimed at you specifically: it's just that with Hackage's current infrastructure it's quite easy for someone to "take over" a package and possibly do something malicious with it (so the next time they do a "cabal update" they could inadvertently get a package with said malicious code). Especially if there's no announcement of the change, it's difficult to know that someone has indeed taken over maintaining a library, and thus they could keep addressing queries (or throwing blame) at someone "known" to be the maintainer of a package even if they didn't upload the latest version. > Since I do not have any plans to develop wl-pprint further, I have no > problem giving the maintainer's role to you or anyone interested. OK; if no-one has any objections I'll do so and make it class-based as I've discussed in the threads on -cafe (after considering name clashes with Applicative, etc.). > PS: For the point 4 of your suggested rules, I think uploading a new > version of a package if only the maintainer changes, rather than when > there is some actual change to the library, is inappropriate. You could > easily get package versions increasing without any code/documentation > being actually improved or extended. By "point release" I meant incrementing the fourth digit, which is usually used to refer to bug-fixes. My aim with this was that the new maintainer could immediately "make their mark" so that people looking for a project's maintainer on the hackage page knew who to contact (rather than waiting for them to finish of their new & improved version). -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

RE: New libraries process
by Simon Peyton-Jones 25 May '11

25 May '11

Thank you! I've added you as such. Simon | -----Original Message----- | From: David Terei [mailto:davidterei@gmail.com] | Sent: 21 May 2011 00:42 | To: Simon Peyton-Jones; cvs-ghc(a)haskell.org; Haskell Libraries | Subject: Re: New libraries process | | I'd be happy to maintain the Pretty library. | | Cheers, | David

1 0

ANNOUNCE: HaNS-2.1.0.0
by Trevor Elliott 24 May '11

24 May '11

Galois, Inc. is pleased to announce the release of HaNS, the Haskell Network Stack. HaNS is a lightweight, pure Haskell network stack that can be used for Haskell networking in the context of the HaLVM, or with a Linux tap device. Currently, HaNS supports 802.3, IPv4, ARP, DHCP (partially), ICMP, UDP, and TCP. On Hackage: http://hackage.haskell.org/package/HaNS Git repo: http://code.galois.com/cgi-bin/gitweb The TCP component is a port of Peng Li and Stephan Zdancewic's Haskell TCP library, which in turn was translated from Norrish et al's HOL4 TCP specification. What might you use HaNS for? Developing new and interesting networking protocols, at any layer of the network stack, or your own variants of existing protocols. HaNS allows HaLVM nodes to support networking, meaning you can run experimental network services directly on top of the HaLVM (without any pesky OS getting in the way). There are probably lots of other cool applications of HaNS we haven't though of yet. HaNS is released under a BSD license, and should be considered experimental at this stage. If you have any questions please contact the HaLVM team at halvm-devel(a)community.galois.com. -- Trevor Elliott (for the HaLVM team) P.S. If you're building with the HaLVM, make sure to add -fhalvm to your cabal install invocation. = References = HaLVM: http://halvm.org Haskell TCP: http://hackage.haskell.org/package/tcp

2 1

Re: Proposal: Value strict versions of containers
by Sebastian Fischer 24 May '11

24 May '11

On Mon, May 23, 2011 at 4:29 PM, Johan Tibell <johan.tibell(a)gmail.com>wrote: > On Mon, May 23, 2011 at 4:18 PM, Sebastian Fischer <fischer(a)nii.ac.jp> > wrote: > > Because unboxing can not be used for the polymorphic value component in > the > > strict structure and there is no way to tell GHC to unbox the specific > > instantiation `IntMap (Lazy a)`? > > Exactly. This would amount to code generation in the module defining > IntMap (Lazy a), similar to how C++ implements template. I see. Given that library authors currently work around the lack of this optimization it's probably a Good Thing to add it to GHC. But that is a separate topic as it seems impractical to extend GHC before containers gets updated. Sebastian

1 0

Proposal: Value strict versions of containers
by Edward Z. Yang 23 May '11

23 May '11

As it stands, we have strict functions for certain operations, such as insertWith. But this current selection is somewhat arbitrary. For illustrative purposes, here are other functions that ought to be strictified in IntMap, because there is no easy way for a user to implement them. Data.IntMap insertLookupWithKey adjust adjustWithKey update updateWithKey updateLookupWithKey alter updateMinWithKey updateMaxWithKey updateMax updateMin map mapWithKey There are also some functions that could be implemented by the user, assuming that IntMap always forces the outer structure returned by the combining functions here, but are tricky to do so. mapAccum mapAccumWithKey mapAccumRWithKey mapAccumL mapMaybe mapMaybeWithKey mapEither mapEitherWithKey Since there are so many of these functions, I propose we introduce Lazy and Strict versions of IntMap. We should also carefully document operations on the IntMap that are strict on all values; for example, filter. Similar changes should be made to Data.Map. There is also a companion proposal: Regardless of whether or not we implement Strict and Lazy versions of IntMap, we should implement all of these strict versions of functions, because are not easy for end-users to implement. A counter-proposal is, if we split out Strict and Lazy IntMap, we should *remove* all strict functions from the lazy map, on grounds that selective strictness can be implemented with an extra layer of indirection on the Strict IntMap. Commentary: I favor separate value strict and value lazy maps, and also believe that insertWith' and friends should be deprecated from the lazy versions. I don't think reimplementing all of these functions to be strict is a good idea, on code duplication and API clutter reasons. Remember: at the cost of one layer of indirection, you can be selectively lazy using IntMap (Lazy a). Discussion period: 3 weeks Cheers, Edward

8 16

Re: Libraries Digest, Vol 93, Issue 20
by Louis Wasserman 22 May '11

22 May '11

I remember that proposal, and it would've definitely supported strictified operations. On Sat, 21 May 2011, Edward Z. Yang wrote: > > > As it stands, we have strict functions for certain operations, such as > > insertWith. But this current selection is somewhat arbitrary. For > > illustrative purposes, here are other functions that ought to be > strictified in > > IntMap, because there is no easy way for a user to implement them. > > Is it possible to solve this with the proposed Location interface? > > "Library proposal: add a Location interface for element-wise operations on > Data.Map" > http://www.haskell.org/pipermail/libraries/2011-January/015593.html > >

1 0

Bugfix for parallel package
by Daniel Fischer 16 May '11

16 May '11

Hi, since libraries@ is the maintainer of parallel, I send the patch for http://hackage.haskell.org/trac/ghc/ticket/5100 here. nonempty-chunks fixes the bug, whitespace removes trailing whitespace in Control.Parallel.Strategies, version-bump bumps the version to 3.1.0.2. Please review.

1 0

ANN: protocol-buffers, protocol-buffers-descriptor, hprotoc version 2.0.5
by Chris Kuklewicz 16 May '11

16 May '11

There is a new version of the Haskell implementation of Google's protocol buffer message serialization format. Performance for serialization has been improved in this release. The new code is up on hackage 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 at http://code.haskell.org/protocol-buffers/ The changes in 2.0.5 compared to 2.0.2 are: * Specialize some encoding during serialization to improve performance * Add some options that protoc handles and that were missing in hprotoc * Alter the namespace resolution in hprotoc to better match protoc * Improve error handling during name resolution in hprotoc * Lex and parse the new aggregate options in Google version 2.4.0 Note that the new aggregate syntax in Google's version 2.4.0 is not supported. The change allows the new notation to be parsed and a clear error message to be reported. -- Chris Kuklewicz

1 0