June 2010 - Libraries

Status of regex-posix on Windows?
by Claus Reinke 16 Jun '10

16 Jun '10

There was a thread here in March 2010 about issues with building regex-posix on Windows: http://www.haskell.org/pipermail/libraries/2010-March/013321.html It was pointed out that the maintainer doesn't have Windows access, and some conclusion seems to have been reached that allowed regex-posix to be included in the Haskell platform release. But it does not look as if the results were fed back to the maintainer for inclusion in the regex-posix package (darcs or hackage version). What is the recommended way to build regex-posix on Windows these days? Could the information be distilled into a package that builds without hacks, and could the hackage package please be updated to reflect that? It is a platform package, after all. Claus It looks as if at some point the package could just be built without external dependencies (other than GHC's build system) but it is not clear to me what the current intention is for building on Windows. The hackage version is still missing bits from the darcs version (in particular, the c-code to build and link with/include from), the darcs version has Makefiles that date back to when regex-posix was built within GHC's build system, and a configure.ac proclaiming the library to be at version 0.71. The .cabal file (version 0.94.2) features two Build-type entries (Custom and Simple), the Setup.hs simply calls defaultMain.

1 0

Parsec branch (was Re: Bug in Parsec.Token)
by Antoine Latter 16 Jun '10

16 Jun '10

On Sat, Apr 3, 2010 at 6:21 AM, wren ng thornton <wren(a)community.haskell.org> wrote: > > I'd argue that it's acceptable, at least under this plan: > > * fork parsec-2.1 as parsec2-2.1 > * continue to develop parsec2-* (as desired) > * deprecate parsec<3 with message to switch to parsec2-* > * continue parsec>=3 as parsec-* > > > The harm is minimal because: > > (a) anyone who is too lazy to upgrade their .cabal can still use parsec-2.1 > until it bitrots > > (b) anyone who is too lazy to upgrade their code to parsec>=3 can just > update their .cabal to use parsec2-* if they want to avoid bitrot > > (c) anyone using parsec>=3 won't notice a thing. > I really like this plan, so I've finally gotten something done in this direction. I pulled parsec-2.1.0.1 off of hackage and stuffed it into a fresh darcs repo, and I've made two branches off of it: http://community.haskell.org/~aslatter/code/parsec-2/parsec2/ This is a new package that I am willing to maintain. I expect to be limiting my actions to maintaing compatibility with as many GHC releases as practical, and I will accept patches needed to get working on other implementations. Fixes such as Greg's above are also appropriate when kept in sync with main-line. http://community.haskell.org/~aslatter/code/parsec-2/parsec-deprecated/ I propose to upload this to hackage as parsec-2.1.0.2. It is identical in all respects to 2.1.0.1, except each module is marked as deprecated, producing the following warning: Text/ParserCombinators/Parsec/Language.hs:27:0: Warning: In the use of type constructor or class `LanguageDef' (imported from Text.ParserCombinators.Parsec.Token): Deprecated: "Please use the parsec2 package or upgrade to a higher version of parsec" Any comments on either of these two branches? Is parsec2 the right name for the branch package? Does anyone want to see anything different in the package description text? Is the next step getting parsec2 into the Platform, and updating inter-platform deps? Take care, Antoine

3 2

Deepseq proposed patch
by Julian Blake Kongslie 14 Jun '10

14 Jun '10

Control.DeepSeq has a large number of instances for its class NFData, I'd like to propose a new one: import Data.Data dataDeepSeq :: (Data a) => a -> a dataDeepSeq a = gmapQr ($) a (seq . dataDeepSeq) a instance (Data a) => NFData a where rnf a = dataDeepSeq a `seq` () This is obviously a very broad instance. I believe, for example, that it correctly covers at least every type that is covered by just the instances currently provided in Control.DeepSeq. It also makes it easy to make a new type "deepseq-able" in GHC, as there is an extension which makes Data derivable. I do not believe this instance to be particularly inefficient, although I will grant that there may be types where the NFData instance can force evaluations in a particular order which may be faster than the order chosen by the Data instance. The mechanism is relatively straightforward: The gmapQr is recursively finding all children in the data structure, and creating a long string of seq calls to force each one to be evaluated before finally returning the parent structure. As long as the Data instances don't have "holes" where they skip some children of the structure, this should visit every thunk in the structure and evaluate them all. Of course, this raises an interesting point: Are there types which can be reasonably made NFData instances, but not Data instances, or for which the NFData instance can be made significantly better in some way? I'd appreciate your thoughts on this, -Julian Blake Kongslie Please CC me on replies.

5 6

Re: package naming policy (was: Please check your dependencies on fgl)
by Don Stewart 11 Jun '10

11 Jun '10

jwlato: > > From: Don Stewart <dons(a)galois.com> > > > > ivan.miljenovic: > >> Thomas Bereknyei are currently re-writing fgl (just about completely > >> from scratch) and we plan to make an initial release to get feedback > >> on the API in the next few weeks. > >> > >> However, I'm sending this email out now to warn people that I highly > >> doubt any code that was written for the current version of fgl > >> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the > >> new version. > > > > How about you give the library a different name then -- so as not to > > break all those programs? > > > > A complete rewrite with a new maintainer: fgl-awesome > > I would like to argue against this practice, i.e. re-naming new, > incompatible versions of existing packages. I think it's bad for the > following reasons: > > 1. It makes development by new users more difficult by fracturing the > package-space (the "Which version of QuickCheck should I use?" > problem). Since this is already an acknowledged issue, I think it's > better that developers not add to it. > 2. It discourages adoption of the latest version despite any benefits > the later version may provide. This also leads to greater > incompatibility between dependent packages. > 3. For packages in the platform, I believe this will create > uncertainty about which package(s) should be included with new major > releases. > 4. It adds to the maintainer workload as the same person or team will > often be responsible for both packages. > > I do agree that there are legitimate reasons why users may decide to > remain with older versions, however I think that in nearly all cases > the proper solution is to follow the PVP and for users to include > upper dependency bounds in .cabal files. In particular, for the very > common case of compatibility with older code, an upper dependency > bound seems like the correct approach. > > IMHO changing a package name should be for when developers intend to > continue development (not just maintenance releases) along both > branches. Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan.

3 3

ANN: bytestring-trie 0.2.2 (major bugfix)
by wren ng thornton 11 Jun '10

11 Jun '10

-------------------------------------------- -- bytestring-trie 0.2.2 (major bugfix) -------------------------------------------- Another release for efficient finite maps from (byte)strings to values. This version corrects a major bug affecting all users who merge tries. -------------------------------------------- -- Changes (since 0.1.4) -------------------------------------------- * Corrected a major bug in mergeBy which caused conflicting values to be merged in the wrong order. Since this is a core function, all other merging-based functions are affected as well (e.g., unionR, unionL,...). The bug was filed by Gregory Crosswhite (thanks!). * added Data.Trie.Convenience.fromListWith --- A variant of 'fromListR' that takes a function for combining values on conflict. * generalized the type of toListBy * removed KeyString and KeyElem aliases * documentation tweaks -------------------------------------------- -- Future work -------------------------------------------- * Worked on explicit definitions for foldl and foldr, as opposed to the default definitions given by Foldable using Endo. The suggested definitions are around 3x faster than the old definitions, however the order of folding is different than foldrWithKey (which seems to have the correct order). These definitions are not currently being used, but perhaps the future will see faster folding functions for Tries. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-trie Darcs: http://community.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring… -- Live well, ~wren

1 0

Fwd: [Gtk2hs-users] Installation problem with cairo.
by Magicloud Magiclouds 09 Jun '10

09 Jun '10

Hi, I cannot install gtk2hs-cairo by cabal using cairo 1.9.6 compiled myself. Cabal always said that the cairo library/devel files were missing. ---------- Forwarded message ---------- From: Axel Simon <Axel.Simon(a)in.tum.de> Date: Tue, Jun 8, 2010 at 7:15 PM Subject: Re: [Gtk2hs-users] Installation problem with cairo. To: Magicloud Magiclouds <magicloud.magiclouds(a)gmail.com> Cc: gtk2hs-users <gtk2hs-users(a)lists.sourceforge.net> Hi again, it's very difficult for me to say what is happening. Could you ask on the cabal mailing list to see if anybody there has an idea. Cheers, Axel On 08.06.2010, at 11:01, Magicloud Magiclouds wrote: > I've tried a little, the error was not thrown out in gtk2hssetup.hs. > And even I faked a version (1.8.10), it did not work. > > On Tue, Jun 8, 2010 at 3:47 PM, Axel Simon <Axel.Simon(a)in.tum.de> wrote: >> >> Hi, >> >> On Jun 8, 2010, at 9:21, Magicloud Magiclouds wrote: >> >>> Yes, seems like so. >>> Here is the output: >>> >>> # /usr/bin/pkg-config --modversion cairo-pdf >>> 1.9.6 >>> # /usr/bin/pkg-config --modversion cairo-ps >>> 1.9.6 >>> # /usr/bin/pkg-config --modversion cairo-svg >>> 1.9.6 >>> # /usr/bin/pkg-config --modversion cairo >>> 1.9.6 >>> >> >> Oh dear. >> >> Since cabal manages once to get the correct version and fails later on, I >> assume it's the magic Duncan added to out Gtk2HsSetup.hs file that requests >> the package version again. If you look for >> >> --FIXME: Cabal should tell us the selected pkg-config package versions in >> the >> -- LocalBuildInfo or equivalent. >> -- In the mean time, ask pkg-config again. >> >> in the cabal file and try to add some debugging output then maybe you can >> find out more. >> >> I suspect that either the LocalBuildInfo or the PackageDescription value is >> not the most up-to-date one but some default value that lack some path or >> some such. >> >> cheers, >> Axel >> >>> On Tue, Jun 8, 2010 at 2:56 PM, Axel Simon <Axel.Simon(a)in.tum.de> wrote: >>>> >>>> Hi, >>>> >>>> On Jun 8, 2010, at 8:54, Magicloud Magiclouds wrote: >>>> >>>>> /usr/bin/pkg-config --modversion cairo >>>>> setup: Missing dependency on a foreign library: >>>>> * Missing C library: cairo >>>>> This problem can usually be solved by installing the system package that >>>>> provides this library (you may need the "-dev" version). If the library >>>>> is >>>>> already installed but in a non-standard location then you can use the >>>>> flags >>>>> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. >>>> >>>> well, what's the output of >>>> >>>>> /usr/bin/pkg-config --modversion cairo >>>> >>>> ? Maybe cabal fails to parse the version for some reason. >>>> >>>> Axel >>>> >>>> >>> >>> >>> >>> -- >>> 竹密岂妨流水过 >>> 山高哪阻野云飞 >> >> > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 -- 竹密岂妨流水过山高哪阻野云飞 -- 竹密岂妨流水过山高哪阻野云飞

1 0

Rewriting a famous library and using the same name: pros and cons
by Don Stewart 08 Jun '10

08 Jun '10

There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL a similar opportunity is present with 'fgl', where the new maintainers are seeking to improve the code. Below I try to summarise the pros and cons of calling the new rewrite/api 'fgl', in the hope we can identify a path that minimizes disruption to users. ------------------------------------------------------------------------ A group of developers is planning to write a new graph library for Haskell. * They maintain an existing package called 'fgl'. * 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/ * The new library will have different authors and a different API. * They would like the new library 'fgl'. It is a controversial step to write a new library and give it the same name as an existing, famous library. Let's look at the arguments. = Reasons to use the new name = * The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption. * Rewrites are effective if the name is preserved. E.g. QuickCheck 2. * It is the maintainer's right to modify APIs as they see fit. * Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. * Relatively few packages use fgl. So damage is limited. = Reasons not to use the name = * Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.… * Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us. * The package has been stable for ~10 years -- why change a stable API? It is already "perfect" * The new package really isn't the same package in any sense. * Rewrites by new teams damage the brand of famous packages (e.g. parsec 3) * No additional breakages are introduced. * If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest. * Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here) * Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway. Are there any other arguments I'm missing? -- Don

3 2

darcs patch: Remove dependency on the Prelude in Control.Concurrent...
by Johan Tibell 08 Jun '10

08 Jun '10

1 patch for repository /usr/local/google/src/base-event: Tue Jun 8 11:13:20 CEST 2010 Johan Tibell <johan.tibell(a)gmail.com> * Remove dependency on the Prelude in Control.Concurrent.MVar

1 1

darcs patch: Remove Prelude dependency from Data.Monoid
by Johan Tibell 08 Jun '10

08 Jun '10

1 patch for repository /usr/local/google/src/base-event: Mon Jun 7 17:58:16 CEST 2010 Johan Tibell <johan.tibell(a)gmail.com> * Remove Prelude dependency from Data.Monoid This removes an import cycle involving the new I/O manager code.

1 2

Re: [Haskell-cafe] The state of Hackage: what are we doing about it?
by Don Stewart 03 Jun '10

03 Jun '10

si: > Don wrote > > > I see fairly regular complaints about too many Haskell libraries, > > bewildering choice of difficult-to-determine quality. > > > > I've tried to summarize the state of Hackage, and what projects are > > active to make it easier to find high quality libraries: > > > > http://tinyurl.com/2cqw9sb > > > > Thoughts? > > the Hayoo! group is currently extending the search engine, such that it > becomes possible, to not only search types and functions, but also search the > package descriptions. Building a search index for the cabal package > description is already implemented. At the moment the Hayoo! search interface > is is the missing part. Technically it's not a difficult extension, but > currently we don't have very much spare time. > > For ranking the results for a package search, a download statistic could be > very useful and could easily be integrated. If such a statistic would be > available in machine readable format (csv, xml, plain text, ...), we could > integrate that. > I've been posting CSV files of the download statistics here: http://www.galois.com/~dons/hackage/hackage-downloads.csv The next quarter's aggregated downloads are due soon. The Arch Haskell site uses these stats to compute some popularity metrics: http://www.galois.com/~dons/arch-haskell-status.html -- Don

1 0