Re: HP 2015.2.0.0 and GHC 7.10
On 03/28/2015 04:27 PM, Randy Polen wrote: Mateusz, Haddock issue #285 indeed sounds like a win (or Win-dows). A logistical wrinkle I worry about for the short-term is that the HP uses the GHC release, and haddock is part of that release. I can certainly incorporate a newer haddock, but I want to mention this GHC-related release issue in case others here have a better approach for this part of the plan (e.g., yes, go ahead and augment GHC 7.10.1 release with a custom haddock or no, let's spin up a 7.10.1.1 (?)). There is also the Cabal piece as well, but that is separate from GHC and thus a bit easier to incorporate into the HP build. Randy We cut a Haddock release when GHC comes out so that it's easy to track versions but that's simply to try to keep some sanity when users report --version. But there is nothing stopping us from releasing a new Haddock version without forcing a GHC release. If I release 2.16.1 tomorrow with the argument list thing, you can just cabal install install it. As long as your system knows to look into binaries built through cabal first and binaries shipped with GHC second, you'll be golden. For HP purposes, you probably want to ship 2.16.1 (or whatever version) when that comes out because tools like cabal-install depend on the version number to determine what features (such as response files) are available. I don't have a date for next point release. Do you have a date for HP? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
With the advent of efficient build tools, would it be too outrageous to suggest we start to move to automated HP releases on an even faster (but rigid) schedule, e.g. weekly, or monthly? As new versions of libraries come out, they could be incorporated in the platform as soon as they are verified to build successfully with the other dependencies, and the next weekly/monthly bundle would have it. Then there would always be a recent Platform good enough for even the bleeding-edge types of users. It would eliminate the rush of please can we hold off until foo is released in a few days time requests, which has tended to cause schedule-drift in the past. Continuous integration FTW! Regards, Malcolm On 28 Mar 2015, at 02:58, Gershom B wrote: On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentcz...@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 ___ Libraries mailing list librar...@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
RE: HP 2015.2.0.0 and GHC 7.10
Mateusz, Haddock issue #285 indeed sounds like a win (or Win-dows). A logistical wrinkle I worry about for the short-term is that the HP uses the GHC release, and haddock is part of that release. I can certainly incorporate a newer haddock, but I want to mention this GHC-related release issue in case others here have a better approach for this part of the plan (e.g., yes, go ahead and augment GHC 7.10.1 release with a custom haddock or no, let's spin up a 7.10.1.1 (?)). There is also the Cabal piece as well, but that is separate from GHC and thus a bit easier to incorporate into the HP build. Randy Date: Sat, 28 Mar 2015 15:12:34 + From: fuuze...@fuuzetsu.co.uk To: ghc-devs@haskell.org Subject: Re: HP 2015.2.0.0 and GHC 7.10 On 03/27/2015 05:16 PM, Randy Polen wrote: I am helping Mark with the Haskell Platform, doing the Windows builds (32- and 64-bit). I want you to be aware of a problem I am encountering, and solicit suggestions and possible help. In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit yet but likely the same problem will occur), I seem to be hitting the 32K limit for the length of arguments to a process, encountered while cabal is invoking haddock to build the docs for the OpenGLRaw package. For HP2014.2.0.0, the argument list was ~25K (from looking at my old build logs) but now is ~36K, which exceeds the maximum for CreateProcess (not a limit of the command-line, but of the OS call itself). Is there a way to build haddock docs for a single package but in multiple haddock invocations (maybe building a .haddock file for portions, then combining them, with the goal that the command line is kept short)? Seems this would also require a corresponding cabal change, as cabal is the invocator when this happens. Barring any existing mechanism, the typical solution to this problem on the Windows OS is (when possible, of course) to modify the program to accept a response file of command-line arguments. In this case, we could add an option to haddock to accept either a complete response file (i.e., allowing *all* options and arguments to come from a file) or just a file containing the files to process. Either of these changes to haddock are rather trivial to write (but adding another option implies more testing, documentation, other cases to handle, etc.). Since haddock ships with the ghc release, that's another wrinkle for this particular release. The other implication of such a solution is that cabal would need a change to utilize this change for it to be effective, checking haddock's version for support of this new haddock-flag, and either use it if the haddock version supports it, or do it optionally (which implies a new flag for cabal's haddock sub-command). This change to cabal is also rather trivial to implement (this is not to imply insensitivity to the incurred cost of each line of code, nor to the added burden of user-visible changes such as a command-line option). (Less desirable possibilities, mentioned only for completeness: skip the documentation for OpenGLRaw for this version of the Haskell Platform; split up the OpenGLRaw package itself in some way.) Other possible solutions and work-arounds? Thoughts on either using haddock in a different way (and the cabal change that would be required to break up the doc build into multiple steps for a single package)? Thoughts on the response file solution? Hi Randy, We actually have an issue about response files already[1], I just haven't gotten around to doing it. When I looked into it last, cabal folks were willing to support it too so there should be no problem on that end. All that remains is that we write code for it in Haddock and for cabal and GHC to adapt. I can implement this in Haddock even today and you can cherry-pick a patch onto whatever you're working with. Is that satisfactory? [1]: https://github.com/haskell/haddock/issues/285 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On Wed, Mar 25, 2015 at 1:02 AM, Sven Panne svenpa...@gmail.com wrote: A +1 for including exceptions, but why version 0.6.1, which is quite old? I would propose including the latest and greatest 0.8.0.2 version. Ah - because gci 3001.2.2.0 has a bound on exceptions 0.7. John Chee: I don't want to ship an old exceptions. Can update cgi or shall we keep cgi out this time 'round? - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On Sat, Mar 28, 2015 at 10:28 AM, John Alfred Nathanael Chee cheech...@gmail.com wrote: Mark: I'm bumping the dependency on exceptions now. I'll post back before noon PDT if I get a release out. Rockin'! All: I appreciate the crazy weekend scramble! Alas, for me during the week I'm swamped with work (a good thing - it means my project there is going very well!) If this sync'ing with GHC releases path is well received, then next time we'll have a bit more (~1 month) runway! - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
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? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
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 george.colpi...@gmail.com 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 mark.lentcz...@gmail.com 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
HP 2015.2.0.0 and GHC 7.10
I am helping Mark with the Haskell Platform, doing the Windows builds (32- and 64-bit). I want you to be aware of a problem I am encountering, and solicit suggestions and possible help. In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit yet but likely the same problem will occur), I seem to be hitting the 32K limit for the length of arguments to a process, encountered while cabal is invoking haddock to build the docs for the OpenGLRaw package. For HP2014.2.0.0, the argument list was ~25K (from looking at my old build logs) but now is ~36K, which exceeds the maximum for CreateProcess (not a limit of the command-line, but of the OS call itself). Is there a way to build haddock docs for a single package but in multiple haddock invocations (maybe building a .haddock file for portions, then combining them, with the goal that the command line is kept short)? Seems this would also require a corresponding cabal change, as cabal is the invocator when this happens. Barring any existing mechanism, the typical solution to this problem on the Windows OS is (when possible, of course) to modify the program to accept a response file of command-line arguments. In this case, we could add an option to haddock to accept either a complete response file (i.e., allowing *all* options and arguments to come from a file) or just a file containing the files to process. Either of these changes to haddock are rather trivial to write (but adding another option implies more testing, documentation, other cases to handle, etc.). Since haddock ships with the ghc release, that's another wrinkle for this particular release. The other implication of such a solution is that cabal would need a change to utilize this change for it to be effective, checking haddock's version for support of this new haddock-flag, and either use it if the haddock version supports it, or do it optionally (which implies a new flag for cabal's haddock sub-command). This change to cabal is also rather trivial to implement (this is not to imply insensitivity to the incurred cost of each line of code, nor to the added burden of user-visible changes such as a command-line option). (Less desirable possibilities, mentioned only for completeness: skip the documentation for OpenGLRaw for this version of the Haskell Platform; split up the OpenGLRaw package itself in some way.) Other possible solutions and work-arounds? Thoughts on either using haddock in a different way (and the cabal change that would be required to break up the doc build into multiple steps for a single package)? Thoughts on the response file solution? Randy ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
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 mark.lentcz...@gmail.com 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 librar...@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
Re: HP 2015.2.0.0 and GHC 7.10
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 ekm...@gmail.com 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 mark.lentcz...@gmail.com 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 librar...@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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald carter.schonw...@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
Re: HP 2015.2.0.0 and GHC 7.10
On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentcz...@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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
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 mark.lentcz...@gmail.com wrote: On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald carter.schonw...@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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On Mon, Mar 23, 2015 at 7:58 AM, Carter Schonwald carter.schonw...@gmail.com wrote: How do you get the ghc docs built successfully on os x? I've tried to replicate you buildsteps but docbook hits a failure when tryingto download some remote file. I added my OS X build notes for GHC https://github.com/haskell/haskell-platform/blob/pre-release/notes/building-ghc-os-x to the Platform repo. Enjoy! - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
*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/Releases2015.hs 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 mark.lentcz...@gmail.com 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
Re: HP 2015.2.0.0 and GHC 7.10
2015-03-25 7:31 GMT+01:00 Mark Lentczner mark.lentcz...@gmail.com: [...] look over the the source file at GitHub that defines the release see if the version of your stuff looks right The OpenGLRaw and GLUTRaw versions are OK, for OpenGL and GLUT we should use newer versions I just released (OpenGL-2.12.0.0 and GLUT-2.7.0.0). These contain much requested API additions/generalizations. Furthermore, due to other popular requests like generalizing things and making OpenAL stuff independent from OpenGL, I split off improved StateVar (thanks to Edward Kmett!) and ObjectName packages again, which are now additional dependencies. This move was made in spite of all those bikeshedding discussions around them, because several actual package users requested them. (Listen to your customers!) I simply don't want to be held back by eternal theoretical discussions anymore, instead let's ship what people actually want. [...] look near the end where there is a bunch of stuff I kinda just added to get it all to compile [...] As mentioned above, we need StateVar-1.1.0.0 and ObjectName-1.1.0.0 now, too. A +1 for including exceptions, but why version 0.6.1, which is quite old? I would propose including the latest and greatest 0.8.0.2 version. rantRegarding the random packages: Shipping 2 packages for basically the same thing is silly IMHO and a bad sign for something which claims to be a coherent set of APIs. Either these packages should be merged or the dependencies adapted. Offering choice for the same task has no place in the platform IMHO, we should ship what is considered the best/most widely used for each area. For the more arcane needs, there's always Hackage.../rant ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
cabal-install should be 1.22.2.0 (latest). Otherwise looks good. On Mar 25, 2015 7:32 AM, Mark Lentczner mark.lentcz...@gmail.com 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/Releases2015.hs 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 mark.lentcz...@gmail.com 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On Mon, Mar 23, 2015 at 4:35 AM, Sven Panne svenpa...@gmail.com wrote: 2015-03-23 6:13 GMT+01:00 Mark Lentczner mark.lentcz...@gmail.com: [...] 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
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 mark.lentcz...@gmail.com 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
Hi Austin, Can you add Mark’s OS X bindists to https://downloads.haskell.org/~ghc/, please? 7.10.1-rc2: http://www.ozonehouse.com/mark/platform/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 (404) https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 (my mirror) 7.10.1-rc3: http://www.ozonehouse.com/mark/platform/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 (my mirror) -- Miëtek https://mietek.io On 2015-03-23, at 12:22, Miëtek Bak mie...@bak.io wrote: Thanks, Mark. Could you restore the OS X GHC 7.10.1-rc2 bindist? It was available at: http://www.ozonehouse.com/mark/platform/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 I have it mirrored and CDN-ified at: https://s3.halcyon.sh/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 -- Miëtek https://mietek.io On 2015-03-23, at 05:13, Mark Lentczner mark.lentcz...@gmail.com 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, and the OS X builds are at my usual platform staging area: Index of /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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs smime.p7s Description: S/MIME cryptographic signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
Hey mark, How do you get the ghc docs built successfully on os x? I've tried to replicate you buildsteps but docbook hits a failure when tryingto download some remote file. Many thanks On Mar 22, 2015 10:13 PM, Mark Lentczner mark.lentcz...@gmail.com 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
I’m asking because until these archives appear on haskell.org, your server is the closest to a canonical location. Halcyon references the canonical locations of GHC and cabal-install archives, in case a cautious user doesn’t want to use the builds I’ve prepared: https://github.com/mietek/halcyon/blob/master/src/ghc.sh#L175 -- Miëtek https://mietek.io On 2015-03-23, at 14:24, Mark Lentczner mark.lentcz...@gmail.com wrote: 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 smime.p7s Description: S/MIME cryptographic signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On Mon, Mar 23, 2015 at 5:22 AM, Miëtek Bak mie...@bak.io 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
