- Libraries - Haskell.org

who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed
by Carter Schonwald 15 Feb '14

15 Feb '14

Hey all, someone needs to help take over language C maintainer ship, because its going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue) I know Anthony and Jason have at points patched language-c for their respective needs, so i'm cc'ing em :) -Carter

10 12

Re: Taking over maintenance of posix-realtime?
by Carter Schonwald 13 Feb '14

13 Feb '14

ccing libraries list :) -Carter On Thu, Feb 13, 2014 at 1:04 AM, Michal J. Gajda <mjgajda(a)gmail.com> wrote: > Dear Package Trustees, > > The posix-realtime-0.0.0.1 has been uploaded in 2008, and it doesn't > work with current GHC 7.6.3. > I managed to make it compile (see http://github.com/mgajda/posix-realtime > ). > I got permission from Vasili (original developer) to take over maintenance. > Could you please make me a member of maintainer group on Hackage? > (Currently it is libraries@... but nobody seems to take responsibility. > I assume libraries@... is a placeholder for "No real maintainer, so > maybe somebody else does it" then.) > > Or just change maintainer group to me, since obviously nobody else > seemed to show interest in the package so far? > -- > Best regards > Michal >

1 0

cabal and extra-libs
by fa-ml 13 Feb '14

13 Feb '14

Hello list, recently I am having trouble installing a package (hbro, more info here [1]). Today I decided to remove every 0mq installed (even system ones) and run another installation to see what went wrong. So I downloaded zmq3, reinstalled it, tried to run cabal install hnro which lead to Loading package zeromq3-haskell-0.5.1 ... <command line>: can't load .so/.DLL for: libzmq.so (libzmq.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: After locating libzmq.so, I typed cabal install hbro --extra-lib-dirs=/home/user/media/vcs/zeromq-3.2.4/src/.libs/ This unfortunately was greeted with the same error, which makes me question wheter I am invoking cabal with the right parameters/wheter cabal actually looks inside that directory. Cabal version: cabal-install version 0.14.0 using version 1.14.0 of the Cabal library # I use debian/wheezy Am I incorrectly calling cabal or is this a bug? -F [1] http://www.haskell.org/pipermail/beginners/2014-February/013152.html

3 3

Re: Maintainership of dvi-processing
by Daniil Frumin 12 Feb '14

12 Feb '14

This is very similar to a situation that was discussed earlier on Cafe. I think you should be given (at least temporal) maintainership to upload a new version of the package given that the package is currently un maintained >> On 11 Feb 2014, at 23:15, Jean-Philippe Bernardy <bernardy(a)chalmers.se> wrote: >> >> Hello, >> >> I wish for the dependencies of package dvi-processing to be updated to current versions. The listed maintainer ("AaronBlack") appears to be unsearchable on the internet (no mention on the name can be found in connection to the Haskell language, except has maintainer on Hackage). Hackage does not seem to want to reveal an email address either. >> >> Hence I propose to take over maintainership of the package. I beg the powers that be to let me know if this would be possible, and if so when it can happen. >> >> Many anticipated thanks, >> JP Bernardy. >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries -- Sincerely yours, -- Daniil

1 0

Maintainership of dvi-processing
by Jean-Philippe Bernardy 12 Feb '14

12 Feb '14

Hello, I wish for the dependencies of package dvi-processing to be updated to current versions. The listed maintainer ("AaronBlack") appears to be unsearchable on the internet (no mention on the name can be found in connection to the Haskell language, except has maintainer on Hackage). Hackage does not seem to want to reveal an email address either. Hence I propose to take over maintainership of the package. I beg the powers that be to let me know if this would be possible, and if so when it can happen. Many anticipated thanks, JP Bernardy.

5 5

Fwd: [Haskell-cafe] Filing bugs for haskell packages
by Richard Eisenberg 08 Feb '14

08 Feb '14

Hi libraries, The message below came through Cafe. It reports a problem when emailing libraries(a)haskell.org, which is listed as the maintainer of several public packages. Yet, the list does not accept emails from non-subscribers. These two facts seem to be at odds, and turns people away from reporting bugs. Can we fix this? Or, do we want a separate, world-writable libraries-bugs(a)haskell.org? Thanks! Richard Begin forwarded message: > From: Szymon Pyżalski <zefciu(a)gmail.com> > Subject: [Haskell-cafe] Filing bugs for haskell packages > Date: February 7, 2014 3:08:20 AM EST > To: haskell-cafe(a)haskell.org > > Hello! > > I am new to haskell and I found a bug in package http://hackage.haskell.org/package/regex-compat-0.92/docs/Text-Regex.html > > On the hackage page it says that the maintainer e-mail of this package is: libraries(a)haskell.org. So i sent a bug report there, but bounced back to me because of quota. So apparently nobody reads these e-mails. > > How can I file a bug report for this package? I don't feel good enough in haskell to try and fix it myself. > > Greetings > Szymon Pyżalski > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

12 14

incorrect MonadPlus law "v >> mzero = mzero"?
by Petr Pudlák 06 Feb '14

06 Feb '14

Hi, this law apparently fails for a MonadPlus instance that has more than one possible failure value. Consider: runIdentity . runErrorT $ ((ErrorT . Identity $ Left "failure") >> mzero :: ErrorT String Identity ()) evaluates to `Left "failure"`, which isn't equal to ErrorT's mzero `Left ""`. This isn't just the case of ErrorT, it fails for any MonadPlus with multiple failure values. For example lift (tell "foo") >> mzero :: MaybeT (Writer String) () is again distinct from mzero. Actually, no monad transformer with a MonadPlus instance can satisfy the law, because the first part in front of `>> mzero` can introduce side effects in the underlying monad. I'm not sure what should be the proper solution. Perhaps to change the laws to: return x >> mzero = mzero (v >> mzero) >>= f = (v >> mzero)` That is, if an expression ends with `mzero`, it behaves like `mzero`. Petr

3 6

Proposal: add Control.Exception.SomeAsyncException
by Roman Cheplyaka 05 Feb '14

05 Feb '14

It is often useful to distinguish between synchronous and asynchronous exceptions. The common idiom is to run a user-supplied computation catching any synchronous exceptions but allowing asynchronous exceptions (such as user interrupt) pass through. There's no way to know how — synchronously or asynchronously — an exception was thrown, so we have to work around it by relying on the exception type itself. Unfortunately, the AsyncException type was designed as a leaf in the exceptions hierarchy, so it's not possible to extend it with user-defined asynchronous exception types. Thus I propose to add SomeAsyncException as an extensible type ("class") of asynchronous exceptions. It will be a direct subclass of SomeException, and will become the superclass of the existing AsyncException type. Users can then define their own asynchronous exceptions by subclassing SomeAsyncException. My main motivation for this change is exceptions used for timeouts. So the second part of this proposal it to mark System.Timeout.Timeout as an asynchronous exception. Roman

4 4

System.Directory.getPermissions crashes when checking file on read-only file system
by Alain O'Dea 05 Feb '14

05 Feb '14

Prelude> System.Directory.getPermissions "/usr/bin/ld" *** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system) That seems wrong. An access(*, W_OK) syscall by design should return EROFS on a read-only file system by specification. This breaks Cabal on SmartOS since /usr is read-only by design and Cabal calls getPermissions "/usr/bin/ld". Is this a Cabal bug or a directory library bug? I am happy to contribute to fixing this in any way I can. Best, Alain

2 1

New Win32 release more or less ready
by Bryan O'Sullivan 05 Feb '14

05 Feb '14

Hi, Austin - I've played some catchup with the Win32 library today, and HEAD currently builds with 7.4 through 7.8 (32- and 64-bit) and contains some additional bugfixes. Unless some last minute changes come in, this is more or less what we should ship with GHC 7.8.1 final. Let me know when you're ready to roll a new 7.8.1 RC, and I can tag and upload Win32 2.3.0.2 to Hackage. B.

1 0