Re: more releases

[Alex Rozenshteyn]

I have the impression (no data to back it up, though) that no small number
of users download bindists (because most OS packages are out of date:
Debian Unstable is still on 7.8.4, as is Ubuntu Wily; Arch is on 7.10.1).

On Wed, Sep 2, 2015 at 12:04 PM, Ben Gamari  wrote:

> Richard Eisenberg  writes:
>
> > I think some of my idea was misunderstood here: my goal was to have
> > quick releases only from the stable branch. The goal would not be to
> > release the new and shiny, but instead to get bugfixes out to users
> > quicker. The new and shiny (master) would remain as it is now. In
> > other words: more users would be affected by this change than just the
> > vanguard.
> >
> I see. This is something we could certainly do.
>
> It would require, however, that we be more pro-active about
> continuing to merge things to the stable branch after the release.
> Currently the stable branch is essentially in the same state that it was
> in for the 7.10.2 release. I've left it this way as it takes time and
> care to cherry-pick patches to stable. Thusfar my poilcy has been to
> perform this work lazily until it's clear that we will do
> another stable release as otherwise the effort may well be wasted.
>
> So, even if the steps of building, testing, and uploading the release
> are streamlined more frequent releases are still far from free. Whether
> it's a worthwhile cost I don't know.
>
> This is a difficult question to answer without knowing more about how
> typical users actually acquire GHC. For instance, this effort would
> have minimal impact on users who get their compiler through their
> distribution's package manager. On the other hand, if most users
> download GHC bindists directly from the GHC download page, then perhaps
> this would be effort well-spent.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Fwd: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

[Edward Z. Yang]

It's certainly true that hsig is in flux, but it doesn't seem like
injective type families should have broken this test.  I'll take a look.

Edward

Excerpts from Simon Peyton Jones's message of 2015-09-03 09:08:23 -0700:
> Edward
> 
> | Jan's injective type families commit is causing tcfail220 to fail, but
> | that's unrelated to this ticket.
> 
> This is true.  I told Jan to commit anyway because tcfail220 is a "hsig" 
> test, and
>  a) I know that hsigs are in flux (although I am not clear about how)
>  b) I don't understand them enough to fix.
> 
> So I hope it's ok to have broken this.  Jan and I can certainly help when you 
> want to fix it.
> 
> Meanwhile would you mark it as expect-broken.  (Although I am not sure that 
> it's worth opening a fresh ticket for it.)
> 
> thanks
> 
> Simon
> 
> | -Original Message-
> | From: nore...@phabricator.haskell.org
> | [mailto:nore...@phabricator.haskell.org]
> | Sent: 03 September 2015 07:11
> | To: Simon Peyton Jones
> | Subject: [Differential] [Commented On] D1182: Implement improved error
> | messages for ambiguous type variables (#10733)
> | 
> | KaneTW added a comment.
> | 
> | Jan's injective type families commit is causing tcfail220 to fail, but
> | that's unrelated to this ticket.
> | 
> | 
> | REPOSITORY
> |   rGHC Glasgow Haskell Compiler
> | 
> | REVISION DETAIL
> |   https://phabricator.haskell.org/D1182
> | 
> | EMAIL PREFERENCES
> |   https://phabricator.haskell.org/settings/panel/emailpreferences/
> | 
> | To: KaneTW, simonpj, bgamari, austin
> | Cc: goldfire, simonpj, thomie
--- End forwarded message ---
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: D1182: Implement improved error messages for ambiguous type variables (#10733)

[Simon Marlow]

On 03/09/2015 09:08, Simon Peyton Jones wrote:

Edward

| Jan's injective type families commit is causing tcfail220 to fail, but
| that's unrelated to this ticket.

This is true.  I told Jan to commit anyway because tcfail220 is a "hsig" test, 
and
  a) I know that hsigs are in flux (although I am not clear about how)
  b) I don't understand them enough to fix.

So I hope it's ok to have broken this.  Jan and I can certainly help when you 
want to fix it.


In general we shouldn't commit anything that breaks validate, because 
this causes problems for other developers.  The right thing to do would 
be to mark it expect_broken before committing.


Cheers
Simon




Meanwhile would you mark it as expect-broken.  (Although I am not sure that 
it's worth opening a fresh ticket for it.)

thanks

Simon


| -Original Message-
| From: nore...@phabricator.haskell.org
| [mailto:nore...@phabricator.haskell.org]
| Sent: 03 September 2015 07:11
| To: Simon Peyton Jones
| Subject: [Differential] [Commented On] D1182: Implement improved error
| messages for ambiguous type variables (#10733)
|
| KaneTW added a comment.
|
| Jan's injective type families commit is causing tcfail220 to fail, but
| that's unrelated to this ticket.
|
|
| REPOSITORY
|   rGHC Glasgow Haskell Compiler
|
| REVISION DETAIL
|   https://phabricator.haskell.org/D1182
|
| EMAIL PREFERENCES
|   https://phabricator.haskell.org/settings/panel/emailpreferences/
|
| To: KaneTW, simonpj, bgamari, austin
| Cc: goldfire, simonpj, thomie
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

[Thomas Miedema]

The bug is trigger by Maybe now being a wired-in type. See
https://phabricator.haskell.org/D1208 for a workaround.

On Thu, Sep 3, 2015 at 6:13 PM, Edward Z. Yang  wrote:

> It's certainly true that hsig is in flux, but it doesn't seem like
> injective type families should have broken this test.  I'll take a look.
>
> Edward
>
> Excerpts from Simon Peyton Jones's message of 2015-09-03 09:08:23 -0700:
> > Edward
> >
> > | Jan's injective type families commit is causing tcfail220 to fail, but
> > | that's unrelated to this ticket.
> >
> > This is true.  I told Jan to commit anyway because tcfail220 is a "hsig"
> test, and
> >  a) I know that hsigs are in flux (although I am not clear about how)
> >  b) I don't understand them enough to fix.
> >
> > So I hope it's ok to have broken this.  Jan and I can certainly help
> when you want to fix it.
> >
> > Meanwhile would you mark it as expect-broken.  (Although I am not sure
> that it's worth opening a fresh ticket for it.)
> >
> > thanks
> >
> > Simon
> >
> > | -Original Message-
> > | From: nore...@phabricator.haskell.org
> > | [mailto:nore...@phabricator.haskell.org]
> > | Sent: 03 September 2015 07:11
> > | To: Simon Peyton Jones
> > | Subject: [Differential] [Commented On] D1182: Implement improved error
> > | messages for ambiguous type variables (#10733)
> > |
> > | KaneTW added a comment.
> > |
> > | Jan's injective type families commit is causing tcfail220 to fail, but
> > | that's unrelated to this ticket.
> > |
> > |
> > | REPOSITORY
> > |   rGHC Glasgow Haskell Compiler
> > |
> > | REVISION DETAIL
> > |   https://phabricator.haskell.org/D1182
> > |
> > | EMAIL PREFERENCES
> > |   https://phabricator.haskell.org/settings/panel/emailpreferences/
> > |
> > | To: KaneTW, simonpj, bgamari, austin
> > | Cc: goldfire, simonpj, thomie
> --- End forwarded message ---
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Shared data type for extension flags

[Herbert Valerio Riedel]

On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote:
> Surely the easiest way here (including for other tooling - ie
> haskell-src-exts) is to create a package which just provides this
> enumeration. GHC, cabal, th, haskell-src-exts and so on then all
> depend on this package rather than creating their own enumeration.

I'm not sure this is such a good idea having a package many packages
depend on if `ghc` is one of them, as this forces every install-plan
which ends up involving the ghc package to be pinned to the very same
version the `ghc` package was compiled against.

This is a general problem affecting packages `ghc` depends upon (and as
a side-note starting with GHC 7.10, we were finally able to cut the
package-dependency between `ghc` and `Cabal`)

Also, Cabal is not GHC specific, and contains a list of known extensions
(`KnownExtension`) across multiple Haskell compilers

  
https://github.com/haskell/cabal/blob/master/Cabal/Language/Haskell/Extension.hs

and I assume the extension enumeration needed for GHC would be tailored
to GHC's need and omit extensions not relevant to GHC, as well as
include experimental/internal ones not suited for consumption by
Cabal.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

[Simon Peyton Jones]

Edward

| Jan's injective type families commit is causing tcfail220 to fail, but
| that's unrelated to this ticket.

This is true.  I told Jan to commit anyway because tcfail220 is a "hsig" test, 
and
 a) I know that hsigs are in flux (although I am not clear about how)
 b) I don't understand them enough to fix.

So I hope it's ok to have broken this.  Jan and I can certainly help when you 
want to fix it.

Meanwhile would you mark it as expect-broken.  (Although I am not sure that 
it's worth opening a fresh ticket for it.)

thanks

Simon


| -Original Message-
| From: nore...@phabricator.haskell.org
| [mailto:nore...@phabricator.haskell.org]
| Sent: 03 September 2015 07:11
| To: Simon Peyton Jones
| Subject: [Differential] [Commented On] D1182: Implement improved error
| messages for ambiguous type variables (#10733)
| 
| KaneTW added a comment.
| 
| Jan's injective type families commit is causing tcfail220 to fail, but
| that's unrelated to this ticket.
| 
| 
| REPOSITORY
|   rGHC Glasgow Haskell Compiler
| 
| REVISION DETAIL
|   https://phabricator.haskell.org/D1182
| 
| EMAIL PREFERENCES
|   https://phabricator.haskell.org/settings/panel/emailpreferences/
| 
| To: KaneTW, simonpj, bgamari, austin
| Cc: goldfire, simonpj, thomie
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Using GHC API to compile Haskell file

[Edward Z Yang]

Hello Neil,

Sorry about the delay; I hadn't gotten around to seeing if I could reproduce 
it. Here is a working copy of the program which appears to work with GHC 7.10.2 
on 64-bit Windows:

module Main where
import GHC
import GHC.Paths ( libdir )
import DynFlags
import SysTools

main = do
  defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
runGhc (Just libdir) $ do
dflags <- getSessionDynFlags
setSessionDynFlags (gopt_set dflags Opt_Static)
target <- guessTarget "Test.hs" Nothing
setTargets [target]
load LoadAllTargets

Here is how I tested it:

stack ghc -- -package ghc -package ghc-paths --make Main.hs

(after stack installing ghc-paths)

Did you mean the error occurred when you did set Opt_Static? I can’t reproduce 
your specific error in that case either.

Cheers,
Edward

Sent from Windows Mail

From: Neil Mitchell
Sent: ‎Monday‎, ‎August‎ ‎24‎, ‎2015 ‎12‎:‎42‎ ‎AM
To: Edward Z Yang
Cc: ghc-devs@haskell.org

Thanks Edward, that fixed the issue with GHC 7.8.3. While trying to
replicate with 7.10.2 to submit a bug report, I got a different error,
even with your fix included:

C:\Users\NDMIT_~1\AppData\Local\Temp\ghc2428_1\ghc_4.o:ghc_3.c:(.text+0x55):
undefined reference to `ZCMain_main_closure'

Doing another diff of the command lines, I see ghc --make includes
"Test.o" on the Link line, but the API doesn't.

Thanks, Neil


On Mon, Aug 24, 2015 at 12:00 AM, Edward Z. Yang  wrote:
> The problem is that the default code is trying to build a dynamically
> linked executable, but the Windows distributions don't come with dlls
> by default.
>
> Why doesn't the GHC API code pick this up?  Based on snooping
> ghc/Main.hs, it's probably because you need to call parseDynamicFlags*
> which will call updateWays which will turn off -dynamic-too if the
> platform doesn't support it.
>
> GHC bug? Absolutely! Please file a ticket.
>
> Edward
>
> Excerpts from Neil Mitchell's message of 2015-08-23 05:43:28 -0700:
>> Hi,
>>
>> Is this the right place for GHC API queries? If not, is there anywhere 
>> better?
>>
>> I want to compile a Haskell module, much like `ghc --make` or `ghc -c`
>> does. The sample code on the Haskell wiki
>> (https://wiki.haskell.org/GHC/As_a_library#A_Simple_Example),
>> StackOverflow (http://stackoverflow.com/a/5631338/160673) and in GHC
>> API slides 
>> (http://sneezy.cs.nott.ac.uk/fplunch/weblog/wp-content/uploads/2008/12/ghc-api-slidesnotes.pdf)
>> says:
>>
>> import GHC
>> import GHC.Paths ( libdir )
>> import DynFlags
>>
>> main =
>> defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
>>   runGhc (Just libdir) $ do
>> dflags <- getSessionDynFlags
>> setSessionDynFlags dflags
>> target <- guessTarget "Test.hs" Nothing
>> setTargets [target]
>> load LoadAllTargets
>>
>> However, given a `Test.hs` file with the contents `main = print 1`, I
>> get the error:
>>
>> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
>> cannot find -lHSbase-4.7.0.1-ghc7.8.3
>> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
>> cannot find -lHSinteger-gmp-0.5.1.0-ghc7.8.3
>> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
>> cannot find -lHSghc-prim-0.3.1.0-ghc7.8.3
>> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
>> cannot find -lHSrts-ghc7.8.3
>> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
>> cannot find -lffi-6
>> collect2: ld returned 1 exit status
>>
>> Has the recipe changed?
>>
>> By turning up the verbosity, I was able to compare the command line
>> passed to the linker. The failing GHC API call contains:
>>
>> "-lHSbase-4.7.0.1-ghc7.8.3" "-lHSinteger-gmp-0.5.1.0-ghc7.8.3"
>> "-lHSghc-prim-0.3.1.0-ghc7.8.3" "-lHSrts-ghc7.8.3" "-lffi-6"
>>
>> While the succeeding ghc --make contains:
>>
>> "-lHSbase-4.7.0.1" "-lHSinteger-gmp-0.5.1.0"
>> "-lHSghc-prim-0.3.1.0" "-lHSrts" "-lCffi-6"
>>
>> Should I be getting DynFlags differently to influence those link variables?
>>
>> Thanks, Neil
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Shared data type for extension flags

[Reid Barton]

On Thu, Sep 3, 2015 at 12:41 PM, Herbert Valerio Riedel 
wrote:

> On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote:
> > Surely the easiest way here (including for other tooling - ie
> > haskell-src-exts) is to create a package which just provides this
> > enumeration. GHC, cabal, th, haskell-src-exts and so on then all
> > depend on this package rather than creating their own enumeration.
>
> I'm not sure this is such a good idea having a package many packages
> depend on if `ghc` is one of them, as this forces every install-plan
> which ends up involving the ghc package to be pinned to the very same
> version the `ghc` package was compiled against.
>
> This is a general problem affecting packages `ghc` depends upon (and as
> a side-note starting with GHC 7.10, we were finally able to cut the
> package-dependency between `ghc` and `Cabal`)
>

Surely this argument does not apply to a package created to hold data types
that would otherwise live in the template-haskell or ghc packages.

Regards,
Reid Barton
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: D1182: Implement improved error messages for ambiguous type variables (#10733)

[Jan Stolarek]

> In general we shouldn't commit anything that breaks validate, because
> this causes problems for other developers.  The right thing to do would
> be to mark it expect_broken before committing.
Sorry for that. I was actually thinking about marking the test as 
expect_broken, but then the 
problem would be completely hidden> I wanted to discuss a possible solution 
with Simon and Edward 
first but it looks like Thomas already found a workaround.

Jan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

[Edward Z. Yang]

Thanks Thomas, I think this workaround is fine.

Excerpts from Thomas Miedema's message of 2015-09-03 09:17:35 -0700:
> The bug is trigger by Maybe now being a wired-in type. See
> https://phabricator.haskell.org/D1208 for a workaround.
> 
> On Thu, Sep 3, 2015 at 6:13 PM, Edward Z. Yang  wrote:
> 
> > It's certainly true that hsig is in flux, but it doesn't seem like
> > injective type families should have broken this test.  I'll take a look.
> >
> > Edward
> >
> > Excerpts from Simon Peyton Jones's message of 2015-09-03 09:08:23 -0700:
> > > Edward
> > >
> > > | Jan's injective type families commit is causing tcfail220 to fail, but
> > > | that's unrelated to this ticket.
> > >
> > > This is true.  I told Jan to commit anyway because tcfail220 is a "hsig"
> > test, and
> > >  a) I know that hsigs are in flux (although I am not clear about how)
> > >  b) I don't understand them enough to fix.
> > >
> > > So I hope it's ok to have broken this.  Jan and I can certainly help
> > when you want to fix it.
> > >
> > > Meanwhile would you mark it as expect-broken.  (Although I am not sure
> > that it's worth opening a fresh ticket for it.)
> > >
> > > thanks
> > >
> > > Simon
> > >
> > > | -Original Message-
> > > | From: nore...@phabricator.haskell.org
> > > | [mailto:nore...@phabricator.haskell.org]
> > > | Sent: 03 September 2015 07:11
> > > | To: Simon Peyton Jones
> > > | Subject: [Differential] [Commented On] D1182: Implement improved error
> > > | messages for ambiguous type variables (#10733)
> > > |
> > > | KaneTW added a comment.
> > > |
> > > | Jan's injective type families commit is causing tcfail220 to fail, but
> > > | that's unrelated to this ticket.
> > > |
> > > |
> > > | REPOSITORY
> > > |   rGHC Glasgow Haskell Compiler
> > > |
> > > | REVISION DETAIL
> > > |   https://phabricator.haskell.org/D1182
> > > |
> > > | EMAIL PREFERENCES
> > > |   https://phabricator.haskell.org/settings/panel/emailpreferences/
> > > |
> > > | To: KaneTW, simonpj, bgamari, austin
> > > | Cc: goldfire, simonpj, thomie
> > --- End forwarded message ---
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

addTopDecls restrictions

[Richard Eisenberg]

Hi Geoff,

The TH addTopDecls function is restricted to only a few kinds of declarations 
(functions, mostly). This set has been expanded in #10486 
(https://ghc.haskell.org/trac/ghc/ticket/10486). Do you remember why the set of 
allowed declarations is restricted? It looks to me like any declaration would 
be OK.

Thanks!
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Joe Hillenbrand]

> As a wild idea -- did anyone look at /Gitlab/ instead?

My personal experience with Gitlab at a previous job is that it is
extremely unstable. I'd say even more unstable than trac and
phabricator. It's especially bad when dealing with long files.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Thomas Miedema]

>
> The real hint is that "the number of contributions will go up". That's
> a noble goal and I think it's at the heart of this proposal.
>

It's not. What's at the heart of my proposal is that `arc` sucks. Most of
those quotes I posted are from regular contributors (here's another
one: "arcanist kinda makes stuff even more confusing than Git by itself").
Newcomers will give it their best shot, thinking it's just another thing
they need to learn, thinking it's their fault for running into problems,
thinking they'll get the hang of it eventually. Except they won't, or at
least I haven't, after using it for over a year.

Maybe the fundamental problem with Phabricator is that it doesn't
understand Git well, and the problems I posted on
https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator are just symptoms
of it. I'm having trouble putting this into words though (something about
branches and submodules). Perhaps someone else can?

In my opinion it's is a waste of our time trying to improve `arc` (it is
34000 lines of PHP btw + another 7 LOC for libphutil), when `pull
requests` are an obvious alternative that most of the Haskell community
already uses.

When you're going to require contributors to use a non-standard tool to get
patches to your code review system, it better just work. `arc` is clearly
failing us here, and I'm saying enough is enough.

I need to think about your other points. Thank you for the thorough reply.





> Here's the meat of it question: what is the cost of achieving this
> goal? That is, what amount of work is sufficient to make this goal
> realizable, and finally - why is GitHub *the best use of our time for
> achieving this?* That's one aspect of the cost - that it's the best
> use of the time. I feel like this is fundamentally why I always seem
> to never 'get' this argument, and I'm sure it's very frustrating on
> behalf of the people who have talked to me about it and like GitHub.
> But I feel like I've never gotten a straight answer for GHC.
>
> If the goal is actually "make more people contribute", that's pretty
> broad. I can make that very easy: give everyone who ever submits a
> patch push access. This is a legitimate way to run large projects that
> has worked. People will almost certainly be more willing to commit,
> especially when overhead on patch submission is reduced so much. Why
> not just do that instead? It's not like we even mandate code review,
> although we could. You could reasonably trust CI to catch and revert
> things a lot of the time for people who commit directly to master. We
> all do it sometimes.
>
> I'm being serious about this. I can start doing that tomorrow because
> the *cost is low*, both now and reasonably speaking into some
> foreseeable future. It is one of many solutions to raw heart of the
> proposal. GitHub is not a low cost move, but also, it is a *long term
> cost* because of the technical deficiencies it won't aim to address
> (merge commits are ugly, branch reviews are weak, ticket/PR namespace
> overlaps with Trac, etc etc) or that we'll have to work around.
>
> That means that if we want GitHub to fix the "give us more
> contributors" problem, and it has a high cost, it not only has _to fix
> the problem_, it also has to do that well enough to offset its cost. I
> don't think it's clear that is the case right now, among a lot of
> other solutions.
>
> I don't think the root issue is "We _need_ GitHub to get more
> contributors". It sounds like the complaint is more "I don't like how
> Phabricator works right now". That's an important distinction, because
> the latter is not only more specific, it's more actionable:
>
>   - Things like Arcanist can be tracked as a Git submodule. There is
> little to no pain in this, it's low cost, and it can always be
> synchronized with Phabricator. This eliminates the "Must clone
> arcanist" and "need to upgrade arcanist" points.
>
>   - Similarly when Phabricator sometimes kills a lot of builds, it's
> because I do an upgrade. That's mostly an error on my part and I can
> simply schedule upgrades regularly, barring hotfixes or somesuch. That
> should basically eliminate these. The other build issues are from
> picking the wrong base commit from the revision, I think, which I
> believe should be fixable upstream (I need to get a solid example of
> one that isn't a mega ultra patch.)
>
>   - If Harbormaster is not building dependent patches as mentioned in
> WhyNotPhabricator, that is a bug, and I have not been aware of it.
> Please make me aware of it so I can file bugs! I seriously don't look
> at _every_ patch, I need to know this. That could have probably been
> fixed ASAP otherwise.
>
>   - We can get rid of the awkwardness of squashes etc by using
> Phabricator's "immutable" history, although it introduces merge
> commits. Whether this is acceptable is up to debate (I dislike merge
> commits, but could live with it).
>
>   - I do not understand point #3, about answering questions. Here's

Re: Proposal: accept pull requests on GitHub

[Vincent Hanquez]

On 03/09/2015 10:53, Thomas Miedema wrote:


The real hint is that "the number of contributions will go up". That's
a noble goal and I think it's at the heart of this proposal.


When you're going to require contributors to use a non-standard tool 
to get patches to your code review system, it better just work. `arc` 
is clearly failing us here, and I'm saying enough is enough.
Not only this, but there's (probably) lots of small/janitorial 
contributions that do not need the full power of phabricator or any 
sophisticated code review.


Not accepting github PRs and forcing everyone to go through an uncommon 
tool (however formidable), is quite likely to turn those contributions 
away IMHO.


--
Vincent
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Thomas Miedema]

On Thu, Sep 3, 2015 at 12:43 PM, Vincent Hanquez  wrote:

> there's (probably) lots of small/janitorial contributions that do not need
> the full power of phabricator or any sophisticated code review.
>

Austin's point, and I agree, is that we shouldn't optimize the system for
those contributions. Cleanup, documentation and other small patches are
very much welcomed, and they usually get merged within a few days. To make
a truly better GHC though, we very much depend on expert contributors, say
to implement and review Backpack or DWARF-based backtraces. My point is
that `arc` is hurting these expert contributors as much, if not more than
everyone else. To get more expert contributors you need more newcomers, but
don't optimize the system only for the newcomers.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Diffusion] [Committed] rGHCbe0ce8718ea4: Fix for crash in setnumcapabilities001

[Thomas Miedema]

Simon,

for what it's worth, I sporadically (< once per month) see this test timing
out on Phabricator.

Latest occurence:
https://phabricator.haskell.org/harbormaster/build/5904/?l=0

Thomas

On Fri, Jun 26, 2015 at 10:32 AM, simonmar (Simon Marlow) <
nore...@phabricator.haskell.org> wrote:

> simonmar committed rGHCbe0ce8718ea4: Fix for crash in
> setnumcapabilities001 (authored by simonmar).
>
> Fix for crash in setnumcapabilities001
>
> getNewNursery() was unconditionally incrementing next_nursery, which
> is normally fine but it broke an assumption in
> storageAddCapabilities(). This manifested as an occasional crash in
> the setnumcapabilities001 test.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: UNS: Re: Proposal: accept pull requests on GitHub

[Kosyrev Serge]

Joe Hillenbrand  writes:
>> As a wild idea -- did anyone look at /Gitlab/ instead?
>
> My personal experience with Gitlab at a previous job is that it is
> extremely unstable. I'd say even more unstable than trac and
> phabricator. It's especially bad when dealing with long files.

Curiously, for the nearly three years that we've been dealing with it,
I couldn't have pointed at a single instability (or even just a bug),
despite using a moderately loaded instance of Gitlab.

Also, not being a huge enterprise yet, Gitlab folks /might/ potentially
be more responsive to feature requests from a prominent open-source
project..


-- 
с уважениeм / respectfully,
Косырев Серёга
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Foreign calls and periodic alarm signals

[Simon Marlow]

On 02/09/2015 15:42, Phil Ruffwind wrote:

TL;DR: Does 'foreign import safe' silence the periodic alarm signals?


No it doesn't.  Perhaps the fact that a safe FFI call may create another 
worker thread means that the timer signal has gone to the other thread 
and didn't interrupt the thread making the statfs64() call.


There's pthread_setmask() that could help, but it's pretty difficult to 
do this in a consistent way because we'd have to pthread_setmask() every 
thread that runs Haskell code, including calls from outside.  I'm not 
sure yet what the right solution is, but a good start would be to open a 
ticket.


Cheers
Simon


I received a report on this rather strange bug in 'directory':

https://github.com/haskell/directory/issues/35#issuecomment-136890912

I've concluded based on the dtruss log that it's caused by the timer
signal that the GHC runtime emits.  Somewhere inside the guts of
'realpath' on Mac OS X, there is a function that does the moral
equivalent of:

 while (statfs64(…) && errno == EINTR);

On a slow filesystem like SSHFS, this can cause a permanent hang from
the barrage of signals.

The reporter found that using 'foreign import safe' mitigates the
issue.  What I'm curious mainly is that: is something that the GHC
runtime guarantees -- is using 'foreign import safe' assured to turn
off the periodic signals for that thread?

I tried reading this article [1], which seems to be the only
documentation I could find about this, and it didn't really go into
much depth about them.  (I also couldn't find any info about how
frequently they occur, on which threads they occur, or which specific
signal it uses.)

I'm also concerned whether there are other foreign functions out in
the wild that could suffer the same bug, but remain hidden because
they normally complete before the next alarm signal.

[1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Tuncer Ayaz]

On Thu, Sep 3, 2015 at 6:41 AM, Austin Seipp  wrote:
> (JFYI: I hate to announce my return with a giant novel of
> negative-nancy-ness about a proposal that just came up. I'm sorry
> about this!)
>
> TL;DR: I'm strongly -1 on this, because I think it introduces a lot
> of associated costs for everyone, the benefits aren't really clear,
> and I think it obscures the real core issue about "how do we get
> more contributors" and how to make that happen. Needless to say,
> GitHub does not magically solve both of these AFAICS.

Let me start off by saying I'm not arguing for GitHub or anything else
to replace Phabricator. I'm merely trying to understand the problems
with merge commits and patch sets.

>   - We can get rid of the awkwardness of squashes etc by using
> Phabricator's "immutable" history, although it introduces merge
> commits. Whether this is acceptable is up to debate (I dislike merge
> commits, but could live with it).

I'm genuinely curious about the need to avoid merge commits. I do
avoid merge-master-to-topic-branch commits in submitted diffs, but
unless you always only merge a single cumulative commit for each diff,
merge commits are very useful for vcs history.

>   - As for some of the quotes, some of them are funny, but the real
> message lies in the context. :) In particular, there have been
> several cases (such as the DWARF work) where the idea was "write 30
> commits and put them on Phabricator". News flash: *this is bad*, no
> matter whether you're using Phabricator or not, because it makes
> reviewing the whole thing immensely difficult from a reviewer
> perspective. The point here is that we can clear this up by being
> more communicative about what we expect of authors of large patches,
> and communicating your intent ASAP so we can get patches in as fast
> as possible. Writing a patch is the easiest part of the work.

I would also like to understand why reviewing a single commit is
easier than the steps (commits) that led to the whole diff. Maybe I
review stuff differently, but, as I wrote yesterday, I've always found
it easier to follow the changes when it's split into proper commits.
And instead of "big patch" I should have written "non-trivial patch".
A 100-line unified diff can be equally hard to follow as a 1000-line
diff, unless each diff hunk is accompanied with code comments. But
comments don't always make sense in the code, and often enough it's
best to keep it in the commit message only. Hence the need for
splitting the work, and ideally committing as you work on it, with a
final cleanup of rearranging commits into a proper set of commits. I'm
repeating myself, but git-bisect is much more precise with relevant
changes split up as they happened.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Bardur Arantsson]

On 09/03/2015 09:18 AM, Joe Hillenbrand wrote:
>> As a wild idea -- did anyone look at /Gitlab/ instead?
> 
> My personal experience with Gitlab at a previous job is that it is
> extremely unstable. I'd say even more unstable than trac and
> phabricator. It's especially bad when dealing with long files.
> 

If we're talking alternative systems, then I can personally recommend
Gerrit (https://www.gerritcodereview.com/) which, while it *looks*
pretty basic, it  works really well with the general Git workflow. For
example, it tracks commits in individual reviews, but tracks
dependencies between those commits. So when e.g. you push a new series
of commits implementing a feature, all those reviews just get a new
"version" and you can diff between different versions of each individual
commit -- this often cuts down drastically on how much you have to
re-review when a new version is submitted.

You can also specify auto-merge when a review gets +2 (or +1, or
whatever), including rebase-before-merge-and-ff instead of having merge
commits which just clutter the history needlessly.

You can set up various rules using a predicate-based rules engine, for
example about a review needing two approvals and/or always needing
approval from an (external) build system, etc.

The only setup it needs in a git hook... which it will tell you exactly
how to install with a single command when you push your first review.
(It's some scp command, I seem to recall.)

Caveat: I haven't tried using it on Windows.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A process for reporting security-sensitive issues

[Adam Gundry]

On 03/09/15 08:22, Michael Smith wrote:
> I feel there should be some process for reporting security-sensitive issues
> in GHC -- for example, #9562 and #10826 in Trac. Perhaps something like the
> SensitiveTicketsPlugin [3] could be used?
> 
> [1] https://ghc.haskell.org/trac/ghc/ticket/9562
> [2] https://ghc.haskell.org/trac/ghc/ticket/10826
> [3] https://trac-hacks.org/wiki/SensitiveTicketsPlugin

Thanks for raising this. While I see where you are coming from, I'm
going to argue against it, because I think it creates a false impression
of the security guarantees GHC provides. Such a process may give the
impression that there are people directly tasked with handling such
security bugs, which is not currently the case.

I think it is unreasonable for the security of a system to depend on GHC
having no type soundness bugs, particularly since GHC is actively used
for developing experimental type system features. #9562 has been open
for a year and we don't have a good solution.

Relatedly, I think the Safe Haskell documentation should prominently
warn about the existence of #9562 and the possibility of other type
soundness bugs, like it does for compilation safety issues.

What do others think?

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs