- Libraries - Haskell.org

Improving X11.Image
by Mitar 02 Dec '10

02 Dec '10

Hi! I have made some improvements to Graphics.X11.Xlib.Image. Currently it is made as a independent library which provides extended functionality (mostly I was interested in saving screen shots of windows), but I could be easily moved to Graphics.X11.Xlib.Image. Please see attached files. image.c and image.h is additional C code required, Image.hsc is an interface to: PlaneMask, allPlanes, Image(..), getImage, getPixel, writeBitmapFile, getHeader, readColors, getXwdColor, freeReadColors, saveImage Some links: http://tronche.com/gui/x/xlib/graphics/XGetImage.html http://tronche.com/gui/x/xlib/utilities/XWriteBitmapFile.html saveImage is a helper function for saving screen shots. Mitar

1 0

Proposal: Export String from Data.String (and two related proposals)
by Bas van Dijk 01 Dec '10

01 Dec '10

Hello, I would like to make three proposals, in order of importance IMHO: 1. Export String from Data.String. Most modules in base and on Hackage of the form: Data.<type> also export <type>. I think it's surprising and confusing that Data.String doesn't conform to this pattern. 2. Unexport String from Data.Char. I feel less strongly about this one, but in general I think it is good that a symbol is exported from as few modules as possible. 3. Export the String operations: lines, words, unlines and unwords from Data.String. I feel even less strongly about this one. However these are operations on Strings so it makes sense to export them from Data.String. As a counter argument you could say these operations either receive or produce a _list_ of Strings so they only belong in Data.List. If we accept 3 then in the spirit of "export a symbol from as few modules as possible", you may expect a fourth proposal: Unexport the String operations: lines, words, unlines and unwords from Data.List. However I think this will break lots of programs. I have no problem also discussing this one though. Discussion deadline: 3 weeks from now: Wednesday 10 November. Ticket with patches: http://hackage.haskell.org/trac/ghc/ticket/4422 Regards, Bas

5 10

Re: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools
by Axel Simon 30 Nov '10

30 Nov '10

Dear Libraries, this message is on shortcomings of cabal with respect to automatically installing the gtk package which (a) depends on a package that contains only build tools (i.e. only binaries) and (b) has a big custom Haskell file Gtk2HsSetup.hs that Setup.hs has to import (and which is required in any package in the Gtk2Hs suite). This file is copied into every package of the Gtk2Hs suite which is a pain to maintain. On 25.11.2010, at 10:50, Lazycat Manatee wrote: > ---------- Forwarded message ---------- > From: Jens Petersen <petersen(a)haskell.org> > Date: 2010/11/25 > Subject: Re: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools > To: Andy Stewart <lazycat.manatee(a)gmail.com> > > >> Jens Petersen <petersen(a)haskell.org> writes: >> >>> I suggest moving Gtk2HsSetup.hs into a library, it could be part >>> of gtk2hs-buildtools perhaps. How about it? >> It can't work. >> >> Because we need Gtk2HsSetup.hs generate Signals.chs and Types.chs >> *before* >> any cabal depend check. > > Hmm I haven't tested but don't really understand. > You mean it will break builds with cabal-install? > Doesn't gtk2hs-buildtools already do that? :) > Yes, but these are two separate show-stoppers: a) the gtk2hs-buildtools contains only binaries. It does not register as a package with ghc. Thus, if we make the gtk package depend on gtk2hs-buildtools, cabal would complain that (even after installing gtk2hs-buildtools) the gtk2hs-buildtools library is not there b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available. I don't know if (b) can be solved by e.g. conditionally importing Gtk2HsSetup.hs if it is there and only installing libraries and re- invoking Setup.hs one this is done. This is a common trick in Makefiles, e.g. one could call make recursively to first build dependencies. Any suggestions welcome. Regards, Axel

4 5

Versions of bracket without masking acquire action
by Mitar 30 Nov '10

30 Nov '10

Hi! With new mask/restore concept it is impossible to unblock exceptions in acquire action which is quite often useful (acquire can be a lengthily action). So it could be a good idea to introduce a variant which has acquire action unmasked. http://hackage.haskell.org/trac/ghc/ticket/4810 Mitar

1 0

ANNOUNCE: iteratee-compress 0.1.2
by Maciej Piechotka 28 Nov '10

28 Nov '10

Iteratee-compress provides compressing and decompressing enumerators including flushing. Currently only gzip is provided but at bzip and LZMA are planned. This is bug-fixing release Changes from previous version: - Fix infinite loop/segfault bug - Fix bug in which part of the output was lost - Support for iteratee 0.5 and 0.6 Next goals: - BZip support - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing? Regards

1 1

ANNOUNCE: iteratee-compress 0.1.2
by Maciej Piechotka 28 Nov '10

28 Nov '10

Iteratee-compress provides compressing and decompressing enumerators including flushing. Currently only gzip is provided but at bzip and LZMA are planned. This is bug-fixing release Changes from previous version: - Fix infinite loop/segfault bug - Fix bug in which part of the output was lost Next goals: - BZip support - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing? Regards

1 0

Re: RFC: Adding a Hashable type class and HashMap/HashSet data types to HP
by wren ng thornton 27 Nov '10

27 Nov '10

On 11/24/10 11:41 AM, Duncan Coutts wrote: > On 22 November 2010 01:19, wren ng thornton wrote: >> +1. Especially given the recent trend towards breaking things out of base, >> moving this in is suspect. As folks have been moving towards base-4 we've >> been able to finally start getting rid of the slew of Cabal flags for >> figuring out when base does or does not include various libraries. Don't >> start inventing new ones :) > > It's not a simple question of "put stuff in base" vs "take stuff out > of base" one has to look at what it is that it makes sense to put in / > take out. The things we have been removing from base have mainly been > independent implementations of things, not standard interfaces. There > is a pretty reasonable argument that standard interfaces -- especially > type classes -- should go in base, while almost all implementation do > not need to be. Right. My implication was that the module in question doesn't seem like the kind of thing that should go in base. Generally used classes (sans implementations) tend toward moving into base because having the class sans implementation in its own package is cumbersome[1], and having the class with its implementations introduces unnecessary dependencies. However, that doesn't mean that all widely used classes should move into base. For instance, consider the popular library Foo which defines a FooClass; because Foo is widely used, FooClass will be too, but if Foo is a graphics library or some other domain-specific thing, then FooClass may not have the kind of generality that's appropriate for base classes. While the idea of hashing is certainly general enough, I don't know that this particular class definition of the idea is.[2] Compare against the current development of classes for randomly generating values. The base class is problematic, as has been known for some time, but the new classes aren't settled in stone yet either. Not to mention that QuickCheck, SmallCheck, etc have classes with similar goals of constructing values "out of nothing" but whose goal is very different than the statistically random generation of types like Int or Double. I anticipate similar issues happening with hashing a few years down the road once people have played around with the hashable/hashmap packages more, and therefore do not think it should be included in base. [1] Though not necessarily a bad idea. If each independent family of classes were in their own package, then we could give those families version numbers of their own instead of trying to remember which version of base/quickcheck/... added or removed some particular method. This, on the whole, strikes me as a good idea since it puts the version numbers where they belong and makes it clearer for using CPP to conditionalize parts of the implementation. Unfortunately, it's a heavyweight solution and cabal doesn't seem like quite the right tool to be tracking this sort of thing. [2] Things like groups, fields, etc have well-defined interfaces and so it's easy to see whether they are complete and appropriate or not (ignoring debates about whether the algebraic classes are the right generalizations to be used). Even things like a class for monad transformers are defined almost entirely based on the types that things must have. But hashing doesn't have the same kind of well-defined structure as either of these. -- Live well, ~wren

1 0

HP 2011 alpha
by Don Stewart 26 Nov '10

26 Nov '10

Test build with the following changes appears to be consistent, using GHC 7 RC2: HTTP 4000.0.9 -> 4000.1.0 HUnit 1.2.2.1 -> 1.2.2.3 QuickCheck 2.1.1.1 -> 2.4.0.1 cgi 3001.1.7.3 -> 3001.1.7.4 deepseq 1.1.0.0 -> 1.1.0.2 haskell-src 1.0.1.3 -> 1.0.1.4 mtl 1.1.0.2 -> 2.0.1.0 #### network 2.2.1.7 -> 2.3 parallel 2.2.0.1 -> 3.1.0.1 parsec 2.1.0.1 -> 3.1.0 #### regex-posix 0.94.2 -> 0.94.4 text Added: 0.10.0.0 transformers Added: 0.2.2.0

4 4

an update on the text package proposal and a call for consensus
by Duncan Coutts 24 Nov '10

24 Nov '10

All, Following the recent discussions about some details in the text package we have had a revision to the proposal. I am confident that we will now be able to achieve a consensus on the last issue of contention and thus we will be able to accept the package as a whole for the next HP release. This email is to summarise the issue, to detail the proposed resolution and to call for consensus on accepting the text package into the Haskell platform. Summary ------- Out of around 90 functions in the Data.Text module, a number of people had concerns about the names and types of 10 of them. In particular the concern was about whether names and types should match between the standard List module and other "list like" modules such as Text (but other examples include ByteString etc). Some functions in the Text API that involve selecting a location in a Text (e.g. to break it at that point). Some of these functions come in two variants: * one based on searching for a character satisfying a predicate * one based on searching for a substring In the standard List module there are only equivalents for the first variant. Taking the example of the functions that break a text into two, in the original proposal the two variants were named as: break :: Text -> Text -> (Text, Text) breakBy :: (Char -> Bool) -> Text -> (Text, Text) This gave the short name 'break' to the substring version, and the longer name 'breakBy' to the character predicate version. The argument for doing this is that the substring version should be the common encouraged one and so it should get the short name. The argument against is that this is inconsistent with the List library which gives the name 'break' to the element predicate version: break :: (a -> Bool) -> [a] -> ([a], [a]) Updated proposal ---------------- The updated proposal accepts the point that the names should be consistent with the List library. The substring versions are given new names with a suffix to distinguish them. In the break example the two variants are now: breakOn :: Text -> Text -> (Text, Text) break :: (Char -> Bool) -> Text -> (Text, Text) The full set of names and types that have changed are as follows The substring functions are now named with the 'On' suffix: breakOn :: Text -> Text -> (Text, Text) breakOnEnd :: Text -> Text -> (Text, Text) breakOnAll :: Text -> Text -> [(Text, Text)] splitOn :: Text -> Text -> [Text] The character predicate functions now match the List names: break :: (Char -> Bool) -> Text -> (Text, Text) span :: (Char -> Bool) -> Text -> (Text, Text) partition :: (Char -> Bool) -> Text -> (Text, Text) find :: (Char -> Bool) -> Text -> Maybe Char split :: (Char -> Bool) -> Text -> [Text] Minor function -------------- One last function that some people raised minor concerns about is the function count :: Text -> Text -> Int This function is not in the List library. It was added to the ByteString library with the type BS.count :: Word8 -> ByteString -> Int The suggestion from some reviewers was that the type be equivalent between ByteString and Text. The current text proposal leaves the count function as it is. If the consensus is that these functions should have equivalent types then my proposal (as a maintainer of the bytestring package) is that we should generalise the type of the count function in the bytestring package. Feel free to comment on this issue. On a procedural note, I see no problem with including a change to the bytestring package into this proposal for the text package. Call for consensus ------------------ http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Consensus Are there any unresolved concerns? If not then the text package will be accepted with the changes outlined above. Duncan (with his Haskell Platform Steering Committee hat on)

2 3

Re: Contribution vs quality, and a few notes on the Platform process
by John Lato 23 Nov '10

23 Nov '10

> > From: Jens Petersen <petersen(a)haskell.org> > > [Me late to the party as usual...] > > On 9 November 2010 21:50, Ross Paterson <ross(a)soi.city.ac.uk> wrote: > > Let's do both: > > - a set of packages under community control that we're trying to make > > consistent. > > - a set of package versions that are popular, meet objective standards > > and have been tested to build together. > > But let's not try to force these to be the same. > > I agree with Ross: and have been thinking the same lately > that it would be really nice to have a midway between the strictness > of HP and the fast flowing package stream of hackage. > > It would great to have a consistent large set of source packages > brought together into one stable package repo - it would be big with > 100s of packages but only one version of a package would be allowed > and built on top of current HP which should be the base of course. > Probably the main barrier to entry/updates would be not breaking > or conflicting with any other package. > > Anyone interested in this? I think Linux distros and Haskell > development would benefit greatly from such a large consistent > collection of libraries, which could be updated in continuous > rolling mode during the life-time of each HP release. There > could also later be different streams (stable, testing, unstable, etc). > I agree this would be useful, particularly if it would help distro packagers. I'd be willing to contribute to such an effort. John Lato

1 0