- Libraries - Haskell.org

The bytestring package has moved to github
by Bryan O'Sullivan 15 Feb '13

15 Feb '13

You can now find it here: https://github.com/haskell/bytestring Ian, please update your GHC juju accordingly.

6 7

Haskell Platform proposal: Add case-insensitive
by Gregory Collins 11 Feb '13

11 Feb '13

Hi all, First: Bas, would you support making case-insensitive a Haskell platform package? Assuming you say yes, I'd like to propose it for inclusion in the Haskell platform. The wiki page for this proposal is here: http://trac.haskell.org/haskell-platform/wiki/Proposals/case-insensitive And the case-insensitive package can be found on Hackage: http://hackage.haskell.org/package/case-insensitive If Bas is not willing to have case-insensitive be a platform package I will rescind the proposal. Any proposals for deadlines? Mark? -- Gregory Collins <greg(a)gregorycollins.net>

15 36

Re: [Haskell-cafe] Control.Monad provisional?
by Roman Cheplyaka 11 Feb '13

11 Feb '13

Alfredo is right. Most users don't pay much attention to it, and developers have preferred to be conservative and mark the modules as experimental (and provisional at best), because there's no incentive to commit to keeping the modules stable. And there's no policy about stable modules. The Haskell Platform is a much more successful experiment in the same direction, because there actually is an incentive (and clear need) to keep the packages stable. "Portability" is another obsolete field. The same information nowadays can be robustly inferred from the LANGUAGE pragmas in the modules and the .cabal file. For my packages, I stopped putting these fields quite some time ago, and I'm looking forward to their removal. Roman * Alfredo Di Napoli <alfredo.dinapoli(a)gmail.com> [2013-02-11 08:03:30+0000] > I might be wrong, > > but the impression I always had is that that field is something that most > developer struggle to keep in sync. Maybe it > was provisional ages ago, but they simply forgot to upgrade to "stable" or > they are simply too humble and think > "How am I to judge if a package is stable or not"? :) > > My 2 cents :P > A. > > On 10 February 2013 20:38, Petr Pudlák <petr.mvd(a)gmail.com> wrote: > > > Dear Haskellers, > > > > Looking at Control.Monad: > > http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Control-M… > > I see: "Stability provisional". I checked some older versions and it's > > the same. This feel somewhat unsettling - if Control.Monad is provisional, > > do we have any "stable" packages at all? > > > > Best regards, > > Petr Pudlak > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Control.Monad provisional?
by Petr Pudlák 10 Feb '13

10 Feb '13

Dear Haskellers, Looking at Control.Monad: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Control-M… I see: "Stability provisional". I checked some older versions and it's the same. This feel somewhat unsettling - if Control.Monad is provisional, do we have any "stable" packages at all? Best regards, Petr Pudlak

1 0

Re: PolyKinds in transformers
by Jake McArthur 10 Feb '13

10 Feb '13

On Sun, Feb 10, 2013 at 12:36 PM, Ross Paterson <ross(a)soi.city.ac.uk> wrote: > On Sun, Feb 10, 2013 at 11:50:29AM -0500, Jake McArthur wrote: > > I realize that transformers is intended to be portable, but I was > wondering if > > it would be crazy to use the PolyKinds extension for compilers that > support it. > > As long as nothing is added to transformers that depends on it, it > should not > > break compatibility with other compilers, and it would make a lot of > types more > > generally useful for GHC >= 7.6. > > > > Also, is there a mailing list I should be sending this to? > > Which ones would be more general? > The following transformers types would be more general with PolyKinds enabled: * Backwards * ContT * IdentityT * ReaderT * Compose * Constant * Product * Reverse > I guess libraries(a)haskell.org would be the best mailing list. > Alright, I'm including the libraries list. - Jake

1 0

HP 2013 packages shaping up...
by Mark Lentczner 10 Feb '13

10 Feb '13

Here's the state of platform as I see it shaping up for 2013.2: Proposals in flight for 2013.2: - *case-insensitive:* looking good - will require *hashable* - *attoparsec: *looking good - *JuicyPixels:* people like the idea of having a library like this one, perhaps even this one, but there is concern that this API hasn't baked enough. - *OpenGL *&* GLUT:* there is a proposal to remove these. The HP versions are very stale, and the new versions would require inclusion of packages* ObjectName*, *StateVar* and *Tensor* which has not met with approval. I would like to see those three packages removed, the modules folded back into OpenGL, and put under Graphics.Rendering.OpenGL. Proposals we need for 2013.2: - *hashable:* required by case-insensitive, no proposal yet Proposals I'd like to see for 2013.2: - *unordered-containers: *though, perhaps Johan is going to meld that into *containers*? I'd like to see the development plan for this (and * hashable*) settled. - *aeson:* we need this in the platform, as JSON has become ubiquitous. It requires settling *hashable* and *unordered-containers*. Proposals that will take some more thought, hence not likely for 2013.2: - *test-framework* & friends: these require a number of other packages like *ansi-terminal* and *hostname*. I suspect they should all just go in, but it will take some time to review and prep all that. - *criterion* & *statistics:* both require a number of smaller packages we don't have like *erf* and *math-functions*. Again, will take time to sort out. Areas still looking for good candidates (if these are simple could make it this round): - simple db like dbm or sqlite support - file utils for common file system manipulations - logging - 2D graphics - perhaps gloss and/or diagrams? - Mark

5 4

Proposal: splitting the network package
by Kazu Yamamoto 10 Feb '13

10 Feb '13

Hello, The network package contains both socket modules and a URI module. They are in different level. Since new features are actively added to the socket modules, we may want to install a new network package even though Haskell Platform includes it. However, the Network.URI module depends on Parsec which depends on the text package. This sometimes causes dependency hell. I would like to propose to split the network package into: - new network package which contains socket modules only - network-uri package which contains Network.URI only Example implementations are available: https://github.com/kazu-yamamoto/network/tree/no-uri https://github.com/kazu-yamamoto/network-uri Note that they keep necessary commit history. In HP, only "HTTP" and "cgi" depends on "network" and they use "Network.URI". They can be compiled by just adding "network-uri" as dependency. Also, "http-conduit" uses "Network.URI". This can also be compiled by adding "network-uri". For more information, please refer to: https://github.com/haskell/network/issues/76 Discussion period: 2 weeks --Kazu

24 58

Maintainer for readline
by Joachim Breitner 09 Feb '13

09 Feb '13

[Resending; looks like libraries@ does not like my @debian.org address] Hi, the readline package (used by lambdabot) lists libraries(a)haskell.org as the maintainer. Is that accurat: Does anyone on this list feel responsible for the package? If so, would you care to make it GHC-7.6-compatible: System/Console/Readline.hsc:587:1: Unacceptable result type in foreign declaration: IO CInt When checking declaration: foreign import ccall unsafe "static rl_unbind_key" rl_unbind_key :: CInt -> IO CInt (and many more of that kind) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Re: [commit: unix] master: change notes (1461d21)
by Ian Lynagh 04 Feb '13

04 Feb '13

Hi Simon, On Wed, Jan 30, 2013 at 03:04:06AM -0800, Simon Marlow wrote: > > commit 1461d21ea3096e252fdd5698772dbfd1ad033d6a > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Thu Oct 4 16:07:27 2012 +0100 > > change notes > > >--------------------------------------------------------------- > > unix.cabal | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/unix.cabal b/unix.cabal > index 287caa8..1aaaec9 100644 > --- a/unix.cabal > +++ b/unix.cabal > @@ -14,6 +14,11 @@ description: > IEEE Std. 1003.1). > . > The package is not supported under Windows (except under Cygwin). > + . > + Changes in 2.7.0.0: > + . > + * @ProcessStatus@ changed to include a core-dumped flag. > + > extra-source-files: > config.guess config.sub install-sh > configure.ac configure The unix version number is still 2.6.1.0, but doesn't the new policy http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages mean that it should be bumped to 2.7.0.0 now? Also, what's the plan for the changelog? Is the package description going to accumulate entries, or just show those for the most recent version? Wouldn't it be better to include a CHANGES file instead? Thanks Ian

5 7

Re: [commit: base] master: fix negative numbers for * modifiers (#7457) (63202b9)
by Ian Lynagh 29 Jan '13

29 Jan '13

On Mon, Jan 28, 2013 at 02:06:48AM -0800, Simon Marlow wrote: > > commit 63202b9df64041e1c17603ad5f06fec3c51f357d > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Mon Jan 28 09:38:06 2013 +0000 > > fix negative numbers for * modifiers (#7457) > > >--------------------------------------------------------------- > > Text/Printf.hs | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/Text/Printf.hs b/Text/Printf.hs > index 0546e84..6028e16 100644 > --- a/Text/Printf.hs > +++ b/Text/Printf.hs > @@ -281,7 +281,7 @@ getSpecs l z s ('*':cs) us = > in ((p', r), us''') > '.':r -> (stoi 0 r, us') > _ -> ((-1, cs), us') > - in (n, p, l, z, s, cs'', us'') > + in (abs n, p, if n < 0 then not l else l, z, s, cs'', us'') > getSpecs l z s ('.':cs) us = > let ((p, cs'), us') = > case cs of Hmm, this works for minBound for Int8: > printf "%*sx\n" (-4 :: Int8) "hi" hi x > printf "%*sx\n" (minBound :: Int8) "hi" hi x but not Int: > printf "%*sx\n" (-4 :: Int) "hi" hi x > printf "%*sx\n" (minBound :: Int) "hi" hix (the last line should have a huge number of spaces between "hi" and "x". Actually, this matches what the printf commandline program does: $ printf "%*sx\n" -4 hi hi x $ printf "%*sx\n" -2147483648 hi hix and C just doesn't print anything: $ cat q.c #include <stdio.h> int main(void) { int i; i = -2147483648; printf("%*sx\n", -4, "hi"); printf("%*sx\n", i, "hi"); printf("Test\n"); return 0; } $ gcc q.c -o q $ ./q hi x Test $ This probably isn't important for printf, but it's a problem that seems to keep coming up. I wonder if there's something we should do. We could add methods like maybeAbs :: a -> Maybe a maybeAbs = Just . abs -- default method to Num, but div and friends are a little trickier, as they can return either divZeroError or overflowError, or even partially succeed in the case of (-1) `divMod` minBound == (overflowError, 0) Thanks Ian

1 0