Hi, cabal-install 1.18.0.2 has two critical bugs on Windows. 1. "cabal sdist" command make broken tarball on Windows. https://github.com/haskell/cabal/issues/1538 2. "cabal update" command broke package index sometimes. https://twitter.com/xyx_is/status/391944129074044929 (in Japanese) Both bugs are already fixed in 1.18 branch's cabal-install (with Cabal 1.18.1.2). But that version isn't released yet. So, please release newer version of cabal-install before releasing HP 2013.4.0.0. Best Regards, On Mon, 11 Nov 2013 01:46:18 +0900, Johan Tibell wrote:

hashable bump is good. I'm also pro shipping a newer Cabal, if it doesn't cause any issues with the one that already comes with GHC.

On Sun, Nov 10, 2013 at 5:11 PM, Mark Lentczner wrote:

...

I know it is late, and so I've done some preliminary version sleuthing.... Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but hoping to hear from all relevant parties soon.

*GHC 7.6.3* -- this is a compiler bump, but all the included packages remain at the same version as 2013.2.0.0

*Packages with no changes:* fgl, haskell-src, html, HTTP, HUnit, mtl, parsec, QuickCheck, random, regex-base, regex-compat, regex-posix, split, stm, text, transformers, xhtml, zlib

*Packages with minor version bumps:* *I'll advance these automatically this time - no need for maintainer input* cgi: 3001.1.7.5 → 3001.1.8.4 network: 2.4.1.2 → 2.4.2.0 parallel: 3.2.0.3 → 3.2.0.4 syb: 0.4.0 → 0.4.1 unordered-containers: 0.2.3.0 → 0.2.3.3 vector: 0.10.0.1 → 0.10.9.1? primitive: 0.5.0.1 → 0.5.1.0?

*Packages with major version bumps:* *I'd like to get confirmation from the maintainers of these packages that this bump is "the right thing to do". The bump should ideally only add API, and not orphan any program that used to compile under the HP - at least not without a good reason.* case-insensitive: 1.0.0.1 → 1.1.0.1 hashable: 1.1.2.5 → 1.2.1.0

GLUT: 2.4.0.0 → 2.5.0.1 GLURaw: 1.3.0.0 → 1.4.0.0 OpenGL: 2.8.0.0 → 2.9.1.0 OpenGLRaw: 1.3.0.0 → 1.4.0.0

alex: 3.0.5 → 3.1.0 happy: 1.18.10 → 1.19.0

*New Packages:* *There was prior discussion on the libraries mailing list, and generally all around resounding "YES!" for including aeson.* *I think we should include it. I'm looking for confirmation from the maintainer that this is the right version to include.* aeson: 0.6.2.1

*Cabal:* *The Cabal 1.18 release was a major new release, including the very very useful sandbox feature. This would require shipping a different Cabal lib than the version shipped with the included GHC. I'm not sure of the implications of doing this - in particular, whether we would have to ship two Cabal packages or just the later.* Cabal: 1.16.0 → 1.18.1.2 cabal-install: 1.16.0.2 → 1.18.0.2

What do you all think?

— Mark "late, but not forgotten" Lentczner

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

Including aeson, which I think we'd all very much like to do, requires dlist-0.5. Now, dlist has been around for a very long time, and is very stable. I do not believe that dlist's API is exposed indirectly via aeson at all. I hereby propose that it be added to the platform. At the very least, it could be like primitive - in the platform, but not "part" of it. Thoughts? - Mark ​

I spoke too soon: *aeson* induces *blaze-builder* & *dlist* -- both are pretty long term established and stable - I say include 'em both. *cgi* 3001.1.8.4 induces *MonadCatchIO-mtl* & *extensible-exceptions* - this is more problematic: - *extensible-exceptions* hasn't been needed since GHC 7, and just reexports stuff into a different place. I don't think that should be in the platform. - *MonadCatchIO-mtl* is one of several approaches to re-mapping extensible exceptions into *mtl*. While none is settled practice yet, this one is probably a dead end as it uses the older block/unblock idiom rather than the now preferred mask idiom. I'm planning holding *cgi* back to 3001.1.7.5 to avoid these two packages. thoughts always welcome! - Mark

Is the API actually different, or just at a different module location? In either case, are you planning on exporting a backward compatible interface for some time from bytestring? Realize that bytestring comes with GHC, so how long before we're likely to see this blaze-builder in a release? - Mark

On 10 November 2013 23:14, Mark Lentczner wrote:

I spoke too soon:

aeson induces blaze-builder

Note that I removed the blaze-builder requirement from aeson-HEAD (it now uses the Builder from bytestring with a fallback to blaze-builder when configured with -fblaze-builder). I think we're pretty close to a release of aeson-0.7.0.0. It would be great to have this version in the HP since: * It includes an important bug fix for the eitherDecodeStrict functions. * It has support for arbitrary precision floating point numbers (as required by the JSON spec) through the Scientific type. * It removes the ByteString instances since JSON doesn't have support for binary data (this was brought up during the HP inclusion discussion). * It adds ToJSON and FromJSON for Data.Tree. Bas

This is true, and in fact I almost never use dlist myself (or Endo), since lambdas are already quite light weight. However, dlist makes the intention explicit, which is probably a good enough reason to use it in a package in the platform. On Nov 11, 2013 10:20 AM, "Dag Odenhall" wrote:

Wouldn’t it be trivial to get rid of the dlist dependency using Endoinstead, too? It seems to only be an implementation detail. On the other hand, maybe dlist in Platform makes sense anyway.

On Mon, Nov 11, 2013 at 11:07 AM, Bas van Dijk wrote:

...

On 10 November 2013 23:14, Mark Lentczner wrote:

...

I spoke too soon:

aeson induces blaze-builder

Note that I removed the blaze-builder requirement from aeson-HEAD (it now uses the Builder from bytestring with a fallback to blaze-builder when configured with -fblaze-builder).

I think we're pretty close to a release of aeson-0.7.0.0. It would be great to have this version in the HP since:

* It includes an important bug fix for the eitherDecodeStrict functions.

* It has support for arbitrary precision floating point numbers (as required by the JSON spec) through the Scientific type.

* It removes the ByteString instances since JSON doesn't have support for binary data (this was brought up during the HP inclusion discussion).

* It adds ToJSON and FromJSON for Data.Tree.

Bas _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 13 Nov 2013 20:33, "Mark Lentczner" wrote:

I'd like to better understand the backwards compatibility of these

On Mon, Nov 11, 2013 at 2:07 AM, Bas van Dijk wrote:

...

Note that I removed the blaze-builder requirement from aeson-HEAD (it now uses the Builder from bytestring with a fallback to blaze-builder when configured with -fblaze-builder).

Which we'd have to do for this HP, as the bytestring package is 0.10.0.2 from the GHC release. Hence, the blaze-builder requirement would still be

changes, and this new major bump of aeson: My idea for the new major release aeson-0.7 was that it would be included in the next HP and introduce breaking changes but that it would significantly stabilize after this. I would prefer this over first including and old release and then later including a breaking release since I would like the HP to be as stable as possible. there. It seems bytestring-0.10.0.2 provides a Builder: http://hackage.haskell.org/package/bytestring-0.10.0.2

...

I think we're pretty close to a release of aeson-0.7.0.0. It would be great to have this version in the HP since:

I'm concerned about timing. In particular, how long should a new major version bump release be out before one is confident that it won't need a minor rev. (0.7.0.1) soon?

...

* It includes an important bug fix for the eitherDecodeStrict functions

Well, that seems good. Could that get back ported on top of 0.6.2.1 if we decided to not do a major bump this time?

...

* It has support for arbitrary precision floating point numbers (as

required by the JSON spec) through the Scientific type.

Well, one can argue if that is what the spec says - but in practice, JSON

Those issues aside, how does the API evolve? What is the plan for introducing this functionality without breaking existing aeson relying code? aeson's Number constructor points to Number from attoparsec which has only two constructors: I Integer and D Double. Wouldn't introducing a

That won't be difficult. libraries in other systems don't use arbitrary precision floating point (nor does any JavaScript implementation that I know of). True. However, users also might want to send arbitrary precision numbers as JSON between two Haskell systems using aeson. Also the Scientific type proved to be more efficient to parse. third, or replacing D, break existing uses of aeson? aeson-0.7 will break code that is directly constructing or analyzing the Number type from the Number constructor from the Value type since that will change to the Scientific number type. I expect that there isn't that many code like that since for decoding or encoding directly to standard numeric types users are probably using the provided FromJSON and ToJSON instances which will keep working as they were. For users that do need to use the Number constructor from the Value type they can still use the (deprecated) withNumber function for parsing. For construction I expect most of these users to use the standard numeric conversion functions like fromInteger, fromIntegral or realToFrac which should work unmodified for Scientific values.

...

* It removes the ByteString instances since JSON doesn't have support for binary data (this was brought up during the HP inclusion discussion).

Do we have any usage stats to know if any code uses this show instance?

No we don't and I agree this would be useful to have but probably hard the obtain.

Again, trying to avoid breaking compiling code. Were deprecation notices added to the package at some point?

I don't think you can add deprecation pragma's to instances which is unfortunate. Thanks for doing this due diligence Mark! Bas

On 10 November 2013 22:40, Mark Lentczner wrote:

Including aeson, which I think we'd all very much like to do, requires dlist-0.5. Now, dlist has been around for a very long time, and is very stable. I do not believe that dlist's API is exposed indirectly via aeson at all.

I hereby propose that it be added to the platform. At the very least, it could be like primitive - in the platform, but not "part" of it.

Thoughts?

+1 However, note that I don't mind dropping the dlist dependency from aeson. I use it in a very limited internal place: https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Generic.hs#L213 Don, If we do decide to include dlist in the HP it would be great if the following instances can be added to it: instance Alternative DList where empty = empty (<|>) = append instance Eq a => Eq (DList a) where (==) = (==) `on` toList instance Ord a => Ord (DList a) where compare = compare `on` toList instance Show a => Show (DList a) where showsPrec p dl = showParen (p >= 10) $ showString "Data.DList.fromList " . shows (toList dl) Bas

On 12 November 2013 11:47, Sean Leather wrote:

Assuming Don is willing and others agree, I don't mind taking over maintenance of dlist. I just imported it into GitHub: https://github.com/spl/dlist

Thanks for maintaining it!

Bas: please submit a pull request with the suggested changes. They all look good.

Done: https://github.com/spl/dlist/pull/1 Bas

On 13 Nov 2013 18:53, "Joachim Breitner" wrote:

Hi,

Am Dienstag, den 12.11.2013, 09:26 +0100 schrieb Bas van Dijk:

...

On 10 November 2013 22:40, Mark Lentczner

wrote:

...

...

Including aeson, which I think we'd all very much like to do, requires dlist-0.5. Now, dlist has been around for a very long time, and is very stable. I do not believe that dlist's API is exposed indirectly via aeson at all.

I hereby propose that it be added to the platform. At the very least, it could be like primitive - in the platform, but not "part" of it.

Thoughts?

+1

However, note that I don't mind dropping the dlist dependency from aeson. I use it in a very limited internal place:

https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Generic.hs#L213

while dlist is certainly a nice and stable library, it is still relatively specialized, and I would personally not consider it important enough to be included in the platform. I’d like the platform to stay a selection of packages that people not only can use, but really should know about, and use them instead of rolling their own. I’m not sure if this holds for dlist – using [a] -> [a] and (.) directly is also good practice.

Hi Joachim, I would call using [a] -> [a] and (.): "rolling your own" and I consider it bad practise. Code would be easier to understand if it used common names.

My suggestion is to remove it from aeson, and keep the platform small and focused.

I think its best if I remove dlist from aeson and that we discuss its inclusion into the HP (after next) in a separate proposal. Sean: care to lead the proposal? Bas

[taking this off the platform mailing list] Hi, Am Mittwoch, den 13.11.2013, 19:10 +0100 schrieb Bas van Dijk:

I would call using [a] -> [a] and (.): "rolling your own" and I consider it bad practise. Code would be easier to understand if it used common names.

I’m not sure; there is a concept behind it that applied to other data types as well, e.g. trees, possibly defined by the user. Having people knowledgeable about [a] -> [a] will enable them to apply the same pattern to their own data types. If [a] -> [a] were bad practice, then base should stop using it¹, and Data.DList should become part of base. (This is not a strawman argument: If people support this then sure, why not). One main advantage of dlist if of course that it comes with instances (Monad, Functor, etc.) Greetings, Joachim ¹ http://hackage.haskell.org/package/base-4.6.0.1/docs/Prelude.html#t:ShowS -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

Re dlist The platform hasn't been aiming for "small and focused" for quite some time. And last year I called for a significant expansion of the palatform, and this was met with general enthusiasm. The original motto for the platform: "batteries included" is still apt. We want to the platform to provide, out-of-the-box, a broad selection of packages for common computing needs, where these packages can be counted on to be there, to be stable, and be a reasonable default choice - and hence worth learning and keeping in your toolbox. Not every package has to be "the only best way" to do some task - Python includes a default HTTP server, but there are plenty of others out there, and good reasons to choose them. We want packages to be the reasonable default to turn to, when the choice doesn't warrant researching through alternative packages on hackage, or soliciting opinions on IRC. Of course, the transitive nature of packages in the platform means that sometime we have things in there that don't quite live up to those goals. primitive is in the platform because vector needs it... but it isn't quite a common computing need. Dlist probably wouldn't have made it in on it's own merits - but it isn't bad, and certainly a reasonable way to do what it does if that is what you need and just want to get on with whatever else your doing. (perhaps our motto should be "less yak-shaving"!) Since the use of Dlist isn't exposed in aeson's interface , it could go either way. But I think it would be reasonable to include. - Mark

On Mon, Nov 11, 2013 at 3:34 AM, Joachim Breitner wrote:

I’d feel more comfortable with this boot-library version deviation if someone who knows the interaction of GHC (the compiler), ghc (the librarY) and Cabal better can comment on it.

I can't say I know the full details of the interactions, but the Cabal library is essentially the only bootlib that not only can safely (I don't think I've ever heard of anyone getting into trouble) be upgraded, but often is *recommended* for upgrade to support newer cabal-install. I think this is because ghc only uses a small portion of it that has been stable for a long time (avoiding data incompatibility) and it's compiled in (so no link time strangeness). The only issues that come to mind would be if someone were to write TH that itself explicitly called out to Cabal, or maybe some complex ghc-as-a-library stuff in a program explicitly using Cabal itself. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Tue, Nov 12, 2013 at 12:21 AM, Ganesh Sittampalam wrote:

FYI I've just uploaded HTTP 4000.2.9 which just has some dependency bumps.

Okay, I'll bump to this version.