- Libraries - Haskell.org

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 11 Feb '14

11 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 05 Feb '14

05 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

Re: [Haskell-cafe] Unmaintained packages and hackage upload rights
by Carter Schonwald 30 Jan '14

30 Jan '14

I HAVE A SOLUTION for anyone who asks me, I will help manage the "this isn't maintained, i wanna take over maintership" pestering emails that need to happen. that said, you'll still need to email me to ask me to do that, or pester me on IRC as applicable. (which may take just as much time as "hey i'd like to take over maintainership of X on hackage please" sent to the libraries list) Point being, if someone finds the prospect of doing the pestering needed to do the process overwhelming, ask me nicely, and i'll try to help push it along (while keeping them in CC and such, though they of course will have to chime in at some point) should this thread also touch on the the libraries mailing list? ccing it just in case :) point being, we need to have a responsive, *responsible* way of quickly resolving these things that easy to do. time for comments: 2 weeks -Carter On Thu, Jan 30, 2014 at 11:53 AM, Ben Gamari <bgamari.foss(a)gmail.com> wrote: > Clark Gaebel <cgaebel(a)uwaterloo.ca> writes: > > > How does the process of taking over maintenance add latency to your work? > > > > 1) Check out broken version of package. > > 2) Fix locally, bump version number locally. > > 3) cabal sandbox add-source ../fixed-package in any package that needs > the > > fixed version. > > 4) Email hackage admins for upload rights. > > 5) Continue working on your actual project. > > 6) Receive upload privileges one day. > > 7) Upload fixed package. > > > > As far as I can tell, the only real latency cost here is that paid to fix > > the broken version. > > > In my experience, step 4 involved several round trips between a number > of different people. Admittedly, this is in part because it's easy to > forget about the broken package after you have fixed it locally. > > Cheers, > > - Ben > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

[Proposal] Add default implementation of mappend/mempty in terms of mconcat
by Niklas Haas 27 Jan '14

27 Jan '14

Hello, I noticed that the current Monoid class doesn't actually provide default implementations of mappend/mempty in terms of mconcat, even though this is technically very simple: > mempty = mconcat [] > mappend a b = mconcat [a, b] This would be a rather small and non-invasive change that shouldn't break any existing programs. The main downside is that an empty Monoid declaration would produce no warnings, but #7633 gives us the ability to solve this. Discussion period: 2 weeks

8 8

A modest proposal (re the Platform)
by Mark Lentczner 20 Jan '14

20 Jan '14

Looks like GHC 7.8 is pretty near release. And while I know that we really like to have a GHC out for a while, and perhaps see the .1 release, before we incorporate it into the Platform, this GHC, while including many new and anticipated things, seems pretty well hammered on. Combine that with the now two-month late (all my fault) HP release for 2013.4.0.0 isn't slated to really have all that much new in it, in part because it is the same GHC as the last HP release. Now - it would really look foolish, and taken poorly (methinks) if we release a HP this month - only to have GHC 7.8 release early Feb. Folks would really be head scratching, and wondering about the platform. SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding it hard to get excited by it!) and instead move right to putting out 2014.2.0.0 - aimed for mid-March to mid-April. This release would have several big changes: - GHC 7.8 - New shake based build for the Platform - Support for validation via package tests - Support for a "server variant" (no OpenGL or other GUI stuff if we had any) - Automated version info w/historical version matrix page - Several significant packages: I'd like to see Aeson at the very least, updated OpenGL stuff I'd also propose changes for the Mac build (though this is obviously independent): - Built from GHC source, not dist. release. (guarantees consistent release) - Only 64bit (I know, controversial...) Thoughts?

8 8