Wither Haskell Platform 2013.4.0.0
Friends — Deep apologies for being so out of touch the last two months(*). In theory, we should be rev'ing up to produce Haskell Platform 2013.4.0.0, but I'd like to explore our options at this time: *1) Proceed as normal:* Such a release would use GHC 7.6.3, as did HP 2013.2.0.0, since that is still the current GHC release. Hence all the core library versions would remain the same, and by my rough eyeballing it, half the platform libraries would remain the same. The only big change might be OpenGL/GLUT libs, which has bumped a major version... though I don't know if that API change is too great or not. Given the time frame, we are unlikely to have any additional packages. This stance brings up the issue that 7.6.3, out of the box, won't work with Xcode 5, and hence the upcoming release of OS X Mavericks (10.9). *2) Delay a month:* This would give us time to consider new packages, which would make the release somewhat more valuable. However, a December release is hard due to holidays, so likelihood would be late December, or January release. *3) Ask GHC Central to produce 7.6.4:* This would incorporate the changes needed work with Xcode 5. This would clearly involve a month delay as in #2. *4) Skip it:* We could just decide that 2013.4.0.0 doesn't offer enough value to run the process now, and simply focus our efforts this cycle on improving the infrastructure that builds HP. Thoughts? I'm particularly interested to hear from HP library maintainers to know if there was/is something important to get out in an HP ASAP. I'd also like to better understand what our Xcode5 options are, and if/how/when we could see the latest cabal in the platform. Again, sorry that this small HP timing crisis is mostly my fault, — Mark (*) At least my excuse is that I was writing music with Haskell for those two months!
On Sun, 13 Oct 2013, Mark Lentczner wrote:
(*) At least my excuse is that I was writing music with Haskell for those two months!
Since I am (still) not using the platform but are interested in Haskell music, I think you set the priorities right. :-) Do you like to share some musical results with us?
On Sun, Oct 13, 2013 at 11:35 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
Do you like to share some musical results with us?
Warning: Minimalist influenced "difficult listening" music for Tesla coil and electric bass... Audio: Plain Changes 2 - all synth mix<https://soundcloud.com/mtnviewmark/plain-changes-2-all-synth-mix> (from my studio) via SoundCloud Audio: Plain Changes 2 - live performance, 20 Sept 2013 (remastered)<https://soundcloud.com/mtnviewmark/plain-changes-2-live-1> from the premier in New Zealand (via SoundCloud) Video: Plain Changes 2 - live performance - YouTube<https://www.youtube.com/watch?v=663vTr8GFx8> from the premier in New Zealand, preliminary video (via YouTube) Code: mzero/PlainChanges2 <https://github.com/mzero/PlainChanges2> (via GitHub) CC & BSD licensed!
On 10/13/2013 03:01 PM, Mark Lentczner wrote:
Code: mzero/PlainChanges2 <https://github.com/mzero/PlainChanges2> (via GitHub)
I tried to install the dependency Euterpea but it wasn't on Hackage and its apparent homepage http://haskell.cs.yale.edu/euterpea/ didn't seem to say how to get it. Mind telling us how to get it? (Also why isn't Euterpea on Hackage?) -Isaac
You'll have to ask the Yale music crowd why it isn't on Hackage.... But, their web site does have a page on how to get it: http://haskell.cs.yale.edu/euterpea/download/ But it basically boils down to getting it from github: https://github.com/Euterpea/Euterpea - If I recall, it has one or two dependencies that didn't build on the latest HP, but just required tweaking of their .cabal files to fix.... Wish I had written that down when I started! - Mark
On 10/13/2013 04:03 PM, Mark Lentczner wrote:
You'll have to ask the Yale music crowd why it isn't on Hackage.... But, their web site does have a page on how to get it: http://haskell.cs.yale.edu/euterpea/download/ But it basically boils down to getting it from github: https://github.com/Euterpea/Euterpea - If I recall, it has one or two dependencies that didn't build on the latest HP, but just required tweaking of their .cabal files to fix.... Wish I had written that down when I started!
Euterpea's Setup.hs imports the local ArrowWrap.hs which requires haskell-src-exts < 1.14.0. Euterpea.cabal specifies haskell-src-exts == 1.13.5, but 'cabal configure' doesn't apply that requirement to compiling Setup.hs. I ran 'cabal install haskell-src-exts-1.13.5' then 'ghc-pkg unregister haskell-src-exts-1.14.0' to fix this, but maybe there's a better way. I didn't have any other trouble building Euterpea or PlainChanges2 (after cabal installing the dependency versions that Euterpea.cabal asks for). Once I built it, this worked for me on my Linux to listen to it: $ ./dist/build/plainchanges2/plainchanges2 midi . $ timidity whole-composed.midi (SoundCloud claims to require Flash, which I avoid installing, so I couldn't listen to it there.) By the way, on https://github.com/mzero/PlainChanges2/blob/master/doc/Building.md the link to Euterpea's website is broken. -Isaac (because I'm interested in computer-generated/mediated sound)
I think this is a good opportunity to change the schedule for all future platform releases. Currently the platform uses a time-based release schedule with two releases each year, but the schedule is out of sync with the rest of the free software community with the result that the haskell-platform package on many Linux distributions typically lags behind one version – and we‘re usually stuck with this outdated version for six months until the cycle repeats itself and we’re stuck with the “new old” version. This in turn results in distributions either opting not to track or ship haskell-platform at all (Arch Linux) or in people installing the packages from the development branch of the distribution (Fedora) which is rather contrary to the stability point of haskell-platform. The obvious solution would be to track a major upstream with time-based releases that isn't a Linux distribution itself. GNOME is a good candidate for this. They typically produce new major versions one or two months before the Linux distributions do, which gives the latter time to package and test it. It would also be good to have time-based release candidates for haskell-platform to make this even smoother, especially since there are much fewer people working on packaging and testing haskell-platform than there is GNOME. The primary audience for haskell-platform might be Windows users and perhaps OS X users, but I think Linux is actually really important to this goal, because a lot of library-producing and support-providing developers use Linux, and currently the attitude seems to be “don‘t use haskell-platform, don’t test your packages against haskell-platform, don‘t advice beginners to use haskell-platform”. It’s just abstractly “there” for “others, unspecified”. But to return to the thread topic: I don‘t really care if there’s a release with GHC 7.6 now or soon, but whatever happens I strongly feel there should be a new haskell-platform with GHC 7.8 *no later than March 2014*, and from then on haskell-platform should continue to track GNOME, more or less. On Sun, Oct 13, 2013 at 8:29 PM, Mark Lentczner <mark.lentczner@gmail.com>wrote:
Friends —
Deep apologies for being so out of touch the last two months(*).
In theory, we should be rev'ing up to produce Haskell Platform 2013.4.0.0, but I'd like to explore our options at this time:
*1) Proceed as normal:* Such a release would use GHC 7.6.3, as did HP 2013.2.0.0, since that is still the current GHC release. Hence all the core library versions would remain the same, and by my rough eyeballing it, half the platform libraries would remain the same. The only big change might be OpenGL/GLUT libs, which has bumped a major version... though I don't know if that API change is too great or not. Given the time frame, we are unlikely to have any additional packages.
This stance brings up the issue that 7.6.3, out of the box, won't work with Xcode 5, and hence the upcoming release of OS X Mavericks (10.9).
*2) Delay a month:* This would give us time to consider new packages, which would make the release somewhat more valuable. However, a December release is hard due to holidays, so likelihood would be late December, or January release.
*3) Ask GHC Central to produce 7.6.4:* This would incorporate the changes needed work with Xcode 5. This would clearly involve a month delay as in #2.
*4) Skip it:* We could just decide that 2013.4.0.0 doesn't offer enough value to run the process now, and simply focus our efforts this cycle on improving the infrastructure that builds HP.
Thoughts? I'm particularly interested to hear from HP library maintainers to know if there was/is something important to get out in an HP ASAP. I'd also like to better understand what our Xcode5 options are, and if/how/when we could see the latest cabal in the platform.
Again, sorry that this small HP timing crisis is mostly my fault,
— Mark
(*) At least my excuse is that I was writing music with Haskell for those two months!
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Sun, Oct 13, 2013 at 10:00:42PM +0200, Dag Odenhall wrote:
The obvious solution would be to track a major upstream with time-based releases that isn't a Linux distribution itself. GNOME is a good candidate for this. They typically produce new major versions one or two months before the Linux distributions do, which gives the latter time to package and test it.
I don't understand the term "before the Linux distributions do". Do all Linux distributions agree on the same release schedule? I doubt so. And there are other operating systems with their completely own (and different) release schedules. For example, in OpenBSD the next release will happen in a little bit more than two weeks, but the versions of all readily built haskell packages for that release had been set in stone more than two months ago. Apart from that, I think neither haskell-platform nor ghc nor anyone else should even *try* to adjust their release schedule in favor of *any* operating system. Because that would introduce additional burdens and pressure on the (relatively small) group of people who are actively working and coordinating on ghc, core libraries, haskell-platform. Those working on Haskell should pick a schedule which they think matches their needs best. Operating system distributors then have to cope with that. If the haskell schedules doesn't fit nicely into a distributros schedule -- mayhbe bad luck, but what's the problem? This is the rule for *any* software project. And end-users always have the choice between using distribution packages or using binaries from haskell.org (well, at least for a few OS platforms) or building everything themselves. Look at debian: I guess a lot of people are using debian-stable, or even old-stable. I'm not sure, but I doubt those are even close to haskell-platform-2013.2.0.0 and/or ghc-7.6.3. (Correct me if I'm wrong)
It would also be good to have time-based release candidates for haskell-platform to make this even smoother, especially since there are much fewer people working on packaging and testing haskell-platform than there is GNOME.
I can only speak for myself, as the OpenBSD maintainer of (most) Haskell packages: I wouldn't have the time to test release candidates. When there's a new release of ghc, I start update the OpenBSD port when I've enough time to do so. And start to update depending libraries. Same for haskell-platform. And if something goes wrong, I just add local patches to our (OpenBSDs) ports. That's a quick&dirty approach, but it's less work (for me *and* Haskell developers) than going through a release candidate phase (and remember: I'm doing this when I have enough spare time, which might be weeks after a release candidate had been published). It would be interesting to hear from other people (like Joachim from Debian) how they deal with this ;-)
The primary audience for haskell-platform might be Windows users and perhaps OS X users, but I think Linux is actually really important to this goal, because a lot of library-producing and support-providing developers use Linux, and currently the attitude seems to be dont use haskell-platform, dont test your packages against haskell-platform, dont advice beginners to use haskell-platform. Its just abstractly there for others, unspecified.
Where are you seeing this attitude? From some mails I got as the OpenBSD Haskell guy I had the impression that there are quite some users who *want* to use haskell-platform, because it's kind of "certified" combination of compiler, tools and libraries. Some users even don't want the latest and greatest haskell-platform, they're just happy with something which isn't completely rotten. For library authors not building/testing against the haskell-platform: well, that's a completely other issue, and I'm not going to blame anyone about it in *this* mail.
But to return to the thread topic: I dont really care if theres a release with GHC 7.6 now or soon, but whatever happens I strongly feel there should be a new haskell-platform with GHC 7.8 *no later than March 2014*,
Why that pressure? Just wait how the new ghc goes, and if it's in a pretty state, update it in haskell-platform. Ciao, Kili -- Personally I learned Unix 22 years ago on a BSD system. I have some expectations of a Unix system based on that experience. When I log into a BSD system, I feel at home. When I log into a typical Linux distro, I feel alienated. -- Otto Moerbeek
On Sun, Oct 13, 2013 at 4:00 PM, Dag Odenhall <dag.odenhall@gmail.com>wrote:
This in turn results in distributions either opting not to track or ship haskell-platform at all (Arch Linux)
Nope. Arch is a rolling release distribution whose policy is directly opposed to the "stable release" philosophy of the Platform. They will package latest versions of everything, not a "stable release". You *cannot* satisfy their requirements with the Platform; ignore them. There are other rolling release distributions out there for which this does not apply, but our schedule is not relevant to them either; they update when we release. This includes MacPorts, Homebrew, BSD ports/pkgsrc, and IIRC Gentoo portage and the pkg repo for Illumos-based distributions. Each has maintainers who will update the relevant ports/ebuilds/etc. (or no maintainers and nothing we do will matter...). Fedora, Mint, Ubuntu, etc. --- the folks who do stable releases on a regular schedule --- are close enough to similar schedules that it is worth trying to synchronize with them. As GNOME has, so watching them probably is a good idea. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that. Back to this release: GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it. SO, back to concrete ideas: *A) Minor release* *• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 *—or—* *B) Delay release* *• New packages:* running the normal process, just a month late *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5 *—or—* *C) Skip a release* *• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP *• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform *• Release in March: *aiming to sync with GNOME, assuming they're on to something! As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell. A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting. B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages. — Mark
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months. -Edward On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner <mark.lentczner@gmail.com>wrote:
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it.
SO, back to concrete ideas:
*A) Minor release*
*• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
*—or—* *B) Delay release*
*• New packages:* running the normal process, just a month late
*• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5
*—or—* *C) Skip a release*
*• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP
*• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform
*• Release in March: *aiming to sync with GNOME, assuming they're on to something!
As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell.
A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting.
B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages.
— Mark
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
I'd also like one of the options that gets us a working Mac platform soon. Given that A involves duplicate work for little benefit (as there weren't many updated packages), it seems to me that option B would be the best. Regards, Erik On Mon, Oct 14, 2013 at 9:52 AM, Edward Kmett <ekmett@gmail.com> wrote:
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months.
-Edward
On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner <mark.lentczner@gmail.com> wrote:
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. [Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]
The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it.
SO, back to concrete ideas:
A) Minor release
• Minor rev: since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. • Bump for Mac: immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
—or— B) Delay release
• New packages: running the normal process, just a month late
• Bump for Mac: get GHC central to put out 7.6.4 which has what is needed to support Xcode 5
—or— C) Skip a release
• Go for 7.8: push everyone (GHC central, library maintainers) to get 7.8 stable ASAP
• Big Push for Packages: use the time to push for a significant increase in the packages in the Platform
• Release in March: aiming to sync with GNOME, assuming they're on to something!
As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell.
A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting.
B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages.
— Mark
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
It's worth noting that it's possible to have a working setup with Xcode 5, it just requires having your own additional build of GCC locally (indeed, that's my current setup), though this will likely have crazy linker errors if I'm not careful :-) when linking a c++ lib built with clang. On Monday, October 14, 2013, Edward Kmett wrote:
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months.
-Edward
On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner <mark.lentczner@gmail.com<javascript:_e({}, 'cvml', 'mark.lentczner@gmail.com');>
wrote:
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it.
SO, back to concrete ideas:
*A) Minor release*
*• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
*—or—* *B) Delay release*
*• New packages:* running the normal process, just a month late
*• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5
*—or—* *C) Skip a release*
*• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP
*• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform
*• Release in March: *aiming to sync with GNOME, assuming they're on to something!
As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell.
A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting.
B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages.
— Mark
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org <javascript:_e({}, 'cvml', 'ghc-devs@haskell.org');> http://www.haskell.org/mailman/listinfo/ghc-devs
I guess my point is there's a number of work arounds that are easy for a power user to support, but should NOT be the default setup or config required for new users. Eg: brew also provides an installer for apple-gcc42 and you could then point your ghc settings file to. That said, it's not a solution we probably want to encourage by default, it definitely took me a while to cook up sane directions, and some of those directions/approaches apparently become useless if you update to OS X 10.9. (I think partly because the default C++ std libs on Mac shift, so you can't easily build GCC on mavericks currently allegedly ) On Monday, October 14, 2013, Edward Kmett wrote:
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months.
-Edward
On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner <mark.lentczner@gmail.com<javascript:_e({}, 'cvml', 'mark.lentczner@gmail.com');>
wrote:
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it.
SO, back to concrete ideas:
*A) Minor release*
*• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
*—or—* *B) Delay release*
*• New packages:* running the normal process, just a month late
*• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5
*—or—* *C) Skip a release*
*• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP
*• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform
*• Release in March: *aiming to sync with GNOME, assuming they're on to something!
As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell.
A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting.
B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages.
— Mark
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org <javascript:_e({}, 'cvml', 'ghc-devs@haskell.org');> http://www.haskell.org/mailman/listinfo/ghc-devs
To briefly explain the issue with Xcode 5 and GHC 7.6.3, as it's really not that big: 7.6.3 passes "-x c" when running the c compiler in preprocessor mode. Clang requires "-x assembler-with-cpp" to be compatible with the GHC codebase. So the workaround Austin Seipp helped me cook up is to simply wrap clang, detect it's being run in preprocessor mode (i.e. look for the args "-E -undef -traditional"), and make sure it gets passed -x assembler-with-cpp. You can see the entirety of it here: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper.... I wrote the workaround as a a Haskell script, but someone with basic bash-fu could easily write it as a shell script. 7.6.3's settings file just has to be pointed at that wrapper instead of directly at clang and then everything works flawlessly with Xcode 5's clang, on 10.8 and 10.9 alike. Cheers Luke On Mon, Oct 14, 2013 at 9:13 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
I guess my point is there's a number of work arounds that are easy for a power user to support, but should NOT be the default setup or config required for new users.
Eg: brew also provides an installer for apple-gcc42 and you could then point your ghc settings file to.
That said, it's not a solution we probably want to encourage by default, it definitely took me a while to cook up sane directions, and some of those directions/approaches apparently become useless if you update to OS X 10.9. (I think partly because the default C++ std libs on Mac shift, so you can't easily build GCC on mavericks currently allegedly )
On Monday, October 14, 2013, Edward Kmett wrote:
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months.
-Edward
On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner <mark.lentczner@gmail.com
wrote:
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it.
SO, back to concrete ideas:
*A) Minor release*
*• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
*—or—* *B) Delay release*
*• New packages:* running the normal process, just a month late
*• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5
*—or—* *C) Skip a release*
*• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP
*• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform
*• Release in March: *aiming to sync with GNOME, assuming they're on to something!
As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell.
A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting.
B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages.
— Mark
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Yes, but it doesn't work for people still using Xcode 4.6! Might it be more correct, albeit hacky aesthetically, to have the clang wrapper actually call GCC, because in Xcode 5 its just a wrapper around clang, and in Xcode 4.6 we need to use GCC rather than clang anyways? That said, that might be the best overall approach. Though it does entail packaging the clang wrapper with ghc / hp for ghc 7.6 on OS X On Monday, October 14, 2013, Luke Iannini wrote:
To briefly explain the issue with Xcode 5 and GHC 7.6.3, as it's really not that big: 7.6.3 passes "-x c" when running the c compiler in preprocessor mode. Clang requires "-x assembler-with-cpp" to be compatible with the GHC codebase.
So the workaround Austin Seipp helped me cook up is to simply wrap clang, detect it's being run in preprocessor mode (i.e. look for the args "-E -undef -traditional"), and make sure it gets passed -x assembler-with-cpp.
You can see the entirety of it here:
https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper....
I wrote the workaround as a a Haskell script, but someone with basic bash-fu could easily write it as a shell script.
7.6.3's settings file just has to be pointed at that wrapper instead of directly at clang and then everything works flawlessly with Xcode 5's clang, on 10.8 and 10.9 alike.
Cheers Luke
On Mon, Oct 14, 2013 at 9:13 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
I guess my point is there's a number of work arounds that are easy for a power user to support, but should NOT be the default setup or config required for new users.
Eg: brew also provides an installer for apple-gcc42 and you could then point your ghc settings file to.
That said, it's not a solution we probably want to encourage by default, it definitely took me a while to cook up sane directions, and some of those directions/approaches apparently become useless if you update to OS X 10.9. (I think partly because the default C++ std libs on Mac shift, so you can't easily build GCC on mavericks currently allegedly )
On Monday, October 14, 2013, Edward Kmett wrote:
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months.
-Edward
On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner <mark.lentczner@gmail.com>wrote:
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it.
SO, back to concrete ideas:
*A) Minor release*
*• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
*—or—* *B) Delay release*
*• New packages:* running the normal process, just a month late
*• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5
*—or—* *C) Skip a release*
*• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP
*• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform
On Mon, Oct 14, 2013 at 1:14 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
Yes, but it doesn't work for people still using Xcode 4.6!
Surely in the wrapper we can detect if we are on Xcode 4 or 5, and only alter the args if on 5? Preferably in a /bin/sh (not bash) script - which I can do I think. - Mark
Okay, now I'm confused.... What change did we think we need for a GHC 7.6.4 to support Xcode 5? Was it just this change to fiddle with the command line options? - Mark
Hi,
What change did we think we need for a GHC 7.6.4 to support Xcode 5? Was it just this change to fiddle with the command line options?
I don't know what is the best. But here is what I know now: clang-xcode5-wrapper.hs (*1) works as a wrapper in many cases so far. We need to change the value of "C compiler command" in settings(*2). Unfortunately, in some commands, hsc2hs for instance, the command name "gcc" is hard coded. So, clang-xcode5-wrapper.hs should be installed as "gcc". This "gcc" should have higher priority than /usr/bin/gcc in PATH. One concern is that users would get troubles with this new gcc. (*1) https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper.... (*2) /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/settings --Kazu
On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery <allbery.b@gmail.com> wrote: Nope. Arch is a rolling release distribution whose policy is directly
opposed to the "stable release" philosophy of the Platform. They will package latest versions of everything, not a "stable release". You *cannot* satisfy their requirements with the Platform; ignore them.
I would say it depends on what you mean by “latest”, since one answer could be “latest haskell-platform”. Does Arch Linux ship the latest Python packages, even if an older version is included in the stdlib of the latest Python release?
On Monday, October 14, 2013, Dag Odenhall wrote:
On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery <allbery.b@gmail.com<javascript:_e({}, 'cvml', 'allbery.b@gmail.com');>> wrote:
Nope. Arch is a rolling release distribution whose policy is directly
opposed to the "stable release" philosophy of the Platform. They will package latest versions of everything, not a "stable release". You *cannot* satisfy their requirements with the Platform; ignore them.
I would say it depends on what you mean by “latest”, since one answer could be “latest haskell-platform”. Does Arch Linux ship the latest Python packages, even if an older version is included in the stdlib of the latest Python release?
There isn't a separate "Python" and "Python Platform". Packages that ship with Python are maintained in Python's repository. Those that are also maintained separately usually have another package/module name altogether so both can be installed without interfering with one another. -bob
good to know! (i'm out of date on my python knowledge) I think we're getting pretty far afield. speaking as someone who's played "OS X support guru/*grunt*" for people dealing with GHC 7.6 + xcode 5 quite a bit for the past 2-5 months, I don't care about what the release is, as long as we clearly communicate to people 1) xcode 5 + ghc 7.6.3 have issues which require menial intervention and following directions to fix (I even sent out an email giving direction http://www.haskell.org/pipermail/haskell-cafe/2013-September/110320.html ). The directions i listed don't cover every *correct* way to work around the issues, they merely list the solutions that are easy to communicate and follow. 2) how to cope while we get a patched ghc/HP ready (by following directions) 3) get a patched GHC/HP out. nearly every day I'm helping someone on IRC deal with this issue, and I strongly suspect that thats the tip of the iceberg. We need to have clear information / warning to people who are installing 7.6 ghc or current haskell platform on OS X about this issue, if we fail to make information about these issues available to new users, some will just give up on bizarre CPP errors and move on. Which i consider unacceptable :) I don't care what solution we do, just that we fix this issue proactively. while we prep to sort this out, can we at least more clearly link to this issues information on the GHC / HP download pages? I'm really really really really tired of playing support on this issue after a few months of it.... it stopped being fun a month ago when it started happening to people who can't patch their own GHC. We need to deal with this. Also i'm a bit buried with my own stuff this month so i'm worried some people wont' get helped! -Carter On Mon, Oct 14, 2013 at 2:55 AM, Bob Ippolito <bob@redivi.com> wrote:
On Monday, October 14, 2013, Dag Odenhall wrote:
On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery <allbery.b@gmail.com> wrote:
Nope. Arch is a rolling release distribution whose policy is directly
opposed to the "stable release" philosophy of the Platform. They will package latest versions of everything, not a "stable release". You *cannot* satisfy their requirements with the Platform; ignore them.
I would say it depends on what you mean by “latest”, since one answer could be “latest haskell-platform”. Does Arch Linux ship the latest Python packages, even if an older version is included in the stdlib of the latest Python release?
There isn't a separate "Python" and "Python Platform". Packages that ship with Python are maintained in Python's repository. Those that are also maintained separately usually have another package/module name altogether so both can be installed without interfering with one another.
-bob
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
I think making the HP release cycle purely time-based is not the best option. For a large amount of users, the HP and what comes with it (including the associated compiler) is what "Haskell" is. If something does not work with the HP, then Haskell does not work. - Support for the latest OS is crucial, probably most importantly to avoid bad publicity. "Hard to install" is an image that's not easily changed when search engines are full of hacks that make it somehow work again. - Are there significant changes in the HP libraries compared to the last release? Is there a good reason to make people update to the latest packages? - In the light of the AMP, I think a relatively early adoption of 7.8 would be very beneficial in order to prepare Hackage. Releasing this year with 7.8 would not be a good idea, but maybe next spring (which would be halfway between the usual HP release dates) is possible? In short, my vote is "delay until it works with all OS and 7.8". David
with all due respect, we can't delay a HP release this fall, we need one that works with OS 10.9 Mavericks / Xcode 5 this fall. as Austin has opined, the right way to do this is to have a bug fix release for 7.6 this fall that addresses the OS X issues. -- Carter Schonwald On October 13, 2013 at 4:22:34 PM, David Luposchainsky (dluposchainsky@googlemail.com) wrote: I think making the HP release cycle purely time-based is not the best option. For a large amount of users, the HP and what comes with it (including the associated compiler) is what "Haskell" is. If something does not work with the HP, then Haskell does not work. - Support for the latest OS is crucial, probably most importantly to avoid bad publicity. "Hard to install" is an image that's not easily changed when search engines are full of hacks that make it somehow work again. - Are there significant changes in the HP libraries compared to the last release? Is there a good reason to make people update to the latest packages? - In the light of the AMP, I think a relatively early adoption of 7.8 would be very beneficial in order to prepare Hackage. Releasing this year with 7.8 would not be a good idea, but maybe next spring (which would be halfway between the usual HP release dates) is possible? In short, my vote is "delay until it works with all OS and 7.8". David _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On 2013-10-13 22:31, Carter Schonwald wrote:
with all due respect, we can't delay a HP release this fall, we need one that works with OS 10.9 Mavericks / Xcode 5 this fall.
I didn't know that the "upcoming" release was that close. In that case I agree that fixing these issues is more important than shipping 7.8. David
On Sun, Oct 13, 2013 at 1:22 PM, David Luposchainsky < dluposchainsky@googlemail.com> wrote:
In short, my vote is "delay until it works with all OS and 7.8".
Agreed. An important idea behind the original scheduling of the HP releases is that the dust should settle from the the latest GHC release before shipping an HP that uses it. The HP is about stability and reliability, not latest and greatest. That means I don't use the HP, but that's okay with me because I've already agreed to pay the early adopter's tax. Jason
On 14 October 2013 05:29, Mark Lentczner <mark.lentczner@gmail.com> wrote:
Friends —
Deep apologies for being so out of touch the last two months(*).
In theory, we should be rev'ing up to produce Haskell Platform 2013.4.0.0, but I'd like to explore our options at this time:
1) Proceed as normal: Such a release would use GHC 7.6.3, as did HP 2013.2.0.0, since that is still the current GHC release. Hence all the core library versions would remain the same, and by my rough eyeballing it, half the platform libraries would remain the same. The only big change might be OpenGL/GLUT libs, which has bumped a major version... though I don't know if that API change is too great or not. Given the time frame, we are unlikely to have any additional packages.
This stance brings up the issue that 7.6.3, out of the box, won't work with Xcode 5, and hence the upcoming release of OS X Mavericks (10.9).
2) Delay a month: This would give us time to consider new packages, which would make the release somewhat more valuable. However, a December release is hard due to holidays, so likelihood would be late December, or January release.
As the maintainer of FGL, I'd be interested in doing a new release with "real" Show and Read instances, etc. if I know when I'd need to have it done by.
3) Ask GHC Central to produce 7.6.4: This would incorporate the changes needed work with Xcode 5. This would clearly involve a month delay as in #2.
4) Skip it: We could just decide that 2013.4.0.0 doesn't offer enough value to run the process now, and simply focus our efforts this cycle on improving the infrastructure that builds HP.
Thoughts? I'm particularly interested to hear from HP library maintainers to know if there was/is something important to get out in an HP ASAP. I'd also like to better understand what our Xcode5 options are, and if/how/when we could see the latest cabal in the platform.
Again, sorry that this small HP timing crisis is mostly my fault,
— Mark
(*) At least my excuse is that I was writing music with Haskell for those two months!
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
participants (15)
-
Bob Ippolito -
Brandon Allbery -
Carter Schonwald -
Dag Odenhall -
David Luposchainsky -
Edward Kmett -
Erik Hesselink -
Henning Thielemann -
Isaac Dupree -
Ivan Lazar Miljenovic -
Jason Dagit -
Kazu Yamamoto -
Luke Iannini -
Mark Lentczner -
Matthias Kilian