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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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,
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
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.
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
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 ?
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
35 matches
Mail list logo
