Re: GHC 7.8 release?
Hi, one remedy to the problem could be better infrastructure: * More automated test-building of packages on hackage (including test suites) with various GHC releases, and better display of the results. This way, library authors would not have to manually build their library to see if they work with the latest compiler. * Automatic test building of packages with explicit relaxation of the dependencies, to suggest dependency relaxation that would work without code changes (from my work at Debian, in most cases only meta-data changes are required to support newer versions of dependencies, including core libs). * A more liberal attitude to changing other peoples packages’s metadata to fix the dependencies – either to exclude broken combinations or to expand the range. Preferably online, similar to the edit button in github, and checked by the above CI infrastructure. This way, it would be easier for libraries to support newer GHC releases without having to give up supporting older releases. But I know that development of Hackage is not something that seems to be happening a lot right now, and as I don’t help, I’m not complaining. So consider this a side notice and carry on discussing :-) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 2:46 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, one remedy to the problem could be better infrastructure: * More automated test-building of packages on hackage (including test suites) with various GHC releases, and better display of the results. This way, library authors would not have to manually build their library to see if they work with the latest compiler. * Automatic test building of packages with explicit relaxation of the dependencies, to suggest dependency relaxation that would work without code changes (from my work at Debian, in most cases only meta-data changes are required to support newer versions of dependencies, including core libs). * A more liberal attitude to changing other peoples packages’s metadata to fix the dependencies – either to exclude broken combinations or to expand the range. Preferably online, similar to the edit button in github, and checked by the above CI infrastructure. This way, it would be easier for libraries to support newer GHC releases without having to give up supporting older releases. But I know that development of Hackage is not something that seems to be happening a lot right now, and as I don’t help, I’m not complaining. So consider this a side notice and carry on discussing :-) Greetings, Joachim The issue is largely social problem that I suspect technological solutions won't solve. Yes, it would be nice to have better infrastructure. However, at the end of the day, when the automated tests say an API or ABI set has been broken, a non-technical decision needs to be taken (should it be part of the next release, or should it be delayed or removed?) And you will be back to square one. Part of the problem is what happens to successful programming languages: you get users, and users -- believe it or not -- like stability (few people like fiddling with function names and arguments in an otherwise working program or library) and, yes they will take new improvements as long as their working programs continue working. Researchers on the other hand need room to experiment with ideas; they need to get their implementations in the wild to get a sense of what scales, what doesn't. These facts are in tension; you can't solve it by more automated testing. If you want GHC to compete with GCC or Clang, then you know what to do: stop experimenting with the language. So far, most of the work on GHC has been done by researchers who are not paid to do development work -- unless academia changes its standards... -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 10:09:56AM +0800, John Lato wrote: What I would like to see are more patch-level bugfix releases. I suspect the reason we don't have more is that making a release is a lot of work. So, Ian, what needs to happen to make more frequent patch releases feasible? Well, * actually making a release takes time * I assume that you also want more patches merged from the HEAD, rather than just putting intermediate releases out, in which case merging those patches also takes time. And most of the small fixes already get merged, so you'd be looking at merging bigger changes which are more likely to require resolving conflicts, and so take even more time so basically to make more releases we'd need to spend less time doing other stuff (or for someone else to look after the branch). Bigger changes, and especially changes that need altering for the stable branch, are also more likely to introduce bugs. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 3:30 PM, Simon Peyton-Jones simo...@microsoft.com wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than compile HEAD gives us. Simon Fitting: http://xkcd.com/1172/ (sorry, I couldn't resist) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: I cannot compile ghc-7.6.2
On Sun, Feb 10, 2013 at 06:35:25PM +0800, Magicloud Magiclouds wrote: Linuxmint Nadia, ghc-7.6.1 was built and running OK. Just downloaded ghc-7.6.2, without changing anything and environment, and boot and configure returned OK, I got these. What happened? /usr/local/bin/ghc -H32m -O --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall \ -DCABAL_VERSION=1,16,0 \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/filepath \ -ilibraries/hpc \ rm -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. libraries/Cabal/Cabal/Distribution/ParseUtils.hs:88:18: Could not find module `Data.Map' It is a member of the hidden package `containers-0.5.0.0'. Use -v to see a list of the files searched for. make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 It looks like there is a problem with your bootstrapping compiler, possibly caused by having more than one copy of containers installed. ghc-pkg check or ghc-pkg list might help. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. These must be social questions (what I was earlier calling “signposting”) rather than technical ones. For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it? They don’t openly insult anyone who points to a release just because HEAD has new cool stuff! No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. Or something. I’m just looking for a way to reconcile ·Release early, release often ·Stability for the Haskell Platform It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now. But maybe I’m wrong. Simon From: Brandon Allbery [mailto:allber...@gmail.com] Sent: 11 February 2013 01:15 To: Simon Peyton-Jones Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kosti...@gmail.com; glasgow-haskell-users; ghc-d...@haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.commailto:allber...@gmail.com ballb...@sinenomine.netmailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi, Am Montag, den 11.02.2013, 22:31 + schrieb Simon Peyton-Jones: No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. wording does indeed help a lot. I remember that 7.2 was dubbed a technology review with the effect that, at least Debian, never included it in the main repository. It was packaged and provided in experimental, for easy access to those who want to play with it, but not with additional library packages. From what I can remember, there was no push towards supporting 7.2 properly, and I believe this would have been different if 7.2 was just “the next regular GHC release”. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Agreed. having relatively bug free technology preview releases, which (perhaps ideally) have new functionality included in a way that keeps the breakage overhead lowish, on a regular basis, is ideal. one thought on the api hacking front: the main concern we're hitting is that we want to not pin internal GHC apis, yet we want to make the breakage rate on libraries people may want to use that might depend on say GHC.Prim or GHC.TH to be minimal. Is a possible solution that on preview releases we have the changed bits of API for a module M to be exported in a module M.Experimental? eg, new ghc primops in a tech preview release maybe are exported by GHC.Prim.Experimental (or something of this sort?) just throwing out one possible point in the design space. cheers -Carter On Mon, Feb 11, 2013 at 5:31 PM, Simon Peyton-Jones simo...@microsoft.comwrote: (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. ** ** These must be *social* questions (what I was earlier calling “signposting”) rather than technical ones. For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it? They don’t openly insult anyone who points to a release just because HEAD has new cool stuff! No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. ** ** Or something. I’m just looking for a way to reconcile **·**Release early, release often **·**Stability for the Haskell Platform It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now. But maybe I’m wrong. ** ** Simon ** ** *From:* Brandon Allbery [mailto:allber...@gmail.com] *Sent:* 11 February 2013 01:15 *To:* Simon Peyton-Jones *Cc:* Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kosti...@gmail.com; glasgow-haskell-users; ghc-d...@haskell.org; Edsko de Vries *Subject:* Re: GHC 7.8 release? ** ** On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones simo...@microsoft.com wrote: What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. ** ** (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. ** ** You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. ** ** -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi, I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? How about aiming for having GHC 7.10 be a release where we only add new stuff and improve old stuff? -- Johan * A major GCC release usually signifies that some large change to the code generator was made. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, 11 Feb 2013 15:03:25 -0800 Johan Tibell johan.tib...@gmail.com wrote: Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Those are very mature platforms, hundreds of millions of people use them indirectly each day, it's hard to compare GHC to them. If anything, Haskell is very young for its age, and should rather move faster. Bad mistakes, accidents and partial or inefficient implementations proliferate in standard libraries for decades, tampering GHC's growth as a serious production language. On Mon, 11 Feb 2013 22:31:53 + Simon Peyton-Jones simo...@microsoft.com wrote: no linux distribution tracks HEAD, does it? Gentoo packages HEAD just fine. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 5:03 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi, I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? How about aiming for having GHC 7.10 be a release where we only add new stuff and improve old stuff? -- Johan * A major GCC release usually signifies that some large change to the code generator was made. I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 6:37 PM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). -- Johan I understand. Concerning GCC, it is true that the shear size of the user base and the audience of the compiler (industrial strength) calls for a very conservative approach to ABI or API breaking. On the hand, that means that there are certain welcomed, beneficial changes that we cannot effect. For example, because libstdc++ has been an early adopter of a reference counted-based implementation of std::string, we could not switch to more efficient and more multithread-friendly implementation. That was has been contributed for years but has been sequestered in some branches and namespaces integrated with the rest of the library. That is a shame, but one that is unavoidable given the expectation of the GCC audience. It is not clear to me that GHC is ready for that kind of constraints. We are still describing the C++11 implementation as experimental because we fear that doing otherwise might commit ourselves to an ABI and API that we may need to break later -- possibly because of undetected bugs or because we have found implementations we like better. Of course, that causes some distress in the community because people would like to say GCC implements C++11. Finally, we do break API, you have just been lucky :-) http://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html But, we have also developed very elaborate scheme for symbol versioning and namespace associations to help users digest API breakages without tears. Symbol versioning is a very messy business. I am still of the opinion that the current issue with GHC and HP is social, and it can be resolved through communication and coordination between the two communities for the great good of the Haskell community. -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Let me strongly support Gaby's many points. Simon has it right: we need a way to support 'users' in a stable way, without adding enormous inertia to the development of GHC. I has lived through the slow death of a system from being rapidly innovative to having 'innovations' which exist only because a marketer says that the raft of boring, incremental improvements in each new release are innovative on some What's New blurb. Haskell is extremely useful, and GHC's flavour of Haskell is quite exciting because of the continual evolution of the language. Please don't kill the excitement! The Platform does seem to be an ideal mechanism to provide stability for users who value stability over bleeding-edge. But for that to be successful, there are to be strong community commitment [especially from library maintainers] to tracking that evolution. If the social mechanisms are not strong enough to fully support the Platform, I would say that that is the most important thing to fix. Jacques ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 7:37 PM, Johan Tibell johan.tib...@gmail.comwrote: Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). gcc has had its moments occasionally, although usually major gcc issues aren't called by gcc itself but by packagers (gcc 2.96, anyone?) or fugly politics (egcs). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Simon Peyton-Jones simo...@microsoft.com: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than compile HEAD gives us. I don't think so. In my experience, library support is not patchy, but virtually non-existent as some of the very widely used libraries (like Text) break, and everything else depends on them in one way or another. If we don't make sure that the commonly used libraries work with these preview releases, I don't think those releases are worth the effort. I understand that we can't really guarantee API backwards compatibility for the GHC API (but that's ok as few packages depend on that). Critical are all the libraries bundled with GHC. Adding to them is fine, but no API definitions should change or be removed. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
