May 2008 - Libraries - Haskell.org

Specifying dependencies on Haskell code
by Duncan Coutts 12 May '08

12 May '08

All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan

7 17

Re: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support
by Don Stewart 10 May '08

10 May '08

vigalchin: > so Don you are saying that mqueue and RTsched I should put on Hackage to > avoid putting in the Unix package? Vis-a-vis fsync and fdatasync I have no > choice .. they both IMO belong in Files.hsc. Right, there are two options: 1) put it in a new package. unix-extensions or 2) submit it as a patch to the libraries(a)haskell.org mailing list, and it can be put in the main 'unix' darcs repository, which then gets uploaded to hackage in the next release cycle. It's currently a bug that anyone can (accidentally) release their own versions of the core libraries. Cheers, Don

6 10

Patch: fixed typo in base modules comments
by Andriy Palamarchuk 10 May '08

10 May '08

Replaced "iff" with "if". Please apply. Andriy ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

3 2

Release of unix 2.4.0.0
by Don Stewart 10 May '08

10 May '08

Vasili Galchin did a release of a new version of the unix library. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.4.0.0 Hmm :( This is a core package, maintained by libraries@, so shouldn't be being uploaded to hackage by 3rd parties. What can we do? -- Don

2 2

Re: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support
by Don Stewart 10 May '08

10 May '08

vigalchin: > Hello, > > Additional POSIX realtime (POSIX 1003.1b) support has been added: > > 1) MQueue.hsc - POSIX message queues > > Supported FFI bindings for: > > - mq_open > > - mq_close > > - mq_unlink > > - mq_getattributes > > - mq_setattributes > > - mq_send > > Not yet supported bindings: > > - mq_rcv .. still debugging a mysterious problem > > - mq_notify - will support when asynchronous I/O is implemented > > 2) RTsched.hsc - real time scheduling > > Supported bindings for: > > - sched_yield > > - sched_get_param > > - sched_set_param > > - sched _get_scheduler > > - sched_set_scheduler > > - sched_get_priority_min > > - sched_get_priority_max > > Unsupported currently: > > - sched_rr_get_interval - still looking for the TimeSpec data > type in order to get "peek" working > > 3) Files.hsc > > Added bindings for: > > - fsync > > - fdatasync > > I am new to Haskell but would like to make a lot of contributions to > insure Haskell success in the marketplace (of ideas ;^)). I apologize for > any glitches and look for feedback. Very interesting! However... this library is a core package, and maintained by libraries(a)haskell.org, so you should not release it yourself. Instead, submit your patches to libraries@ for inclusion, following the patch submission guide here: http://haskell.org/haskellwiki/How_to_write_a_Haskell_program Where the patches will be tested on other unix platforms, and then encorporated into the main 'unix' repository. Also, as unix .hsc files tend to be a bit fragile, portability wise, it might be a good idea to instead place your patches in a separate library on hackage, rather than patching the 'unix' package directly. We have many other unix-alike packages, so one for message queues, and real time scheduling make sense -- separate from the core 'unix' package (like the mmap package, for example). -- Don

1 0

proposal #2254: have Control.Arrow re-export (>>>) and (<<<)
by Ross Paterson 06 May '08

06 May '08

A previous proposal: http://hackage.haskell.org/trac/ghc/ticket/1773 split the Arrow class, making (>>>) and (<<<) functions in Control.Category. This breaks programs that use Control.Arrow. To avoid some of the breakage, the proposal is that Control.Arrow should re-export (>>>) and (<<<), imported from Control.Category.

6 12

Deriving instance for Foreign.C.Error.Errno (trac 2261)
by Thomas M. DuBuisson 06 May '08

06 May '08

Errno, the Haskell encapsulation of the CInt 'errno' value, should be an instance of the commonly used type classes so higher level data structures that include it aren't bothered. This change will break code that has custom instances for Errno, but this should be little (if any) code. A patch is attached to the trac ticket to derive Show and Ord while Eq remains a custom instance. One could argue that, like Eq, Show and Ord should be customized to provide a identical result for all 'invalid' errno's - any thoughts on if this is necessary and what the corner case result would be? http://hackage.haskell.org/trac/ghc/ticket/2261 Thomas P.S. Traveling soon, so I won't be responsive - sorry.

2 2

QuickCheck properties for IntSet
by David Benbennick 01 May '08

01 May '08

Here's a patch to IntSet.hs that adds many QuickCheck properties. It adds properties testing almost all of the public interface of IntSet, and also properties testing that the data type invariants are never broken. (The patch doesn't test the Data, Eq, Monoid, Read, or Typeable instances.) Also, this patch removes a helper function, foldlStrict, and replaces it with calls to Data.List.foldl'. I have two questions: 1) Is this the right way to submit patches? 2) Is there a good reason that IntSet doesn't use "deriving Eq", and instead manually implements the Eq instance?

5 21

Re: getLazyByteString network I/O Bug
by Lennart Kolmodin 01 May '08

01 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Right, so it comes down to how binary handles chunks of the ByteString that might not yet be available. We have do decide what is reasonable to handle, and what could possibly trigger an error. splitAtST is too strict in the #ifndef BYTESTRING_IN_BASE version. Why the versions differ? I don't know. Even if it did not need any more data it forces the next chunk. This is easy to fix. This solves the problem when you ask for some data which is available, but the data after that is not. As I don't fully understand the splitAtST solution I can't say which splitAtST version is buggy. Then reading the last available data would create a state ~ S B.empty lbs x where lbs is an unevaluated lazy bytestring. ~ All is well as lbs remains unevaluated Curt, this is probably the bug you ran into. However, another issue; if you run any action and ask for 0 bytes; ~ like ~ * getByteString 0, or ~ * getLazyByteString 0 and no bytes are available, it would still block. Like so: ~ runGet (getByteString 0) (...blocking lazy bytestring...) This is due to that creating the state (mkState) forces the first chunk. 152 mkState :: L.ByteString -> Int64 -> S 153 mkState l = case l of 154 L.Empty -> S B.empty L.empty 155 L.Chunk x xs -> S x xs Is it acceptable to block in this case? By making splitAtST not force its last argument, let getLazyByteString and getBytes return an empty string immediately when 0 bytes are requested, we solve the three issues. Too hackish? Would anyone like to shed some light on why splitAtST forced the last argument? Cheers, ~ Lennart Kolmodin Curt Sampson wrote: | dcoutts on #haskell suggested that a difference in behaviour | between Data.Binary's getByteString and getLazyByteString was a | bug. Basically, in my particular case I send something to the | server (or for the purposes of this test, just connect) and it | sends back a non-newline-terminated response. If I pull it from the | getContents of the handle using getByteString, it works fine; if I use | getLazyByteString, it blocks, even though it has all of the data it | needs to satisfy the request. | | BTW, I did try setting the mode of the handle to non-blocking, but it | didn't make any difference in either case. | | I've attached a small project that displays this difference; see the | README at the top level to see how to try it for yourself. | | Incidently, I'm ghc 6.8.2 on NetBSD 4, and of course using the version | of Data.Binary that's included in the project, 0.4.1. | | Also, let me know if this is about the right amount of work for a test | case for something like this. It took me about an hour to put together, | so if you didn't really need all of this, I can probably send you less | next time. | | cjs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgaDOAACgkQ4txYG4KUCuEZ3ACfYJIPl/hKYoyudojK9VX5KTBe kjMAn3jFY0XnZdT7jlOZsJ004q0y6aIo =eG2B -----END PGP SIGNATURE-----

1 0