ghc-prim 0.5.1.1 not on Hackage

[Michael Snoyman]

The Stackage issue tracker just received an issue about ghc-prim 0.5.1.1.

https://github.com/fpco/stackage/issues/3115

This version of the package has not been uploaded to Hackage, so:

* The Stackage snapshots refer to 0.5.1.1
* The stackage.org documentation shows version 0.5.1.1
* `stack unpack` and `cabal unpack` both fail on ghc-prim-0.5.1.1

Also, it appears that the GHC 8.2.2 release notes still refer to ghc-prim
0.5.1.0.

I'm happy to file an issue for this, but last time this popped up it was
unclear if the issue should be filed on GHC Trac or the Hackage Trustees
issue tracker.

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

Re: [GHC DevOps Group] Release policies

[Michael Snoyman]

Thanks for spelling this out Gershom. Reading it through, here are my
questions:

1. What's the definition of "feature freeze"? Does it mean API stability?
Does it mean not code changes at all except to fix a bug? Are performance
fixes allowed in that case?
2. What's the minimum time between GHC cutting a feature-freeze branch and
the first release candidate? And the minimum time between first release
candidate and official release? Obviously, if each of these is 1 week
(which I can't imagine would be the case), then these libraries could cut a
feature-freeze branch after the official release, which obviously isn't
intended. I apologize if these timings are already well established, I'm
not familiar enough with GHC release cadence to know.

I can't speak to GHC development itself, but from a downstream perspective,
this sounds like the right direction.

On Mon, Dec 18, 2017 at 9:41 PM, Gershom B  wrote:

> Let me try to formulate a synthetic policy as per Simon's request:
>
> Policy:
> Bundled library maintainers agree to the following:
>   1) When GHC cuts a feature-freeze branch, they too (if anything has
> changed) cut a feature-freeze branch within two weeks at the maximum
> (ideally sooner), to be included in the main GHC freeze branch. If
> they do not do so, the last released version will be included instead.
>   2) When GHC releases the first release candidate, maintainers (if
> anything has changed) release new versions of their packages, to then
> be depended on directly in the GHC repo. All submodules are then
> replaced with their proper released versions for GHC release.
>
> This policy can be enforced by GHC hq as part of the release process
> with the exception of a case in which there's coupling so that a new
> GHC _requires_ a new submodule release, and also the maintainer is not
> responsive. We'll have to deal with that case directly, likely by just
> appealing to the libraries committee or something to force a new
> release :-)
>
> Motivation:
> This should help address multiple issues: 1) holdup of ghc on other
> releases. 2) lack of synchronization with ghc and other releases. 3)
> low lead-time for people to adapt to API changes in forthcoming
> library releases tied to ghc releases. In particular, because Cabal is
> part of this policy, it should help circumvent the sorts of problems
> that led to this thread initially. Further, because this only applies
> to freeze/release branches, it should not slow down
> rapid-implementation of cross-cutting changes more generally.
>
> Cheers,
> Gershom
> ___
> 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: Fwd: Release policies

[Michael Snoyman]

On Fri, Dec 15, 2017, 6:23 PM Simon Peyton Jones <simo...@microsoft.com>
wrote:

> Therefore bytestring, process, containers, transformers, and many more
> will be pinned in a Stackage snapshot.
>
> So that would make it significantly harder, even impossible, for GHC
> releases to make any promises about the .cabal-file format of these
> packages, wouldn’t it?
>
>
>
> So even if we made some back-compat promise for non-reinstallable things
> like integer-gmp or base, we could not do so for bytestring.
>
>
>
> Does that give you cause for concern?   After all, it’s where Trac #14558
> started.  I don’t see how we can avoid the original problem, since we don’t
> have control over the .cabal file format used by the authors of the
> packages on which we depend.
>
>
>
> Still: GHC can only depend on a package P if the version X of Cabal that
> GHC is using can parse P.cabal.  So if we fix Cabal-X some while in advance
> and announce that, perhaps that would serve the purpose?
>
>
>
> Simon
>
>
>
That will certainly help. Even if GHC can't force any behavior on upstream
packages, perhaps just an official request that new features in the cabal
file format be held off on would be sufficient. After all, the case in the
Trac issue was a situation where the new cabal feature want necessary. I
would imagine that in the vast majority of cases, maintaining backwards
compatibility in these packages will not only be desirable, but relatively
trivial.


*From:* Michael Snoyman [mailto:mich...@snoyman.com]
> *Sent:* 15 December 2017 09:27
>
>
> *To:* Simon Peyton Jones <simo...@microsoft.com>
>
> *Cc:* Boespflug, Mathieu <m...@tweag.io>; Ben Gamari <b...@well-typed.com>;
> ghc-devs <ghc-devs@haskell.org>
>
>
> *Subject:* Re: Fwd: Release policies
>
>
>
>
>
>
>
> On Fri, Dec 15, 2017 at 12:10 PM, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> |  at this point in time Stackage works
> |  hard to ensure that in any given package set, there is *exactly one*
> |  version of any package. That's why Stackage aligns versions of core
> |  packages to whatever ships with the GHC version the package set is
> |  based on.
>
> Ah. It follows that if Stackage wants to find a set of packages compatible
> with GHC-X, then it must pick precisely the version of bytestring that
> GHC-X depends on.  (I'm assuming here that GHC-X fixes a particular
> version, even though bytestring is reinstallable?  Certainly, a
> /distribution/ of GHC-X will do so.)
>
> If meanwhile the bytestring author has decided to use a newer version of
> .cabal file syntax, then GHC-X is stuck with that.  Or would have to go
> back to an earlier version of bytestring, for which there might be material
> disadvantages.
>
> That would make it hard to GHC to guarantee to downstream tools that it
> doesn't depend on any packages whose .cabal files use new syntax; which is
> where this thread started.
>
> Hmm.  I wonder if I have understood this correctly.  Perhaps Michael would
> like to comment?
>
>
>
> Stackage does in fact pin snapshots down to precisely one version of each
> package. And in the case of non-reinstallable packages, it ensures that
> those package's transitive dependency set are pinned to the same version
> that ships with GHC. I know there's work around making more package
> reinstallable, and the ghc package itself may have crossed that line now,
> but for the moment Stackage assumes that the ghc package and all its
> dependencies are non-reinstallable. Therefore bytestring, process,
> containers, transformers, and many more will be pinned in a Stackage
> snapshot.
>
>
>
> Michael
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fwd: Release policies

[Michael Snoyman]

On Fri, Dec 15, 2017 at 12:10 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> |  at this point in time Stackage works
> |  hard to ensure that in any given package set, there is *exactly one*
> |  version of any package. That's why Stackage aligns versions of core
> |  packages to whatever ships with the GHC version the package set is
> |  based on.
>
> Ah. It follows that if Stackage wants to find a set of packages compatible
> with GHC-X, then it must pick precisely the version of bytestring that
> GHC-X depends on.  (I'm assuming here that GHC-X fixes a particular
> version, even though bytestring is reinstallable?  Certainly, a
> /distribution/ of GHC-X will do so.)
>
> If meanwhile the bytestring author has decided to use a newer version of
> .cabal file syntax, then GHC-X is stuck with that.  Or would have to go
> back to an earlier version of bytestring, for which there might be material
> disadvantages.
>
> That would make it hard to GHC to guarantee to downstream tools that it
> doesn't depend on any packages whose .cabal files use new syntax; which is
> where this thread started.
>
> Hmm.  I wonder if I have understood this correctly.  Perhaps Michael would
> like to comment?
>
>
>
Stackage does in fact pin snapshots down to precisely one version of each
package. And in the case of non-reinstallable packages, it ensures that
those package's transitive dependency set are pinned to the same version
that ships with GHC. I know there's work around making more package
reinstallable, and the ghc package itself may have crossed that line now,
but for the moment Stackage assumes that the ghc package and all its
dependencies are non-reinstallable. Therefore bytestring, process,
containers, transformers, and many more will be pinned in a Stackage
snapshot.

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

Re: Fwd: Release policies

[Michael Snoyman]

On Thu, Dec 14, 2017 at 12:27 PM, Boespflug, Mathieu  wrote:

[snip]

* Or a middle ground: make feature freeze a thing. Meaning that for a
> couple of months before a major GHC release, the major new Cabal isn't
> technically released yet, but like GHC itself within this period, it's
> pretty staid, so not so much a moving target, and something downstream
> tooling authors can possibly adapt to even without any grace period on
> new metadata features. This assumes that the 2 months of feature
> freeze are enough time for downstream tooling. Thoughts from any of
> those maintainers?
>
>
Short answer: if there's a clear idea in advance of when this feature
freeze is going to happen, I think we can coordinate releases of downstream
tooling (Stack being the most important, but stackage-curator playing in as
well) so that 2 months is sufficient. I'll talk with the rest of the Stack
team to see if there are any concerns.

Longer answer: Stack intentionally avoids depending on the internals of
Cabal wherever possible. Instead of calling library functions directly from
within Haskell code to perform builds, for example, it interacts with the
Setup.hs files over their command line interface.[1] This has two results:

* Stack can usually start using new GHC/Cabal versions without a new Stack
release, since it's just shelling out for the actual build
* There's not usually very much code churn needed in Stack to upgrade to a
newer Cabal release

This past release was an exception because of all of the changes that
landed, both the new cabal grammar to support the ^>= operator (making the
old parser incapable of lossily parsing new files) and API changes (I think
mostly around Backpack, though there was some code cleanup as well). In
particular, the main interface we need from Cabal—the package description
data types and parser—changed significantly enough that it took significant
effort to upgrade. There were also new features added (like sub libraries
and foreign libraries) that weren't immediately supported by the old Stack
version, and had to be manually added in.

Tying this up: generally upgrading to a new Cabal release should be fine,
and the only concern I'd have is fitting it into a release schedule with
Stack. The complications that could slow that down are:

* Changes to the command line interface that Stack uses (hopefully those
are exceedingly rare)
* Major overhauls to the Stack-facing API

Michael

[1] This allows for more reproducible builds of older snapshots, insuring
that the exact same Cabal library is performing the builds
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Remove deprecated quasiquote syntax

[Michael Snoyman]

I think I'm the one who requested that the backwards compatibility be added
back in. I have no objection to removing it at this point.

On Wed, Nov 25, 2015 at 2:11 PM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> The [$qq| quasiquote syntax has been deprecated since around 2010.
>
> Is there any objection to removing the backwards compatibility now?
>
> I counted 216 uses of it on hackage in a handful of packages, some in
> comments.
>
> http://lpaste.net/145938
>
> Here is the commit which deprecated it -
> https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78126e
>
> Matt
> ___
> 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: process librarry

[Michael Snoyman]

Can you try updating the submodule to the latest master and see if that
fixes it for you?

On Tue, Nov 17, 2015, 1:25 AM Simon Peyton Jones 
wrote:

> Michael
>
> My Windows build (sh validate in a clean tree) is still falling over as
> follows, on Windows.   Would it be possible to fix the process library to
> stop this happening?
>
> Thanks
>
> Simon
>
>
>
> libraries\process\System\Process\Internals.hs:106:16: warning:
>
> Defined but not used: data constructor `CGid'
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: process library broken on Windows

[Michael Snoyman]

I didn't read closely enough: I see now that it's a warning, not an error.
I initially didn't export that constructor since it's only present on
Windows for API compatibility, but will never be used. Since this is just
the internals module, I can export it, but my preference would in fact be
to leave it as-is with the warning. Two alternatives:

1. Create a new hidden module that creates and exports the type
constructor, just to hide the warning. I'm -1 on that, since that's extra
compile time everyone has to endure just for warning avoidance.
2. base could export CGid for Windows (currently, it does not).

On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman <mich...@snoyman.com> wrote:

> I'll look into this. I just made a new release of process, and was certain
> I tested on Windows, but perhaps something changed between that commit and
> release.
>
> On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones <simo...@microsoft.com>
> wrote:
>
>> I’m getting this on HEAD in te ‘
>>
>> libraries\process\System\Process\Internals.hs:106:16: warning:
>>
>> Defined but not used: data constructor ‘CGid’
>>
>> Indeed it looks as if CGId(..) should be exported, else createProcess is
>> unusuable.  This looks like the right change.  Would someone like to check
>> and make the change
>>
>> Simon
>>
>> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs
>>
>> index 5575ac4..3e23ad5 100644
>>
>> --- a/System/Process/Internals.hs
>>
>> +++ b/System/Process/Internals.hs
>>
>> @@ -37,6 +37,8 @@ module System.Process.Internals (
>>
>> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)
>>
>>  pPrPr_disableITimers, c_execvpe,
>>
>>  ignoreSignal, defaultSignal,
>>
>> +#else
>>
>> +CGid(..), GroupID, UserID,
>>
>> #endif
>>
>>  withFilePathException, withCEnvironment,
>>
>>  translate,
>>
>> ___
>> 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: process library broken on Windows

[Michael Snoyman]

On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones <simo...@microsoft.com>
wrote:

> Aha.  It would be great to say all that in the source code!!  It’s very
> non-obvious that you not want people ever to construct a CGId on Windows.
> After all, it has a newtype definition!
>
>
>

Good call, I'll update with some comments (though see refactoring comments
below).


> Could you declare it differently?
>
> data CGId   -- No constructors
>
>
Certainly we could. Then the question would be "why does the Windows code
look so different?" There are lots of colors to this bikeshed, and I don't
have any particular affinity to any of them. If you'd prefer it looked that
way, I can make that change. I initially erred with making the code as
similar to the POSIX code as possible.


>
>
> Also if so, why does the Windows-specific foreign import of
> c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You’d just told me
> that we can never create one.
>
>

The Windows-specific foreign import is on line ~533, and does not include
those arguments.


>
>
> Also,
>
> · It’d help to comment the #else on line 456 as being “else if
> not windows”
>
> · The #endifs on line 546 or thereabouts are mis-labelled.  at
> the moment the second says “GLASGOW_HASKELL” but actually it’s the first
>
>

Agreed that the code is fairly difficult to follow with the nested ifdefs.
However, instead of trying to salvage that, it's probably worth a
refactoring to put the Windows and POSIX code into separate modules and
then just import those conditionally.


>
>
> I have no opinion about the best solution; I’d just like it to compile and
> preferably warning free since that is our default policy.  Or add a –Wwarn
> at the top.
>
>
If you're looking for a short-term solution, I can add -Wwarn to the top
until some kind of refactoring takes place.


>
>
> thanks
>
>
>
> Simon
>
>
>
>
>
> *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 02 November 2015 13:42
>
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: process library broken on Windows
>
>
>
> That's the goal; it's a feature that does not work on Windows, only on
> non-Windows systems (setuid/setgid for a child process). For POSIX systems,
> CGid is exported from base, and can be used. On Windows, the data type is
> present to give the same signature, but the constructor itself is not
> exported to prevent using the feature. An argument could be made for other
> approaches:
>
>
>
> 1. Expose the constructor, allowing users to set a value, and that value
> will be ignored
>
> 2. Make the fields themselves conditional on the OS being used
>
>
>
> I don't think there's a strong argument in any direction for this.
>
>
>
> On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones <simo...@microsoft.com>
> wrote:
>
> I’m puzzled.   Internals.hs defines a newtype
>
>
>
> newtype CGid = CGid Word32
>
>
>
> A value of this type is needed to fill in the child_group field of
> CreateProcess.  If you don’t export it, you could never initialise this
> field to anything other than Nothing, so why do you have it?
>
>
>
> Looks to me as if the warning has nailed a real bug
>
>
>
> Simon
>
>
>
> *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 02 November 2015 13:34
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: process library broken on Windows
>
>
>
> I didn't read closely enough: I see now that it's a warning, not an error.
> I initially didn't export that constructor since it's only present on
> Windows for API compatibility, but will never be used. Since this is just
> the internals module, I can export it, but my preference would in fact be
> to leave it as-is with the warning. Two alternatives:
>
>
>
> 1. Create a new hidden module that creates and exports the type
> constructor, just to hide the warning. I'm -1 on that, since that's extra
> compile time everyone has to endure just for warning avoidance.
>
> 2. base could export CGid for Windows (currently, it does not).
>
>
>
> On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman <mich...@snoyman.com>
> wrote:
>
> I'll look into this. I just made a new release of process, and was certain
> I tested on Windows, but perhaps something changed between that commit and
> release.
>
>
>
> On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones <simo...@microsoft.com>
> wrote:
>
> I’m getting this on HEAD in te ‘
>
> libraries\p

Re: process library broken on Windows

[Michael Snoyman]

That's the goal; it's a feature that does not work on Windows, only on
non-Windows systems (setuid/setgid for a child process). For POSIX systems,
CGid is exported from base, and can be used. On Windows, the data type is
present to give the same signature, but the constructor itself is not
exported to prevent using the feature. An argument could be made for other
approaches:

1. Expose the constructor, allowing users to set a value, and that value
will be ignored
2. Make the fields themselves conditional on the OS being used

I don't think there's a strong argument in any direction for this.

On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones <simo...@microsoft.com>
wrote:

> I’m puzzled.   Internals.hs defines a newtype
>
>
>
> newtype CGid = CGid Word32
>
>
>
> A value of this type is needed to fill in the child_group field of
> CreateProcess.  If you don’t export it, you could never initialise this
> field to anything other than Nothing, so why do you have it?
>
>
>
> Looks to me as if the warning has nailed a real bug
>
>
>
> Simon
>
>
>
> *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 02 November 2015 13:34
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: process library broken on Windows
>
>
>
> I didn't read closely enough: I see now that it's a warning, not an error.
> I initially didn't export that constructor since it's only present on
> Windows for API compatibility, but will never be used. Since this is just
> the internals module, I can export it, but my preference would in fact be
> to leave it as-is with the warning. Two alternatives:
>
>
>
> 1. Create a new hidden module that creates and exports the type
> constructor, just to hide the warning. I'm -1 on that, since that's extra
> compile time everyone has to endure just for warning avoidance.
>
> 2. base could export CGid for Windows (currently, it does not).
>
>
>
> On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman <mich...@snoyman.com>
> wrote:
>
> I'll look into this. I just made a new release of process, and was certain
> I tested on Windows, but perhaps something changed between that commit and
> release.
>
>
>
> On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones <simo...@microsoft.com>
> wrote:
>
> I’m getting this on HEAD in te ‘
>
> libraries\process\System\Process\Internals.hs:106:16: warning:
>
> Defined but not used: data constructor ‘CGid’
>
> Indeed it looks as if CGId(..) should be exported, else createProcess is
> unusuable.  This looks like the right change.  Would someone like to check
> and make the change
>
> Simon
>
> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs
>
> index 5575ac4..3e23ad5 100644
>
> --- a/System/Process/Internals.hs
>
> +++ b/System/Process/Internals.hs
>
> @@ -37,6 +37,8 @@ module System.Process.Internals (
>
> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)
>
>  pPrPr_disableITimers, c_execvpe,
>
>  ignoreSignal, defaultSignal,
>
> +#else
>
> +CGid(..), GroupID, UserID,
>
> #endif
>
>  withFilePathException, withCEnvironment,
>
>  translate,
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd25a0d693de489171bb08d2e38a505d%7c72f988bf86f141af91ab2d7cd011db47%7c1=YdqpMC5wr2K6oUOw9WImRGpSl6EsV8zQyAK%2ba26oF9M%3d>
>
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: process library broken on Windows

[Michael Snoyman]

I'll look into this. I just made a new release of process, and was certain
I tested on Windows, but perhaps something changed between that commit and
release.

On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones 
wrote:

> I’m getting this on HEAD in te ‘
>
> libraries\process\System\Process\Internals.hs:106:16: warning:
>
> Defined but not used: data constructor ‘CGid’
>
> Indeed it looks as if CGId(..) should be exported, else createProcess is
> unusuable.  This looks like the right change.  Would someone like to check
> and make the change
>
> Simon
>
> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs
>
> index 5575ac4..3e23ad5 100644
>
> --- a/System/Process/Internals.hs
>
> +++ b/System/Process/Internals.hs
>
> @@ -37,6 +37,8 @@ module System.Process.Internals (
>
> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)
>
>  pPrPr_disableITimers, c_execvpe,
>
>  ignoreSignal, defaultSignal,
>
> +#else
>
> +CGid(..), GroupID, UserID,
>
> #endif
>
>  withFilePathException, withCEnvironment,
>
>  translate,
>
> ___
> 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: process library broken on Windows

[Michael Snoyman]

I'd rather not change the public API (even though it's an internal module)
in a way we'll later undo to avoid a warning, when the code cleanup should
achieve the goal without making that modification. I've pushed my changes
to the less-cpp branch, if anyone wants to play with the changes thus far.
I've also modified the Travis build to use -Wall -Werror, and added an
AppVeyor Windows build that similarly uses -Werror.

On Mon, Nov 2, 2015 at 6:44 AM, Simon Marlow <marlo...@gmail.com> wrote:

> -Wwarn shouldn't really be in source code.  Since it's an Internals
> module, I would just export it.  Maybe add a {-# WARNING #-} to discourage
> people from using it.
>
> Cheers
> Simon
>
> On 02/11/2015 06:14, Michael Snoyman wrote:
>
>>
>>
>> On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones
>> <simo...@microsoft.com <mailto:simo...@microsoft.com>> wrote:
>>
>> Aha.  It would be great to say all that in the source code!!  It’s
>> very non-obvious that you not want people ever to construct a CGId
>> on Windows.  After all, it has a newtype definition!
>>
>> __
>>
>>
>> Good call, I'll update with some comments (though see refactoring
>> comments below).
>>
>> __
>>
>> Could you declare it differently?
>>
>>  data CGId   -- No constructors
>>
>> __
>>
>>
>> Certainly we could. Then the question would be "why does the Windows
>> code look so different?" There are lots of colors to this bikeshed, and
>> I don't have any particular affinity to any of them. If you'd prefer it
>> looked that way, I can make that change. I initially erred with making
>> the code as similar to the POSIX code as possible.
>>
>> __
>>
>> Also if so, why does the Windows-specific foreign import of
>> c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You’d just told
>> me that we can never create one.
>>
>> __
>>
>>
>>
>> The Windows-specific foreign import is on line ~533, and does not
>> include those arguments.
>>
>> __
>>
>> Also, 
>>
>> __·__It’d help to comment the #else on line 456 as being “else if
>> not windows”
>>
>> __·__The #endifs on line 546 or thereabouts are mis-labelled.  at
>> the moment the second says “GLASGOW_HASKELL” but actually it’s the
>> first
>>
>> __
>>
>>
>>
>> Agreed that the code is fairly difficult to follow with the nested
>> ifdefs. However, instead of trying to salvage that, it's probably worth
>> a refactoring to put the Windows and POSIX code into separate modules
>> and then just import those conditionally.
>>
>> __
>>
>> I have no opinion about the best solution; I’d just like it to
>> compile and preferably warning free since that is our default
>> policy.  Or add a –Wwarn at the top.
>>
>> __
>>
>>
>> If you're looking for a short-term solution, I can add -Wwarn to the top
>> until some kind of refactoring takes place.
>>
>> __
>>
>> thanks
>>
>> __ __
>>
>> Simon
>>
>> __ __
>>
>> __ __
>>
>> *From:*michael.snoy...@gmail.com <mailto:michael.snoy...@gmail.com>
>> [mailto:michael.snoy...@gmail.com
>> <mailto:michael.snoy...@gmail.com>] *On Behalf Of *Michael Snoyman
>> *Sent:* 02 November 2015 13:42
>>
>>
>> *To:* Simon Peyton Jones
>> *Cc:* ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>> *Subject:* Re: process library broken on Windows
>>
>> __ __
>>
>> That's the goal; it's a feature that does not work on Windows, only
>> on non-Windows systems (setuid/setgid for a child process). For
>> POSIX systems, CGid is exported from base, and can be used. On
>> Windows, the data type is present to give the same signature, but
>> the constructor itself is not exported to prevent using the feature.
>> An argument could be made for other approaches:
>>
>> __ __
>>
>> 1. Expose the constructor, allowing users to set a value, and that
>> value will be ignored
>>
>> 2. Make the fields themselves conditional on the OS being used
>>
>> __ __
>>
>> I don't think there's a strong argument in any direction for this.
>>
>> __ __
>>
>> On Mon, Nov 2, 20

Re: Building on Windows

[Michael Snoyman]

That may have been it, thanks.

On Fri, Aug 21, 2015 at 9:52 AM, Tamar Christina loneti...@gmail.com
wrote:

 Hmm no that doesn't seem familiar to me. It looks like some Windows style
 paths are being passed around but don't know why..

 Are you running the non-emulating shells? E.g. The MinGW-w64 Win64 Shell
 bat?
 --
 From: Michael Snoyman mich...@snoyman.com
 Sent: ‎8/‎21/‎2015 8:27
 To: Tamar Christina loneti...@gmail.com
 Cc: ghc-devs@haskell.org
 Subject: Re: Building on Windows

 That worked, and got me much farther. If you don't mind one more newb
 question, I'm now seeing the following. Any thoughts?

 ===--- building final phase
 make -r --no-print-directory -f ghc.mk phase=final all
 /usr/bin/install -c -m 755 utils/hp2ps/dist/build/tmp/hp2ps.exe
 inplace/bin/hp2ps.exe
 cp driver/ghc-usage.txt inplace/lib/ghc-usage.txt
 cp driver/ghci-usage.txt inplace/lib/ghci-usage.txt
 inplace/bin/ghc-stage1.exe -o driver/ghci/dist/build/tmp/ghci.exe -hisuf
 hi -osuf  o -hcsuf hc -static  -H32m -O -i -idriver/ghci/.
 -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen
 -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen
 -no-user-package-db -rtsopts  -odir driver/ghci/dist/build -hidir
 driver/ghci/dist/build -stubdir driver/ghci/dist/build-static  -H32m
 -O -i -idriver/ghci/. -idriver/ghci/dist/build
 -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build
 -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts
 -no-auto-link-packages -no-hs-main  driver/ghci/dist/build/ghci.o
 driver/ghci/dist/build/../utils/cwrapper.o
 driver/ghci/dist/build/../utils/getLocation.o  driver/ghci/ghci.res
 Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
 Call hs_init_ghc() from your main() function to set these options.
 gcc.exe: error: driverghcidistbuildghci.o: No such file or directory
 gcc.exe: error: driverghcidistbuild..utilscwrapper.o: No such file or
 directory
 gcc.exe: error: driverghcidistbuild..utilsgetLocation.o: No such file or
 directory
 gcc.exe: error: driverghcighci.res: No such file or directory
 gcc.exe: error: C:msys64-2tmpghc6528_0ghc_4.o: No such file or directory
 gcc.exe: error: C:msys64-2tmpghc6528_0ghc_2.o: No such file or directory
 driver/ghci/ghc.mk:39: recipe for target
 'driver/ghci/dist/build/tmp/ghci.exe' failed
 make[1]: *** [driver/ghci/dist/build/tmp/ghci.exe] Error 1
 Makefile:71: recipe for target 'all' failed
 make: *** [all] Error 2

 On Fri, Aug 21, 2015 at 8:18 AM, Michael Snoyman mich...@snoyman.com
 wrote:

 Awesome, thanks for the quick response Tamar. Cloning now.

 On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com
 wrote:

 Hi Michael,

 Those instructions are for the GHC head. For 7.10 and earlier this page
 https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy
 should have been updated but it seems it never was..

 To get the tarballs on that version do
 git clone git://git.haskell.org/ghc-tarballs.git

 I will update the legacy page later.

 Regards,
 Tamar
 --
 From: Michael Snoyman mich...@snoyman.com
 Sent: ‎8/‎21/‎2015 7:06
 To: ghc-devs@haskell.org
 Subject: Building on Windows

 I'm trying to test a patch I wrote for Windows builds[1]. I'm following
 the preparation guide[2], but my configure step fails[3] with config.log
 contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is
 it possible that this would contribute to the unrecognized
 --enable-tarballs-autodownload option, and/or the inability to compile C
 files?

 [1] https://phabricator.haskell.org/D1158, handles long linker command
 line arguments
 [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
 [3] http://lpaste.net/139330
 [4] http://lpaste.net/139331




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

Re: Building on Windows

[Michael Snoyman]

That worked, and got me much farther. If you don't mind one more newb
question, I'm now seeing the following. Any thoughts?

===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
/usr/bin/install -c -m 755 utils/hp2ps/dist/build/tmp/hp2ps.exe
inplace/bin/hp2ps.exe
cp driver/ghc-usage.txt inplace/lib/ghc-usage.txt
cp driver/ghci-usage.txt inplace/lib/ghci-usage.txt
inplace/bin/ghc-stage1.exe -o driver/ghci/dist/build/tmp/ghci.exe -hisuf
hi -osuf  o -hcsuf hc -static  -H32m -O -i -idriver/ghci/.
-idriver/ghci/dist/build -idriver/ghci/dist/build/autogen
-Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen
-no-user-package-db -rtsopts  -odir driver/ghci/dist/build -hidir
driver/ghci/dist/build -stubdir driver/ghci/dist/build-static  -H32m
-O -i -idriver/ghci/. -idriver/ghci/dist/build
-idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build
-Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts
-no-auto-link-packages -no-hs-main  driver/ghci/dist/build/ghci.o
driver/ghci/dist/build/../utils/cwrapper.o
driver/ghci/dist/build/../utils/getLocation.o  driver/ghci/ghci.res
Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
Call hs_init_ghc() from your main() function to set these options.
gcc.exe: error: driverghcidistbuildghci.o: No such file or directory
gcc.exe: error: driverghcidistbuild..utilscwrapper.o: No such file or
directory
gcc.exe: error: driverghcidistbuild..utilsgetLocation.o: No such file or
directory
gcc.exe: error: driverghcighci.res: No such file or directory
gcc.exe: error: C:msys64-2tmpghc6528_0ghc_4.o: No such file or directory
gcc.exe: error: C:msys64-2tmpghc6528_0ghc_2.o: No such file or directory
driver/ghci/ghc.mk:39: recipe for target
'driver/ghci/dist/build/tmp/ghci.exe' failed
make[1]: *** [driver/ghci/dist/build/tmp/ghci.exe] Error 1
Makefile:71: recipe for target 'all' failed
make: *** [all] Error 2

On Fri, Aug 21, 2015 at 8:18 AM, Michael Snoyman mich...@snoyman.com
wrote:

 Awesome, thanks for the quick response Tamar. Cloning now.

 On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com
 wrote:

 Hi Michael,

 Those instructions are for the GHC head. For 7.10 and earlier this page
 https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy
 should have been updated but it seems it never was..

 To get the tarballs on that version do
 git clone git://git.haskell.org/ghc-tarballs.git

 I will update the legacy page later.

 Regards,
 Tamar
 --
 From: Michael Snoyman mich...@snoyman.com
 Sent: ‎8/‎21/‎2015 7:06
 To: ghc-devs@haskell.org
 Subject: Building on Windows

 I'm trying to test a patch I wrote for Windows builds[1]. I'm following
 the preparation guide[2], but my configure step fails[3] with config.log
 contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is
 it possible that this would contribute to the unrecognized
 --enable-tarballs-autodownload option, and/or the inability to compile C
 files?

 [1] https://phabricator.haskell.org/D1158, handles long linker command
 line arguments
 [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
 [3] http://lpaste.net/139330
 [4] http://lpaste.net/139331



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

Building on Windows

[Michael Snoyman]

I'm trying to test a patch I wrote for Windows builds[1]. I'm following the
preparation guide[2], but my configure step fails[3] with config.log
contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is
it possible that this would contribute to the unrecognized
--enable-tarballs-autodownload option, and/or the inability to compile C
files?

[1] https://phabricator.haskell.org/D1158, handles long linker command line
arguments
[2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
[3] http://lpaste.net/139330
[4] http://lpaste.net/139331
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building on Windows

[Michael Snoyman]

Awesome, thanks for the quick response Tamar. Cloning now.

On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com
wrote:

 Hi Michael,

 Those instructions are for the GHC head. For 7.10 and earlier this page
 https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy
 should have been updated but it seems it never was..

 To get the tarballs on that version do
 git clone git://git.haskell.org/ghc-tarballs.git

 I will update the legacy page later.

 Regards,
 Tamar
 --
 From: Michael Snoyman mich...@snoyman.com
 Sent: ‎8/‎21/‎2015 7:06
 To: ghc-devs@haskell.org
 Subject: Building on Windows

 I'm trying to test a patch I wrote for Windows builds[1]. I'm following
 the preparation guide[2], but my configure step fails[3] with config.log
 contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is
 it possible that this would contribute to the unrecognized
 --enable-tarballs-autodownload option, and/or the inability to compile C
 files?

 [1] https://phabricator.haskell.org/D1158, handles long linker command
 line arguments
 [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
 [3] http://lpaste.net/139330
 [4] http://lpaste.net/139331

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

Re: A GHC Library

[Michael Snoyman]

Hey Richard,

Just a layman's bit of input: when I read GHC Library, I immediately
think of calling the GHC API from Haskell code, not a collection of
writings about GHC organized properly. The terminology overload may
cause confusion.

Michael

On Tue, Jul 28, 2015 at 8:14 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
 Hi devs,

 It has struck me that we have a vast trove of documentation about GHC in the 
 form of academic papers, but little organization to this trove. The papers 
 are scattered across authors' websites, and sometimes it is hard to remember 
 what a paper is titled when searching for it.

 I have thus started a wiki page here: 
 https://ghc.haskell.org/trac/ghc/wiki/Library

 I would love for this page to be the Definitive List of GHC-related papers. 
 The list I've included is, of course, woefully short, but it is a starting 
 point. Please add to it!

 Have you written a GHC paper? If so, make sure it's included.

 Thanks,
 Richard
 ___
 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: Improving the Get Haskell Experience

[Michael Snoyman]

On Fri, Jul 24, 2015 at 11:16 AM Heinrich Apfelmus 
apfel...@quantentunnel.de wrote:

 Michael Snoyman wrote:
 
  Hopefully, they come with suitable documentation. For instance, one
  thing I don't understand about  stack  yet is in which location it
  magically installs GHC and packages, and how I can invoke `ghci` from
  these locations. Somehow, I was unable to understand this from the FAQ.
 
 
  I think this FAQ entry should help[1] on the first question:
 
  [1]: https://github.com/commercialhaskell/stack/wiki/FAQ [..]
 
  Note that stack setup installs GHC into
  ~/.stack/programs/$platform/ghc-$version/ and not a global location.

 Ah, ok. Can I assume that the non-sandboxed packages are also installed
 in the ~/.stack directory? That's the other part I didn't understand.


I'm not sure what non-sandboxed packages means. Do you mean
snapshot-level packages? If so, yes. If you mean project-specific packages:
they're all stored in the .stack-work directory of the project itself.

My recommendation overall is: build a project with `stack`, and run `stack
path` to get information on all of the different paths it's using for
various things.


  For the second question: either `stack ghci` or `stack exec ghci` should
  achieve what you're looking for. The former is a bit more experimental,
 and
  does more intelligent stuff at the project level as far as loading up
 your
  code. The latter simply runs the ghci command with appropriate PATH and
  GHC_PACKAGE_PATH environment variables set.

 `stack ghci` sounds good to me, then. I really like the short startup
 times of ghci and never use `cabal exec ghci` for that reason.


I think `stack exec ghci` is what you mean, correct?


 Best regards,
 Heinrich Apfelmus

 --
 http://apfelmus.nfshost.com


 ___
 Libraries mailing list
 librar...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Improving the Get Haskell Experience

[Michael Snoyman]

On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus apfel...@quantentunnel.de
wrote:

 Mark Lentczner wrote:
  *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
  shipping pre-built packages, so we banish cabal hell, and have a single
  common way to 'get Haskell' that just works.*
 
  [..]
 
  We think this plan solves many different community needs:
 
 - We have a clear way to get Haskell that works for a wide variety
 of
 use cases.
 - HP installer gets much smaller, and about as minimal as a working
 installation can get.
 - By leaving most packages out of the global database, users of
 cabal-install, will now have far fewer problems. Sandbox builds
 should now
 never give users cabal hell like warnings.
 - By building and installing the Platform packages into it's own
 package
 db, users get the benefit of building and installing these common
 packages
 only once per system, yet can easily bypass them for any given
 project if
 desired.
 - Since the Platform packages are now built and installed as needed,
 installing on smaller systems or servers without OpenGL will work.

 Sounds great to me! Personally, I do not mind how the Haskell Platform
 achieves these goals; I will simply adapt to whatever tools the platform
 happens to install on my machine.

 Hopefully, they come with suitable documentation. For instance, one
 thing I don't understand about  stack  yet is in which location it
 magically installs GHC and packages, and how I can invoke `ghci` from
 these locations. Somehow, I was unable to understand this from the FAQ.




I think this FAQ entry should help[1] on the first question:

 Note that stack setup installs GHC into
~/.stack/programs/$platform/ghc-$version/ and not a global location.

For the second question: either `stack ghci` or `stack exec ghci` should
achieve what you're looking for. The former is a bit more experimental, and
does more intelligent stuff at the project level as far as loading up your
code. The latter simply runs the ghci command with appropriate PATH and
GHC_PACKAGE_PATH environment variables set.

[1]
https://github.com/commercialhaskell/stack/wiki/FAQ#i-already-have-ghc-installed-can-i-still-use-stack
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Backporting srcLoc to the GHC 7.10 branch

[Michael Snoyman]

Hi Simon,

We had a small pow-wow over here. We're already providing relevant
customers with a custom-built GHC, and only using this feature internally
to their codebases, so it's not a necessity to get this into upstream GHC
7.10. It would be nice if the library ecosystem could start to add in
support for this feature, but on the other hand having it out in the wild
ties everyone's hands with improving the feature before the 7.12 release.

So put FP Complete down as somewhat ambivalent on whether it should go out.

On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones simo...@microsoft.com
wrote:


  * There is some change you want to make to 7.10.2.
I'm not sure precisely what it is.

 |  The change would be to put the latest two commits from
 |
 |  https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip
 |
 |  on top of 7.10 branch.

 Aha.  Now you say the top two commits I can see what you are talking
 about, namely the entire CallStack feature.  Specifically
 https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c


 |   * The change is an API change, which we do not normally make.
 | But you argue that it will harm no one (why are you so sure?),
 | and you are confident that it will not break anything (why?)
 |
 |  The API change is precisely at this commit.
 |
 |  https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8
 |  9b6b

 It's much more than that!  The main commit (the one you want) adds
 `CallStack`, `getCallStack` etc, as well as special treatment for implicit
 parameters of that type.

 That widens the API, which is certainly less disruptive than changing it.


 Let's see what Ben and Herbert have to say.

 Do any other ghc-devs, or Mark or Michael, have an opinion?

 Simon

 |
 |  I never said that it will not harm anyone or that it will not break
 |  anything. I only said that it is a small price to pay.
 |
 |  The change is your own in the typechecker, a two SrcSpans turning into
 |  RealSrcSpans. I think we can agree at least that it is not a large
 |  change. I understand if it gets rejected on this basis regardless, I
 |  am merely trying my chances.
 |
 |   * FP Complete and Zalora specifically want this change.
 | Zalora = you?  Who at FP Complete wants the change?
 |
 |  Some of us at Zalora, yes. This thread of messages was created my FP
 |  Complete and they did the backport. They even say that they'll include
 |  the changes into their custom build of GHC and ship that to their
 |  customers. So it seems like they'd want the change. The very first
 |  message in this thread is Michael Snoyman asking if such backport
 |  could make it into 7.10.
 |
 |   Ben and Herbert are the guys you have to persuade if you really want
 |  this.
 |   I suspect it'll be more effective to open a ticket, milestoned for
 |   7.10.2, with specifics on it.  Email gets lost; tickets don't.
 |
 |  Noted, thanks.
 |
 |   Thanks
 |  
 |   Simon
 |  
 |  
 |   | -Original Message-
 |   | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
 |   | Mateusz Kowalczyk
 |   | Sent: 06 July 2015 17:40
 |   | To: ghc-devs@haskell.org
 |   | Subject: Re: Backporting srcLoc to the GHC 7.10 branch
 |   |
 |   | On 04/20/2015 05:29 PM, Niklas Hambüchen wrote:
 |   |  Hello everybody,
 |   | 
 |   |  I'm glad to announce that I performed the suggested backporting
 |  as
 |   |  part
 |   | of
 |   |  my work for FP Complete!
 |   | 
 |   |  With the help of Eric (thanks for your support in #ghc!) we now
 |   |  have
 |   | this
 |   |  patch for 7.10 and 7.8.
 |   | 
 |   |  As promised, here are the commits:
 |   | 
 |   |  * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-
 |  ip
 |   |  * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip
 |   | 
 |   |  You can see in the history that I only needed to cherry-pick
 |  Make
 |   |  the location in TcLclEnv and CtLoc into a RealSrcSpan as a
 |   |  dependent
 |   | commit,
 |   |  so the changes beyond the actual feature are fairly minimal.
 |   | 
 |   |  For 7.8, I had to do a little more cleanup, see the Use
 |  wrapIPTc
 |   | instead
 |   |  of coercionToTcCoercion on wrapIP commit.
 |   | 
 |   |  Regarding the commit of the feature itself, I had to do quite
 |  some
 |   | merge
 |   |  resolution, especially due to the (lack of) the -fwarn-
 |  redundant-
 |   |  constraints patch https://github.com/nh2/ghc/commit/32973bf3
 |   |  (alias
 |   | but it
 |   |  was Christmas, so I did some recreational programming that went
 |   |  much further).
 |   |  However, the type checker had a strong opinion of what the right
 |   |  merge decision was, at least for the 7.10 backport; for 7.8
 |  there
 |   |  was an ambiguity (whether to return `Nothing` or `Just` in
 |   |  `interactDict`),
 |   | which
 |   |  was resolved with Eric's help.
 |   | 
 |   |  Please be invited to review the two commits.
 |   | 
 |   |  We would like to make 7.8 and 7.10 binaries

Re: Backporting srcLoc to the GHC 7.10 branch

[Michael Snoyman]

I'm on board with that, and as always am happy to run as many Stackage
builds as necessary, preferably using Herbert's PPAs (which make the
process so darn easy).

On Mon, Jul 13, 2015 at 3:17 PM Simon Peyton Jones simo...@microsoft.com
wrote:

  We (Ben/Herbert/myself/Simon) had a pow-wow too.

 ·We have a *strong* bias against making changes late in the
 release cycle

 ·And especially ones that change the API at all

 But on the other hand

 ·Mateusz did first float this back in mid-April and we didn’t pay
 enough attention at the time which is making us feel guilty.

 ·Although nothing is risk free, it seems unlikely to break
 anything because the changes only have an effect if you import the new
 module.

 ·Stackage gives us a pretty good smoke-test for if we’ve broken
 anything.

 ·Zalora want this strongly; and FP Complete do mildly.



 As to the stability of the feature itself, I’ll feel no compunction about
 changing it a bit in 7.12, say.  We often change new features in the light
 of feedback, and putting it in a release is a way to get people to actually
 use it and thereby get that feedback.



 So we decided, *strictly without setting a precedent*, to try applying
 the patch to 7.10.2, validating with the usual test suite and Stackage.



 I hope that’s ok with everyone.



 Simon



 *From:* Michael Snoyman [mailto:mich...@snoyman.com]
 *Sent:* 13 July 2015 18:33
 *To:* Simon Peyton Jones; Mateusz Kowalczyk; ghc-devs@haskell.org
 *Cc:* Mark Lentczner


 *Subject:* Re: Backporting srcLoc to the GHC 7.10 branch



 Hi Simon,

 We had a small pow-wow over here. We're already providing relevant
 customers with a custom-built GHC, and only using this feature internally
 to their codebases, so it's not a necessity to get this into upstream GHC
 7.10. It would be nice if the library ecosystem could start to add in
 support for this feature, but on the other hand having it out in the wild
 ties everyone's hands with improving the feature before the 7.12 release.

 So put FP Complete down as somewhat ambivalent on whether it should go out.



 On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones simo...@microsoft.com
 wrote:


  * There is some change you want to make to 7.10.2.
I'm not sure precisely what it is.

 |  The change would be to put the latest two commits from
 |
 |  https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip
 |
 |  on top of 7.10 branch.

 Aha.  Now you say the top two commits I can see what you are talking
 about, namely the entire CallStack feature.  Specifically
 https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c


 |   * The change is an API change, which we do not normally make.
 | But you argue that it will harm no one (why are you so sure?),
 | and you are confident that it will not break anything (why?)
 |
 |  The API change is precisely at this commit.
 |
 |  https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8
 |  9b6b

 It's much more than that!  The main commit (the one you want) adds
 `CallStack`, `getCallStack` etc, as well as special treatment for implicit
 parameters of that type.

 That widens the API, which is certainly less disruptive than changing it.


 Let's see what Ben and Herbert have to say.

 Do any other ghc-devs, or Mark or Michael, have an opinion?

 Simon

 |
 |  I never said that it will not harm anyone or that it will not break
 |  anything. I only said that it is a small price to pay.
 |
 |  The change is your own in the typechecker, a two SrcSpans turning into
 |  RealSrcSpans. I think we can agree at least that it is not a large
 |  change. I understand if it gets rejected on this basis regardless, I
 |  am merely trying my chances.
 |
 |   * FP Complete and Zalora specifically want this change.
 | Zalora = you?  Who at FP Complete wants the change?
 |
 |  Some of us at Zalora, yes. This thread of messages was created my FP
 |  Complete and they did the backport. They even say that they'll include
 |  the changes into their custom build of GHC and ship that to their
 |  customers. So it seems like they'd want the change. The very first
 |  message in this thread is Michael Snoyman asking if such backport
 |  could make it into 7.10.
 |
 |   Ben and Herbert are the guys you have to persuade if you really want
 |  this.
 |   I suspect it'll be more effective to open a ticket, milestoned for
 |   7.10.2, with specifics on it.  Email gets lost; tickets don't.
 |
 |  Noted, thanks.
 |
 |   Thanks
 |  
 |   Simon
 |  
 |  
 |   | -Original Message-
 |   | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
 |   | Mateusz Kowalczyk
 |   | Sent: 06 July 2015 17:40
 |   | To: ghc-devs@haskell.org
 |   | Subject: Re: Backporting srcLoc to the GHC 7.10 branch
 |   |
 |   | On 04/20/2015 05:29 PM, Niklas Hambüchen wrote:
 |   |  Hello everybody,
 |   | 
 |   |  I'm glad to announce that I performed the suggested

Re: Improving the Get Haskell Experience

[Michael Snoyman]

I think it depends somewhat on operating system, since there are
permissions issues to be dealt with regarding user vs global installation.
In principle though: I think the HP installers would install to a
non-stack-specific location, and then stack would simply use that GHC based
on its inclusion in the PATH. (I'm also guessing this will tie in nicely
with Linux distro packages, which would likely want ghc to live in
/usr/bin).

On Sun, Jul 12, 2015 at 10:11 AM Dan Burton danburton.em...@gmail.com
wrote:

 Stack has the capability of downloading and installing GHC on demand, as
 well as auto-updating itself. Both of these features, by default, occur in
 subdirectories of the user's home directory. (Slightly different on Windows
 but same idea.) Would the Platform install GHC to the stack location
 directly, or install it system-wide as previously? (Stack can still make
 use of GHC anywhere on your path.)

 On Sunday, July 12, 2015, Michael Snoyman mich...@snoyman.com wrote:

 I'm +1 on nailing down an LTS release cycle, I've been pushing for it,
 and planning that it would happen after the first few releases. I'm fine
 with doing it starting with the next release if that's desired.

 The cygwin/msys conflict is a problematic one. stack has more flexibility
 addressing this than MinGHC did, since stack can control the PATH more
 directly. What we do now is, by default, add msys to the beginning of the
 PATH, and provide a command line option to not use msys at all. I believe
 this combination has addressed the bug reports we've received in the past.

 That's not to say I'm opposed to generating binary databases; I'm
 actually in favor of having that option for all platforms at some point
 (there's an open stack issue about it[1]). But it's a significant amount of
 work, and I think if possible we should defer it until we've figured out
 initial integration points.

 [1] https://github.com/commercialhaskell/stack/issues/117

 On Sun, Jul 12, 2015 at 9:20 AM Gershom B gersh...@gmail.com wrote:

 I’m ccing cabal-devel, as that list seems pertinent to this discussion
 too. In general I’m in favor of unifying efforts such as this.

 For windows, I’d still like the _option_ to get prebuilt library
 binaries for the full platform db. The modularity means that they can be
 just downloaded in a separate folder now, rather than installed into e.g.
 the global db? If so, that’s a nice win. Here is my motivation — I tried
 the minghc installer and it mainly worked, but it played terribly with
 cygwin, which I use pervasively. So I found myself in a situation where one
 set of paths worked with cygwin, and the other set of paths let me build
 the network library. I still have some anxieties about those sorts of
 issues, and being able to “just download the binaries” would make me feel a
 bit safer about at least one workaround should things get too muddled up.

 If we synchronize LTS and “platform libs,” then I would like A) some way
 of distinguishing “blessed platform libs” from “other libs in LTS” (to
 solve the “curation problem” which has always been a goal of the platform)
 and B) a standardized release schedule for LTS.

 (And, of course, I assume this will _not_ be for the platform release
 upcoming, which is due very shortly, but we’ll have a longer lead time to
 integrate and shake out all the various issues and test, etc.)

 —Gershom


 On July 12, 2015 at 12:04:22 PM, Mark Lentczner (
 mark.lentcz...@gmail.com) wrote:
  *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
  shipping pre-built packages, so we banish cabal hell, and have a single
  common way to 'get Haskell' that just works.*
 
  At ICFP '14, there were several long group discussions of the state of
  getting Haskell, including Haskell Platform, Stackage, and other
  approaches. Over the last year, there have been a few more public
  discussions and evolution on the ideas, and other installer
 developments.
  In particular, Stackage's LTS package sets are a direct development
 from
  this work, and the release of stack has offered new options.
 
  Today, drawing from all this good work and ideas from so many, we'd
 would
  like to propose a concrete plan:
 
  - Haskell Platform becomes the standard way to get *GHC* and related
  tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
  user-friendly, cross-platform installer that gives a standard way to
 get
  Haskell for most users.
  - Use the *stack* model for package installation:
  - The global db has only the GHC packages
  - There is a package db for each curated set, Haskell Platform
  becomes one such set
  - Projects each have their own package db, much like sandboxes.
  - Haskell Platform's installer will no longer include pre-built,
  pre-installed packages other than GHC's set. Instead, it is configured
 so
  that *stack* can be used to build and install, on as needed, the
  corresponding Haskell Platform release packages.
 
  We think this plan

Re: Improving the Get Haskell Experience

[Michael Snoyman]

I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and
planning that it would happen after the first few releases. I'm fine with
doing it starting with the next release if that's desired.

The cygwin/msys conflict is a problematic one. stack has more flexibility
addressing this than MinGHC did, since stack can control the PATH more
directly. What we do now is, by default, add msys to the beginning of the
PATH, and provide a command line option to not use msys at all. I believe
this combination has addressed the bug reports we've received in the past.

That's not to say I'm opposed to generating binary databases; I'm actually
in favor of having that option for all platforms at some point (there's an
open stack issue about it[1]). But it's a significant amount of work, and I
think if possible we should defer it until we've figured out initial
integration points.

[1] https://github.com/commercialhaskell/stack/issues/117

On Sun, Jul 12, 2015 at 9:20 AM Gershom B gersh...@gmail.com wrote:

 I’m ccing cabal-devel, as that list seems pertinent to this discussion
 too. In general I’m in favor of unifying efforts such as this.

 For windows, I’d still like the _option_ to get prebuilt library binaries
 for the full platform db. The modularity means that they can be just
 downloaded in a separate folder now, rather than installed into e.g. the
 global db? If so, that’s a nice win. Here is my motivation — I tried the
 minghc installer and it mainly worked, but it played terribly with cygwin,
 which I use pervasively. So I found myself in a situation where one set of
 paths worked with cygwin, and the other set of paths let me build the
 network library. I still have some anxieties about those sorts of issues,
 and being able to “just download the binaries” would make me feel a bit
 safer about at least one workaround should things get too muddled up.

 If we synchronize LTS and “platform libs,” then I would like A) some way
 of distinguishing “blessed platform libs” from “other libs in LTS” (to
 solve the “curation problem” which has always been a goal of the platform)
 and B) a standardized release schedule for LTS.

 (And, of course, I assume this will _not_ be for the platform release
 upcoming, which is due very shortly, but we’ll have a longer lead time to
 integrate and shake out all the various issues and test, etc.)

 —Gershom


 On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentcz...@gmail.com)
 wrote:
  *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
  shipping pre-built packages, so we banish cabal hell, and have a single
  common way to 'get Haskell' that just works.*
 
  At ICFP '14, there were several long group discussions of the state of
  getting Haskell, including Haskell Platform, Stackage, and other
  approaches. Over the last year, there have been a few more public
  discussions and evolution on the ideas, and other installer developments.
  In particular, Stackage's LTS package sets are a direct development from
  this work, and the release of stack has offered new options.
 
  Today, drawing from all this good work and ideas from so many, we'd would
  like to propose a concrete plan:
 
  - Haskell Platform becomes the standard way to get *GHC* and related
  tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
  user-friendly, cross-platform installer that gives a standard way to get
  Haskell for most users.
  - Use the *stack* model for package installation:
  - The global db has only the GHC packages
  - There is a package db for each curated set, Haskell Platform
  becomes one such set
  - Projects each have their own package db, much like sandboxes.
  - Haskell Platform's installer will no longer include pre-built,
  pre-installed packages other than GHC's set. Instead, it is configured so
  that *stack* can be used to build and install, on as needed, the
  corresponding Haskell Platform release packages.
 
  We think this plan solves many different community needs:
 
  - We have a clear way to get Haskell that works for a wide variety of
  use cases.
  - HP installer gets much smaller, and about as minimal as a working
  installation can get.
  - By leaving most packages out of the global database, users of
  cabal-install, will now have far fewer problems. Sandbox builds should
 now
  never give users cabal hell like warnings.
  - By building and installing the Platform packages into it's own package
  db, users get the benefit of building and installing these common
 packages
  only once per system, yet can easily bypass them for any given project if
  desired.
  - Since the Platform packages are now built and installed as needed,
  installing on smaller systems or servers without OpenGL will work.
 
  To do this, we have a bit of work ahead of us: We need to settle on
  installation layout for each OS (including getting msys into the Windows
  installer); decide on the naming and versioning of the Platform package
 set
  

Re: Abstract FilePath Proposal

[Michael Snoyman]

On Mon, Jun 29, 2015 at 12:07 PM Erik Hesselink hessel...@gmail.com wrote:

 On Mon, Jun 29, 2015 at 10:46 AM, Michael Snoyman mich...@snoyman.com
 wrote:
  Regarding underspecified: I think that's appropriate at this phase. The
 main
  proposal is: maybe FilePath an abstract type. It will take multiple GHC
  releases before we switch over fully, with plenty of time to hash out
  details of how the filepath package should work, and the opportunity to
  experiment with different wrappers around a core abstract type.

 But changing the semantics of an established newtype is very tricky
 business, since the resulting breakage won't be indicated by the
 types!


My suggestion isn't to roll out one breaking change and then another silent
semantics change later. Rather, my point is: getting FilePath to be an
abstract type is the meat of the proposal, and what we need to agree on.
Working out the exact semantics of how the filepath package interacts with
that is important, but not urgent. Let's get to an agreement that an
abstract type is an improvement, and then we can figure out exactly how it
should behave. After all, we'll have about 2 years to figure that out.


  Having used an alternate FilePath type for a while (via
 system-filepath), I
  can say that it doesn't give the same benefit of just fixing the central
  FilePath type. Having to convert between types all over the place is
  tedious, defeats a lot of the performance benefits we're going for, and
  hurts type safety.

 Why would you have to convert 'all over the place'? If the alternative
 library also provides the basic IO functions, the only places you'd
 have to convert are interfaces with other libraries, and things from
 e.g. config file, both of which don't happen a lot.


By having two different types, we know that not everyone will convert over.
In fact, the very argument for having two types is so that not everyone
will need to convert. Especially if Prelude continues to export the current
`type FilePath = [Char]`, it will be difficult to get all libraries to use
the new type.


  As someone who typically is very much opposed to breaking changes in core
  libraries: I think this one is well worth it.

 Do you have any insight in the amount of breakage this will cause? I
 have a gut feeling that it's a lot more than any of the previous
 changes we've had, and those have already caused a lot of grumbling.
 But the only way to be sure is to run the builds on hackage (or
 stackage, but that's a smaller sample size).


I agree, this is going to be a big one. It does not lend itself to elegant
migrations like FTP did, for instance. But the scope of the current problem
is also large, which is why I believe this breakage is warranted. Doing it
gradually with a deprecation plan will hopefully make it possible for us to
make it as easy as possible.


 Erik

  On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink hessel...@gmail.com
 wrote:
 
  I think this proposal is currently underspecified. For example, it's
  not clear to me what the semantics of a FilePath are. I have the
  feeling that `toFilePah` should return a Maybe, for example, but it's
  hard to say without knowing what it's converting to, exactly.
 
  I also worry about the immense breakage this will cause. This is not
  just an issue of causing a lot of work for maintainers, but also of
  lots of unmaintained libraries, printed code etc breaking. I feel that
  there is not enough gain in this proposal relative to the amount of
  breakage.
 
  Has any thought been given to introduce new modules for this type, and
  leave the old ones in place?
 
  Erik
 
  On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel h...@gnu.org
  wrote:
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
  
   Hello *,
  
   What?
   =
  
   We (see From:  CC: headers) propose, plain and simple, to turn the
   currently defined type-synonym
  
 type FilePath = String
  
   into an abstract/opaque data type instead.
  
   Why/How/When?
   =
  
   For details (including motivation and a suggested transition scheme)
   please consult
  
 https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
  
  
  
   Suggested discussion period: 4 weeks
   -BEGIN PGP SIGNATURE-
   Version: GnuPG v1
  
   iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
   BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
   YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
   28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
   koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
   qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
   KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
   NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
   tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
   awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv

Re: Abstract FilePath Proposal

[Michael Snoyman]

Regarding underspecified: I think that's appropriate at this phase. The
main proposal is: maybe FilePath an abstract type. It will take multiple
GHC releases before we switch over fully, with plenty of time to hash out
details of how the filepath package should work, and the opportunity to
experiment with different wrappers around a core abstract type.

Having used an alternate FilePath type for a while (via system-filepath), I
can say that it doesn't give the same benefit of just fixing the central
FilePath type. Having to convert between types all over the place is
tedious, defeats a lot of the performance benefits we're going for, and
hurts type safety.

As someone who typically is very much opposed to breaking changes in core
libraries: I think this one is well worth it.

On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink hessel...@gmail.com wrote:

 I think this proposal is currently underspecified. For example, it's
 not clear to me what the semantics of a FilePath are. I have the
 feeling that `toFilePah` should return a Maybe, for example, but it's
 hard to say without knowing what it's converting to, exactly.

 I also worry about the immense breakage this will cause. This is not
 just an issue of causing a lot of work for maintainers, but also of
 lots of unmaintained libraries, printed code etc breaking. I feel that
 there is not enough gain in this proposal relative to the amount of
 breakage.

 Has any thought been given to introduce new modules for this type, and
 leave the old ones in place?

 Erik

 On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel h...@gnu.org
 wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hello *,
 
  What?
  =
 
  We (see From:  CC: headers) propose, plain and simple, to turn the
  currently defined type-synonym
 
type FilePath = String
 
  into an abstract/opaque data type instead.
 
  Why/How/When?
  =
 
  For details (including motivation and a suggested transition scheme)
  please consult
 
https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
 
 
 
  Suggested discussion period: 4 weeks
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1
 
  iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
  BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
  YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
  28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
  koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
  qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
  KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
  NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
  tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
  awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
  aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
  HjIPRrJbVK9AABo4AZ/Y
  =lg0o
  -END PGP SIGNATURE-
  ___
  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

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

Re: quick report using GHC 7.10 RC3

[Michael Snoyman]

On Thu, Mar 26, 2015 at 11:40 AM Erik Hesselink hessel...@gmail.com wrote:

 On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner
 mark.lentcz...@gmail.com wrote:

  7. Cabal incompatible API change
  In particular, the api that a custom Setup.hs uses.
  Distribution.Simple.UserHooks changed the type of a hook. It should not,
 it
  should have added another to do what it wanted. The poblem is you can't
 use
  CPP in Setup.hs. And so now anyone using the testHook hook is in a
 pickle:
  Your Setup.hs can't work in both 7.10 and 7.8!

 It can, but it's a bit tricky. When this happened before, people used
 a type class with two instances, where one of them filled in a default
 argument, IIRC. I can't find the exact code now, perhaps others
 remember this better.



I wrote a blog post in June of last year[1] and was told that some of those
tricks are used to Cabal files. I also don't have a link to a real example,
but the blog post may help.

Michael

[1] http://www.yesodweb.com/blog/2014/06/evil-conditional-compile
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: wither the Platform

[Michael Snoyman]

Thanks for linking to that Mike, I'd actually forgotten that I'd written
that :). Those are all very concrete issues people run into with the
platform regularly, but I'd like to point out a meta issue: the platform
tries to do too much, and in a non-composable manner. As I pointed out
previously, it's providing a tools installer, choosing blessed libraries,
pegging certain library versions, and selecting a distribution manner for
those libraries. Even if the other issues were all addressed, I still
believe the current trajectory of the platform is problematic, because it
is necessarily removing choice.

When Mark, Duncan and I were discussing GPS Haskell at ICFP, a big goal (in
my mind at least) was to allow individual tools to target individual goals.
I don't expect every use case to be served by a curated package set (like
LTS), so making that an optional feature of tooling makes sense. Similarly,
almost all users (excepting some people playing with bleeding-edge GHC)
will benefit from having an easy-to-use GHC+cabal-install installation, but
a large set of users (specifically Hackage package authors) need a way to
compile against different versions than the HP-blessed ones for testing
purposes.

And now a completely separate point: the current functioning of the HP
process seems very much at odds with the way people actually write and
release packages. Some examples:

* Having to go through an extra step of requesting that a package version
is bumped is tedious, and resulted in a buggy attoparsec being released in
HP
* Requiring package authors to endure long debate periods before the
package is accepted scares people off from wanting to participate
* A number of months back, the HP was used as a vehicle to push the PVP
agenda as well, which completely alienated some people from wanting to
participate (ironically, the package being pushed instead was not PVP
compliant either, go figure). The practical result to that is we currently
have no plans at all for getting TLS/HTTPS support into the platform, and
everyone's tooling (cabal-install) is far less secure than it should be.
* Authors want the freedom to quickly release new versions to their users,
especially for bug fixes. While in theory the HP is set up to do bugfix
releases, in practice this has never happened. In that sense, it is often
preferable from the eyes of a package author *not* to have his/her package
in the HP, as then users are better served

As long as I'm writing a long email, I want to point out one other thing. A
lot of the points being raised in this thread are discussing an idealized
view of what the HP could become. I'm fully in favor of improving it (like
I said, that's why I tried working with Mark on GPS Haskell and integrating
with Stackage). However, we need to accept the reality of the situation
today. Could the windows HP installer be improved like MinGHC to include
MSYS? Absolutely, and I hope it happens. Could we improve Cabal and work
around the global package database issues we've been mentioning? Yes, and I
support such moves. But we need to acknowledge current deficiencies, and
plot out a course of action to solve them. And given that this thread
started by lamenting how much effort the platform currently takes to
maintain, I'm concerned about those improvements actually occurring.

On Wed, Mar 25, 2015 at 11:30 AM Mike Meyer m...@mired.org wrote:

 On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones simo...@microsoft.com
  wrote:

  So that was the plan.  I still think it’s a good plan.  But it clearly
 is not working well, and I’m hazy about why.  Possible reasons:


 Possibly relevant is the stackage commentary on HP at
 http://www.stackage.org/install#why-not-haskell-platform:

 • On Windows, it does not provide a complete environment (missing MSYS).
 • By placing a large number of packages in the global package database,
 Haskell Platform installations are more easily corrupted.
 • The choice of package versions conflicts with the needs of many commonly
 used packages.
 • Some of the package versions included with the platform have known and
 severe bugs, and cannot be reliably upgraded.
 ___
 Libraries mailing list
 librar...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Backporting srcLoc to the GHC 7.10 branch

[Michael Snoyman]

Thanks for the feedback everyone. If/when we decide to backport the patch,
we'll be sure to make the commit available for others interested in running
a custom build of GHC. And thank you for the offer of help Eric, it's much
appreciated :)

On Mon, Mar 23, 2015 at 8:14 PM Eric Seidel e...@seidel.io wrote:

 IIRC the patch doesn't directly depend on -fwarn-redundant-constraints,
 but I think I ran into some merge conflicts that had to be resolved. I
 agree with Austin that backporting it should be doable, and would be
 happy to help if there's interest.

 Also, I still mean to submit a follow-on patch that uses the new srcLoc
 infrastructure to add locations to explicitly-failing functions (i.e.
 error, undefined, and maybe assert). I don't know if this will be
 palatable to GHC-HQ as it changes base, but I think it's at least a
 discussion worth having. Unfortunately I got sidetracked by school stuff
 and haven't had a chance to throw the patch together yet..

 On Mon, Mar 23, 2015, at 10:50, Austin Seipp wrote:
  Hi Michael,
 
  I actually tried to adopt this patch into 7.10, because I thought it
  was needed for another dependent patch we wanted. Unfortunately, the
  backtrace-via-implicit-params patch seems to depend on some prior work
  by Simon PJ in the typechecker (-fwarn-redundant-constraints, a rather
  large patch), which we *did not* want in 7.10 (the *textual* diff
  applied fine, but there were some API changes the backtrace patch
  needed, so it failed to build). So, in the end, it was easier to
  surgically remove this patch from the one that depended on it, and it
  had a much lower 'surface area' of changes, than adopting both. Hope
  that makes sense.
 
  Also, as Simon said, we don't normally do big changes like this in
  point releases, so I think this is unlikely to happen.
 
  So the short story is afraid not. But a backport should be possible,
  if you're willing to get your hands a bit dirty (any conflict will
  likely be fairly easy to fix, but it will involve some textual
  munging).
 
  On Mon, Mar 23, 2015 at 6:49 AM, Michael Snoyman mich...@snoyman.com
  wrote:
   It looks like the srcLoc change[1] is something that some of our (FP
   Complete's) customers would be quite interested in getting access to
 sooner
   rather than later. Would there be any possibility of getting that patch
   merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at
   actually including it in 7.10.1, but would it be on the table for
 7.10.2?
  
   We do of course have the option of backporting it ourselves and
 including it
   in a custom GHC we provide customers, but we generally try to stay as
 close
   to upstream as possible.
  
   [1] https://ghc.haskell.org/trac/ghc/ticket/9049
  
   ___
   ghc-devs mailing list
   ghc-devs@haskell.org
   http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
  
 
 
 
  --
  Regards,
 
  Austin Seipp, 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
 ___
 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: Cabal and simultaneous installations of the same package

[Michael Snoyman]

On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones simo...@microsoft.com
wrote:

 It's already a huge source of confusion for people using GHCi what they
 get messages about ByteString is not ByteString.



 Reading your blog post [1] it seems that we are addressing different
 questions:

 · My proposal is only that the act of **installing** a package
 does not break existing installed package, and is not rejected because it
 risks doing so.

Thank you for the clarification, I had misread that. On that front: I
agree.

  · You agree that the confusing behaviour you describe can’t
 happen with Cabal.  In any one build, Cabal can ensure that only one
 version of each package is used in the build, so such a message could never
 show up.

I've seen people discussing exactly such a change to Cabal's behavior, so I
mistakenly took your comments to be heading in that direction. While I
think there *might* be some future where we could expose that
functionality, it could be incredibly confusing. I'd feel much better
starting off with simply the act of installing.

  · What you want is for the confusing behaviour to be true of
 GHCi too.  Well that’s simple enough: ensure that the set of *exposed*
 packages (ie the ones you say ‘import M’ for), is consistent in the same
 way.  The point is that I may need to install a bunch of packages to build
 a program.  If I’m using Cabal, none of those newly installed packages need
 be exposed; I simply need them there so I can compile my program (using
 Cabal).   But at the moment I can’t do that.



 That leaves open the following question. Suppose

 · I want to install *and expose* package P and Q

 · But alas, P depends on containers 2.9 and Q depends on
 containers 3.1

 Now I’m stuck. But there is a good reason for being stuck, and one that is
 explicable.




If I'm reading this correctly, the proposal then would be to have cabal
automatically hide packages (as oppose to unregister them) to arrive at a
world where all exposed packages are consistent. Extrapolating for the case
you mention above

* if I installed P and then Q, I'd end up with containers-3.1 and Q
exposed, and containers-2.9 and P hidden
* if I installed Q and then P, I'd end up with containers-2.9 and P
exposed, and containers-3.1 and Q hidden

But either way, all four package/versions would be available, and cabal
would be able to select an appropriate subset of packages when configuring.
Does that sound about right?

Michael


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

Re: wither the Platform

[Michael Snoyman]

On Mon, Mar 23, 2015 at 5:21 PM Brandon Allbery allber...@gmail.com wrote:

 On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg e...@cis.upenn.edu
 wrote:

 - It's always out-of-date. This statement, while true, isn't a direct
 indication that something is wrong.


 Perception is reality. The period when the Platform went without an
 update for over a year because we were waiting on ghc 6.8.3 did a lot to
 ruin the Platform's reputation.



I hate to bring this up, but it's not just a historical issue. The version
of attoparsec used by the platform today forces an old version of aeson to
be used (0.6.2.1). The combination of that aeson and attoparsec version is
vulnerable to an incredibly severe DoS attack for specially crafted JSON
strings (e.g., {foo:1e1000}). In fact, just a few
weeks ago I sent a private email to someone about a massive vulnerability
in a service (obviously not going to point out which one).

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

Re: wither the Platform

[Michael Snoyman]

It should go without saying that the first sentiment we all likely have is
gratitude for all the work Mark has put into the platform, as well as all
of the other contributors and maintainers the platform has had over the
years. It hasn't just been work on producing the platform itself, but also
for setting up an expectation in the Haskell world for high quality,
reliable libraries. Even if the current incarnation of the platform is in
jeopardy, I hope that we continue with that attitude going forward.

I spend a lot of time working on Stackage, and obviously there's quite a
bit of overlap between Stackage, Haskell Platform, and LTS Haskell. For
purposes of this discussion, I think it's important to separate out
different features of the platform, and see how we may continue or
discontinue each individually:

1. A quality-approved set of libraries. As I see it, the process of coming
up with recommended libraries can continue completely independently of any
other work.
2. A method for installing GHC and build tools. I personally think that it
makes sense to separate out this aspect of the platform from all others.
MinGHC is an example of such a project: a minimal set of functionality for
bootstrapping a more complete Haskell development environment.
3. Prebuilt binary package databases. As I've mentioned in the past, and
others have here, there are problems with the current approach of putting
the packages in the global package database. I'd personally rather see this
aspect of the platform give way to more robust solutions.

And as we've already discussed in the past regarding GPS, there's
definitely room to add *more* to the platform with better build dependency
solving. LTS Haskell was specifically an effort to try to advance that
aspect of GPS.

Putting this together, I think it leads to a new approach for the platform:
minimalistic installers, curated package sets (ala LTS), recommended
packages (ala the current platform set), and a robust means for installing
these (e.g., cabal sandboxes). The Haskell world has advanced since the
initial HP work, maybe all that's needed now is upgrading to the newest
tooling available.

I realize I haven't put down any concrete next steps here. I definitely
have more ideas than I could put into this (already quite long) email. I
think a smaller task force dedicated to improving the tooling situation is
the best next step, and I'd be happy to kick off such an effort with other
interested individuals.

On Sat, Mar 21, 2015 at 7:54 PM Mark Lentczner mark.lentcz...@gmail.com
wrote:

 I'm wondering how we are all feeling about the platform these days

 I notice that in the new Haskell pages, the Platform is definitely not the
 recommended way to go: The main download pages suggests the compiler and
 base libraries as the first option - and the text for the Platform (second
 option) pretty much steers folks away from it. Of the per-OS download
 pages, only the Windows version even mentions it.

 Does this mean that we don't want to consider continuing with it? It is a
 lot of community effort to put out a Platform release - we shouldn't do it
 if we don't really want it.

 That said, I note that the other ways to officially get Haskell look, to
 my eye, very ad hoc. Many of the options involve multiple steps, and
 exactly what one is getting isn't clear. It hardly looks like there is now
 an official, correct way to setup Haskell.

 The Platform arose in an era before sandboxes and before curated library
 sets like Stackage and LTS. Last time we set direction was several years
 ago. These new features and development have clearly changed the landscape
 for use to reconsider what to do.


 I don't think the status quo for the Platform is now viable - mostly as
 evidenced by waning interest in maintaining it. I offer several ways we
 could proceed:

 *1) Abandon the Platform.* GHC is release in source and binary form.
 Other package various installers, with more or less things, for various
 OSes.

 *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of
 essential libs + tools. Keeps a consistent build layout and installation
 mechanism for Haskell.

 *3) Re-conceive the Platform.* Take a very minimal install approach,
 coupled with close integration with a curated library set that makes it
 easy to have a rich canonical, stable environment. This was the core idea
 around my GPS Haskell thoughts from last September - but there would be
 much to work out in this direction.

 Thoughts?

 — Mark

 ___
 Libraries mailing list
 librar...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Proposal for removing transformers dependency

[Michael Snoyman]

Huge +1 from a Stackage standpoint. The transformers dependency (and other
such dependencies) causes me a huge amount of pain.

On Wed Jan 21 2015 at 8:52:57 AM Joachim Breitner m...@joachim-breitner.de
wrote:

 Hi,

 Am Mittwoch, den 21.01.2015, 19:51 +0400 schrieb Alexander V Vershilov:
  Should I continue doing this?

 with my Debian packaging maintainer hat on: Yes, please do!

 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

 ___
 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

Limiting size of global package database

[Michael Snoyman]

tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library),
can we remove Cabal from the global package database installed with GHC?

A problem that comes up quite a bit for users of GHC is conflicting package
versions versus the version of a package that shipped with GHC. Some
examples I've run into in the past include binary-0.7/GHC-7.6, and
bytestring0-0.10/GHC-7.4. This is problematic for two reasons:

1. End users can be confused by having multiple versions of a package
installed (one global, one user). I've seen at least a dozen questions on
Stack Overflow, Reddit, and mailing lists about things like ByteString is
not bytestring-0.10.0.0-Data.ByteString.Internal.ByteString.
2. Any packages depended on by the ghc package can be very dangerous to
upgrade, as then you're blocked from using the ghc package with the new
version. This most often comes into play with doctest, though I've been
affected by it on other projects as well.

For both of these reasons, I think we should limit the number of packages
included in the global package database. One seemingly small step we could
do on that front is not include extraneous packages. In GHC 7.10rc1, that
includes Cabal and xhtml: both packages are in the global package database,
but could just as easily be removed from there and installed by users. The
motivation for that would be to avoid problem (1) above.

I realize that this change wouldn't affect point (2) above at all. Frankly,
that's the issue that causes me quite a bit more trouble, and I'd love to
see it resolved somehow, but it's unlikely to occur during the GHC 7.10
window. I'm writing this email now because I think there's a chance of
resolving the smaller issue immediately, but I'd like to explore the wider
issue of ghc-the-library dependencies for GHC 7.12.

I've opened up an issue[1] on Stackage's issue tracker about this as well.

[1] https://github.com/fpco/fpco/issues/3978
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Limiting size of global package database

[Michael Snoyman]

On Wed Dec 31 2014 at 4:25:12 PM Herbert Valerio Riedel hvrie...@gmail.com
wrote:

 Hello Michael,

 On 2014-12-31 at 15:10:37 +0100, Michael Snoyman wrote:
  tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library),
  can we remove Cabal from the global package database installed with GHC?

 [...]

  For both of these reasons, I think we should limit the number of packages
  included in the global package database. One seemingly small step we
 could
  do on that front is not include extraneous packages. In GHC 7.10rc1, that
  includes Cabal and xhtml:

 btw, haskeline and terminfo should be considered as well, according to
 your argument.


Yes, I didn't mean to imply that my list was exhaustive, those were just
two examples that jumped out at me.


  both packages are in the global package database, but could just as
  easily be removed from there and installed by users. The motivation
  for that would be to avoid problem (1) above.

 However, as for xhtml, haskeline and terminfo, we had to register/expose
 them in the global pkg DB due to

   https://ghc.haskell.org/trac/ghc/ticket/8919


IIUC, this comes down to the fact that distros want to install all packages
into the global database, whereas the pain point I'm describing here is
from users wanting to *avoid* having things in the global database. Perhaps
there's a simple solution here: if end-users non-distro installations of
GHC unregistered those packages, would it cause them any problems? Perhaps
having those packages in the global database is something that *only*
distros need.


 and as for Cabal, I have been told (maybe Duncan can weigh in...?) that
 Haskell implementations need to provide it (together with a `*hc-pkg`
 executable) in order to conform to the CABAL specification[1].



If that's the case, I would request that we modify the CABAL specification.
I wouldn't want us to make a bad technical decision because a spec told us
to do so.

Michael
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

[Michael Snoyman]

On Tue Nov 25 2014 at 9:46:46 PM Austin Seipp aus...@well-typed.com wrote:

 We are pleased to announce the first release candidate for GHC 7.8.4:

 https://downloads.haskell.org/~ghc/7.8.4-rc1/

 This includes the source tarball and bindists for 64bit Linux. Binary
 builds for other platforms will be available shortly. These binaries
 and tarballs have an accompanying SHA256SUMS file signed by my GPG key
 id (0x3B58D86F).

 We plan to make the 7.8.4 release sometime in the next few weeks.

 Please test as much as possible; bugs are much cheaper if we find them
 before the release!



Just wanted to report: I ran a full Stackage build + test suite using the
release candidate, and everything passed. This build consisted of ~750
packages. You can find the list of packages at:

http://lpaste.net/115090

Michael
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Source-markup language for GHC User's Guide

[Michael Snoyman]

On Tue, Oct 7, 2014 at 6:25 PM, Edward Z. Yang ezy...@mit.edu wrote:

 I personally don't have a problem writing Docbook, and one problem
 with moving to lightweight markup is it becomes a bit harder to
 keep your markup semantic.

 Edward


Why would this be a problem with asciidoc? All asciidoc maps directly into
DocBook markup, and for cases that the simple asciidoc markup is
insufficient, you can always embed full-blown DocBook (though I've ever
done that in practice).

Michael


 Excerpts from Herbert Valerio Riedel's message of 2014-10-07 09:20:43
 -0600:
  Hello GHC Developers  GHC User's Guide writers,
 
  I assume it is common knowledge to everyone here, that the GHC User's
  Guide is written in Docbook XML markup.
 
  However, it's a bit tedious to write Docbook-XML by hand, and the XML
  markup is not as lightweight as modern state-of-the-art markup languages
  designed for being edited in a simple text-editor are.
 
  Therefore I'd like to hear your opinion on migrating away from the
  current Docbook XML markup to some other similarly expressive but yet
  more lightweight markup documentation system such as Asciidoc[1] or
  ReST/Sphinx[2].
 
  There's obviously some cost involved upfront for a (semi-automatic)
  conversion[3].  So one important question is obviously whether the
  long-term benefits outweight the cost/investment that we'd incur for the
  initial conversion.
 
  All suggestions/comments/worries welcome; please commence brainstorming
 :)
 
 
 
   [1]: http://www.methods.co.nz/asciidoc/
 
   [2]: http://sphinx-doc.org/
 
   [3]: There's automatic conversion tools to aid (though manual cleanup
is still needed) the initial conversion, such as
 
   https://github.com/oreillymedia/docbook2asciidoc
 
As an example, here's the conversion of
 
 
 http://git.haskell.org/ghc.git/blob/HEAD:/docs/users_guide/extending_ghc.xml
 
to Asciidoc:
 
   https://phabricator.haskell.org/P24
 
to give an idea how XML compares to Asciidoc
 ___
 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: GitHub pull requests

[Michael Snoyman]

On Sun, Oct 5, 2014 at 11:21 AM, Andreas Abel ab...@chalmers.se wrote:

 On 05.10.2014 07:03, Ben Gamari wrote:

 and yet aren't willing to take the five (twenty?) minutes to familiarize
 themselves with Phabricator and the arc toolchain.


 Are you serious about this?  I think your time estimate is a grand
 illusion.  I attended Joachim Breitner's talk about Phabricator at the GHC
 developer meeting, that already  (nearly?) used up the twenty minutes you
 allow.  Yet I still have to

 * try it the first time,
 * make sure I get everything right,
 * learn to *trust* the tool
   * that is does the right thing,
   * does not do anything bad to my files
   * etc. pp.

 The brightest might be up to get on track in a couple of hours, but the
 majority is quite hesitant towards new tools...

 Human condition.

 Cheers,
 Andreas

 --
 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


I have to agree with Andreas here. I was in the boat of wanting to send a
pull request for a simple documentation fix. If I could have just sent a
Github PR, it would have taken no more than 5 minutes[1] to send a pull
request. And since it was pure documentation, I could have even done it
directly from the Github web interface if I'd wanted to. Phabricator took
me quite a bit longer to set up (I don't remember the exact time, but
certainly more than 20 minutes and certainly less than 3 hours). I also had
trouble figuring out the right way to get started on this, and had to bug
Herbert, who just sent me a link to the Phabricator site.

At the very least, I think accepting Github PRs would allow people in my
situation to send documentation fixes- which is something we should really
be encouraging[2]. If we're still going to require Phabricator, there
should be a canonical, step-by-step guide linked from multiple locations
(including a README.md on GHC's Github repo) to make it as obvious as
possible to willing contributors how to get started.

Michael

[1] Yes, I realize that's because I'm very familiar with the Github PR
process already. I'm not interested in whether Github or Phabricator are
easier for new users, the presumption is that many people- like me- are
already very familiar with Github.
[2]
http://www.reddit.com/r/haskell/comments/2i1z9u/improving_haskellrelated_documentation/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [core libraries] Core libraries bug tracker

[Michael Snoyman]

On Mon, Aug 4, 2014 at 6:00 PM, Simon Peyton Jones simo...@microsoft.com
wrote:

  Edward, and core library colleagues,

 This came up in our weekly GHC discussion

 · Does the Core Libraries Committee have a Trac?  Surely, surely
 you should, else you’ll lose track of issues.

 · Would you like to use GHC’s Trac for the purpose?   Advantages:

 o   People often report core library issues on GHC’s Trac anyway, so
 telling them to move it somewhere else just creates busy-work --- and maybe
 they won’t bother, which leaves it in our pile.

 o   Several of these libraries are closely coupled to GHC, and you might
 want to milestone some library tickets with an upcoming GHC release

 · If so we’d need a canonical way to identify tickets as CLC
 issues.  Perhaps by making “core-libraries” the owner?  Or perhaps the
 “Component” field?

 · Some core libraries (e.g. random) have a maintainer that isn’t
 the committee.  So that maintainer should be the owner of the ticket. Or
 the CLC might like a particular member to own a ticket.  Either way, that
 suggest using the “Component” field to identify CLC tickets

 · Or maybe you want a Trac of your own?

 The underlying issue from our end is that we’d like a way to

 · filter out tickets that you are dealing with

 · and be sure you are dealing with them

 · without losing track of milestones… i.e. when building a
 release we want to be sure that important tickets are indeed fixed before
 releasing

 Simon

 --
 You received this message because you are subscribed to the Google Groups
 haskell-core-libraries group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to haskell-core-libraries+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


+1 for the general concept of an issue tracker, and +0.5 on doing it as
part of the GHC tracker. That seems like it will be the most useful place
to track issues, but I don't feel *that* strongly on it versus other
options.

Michael
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs