So, why not put everything on GutHub and use pull requests and so on?
SimonM writes that Phabricator is better than GitHub. I’m happy to believe
that, but he also writes that using it requires installing local software and
quite a bit of work. Moreover, I like to add that lots of people already
On 04/10/2014 12:12 AM, Páli Gábor János wrote:
> 2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg :
>> 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 auth
I assume if the decission is made to use this, the read-only view won't
require any login or registration?
Nicolas
On Jun 6, 2014 6:05 AM, "Austin Seipp" wrote:
> Hello all,
>
> Recently, while doing server maintenance, several of the
> administrators for Haskell.org set up an instance of Phabri
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 th
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 compil
On 6 June 2014 04:27, Sergei Trofimovich wrote:
> Can you write what problems are to ship those libraries in it's current
> form?
> Do you have some linking problems or something?
>
I suppose one could exclude the shared library from the separate distro
packages of terminfo, haskeline and xhtml
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 pu
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 h
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 libphut
The obvious place to put it is on the "Status reports" page, which is one click
from the side bar. A new heading with link to the nightly builds or Travis or
whatever, and some description about how to interpret the information you find.
Simon
| -Original Message-
| From: mad@gmail
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
>
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
automatic
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
> |
> | where refers to the kind of branch-update operation you want
> | to push, li
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? Havin
| 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
|
| where refers to the kind of branch-update operation you want
| to push, like e.g. 'HEAD:master' to update the remote master branch to
| what your c
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 \
ssh
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 pat
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
2014-06-06 3:26 GMT+02:00 Kazu Yamamoto :
> 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 24/7 so the cl
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 s
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 t
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 problem
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
2014-06-06 7:05 GMT+03:00 Austin Seipp :
> 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 be relevant to th
I'm fiddling with the access policies a bit, to make it all publicly
viewable. I thought I fixed it, but apparently not...
In the mean time, you can just register an account (with a
username/password, or just use your existing GitHub login!) and
everything will be viewable.
On Fri, Jun 6, 2014 at
On Fri, Jun 6, 2014 at 1:28 AM, Simon Peyton Jones
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 other
> alternativ
26 matches
Mail list logo
