ghc-prim 0.5.1.1 not on Hackage
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
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
On Fri, Dec 15, 2017, 6:23 PM Simon Peyton Jones 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 > > *Cc:* Boespflug, Mathieu ; Ben Gamari ; > ghc-devs > > > *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
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
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
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
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
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 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
>> 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.
>>
>> __ __
>>
>>
Re: process library broken on Windows
On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones 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 > 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 > 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 > wrote: > > I’m getting this on HEAD in te ‘ > > libraries\process\System\Process\Internal
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 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 > 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 > 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&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd25a0d693de489171bb08d2e38a505d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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
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 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 > 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
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: more releases
It's definitely an interesting idea. From the Stackage side: I'm happy to provide testing and, even better, support to get some automated Stackage testing tied into the GHC release process. (Why not be more aggressive? We could do some CI against Stackage from the 7.10 branch on a regular basis.) I like the idea of getting bug fixes out to users more frequently, so I'm definitely +1 on the discussion. Let me play devil's advocate though: having a large number of versions of GHC out there can make it difficult for library authors, package curators, and large open source projects, due to variety of what people are using. If we end up in a world where virtually everyone ends up on the latest point release in a short timeframe, the problem is reduced, but most of our current installation methods are not amenable to that. We need to have a serious discussion about how Linux distros, Haskell Platform, minimal installers, and so on would address this shift. (stack would be able to adapt to this easily since it can download new GHCs as needed, but users may not like having 100MB installs on a daily basis ;).) What I would love to see is that bug fixes are regularly backported to the stable GHC release and that within a reasonable timeframe are released, where reasonable is some value we can discuss and come to consensus on. I'll say that at the extremes: I think a week is far too short, and a year is far too long. On Tue, Sep 1, 2015 at 9:45 AM, Richard Eisenberg wrote: > Hi devs, > > An interesting topic came up over dinner tonight: what if GHC made more > releases? As an extreme example, we could release a new point version every > time a bug fix gets merged to the stable branch. This may be a terrible > idea. But what's stopping us from doing so? > > The biggest objection I can see is that we would want to make sure that > users' code would work with the new version. Could the Stackage crew help > us with this? If they run their nightly build with a release candidate and > diff against the prior results, we would get a pretty accurate sense of > whether the bugfix is good. If this test succeeds, why not release? Would > it be hard to automate the packaging/posting process? > > The advantage to more releases is that it gets bugfixes in more hands > sooner. What are the disadvantages? > > Richard > > PS: I'm not 100% sold on this idea. But I thought it was interesting > enough to raise a broader discussion. > ___ > 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: Building on Windows
And I just understood that you're saying that's the cause of the failed compile, thank you :) Nonetheless, could you add the comment to Phabricator? On Fri, Aug 21, 2015 at 10:24 AM, Michael Snoyman wrote: > I'd like to discuss that in Phabricator to keep the discussion > centralized. Could you add a comment? > > On Fri, Aug 21, 2015 at 10:17 AM, kyra wrote: > >> My original patch >> https://ghc.haskell.org/trac/ghc/attachment/ticket/10777/cabal-rsp.patch >> contains 'normslash' function. It seems, Michael have overlooked this. GNU >> tools wait response files containing forward slashes in paths. >> >> On 21.08.2015 9:52, Tamar Christina 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 <mailto:mich...@snoyman.com> >>> Sent: 8/21/2015 8:27 >>> To: Tamar Christina <mailto:loneti...@gmail.com> >>> Cc: ghc-devs@haskell.org <mailto: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 <http://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 <http://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 >> <mailto:mich...@snoyman.com>> wrote: >>> >>> Awesome, thanks for the quick response Tamar. Cloning now. >>> >>> On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina >>> mailto: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 >>> <http://git.haskell.org/ghc-tarballs.git> >>> >>> I will update the legacy page later. >>> >>> Regards, >>> Tamar >>> >>>
Re: Building on Windows
I'd like to discuss that in Phabricator to keep the discussion centralized. Could you add a comment? On Fri, Aug 21, 2015 at 10:17 AM, kyra wrote: > My original patch > https://ghc.haskell.org/trac/ghc/attachment/ticket/10777/cabal-rsp.patch > contains 'normslash' function. It seems, Michael have overlooked this. GNU > tools wait response files containing forward slashes in paths. > > On 21.08.2015 9:52, Tamar Christina 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 <mailto:mich...@snoyman.com> >> Sent: 8/21/2015 8:27 >> To: Tamar Christina <mailto:loneti...@gmail.com> >> Cc: ghc-devs@haskell.org <mailto: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 <http://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 <http://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 > <mailto:mich...@snoyman.com>> wrote: >> >> Awesome, thanks for the quick response Tamar. Cloning now. >> >> On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina >> mailto: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 >> <http://git.haskell.org/ghc-tarballs.git> >> >> I will update the legacy page later. >> >> Regards, >> Tamar >> >> >> From: Michael Snoyman <mailto:mich...@snoyman.com> >> Sent: 8/21/2015 7:06 >> To: ghc-devs@haskell.org <mailto: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 >>
Re: Building on Windows
That may have been it, thanks. On Fri, Aug 21, 2015 at 9:52 AM, Tamar Christina 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 > Sent: 8/21/2015 8:27 > To: Tamar Christina > 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 > wrote: > >> Awesome, thanks for the quick response Tamar. Cloning now. >> >> On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina >> 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 >>> 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
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 wrote: > Awesome, thanks for the quick response Tamar. Cloning now. > > On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina > 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 >> 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
Awesome, thanks for the quick response Tamar. Cloning now. On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina 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 > 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
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
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 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"
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"
On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus 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
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 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 > 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
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 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. > | >
Re: Improving the "Get Haskell Experience"
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 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 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 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 >>>
Re: Improving the "Get Haskell Experience"
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 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
Re: Abstract FilePath Proposal
On Mon, Jun 29, 2015 at 12:07 PM Erik Hesselink wrote: > On Mon, Jun 29, 2015 at 10:46 AM, Michael Snoyman > 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 > 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 > >> 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/A
Re: Abstract FilePath Proposal
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 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 > 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: [Haskell] Haskell on Windows instructions - is MinGHC version update needed?
Just weighing in from the LTS side (and I guess MinGHC as well): having a link to 7.8.4 is definitely the right thing to do. LTS 2 will not compile with GHC 7.10 (see: https://github.com/fpco/stackage/issues/378 for more information). On Thu, Apr 16, 2015 at 2:45 AM Tamar Christina wrote: > Hi Howard, > > Ah, I was under the impression that there would be a download link from > the LTS section on the download page. > > Since there isn’t one I have updated the pull request with a section for > Haskell LTS which provides links to 7.8.4. > > It will look like > https://github.com/Mistuke/hl/blob/update-windows-download-pages/static/markdown/windows-install.md > > Regards, > Tamar > > *From:* Howard B. Golden > *Sent:* Thursday, April 16, 2015 01:11 > *To:* Tamar Christina , Simon Peyton Jones > , Tamar Christina , Roman Kuznetsov > , kyra , Darren Grant > , David Macek , Michael > Steele , Andrew Klingenberg > > *Cc:* GHC > > Hi Windows Task Force, > > Rather than pointing to just the latest 7.10.1 release, please consider > having 7.10.1 and 7.8.4 links (and others if you wish). Haskell LTS 2.3 is > designed for GHC-7.8.4. It seems to me that many Windows users would find > that an attractive combination in addition to 7.10.1. > > Howard > > From: Tamar Christina > To: Simon Peyton Jones ; Tamar Christina < > ta...@zhox.com>; Roman Kuznetsov ; Kyrill Briantsev < > ky...@mail.ru>; Darren Grant ; David Macek < > david.mace...@gmail.com>; Michael Steele ; Andrew > Klingenberg > Cc: GHC > Sent: Wednesday, April 15, 2015 3:54 PM > Subject: Re: [Haskell] Haskell on Windows instructions - is MinGHC version > update needed? > > > > > Hi Simon, > > I have created a pull request to update the download links to 7.10.1 > releases. > > https://github.com/haskell-infra/hl/pull/106 > > Regards, > Tamar > > > From: Simon Peyton Jones > Sent: Wednesday, April 15, 2015 22:10 > To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, > David Macek, Michael Steele, Andrew Klingenberg > Cc: GHC > > > > Fwding to the GHC Windows Task force, who will doubtless know what to do. > > Simon > > | -Original Message- > | From: Haskell [mailto:haskell-boun...@haskell.org] On Behalf Of Howard > B. > | Golden > | Sent: 15 April 2015 17:51 > | To: hask...@haskell.org > | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version > | update needed? > | > | Hi, > | > | Currently, the Haskell website's Windows download page > | (https://www.haskell.org/downloads/windows) offers two alternatives, > | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- > | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this > | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want > | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. > | > | Howard > | ___ > | Haskell mailing list > | hask...@haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > ___ > 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 > ___ 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
On Thu, Mar 26, 2015 at 11:40 AM Erik Hesselink wrote: > On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner > 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
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 wrote: > On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones > 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
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 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 > > 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: wither the Platform
On Mon, Mar 23, 2015 at 5:21 PM Brandon Allbery wrote:
> On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg
> 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
Backporting srcLoc to the GHC 7.10 branch
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
Re: Cabal and simultaneous installations of the same package
On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones 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: Cabal and simultaneous installations of the same package
I'm in favor of adding support to Cabal to allow for this situation. However: I highly doubt this will be the panacea as predicted. It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." In fact, this confusion is so prevalent that I wrote a blog post about it in September[1]. I strongly believe that the best end-user experience comes from having a single mapping from package name to actually installed package/version/dependencies. I'd go even farther and say that users would be well served by having a single mapping from module name to installed module. In fact, Adam Bergmark even created an issue[2] to look into adding support to Stackage to start enforcing this situation, though the response to a blog post I wrote on that[3] implies that people are not so interested in addressing that problem. So my word of warning here is: if we simply throw multiple package/version/dependency combinations at users via cabal, there's a good chance that we'll do more harm than good. [1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions [2] https://github.com/fpco/stackage/issues/416 [3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones wrote: > Dear Cabal developers > > You'll probably have seen the thread about the Haskell Platform. > > Among other things, this point arose: > > | Another thing we should fix is the (now false) impression that HP gets > in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is > referring to here. > > But some time now GHC has allowed multiple versions of the same package > (compiled against different dependencies) to be installed simultaneously. > So all we need to do is to fix Cabal to allow it too, and thereby kill of a > huge class of cabal-hell problems at one blow. > > But time has passed and it hasn't happened. Is this because I'm > misunderstanding? Or because it is harder than I think? Or because there > are much bigger problems? Or because there is insufficient effort > available? Or what? > > Unless I'm way off beam, this "multiple installations of the same package" > thing has been a huge pain forever, and the solution is within our grasp. > What's stopping us grasping it? > > Simon > > ___ > 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: wither the Platform
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 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
Broken `cabal haddock --hoogle` with GHC 7.10
I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it: https://github.com/haskell/haddock/issues/361 https://github.com/haskell/cabal/issues/2297 I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Proposal for removing transformers dependency
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 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
Re: Limiting size of global package database
On Wed Dec 31 2014 at 4:25:12 PM Herbert Valerio Riedel 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
Limiting size of global package database
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: ANNOUNCE: GHC 7.8.4 Release Candidate 1
On Tue Nov 25 2014 at 9:46:46 PM Austin Seipp 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
On Tue, Oct 7, 2014 at 6:25 PM, Edward Z. Yang 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: RFC: Source-markup language for GHC User's Guide
On Tue, Oct 7, 2014 at 6:20 PM, Herbert Valerio Riedel wrote: > 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 > My $0.02: I originally wrote the Yesod book in XML[1], and through automated tools converted it to asciidoc. The conversion was mostly painless, and it's a *huge* improvement to be able to edit in asciidoc instead. One of the nice things is you should be able to do the transition incrementally, since you can generally mix asciidoc and DocBook. Michael [1] DITA which I converted into DocBook ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
On Sun, Oct 5, 2014 at 11:21 AM, Andreas Abel 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 Abel <>< Du 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
On Mon, Aug 4, 2014 at 6:00 PM, Simon Peyton Jones 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
Re: [core libraries] RE: Alex and new Bool primops
Having a requirement to manually install a newer Alex doesn't seem too onerous to me. That would be my recommendation. On Tue, Sep 10, 2013 at 11:53 AM, Simon Peyton-Jones wrote: > (Simon M: are you ok with updating Alex? You were the one of those who > argued strongly for using the old names for the new primops.) > > ** ** > > The difficulty is this. > > **· **Alex generates Haskell code, by transforming Foo.x into > Foo.hs > > **· **The generated Foo.hs contains references to comparison > primops, say (>#) :: Int# -> Int# -> Bool > > **· **Therefore Foo.hs will not work with GHC 7.8 if we have > changed the type of (>#), which is what I think we have agreed to do. > > **· **The solution is to make Alex generates a Foo.hs that is > compilable either with GHC 7.8 or 7.6, by including enough CPP directives. > Alex already does this for compatibility with earlier GHCs > > **· **However, until there is a new version of Alex, you simply > won’t be able to bootstrap GHC 7.8 (or indeed the current HEAD). > > ** ** > > That’s all there is to it. It’s tiresome and trivial in a sense, but it’s > a choice we have to make. > > ** ** > > It might be perfectly reasonable to say > > **· **You can’t build GHC 7.8 from source with the Haskell > Platform until a new HP comes out with the new Alex (which will be soon).* > *** > > **· **Unless you install the new Alex manually > > ** ** > > This seems not too bad; people who build GHC from source are generally > pretty savvy. The choice between the two is what we seek your guidance on. > > > ** ** > > (Incidentally, a very similar situation has arisen for Happy: see > http://ghc.haskell.org/trac/ghc/ticket/8022. But there the cost of > perpetuating the status quo for another release cycle seems minimal.) > > ** ** > > Simon > > ** ** > > *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On > Behalf Of *Michael Snoyman > *Sent:* 10 September 2013 05:28 > *To:* Simon Peyton-Jones > *Cc:* core-libraries-commit...@haskell.org; ghc-devs; Geoffrey Mainland; > Jan Stolarek > *Subject:* Re: [core libraries] RE: Alex and new Bool primops > > ** ** > > I'll admit a fair amount of ignorance of the GHC build process. But > wouldn't it be standard that any tool used in the GHC build process itself, > and built by GHC itself, would need to have some conditional compilation in > place to handle API changes? It seems like the questions here are whether > we should ever allow breaking changes in the API, and in this case whether > the changes are coming too late in the development cycle. It seems like > we've agreed on the first count that it's beneficial to allow breaking API > changes. It could be that in this case we're too late in the dev cycle.*** > * > > ** ** > > In this case, it sounds like including the compatibility module in Alex > would be most expedient, but I'd defer to those who understand the process > better than me. > > ** ** > > On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones > wrote: > > Dear Core Libraries Committee > > I think we need your advice. > > This thread (mostly on ghc-devs) shows that if the shim-package and > boolean-primop decision goes as currently proposed, then we'll need a new > release of Alex > * Either to generate an import of GHC.Exts.Compat >(ie depend on the shim package) > * Or to make its own local tiny shim module for the primops it uses > * Or maybe some other plan > (Alex already has quite a bit of stuff designed to make it generate code > that will be compilable with a variety of GHCs.) > > Moreover this new release of Alex will be necessary simply in order to > allow 7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current > HP could not be used to build GHC. > > How would you like us to proceed? Thanks! > > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of > | Geoffrey Mainland > > | Sent: 09 September 2013 16:14 > | To: Jan Stolarek > | Cc: ghc-devs > | Subject: Re: Alex and new Bool primops > | > > | I say this only somewhat facetiously, but this is *exactly* the sort of > | problem that the pro-backwards compatibility camp anticipates, and I > | mean the "pro-backwards compatibility camp" in the most general possible > | way :) The point is that you can never anticipate all the ways in which > | breaking backwards compatibility breaks things. How much "tec
