Re: Configuration documentation (Was Re: GitLab is down: urgent)

[Gershom B]

> How would I learn of that address? Who is ad...@haskell.org?

In fact, I know you knew this address at one point, because you
emailed it asking for help with the haskell symposium website in 2019
:-)

But yes, we all learn things and forget them, so documenting them
accessibly is important.

The who is answered in the github repo, as the current host of
information that used to live on phab, and before that on the wiki (eg
at https://wiki.haskell.org/Haskell.org_infrastructure)

That address has been publicized many times over the years, and is
linked to from hackage, among many other places. You're quite right
that it could be on the website too, and I'm sure a PR doing that
would be welcomed. And in fact, improving discoverability has been a
priority of the HF, which you've been involved with. We assembled the
repo specifically to help the foundation have a single place to link
to that holds this information. So, I really look forward to the HF
working to improve discoverability still further.

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

Re: Website for viewing proposals

[Gershom B]

Joachim -- will the readthedocs settings automatically know how to
direct things once the cname is set?

Also, I'd note that the documentation needs a little cleanup to make
clear that this is the page for _accepted_ proposals, not all
proposals -- perhaps it should also link back to the PR tracker as
well? (And also the nice generation makes obvious that there are a few
too many proposals numbered "1" :-)). Along those lines too, perhaps
the name should be bikeshedded a bit for that reason --
ghc-proposals.haskell.org makes it look like that's where I'd go to
get all proposals, not just the accepted ones.

Cheers,
Gershom

On Fri, May 10, 2019 at 6:22 PM Matthew Pickering
 wrote:
>
> Thanks Joachim, that looks good.
>
> I might have a go styling the site this weekend to make it fit in more
> with the Haskell.org theme.
>
> Matt
>
> On Fri, May 10, 2019 at 11:13 PM Joachim Breitner
>  wrote:
> >
> > Hi,
> >
> > given that Matthew already created a sphinx setup, GitHub pages isn’t
> > optimal. You need to use some other CI system like Travis to actually
> > build the page and push it, which I have set up a few times and is
> > possible, not completely straight-forward. What is straight-forward is
> > readthedocs.io, where I essentially just pressed one button and got
> > this:
> >
> >https://ghc-proposals.readthedocs.io/en/latest/
> >
> > Neat, isn’t it? I will clean up the section numbering.
> >
> >
> > The only thing I’d like to do before making this official is to use a
> > more permanent URL, in case we move this somewhere else. For that I’d
> > need a haskell.org admin to add a CNAME from
> >
> >ghc-proposals.haskell.org
> >
> > to
> >
> >readthedocs.io
> >
> > CC’ing gershom, hope he is the right contact for this task.
> >
> > Cheers,
> > Joachim
> >
> >
> > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki:
> > > Having a read-only rendered version of all accepted proposals should
> > > probably be pretty simple---we can even host it in the same repo using
> > > "Github Pages".I don't know that we need anything more complex
> > > than that.
> > >
> > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner
> > >  wrote:
> > > > Hi,
> > > >
> > > > I looked into getting doi’s for our accepted proposals, but it looked
> > > > harder than it should be.
> > > >
> > > > Building a nice web page from our repository and publishing it on
> > > > GitHub pages, which can serve a custom domain like
> > > > ghc-proposals.haskell.org would not be hard. Matthew even started a
> > > > Makefile at some point that produces a reasonably nice output using
> > > > sphinx.
> > > >
> > > > Maybe only reason why I am hesitant to do so is that there is a feature
> > > > creep risk:
> > > > We start with a webpage that shows accepted proposals,
> > > > soon we’ll add functionality to list pending proposals and their status
> > > > (why not? They are just a GitHub API call away),
> > > > then we start using this page to actually drive the proposals (surely
> > > > we can use this to tally the votes),
> > > > and then we end up with a system that no longer has the “you just need
> > > > to know GitHub to use it” property that made us build a Github-centric
> > > > process in the first place.
> > > >
> > > > But maybe I am paranoid, and I should just set up the CI infrastructure
> > > > for Matthew’s sphinx build.
> > > >
> > > > BTW, in hindsight, I regret that we renumber proposals after
> > > > acceptance. It would be easier if they just retained the number of the
> > > > PR (other proposal processes out there do that). But that ship has
> > > > sailed.
> > > >
> > > > Cheers,
> > > > Joachim
> > > >
> > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering:
> > > > > I want to cite a GHC proposal but linking to github for it doesn't
> > > > > seem very official or permanent.
> > > > >
> > > > > Last year you also cited a proposal for your Haskell symposium paper
> > > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull
> > > > > request which also doesn't seem ideal to me.
> > > > >
> > > > > Matt
> > > > >
> > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones
> > > > >  wrote:
> > > > > > Interesting.  How would it differ from what we have (i.e. github's 
> > > > > > RST viewer)?
> > > > > >
> > > > > > >  -Original Message-
> > > > > > >  From: ghc-devs  On Behalf Of 
> > > > > > > Matthew
> > > > > > >  Pickering
> > > > > > >  Sent: 09 May 2019 09:40
> > > > > > >  To: GHC developers 
> > > > > > >  Subject: Website for viewing proposals
> > > > > > >
> > > > > > >  Hi,
> > > > > > >
> > > > > > >  It would be useful if there was a canonical way to link and view 
> > > > > > > GHC
> > > > > > >  proposals rather than relying on github's RST viewer.
> > > > > > >
> > > > > > >  Can we set up a website, `ghc.haskell.org/proposals`, which is 
> > > > > > > deployed to
> > > > > > >  automatically when a new accepted proposal is merged?
> > > > > > >

Re: Update on HIE Files

[Gershom B]

Another reason that this probably should go into the mainline rather than a
plugin is that Zubin was explaining to me that the mechanisms introduced
could improve and generalize the “:set +c” family of type and location
information provided by ghci:
https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd-:set%20+c

—g


On June 26, 2018 at 7:09:23 AM, Zubin Duggal (zubin.dug...@gmail.com) wrote:

Hey Matt,

In principle, there should be no problem interacting with source plugins,
or implementing this as a source plugin, given that the generating function
has type:

enrichHie :: GhcMonad m => TypecheckedSource -> RenamedSource -> m (HieAST
Type)

The only reason the GhcMonad constraint is necessary and this is not a pure
function is because desugarExpr has type

deSugarExpr :: HscEnv -> LHsExpr GhcTc -> IO (Messages, Maybe CoreExpr)

So we need a GhcMonad to get the HscEnv. We need to desugar expressions to
get their Type.

However, in a private email with Németh Boldizsár regarding implementing
this as a source plugin, I had the following concerns:

1. Since HIE files are going to be used for haddock generation, and haddock
is a pretty important part of the haskell ecosystem, GHC should be able to
produce them by default without needing to install anything else.
2. Integrating HIE file generation into GHC itself will push the burden of
maintaining support to whoever makes breaking changes to GHC, instead of
whoever ends up maintaining the source plugin. This way, HIE files can be a
first class citizen and evolve with GHC.
3. Concerns about portability of source plugins - it should work at least
wherever haddock can currently work
4. I believe there are some issues with how plugins interact with GHCs
recompilation avoidance? Given that HIE files are also meant to be used for
interactive usage via haskell-ide-engine, this is a pretty big deal breaker.

I understand (4) has been solved now, but the first three still remain.

On 26 June 2018 at 16:23, Matthew Pickering 
wrote:

> Have you considered how this feature interacts with source plugins?
>
> Could the generation of these files be implemented as a source plugin?
> That would mean that development of the feature would not be coupled
> to GHC releases.
>
> Cheers,
>
> Matt
>
> On Tue, Jun 26, 2018 at 11:48 AM, Zubin Duggal 
> wrote:
> > Hello all,
> >
> > I've been working on the HIE File
> > (https://ghc.haskell.org/trac/ghc/wiki/HIEFiles) GSOC project,
> >
> > The design of the data structure as well as the traversal of GHCs ASTs to
> > collect all the relevant info is mostly complete.
> >
> > We traverse the Renamed and Typechecked AST to collect the following info
> > about each SrcSpan
> >
> > 1) Its type, if it corresponds to a binding, pattern or expression
> > 2) Details about any tokens in the original source corresponding to this
> > span(keywords, symbols, etc.)
> > 3) The set of Constructor/Type pairs that correspond to this span in the
> GHC
> > AST
> > 4) Details about all the identifiers that occur at this SrcSpan
> >
> > For each occurrence of an identifier(Name or ModuleName), we store its
> > type(if it has one), and classify it as one of the following based on
> how it
> > occurs:
> >
> > 1) Use
> > 2) Import/Export
> > 3) Pattern Binding, along with the scope of the binding, and the span of
> the
> > entire binding location(including the RHS) if it occurs as part of a top
> > level declaration, do binding or let/where binding
> > 4) Value Binding, along with whether it is an instance binding or not,
> its
> > scope, and the span of its entire binding site, including the RHS
> > 5) Type Declaration (class or regular) (foo :: ...)
> > 6) Declaration(class, type, instance, data, type family etc.)
> > 7) Type variable binding, along with its scope(which takes into account
> > ScopedTypeVariables)
> >
> > I have updated the wiki page with more details about the Scopes
> associated
> > with bindings:
> > https://ghc.haskell.org/trac/ghc/wiki/HIEFiles#
> Scopeinformationaboutsymbols
> >
> > These annotated SrcSpans are then arranged into a interval/rose tree to
> aid
> > lookups.
> >
> > We assume that no SrcSpans ever partially overlap, for any two SrcSpans
> that
> > occur in the Renamed/Typechecked ASTs, either they are equal, disjoint,
> or
> > strictly contained in each other. This assumption has mostly held out so
> far
> > while testing on the entire ghc:HEAD tree, other than one case where the
> > typechecker strips out parenthesis in the original source, which has been
> > patched(see https://ghc.haskell.org/trac/ghc/ticket/15242).
> >
> > I have also written functions that lookup the binding site(including RHS)
> > and scope of an identifier from the tree. Testing these functions on the
> > ghc:HEAD tree, it succeeds in looking up scopes for almost all symbol
> > occurrences in all source files, and I've also verified that the
> calculated
> > scope always contains all the occurrences of the symbol. The few cases

RE: Trac email

[Gershom B]

The mailqueue is clear, and I’ve confirmed that I (and others) can get trac
emails.

I checked and Simon’s email had been disabled from recieving emails from
the ghc-tickets list automatically due to bounces. I re-enabled it, so
perhaps that suffices. If not, at least it’ll give us a lead on _why_
things might be bouncing...

Simon: contact me offthread if you’d like, with what other email lists you
want to recieve messages from, if you want to confirm that they also
haven’t stopped sending to you due to the bounces.

—Gershom

On June 1, 2018 at 9:27:27 AM, Ben Gamari (b...@well-typed.com) wrote:

Simon Peyton Jones via ghc-devs  writes:

> Alas I am still getting no Trac mail whatsoever, despite Tamar’s work
> below. Can anyone help? It’s quite disabling.
>
Hmm, this is unfortunately.

Gershom, do you happen to know what is going on here?

Cheers,

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

Re: HIE Files

[Gershom B]

On Mon, May 14, 2018 at 9:30 AM, Simon Peyton Jones
 wrote:

>
> Why not put the .hie-file info into the .hi file?  (Optionally, of course.)
>

Simon, I'm curious what benefits you think we might get from this?
(I'm one of the mentors on this GSoC project btw).

> What tools/libraries do you plan to produce to allow clients to read a .hie 
> file and make send of the contents?

For GSoC as a proof of concept the idea is to teach haddock's
hyperlinked-source backend to use this information to add
type-annotation-on-hover to the colorized, hyperlinked, html source.

I think what is anticipated more broadly is that other tools like the
Haskell IDE Engine (which Zubin has contributed to in the past) will
also be able to make use of these files to provide ide and tooling
features in a more lightweight way than needing to directly interface
with the GHC API. (This by the way is one of the key benefits of
keeping the file separate from standard hi files -- it should be
parseable and consumable without needing to link in GHC).

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

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.2-rc1 now available

[Gershom B]

Thanks for the announcement, Ben. Since cabal-install 2.2 was just released, we 
were planning a new Haskell Platform release Any Day Now (tm). But given the 
impending 8.4.2 release, I think we will hold off until it lands.

Cheers,
Gershom


On April 1, 2018 at 5:07:35 PM, Ben Gamari (b...@well-typed.com) wrote:

Hello everyone, 

The GHC team is proud to announce the first release candidate of 8.4.2. 
the source distribution, binary distributions, and documentation are 
available at 

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

This release follows so closely to 8.4.1 due to a number last-minute 
bug-fixes that didn't quite make it into 8.4.1. This includes fixes for: 

* #14705, the interpreter being broken on some systems 
* #14779, where the compiler produces invalid code when used with -g 
* #14891, where a selection of GHC testsuite cases fail on OS X 
* #5129, where the simplifier would incorrectly reorder evaluation in 
under some conditions. 

Since this is a relatively small bugfix release we are bypassing the 
alpha releases and moving right to the release candidate stage. If all 
goes well the final release will be cut next week. 

Happy testing 

Cheers, 

- Ben 
___
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Proposal: Professionalizing GHC Development

[Gershom B]

Fellow Haskellers,

Recently there has been much work into creating a better and more
professional GHC development process, including in the form of DevOps
infrastructure, scheduled releases and governance, etc. But much
remains to be done. There continues to be concern about the lack of
use of industry-standard tools. For example, GHC development is tied
to Phabricator, which is a custom product originally developed for
in-house use by an obscure startup. GHC development is documented on a
wiki still -- ancient technology, not appropriate for 2018. Wiki
syntax for documentation needs to be replaced by the only modern
standard -- github flavored markdown. Trac itself is ancient
technology, dating to 2003, well before anybody knew how to program
real software. It provides no support for all the most important
aspects of software development -- Kanban boards, sprint management,
or even burndown charts.

What is necessary is an integrated solution that holistically
addresses all aspects of development, fostering a DevOps culture,
embracing cloud-first, agile-first, test-first, disrupt-first
principles, and with an
ironclad SLA. Rather than homegrown solutions, we need a GHC
development process that utilizes tools and procedures already
familiar to regular developers. Cross-sectional feature comparison
analysis yields a clear front-runner -- Visual Studio Team Services.

VSTS is a recognized Leader in the Gartner Magic Quadrant for
Enterprise Agile Planning tools. It lets us migrate from custom git
hosting to a more reliable source control system -- Team Foundation
Version Control. By enforcing the locking of checked-out files, we can
prevent the sorts of overlap between different patches that occur in
the current distributed version management system, and coordinate
tightly between developers, enabling and fostering T-shaped skills.
Team Build also lets us migrate from antiquated makefiles to modern,
industry-standard technology -- XML descriptions of build processes
that integrate automatically with tracking of PBIs (product backlog
items), and one-button release management.

In terms of documentation, rather than deal with the subtleties of
different markdown implementations and the confusing world of
restructured text, we can utilize the full power of Word, including
SharePoint integration as well as Office 365 capabilities, and integration
with Microsoft Teams, the chat-based workspace for collaboration. This
enables much more effective cross-team collaboration with product and
marketing divisions.

One of the most exciting features of VSTS is powerful extensibility,
with APIs offered in both major programming paradigms in use today --
JVM and .NET. The core organizational principle for full application
lifecycle management is a single data construct -- the "work item"
which documentation informs us "represents a thing," which can be
anything that "a user can imagine." The power of work items comes
through their extensible XML representation. Work items are combined
into a Process Template, with such powerful Process Templates
available as Agile, Scrum, and CMMI. VSTS will also allow us to
analyze GHC Developer team performance with an integrated reporting
data warehouse that uses a cube.

Pricing for up to 100 users is $750 a month. Individual developers can
also purchase subscriptions to Visual Studio Professional for $45 a
month. I suggest we start directing resources towards a transition. I
imagine all work to accomplish this could be done within a year, and
by next April 1, the GHC development process will be almost
unrecognizable from that today.

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

Re: [GHC DevOps Group] Release policies

[Gershom B]

This proposal seems to have trailed off. I think it is worth putting a bow
on it and getting it signed off on for the GHC release policy page.

Let me restate it:


Bundled library maintainers agree to the following responsibilities:

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.


I know Chak and I had a back and forth, but I consider it resolved in the
direction of this proposal at this point, as a strict improvement over the
current situation that does not seem to invite further controversy. If in
the event of future things we learn, this proposal is inadequate, we can
revisit then.

The one thing missing from both this proposal and the current release
policy page in general is discussion of the head overlay to hackage. I
think discussion of this should be integrated in both as a separate issue.
In particular — the feature freeze branches of bundled libraries can and
should be regularly updated in the head overlay.

Thoughts?

—Gershom

On December 19, 2017 at 8:53:22 PM, Gershom B (gersh...@gmail.com) wrote:

On December 19, 2017 at 8:15:49 PM, Manuel M T Chakravarty (
c...@justtesting.org) wrote:
> >
> This in particular implies that everything merged to the release
> branch has to have been well tested (the wiki page states, ”[o]nly
> previously agreed on, stable and tested new functionality is
> allowed in.”)

Ok — here’s where I get confused. In my experience, “well tested” is a
relative term. Certainly if we want a three month period between branch and
release, that’s because we’re expecting a _fair amount_ of bugs to shake
out over that period. As you point out, the wiki page says “agreed on,
stable and tested.” But nonetheless — that’s leaving a fair amount of room
for bugs to be found. Since there’s a period when features are written, and
another in which focus is all on bugfixing, then this is to be expected.
Keeping moving the barrier for making it into even a _branch_ higher and
higher seems weird to me. We’re already creating a new set of significant
barriers by even starting to have this branch process at all.

> Implicitly adding new functionality by depending
> on a moving library dependency, which is out of the quality control
> of the GHC team, is not something that I would call ”stable and
> tested functionality”.

And now here’s where you lose me entirely. The point is you wouldn’t be
depending on a moving library dependency. You’d be depending on a _release
branch_ just the same as GHC. Unless you mean to say that we shouldn’t
trust the maintainers of bundled packages to only put “stable and tested”
features in to a release branch? In the abstract, sure. If we were just
including random github repos sourced from stackoverflow answers, sure. But
in the actual concrete history of GHC and Haskell development — we know the
maintainers of these libs. We know they move slowly in general, and they
have processes too. And we know that if these libs, which are hard to
upgrade on their own (because they’re bundled with GHC), are going to get a
wide exposure to not just internal tests, but external users, it will be
via being bundled with GHC.

Since I would expect, based on past experience, that bundled libraries will
often need small bugfixes and tweaks, as you agree, then what you’ve just
sort of proposed is that we release extra versions of them that end up not
bundled with GHC versions, and which are less well tested. What is the
difference between cutting a branch and depending on it, which is what I
propose, and what you propose, except that we’ll end up with extra version
bumps in your scheme, and hackage packages with bugs that haven’t had a
chance to be shaken out, and may, in some cases (integer-gmp, ghc-prim,
base), not even make _sense_ outside of a GHC release.

I understand that its not pleasant, but GHC and the bundled packages have,
for the time being, a very special relationship. We can’t decouple them by
administrative fiat. GHC depends on them, and they also need GHC to run. So
their lifecycles are intertwined, and their development processes are
intertwined. This is how they have been developed and maintained for years.
Why do we suddenly want to pretend that now these maintainers are “out of
the quality control of the GHC team” like they’re foreign entities?

I also want to underline this is not about “new library features” as such —
this is about cross-cutting development of the sort Moritz described that
requires modifying GHC and bundled libs both.

RE: Haskell Platform 8.2.2 - virus?

[Gershom B]

Note that HitmanPro has caused plenty of problems with GHC in the
past, and should be avoided by Haskell devs:

https://www.reddit.com/r/haskell/comments/77from/gettting_segmentation_fault_on_stackcabal_any/

https://github.com/commercialhaskell/intero/issues/436
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] Release policies

[Gershom B]

On December 19, 2017 at 8:15:49 PM, Manuel M T Chakravarty
(c...@justtesting.org) wrote:
> >
> This in particular implies that everything merged to the release
> branch has to have been well tested (the wiki page states, ”[o]nly
> previously agreed on, stable and tested new functionality is
> allowed in.”)

Ok — here’s where I get confused. In my experience, “well tested” is a
relative term. Certainly if we want a three month period between
branch and release, that’s because we’re expecting a _fair amount_ of
bugs to shake out over that period. As you point out, the wiki page
says “agreed on, stable and tested.” But nonetheless — that’s leaving
a fair amount of room for bugs to be found. Since there’s a period
when features are written, and another in which focus is all on
bugfixing, then this is to be expected. Keeping moving the barrier for
making it into even a _branch_ higher and higher seems weird to me.
We’re already creating a new set of significant barriers by even
starting to have this branch process at all.

> Implicitly adding new functionality by depending
> on a moving library dependency, which is out of the quality control
> of the GHC team, is not something that I would call ”stable and
> tested functionality”.

And now here’s where you lose me entirely. The point is you wouldn’t
be depending on a moving library dependency. You’d be depending on a
_release branch_ just the same as GHC. Unless you mean to say that we
shouldn’t trust the maintainers of bundled packages to only put
“stable and tested” features in to a release branch? In the abstract,
sure. If we were just including random github repos sourced from
stackoverflow answers, sure. But in the actual concrete history of GHC
and Haskell development — we know the maintainers of these libs. We
know they move slowly in general, and they have processes too. And we
know that if these libs, which are hard to upgrade on their own
(because they’re bundled with GHC), are going to get a wide exposure
to not just internal tests, but external users, it will be via being
bundled with GHC.

Since I would expect, based on past experience, that bundled libraries
will often need small bugfixes and tweaks, as you agree, then what
you’ve just sort of proposed is that we release extra versions of them
that end up not bundled with GHC versions, and which are less well
tested. What is the difference between cutting a branch and depending
on it, which is what I propose, and what you propose, except that
we’ll end up with extra version bumps in your scheme, and hackage
packages with bugs that haven’t had a chance to be shaken out, and
may, in some cases (integer-gmp, ghc-prim, base), not even make
_sense_ outside of a GHC release.

I understand that its not pleasant, but GHC and the bundled packages
have, for the time being, a very special relationship. We can’t
decouple them by administrative fiat. GHC depends on them, and they
also need GHC to run. So their lifecycles are intertwined, and their
development processes are intertwined. This is how they have been
developed and maintained for years. Why do we suddenly want to pretend
that now these maintainers are “out of the quality control of the GHC
team” like they’re foreign entities?

I also want to underline this is not about “new library features” as
such — this is about cross-cutting development of the sort Moritz
described that requires modifying GHC and bundled libs both.

Another element of the two-way character of this relationship is that
when GHC develops a new feature, often it is the bundled libs that are
the first to take advantage of it — and this is a good thing, as it
allows further stress-testing of the feature. (And sometimes, with
certain deprication warnings, etc., the feature is even especially
_for_ those libs). But if the feature turns out to need tweaks in the
stability period (and this is far from unheard of) then it is the
bundled libs that need to change to adapt. If you have already pinned
yourself to released versions of libs, this is very hard!

It would be nice if bundled libs were upstream of GHC, but they’re
not, so we should stop pretending. Everyone’s in the same stream
together, and everyone will have to agree to row :-)

Again — what is objectionable to having a release branch cut instead
of a full release at T-3? What danger from this do you anticipate?

Personally, I see only upside. More flexibility — same mitigation of
risk, same alignment of processes.

We already have a number of changes in the pipeline, not least the new
schedule in any form. How about we try that, along with a more modest
proposal for bundled libs, and just _see how it feels_ before making
any futher decisions. A “big bang” in process doesn’t need to be
bigger — that only introduces more risk factors that will prevent us
from evaluating the first changeset independently. Honestly, before
making any further policy I’d just like to see if one or two releases
can be done with the new schedule at 

Re: Can't push to haddock

[Gershom B]

> You're also assuming github doesn't suddenly pull a SourceForge (or a
> Gitorious for that matter). Business cares not what it steamrolls in the
> name of profit.
>
> I fail to understand why, with multiple examples of the folly of this
> belief out there, people are still willing to bet on *this* company being
> *different* from all others and absolutely safe to trust.

What the heck is everyone arguing over? The initial statement was that
even if we moved everything to github "We'd need mirroring anyway".
That's it! There's no either/or involved. Just a statement that when
you have data in one location, no matter how trustworthy, you want a
backup as well. And ideally you want the backup under your control.

We can debate moving anything anywhere all we want, but the idea that
stuff should also be backed up, regardless, in a source not under
third-party control, seems inoffensive and besides the point.

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

Re: [GHC DevOps Group] Release policies

[Gershom B]

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

Re: [GHC DevOps Group] Fwd: Release policies

[Gershom B]

On Fri, Dec 15, 2017 at 12:37 PM, Boespflug, Mathieu  wrote:
> I did mean that one, yes. That was my question earlier - is Cabal
> along with *all* core libraries covered by the CLC's 3-release policy?

The 3 release policy does not apply to all libraries maintained by the
CLC. It applies to "basic libraries":
https://prime.haskell.org/wiki/Libraries/3-Release-Policy

The general notion is that it applies to things surrounding the
prelude, base, and things perhaps adjacent to that. That is to say,
more or less, things that would be defined in the libraries section of
the Haskell Report:
https://www.haskell.org/onlinereport/haskell2010/haskellpa2.html

> The *Core Libraries* Committee (CLC) defines a "core library" as
>
> "Our definition of "core library" is a library that ships with GHC."
> (See https://wiki.haskell.org/Library_submissions#The_Libraries)

By that definition, "Cabal" might well be listed in the core libraries
that are not maintained by the CLC on that page, and it is perhaps an
oversight that it is not? I would ask them.

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

Re: Fwd: Release policies

[Gershom B]

On Wed, Dec 13, 2017 at 7:06 PM, Boespflug, Mathieu  wrote:
>
> But crucially, what *is* the policy around Cabal versions? This
> comment, https://ghc.haskell.org/trac/ghc/ticket/14558#comment:23
> claims "if Stack doesn't support the version of Cabal that ships with
> a certain version of GHC, it shouldn't claim that it supports that
> version of GHC. The same applies to cabal-install". Is any build tool
> linked against Cabal-X by definition "not a supported configuration"
> by GHC-Z if it ships with Cabal-Y such that X < Y?

My understanding is that this is the general thought, yes. In fact,
I've been told that even though cabal-install 1.24 did end up working
with the GHC 8.2.x series, the release notes, which were not updated
properly, actually _were supposed_ to say cabal-install 2.0.0.0 was
what was supported there. I believe future cabal-installs will warn
when used with a ghc with a newer Cabal-lib than they were built
against...

> Right. But switching from Cabal-2 to Cabal-3 (a hypothetical at this
> point) sounds like a whole new set of features transitively just made
> it into the compiler. Is that something we're happy to happen during
> feature freeze?

Right. After freeze, the compiler itself shouldn't switch from Cabal-2
to Cabal-3. But I would imagine rather that the Cabal-3 tree and the
compiler tree would be updated in tandem, and then the "freeze" would
sort of apply to both in tandem as well. So there wouldn't be big
changes after the freeze, but nor would the compiler be coupled to a
_released_ lib. Rather, they would develop together, freeze together,
and release together.

> I don't disagree. But then we'd need to abandon any notion that
> versions of packages on Hackage and versions of packages in the GHC
> release tarball always match up. Might even be worth calling that out
> explicitly in the policy.

Not exactly. The tarball of the package on hackage should match the
release tarball. Revisions don't change the tarball. They just add
additional metadata to the index as well that cabal-install knows how
to use in conjunction with the tarball:
https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md#what-are-revisions

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

Re: Fwd: Release policies

[Gershom B]

Mathieu:

I think the points about better tooling for documenting the correct
claims in the release process are well taken. Updating the release
notes manually leaves way too much room for error.

However, I think you are incorrect that GHC 8.2.1 and 8.2.2 did not
have cabal-install 1.24 support. They did. it works with them. I used
it! The fact that the cabal files for builtin libraries use Cabal-2
syntax does not cause a problem.

I think elsewhere Mikhail has corrected your timeline a bit. The
general point is that Cabal-the-library and ghc releases do tend to be
in tandem. But it is also the case that this happens because they are
often developed in a coupled fashion. This in not really different
than other builtin libs to GHC. They are necessarily coupled to
changes in the compiler, and so end up being released together. Our
process for making sure they are actually uploaded is absolutely
error-prone as is the process for documenting what occurs in release
notes. But I don't think we can simply by fiat decouple this stuff --
rather, this needs to occur on a technical level first, before other
policies can really even be considered.

Onto the concrete ideas:

> * GHC should never under any circumstance ship with an unreleased version
> of any independently maintained dependency. Cabal is one such dependency.
> This should hold true for anything else. We could just add that policy to
> the Release Policy.

Yes, this is a good policy. Sometimes in the drive for a release, GHC
will run ahead of a dependencies' upload by a bit. (Iirc this happened
at one point in the past for bytestring, but this was some years ago).
It is always better to hold things by a few days to get the dependency
released first.

> * Stronger still, GHC should not switch to a new major release of a
> dependency at any time during feature freeze ahead of a release. E.g. if
> Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
> game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.

I don't think this works, in terms of coupled dependencies. If/when
Cabal-3 is developed it will almost certainly be in tandem with GHC
support.

> * GHC does have control over reinstallable packages (like text and
> bytestring): GHC need not ship with the latest versions of these, if indeed
> they introduce breaking changes that would contravene the 3-release policy.

Right, but this won't occur, because those libs are already under the
control of the libraries committee and abide by the policy.

> * Because there are far fewer consumers of metadata than consumers of say
> base, I think shorter lead time is reasonable. At the other extreme, it
> could even be just the few months during feature freeze.

Right. There's not a sufficient quantity of metadata-consuming
downstream tooling to motivate a long lead. And furthermore, the
examples I can think of -- tracking dependencies for notifications or
graphs -- have no need of pulling this data out of ghc-builtin
libraries anyway, as they're for exploring the _userland_ portion of
the package world regardless. (The other key example -- stack -- can
also choose to ignore the metadata of builtin libs without harm).

The general motivation of making a "feature freeze" more of a "freeze
all the moving parts, really" I do agree with. Having a real freeze is
part of a better release process, and it should allow all the
downstream consumers of everything more time to really catch up. This
is just one instance of that need.

> Finally, a question for discussion:
>
> * Hackage allows revising the metadata of an uploaded package even without
> changing the version number. This happens routinely on Hackage today by the
> Hackage trustees. Should this be permitted for packages whose release is
> completely tied to that of GHC itself (like integer-gmp)?

It is rare that this is needed, but the ability just served us well --
editing integer-gmp to remove the new syntax was very useful, as it
let us fix up old stack nightlies. Like all revisions, these should be
made with some care and thought, but since we've just seen why it was
helpful, I'd hate to now say we can't do it again if some other
unforseen circumstance crops up.

Regards,
Gershom

> Hi Simon,
>
> feedback from downstream consumers of Cabal metadata (e.g. build tool
> authors) will be particularly useful for the discussion here. Here are my
> thoughts as a bystander.
>
> It's worth trying to identify what problems came up during the integer-gmp
> incident in Trac #14558:
>
> * GHC 8.2.1 shipped with integer-gmp-1.0.1.0 but the release notes said
> otherwise.
> * GHC 8.2.1 shipped with Cabal-2.0.0.2, but specifically claimed in the
> release notes that cabal-install-1.24 (and by implication any other build
> tool based on Cabal-the-library version 1.24) was supported: "GHC 8.2 only
> works with cabal-install version 1.24 or later. Please upgrade if you have
> an older version of cabal-install."
> * GHC 8.2.2 also claimed 

Re: cvs-ghc archives

[Gershom B]

You can also get cvs-ghc specific mail at:

https://www.mail-archive.com/cvs-ghc=40haskell.org/

Note: We still have the old list archives. It looks like the list itself =
was deleted on mailman when the old cvs- lists were decomissioned so as t=
o prevent confusion. I think they=E2=80=99ve been inaccessable for years =
so it doesn=E2=80=99t seem like its a pressing concern=3F That said, we c=
an look into hosting the archives with a redirect on archives.haskell.org=
.

Cheers,
Gershom

On September 28, 2017 at 8:32:26 AM, ghc-devs-request=40haskell.org (ghc-=
devs-request=40haskell.org) wrote:
> Send ghc-devs mailing list submissions to
> ghc-devs=40haskell.org
> =20
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> or, via email, send a message with subject or body 'help' to
> ghc-devs-request=40haskell.org
> =20
> You can reach the person managing the list at
> ghc-devs-owner=40haskell.org
> =20
> When replying, please edit your Subject line so it is more specific
> than =22Re: Contents of ghc-devs digest...=22
> =20
> =20
> Today's Topics:
> =20
> 1. Re: cvs-ghc archives (Bartosz Nitka)
> =20
> =20
> --
> =20
> Message: 1
> Date: Thu, 28 Sep 2017 11:07:43 +0100
> =46rom: Bartosz Nitka =20
> To: ghc-devs Devs =20
> Subject: Re: cvs-ghc archives
> Message-ID:
> =20
> Content-Type: text/plain; charset=3D=22UT=46-8=22
> =20
> I think someone has archived the data for us here
> https://www.mail-archive.com/cvs-all=40haskell.org/.
> I don't have a good way to map the old links to new ones, though.
> =20
> 2017-09-28 11:01 GMT+01:00 Bartosz Nitka :
> > Hello,
> >
> > I was reading a comment that pointed to
> > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html.
> > It's a dead link and I couldn't find any place where cvs-ghc is archi=
ved.
> > I've tried webarchive.
> >
> > Looks like Simon had a simliar problem 4 years ago:
> > http://ghc-devs.haskell.narkive.com/3dIDGsHy/cvs-ghc-archives
> >
> > Is the data forever lost=3F
> >
> > There aren't actually that many references in the source tree:
> > ./libraries/base/configure.ac:=23 See
> > http://www.haskell.org/pipermail/cvs-ghc/2011-September/065980.html
> > ./libraries/base/configure:=23 See
> > http://www.haskell.org/pipermail/cvs-ghc/2011-September/065980.html
> > ./libraries/base/autom4te.cache/output.0:=23 See
> > http://www.haskell.org/pipermail/cvs-ghc/2011-September/065980.html
> > ./rts/linker/Elf.c: * See thread
> > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html
> > ./rts/Linker.c: // see
> > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038570.html
> > ./testsuite/tests/typecheck/should=5Ffail/tcfail201.hs:--
> > http://www.haskell.org/pipermail/cvs-ghc/2008-June/043173.html
> >
> > I'm happy to remove them if that's what we want to do.
> >
> > Coincidentally cvs-ghc=40haskell.org appears 58 times in the GHC sour=
ce
> > tree. Do we want to keep using it=3F
> >
> > Thanks,
> > Bartosz
> =20
> =20
> --
> =20
> Subject: Digest =46ooter
> =20
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> ghc-devs mailing list
> ghc-devs=40haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> =20
> =20
> --
> =20
> End of ghc-devs Digest, Vol 169, Issue 60
> *
> =20


signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Gershom B]

On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com) wrote:
>
> I think it is what the process should change. It makes sense to have
> two committees only if we have multiple language implementations, but
> it is not the case. Prime committee may accept or reject e.g. GADTs,
> but it will change nothing because people will continue using GADTs
> regardless, and any feature accepted by the Prime committee will
> necessary be compatible with GADTs extension.

I disagree. By the stated goals of the H2020 Committee, if it is successful, 
then by 2020 it will still for the most part have only standardized ony a 
_portion_ of the extentions that now exist today.

There’s always been a barrier between implementation and standard in the 
Haskell language, that’s precisely one of the things that _keeps_ it from 
having become entirely implementation-defined despite the prevelance of 
extensions.

Having two entirely different processes here (though obviously not without 
communication between the individuals involved) helps maintain that.

—Gershom


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

Re: Warnings, -Wall, and versioning policy

[Gershom B]

On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
<simo...@microsoft.com> wrote:

> An implication is that GHC is free to introduce new warnings X into -Wall.   
> Indeed doing so would be good, because the warning X might later move into 
> the default set.  Indeed for such warnings, adding a "PS: this warning will 
> become the default in GHC 9.2" might be a useful way to signal the upcoming 
> change.  Then you can use -Wall and look for any "PS" indicators.

Yep. In general I think we don't know how _much_ noise a warning will
create until it makes it into the wild, so just as with other new
features its good to give them a bit of a "dry run" before deciding
that they come "by default."

> You don’t give a rationale for (2) but I think you intend that if someone 
> wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to 
> fall over.  Worth articulating the rationale.

Yes, that's exactly the rationale. It doesn't help us short term, but
longer term it should let users fiddle with warning flags more freely.

I think the general issue with three releases is not whether or not
GHC introduces warnings and at what pace, but that certain _types_ of
warnings (in particular redundancies, be they constraints, imports,
etc) will fire on entirely desirable code due to certain migration
paths. Most of the tricks we developed for backwards-compatible
migrations essentially depend on certain redundancies in code for a
period. Those can't be removed without hurting backwards-compatibility
of code, but their presence also induces warnings.

So as a whole "warning freeness" and "backwards compatible migrations"
become increasingly at odds with one another.

A full refactor of our warning sets would probably help in this
regard, so that the default advice could be "good code is -Wlint clean
but not necessarily -Wpedantic clean". Or even "is clean under
-Wpedantic -Wno-redundancies".

--Gershom

>
> | -Original Message-
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Gershom B
> | Sent: 13 January 2016 02:20
> | To: GHC users <glasgow-haskell-us...@haskell.org>; ghc-devs@haskell.org;
> | Edward Kmett <ekm...@gmail.com>; Herbert Valerio Riedel <h...@gnu.org>; 
> Simon
> | Marlow <marlo...@gmail.com>
> | Subject: Re: Warnings, -Wall, and versioning policy
> |
> | Hi Simon. I think you raise important issues here, although I believe you’re
> | mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects
> | -Wall.
> |
> |  What I’d suggest is perhaps the following.
> |
> | 1) The libraries committee put forward -Wall cleanliness as an _aspirational
> | goal_ rather than a final product, noting that the actual cleanliness might
> | be with regards to `-Wall -Wno-foo -Wno-bar``.
> |
> | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
> | than an _error_ on `-W` followed by an unrecognized string.
> |
> | 3) No warning flags be introduced into the _default_ set without at least a
> | few releases in some other set such as `-Wall`.
> |
> | We may also want to try to maintain a “best practices” example cabal file
> | that shows how one can build with additional warnings under a “dev” flag, 
> and
> | with fewer warnings otherwise — so that the noise inflicted on package devs
> | under their builds doesn’t get inflicted on all end users, and even perhaps
> | with different warning flags per ghc version flag.
> |
> | I think this will respect the concerns of people that like to use `-Wall`,
> | want to have relatively warning clean code, and want to have some degree of
> | backwards compatibility (which is not an unreasonable combination in my
> | opinion).
> |
> | Some related
> | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and 
> https://ghc.has
> | kell.org/trac/ghc/wiki/Design/Warnings
> |
> | Cheers,
> | Gershom
> |
> |
> | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlo...@gmail.com) wrote:
> | > Hi folks,
> | >
> | > We haven't described what guarantees GHC provides with respect to -Wall
> | > behaviour across versions, and as a result there are some differing
> | > expectations around this. It came up in this weeks' GHC meeting, so we
> | > thought it would be a good idea to state the policy explicitly. Here it 
> is:
> | >
> | > We guarantee that code that compiles with no warnings with -Wall
> | > ("Wall-clean") and a particular GHC version, on a particular
> | > platform, will be Wall-clean with future minor releases of the same
> | > major GHC version on the same platform.
> | >
> | > (we plan to p

Re: [ANNOUNCE] 7.10.3 release candidate 3

[Gershom B]

The link provided for rc3 (https://downloads.haskell.org/~ghc/7.10.3-rc3/) 
appears to be empty at the moment.

However I have had success with a different link: 
https://downloads.haskell.org/~ghc/ghc-7.10.3-rc3/

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

Haskell Platform Plans

[Gershom B]

Dear all,

As you know, Mark has passed on the Haskell Platform maintainer hat to me.

I wanted to give a heads-up on current plans to keep folks in the loop.
This message has three sections, first the 7.10.3 release, next the 8.0
release, and finally some general musings on fiddly details and future
plans.

1) 7.10.3

The 7.10.3 release candidates have been out for windows and unix for a bit.
As I understand it there is still work underway on the mac build, but that
will hopefully be coming shortly. The plan is to release a new platform
roughly simultaneously. This platform will work essentially as in the past,
for two reasons. First, because it is the last release in the 7.10 series
and should be seen like the 7.10.3 compiler as just incorporating some
necessary patches rather than any serious changes. Furthermore, the future
plans underway rely on a few patches to cabal which have been merged, but
are not yet in any existing cabal-install release. A few packages have
received minor version bumps, as follows:

PACKAGE   7.10.2-a   latest
---
case-insensitive  1.2.0.4   1.2.0.5
fgl   5.5.2.0   5.5.2.3
GLUT  2.7.0.1   2.7.0.3
GLURaw1.5.0.1   1.5.0.2
HUnit 1.2.5.2   1.3.0.0
OpenGL2.12.0.1  2.13.1.0
OpenGLRaw 2.5.1.0   2.6.0.0
primitive 0.6   0.6.1.0
syb   0.5.1 0.6
scientific0.3.3.8   0.3.4.2
StateVar  1.1.0.0   1.1.0.1

A few packages were held back due to dependency issues (notably zlib) and
additionally, packages shipped with ghc were held back to the versions that
will be shipped with 7.10.3.

2) 8.0

We also plan to ship a new platform concurrently with the ghc 8.0 that
should be released early next year.

That platform will implement some long-discussed and requested changes.
First, the platform already ships with msys on windows. However, it does
not do so in a way that lets you, as with minGHC, install the network
library directly, or for that matter install directly other libraries that
use build-type configure. This is because the msys binaries don't get
placed into the path, by design. The new platform will ship with a newer
cabal, incorporating a patch (pull request #2480) that uses the
extra-prog-path setting for build-type: configure. This should allow
network and other things reliant on build-type: configure to directly cabal
install. The goal for the platform on windows will be that any packages
binding to msys libraries _should_ be cabal installable without hassle. If
you maintain a library that you think would be a good test-case for this,
please drop a line so we can work together towards this goal.

Second, the default platform will be _minimal_. That is to say that it will
_only_ install into the global package database those packages that are
directly shipped with ghc, and not any additional platform packages.

"Blessed" platform packages will however still be shipped as a "default
user cabal.config" file, so in a setting where users want to work
unsandboxed, their versions of platform libs will remain pegged to those
chosen by the platform, should they not choose to alter their settings. In
a sandboxed setting, or in the presence of a local cabal.config generated
by a freeze, those constraints will be disregarded.

Furthermore, it is likely but not certain that the "nix-like cabal" or
"no-reinstall cabal" will be available for the 8.0 release. If this is the
case, users will be able to operate in an unsandboxed environment without
conflicts, as multiple instances of the same version of a package, with
different dependency choices, will be able to live side-by-side.

Third, the platform will ship not only with cabal-install, but also with
the stack tool, so that users can choose either workflow, depending on
their project or preferences. A number of people have adopted the stack
tool, and many beginners have reported success with it as well, so it will
be good to provide that functionality out of the box with every platform
install.

Time and resources permitting we would also like to ship a platform version
_with_ the platform libraries prebuilt and included, as that is also a use
case that some people continue to like. However, this is a secondary
priority, and contingent on us getting our build infrastructure into a good
enough shape to make this not too much extra hassle.

I'm excited about these changes, and confident we can get their in a
timespan that matches the 8.0 release of ghc.

3) Generalities

As I mentioned, it would be good to have a more uniform build
infrastructure. Generally, I have put out some feelers and am working
towards extending the ghc nightly buildbot infrastructure to both cover
more platforms and also cover more tools -- not only ghc, but cabal, the
platform, perhaps haddock, ghcjs, etc. This way we can get an economy of
scale and many of our core tools will be able to all share regular
automated 

Re: [haskell-infrastructure] the platform has outgrown Travis-CI

[Gershom B]

Mark: Is this still an issue? I don't know if phab is the right place --
would have to check with Austin. But if this is a roadblock on the
platform, we should certainly do something :-)

-g

On Sun, Jun 7, 2015 at 12:33 PM, Mark Lentczner 
wrote:

> I finally figured out what was wrong with the Travis CI build for Haskell
> Platform, and got it all working w/hvr's .debs of GHC (for the boot
> compiler)... and ran smack into this:
>
> Your test run exceeded 50 minutes.
>
>
> SO... I'd like to find another CI solution. Is phabricator.haskell.org an
> option? Can we / should we create a project there?
>
> - Mark
>
> ___
> haskell-infrastructure mailing list
> haskell-infrastruct...@community.galois.com
> http://community.galois.com/mailman/listinfo/haskell-infrastructure
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving the Get Haskell Experience

[Gershom B]

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

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

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

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

—Gershom


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

Test posting -- debugging mailinglist issues.

[Gershom B]

Disregard this, sorry for the noise :-)

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

[Gershom B]

For the info of all, here is the proposal:
https://gist.github.com/fugyk/37510958b52589737274

The mentors are Ryan Trinkle and Thomas Tuegel. Hopefully as the project
proceeds, Vishal will be checking in with us, asking questions and seeking
clarification where necessary, etc.

--Gershom


On Thu, May 7, 2015 at 5:19 PM, Mikhail Glushenkov 
the.dead.shall.r...@gmail.com wrote:

 On 7 May 2015 at 22:34, Simon Peyton Jones simo...@microsoft.com wrote:
  Dear Cabal developers
 
  I guess everyone is busy, but I feel a bit stuck on knowing how to make
  progress on this thread.

 Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have
 to wait and see what comes out of it now.
 ___
 cabal-devel mailing list
 cabal-de...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

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

Re: HP 2015.2.0.0 and GHC 7.10

[Gershom B]

On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentcz...@gmail.com) 
wrote:
 Is soon measured in hours? If not - I suggest that it misses.
  
 I'm pushing that we change how we do this Platform thing - and make it
 stick, like glue, to the GHC release schedule. Sure, this time 'round we'll
 be out of sync with those it's almost there packages... but next time
 we'll know it's coming and hopefully, we'll have these panic attacks as GHC
 is in beta not post-Release.

+1 to this sentiment. Now that we can do efficient platform builds, better to 
release regularly and efficiently. Otherwise we’ll always be playing catch-up 
to “one more thing.”

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

Re: wither the Platform

[Gershom B]

On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (c...@cse.unsw.edu.au) 
wrote:
  
 Look. I guess, I count as a power user ;) I rarely use sandboxes. They are 
 great for a particular  
 type of use, but you can do many things quite happily without them. (Ask 
 SimonPJ; I reckon  
 he doesn’t use sandboxes either.)

Ironically, the only time I have had to use a sandbox was in doing work on the 
new Haskell homepage (it is written in Yesod). In fact, that was insufficient 
for some reason and I had to install hsenv as well and use that for an even 
“stronger” sandbox. As I have said, I also install the platform whenever 
possible. Believe me, you are preaching to the choir!

 The mistake here is to try to make this a one-size-fits all. I honestly don’t 
 care about  
 a platform that is ideal for everybody. I want something that I can point 
 newbies at that  
 makes them happy quickly. That needs to be one download with all the packages 
 that you  
 need to get going included.
..
 Well, we have got people who want to learn Haskell now and who use Haskell as 
 part of their 
 coursework now. Why make them wait for future work which will probably take 
 longer than 
 planned, needs to be rolled out, etc?

I do not understand this. The platform still exists, is still great, is not 
going anywhere, and as far as I can tell, is on track to become even better. 
You can point people at https://www.haskell.org/platform/ or you can point them 
at downloads.haskell.org which links to there or you can point them at 
www.haskell.org and tell them “the downloads page gives you options, pick the 
platform option.” Nobody who wants to use the platform must wait for anything.

Nobody has taken anything from you, or anyone else. Nobody wants to take 
anything from you, or anyone else. We just want to recognize that this other 
set of users — those coming from other languages, and wanting to “from the 
gate” install large sets of dependencies — this set of users has grown and is 
growing and if we don’t want them to become frustrated and bounce off Haskell, 
then we need to provide resources for them too, and steer them to things that 
meet _their_ needs as well. They are not lucky enough to be in your class and 
be guided by an instructor.

If you want to patch the downloads page so that it more clearly highlights the 
platform option or makes clear that if you want to be a “power user” and manage 
lots of dependencies with abandon you may want the minimal installers, and if 
you want “a good, wide-ranging set of defaults to experiment and learn with” 
then you want the platform, or some other wording that is perhaps clearer, or 
anything at all like that, then there is again a ticket on the github homepage 
to improve the language, and pull requests are welcome. The compromise wording 
on the page now is just that: a compromise. I don’t even claim it to be a great 
one, just what was settled on. If you (or anyone) can improve it to present 
both sorts of installers and the tradeoffs more clearly and more simply, please 
do!

There are different types of beginners, and meeting all their needs (as well as 
the needs of long-timers of various stripes, etc) all at once is a tricky task. 
Again, the main advantage that students have is that they have instructors who 
can guide them in what they recommend to download, how to get started, etc. So, 
for the moment, I would argue that students are not the most fundamental target 
audience for that snippet of text on the downloads page. But, that does not 
mean the language cannot be better for students too. And I would very much like 
it to be!

Beyond that I don’t feel we’re discussing anything as metaphysical as 
flexibility or simplicity. And I don’t feel my own preferences are necessarily 
better or worse than others — I just want two things, as do we all I think. A) 
To have the best possible toolsets available for all types of users in all 
possible development setups, and B) To somehow condense the core of that 
information into an easily digestible form to help steer visitors to the 
Haskell homepage to the setup that is right for _them_. 

As always, anybody who wants to help with this in any regard with the new 
homepage is welcome and invited to do so. We have plenty of open tickets and 
room for improvement all around, a helpful crew on the #haskell-infrastructure 
irc, and patches, pull requests, and new tickets are always welcomed.

Best,
Gershom


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

Re: [haskell-infrastructure] wither the Platform

[Gershom B]

On March 23, 2015 at 10:02:11 AM, Mark Lentczner (mark.lentcz...@gmail.com) 
wrote:
 I do too...! But follow the new Haskell.org pages like you are a user just
 want to install Haskell... you'll never end up with the Platform.
  
 It looks like the Platform deprecated on the Haskell.org site for Linux and
 OS X in June
 ,  
 and for Windows in Jan
  
 .
 *Infrastructure team:* Was there a discussion and decision to do that
 somewhere?


I thought the current language on the page was rather balanced?

That said, the initial people working on the site strongly leaned towards 
recommending minimal downloads over the platform in general, and as OS X and 
Windows developed good minimal installers the site was updated to point to 
them. In the editorial process on the site we, actually worked to make sure the 
platform _was_ highlighted more than it had been. And every time the site has 
come under public review (three times thus far, at least) the issue of minimal 
installers vs. platform was contentious, but with the former voice dominating. 
Note that there remains an issue under discussion about making the presentation 
of the two alternatives more balanced yet: 
https://github.com/haskell-infra/hl/issues/55 (patches and pull requests 
welcome!).

In any case, here is my problem. I would like us to be in a situation where we 
can always say “use the platform” to new users. I don’t think we are there, 
because new users will insist on using whatever libraries they read about as 
the latest and greatest, and those libraries do necessarily take care to ensure 
platform-compatability. (And if you tell them that straying from the platform 
is not for the inexperienced, they will snap at you and call you condescending, 
and insist they know what they are doing… shrug). Since we cannot mass-alter 
this sort of attitude among new users, then the next best thing would be to 
mass-alter the attitude among people who write not-platform-compatible 
libraries. But that is hard to do as well! (A “badge” on hackage for 
platform-compatible packages would do wonders, I think).

So, in the meantime, we need to get the centralized, uniform platform 
installers into a shape where we _can_ uniformly recommend them. And, as I 
suggested, it seems to me the way to go about doing that is decoupling the 
“library curation” element of the platform from the “installing haskell” 
element. That, or ruthlessly marking packages on hackage that do not work with 
the current platform with a big red X :-)

Cheers,
Gershom
___
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

[Gershom B]

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

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

My understanding is that the problem Yitz is discussing is much more
straightforward and easy to fix.

The issue is that if I have an empty global package db and enter a
sandbox and cabal-install something, then I will get one package
install plan. But if I have a well populated package db, then
attempt to cabal-install something in the sandbox, the plan will
attempt to use the packages from that global db, and so will often be
a different, and perhaps worse plan (especially if it runs into quirks
in the solver).

This is discussed on the associated reddit thread here:
http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7

As I proposed on the main email thread, I think it would make sense to
make the easy, default option the one which, in sandboxes, effectively
ignores the global db for solving. This leads to more duplication and
longer build times, but it is safer. However, we should have an easy
setting/flag (to be set when initializing a sandbox or any time
thereafter) which can switch the preference over to preferring to use
already installed versions in the global db. That way, new users can,
naively, get a _lot_ of isolation with sandboxes, and those who know
what they are doing can opt out in order to reduce duplication of
installs and cut down on build times.

Addition of a `prefer-global-db` flag and a good default setting for
it (i.e., false) seems to me like it would resolve the _central_ issue
people have with the platform, and situate us well to unilaterally
recommend it as the default install option.

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

Re: [haskell-infrastructure] wither the Platform

[Gershom B]

On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley acow...@gmail.com wrote:

 I don't understand this attitude. You say that neither new users nor package
 authors agree with your stance on the HP, so you want to force their hands.
 Presumably package authors know what they're doing for themselves, and the
 majority of evidence we have is that new users who stick with the language
 do not like the way the HP works
 https://reddit.com/r/haskell/comments/2zts44/wither_the_platform/.

No, this is not what I said. I was explaining that it rather
difficult, even if we wanted to force their hands, to imagine that we
could do so. I will say that I do not share your belief that package
authors know what they are doing, in general. If they did, I would
imagine that nearly all packages would ensure they would work with the
current platform. But getting programmers to all agree on something
like that is herding cats, and all it takes is a few people saying
feh on the platform but nonetheless producing otherwise good
packages that come into widespread use to _in general_ mean that many
packages which directly or indirectly want to use those dependencies
must also now split off from support for the platform.

So I agree that people have voted with their feet, and we need to
catch up to that.

In fact, it seems to me from this discussion that there are only _two_
things we need to do to make the platform the recommended install path
for all platforms again:

1) Incorporate the improvements to windows builds that have been
pioneered by the MinGHC project (in particular so that
platform-installed windows ghc can build the network package properly,
and perhaps even the GL stuff).

2) Address the problem that in a sandbox you will get a different
install plan depending on your global package db. I would suggest this
be done by setting a default preference of the sandbox to ignore
global packages, and allow that to be overridden with an easily
configurable flag or setting or the like. That way, new users can pay
the longer compile price for a guaranteed-safer experience, and more
experienced users can choose to use / build up a broader library of
packages they can share across sandboxes.

(Certainly some nix-like tricks in cabal could also help address the
repeated builds problem, but a flag can be implemented much more
quickly as a short-term measure).

All that said, I think it would _still_ be better if more package
authors paid attention to backwards-compatibility across releases, and
it would _still_ be better for new users if they didn't go off and
bash their heads against the newest and least stable packages around.
But that is indeed a different problem.

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

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

[Gershom B]

I recall having some discussions with Mathieu Boespflug regarding how the
static pointers work could be of use here. (And also Richard Eisenberg?) In
particular, we want to demand a special property of our validation
functions -- that they can safely be used at compile-time without
necessarily linking in the world and invoking the whole of template
haskell.

A function that is static should in a sense have this sort of property?
And so requiring that our validation functions be static seems like a
useful thing from an implementation standpoint. Static semantics might also
help force the thunk on what the correct relationship to polymorphism is.

I guess the remaining question is then where to add them. I suppose we
could stick them with special semantics on Num and IsString or the like and
do it by magic?

Alternately we could maybe have a whole class of compile-time static
functions that we just explicitly use, and all have the property that they
have type a - a for some concrete a, and that the value they are
applied to is static. These functions are then applied at compile time, and
forced to whnf. If they toss an error it is a compile error, otherwise they
are not present in the generated code.

There are other design variations possible, but that one feels pretty neat
to me, if feasible.

So then I could write

foo :: Even
foo = even 6

for example, and get errors at compile-time.

On top of this we could add a special way to augment Num, IsString, etc
with such methods to yield the desired:

foo :: Even
foo = 6

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

Re: RFC: Dropping Windows XP support

[Gershom B]

One concern here is that even with XP falling out of support, Windows Server 
2003 remains supported through July 2015, and so we should give it a little 
chunk of time after that falls out of support from Microsoft before we stop 
supporting that. I think the limitations in Server 2003 are roughly the same as 
XP.

http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/

However, the next Windows Server (2008) should share all Vista features.

Cheers,
Gershom


On November 7, 2014 at 1:16:39 PM, Austin Seipp (aus...@well-typed.com) wrote:
 Hi all,
 
 This is a quick discussion about the current system requirements for
 Windows builds.
 
 Spurred by a recent[1] LLVM discussion, I'd like to raise the question
 of dropping support for Windows XP, and bumping the minimum required
 version to Windows Vista or even Windows 7.
 
 For one, Microsoft doesn't support XP anymore, so most people are
 moving off it anyway. 'Soon' even XP Embedded will be obsoleted.
 
 But second, Vista and beyond introduced useful new APIs we could use.
 I was digging through the LLVM thread and two came out to me:
 
 1) We could switch to using slim reader/writer locks, which in some
 workloads may work out better than critical sections (they'll win on
 more read-heavy workloads). The downsides is there's no recursive
 locking but we don't use that anyway (and recursive locks are
 considered bad by many anyway[2]).
 
 2) We could probably use an actual condition variables API that was
 introduced with Vista. Currently we use a giant EVENT object to
 emulate the API, which could be replaced with the real deal.
 
 Both of these could be nice wins for simplicity and performance I think.
 
 I know there are some corporate users out there who this may impact,
 and users as well. I'd like to know what people think. Particularly
 what version we should standardize on.
 
 FWIW, I don't plan on changing any of this until the 7.12 release at least.
 
 [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419
 [2] http://www.zaval.org/resources/library/butenhof1.html
 
 --
 Regards,
 
 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 Glasgow-haskell-users mailing list
 glasgow-haskell-us...@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 

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

Re: GADTs in implementation of Template Haskell

[Gershom B]

On October 20, 2014 at 2:35:27 PM, Richard Eisenberg (e...@cis.upenn.edu) wrote:
 Having done so, I'm not 100% convinced that this is the right thing to do. I 
 would love feedback  
 on my full, concrete proposal available at 
 https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs  
  
 Is this a change for the better or worse? Feel free either to comment on the 
 wiki page or  
 to this email.
  
 Thanks!
 Richard

As I understand it, the big downsides are that we don’t get `gunfold` for Dec 
and Pragma, and we may not get `Generic` instances for them at all.

At first this felt pretty bad, but then I reviewed how generics and TH tend to 
get used together, and now I’m not _quite_ as anxious. In my mind the main use 
case for them is in things like this: 
http://www.well-typed.com/blog/2014/10/quasi-quoting-dsls/ — skimming the code 
involved, and the way `dataToExpQ` and friends tend to work, the key bit is 
having the generic instances on what we’re inducting on, not what we’re 
building… By the time we hit concrete TH syntax, it feels a bit late to be 
doing further generic transformations on it, so I have a suspicion this won’t 
hit anyone. I certainly don’t think it’ll affect _my_ uses of TH at least :-)

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