On Mon, Mar 23, 2015 at 4:35 AM, Sven Panne wrote:

2015-03-23 6:13 GMT+01:00 Mark Lentczner :

...

[...] exceptions & multipart - needed by cgi - is exceptions now subsumed by something in transformers? [...]

Coincidentally, Edward Kmett pointed me to the exceptions package while I was trying to generalize some of my packages from using plain IO to MonadIO. Alas, the transformers package still doesn't subsume the exceptions package, but IMHO it really should. Looking at the import list of e.g. Control.Monad.Catch alone is already indicating that. :-)

transformers remains rather rigidly locked into Haskell 98/2010. mtl uses comparatively few extensions. exceptions uses rank-3 types in the API, which is something we currently don't do in transformers or the mtl.

BTW: System.Console.Haskeline.MonadException has something similar, but far less complete, too, but that's really a strange place for such a feature. How did it end up there?

Haskeline makes a few weird choices. e.g. The opacity of the InputT type pretty much renders the library very difficult to use the moment you need to do something that the package doesn't anticipate, like work with InputT in a transformer and expect any instances to exist, handle exceptions around _it_ in turn, lift monad transformers over it yourself, etc. =( I have more code for working around this aspect of Haskeline than I do for working with it. But it appears, in this case, Judah needed it for working with InputT, and chose to implement that by lifting transformer-by-transformer, since internally InputT is made by wrapping up an mtl-based type in a newtype. -Edward

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Mon, Mar 23, 2015 at 5:22 AM, Miëtek Bak wrote:

Could you restore the OS X GHC 7.10.1-rc2 bindist?

Didn't think anyone would want it now that we have RC3... I don't have it on the server anymore, but see you have it mirrored. Hashes are: e3d160e853b549cab64726c204655a5979e6c345 ghc/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 dc2526687a51288dcd157be07ee1452ddfe7be34 ghc/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 - Mark

NO MOAR BIKESHEDS! I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do "with and without" releases. Votes? ​

Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another. At the very least, we should try to get that new version of primitive ready for release and onto platform, since it immediately upgrades the power of any package that uses prim monad! On Mar 27, 2015 11:28 AM, "Edward Kmett" wrote:

I'm personally a rather vocal proponent of the new OpenGL API changes.

I'd also in general favor a policy of greater trust when it comes to library authors factoring out bits of their packages even once they become part of the platform. We all want our code to work together.

The hand-wringing we've had over the splitting off of multipart from cgi and ObjectName or StateVar from OpenGL because designers of packages like sdl2 want to be able to support a common API without incurring a needless OpenGL dependency is largely indicative of why some folks get scared of their packages being included in the platform.

And, e.g. aeson's scientific dependency is needed to ensure data going through the API doesn't lose precision, and due to stackage almost everyone has adapted to its presence for over a year. Removing it would do nobody any good. Let's bless it and move on.

-Edward

On Fri, Mar 27, 2015 at 10:41 AM, Mark Lentczner

...

wrote:

...

NO MOAR BIKESHEDS!

I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do "with and without" releases.

Votes? ​

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentczner@gmail.com) wrote:

Is "soon" measured in hours? If not - I suggest that it misses.

I'm pushing that we change how we do this Platform thing - and make it stick, like glue, to the GHC release schedule. Sure, this time 'round we'll be out of sync with those "it's almost there" packages... but next time we'll know it's coming and hopefully, we'll have these panic attacks as GHC is in beta not post-Release.

+1 to this sentiment. Now that we can do efficient platform builds, better to release regularly and efficiently. Otherwise we’ll always be playing catch-up to “one more thing.” -g

Soon is now. I just published primitive-0.6 and vector-0.10.12.3 that increments the version dependency for it. So they can go in if people want. -- Dan On Fri, Mar 27, 2015 at 10:46 PM, Mark Lentczner wrote:

On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another.

Is "soon" measured in hours? If not - I suggest that it misses.

I'm pushing that we change how we do this Platform thing - and make it stick, like glue, to the GHC release schedule. Sure, this time 'round we'll be out of sync with those "it's almost there" packages... but next time we'll know it's coming and hopefully, we'll have these panic attacks as GHC is in beta not post-Release.

- Mark

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

cabal-install should be 1.22.2.0 (latest). Otherwise looks good. On Mar 25, 2015 7:32 AM, "Mark Lentczner" wrote:

*Hey you....* yes you... Platform committee member, or Platform library maintainer, Platform packager... that's right, you:

GHC 7.10 is about to be released. Wouldn't it rock if we came out with a Platform within days? Or on the same day?

I know, I know, our process is long and full of discussion, and hard, and slow.... let's smash that, eh? How'z'bout it?

OKAY? Good! Your task is:

- look over the the source file at GitHub https://github.com/haskell/haskell-platform/blob/pre-release/hptool/src/Rele... that defines the release - see if the version of your stuff looks right - yeah, I bumped it all to latest, major or minor version change - so APIs probably broke from last HP - look near the end where there is a bunch of stuff I kinda just added to get it all to compile - read the notes about those things in the first message of this thread (copied below) - weigh in - short and sweet - if you have an opinion - if you have a spare Mac - download it and try it! http://www.ozonehouse.com/mark/platform/

Crazy, right? I know... but, can we do this?

— Mark

On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner

...

wrote:

...

I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3.

I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues:

- *old-locale and old-time* - no longer part of GHC, but cabal-install, cgi & HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, & HTTP update, not sure what else to do. - *tf-random* - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages - *network-uri *- was split out of network, and needed by cabal-install, cgi, & HTTP. I suppose we should include it, as it was functionality and API that was part of the platform - *exceptions* & *multipart* - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! - *scientific* - needed by attoparsec - debated in detail last time ... and we're still here!

The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M!

If you want to poke at it, the source is in the pre-release branch at GitHub https://github.com/haskell/haskell-platform/tree/pre-release, and the OS X builds are at my usual platform staging area:

Index of /mark/platform http://www.ozonehouse.com/mark/platform/

Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too.

I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death!

- Mark

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

there is a bindist for 7.10 RC3 - right alongside the HP I built. I'm the builder for the bindists for GHC of OS X - not sure why Austin never put it on the GHC site. On Wed, Mar 25, 2015 at 2:51 PM, George Colpitts wrote:

Thanks for doing this, AFAIK there is no bindist for 7.10.3 on the Mac. I downloaded and installed it, works great. I used it to install hlint and criterion. The only issue I saw was that uninstall didn't remove ghc executables of older versions that I had in /usr/local/bin (earlier bindist of 7.10.1rc2). Looking forward to using next version for 7.10.1 final

Thanks again

On Mon, Mar 23, 2015 at 2:13 AM, Mark Lentczner wrote:

...

I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3.

I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues:

- *old-locale and old-time* - no longer part of GHC, but cabal-install, cgi & HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, & HTTP update, not sure what else to do. - *tf-random* - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages - *network-uri *- was split out of network, and needed by cabal-install, cgi, & HTTP. I suppose we should include it, as it was functionality and API that was part of the platform - *exceptions* & *multipart* - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! - *scientific* - needed by attoparsec - debated in detail last time ... and we're still here!

The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M!

If you want to poke at it, the source is in the pre-release branch at GitHub https://github.com/haskell/haskell-platform/tree/pre-release, and the OS X builds are at my usual platform staging area:

Index of /mark/platform http://www.ozonehouse.com/mark/platform/

Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too.

I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death!

- Mark

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs