RE: Tentative high-level plans for 7.10.1
I don't know whether this has ever been considered as an idea, but what about
having a notion of Long Term Support version (similar to how a lot of processor
and operating systems vendors go about this).
The idea behind an LTS-GHC would be to continue bug-fixing on the LTS-version,
even if newer major versions no longer get bug-fixing support. To some extent,
there will be redundancies (bugs that have disappeared in newer versions
because newer code does the same and more, still needing to be fixed on the LTS
code base), but the upside would be a clear prioritisation between stability
(LTS) and innovation (latest major release).
The current policy for feature *use* in the GHC code-base is that they're
supported in (at least) three earlier major release versions. Should we go the
LTS-route, the logical choice would be to demand the latest LTS-version. The
danger, of course, is that people aren't very enthusiastic about bug-fixing
older versions of a compiler, but for language/compiler-uptake, this might
actually be a Better Way.
Thoughts?
Ph.
From: John Lato jwl...@gmail.com
Sent: 06 October 2014 01:10
To: Johan Tibell
Cc: Simon Marlow; ghc-devs@haskell.org
Subject: Re: Tentative high-level plans for 7.10.1
Speaking as a user, I think Johan's concern is well-founded. For us, ghc-7.8.3
was the first of the 7.8 line that was really usable in production, due to
#8960 and other bugs. Sure, that can be worked around in user code, but it
takes some time for developers to locate the issues, track down the bug, and
implement the workaround. And even 7.8.3 has some bugs that cause minor
annoyances (either ugly workarounds or intermittent build failures that I
haven't had the time to debug); it's definitely not solid. Similarly, 7.6.3
was the first 7.6 release that we were able to use in production. I'm
particularly concerned about ghc-7.10 as the AMP means there will be
significant lag in identifying new bugs (since it'll take time to update
codebases for that major change).
For the curious, within the past few days we've seen all the following, some
multiple times, all so far intermittent:
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3.0 for x86_64-unknown-linux):
kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
some_mangled_name_closure
ghc: mmap 0 bytes at (nil): Invalid Argument
internal error: scavenge_one: strange object 2022017865
Some of these I've mapped to likely ghc issues, and some are fixed in HEAD, but
so far I haven't had an opportunity to put together reproducible test cases.
And that's just bugs that we haven't triaged yet, there are several more for
which workarounds are in place.
John L.
On Sat, Oct 4, 2014 at 2:54 PM, Johan Tibell
johan.tib...@gmail.commailto:johan.tib...@gmail.com wrote:
On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp
aus...@well-typed.commailto:aus...@well-typed.com wrote:
- Cull and probably remove the 7.8.4 milestone.
- Simply not enough time to address almost any of the tickets
in any reasonable timeframe before 7.10.1, while also shipping them.
- Only one, probably workarouadble, not game-changing
bug (#9303) marked for 7.8.4.
- No particular pressure on any outstanding bugs to release immediately.
- ANY release would be extremely unlikely, but if so, only
backed by the most critical of bugs.
- We will move everything in 7.8.4 milestone to 7.10.1 milestone.
- To accurately catalogue what was fixed.
- To eliminate confusion.
#8960 looks rather serious and potentially makes all of 7.8 a no-go for some
users. I'm worried that we're (in general) pushing too many bug fixes towards
future major versions. Since major versions tend to add new bugs, we risk
getting into a situation where no major release is really solid.
___
ghc-devs mailing list
ghc-devs@haskell.orgmailto: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: Tentative high-level plans for 7.10.1
Here are the major patches on Phabricator still needing review, that I think we'd like to see for 7.10.1: - D72: New rebindable syntax for arrows. I don't think D72 will make it in. I started to work on this a couple of months ago but the work has stalled. I just don't understand arrows well enough :-/ Sophie Taylor (aka spacekitteh) expressed some interest in this and we chatted a bit about it on IRC. But I haven't heard anything from Sophie in the past 2 weeks so I don't know whether she intends to pick up my work or not. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
This is also the thing that worries most about arc: Squashing commits. Splitting commits into * things that only do whitespace changes * things that only add comments * things that only refactor * things that actually introduce a semantic change *is* very valuable also for the efficency of the review process. On 05.10.2014 19:13, Tuncer Ayaz wrote: On Sun, Oct 5, 2014 at 4:32 PM, Ben Gamari wrote: 5.a. I reflected on the mild shock of seeing that `arc` had squashed my carefully crafted patch set into a single commit. This still bothers me to this day. I second 5.a, but does it have to be this way, or can arc be instructed to not squash commits? -- Andreas AbelDu bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.a...@gu.se http://www2.tcs.ifi.lmu.de/~abel/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tentative high-level plans for 7.10.1
On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote: [...] The idea behind an LTS-GHC would be to continue bug-fixing on the LTS-version, even if newer major versions no longer get bug-fixing support. To some extent, there will be redundancies (bugs that have disappeared in newer versions because newer code does the same and more, still needing to be fixed on the LTS code base), but the upside would be a clear prioritisation between stability (LTS) and innovation (latest major release). As I'm not totally sure what you mean: Assuming we already had decided years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the future 7.10; which of those GHC versions would you have been considered a LTS version? [...] The danger, of course, is that people aren't very enthusiastic about bug-fixing older versions of a compiler, but for language/compiler-uptake, this might actually be a Better Way. Maybe some of the commercial GHC users might be interested in donating the manpower to maintain older GHC versions. It's mostly a time-consuming QA auditing process to maintain old GHCs. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tentative high-level plans for 7.10.1
On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote: The danger, of course, is that people aren't very enthusiastic about bug-fixing older versions of a compiler, but for language/compiler-uptake, this might actually be a Better Way. Maybe some of the commercial GHC users might be interested in donating the manpower to maintain older GHC versions. It's mostly a time-consuming QA auditing process to maintain old GHCs. What can we do to make that process cheaper? In particular, which are the manual steps in making a new GHC release today? In the long run back porting bugfixes is the route successful OSS projects take. Once people have written large enough Haskell programs they will stop jumping onto the newer version all the time and will demand backports of bug fixes. This is already happening to some extent in cabal (as cabal is tied to a ghc release which means we need to backport changes sometimes.) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tentative high-level plans for 7.10.1
On 6 Oct 2014, at 10:28, Herbert Valerio Riedel wrote: As I'm not totally sure what you mean: Assuming we already had decided years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the future 7.10; which of those GHC versions would you have been considered a LTS version? We continue to use 7.2, at least partly because all newer versions of ghc have had significant bugs that affect us. In fact, 7.2.2 also has a show-stopping bug, but we patched it ourselves to create our very own custom ghc-7.2.3 distribution. Regards, Malcolm ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Again: Uniques in GHC
Very much part of my plan, Johan! I was a fervent +1 on that recommendation. Ph. ? From: Johan Tibell johan.tib...@gmail.com Sent: 06 October 2014 12:06 To: Holzenspies, P.K.F. (EWI) Cc: ghc-devs@haskell.org Subject: Re: Again: Uniques in GHC On Mon, Oct 6, 2014 at 11:58 AM, p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl wrote: - The export-list of Unique has some comments stating that function X is only exported for module Y, yet is used elsewhere. This may be because these comments do not show up in haddock etc. leading some people to think they're up for general use. In my refactoring, I'm sticking the restriction in the function name, so it's no longer mkUniqueGrimily, but rather mkUniqueOnlyForUniqSupply (making the name even longer should discourage their use more). If at all possible, these should be removed altogether asap. Since you're touching this code base it would be a terrific time to add some Haddocks! (We recently decided, on the ghc-devs@ list, that all new top-level entities, i.e. functions, data types, and classes, should have Haddocks.) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Again: Uniques in GHC
Hi, Am Montag, den 06.10.2014, 09:58 + schrieb p.k.f.holzensp...@utwente.nl: - The implementation is based on FastInts, which, on most machines nowadays, is a 64-bit thing. The serialisation in BinIface is explicitly based on Word32s. Aside from the obvious potential (albeit with a low probability) for errors, this lead me to wonder about 32/64-bitness. Is there a reason for 64-bit versions of GHC to write Word32s, or is this a historic thing? Must the interface-files be bit-compatible between different versions (32/64-bits) of the compiler? Lastly, is the choice of whether this is a 32 or 64-bit version completely determined by WORD_SIZE_IN_BITS (MachDeps.h)? A while ago we had problems with haddock in Debian when the serialization became bit-dependent.¹ I suggest to keep the specification of any on-disk format independent of architecture specifics. Greetings, Joachim ¹ http://bugs.debian.org/586723#15 -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tentative high-level plans for 7.10.1
Hi Nicolas, So, if 1.4.x, 1.5.x, 1.6.x and 1.7.x are 'supported' versions, and some bug is found in 1.6.2, but turns out to be introduced in 1.5.1, we fix the bug in the 1.5 branch. Then, if the bugfix is important enough, we merge 1.4 in 1.5 (which can be a no-op), 1.5 in 1.6, and 1.6 into 1.7. As such, every version branch 'contains' all 'older' branches. I don't like this practise, because you certainly don't want to always incorprocate all commits of one release branch into an other. Just think about a hackish bug fix needed to be added in a former release, and in a newer release the problem has been solved in a completely different way, and now, if you have bad luck, the former release branch merges without conflicts into the new one, now getting the hackish fix into the new release, which might be even harmful. IMHO using cherry picking in this case is a lot better manageable. Greetings, Daniel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tentative high-level plans for 7.10.1
On 2014-10-06 at 11:50:03 +0200, Malcolm Wallace wrote: On 6 Oct 2014, at 10:28, Herbert Valerio Riedel wrote: As I'm not totally sure what you mean: Assuming we already had decided years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the future 7.10; which of those GHC versions would you have been considered a LTS version? We continue to use 7.2, at least partly because all newer versions of ghc have had significant bugs that affect us. In fact, 7.2.2 also has a show-stopping bug, but we patched it ourselves to create our very own custom ghc-7.2.3 distribution. I'd like to point out that's kinda ironic, as of *all* the GHC releases, you had to stay on the one major release that was considered a non-proper tech-preview... :-) Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tentative high-level plans for 7.10.1
Hello Daniel, On Mon, 2014-10-06 at 12:46 +0200, Daniel Trstenjak wrote: So, if 1.4.x, 1.5.x, 1.6.x and 1.7.x are 'supported' versions, and some bug is found in 1.6.2, but turns out to be introduced in 1.5.1, we fix the bug in the 1.5 branch. Then, if the bugfix is important enough, we merge 1.4 in 1.5 (which can be a no-op), 1.5 in 1.6, and 1.6 into 1.7. As such, every version branch 'contains' all 'older' branches. I don't like this practise, because you certainly don't want to always incorprocate all commits of one release branch into an other. Just think about a hackish bug fix needed to be added in a former release, and in a newer release the problem has been solved in a completely different way, and now, if you have bad luck, the former release branch merges without conflicts into the new one, now getting the hackish fix into the new release, which might be even harmful. Agree, although I think this is less of an issue in practice because we enforce code reviews for all commits, including 'merge' commits, even if the merge was 100% automatic (hence we have PRs for '1.5-for-1.6' branches once in a while). These 'workarounds' are spotted easily during this process. Next to that, chances are fairly low a 'hack' won't in any way conflict with a 'proper fix', since they tend to touch (a portion of) the same code most of the time (except in build systems maybe). Using 'git-imerge' helps here quite a bit as well, since the conflicts aren't buried between 100s of unrelated changes (like what git-merge does). IMHO using cherry picking in this case is a lot better manageable. Yet it has a (IMHO) major drawback: it requires a system next to VCS (issue tracker or alike) to make sure all fixes are propagated to all applicable versions, which all too often results in (human) error. Hey, we reported this against 1.6.3, and it was fixed in 1.6.4, but now we upgraded to 1.7.3 which was released after 1.6.4 and the bug is back is no good PR. Anyway, it's not like I intend to push GHC development/maintenance in any specific direction at all, just wanted to provide some experience report :-) Regards, Nicolas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Show instance for SrcSpan
Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Show instance for SrcSpan
On 10/06/2014 01:59 PM, Alan Kim Zimmerman wrote: Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan Why? If you're looking for pretty output then you should be changing Outputable. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Show instance for SrcSpan
Aside: I really miss derived Show instances in GHC. The Outputable class is only really useful if you already know how things work. If you e.g. want to see the AST used to represent some piece of Haskell code, in all its glory, the Outputable instances aren't useful because they elide too much information. On Mon, Oct 6, 2014 at 3:11 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 10/06/2014 01:59 PM, Alan Kim Zimmerman wrote: Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan Why? If you're looking for pretty output then you should be changing Outputable. -- Mateusz K. ___ 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: Show instance for SrcSpan
True, but if you are using GHC generated stuff via the GHC API you sometimes do not want to have to implement Outputable for all your app types, when you can auto derive Show which mostly does what you need. On Mon, Oct 6, 2014 at 3:11 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 10/06/2014 01:59 PM, Alan Kim Zimmerman wrote: Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan Why? If you're looking for pretty output then you should be changing Outputable. -- Mateusz K. ___ 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: Show instance for SrcSpan
On Mon, Oct 06, 2014 at 02:59:03PM +0200, Alan Kim Zimmerman wrote: Date: Mon, 6 Oct 2014 14:59:03 +0200 From: Alan Kim Zimmerman alan.z...@gmail.com To: ghc-devs@haskell.org ghc-devs@haskell.org Subject: Show instance for SrcSpan Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan I like the notion that `Read . Show` should always work. Dropping parts of a datatype would break that rule. matthias ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Show instance for SrcSpan
Not at all, just show as e.g. SrcSpan (RealSrcSpan (SrcSpanOneLine ./foo.hs 4 1 6)) We just avoid showing the srcSpanFile / srcSpanLine / srcSpanSCol / srcSpanECol noise On Mon, Oct 6, 2014 at 3:16 PM, Matthias Fischmann m...@zerobuzz.net wrote: On Mon, Oct 06, 2014 at 02:59:03PM +0200, Alan Kim Zimmerman wrote: Date: Mon, 6 Oct 2014 14:59:03 +0200 From: Alan Kim Zimmerman alan.z...@gmail.com To: ghc-devs@haskell.org ghc-devs@haskell.org Subject: Show instance for SrcSpan Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan I like the notion that `Read . Show` should always work. Dropping parts of a datatype would break that rule. matthias ___ 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: Show instance for SrcSpan
Ah, you want to drop constructor field names. Then I withdraw my reservations. thanks for the clarification, m. On Mon, Oct 06, 2014 at 03:27:49PM +0200, Alan Kim Zimmerman wrote: Date: Mon, 6 Oct 2014 15:27:49 +0200 From: Alan Kim Zimmerman alan.z...@gmail.com To: Matthias Fischmann m...@zerobuzz.net Cc: ghc-devs@haskell.org ghc-devs@haskell.org Subject: Re: Show instance for SrcSpan Not at all, just show as e.g. SrcSpan (RealSrcSpan (SrcSpanOneLine ./foo.hs 4 1 6)) We just avoid showing the srcSpanFile / srcSpanLine / srcSpanSCol / srcSpanECol noise On Mon, Oct 6, 2014 at 3:16 PM, Matthias Fischmann m...@zerobuzz.net wrote: On Mon, Oct 06, 2014 at 02:59:03PM +0200, Alan Kim Zimmerman wrote: Date: Mon, 6 Oct 2014 14:59:03 +0200 From: Alan Kim Zimmerman alan.z...@gmail.com To: ghc-devs@haskell.org ghc-devs@haskell.org Subject: Show instance for SrcSpan Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan I like the notion that `Read . Show` should always work. Dropping parts of a datatype would break that rule. matthias ___ 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: Show instance for SrcSpan
To get even more heretical, a quick grep of the compiler source tree does not show SrcSpanOneLine / SrcSpanMultiLine / SrcSpanPoint being used anywhere but in SrcLoc.lhs. The use in SrcLoc is in the original constructor, the deconstructors pulling out lines and columns, and combineSrcSpans. Perhaprs our SrcSpan is more complicated than it needs to be? On Mon, Oct 6, 2014 at 3:37 PM, Matthias Fischmann m...@zerobuzz.net wrote: Ah, you want to drop constructor field names. Then I withdraw my reservations. thanks for the clarification, m. On Mon, Oct 06, 2014 at 03:27:49PM +0200, Alan Kim Zimmerman wrote: Date: Mon, 6 Oct 2014 15:27:49 +0200 From: Alan Kim Zimmerman alan.z...@gmail.com To: Matthias Fischmann m...@zerobuzz.net Cc: ghc-devs@haskell.org ghc-devs@haskell.org Subject: Re: Show instance for SrcSpan Not at all, just show as e.g. SrcSpan (RealSrcSpan (SrcSpanOneLine ./foo.hs 4 1 6)) We just avoid showing the srcSpanFile / srcSpanLine / srcSpanSCol / srcSpanECol noise On Mon, Oct 6, 2014 at 3:16 PM, Matthias Fischmann m...@zerobuzz.net wrote: On Mon, Oct 06, 2014 at 02:59:03PM +0200, Alan Kim Zimmerman wrote: Date: Mon, 6 Oct 2014 14:59:03 +0200 From: Alan Kim Zimmerman alan.z...@gmail.com To: ghc-devs@haskell.org ghc-devs@haskell.org Subject: Show instance for SrcSpan Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan I like the notion that `Read . Show` should always work. Dropping parts of a datatype would break that rule. matthias ___ 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: Show instance for SrcSpan
The way I read Alan's earlier mail is precisely that; auto-generated Show does what he wants (show the entire AST), whereas Outputable hides too much information. I very much understand his frustration with having to manually figure out what constructors and datatypes go where in a compiled program. Alan's point was the *absence* of auto derived Show instances and, in the case of SrcSpan, too much verbosity (rather than wanting stuff to be incomplete). Allowing some bespoke stuff to reduce the noise of something like record field names for SrcSpan makes even more sense in this context. Similarly, this is why Alan I want everything to have Data instances, so you can (amongst many other nice things) selectively print parts of the AST. Ph. From: Alan Kim Zimmerman alan.z...@gmail.com Sent: 06 October 2014 15:15 To: Mateusz Kowalczyk Cc: ghc-devs@haskell.org Subject: Re: Show instance for SrcSpan True, but if you are using GHC generated stuff via the GHC API you sometimes do not want to have to implement Outputable for all your app types, when you can auto derive Show which mostly does what you need. On Mon, Oct 6, 2014 at 3:11 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukmailto:fuuze...@fuuzetsu.co.uk wrote: On 10/06/2014 01:59 PM, Alan Kim Zimmerman wrote: Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan Why? If you're looking for pretty output then you should be changing Outputable. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.orgmailto: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
Stepping through ghc
Hi, I'm new to ghc codebase and I'm interested in stepping through the code in order to gain a better idea of how it all works. - Is there a way to load ghc into ghci ? and debug through it ? - What are the ways experienced ghc devs step through the code ? - Any techniques you guys recommend ? - What would your advices be for a newbie to the source code ? Thanks, Omar Mefire, ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
On Mon, Oct 6, 2014 at 11:27 AM, Andreas Abel wrote: This is also the thing that worries most about arc: Squashing commits. Splitting commits into * things that only do whitespace changes * things that only add comments * things that only refactor * things that actually introduce a semantic change *is* very valuable also for the efficency of the review process. Having separate commits also increases the chances of finding the faulty diff with git-bisect. Also, reviewing is usually easier with split commits, and it's simpler to provide descriptive per-commit explanations within each commit message. That being said, temp/fixup/backup commits should be squashed prior to submitting a commit/patch series, and I suppose that's the rationale behind arc's behavior. On 05.10.2014 19:13, Tuncer Ayaz wrote: On Sun, Oct 5, 2014 at 4:32 PM, Ben Gamari wrote: 5.a. I reflected on the mild shock of seeing that `arc` had squashed my carefully crafted patch set into a single commit. This still bothers me to this day. I second 5.a, but does it have to be this way, or can arc be instructed to not squash commits? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
On Sun, Oct 5, 2014 at 10:44 PM, Joachim Breitner wrote: Hi, Am Sonntag, den 05.10.2014, 19:20 +0200 schrieb Tuncer Ayaz: There's also the problem that Github's review system is not as powerful and most importantly does not preserve history like Gerrit or Phabricator do. Once used to it, maintainers probably won't be happy to lose productivity due to the simplistic review system. I don't think this is a reason to forbid them alltogether. We could say: We prefer submissions via Phabricator, especially for larger patches, but if you like, you can use GitHub as well - your contributions is welcome in any case. We are talking about small contributions and entry-barriers here, and a for a documentation patch or similarly small contributions, we don't need the full power of Phabricator. When new contributors start to engage more deeply they will not mind learning Phabricator. But they will be much more motivated to do so when they have already successfully contributed something. Sure, it should certainly be tried. By the way, while the Github team has no public ticket system, they are very responsive when you send them feature requests or, say, explain where the review system is incomplete/broken. They never promise anything and do not pre-announce a feature, so it is hard to track future changes. However, they're responsive and seem to value majority opinion. Here's the page: https://github.com/support ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
To be completely clear, arc does not FORCE you to squash commits. You can simply arc diff each commit in question seperately. Now, it is certainly true that arc does not make this easy to do. See: https://secure.phabricator.com/T5636 Edward Excerpts from Andreas Abel's message of 2014-10-06 03:27:10 -0600: This is also the thing that worries most about arc: Squashing commits. Splitting commits into * things that only do whitespace changes * things that only add comments * things that only refactor * things that actually introduce a semantic change *is* very valuable also for the efficency of the review process. On 05.10.2014 19:13, Tuncer Ayaz wrote: On Sun, Oct 5, 2014 at 4:32 PM, Ben Gamari wrote: 5.a. I reflected on the mild shock of seeing that `arc` had squashed my carefully crafted patch set into a single commit. This still bothers me to this day. I second 5.a, but does it have to be this way, or can arc be instructed to not squash commits? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
Hi, Am Montag, den 06.10.2014, 17:54 +0200 schrieb Tuncer Ayaz: By the way, while the Github team has no public ticket system, they are very responsive when you send them feature requests or, say, explain where the review system is incomplete/broken. They never promise anything and do not pre-announce a feature, so it is hard to track future changes. However, they're responsive and seem to value majority opinion. Here's the page: https://github.com/support good idea, I sent them a message which is basically http://stackoverflow.com/questions/26204811/prevent-github-from-interpreting--in-commit-messages Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
I think the arc barrier is significant. Personally, while I feel quite comfortable hacking on Haskell code, system tools are always a bit of a mystery. Those of you who help manage the infrastructure may feel like the tools are easy enough to pick up, but I'm sure there are many competent Haskell programmers out there who dread learning new tooling. (Perhaps I'm a representative sample of this set. I still say `git help merge` before just about every merge, just to make sure that I'm remembering the concepts correctly.) I absolutely believe that we should use the best tools available and that committed GHC contributors should have to learn these tools as necessary. Though I've had my problems with Phab and `arc`, I'm confident that this tool was chosen after a deliberative process and am grateful that we have leaders in this area in our midst. All that said, I think that the suggestion just to accept GitHub pull requests will lead to confusion, if only for the namespace problem. If we start to accept pull requests, then we are de facto going to have to deal with both the GH issue tracker and Trac's (and Phab's), and that is a terrible place to be. Part of the automated response to pull request submissions could be a post on the GH pull request record pointing folks to the Phab review that was created in response. The pull request would then be closed. I agree with the comment that users will be more committed to learn Phab once they have contributed. That's why I wanted to point them to Phab in the automated response to the GH pull request. I think there's a psychological commitment made by a person once they click submit pull request and they will be happy enough to follow up on Phab, especially if commenting and such doesn't require the installation of a local tool. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Show instance for SrcSpan
By all means do so S From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan Kim Zimmerman Sent: 06 October 2014 13:59 To: ghc-devs@haskell.org Subject: Show instance for SrcSpan Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
Richard Eisenberg e...@cis.upenn.edu writes: I absolutely believe that we should use the best tools available and that committed GHC contributors should have to learn these tools as necessary. Though I've had my problems with Phab and `arc`, I'm confident that this tool was chosen after a deliberative process and am grateful that we have leaders in this area in our midst. Agreed. Phab certainly has a learning curve and is not without its papercuts but on the whole seems to be an excellent tool. All that said, I think that the suggestion just to accept GitHub pull requests will lead to confusion, if only for the namespace problem. If we start to accept pull requests, then we are de facto going to have to deal with both the GH issue tracker and Trac's (and Phab's), and that is a terrible place to be. Part of the automated response to pull request submissions could be a post on the GH pull request record pointing folks to the Phab review that was created in response. The pull request would then be closed. This is where I was going with the beginning of a script I posted on Saturday. To me this seems like an excellent compromise: using the familiarity of Github to attract contributions and (hopefully) siphon them into Phabricator. The numbering conflicts may still be problematic but I suspect that in practice people will learn that the Github numbers are meaningless fairly quickly. Cheers, - Ben pgpgUyI9NKHvg.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stepping through ghc
Hi Omar, You might want to narrow your scope to one part of GHC. For example, I mostly focused on the Run Time System to be able to conduct my master's thesis. Also, you might want to start off with a tiny goal, like to fix bug XYZ. Oh, and most important of all is the Commentary, which I think of as a wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary Cheers, Arash On 2014-10-06 17:23, Omar Mefire wrote: Hi, I'm new to ghc codebase and I'm interested in stepping through the code in order to gain a better idea of how it all works. - Is there a way to load ghc into ghci ? and debug through it ? - What are the ways experienced ghc devs step through the code ? - Any techniques you guys recommend ? - What would your advices be for a newbie to the source code ? Thanks, Omar Mefire, ___ 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: Again: Uniques in GHC
Dear Joachim, Although I can't quite get what you're saying from the posts on that link, I'm not immediately sure what you're saying should extend to hi-files. These files are very much specific to the compiler version you're using, as in, new GHCs add stuff to them all the time and their binary format does not (seem to) provision for being able to skip unknown things (i.e. it doesn't say how large the next semantic block is in the hi-file). If we're going to keep the formats the same for any architecture, we're going to have to limit 64-bit machines to 32-bit (actually 30-bits, another thing I don't quite understand in BinIface) Uniques. There seem to be possibilities to alleviate the issues with parallel generation of fresh Uniques in a parallel version of GHC. The idea is that, since 64-bits is more than we'll ever assign anyway, to use a few for thread-ids, so we would guarantee non-conflicting Uniques generated by different threads. Anyway, maybe someone a tad more knowledgeable about Uniques could maybe tell me on what scale Uniques in the hi-files should be unique? Must they only be non-conflicting in a Module? In a Package? If I first compile a file with GHC and then, in a separate invocation of GHC, compile another, surely their hi-files will have some of the same Uniques for their own, different things? Where are these conflicts resolved when linking multiple independently compiled files? Are they ever? Regards, Philip ? From: Joachim Breitner m...@joachim-breitner.de Sent: 06 October 2014 12:36 Subject: Re: Again: Uniques in GHC snip A while ago we had problems with haddock in Debian when the serialization became bit-dependent.^1 I suggest to keep the specification of any on-disk format independent of architecture specifics. Greetings, Joachim ^1 http://bugs.debian.org/586723#15 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Again: Uniques in GHC
Hi, Am Montag, den 06.10.2014, 19:55 + schrieb p.k.f.holzensp...@utwente.nl: Although I can't quite get what you're saying from the posts on that link, I'm not immediately sure what you're saying should extend to hi-files. These files are very much specific to the compiler version you're using, as in, new GHCs add stuff to them all the time and their binary format does not (seem to) provision for being able to skip unknown things (i.e. it doesn't say how large the next semantic block is in the hi-file). Some of this may not be true, but to my knowledge (part of) that interface reading code is (or was?) used by haddock when generating its .haddock file. If we're going to keep the formats the same for any architecture, we're going to have to limit 64-bit machines to 32-bit (actually 30-bits, another thing I don't quite understand in BinIface) Uniques. Why? You can just serialize Uniques always as 64 bit numbers, even on 32-bit systems. This way, the data format is the same across architectures, with little cost. There seem to be possibilities to alleviate the issues with parallel generation of fresh Uniques in a parallel version of GHC. The idea is that, since 64-bits is more than we'll ever assign anyway, to use a few for thread-ids, so we would guarantee non-conflicting Uniques generated by different threads. But that would only work on 64 bit systems, right? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stepping through ghc
Yeah , picking a single subsystem to get started is a very good and healthy idea. On Oct 6, 2014 2:50 PM, Arash Rouhani rar...@student.chalmers.se wrote: Hi Omar, You might want to narrow your scope to one part of GHC. For example, I mostly focused on the Run Time System to be able to conduct my master's thesis. Also, you might want to start off with a tiny goal, like to fix bug XYZ. Oh, and most important of all is the Commentary, which I think of as a wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary Cheers, Arash On 2014-10-06 17:23, Omar Mefire wrote: Hi, I'm new to ghc codebase and I'm interested in stepping through the code in order to gain a better idea of how it all works. - Is there a way to load ghc into ghci ? and debug through it ? - What are the ways experienced ghc devs step through the code ? - Any techniques you guys recommend ? - What would your advices be for a newbie to the source code ? Thanks, Omar Mefire, ___ ghc-devs mailing listghc-devs@haskell.orghttp://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: Tentative high-level plans for 7.10.1
On Mon, Oct 6, 2014 at 5:38 PM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote: The danger, of course, is that people aren't very enthusiastic about bug-fixing older versions of a compiler, but for language/compiler-uptake, this might actually be a Better Way. Maybe some of the commercial GHC users might be interested in donating the manpower to maintain older GHC versions. It's mostly a time-consuming QA auditing process to maintain old GHCs. What can we do to make that process cheaper? In particular, which are the manual steps in making a new GHC release today? I would very much like to know this as well. For ghc-7.8.3 there were a number of people volunteering manpower to finish up the release, but to the best of my knowledge those offers weren't taken up, which makes me think that the extra overhead for coordinating more people would outweigh any gains. From the outside, it appears that the process/workflow could use some improvement, perhaps in ways that would make it simpler to divide up the workload. John L. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Errors building GHC on iOS with LLVM = 3.4
On Sat, Oct 4, 2014 at 7:32 PM, Ben Gamari bgamari.f...@gmail.com wrote: Murray Campbell mur...@sonology.net writes: [snip] before bailing with /var/folders/02/0mv6cz6505x2xhzlr279k234gp/T/ghc6860_0/ghc6860_6-armv7.s:3916:2: error: out of range pc-relative fixup value vldrd8, LCPI70_0 ^ /var/folders/02/0mv6cz6505x2xhzlr279k234gp/T/ghc6860_0/ghc6860_6-armv7s.s:3916:2: error: out of range pc-relative fixup value vldrd8, LCPI70_0 ^ Next I tried to build HEAD (plus phabricator D208) with LLVM 3.4 but got the same error. I've never seen an error of this form. What symbol definitions does this error occur in? I have attached a gzipped version of the *-armv7.s file. The one I attached is from a build with LLVM 3.5. I had to apply D208 D155 to get it to compile. I also had to get the ghc-ios-scripts/arm-apple-darwin10-clang script to pick up the homebrew clang rather than the apple one to get around an 'unknown directive: .maosx_version_min' error. However, the vldr error is identical to that with LLVM 3.4 building 7.8.3. I can get a straight 7.8.3 with LLVM 3.4 version if that would help. The error in the attached file is at line 5988 just below '_c3pb_info$def: '. This is below '_integerzmsimple_GHCziIntegerziType_doubleFromPositive_info$def:' The last lines of build instructions before the error are: inplace/bin/ghc-stage1 -hisuf hi -osuf o -hcsuf hc -static -H64m -O0-this-package-key integ_FpVba29yPwl8vdmOmO0xMS -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/.-optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package-key ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -this-package-key integer-simple -Wall -XHaskell2010 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XUnliftedFFITypes -XNoImplicitPrelude -O -fllvm -no-user-package-db -rtsopts -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o You are using a new version of LLVM that hasn't been tested yet! We will try though... /var/folders/02/0mv6cz6505x2xhzlr279k234gp/T/ghc80302_0/ghc80302_6-armv7.s:5988:2: error: out of range pc-relative fixup value vldrd8, LCPI102_0 ^ /var/folders/02/0mv6cz6505x2xhzlr279k234gp/T/ghc80302_0/ghc80302_6-armv7s.s:5988:2: error: out of range pc-relative fixup value vldrd8, LCPI102_0 ^ ghc80302_6-arm7.s.gz Description: GNU Zip compressed data ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tentative high-level plans for 7.10.1
The steps for making a GHC release are here: https://ghc.haskell.org/trac/ghc/wiki/MakingReleases So, for the record, making a release is not *that* arduous, but it does take time. On average it will take me about 1 day or so to go from absolutely-nothing to release announcement: 1. Bump version, update configure.ac, tag. 2. Build source tarball (this requires 1 build, but can be done very quickly). 3. Make N binary builds for each platform (the most time consuming part, as this requires heavy optimizations in the builds). 4. Upload documentation for all libraries. 5. Update webpage and upload binaries. 6. Send announcement. 7. Upload binaries from other systems later. Herbert has graciously begun taking care of stewarding and uploading the libraries. So, there are a few steps we could introduce to alleviate this process technically in a few ways, but ultimately all of these have to happen, pretty much (regardless of the automation involved). But I don't think this is the real problem. The real problem is that GHC moves forward in terms of implementation extremely, extremely quickly. It is not clear how to reconcile this development pace with something like needing dozens of LTS releases for a stable version. At least, not without a lot of concentrated effort from almost every single developer. A lot of it can be alleviated through social process perhaps, but it's not strictly technical IMO. What do I mean by that? I mean that: - We may introduce a feature in GHC version X.Y - That might have a bug, or other problems. - We may fix it, and in the process, fix up a few other things and refactor HEAD, which will be GHC X.Y+2 eventually. - Repeat steps 2-3 a few times. - Now we want to backport the fixes for that feature in HEAD back to X.Y. - But GHC X.Y has *significantly* diverged from HEAD in that timeframe, because of step 3 being repeated! In other words: we are often so aggressive at refactoring code that the *act* of backporting in and of itself can be complicated, and it gets harder as time goes on - because often the GHC of a year ago is so much different than the GHC of today. As a concrete example of this, let's look at the changes between GHC 7.8.2 and GHC 7.8.3: https://github.com/ghc/ghc/compare/ghc-7.8.2-release...ghc-7.8.3-release There are about ~110 commits between 7.8.2 and 7.8.3. But as the 7.8 branch lived on, backporting fixes became significantly more complex. In fact, I estimate close to 30 of those commits were NOT direct 7.8 requirements - but they were brought in because _actual fixes_ were dependent on them, in non-trivial ways. Take for example f895f33 by Simon PJ, which fixes #9023. The problem with f895f33 is that by the time we fixed the bug in HEAD with that commit, the history had changed significantly from the branch. In order to get f895f33 to plant easily, I had to backport *at least* 12 to 15 other commits, which it was dependent upon, and commits those commits were dependent upon, etc etc. I did not see any non-trivial way to do this otherwise. I believe at one point Gergo backported some of his fixes to 7.8, which had since become 'non applicable' (and I thank him for that greatly), but inevitably we instead brought along the few extra changes anyway, since they were *still* needed for other fixes. And some of them had API changes. So the choice was to rewrite 4 patches for an old codebase completely (the work being done by two separate people) or backport a few extra patches. The above is obviously an extreme case. But it stands to reason this would _only happen again_ with 7.8.4, probably even worse since more months of development have gone by. An LTS release would mandate things like no-API-changes-at-all, but this significantly limits our ability to *actually* backport patches sometimes, like the above, due to dependent changes. The alternative, obviously, is to do what Gergo did and manually re-write such a fix for the older branch. But that means we would have had to do that for *every patch* in the same boat, including 2 or 3 other fixes we needed! Furthermore, while I am a release manager and do think I know a bit about GHC, it is hopeless to expect me to know it all. I will absolutely require coordinated effort to help develop 'retropatches' that don't break API compatibility, from active developers who are involved in their respective features. And they are almost all volunteers! Simon and I are the only ones who wouldn't qualify on that. So - at what point does it stop becoming 'backporting fixes to older versions' and instead become literally working on the older version of the compiler AND the new one in tandem? Given our rate of churn and change internally, this seems like it would be a significant burden in general to ask of developers. If we had an LTS release of GHC that lasted 3 years for example, that would mean developers are expected to work on the current code of their own, *and their old code for the next three
