- Libraries - Haskell.org

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

Re: Proposal: overhaul System.Process
by Simon Marlow 29 Apr '08

29 Apr '08

Brian Brunswick wrote: > On Tue, Apr 29, 2008 at 6:14 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> readProcessWithExitCode >> :: FilePath -- ^ command to run >> -> [String] -- ^ any arguments >> -> String -- ^ standard input >> -> IO (ExitCode,String) -- ^ exitcode, and stdout + stderr > > Surely in this case one wants stdout in a separate String to stderr? > > If something fails in the middle of a long operation, I want just the > error, doc! Well yes, but maybe you also want to tally the stderr with the stdout, to see what was going on at the time the errors were generated (modulo buffering, of course). How about two separate versions? In which case, what should they be called? Cheers, Simon

3 2

proper cabal use?
by Daniel Gorín 29 Apr '08

29 Apr '08

Hi In the hint [1] package I need to run ghc --print-libdir at configure time and save its result. The catch is that I need to run exactly the same ghc binary that will build the package (i.e. not necessarily the one in the path). Because of this requirement I can't use a "configure" script as advised in the docs [2], can I? What I did, instead, is to write a posthook that takes the information in the LocalBuildInfo and runs the ghc configured there. The downside is that this it is not portable across Cabal versions (incidentally, if I add the requirement cabal-version: >= 1.2 && < 1.3, hackage refuses to upload the package...) So my question is, what would be the proper way to handle this? Thanks Daniel [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint-0.2 [2] http://www.haskell.org/cabal/release/latest/doc/users-guide/ x30.html#system-dependent

2 2

Issue with package "pretty"
by David MacIver 27 Apr '08

27 Apr '08

#haskell have just helped me figure out an entertaining issue with the pretty library on hackage. I couldn't figure out the right place to file a bug report and the maintainer is listed as libraries(a)haskell.org so I'm emailing the list in the hopes that someone will know what to do about it. :-) The problem is that if you install pretty, Cabal will suddenly cease working until you recompile it. It depends on a version of pretty which gets bundled with GHC is purportedly of the same version as the one on hackage, but the two aren't binary compatible. So when it tries to use it, everything goes boom.

4 9

darcs patch: Change LICENSE from BSD4 to BSD3
by Lennart Kolmodin 26 Apr '08

26 Apr '08

Sat Apr 26 07:58:06 CEST 2008 Lennart Kolmodin <kolmodin(a)gentoo.org> * Change LICENSE from BSD4 to BSD3 Picking BSD4 over BSD3 is usually by confusion. See http://hackage.haskell.org/trac/hackage/ticket/205.

1 0