Re: Offering GHC builder build slaves
On 04/ 9/14 03:41 AM, Alain O'Dea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-04-08 08:17 PM, Karel Gardas wrote: On 04/ 8/14 03:16 PM, Alain O'Dea wrote: The two build slaves I intend to run are: - x86_64 Solaris (on SmartOS) Please name it smartos-x86 then. I'm running real Solaris 11.1 as a builder here so let's make it different name builder and see if there are any incompatibilities between those two (I hope still very close) platforms. BTW: what's your platform triple detected by config.guess? Thanks! Karel Hi Karel, My platform triple detected by config.guess is: x86_64-unknown-solaris2 I got that by running `cat config.status | grep TargetPlatformFull`. Hi Alain, hmm, that's after GHC own platform processing is done, but what does sh config.guess tells you? E.g. on my two Solaris 11 I get: $ sh config.guess i386-pc-solaris2.11 $ sh config.guess sparc-sun-solaris2.11 BTW: also if you are building GHC on AMD64/Solaris/err/SmartOS, then I think Christian (cced) may be interested as he is currently working on cross-compiling from i386/Solaris to AMD64/Solaris and he is hit by some bugs along the way. So if you do have already binary for GHC on that, then perhaps it'll work on Solaris too... You may wonder why I'm so picky about Solaris, but I've just been hit on Solaris 10 by bugs (in linker) which are not presented on Solaris 11 so in the past I needed to switch off shared libs on Solaris 10 and keep this functionality on Solaris 11 so I'm curious what third member to Solaris family will bring here. I hope SmartOS is still more closer to Solaris 11 than Solaris 10 thanks to its roots in OpenSolaris project... Thanks, Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
Hi Pavel, I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs. Solaris 2.10: https://app.box.com/s/s1bysqga0x5f3itysu7g https://app.box.com/s/fbfki0szetnp4pghpeuk Solaris 2.11: https://app.box.com/s/zstci63pt10t4yix74s8 https://app.box.com/s/9375dyx8hwu9cnox2lgi The first link is binary tarball while the second is sha256. Karel On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: Hi, I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than. https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 Regards, Pavel Ryzhov On 08 Apr 2014, at 21:39, Carter Schonwald carter.schonw...@gmail.com mailto:carter.schonw...@gmail.com wrote: ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János pali.ga...@gmail.com mailto:pali.ga...@gmail.com wrote: 2014-04-08 15:28 GMT+02:00 Austin Seipp aus...@well-typed.com mailto:aus...@well-typed.com: Feel free to make builds - I'll add them as they come in and will announce soon... The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual: http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html ___ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org mailto: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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
Hi Jens, Ben Gamari (cced) documented it well here: http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html Looks like the issue is caused by binutils' linker while fixed in gold. Cheers, Karel On 04/ 9/14 10:21 AM, Jens Petersen wrote: dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for the full build.log, etc. I reproduced this two times now. RC2 built okay on ARM so I am not sure what changed. I tested and this also happens on Fedora 20 ARM [1] so I now doubt it could be due to any recent changes in Fedora devel (Rawhide). I filed https://ghc.haskell.org/trac/ghc/ticket/8976. Anyway I suppose it may be too late to fix for the 7.8.1 release but hopefully soon for 7.8.2. Jens [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720188 ___ 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
Avoiding bumping the major version of base in every release
Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. *Medium term* - Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Offering GHC builder build slaves
On Apr 9, 2014, at 8:36, Karel Gardas karel.gar...@centrum.cz wrote: On 04/ 9/14 03:41 AM, Alain O'Dea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-04-08 08:17 PM, Karel Gardas wrote: On 04/ 8/14 03:16 PM, Alain O'Dea wrote: The two build slaves I intend to run are: - x86_64 Solaris (on SmartOS) Please name it smartos-x86 then. I'm running real Solaris 11.1 as a builder here so let's make it different name builder and see if there are any incompatibilities between those two (I hope still very close) platforms. BTW: what's your platform triple detected by config.guess? Thanks! Karel Hi Karel, My platform triple detected by config.guess is: x86_64-unknown-solaris2 I got that by running `cat config.status | grep TargetPlatformFull`. Hi Alain, hmm, that's after GHC own platform processing is done, but what does sh config.guess tells you? E.g. on my two Solaris 11 I get: $ sh config.guess i386-pc-solaris2.11 $ sh config.guess sparc-sun-solaris2.11 Ah. I'll have to send that later today. BTW: also if you are building GHC on AMD64/Solaris/err/SmartOS, then I think Christian (cced) may be interested as he is currently working on cross-compiling from i386/Solaris to AMD64/Solaris and he is hit by some bugs along the way. So if you do have already binary for GHC on that, then perhaps it'll work on Solaris too... Christian, the SmartOS GHC binaries should work unmodified on Solaris 10 and 11. Both 32- and 64-bit GHC 7.6.3 are available in SmartOS PKGSRC. I have successfully used them as bootstrap for GHC 7.8. The binaries should be separable. I can get the build details if desired. You may wonder why I'm so picky about Solaris, but I've just been hit on Solaris 10 by bugs (in linker) which are not presented on Solaris 11 so in the past I needed to switch off shared libs on Solaris 10 and keep this functionality on Solaris 11 so I'm curious what third member to Solaris family will bring here. It seems SmartOS builds GHC 7.8 cleanly without patches. There are some test failures which I'm working on. I hope SmartOS is still more closer to Solaris 11 than Solaris 10 thanks to its roots in OpenSolaris project... SmartOS is an Illumos distro (like Ubuntu is to Linux). Illumos is descended directly from the last public commit of OpenSolaris 10 (grr Oracle). Thanks, Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Avoiding bumping the major version of base in every release
I just noticed that 7.8.1 bumps the major version of base, but I can't see any breaking changes in the release notes: http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/release-7-8-1.html On Wed, Apr 9, 2014 at 12:00 PM, Johan Tibell johan.tib...@gmail.comwrote: Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. *Medium term* - Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Avoiding bumping the major version of base in every release
On 2014-04-09 at 12:00:36 +0200, Johan Tibell wrote: [...] All this is to say, we should try to avoid major version bumps to base. Here's my suggestion *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. Fwiw, I did go over the changes in base-4.7.0.0 when I compiled the changelog to check whether the major bump was justified; but since a couple of deprecated functions where removed, several new typeclass instances were added (however, this isn't a justification anymore), the rather disruptive Typeable change occured, as well as the PrimBool changes (which may leak into the API exposed by base) I believed it was well justified. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. Aren't we already following this practice in base? *Medium term* - Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Avoiding bumping the major version of base in every release
On Wed, Apr 9, 2014 at 2:17 PM, Herbert Valerio Riedel hvrie...@gmail.comwrote: On 2014-04-09 at 12:00:36 +0200, Johan Tibell wrote: *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. Fwiw, I did go over the changes in base-4.7.0.0 when I compiled the changelog to check whether the major bump was justified; but since a couple of deprecated functions where removed, several new typeclass instances were added (however, this isn't a justification anymore), the rather disruptive Typeable change occured, as well as the PrimBool changes (which may leak into the API exposed by base) I believed it was well justified. I wasn't aware there was a more detailed changelog. Thanks for pointing it out. I just wanted to make sure we're all on the same page here. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. Aren't we already following this practice in base? I am and I'm hoping others are too. Since hope is not a strategy I just thought I'd spell it out to make sure we all agree. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Avoiding bumping the major version of base in every release
On 2014-04-09 at 14:51:48 +0200, Johan Tibell wrote: [...] Fwiw, I did go over the changes in base-4.7.0.0 when I compiled the changelog to check whether the major bump was justified; but since a couple of deprecated functions where removed, several new typeclass instances were added (however, this isn't a justification anymore), the rather disruptive Typeable change occured, as well as the PrimBool changes (which may leak into the API exposed by base) I believed it was well justified. I wasn't aware there was a more detailed changelog. Thanks for pointing it out. I just wanted to make sure we're all on the same page here. Oh, and btw, here's also a somewhat older API delta (which is only as accurate as the hoogle txt files generated -- i.e. take it with a grain of salt) I generated some time ago: https://gist.github.com/hvr/6648575 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Backward-compatible role annotations
We indeed had unexported internal coercions as a desideratum during the design process, but we didn't have a specific use case and it didn't mesh with our eventual decision to use class instances. Now that the whole thing is implemented, Coercible instances are actually fully magical inside of GHC. Thus, there would be nothing especially difficult, from an implementation standpoint, of adding the feature described below in a later release. There is always the niggling issue of concrete syntax. So, if you (or others) hit upon a nice, real use case desiring this feature and want to come up with a design, please propose it! I do think it would likely be easy to make happen. Richard On Apr 8, 2014, at 10:28 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: I've been wondering whether there are any cases where the ability to coerce a parameter should not be exported (as for Set) but where the implementation would like to use some coercions (for example, if it internally wanted to coerce the contained type to a specific newtype, to change some of the contained type's instances while being able to guarantee that the invariant-related instances stayed safe). This would call for coercibility to be something you can import and export. What if, in the long term, there were a flag ExplicitRoleExports (probably rarely used): - with ExplicitRoleExports on, role signatures would be listed in the export list and must be at least as restrictive as the roles visible within the module. Exported types without role signatures in the export list would default to being exported as all-nominal. - with ExplicitRoleExports off, any types the modules export would be exported with the same roles visible inside the module. As is currently, the default role at a type's definition site would allow as many coercions as is segfault-safe. -Isaac P.S. I think this particular proposal likely has issues. If you import (T :: * - * - *) as nominal, representational and from elsewhere as representational, nominal, do those roles combine somehow? What about contravariant [or is it covariant] roles as in (T :: (* - *) - *)? I haven't thought these through. Also I haven't thought of any concrete use cases for export-controlled roles; perhaps there aren't any. On 03/31/2014 02:12 PM, Dominique Devriese wrote: Richard, Right, but I was thinking about the debate between nominal/non-parametric-by-default or representational/parametric-by-default for parameters of data types that aren't forced to nominal from inspecting the datatype implementation. As I understand it, representational-by-default (currently used) may leave libraries that don't add role annotations open for abuse, but won't unnecessarily break library users' code and nominal-by-default prevents all abuse but may unnecessarily break code that uses libraries that have not added proper role annotations. What I was wondering about is if the dilemma could be solved by choosing nominal-by-default in the long term for the role inference (so that library writers cannot accidentally leave abstraction holes open by forgetting to add role annotations) and use them in the long-term-supported SafeNewtypeDeriving extension, but provide a deprecated not-quite-as-safe GND extension for helping out users of libraries that have not yet added role annotations. I would fancy that this not-quite-as-safe GND could use unsafeCoerce wherever the safe one would give an error about annotated roles. Regards, Dominique 2014-03-31 17:05 GMT+02:00 Richard Eisenberg e...@cis.upenn.edu: Hi Dominique, When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one. The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues. Richard On Mar 31, 2014, at 2:51 AM, Dominique Devriese dominique.devri...@cs.kuleuven.be wrote: Richard, (re-posting because I first used an address that is not subscribed to the lists) I've been wondering about the following: it seems like the main problem in this situation is that the GeneralizedNewtypeDeriving extension changed meaning from just coerce everything while deriving to only coerce stuff if it's allowed by the relevant role annotations. Would it not be an alternative solution to split up the GND extension into * a backwards-compatible one
Re: 7.8.1 plan
Hi Karel, That is great! Do you know if there any plans for 64-bit build of GHC for Solaris 11? Regards, Pavel On 09 Apr 2014, at 10:49, Karel Gardas karel.gar...@centrum.cz wrote: Hi Pavel, I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs. Solaris 2.10: https://app.box.com/s/s1bysqga0x5f3itysu7g https://app.box.com/s/fbfki0szetnp4pghpeuk Solaris 2.11: https://app.box.com/s/zstci63pt10t4yix74s8 https://app.box.com/s/9375dyx8hwu9cnox2lgi The first link is binary tarball while the second is sha256. Karel On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: Hi, I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than. https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 Regards, Pavel Ryzhov On 08 Apr 2014, at 21:39, Carter Schonwald carter.schonw...@gmail.com mailto:carter.schonw...@gmail.com wrote: ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János pali.ga...@gmail.com mailto:pali.ga...@gmail.com wrote: 2014-04-08 15:28 GMT+02:00 Austin Seipp aus...@well-typed.com mailto:aus...@well-typed.com: Feel free to make builds - I'll add them as they come in and will announce soon... The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual: http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html ___ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org mailto: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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Avoiding bumping the major version of base in every release
Sounds reasonable to me, but I'm fwding this to the Core Libraries committee, who are in charge of all this. On the question of breaking up 'base', see https://ghc.haskell.org/trac/ghc/wiki/SplitBase, which seems stalled for lack of anyone willing to take up the cudgels. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell Sent: 09 April 2014 11:01 To: ghc-devs@haskell.org Subject: Avoiding bumping the major version of base in every release Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion Short term * Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. * Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. Medium term * Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [core libraries] RE: Avoiding bumping the major version of base in every release
The current plan with breaking up base is mostly to push it out until we get the lower hanging fruit out of the way for 7.10, and to start moving forward more aggressively on that around 7.12. Back at ICFP we made the call to more or less take greater ownership of base upon the release of 7.8. Given the release timeline that was perhaps, in hindsight, a mistake, as it drained a lot of momentum. That said, now that 7.8 is out the door we can at least get started on the Foldable/Traversable/Applicative/Monoid changes and AMP. The orginal plan, and one that I think is still a good plan going forward, is that the changes for 7.10 should be done in such a way that most users can work around them all without CPP at all, and just enjoy the greater flexibility of Foldable/Traversable/Applicative/Monoid in Prelude. I think the major things broken by those inclusions are and $ in the pretty printing libraries, which could hide two symbols, and a boatload of redundant import warnings. Almost any serious stab at breaking up base to meet the demands of the javascript crowd, one of the two major reasons for breaking up base, is going to cause some serious challenges for the very makeup of the Prelude we export today. I'm all for doing splitting up base, but it is definitely stalled for a reason, and I think that given the scope of work in just modernizing the Prelude, we've got a lot bitten off already for this coming year in 7.10. Beyond that, one potentially viable plan is to break it up in phases -- if the more invasive changes needed to make the ghcjs/haste crowd can't converge for 7.12 we could at least start splintering off some parts of base that don't feed into the Prelude. That would let us better meet Johan's goal of an eventually more stable base version number as those things at the fringes of base are the kinds of thing that iterate quickly, but very little of the Prelude itself changes from release to release -- although, 7.10 will be a rather large exception in that regard. -Edward On Wed, Apr 9, 2014 at 4:50 PM, Simon Peyton Jones simo...@microsoft.comwrote: Sounds reasonable to me, but I’m fwding this to the Core Libraries committee, who are in charge of all this. On the question of breaking up ‘base’, see https://ghc.haskell.org/trac/ghc/wiki/SplitBase, which seems stalled for lack of anyone willing to take up the cudgels. Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 09 April 2014 11:01 *To:* ghc-devs@haskell.org *Subject:* Avoiding bumping the major version of base in every release Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. *Medium term* - Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan -- You received this message because you are subscribed to the Google Groups haskell-core-libraries group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Offering GHC builder build slaves
2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg lyn...@orthanc.ca: Is there any way to verify that builder-client can actually do a successful build, without having access to the build system server? 'builder-client --do-build' wants to connect and authenticate first; it would be helpful if there was a way to bypass that so that I can first verify the local build environment is sane. This is because the builder client gets the commands to be executed from the server. A naive solution would be to put the commands in the script and run it. You can find the current set of installed commands at one of the active builders page, e.g. [1]. Note that you may have to change some of them, such as the flags passed to configure script and name of the make(1) command. [1] http://haskell.inf.elte.hu/builders/solaris-x86-head/23.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
On Fri, 4 Apr 2014 16:19:48 +
Simon Peyton Jones simo...@microsoft.com wrote:
Filed the reproducer as a new ticket:
https://ghc.haskell.org/trac/ghc/ticket/8980
[ Looks like highlighting-kate asks to be added to
compiler performance benchmarks (are there such ones?)
It tends to stress ghc all the time:
http://hackage.haskell.org/trac/ghc/ticket/3664
]
Thanks!
Sergei
SpecConstr is too aggressive: it sometimes blows up the program badly and we
have no good solution. See Trac #7898, #7068, #7944, #5550, #8836.
I notice that the latter three are actually fixed in 7.8, so worth trying
that. If it still fails, do add instructions to reproduce to one of the
above open tickets, or make a new one.
Amos Robinson (cc'd) was working on this problem, but I have not heard
anything recently.
It surely ought to be possible to throttle it a bit so that it stops before
generating too vast a program.
Meanwhile you can use -fno-spec-constr to simply switch it off for offending
modules. That should get you going.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Sergei Trofimovich
| Sent: 03 April 2014 21:20
| To: ghc-devs@haskell.org
| Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-
| citeproc / highlighting-kate
|
| On Sat, 22 Mar 2014 22:21:42 +0300
| Sergei Trofimovich sly...@gmail.com wrote:
|
| Hello!
|
| I have noticed the problem in ghc-7.6.3 first when tried to build all
| haskell userland with -O2 opt level.
|
| It led to amazing bugs!
|
| Here is one of those (highlighting-kate hackage package):
| [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
| stack overflow: use +RTS -Ksize to increase it
|
| How to reproduce it:
| 1. Download a bundled file (6.6MB):
|
| http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-
| rc2.tar.gz
| 2. Unpack and run there:
|./mk.sh
|
| The script is designed to plug any built ghc version w/o external
| depends.
|
| Command will fail as:
| $ ./mk.sh
| ...
| [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
| stack overflow: use +RTS -Ksize to increase it
|
| On ghc-7.6.3 it will progress a bit more: down to 452 file and will
| crash there similar way.
|
| I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them
| manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around.
| Nothing else.
|
| It's very hard to shrink such large thing manually down to 2-3 files.
| Would be cool if ghc (and cabal) would be able to spit something
| self-sufficient (like 'gcc -i' does) for devs to reproduce.
|
| Adding '-v' shows such log:
| ...
| *** Simplifier:
| Result size of Simplifier iteration=1
|= {terms: 21,973, types: 21,838, coercions: 1,842}
| Result size of Simplifier iteration=2
|= {terms: 21,952, types: 21,819, coercions: 1,842}
| Result size of Simplifier
|= {terms: 21,950, types: 21,817, coercions: 1,842}
| *** SpecConstr:
| Result size of SpecConstr***CRASH
|
| Nobody interested? Is it too scary?
|
| Such inliner blowups are hard to shrink down from real examples down to
| toy ones. I could try to but I need a bit of guidance.
|
| Maybe you need only an intermediate core step right before an OOM,
| whatever?
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Offering GHC builder build slaves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-04-09 11:49 AM, Alain O'Dea wrote: On Apr 9, 2014, at 8:36, Karel Gardas karel.gar...@centrum.cz wrote: On 04/ 9/14 03:41 AM, Alain O'Dea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-04-08 08:17 PM, Karel Gardas wrote: On 04/ 8/14 03:16 PM, Alain O'Dea wrote: The two build slaves I intend to run are: - x86_64 Solaris (on SmartOS) Please name it smartos-x86 then. I'm running real Solaris 11.1 as a builder here so let's make it different name builder and see if there are any incompatibilities between those two (I hope still very close) platforms. BTW: what's your platform triple detected by config.guess? Thanks! Karel Hi Karel, My platform triple detected by config.guess is: x86_64-unknown-solaris2 I got that by running `cat config.status | grep TargetPlatformFull`. Hi Alain, hmm, that's after GHC own platform processing is done, but what does sh config.guess tells you? E.g. on my two Solaris 11 I get: $ sh config.guess i386-pc-solaris2.11 $ sh config.guess sparc-sun-solaris2.11 Karel, I think I finally have what you were looking for: x86_64-pc-solaris2.11 i386-pc-solaris2.11 Gábor sent me usernames and passwords for my builders and I'm in the process of setting those up now. Ah. I'll have to send that later today. BTW: also if you are building GHC on AMD64/Solaris/err/SmartOS, then I think Christian (cced) may be interested as he is currently working on cross-compiling from i386/Solaris to AMD64/Solaris and he is hit by some bugs along the way. So if you do have already binary for GHC on that, then perhaps it'll work on Solaris too... Christian, the SmartOS GHC binaries should work unmodified on Solaris 10 and 11. Both 32- and 64-bit GHC 7.6.3 are available in SmartOS PKGSRC. I have successfully used them as bootstrap for GHC 7.8. The binaries should be separable. I can get the build details if desired. You may wonder why I'm so picky about Solaris, but I've just been hit on Solaris 10 by bugs (in linker) which are not presented on Solaris 11 so in the past I needed to switch off shared libs on Solaris 10 and keep this functionality on Solaris 11 so I'm curious what third member to Solaris family will bring here. It seems SmartOS builds GHC 7.8 cleanly without patches. There are some test failures which I'm working on. I hope SmartOS is still more closer to Solaris 11 than Solaris 10 thanks to its roots in OpenSolaris project... SmartOS is an Illumos distro (like Ubuntu is to Linux). Illumos is descended directly from the last public commit of OpenSolaris 10 (grr Oracle). Thanks, Karel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRetbAAoJEP0rIXJNjNSAGpIH/Rd0Kp4K3OV5jIdwiT3x1GNI jbed0L48bOB9u4ChasoLsq+12iOhwYkb4eBd+hAWGnjW+/EDsX7F19qfuBugsr9a GiYyGRprRaMFMUQ0DR1pFPqeLKe5EUaNw5Al4KVW5i9W3LDCwGL3pQI8D0dRYzlN 4QlG7OcDG9DN8mTyiFAtWOjFloqkQN1G6EQG1GbwkHSdjKrXVRfeatAxMl9QfS7H I1o9sLDKJWQTL38XmnMuXWKqLmvxundO0UUJNmvmKoJdSnRnBvD5m4BvnpIN1Cl2 xVnIvPef5PuPE5I1EXqZu61zUD2qgqmyVCHZui5D+ltZoEUS0Hh94JSzb2YOSGs= =mu2x -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
On 9 April 2014 17:53, Karel Gardas karel.gar...@centrum.cz wrote: Ben Gamari (cced) documented it well here: http://bgamari.github.io/ posts/2014-03-06-compiling-ghc-7.8-on-arm.html Looks like the issue is caused by binutils' linker while fixed in gold. Thanks a lot, Karel! I will try Ben's hack later. I am still surprised that RC2 builds fine on ARM (I re-verified that yesterday [1]) but not final 7.8.1. Were there some late ARM or linking changes that cause this now? On 04/ 9/14 10:21 AM, Jens Petersen wrote: dll-split: internal error: evacuate(static): strange closure type 0 See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for I reproduced this two times now. RC2 built okay on ARM so I am not sure what changed. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
Jens, It's probably due to abb86adf7f749b3d44887d28bc96b43c5a1e0631[1] which was merged post RC2. I base this on the fact your build is failing during the dynamic build. Do try a reverse patch and see if it helps. I believe Karel is right - you just need to use Gold. Ben actually had patches to make the build fail if using binutils ld was detected, but I believe I had reservations about the patch which I cannot recall off the top of my head. In any case, a fix like that can certainly go in 7.8.2. Do let us know how it goes. [1] https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631 On Wed, Apr 9, 2014 at 8:03 PM, Jens Petersen peter...@fedoraproject.org wrote: On 9 April 2014 17:53, Karel Gardas karel.gar...@centrum.cz wrote: Ben Gamari (cced) documented it well here: http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html Looks like the issue is caused by binutils' linker while fixed in gold. Thanks a lot, Karel! I will try Ben's hack later. I am still surprised that RC2 builds fine on ARM (I re-verified that yesterday [1]) but not final 7.8.1. Were there some late ARM or linking changes that cause this now? On 04/ 9/14 10:21 AM, Jens Petersen wrote: dll-split: internal error: evacuate(static): strange closure type 0 See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for I reproduced this two times now. RC2 built okay on ARM so I am not sure what changed. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
