At the moment GHC's main sources aren't on github, which means that that (in my
highly imperfect understanding) people can't submit pull requests or use their
code review mechanisms. Moreover, most people don't have commit rights on the
main GHC server, so if someone wants to offer a patch
PS I couldn't get past the login box at https://phabricator.haskell.org/D4
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin
| Seipp
| Sent: 06 June 2014 05:06
| To: ghc-devs@haskell.org
| Subject: RFC: Phabricator for patches and code review
On Fri, Jun 6, 2014 at 1:28 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
So we really don't have a good work flow for creating, reviewing, modifying,
and finally apply patches. I am no expert on these matters. If Phabricator
would help with that I'm all for it. But perhaps there are
2014-06-06 7:05 GMT+03:00 Austin Seipp aus...@well-typed.com:
2) Phabricator in particular makes it very easy to submit patches for
review. To submit a patch, I just run the command 'arc diff' and it
Does The Right Thing. It also makes it easy to ensure people are
*alerted* when a patch might
The motivation for this design is to make it so that
let
f = \x . E
in
... f y ...
Gives the same call stack as
... (\x . E) y ...
That is, inlining a function does not change the call stack. GHC
assumes that this is valid, so the call stack semantics should reflect that.
I want to change the interface to PatSyn.patSynSig, as part of fixing a bug in
7.8.2. But Haddock calls patSynSig, so there is a (fairly trivial) knock on
change to Haddock
Is that acceptable in a 7.8.3 release cycle?
If not, I can program round it in the 7.8.3 branch. But if it's not a
tl;dir I strongly support this, but for code review only, and only if we
can integrate it well with Trac.
Phabricator is what we use internally at Facebook, and it's a really
good code review tool (better than github, IMO). For one thing, you
only get one email for a complete review, rather
On 06/06/2014 11:44 AM, Simon Peyton Jones wrote:
I want to change the interface to PatSyn.patSynSig, as part of fixing a bug
in 7.8.2. But Haddock calls patSynSig, so there is a (fairly trivial) knock
on change to Haddock
Is that acceptable in a 7.8.3 release cycle?
There are already some
2014-06-06 3:26 GMT+02:00 Kazu Yamamoto k...@iij.ad.jp:
I have one Mac Pro to build GHC. But it is behind a firewall.
Is this useful for this purpose?
If it can reach the server (haskell.inf.elte.hu) on port 4938 then you
are probably good to go. The other requirement would be to able to
run
I'm trying desperately to follow the instructions on
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules for how
to update haddock to follow a small change to GHC.
I've checked out the haddock master, made my patch, and want to push to
haddock. But my push is rejected for an
On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote:
I'm trying desperately to follow the instructions on
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
for how to update haddock to follow a small change to GHC.
I've checked out the haddock master, made my patch,
On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote:
[...]
To ssh://g...@ghc.haskell.org/haddock.git
PS: you could also try to configure the following (assuming your Git is
new enough):
git config --global \
url.ssh://g...@github.com/haskell/haddock.git.pushInsteadOf \
| Short story: you have to use ssh://g...@github.com/haskell/haddock.git as
| push-url
|
| git push ssh://g...@github.com/haskell/haddock.git refspec
|
| where refspec refers to the kind of branch-update operation you want
| to push, like e.g. 'HEAD:master' to update the remote master branch
I ran that command and it didn't complain. No idea whether it worked or not
though! This now appears in .gitconfig
[url ssh://g...@github.com/haskell/haddock.git]
pushInsteadOf = ssh://g...@ghc.haskell.org/haddock.git
But shouldn't sync-all set this push-url stuff up correctly? Having
On 2014-06-06 at 14:07:44 +0200, Simon Peyton Jones wrote:
| Short story: you have to use ssh://g...@github.com/haskell/haddock.git as
| push-url
|
| git push ssh://g...@github.com/haskell/haddock.git refspec
|
| where refspec refers to the kind of branch-update operation you want
| to
On 2014-06-06 at 14:11:21 +0200, Simon Peyton Jones wrote:
I ran that command and it didn't complain. No idea whether it worked or not
though! This now appears in .gitconfig
[url ssh://g...@github.com/haskell/haddock.git]
pushInsteadOf = ssh://g...@ghc.haskell.org/haddock.git
But
Michael
I think that would be great. Absolutely: the earlier we can catch regressions
the better.
Couldn’t we make it part of the continuous-integration builds (Travis?) that
various folk are running, eg. Joachim?
I’m hazy about how all of this works, but I’d love it just to happen
I haven't looked deeply into Trac integration yet, but I believe this
should generally be possible. I'll probably pester the developers
about it later today. I'm glad people seem receptive to it.
I don't think Arcanist will be a barrier, actually. Here's what I
propose: we add arcanist and
Hi,
Am Freitag, den 06.06.2014, 12:37 + schrieb Simon Peyton Jones:
I think that would be great. Absolutely: the earlier we can catch
regressions the better.
Couldn’t we make it part of the continuous-integration builds
(Travis?) that various folk are running, eg. Joachim?
Travis has a
No, at the moment Phabricator is not integrated with any testing
functionality. It could be, but that would be a bit of work I think to
integrate with GHC's ./validate process. It would be nice to have
long-term, however, but I don't think it's necessary right now - I run
./validate before every
Piggybacking a bit on Ömer's point:
It is often the case that something flies by that I can fix in a few moments
(for example, #9163) but that I have to defer until I have enough time for a
GHC hacking session. Making even a tiny patch requires that I'm up-to-date,
that my unchanged tree
Richard, I think Phabricator would suit this just fine.
Here's (roughly) how Phabricator will work from a GHC hackers point of view.
1) I have a thing I want. Make a branch, hack hack hack away.
$ git branch new-thing
$ git checkout new-thing
$ emacs
$ git commit -a -m Add minor new
22 matches
Mail list logo
