Re: Call for GHC Maintainers

[Herbert Valerio Riedel]

Moritz,

Moritz Angermann  writes:
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of

You skipped GHC 8.2 ;-)

In any way, I'd be interested in helping making GHC 8.2.3+ happen!

Cheers,
Herbert


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

Re: Question about negative Integers

[Herbert Valerio Riedel]

On Fri, Nov 15, 2019 at 5:04 PM Sylvain Henry  wrote:

> Question is: do we need/want to keep this behavior?


Yes ;-)

I chose it quite intentionally after benchmarking and carefully examining
various approaches, and with the intent to use a common-denominator
representation which would be easy to supplement with alternative bignum
implementations.

Since you didn't seem to reference it, I wonder if you even saw the page
where some of my design rationale was written down as well as hinting at
how I intended to make the backend selectable via a link-time flag (similar
to how you'd select the RTS via -threaded or -prof, you'd also be able to
select the integer backend at link-time w/o the need to recompile
anything). See

https://gitlab.haskell.org/ghc/ghc/wikis/design/integer-gmp2

However, some time ago I did discuss picking up that plan again, but he did
point out that it would make a lot more sense to leverage Backpack for
this, as it seems to be a much more elegant solution to this problem than
the simple but platform-specific link-time approach I was aiming for. Ben
put it quite bluntly that if Backpack can't be used for this thing it was
basically designed for, we should consider ripping it out again as it would
have effectively failed its promise.

And I do agree! Back when I originally redesigned and rewrote integer-gmp
from scratch, Backpack wasn't available yet. But now we have it, and a
Backpack based solution would IMO indeed be the proper solution at this
point to the problem of abstracting over integer-backends as well as
representations -- it could even be combined with my original plan for C
FFI based platforms (but that's mostly an optimization at that point for
the special case where the backends share said common representation at the
ABI level).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

On 2019-03-28 at 18:33:58 +, Michael Peyton Jones wrote:
> +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used
> by many other tools that handle this kind of thing. For example:

..just because everyone else does it this way doesn't mean that it's the
best way.. I'd argue it might be a sign of lack of imagination  ;-)

In fact, personally I never liked `virtualenv` much as it required me

[...]

> The advantage is that the scoping of the special configuration is very
> clear: it's the shell that the command launches. Programmers are very used
> to this, and changes in shell environments are expected to change the
> behaviour of programs.

I'm a programmer. I'm very used to devel tooling I'm expected to invoke
as a programmer to be affected by what's in scope as a function of the CWD,
e.g. `cabal`, `git`, `make` to name a few.

And to me GHCi falls into the same category, it's a tool I'm expected to
interact directly with -- otherwisw it's CLI would be designed a lot
different; as a matter fact it's been supported for ages to pick up a
`.ghci` by walking up your fs system starting at CWD until one is found...
So there's clearly precedent for the logical next step that ghc env
files represent...

> Plus, as functional programmers this is just the sort of idiom we use all
> the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`.

Sure, but then again, we're talking about the unix shell which leans
towards different idioms than the functional programming paradigm; and
insisting to impose one paradigm on a language which isn't rooted in
that paradigm is often not a good idea either...

> On the negative side: I've helped ~6 people at my company alone debug
> issues due to environment files.

Which GHC versions was this with?

[...]

> *However*, I think Herbert is quite right that this particular proposal
> amounts to "remove this feature". The following might be a compromise
> solution: we can introduce `cabal ghc` as a parallel feature, and then in a
> few releases we can assess the popularity of the two approaches, and
> potentially stop generating environment files from Cabal if people aren't
> using them.
>
> I think there are enough people that feel strongly about environment files
> that we could get together the manpower to write `cabal ghc`.

Sure, but this totally misses the point. We already have `cabal ghc` but
the point was (as Duncan also pointed out in an earlier reply) to *not*
have to require cabal as a middleman.

I want to be able to invoke `ghc` and `ghci` directly, without having to
invoke `cabal` everytime. If I wanted to always invoke `cabal ghci` I
wouldn't have needed to invest time to help with the ghc-env
feature... ;-)

>> This is also a workflow which has been well documented for over a decade
>> in Haskell's literature and instructions *and* this is the same idiom as
>> used by many popular package managers out there ("${pkgmgr} install
>> somelibrary")
>
> This is an interesting bit of background. FWIW, I would feel a lot better
> about this feature if it wasn't a side-effect of `cabal build`. If you had
> to run `cabal
> save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects`
> that wouldn't bother me (I still wouldn't use it, though). The current
> situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} install`,
> which is a bit surprising.

You can tweak your global cabal config to have `cabal` behave just like
that, i.e. then you'd have to explictly opt-in either by writing

  write-ghc-environment-files: always

into your current `cabal.project` configuration, or pass it adhoc on the
CLI

  cabal v2-build --write-ghc-environment-files=always

and as outlined earlier, the per-user env-files (which are picked up
when you are *not* in any project context) are already explicitly
managed (i.e. you have to explcitly invoke `cabal v2-install` to have
them be created/modified)


PS: There's two categories of pkg-env files (the per-HOME ones and the
per-CWD ones) and I'm not sure if people are only complaining about
the CWD ones or also the HOME ones...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

On 2019-03-28 at 15:55:01 +0200, Bryan Richter wrote:

[...]

> If we want Nix-style builds, let's do them Nix style, and use a shell.

Cabal supports multiple workflows/idioms. Sometimes you want a transient
sub-shell (which is the one you're e.g. limited to when using Stack),
while sometimes you want to use cabal to set up an implicit stateful
environment after which you want cabal to be completely out of the
picture and operate in a non-Nix-style idiom...

I for one would hate to remove what I consider a useful feature (which I
happen to use a lot myself and I also show it off when teaching Haskell;
and which we spent a lot of effort designing and implementing in ghc and
cabal over the last couple years...) just to satisfy another group of
people who don't appreciate it and request that those who like it shall
not have it anymore... :-/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

Matthew,

I realize this to be a controversial issue, but what you're suggesting
is effectively an attempt at cutting this cabal V2 feature off at the knees
("If Cabal won't change its default let's cripple this feature on GHC's
side by rendering it pointless to use in cabal").

If ghc environment aren't read anymore by default they fail to have
the purpose they were invented for in the first place!

At the risk of repeating things I've tried to explain already in the
GitHub issue let me motivate (again) why we have these env files: We
want to be able to provide a stateful interface providing the common
idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`
already provided in the past; e.g.


,
| $ cabal v1-install lens lens-aeson
| 
| $ ghc --make MyProgUsingLens.hs
| [1 of 1] ...
| ...
| 
| $ ghci
| GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
| Prelude> import Control.Lens
| Prelude Control.Lens> 
`

or similarly, when you had just `cabal v1-build` something, you'd get
access to your projects dependencies which were installed into ghc's
user pkg-db.

This is also a workflow which has been well documented for over a decade
in Haskell's literature and instructions *and* this is the same idiom as
used by many popular package managers out there ("${pkgmgr} install
somelibrary")

So `cabal v1-build` made use of the user package-db facility to achieve
this; but now with `cabal v2-build` the goal was to improve this
workflow, but the user pkg-db facility wasn't a good fit anymore for the
nix-style pkg store cache which can easily have dozens instances for the
same lens-4.17 pkg-id cached (I just checked, I currently have 9
instances of `lens-4.17` cached in my GHC 8.4.4 pkg store).

So ghc environment files were born as a clever means to provide a
thinned slice/view into the nix-style pkg store.

And with these we can provide those workflows *without* the needed to pass
extra flags or having to prefix each `ghc` invocation with `cabal
repl`/`cabal exec`:

,
| $ cabal v2-install --lib lens lens-aeson
| 
| $ ghc --make MyProgUsingLens.hs
| Loaded package environment from 
/home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
| [1 of 1] ...
| ...
|
| $ ghci
| GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
| Loaded package environment from 
/home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
| Prelude> import Control.Lens
| Prelude Control.Lens> 
`

(and respectively for the `cabal v2-build` workflow)

However, if we now had to explicitly pass a flag to ghc in order to have
it pick up ghc env files, this would severly break this workflow
everytime you forget about it, and it would certainly cause a lot of
confusion (of e.g. users following instructions such as `cabal install
lens` and then being confused that GHCi doesn't pick it up) and
therefore a worse user experience for cabal users.

Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6
have been picking up ghc env files by default (and finally we've reached
the point where the pkg-env-file-agnostic GHC versions are old enough to
have moved outside the traditional 3-5 major ghc release
support-windows!), and now you'd have to remember which GHC versions
don't do this anymore and instead require passing an additional
flag. This would IMO translate to a terrible user experience.

And also tooling would still need to have the logic to "isolate
themselves" for those versions of GHC that picked up env files by
default unless they dropped support for older versions. Also, how much
tooling is there even that needs to be aware of this and how did it cope
with GHC's user pkg db which can easily screw up things as well by
providing a weird enough pkg-db env! And why is it considered such a big
burden for tooling to invoke GHC in a robust enough way to not be
confused by the user's configuration? IMO, shifting the cost of passing
an extra flag to a tool which doesn't feel any pain is the better
tradeoff than to inconvience all cabal users to have rememeber to pass
an additional flag for what is designed to be the default UI/workflow
idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, the Nix
environment which already controls environment vars can easily override
GHC's or cabal's defaults to tailor them more towards Nix's specific
assumptions/requirements.


Long story short, I'm -1 on changing GHC's default as the resulting
downsides clearly outweight IMO.


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

Re: Discussion: Hadrian's defaults

[Herbert Valerio Riedel]

On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud 
wrote:

>
>- The -c option should be the default.
>
> Very strong -1 from me on this one; I've been quite vocal on the Hadrian
issue tracker early on and multiple times against having Hadrian invoke
./configure at all, even more so against having it do so by default. I
don't have the ticket number at my fingertips but it should be fairly easy
to find.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Herbert Valerio Riedel]

On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:

> What about the wiki? Can we migrate that off Trac too?

I worry that it's a lot of work to migrate it away while preserving the
special markup and features that Trac provides; so the resulting pages
will require a significant amount of manual cleanup and finding ways to
emulate the previous features; for instance, I've been using features
like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow
to highlight important information and footnote-like annotations in; and
thus IMO help contribute to present the information less
wall-of-text-ish which is harder to digest.

[...]

> I suppose we can do a squash-merge when committing to keep the history
> clean, but then contributors have a choice - either do GitHub-style
> where you add commits to a PR to update it and we squash on merge, OR
> Phabricator-style where you keep the same set of commits and rebase
> the stack to update it.

(Minor nitpick: in GitLab there are no pull-requests (PRs) anymore;
they're called "MRs" for "merge-request", which is probably a more
accurate term to describe the concept than "PR" is)

Well, if MRs are to be squashed on merge anyway, I'm definitely not
going to waste my time carefully grooming a stack of atomic individually
validating commits via git-rebase-interactive...

> If you want to do dependent commits then you have to use Phabricator
> style. Choices between workflows make things more complicated for
> contributors, and that worries me.

...submitting a stacked set of commits as invidual overlapping MRs
(i.e. where the first MR has only the first commit, the 2nd has the
first two commits from the stack, and so on) -- if that's what you're
referring to as "Phabricator-style" -- sounds like an awkward workflow
to me.

> Does GitLab keep the history of a PR after it has been updated, like in
> Phabricator? So we can see what happened between versions of a PR?

I wonder too how this is represented in GitLab... especially when a MR
is comprised of multiple commits, and those individual commits evolve,
might get reordered, commits added or removed fromt he stack, or when
the whole MR gets rebased in the process...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The future of Phabricator

[Herbert Valerio Riedel]

On 2018-10-30 at 11:53:18 +, Matthew Pickering wrote:

[...]

> A compelling argument to move to gitlab is the possibility of tighter
> integration between the patches and tickets.

You don't need to move to GitLab to achieve that, do you?

In fact, we had this project where somebody invested quite a lot of time
& effort to implement a proof of concept for migrating Trac tickets into
Phabricator which you might remember; it was generally well received
but afaik this was silently forgotten about and so the ball was dropped
in pushing it further:

  https://mail.haskell.org/pipermail/ghc-devs/2016-December/013444.html

I'd much rather sacrifice Trac's benefits by consolidating Trac tickets
into Phabricator (if the tighter integration between code-review &
ticketing is the main compelling argument) than to give up on both,
Phabricator *and* Trac.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Herbert Valerio Riedel]

On 2018-10-30 at 00:54:42 -0400, Ben Gamari wrote:
> TL;DR. For several reasons I think we should consider alternatives to
>Phabricator. My view is that GitLab seems like the best option.
>
>
> Hello everyone,
>
> Over the past year I have been growing increasingly weary of our
> continued dependence on Phabricator. Without a doubt, its code review
> interface is the best I have used. However, for a myriad of reasons I
> am recently questioning whether it is still the best tool for GHC's
> needs.

TL;DR. IMO, Phabricator is still the best tool we know about for *GHC's needs* 
;-)

[...]

> For one, at this point we have no options for support in the event that
> something goes wrong as the company responsible for Phabricator,
> has closed their support channels to non-paying customers.

While it's certainly a good idea to have an emergency plan ready, I
don't think we need to act prematurely before something has actually
happened. Phabricator is open-source and therefore there's little that
can go so catastrophically wrong that we wouldn't give us more than enough
time to act upon.

(Also, there's still the option of becoming part of that
paying-customers group and thus influence their focus -- after all, we'd
be contributing to a improving an OSS codebase; and not a proprietary
closed product such as GitHub)

> Furthermore, in the past year or two Phacility has been placing their
> development resources in the parts their customers pay them for, which
> appear to be much different that the parts that we actively use. For
> this reason, some parts that we rely on seem oddly half-finished.
>
> This concern was recently underscored by some rather unfortunate
> misfeatures in Harbormaster which resulted in broken CI after the
> Hadrian merge and now apparent bugs which have made it difficult to
> migrate to the CircleCI integration we previously prepared.
>
> Perhaps most importantly, in our recent development priorities survey
> our use of Phabricator was the most common complaint by a fair margin,
> both in case of respondents who have contributed patches and those who
> have not. On the whole, past contributors and potential future
> contributors alike have strongly indicated that they want a more
> Git-like experience. Of course, this wasn't terribly surprising; this
> is just the most recent case where contributors have made this
> preference known.
>
> Frankly, in a sense it is hard to blame them. The fact that users need
> to install a PHP tool, Arcanist, to contribute anything but
> documentation patches has always seemed like unnecessary friction to me
> and I would be quite happy to be rid of it.

[...]

> Indeed we have had a quite healthy number of GitHub documentation
> patches since we started accepting them.


While I do agree that Phabricator's impedance mismatch with Git idioms
has bugged me ever since we started using it (I even started
implementing https://github.com/haskell-infra/arc-lite as a proof of
concept but ran out of time), I still consider some of its features
unparalleled in PR-based workflows as provided by GitHub or GitLab.

For example, to me the support for stacked diffs outweights any
subjective inconvenience brought forward against Phabricator

https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/?fbclid=IwAR3JyQP5uCn6ENiHOTWd41y5D-U0_CCJ55_23nzKeUYTjgLASHu2dq5QCc0

The PR workflow is perfectly well-suited for trivial documentation
patches to a project; but that's for contributions that frankly are of
minor importance; they're surely nice to have, but they're not the kind
of contributions that are essential to GHC's long-term sustainability
IMO.

The reality IMO is that everybody tends to come up with this or that
complaint about a tool which isn't their favorite one, but it's hardly a
real barrier to contribution. In fact, I bet the majority of the people
that now complain about phabricator not being GitHub will be vocally
unhappy about having to create a GitLab account and that GitLab is not
GitHub...

Sure, by not trying to make everyone (specifically non-MVP contributors)
happy we might loose some typo fixes or whatever, but do we really want
to optimize the workflows for casual drive-by contributors which may
contribute a couple of trivial patches and then never be seen again, at
the expense of making life harder for what is already a complex enough
task: managing and reviewing complex patches to GHC where it's paramount
to use the best possible code-review facilities, and not shift the cost
from contributors to the even more important people, the ones maintaing
the projects as well as having intimate knowledge about the internals of
GHCs (but unfortunately have a very tight time & cognitive time budget
to spend on GHC, and which are the ones we really want to be able to
review those patches with as little cognitive overhead as possible.

So yes, phabricator is optimized for reviewers, and that's IMO a very
good thing and outweights the benefit of 

Re: [ANNOUNCE] GHC 8.6.1 released

[Herbert Valerio Riedel]

Hello everyone,

Here's an addendum to the announcment as it ommitted an important detail:

GHC 8.6.1 is only guaranteed to work properly with tooling which uses
lib:Cabal version 2.4.0.1 or later.

As such, GHC 8.6.1 works best with ​`cabal-install` 2.4.0.0 or later;
please upgrade to `cabal-install` 2.4.0.0 if you haven't already.

Note that cabal-install 2.4 supports all GHC versions back till GHC
7.0.4 and we also strongly recommend to use the latest available stable
release of `cabal` even with older GHC releases as bugfixes and
improvements aren't always backported to older Cabal releases as well as
to be able to benefit from recently added CABAL format features[8] (or
be able to access package releases on Hackage[9] which rely on those
features) which require recent enough versions of Cabal as well.

Note that binaries aren't available on cabal's download page[1] yet.

If you're on Ubuntu or Debian, you can get a compiled cabal-install 2.4
`.deb` package via Apt from

- https://launchpad.net/~hvr/+archive/ubuntu/ghc

or

- http://downloads.haskell.org/debian/

respectively.

Binary versions for macOS and Windows are also expected to become
available via [2] and [3] soon (and also at [1]).

In the meantime, if you already have GHC 7.10 or later (together with a
compatible `cabal` executable) installed, you can easily install cabal
2.4 yourself from Hackage[9] by invoking

cabal install cabal-install-2.4.0.0

and making sure that the resulting `cabal` executable is accessible via
your $PATH; you can check with `cabal --version` which should emit
something along the lines of

$ cabal --version
cabal-install version 2.4.0.0
compiled using version 2.4.0.1 of the Cabal library 



Finally, the Haskell Platform[4] release for GHC 8.6.1 should be
available soon as well which provides yet another recommended "standard
way to get GHC and related tools"[5] in a uniform way across multiple
operating systems. See [4] and [5] for more details about the standard
Haskell Platform distribution.


 [1]: https://www.haskell.org/cabal/download.html
 
 [2]: https://haskell.futurice.com/
 
 [3]: https://hub.zhox.com/posts/chocolatey-introduction/
 
 [4]: https://www.haskell.org/platform/
 
 [5]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009379.html

 [6]: https://launchpad.net/~hvr/+archive/ubuntu/ghc
 
 [7]: http://downloads.haskell.org/debian/

 [8]: https://cabal.readthedocs.io/en/latest/file-format-changelog.html

 [9]: http://hackage.haskell.org/
 

-- Herbert


On 2018-09-21 at 20:57:02 -0400, Ben Gamari wrote:
> Hello everyone,
>
> The GHC team is pleased to announce the availability of GHC 8.6.1, the
> fourth major release in the GHC 8 series. The source distribution, binary
> distributions, and documentation for this release are available at
>
> https://downloads.haskell.org/~ghc/8.6.1
>
> The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a
> number of exciting features. These most notably include:
>
>  * A new deriving mechanism, `deriving via`, providing a convenient way
>for users to extend Haskell's typeclass deriving mechanism
>
>  * Quantified constraints, allowing forall quantification in constraint 
> contexts
>
>  * An early version of the GHCi `:doc` command
>
>  * The `ghc-heap-view` package, allowing introspection into the
>structure of GHC's heap
>
>  * Valid hole fit hints, helping the user to find terms to fill typed
>holes in their programs
>
>  * The BlockArguments extension, allowing the `$` operator to be omitted
>in some unambiguous contexts
>
>  * An exciting new plugin mechanism, source plugins, allowing plugins to
>inspect and modify a wide variety of compiler representations.
>
>  * Improved recompilation checking when plugins are used
>
>  * Significantly better handling of macOS linker command size limits,
>avoiding linker errors while linking large projects
>
>  * The next phase of the MonadFail proposal, enabling
>-XMonadFailDesugaring by default
>
> A full list of the changes in this release can be found in the
> release notes:
>
> 
> https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html
>
> Perhaps of equal importance, GHC 8.6 is the second major release made
> under GHC's accelerated six-month release schedule and the first set of
> binary distributions built primarily using our new continuous
> integration scheme. While the final 8.6 release is around three weeks
> later than initially scheduled due to late-breaking bug reports, we
> expect that the 8.8 release schedule shouldn't be affected.
>
> Thanks to everyone who has contributed to developing, documenting, and
> testing this release!
>
> As always, let us know if you encounter trouble.
>
>
> How to get it
> ~
>
> The easy way is to go to the web page, which should be self-explanatory:
>
> https://www.haskell.org/ghc/
>
> We supply binary builds in the native package format for many
> platforms, 

Re: Any ways to test a GHC build against large set of packages (including test suites)?

[Herbert Valerio Riedel]

Hi Artem,

On Fri, Aug 10, 2018 at 11:05 AM Artem Pelenitsyn
 wrote:
> The task seems to be not solvable even if an affected package (stm in your 
> case and primitive in mine) has already adopted in its master the breaking 
> change but has no corresponding release on Hackage (which will always be the 
> case, because how would you release depending on base which hasn't been 
> released yet).
>
> Some package managers in other languages (Julia's Pkg, go install) allow you 
> to depend directly on master branch of a package if you wish to. I wonder if 
> there is a road here for cabal to take in order to support this kind of 
> unsafe installs.

As a matter of fact we have a couple of options here:

- Add the http://cand.hackage.haskell.org/ package index to your
config and get access to the stm-2.5.0.0 package release candidate
(i.e. 
http://hackage.haskell.org/package/stm-2.5.0.0/candidate/stm-2.5.0.0.tar.gz)

- We could have added `stm-2.5.0.0` to the head.hackage overlay (so
far the "overlay" has only modified existing packages from the primary
hackage index)

- Starting with cabal-2.4, we support adding package tarballs to
`cabal.project`; and this should work also for specifiying remote
tarball locations such as
http://hackage.haskell.org/package/stm-2.5.0.0/candidate/stm-2.5.0.0.tar.gz

- Starting with cabal 2.4, we do support remote git repo deps in
`cabal.project`, see e.g.

 
https://github.com/hvr/cardano-sl/blob/wip/cabal-project/cabal.project#L41-L156

   for an extensive real-world example.


There's work planned to refine/improve these options and make them
more convenient/expressive. Help is appreciated if somebody wants to
help us get there sooner.


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

Re: How do you build base with your own compiler?

[Herbert Valerio Riedel]

Note that `base` is mostly a normal cabal package and you can easily
build it with `cabal new-build` if that's any help.
On Thu, Jun 28, 2018 at 7:09 PM Christopher Done  wrote:
>
> I've built the GHC compiler along with libraries/base in the canonical way.
>
> Now, I want to compile base with my own compiler frontend which will
> do some analysis. Here's what I've done so far:
>
> 1) I've compiled my frontend with the ghc-stage2 compiler and
> registered it. That works.
> 2) I've found the right GHC invocation which looks like this:
>
> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -O0
> -H64m -Wall  -this-unit-id base-4.9.1.0 -hide-all-packages -i
> -ilibraries/base/. -ilibraries/base/dist-install/build
> -ilibraries/base/dist-install/build/autogen
> -Ilibraries/base/dist-install/build
> -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include
> -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include
> -optPlibraries/base/dist-install/build/autogen/cabal_macros.h
> -package-id ghc-prim-0.5.0.0 -package-id integer-gmp-1.0.0.1
> -package-id rts -this-unit-id base -XHaskell2010 -O0
> -no-user-package-db -rtsopts -Wno-trustworthy-safe
> -Wno-deprecated-flags -Wnoncanonical-monad-instances  -odir
> libraries/base/dist-install/build -hidir
> libraries/base/dist-install/build -stubdir
> libraries/base/dist-install/build   -dynamic-too $hsfile
>
> So I
>
> (1) changed stage1 to stage2, so that I could use plugins,
> (2) simply added --frontend GhcFrontendPlugin -package frontend and
> ran that on every file under base/ in a loop:
>
> https://gist.github.com/chrisdone/3ca64592aed2053606d8814f2fa5d772
>
> That seems to work. I basically have what I wanted.
>
> But I'd rather be able to invoke make with e.g.
> GHC_COMPILER=inplace/ghc/stage2 and EXTRA_HC_OPTS=" --frontend
> GhcFrontendPlugin -package frontend". Is there an easy flag to do
> that?
>
> If not, can someone point me where in the makefile I could tweak this?
>
> Cheers
> ___
> 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: Site of ghc.haskell.org is down?

[Herbert Valerio Riedel]

Hi *,

Should be fixed now. Please check.

-- hvr

On Sun, Apr 15, 2018 at 7:49 PM, Simon Peyton Jones via ghc-devs
 wrote:
> I'm getting this too.
>
> --
> The owner of ghc.haskell.org has configured their website improperly. To 
> protect your information from being stolen, Firefox has not connected to this 
> website.
>
> This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
> may only connect to it securely. As a result, it is not possible to add an 
> exception for this certificate.
>
> ghc.haskell.org uses an invalid security certificate. The certificate expired 
> on 15 April 2018, 05:49. The current time is 15 April 2018, 18:48. Error 
> code: SEC_ERROR_EXPIRED_CERTIFICATE
>
> ---
>
> It'd be great to get this fixed, since it means no one can access GHC's Trac.
>
> Simon
>
> | -Original Message-
> | From: ghc-devs  On Behalf Of David
> | Kraeutmann
> | Sent: 15 April 2018 08:20
> | To: ghc-devs@haskell.org
> | Subject: Re: Site of ghc.haskell.org is down?
> |
> | It's an issue with the site---the SSL certificate seems to have expired.
> |
> |
> | On 04/15/2018 02:37 AM, Takenobu Tani wrote:
> | > Hi devs,
> | >
> | > When I accessed `https://ghc.haskell.org/`
> | > , the following message is displayed:
> | >
> | >   Your connection is not secure
> | >
> | > I checked it with Firefox and Chrome.
> | > Is it a matter of site setting?
> | >
> | > Regards,
> | > Takenobu
> | >
> | >
> | >
> | > ___
> | > 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: 8.5 build failure

[Herbert Valerio Riedel]

Hi Simon et al.

On Tue, Apr 3, 2018 at 5:37 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> It seems to be caused by some missing Makefile dependency
>
>
>
> It may be significant that the dependency is a module in libraries/base
> GHC/IO.hs-boot  depending on one GHC.Integer.Type  in
> libraries/integer-gmp.
>


That's quite likely the case, either directly or indirectly. When changing
the dependency graph, especially involving `.hs-boot` files, it happens
quite easily that one needs to give the build-system a hint and make
implicit module-graph dependencies more explicit by adding an explicit
`import SomeModule ()` in the appropriate place. You may find commit of
mine where I did things like that in the past.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] GHC 8.2.2 for WSL Ubuntu 16.04

[Herbert Valerio Riedel]

Hello *,

Even though WSL may eventually address this issue for good, I've setup
a new WSL-optimised flavour of my PPA for Ubuntu 16.04 LTS

  https://launchpad.net/~hvr/+archive/ubuntu/ghc

over at

  https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl

I don't have experience myself with Ubuntu on WSL, but it should be
simply a matter of using

  sudo add-apt-repository ppa:hvr/ghc-wsl
  sudo apt-get update

and then

  sudo apt-get install ghc-8.2.2-prof cabal-install-head


Then simply add `/opt/ghc/bin` to your `$PATH` (see instructions at
https://launchpad.net/~hvr/+archive/ubuntu/ghc )

There are also builds of GHC 8.0.2 and GHC 8.4.1-alpha (may still be
building as of writing) in this new ghc-for-wsl PPA.

I'd appreciate if somebody could test whether these GHC binaries work
as intended on the non-insider Windows 10 builds and let me know.

Cheers,
  Herbert


On Tue, Feb 13, 2018 at 12:21 PM, Yitzchak Gale  wrote:
> I wrote:
>>> I have made available a build of GHC 8.2.2 with the config option:
>>> --disable-large-address-space
>>> [2] https://github.com/Microsoft/WSL/issues/1671
>
> Shao Cheng wrote:
>> Thank you! A simpler fix for WSL ghc users is upgrading to fast ring of
>> insider builds, the mmap overhead is much lower and ghc startup lag is
>> barely noticable.
>
> Thanks, that's good news. I can't use an insider build - I need to be on
> standard Windows in order to support our customers. The latest reports
> in the GitHub issue seemed to indicate that the slowness is still quite
> significant even on insider builds. I'm glad to hear you say that this is no
> longer true. I am looking forward to regular GHC binary tarballs working
> normally on regular WSL sometime in the near future.
>
> Yitz
> ___
> 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

Re: Can't push to haddock

[Herbert Valerio Riedel]

Hi,

On 2017-12-19 at 08:31:06 +0100, Sven Panne wrote:

> This is a tradeoff: Doing it that way, you catch incorrect commits a
> little bit later, but it makes the overall arcane repository magic
> quite a bit simpler, probably removing the need for mirroring.

We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover; the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. As a Haskell programmer, I rather err on the side of
correctness for mission critical things, and shifting checks we can (and
already) do statically to CI feels to me like embracing
`-fdefer-type-errors`... :-)

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

Re: The build is broken (Solaris/x86, FreeBSD/{i386,amd64})

[Herbert Valerio Riedel]

On 2014-04-15 at 06:52:42 +0200, Jan Stolarek wrote:
>> I think Simon Marlow is even more conservative, and
>> does his validate builds in a separate tree so he catches missing
>> files.

> I thought everyone is doing that.

Btw, using such a workflow[1] is actually almost a necessity if you want to
continue working on GHC while a longish validate is running in the
background... otherwise you're blocked till validate completes.


Cheers,
  hvr

 [1]: like e.g. 
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Workflowwithvalidate
  (fwiw, I meant to write up a variant not relying on sync-all)

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

Re: Observation on Hadrian's relative performance re current buildsystem

[Herbert Valerio Riedel]

Hi Malcolm,

On 2017-11-18 at 11:09:28 +, Malcolm Wallace wrote:

[...]

> But surely the timing for a full build from scratch is not the most
> important thing to compare?  In my work environment, full builds are
> extremely rare; the common case is an incremental build after pulling
> changes from upstream.  Is this something you can measure?

If Hadrian is more exact about the dependency tracking, I'd expect
something close to a full rebuild when I `git pull` from GHC HEAD, since
the Git commit and the snapshot versioning we infer from that,
pervasively transcends most most artifacts of GHC, and in general you
should boot & configure everytime you `git pull` unless you're sure it
won't matter.

You'd have to suppress/mask this logic if you want to avoid full
rebuilds.

Also I'm not sure how Hadrian tracks itself as a dependency (NB: The GNU
Make system doesn't); When I used Shake myself, I remember that
meta-depending on the rules per se wasn't a trivial thing to do; and the
simplest way was to introduce very coarse (either manual or by hashing)
global versioning over all rules, which would invalidate the full
build. But it's been some time since I did that, so I may be wrong here.

However, what I think would be a more relevant benchmark matching the
usual GHC developer workflow, would be to see how well Hadrian manages
to minimize the work needed to rebuild GHC after editing a source file
in GHC's source-tree without changing the Git commit. As that's what
matters most to me when I'm actively working on a GHC patch.

I'll try to measure/compare this with the next GHC patch I hack on.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Observation on Hadrian's relative performance re current buildsystem

[Herbert Valerio Riedel]

Hello GHC devs,

I took the opportunity to give Hadrian a test-run to see whether it
could live up to the big promise of delivering a "more scalable, faster"
system than the current GNU Make based system. Unfortunately, my
preliminary results don't back this claim, and actually make Hadrian
appear to be significantly slower.



Here's the summary of the results:

 | Hadrian   | GNU Make  |
++---+---+
| Compiling `hadrian`| 5m25s | 0 |
| (one-time setup)   |   |   |
++---+---+
| build "all" at -j8 | 38m   | 33m   |
++---+---+
| no-op build at -j8 | 10.977s   | 3.258s|
++---+---+
| "clean"| 21s   | 51s   |
++---+---+


So, Hadrian is ~5 minutes than GNU Make (or even ~10 minutes if
you also count the one-time setup cost).

And what I personally consider a bit annoying is that it's ~3 times
slower detecting; i.e. you have to wait 11s for Hadrian to detect
there's nothing to be done which compared to GNU Make (which currently
needlessly re-runs Sphinx; so it could be even faster!) is very
noticeable to me.

There's a silver-lining though, deleting files is the part which is a
lot more costly in the GNU Make system currently since artifacts are
spread over several (scroll to the end of this email) subfolders
there. Whereas Hadrian did something we should have done for the GNU
Make system as well (and probably would have done sooner or later anyway
in order to support the srcdir!=buildir scheme that people are used to
from GNU Autotools projects); Hadrian places build-artifacts into a few
top-level folders, and so cleaning up is trivial and requires to unlink
only a few folders from the filesystem.



At the very least, I'd expect Hadrian to be as fast as the GNU Make
system (and ideally beat it, not the least as this was besides
maintainability its big promise), but so far it doesn't seem to deliver
that promise for me.

It could easily be that I'm comparing apples to oranges here or that
I've otherwise overlooked something, so let me describe how I came to
this conclusion:

I tried this on an reasonably idle Linux workstation with an Intel(R)
Core(TM) i7-3770 CPU @ 3.40GHz CPU, and with 32GiB RAM (i.e. the
filesystem content was well-cached into memory; NB: a ghc source tree +
compiled artifacts takes up about 4GiB on the filesystem).

I've started from a fresh Git clone, i.e.

  git clone --recursive git://git.haskell.org/ghc.git

followed by

  ./boot
  ./configure

At this point, we're at the common point from which both the Hadrian and
the GNU Make build-system would start diverging:

For the Hadrian build-system, we need to pay for a one-time setup, since
we need to build the `hadrian` executable (which requires to build the
in-tree lib:Cabal as an in-place library):


  $ time ./hadrian/build.sh --help
   
  ...
   
  real  5m25.992s
  user  6m19.196s
  sys   0m6.079s


I'm not too worried about this part, as there's a few tricks by which we
could likely bring that down to about 2 minutes or so, and we mostly pay
this setup-cost, when lib:Cabal and/or `hadrian` changes and requires to
be recompiled.


Now, after having made sure that the `hadrian` executable is fresh, I
started the actual build:

$ time ./hadrian/build.sh -j8
 
...
 
shakeArgsWith0.000s0%   
Function shake   0.178s0%   
Database read0.000s0%   
With database0.000s0%   
Running rules 2338.398s   99%  =
Pool finished (5261 threads, 8 max)  0.002s0%   
Lint checking0.111s0%   
Total 2338.690s  100%   
Build completed in 38:59m
 
real 38m59.626s
user 219m7.421s
sys  11m7.584s


then I immediately re-issued the same command to test how long it takes
to perform a no-op build:


$ time ./hadrian/build.sh -j8
 
Up to date
Up to date
shakeArgsWith0.000s0%   
Function shake   0.183s1%   
Database read0.144s1%   
With database0.241s2%   
Running rules9.379s   93%  =
Pool finished (4165 threads, 8 max)  0.004s0%   
Lint checking0.101s1%   

Re: Hadrian

[Herbert Valerio Riedel]

Hi Moritz (et al.),

On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote:

> a) why a git subtree if we keep working on github with hadrian, wouldn't that 
> imply using a submodule? We use submodules for 
>all the other ghc boot libs that are not part of the tree and are 
> developed on github as well, no? As far as I understand
>a subtree, it's essentially integrating everything into the main tree.  So 
> this looks more like the submodule to subtree
>conversion, when hadrian development is switched over to phabricator?

Fwiw, using a submodule makes sense imho if hadrian is supposed to
remain a submodule on the long-term; as transitioning from submodule <->
non-submodule is something Git doesn't handle to well automatically
(we've had fun with that when we restructured ghc.git into the current
structure...)

Also, a submodule has the benefit of ticket references clearly referring
to a different numbering namespace w/o having to rewrite all ticket &
commit-hash references (which is often overlooked; I for one tend to
refer quite often to other commit shas in my commits, and they also
result when you 'git cherry-pick -x')

So, what's the long-term plan for Hadrian repo-wise? Is it going to
remain externally maintained on GitHub, or will it be integrated into
GHC HQ's infrastucture which means using Phabricator (which may pose its
own challenge, as Phabricator, like Trac, uses globally unique ticket
numbers, rather than per-project numbering)?

If it is to be a submodule, we (and by that I mean myself; it doesn't
take long) also need to setup mirroring from snowleopard/hardian to
git://git.haskell.org, and from there to to github.com/ghc/hadrian for
technical reasons.

> b) should we really hardcode the full url to hadrian tickets? wouldn't 
> hadrian/#xxx suffice? Assuming for a moment hadrian
>would move into the github.com/haskell org or something, while the linkes 
> would likely (due to githubs url redirection)
>keep on working, until someone recreates a snowleopard/hardian
>repo, but not necessarily correct anymore.

Note that GitHub doesn't support the abbreviated hadrian#xxx syntax; you
*have* to prefix it by the organization/user, in order for GitHub to
recognize a ticket reference; i.e. you *have* to use one of


- https://github.com/snowleopard/hadrian/issues/123  (or possibly .../pull/123)

- snowleopard/hadrian#123

- #123

- GH-123

for GitHub to recognize the issue reference.

anything else won't be recognized.

Moreover, github.com/haskell/ is not a good place for Hadrian since it's
a too GHC-specific tooling; if anywhere, it would rather end up together
with the other GHC repos in the /ghc/ org at
https://github.com/ghc/hadrian (or something slightly different; we need
reconcile this with our GHC mirroring scheme; that's may be a bit
tricky).

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

ANN: Overlay Hackage Package Index for GHC HEAD

[Herbert Valerio Riedel]

Hi GHC devs,

A long-standing common problem when testing/dogfooding GHC HEAD is that
at some point during the development cycle more and more packages from
Hackage will run into build failures.

Obviously, constantly nagging upstream maintainers to release quickfixes
for unreleased GHC HEAD snapshots which will likely break again a few
weeks later (as things are generally in flux until freeze comes into
effect) does not scale and only introduces a latency/coordination
bottleneck, and on top of it ultimately results in spamming the primary
Hackage Package index with releases (which has non-negligible negative
impact/costs of its own on the Hackage infrastructure, and thus ought to
be minimised).

OTOH, we need the ability to easily test, debug, profile, and prototype
changes to GHC HEAD while things are still in motion, and case in point,
if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently
run into a dozen or so of packages not building with GHC HEAD.

To this end, I've finally found time to work on a side-project (related
to matrix.hackage.haskell.org) which implements a scheme tailored to
`cabal new-build`, which is inspired by how Eta copes with a very
related issue (they rely on it for stable versions of the compiler);
i.e., they maintain a set of patches at

  https://github.com/typelead/eta-hackage/tree/master/patches

which fix up existing Hackage packages to work with the Eta compiler.


And this gave me the idea to use a similar scheme for GHC HEAD:

  https://github.com/hvr/head.hackage/tree/master/patches

This folder already contains several of patches (which mostly originate
from Ryan, Ben and myself) to packages which I needed to patch in order
to build popular Hackage packages & tools.

The main difference is how those patches are applied; Eta uses a
modified `cabal` which they renamed to `etlas` which is checks
availability of .patch & .cabal files in the GitHub repo linked above;

Whereas for GHC HEAD with `cabal new-build` a different scheme makes
more sense: we simply generate an add-on Hackage repo, and use the
existing `cabal` facilities (e.g. multi-repo support or the nix-style
package store which makes sure that unofficially patched packages don't
contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage
repo containing fixed up packages.



I've tried to describe how to use the HEAD.hackage add-on repo in the
README at

  https://github.com/hvr/head.hackage#how-to-use


And finally, here's a practical example of how you can use it to build
e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to
build your project of choice; please refer to

  http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
  
to learn more about how to describe your project via  `cabal.project`
files):


0.) This assumes you have a recent cabal 2.1 snapshot built from Git 

1.) create & `cd` into a new work-folder

2.) invoke `head.hackage.sh update` to update the HEAD.hackage index cache

3.) invoke `head.hackage.sh init` to create an initial `cabal.project`
configuration which locally activates the HEAD.hackage overlay repo

4.) If needed, edit the cabal.project file and change where GHC
HEAD can be found (the script currently assumes GHC HEAD is
installed from my Ubuntu PPA), e.g.

  with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2

or you can add something like `optional-packages: deps/*/*.cabal`
to have cabal pick up package source-trees unpacked in the deps/
folder, or you can inject ghc-options, relax upper bounds via
`allow-newer: *:base` etc (please refer to the cabal user guide)

5.) Create a `dummy.cabal` file (in future we will have `cabal
new-install` or other facilities, but for now we use this
workaround):


--8<---cut here---start->8---
name:dummy
version: 0
build-type:  Simple
cabal-version:   >=2.0
 
library
  default-language:Haskell2010

  -- library components you want cabal to solve & build for
  -- and become accessible via .ghc.environment files and/or
  -- `cabal new-repl`
  build-depends: base, lens
  
  -- executable components you want cabal to build
  build-tool-depends: pandoc:pandoc
  
--8<---cut here---end--->8---

 6.) invoke `cabal new-build`

 7.) If everything works, you'll find the `pandoc:pandoc` executable
 somewhere in your ~/.cabal/store/ghc-8.3.*/ folder
 (you can use http://hackage.haskell.org/package/cabal-plan
  to conveniently list the location via `cabal-plan list-bins`)

 8.) As for libraries, you can either use `cabal new-repl`
 or you can leverage GHC's package environment files:

 `cabal new-build` will have generated a file like

   .ghc.environment.x86_64-linux-8.3.20170913

 which brings into scope all transitive dependencies of
 `build-depends: base, lens`

 Now all you need to do is 

Re: Semigroup repeat (base package)

[Herbert Valerio Riedel]

Hi,

On Sun, Sep 10, 2017 at 9:24 AM, Harendra Kumar
 wrote:
> I could not find a function that repeats a value using a semigroup append. I
> am looking for something like this:
>
> srepeat :: Semigroup a => a -> a
> srepeat x = xs where xs = x <> xs
>
> Is it already available somewhere? Does it make sense to add it to
> Data.Semigroup?

What you seem to be searching for looks more like what we know as
`cycle :: [a] -> [a]`, and in fact there is its generalisation at

http://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Semigroup.html#v:cycle1

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

Re: Convenient URL alias for Trac tickets

[Herbert Valerio Riedel]

Good idea!

...btw, note that a couple years ago, I set up the little known

http://ghc.haskell.org/ticket/1234

alias... :-)

On Fri, Sep 1, 2017 at 8:26 PM, Ben Gamari  wrote:
> Hello everyone,
>
> Earlier today a contributor requested that we have an easier-to-remember URL
> for Trac tickets. Consequently, I've configured ghc.haskell.org to redirect
> URLs of the form,
>
> http://ghc.haskell.org/t/$n
>
> to the appropriate Trac ticket. For instance,
> https://ghc.haskell.org/t/14171 will bring you to the ticket for #14171.
> Hopefully others also will find this helpful.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Alex install failure

[Herbert Valerio Riedel]

On Sat, Aug 19, 2017 at 12:43 AM, Simon Peyton Jones via ghc-devs
 wrote:
> | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by
> | any chance?
>
> Direct hit!  (for the shot in the dark).  Yes it's NFS mounted I think.  So 
> what?

Then you're another victim of

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

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

Re: GHC release timing and future build infrastructure

[Herbert Valerio Riedel]

Hi!

On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote:

[...]

> I nevertheless see `stack` as a huge boon for easing adoption of new
> compiler versions (and hence new language features/extensions).

Since I totally disagree about Stack being beneficial to the quick
adoption of new features, would you care to elaborate what makes you
think that Stack was a "huge boon" in this particular context?

Just to name one example where Stack has been lagging behind Cabal for
several months already: Support for Backpack or convenience libraries --
there's already a handful of packages on Hackage which Stack (and
consequently Stackage) cannot install due to this. Being slow to adopt
new features IMO makes totally sense for Stack, as it's target audience
is practicioners who value stability, "reproducibility" and "long term
support", so it's actually a good thing that Stack stays behind until we
iron out issues with new bleeding edge features and Stack(age) adopts
them only when they're officially released and deemed ready for Stack's
target audience.

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

Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))

[Herbert Valerio Riedel]

50632672ad7439cb84a5c56ff0e4781346b1 
(lib)
Installing   
ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 
(lib)
Finished 
ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 
(lib)
Configuring  
ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)
Building 
ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)
Installing   
ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)
Finished 
ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)

Configuring executable 'ghc-demo' for ghc-demo-0..
Preprocessing executable 'ghc-demo' for ghc-demo-0..
Building executable 'ghc-demo' for ghc-demo-0..
[1 of 1] Compiling Main ( Main.hs, 
/tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo-tmp/Main.o
 )
Linking 
/tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo
 ...
--8<---cut here---end--->8---


So, cabal was able to succesfully produce an executable which uses a
reinstalled lib:ghc w/ a different lib:binary version!


But now for the limitations: this currently works at best with a GHC
8.2.1 installation whose configuration matches the generated files I
manually included in the modified lib:ghc package in

  http://hackage.haskell.org/package/ghc-8.2.1/src/autogen/

which as you can see from the generated files (see e.g. Config.hs) was a
Linux/x86_64/libgmp/internal-libffi/... configuration.

...and this finally brings me to the purpose of why I wrote this email:
In order to make lib:ghc properly reinstallable we'd need to either

 a) have a way to regenerate the files autogen/* via a custom Setup.hs
(by the likes of genprimcode or similiar)

or the lazy option,

 b) simply have those files installed in a place we can easily locate
(again, from a custom Setup.hs)

Does this make any sense; which option do you prefer?

Also, I'd like to know if you can think of reasons why or situations
when the reinstalled lib:ghc wouldn't work; or other reasons why this is
a bad idea.


Cheers,
  hvr

On 2016-06-05 at 19:02:29 +0200, Herbert Valerio Riedel wrote:
>> As an ultimate goal for a project like this, it would be nice if you could
>> do something like upgrade your base package but continue to use the ghc
>> package without incompatible types.
>
> That's one way to approach this. However, I've been experimenting with a
> more flexible way: Thanks to cabal-1.24's new nix-based tech-preview
> which gets rid of that `--force-reinstall` abomination for good, the
> prospect of simply recompiling the `ghc` cabal package becomes more
> attractive.
>
> This would get rid of the primary reason which currently constraints us
> to using the package versions bundled in GHC (like e.g. for
> `bytestring`) as soon as `ghc` enters an install-plan.
>
> I'm still investigating this, but early experiments were promising, but
> I need to reorganise GHC's source-tree a little bit to know for sure if
> this is feasable. But if this as I hope is possible, this could open up
> a lot of new possibilities!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removing Hoopl dependency?

[Herbert Valerio Riedel]

Hi Simon,

On 2017-06-09 at 09:50:51 +0200, Simon Peyton Jones via ghc-devs wrote:

[...]

>> Stackage only allows one version of each package
>
> I didn’t know that, but I can see it makes sense.  That makes a strong
> case for re-doing it as a new package hoopl2

The limitations of Stackage's design shouldn't drive nor limit
library design. Cabal has been moving to finally allow us to have
multiple versions and even multiple configurations/instances of the same
version of a package registered in the package db at the same time, and
subjecting ourselves to Stackage's limitations after all the work done
(and more in that direction is being considered to push the boundaries
even further) to that effect *now* seems quite backward to me.

If we push the idea to its conclusion, that we shall rather publish a
new package rather than release a new major version of a package to
workaround Stackage, you'd see a proliferation of number-suffixed
packages on Hackage.  Moreover, packages which can easily support
multiple major versions of a package would have to use conditional logic
boilerplate in their .cabal files (which again would be incompatible
with Stackage's inherent limitations, as it allows only *one
configuration* of a given package version).

We should build upon the facilities we already have in place; and major
versions are here to encode the epoch/generation of an API; moreover, as
a big advantage over classic SemVer, we also have this 2-component major
version which gives us more flexibility for versioning during developing
two or more epochs of an API in parallel. So hoopl-1.* and hoopl-2.*
could keep evolving independently, each branch being able to perform
major version increments in their respective version namespace.

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

Re: 8.2 and earlier build times

[Herbert Valerio Riedel]

On Wed, May 17, 2017 at 10:56 AM, Simon Peyton Jones via ghc-devs
 wrote:
> That's great news!  Faster than GHC 7.8!   We should advertise this :-).

However, not everything is back to 7.8 levels  when looking at the
time-dimension, e.g. for regex-tdfa-1.2.2  (with reasonably similar
versions of dependencies):

GHC 7.8.4:

<>

GHC 7.10.3:

<>

GHC 8.0.2:

<>

GHC 8.2.1:

<>


So GHC 8.2.1 seems to have traded memory-in-use (significantly less
than 7.8) for compile-time (significantly more than 7.8).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.2.1-rc1 source tarball availability

[Herbert Valerio Riedel]

$ tar xOf ghc-8.2.0.20170404-src.tar.xz  ghc-8.2.0.20170404/GIT_COMMIT_ID ;
echo
d67f0471cd3584c5a548ff30c9023b599b598d3e


On Tue, Apr 4, 2017 at 9:01 AM Alan & Kim Zimmerman 
wrote:

> There is no tag in the source tree, which commit has been used?
>
> Alan
>
> On 4 April 2017 at 06:21, Ben Gamari  wrote:
>
>
> tl;dr: If you would like to produce a binary distribution for GHC
>8.2.1-rc1 then let me know, grab the source distribution and
>start building. The binary distributions will be announced one
>week from today.
>
> Hello GHC packagers,
>
> I am happy to announce the release of the 8.2.1-rc1 source distribution
> to binary packagers. You will find the usual source artifacts at
>
> http://downloads.haskell.org/~ghc/8.2.1-rc1/
>
> As usual, the sooner we can get the binary distributions together the
> better, but I will hold off on announcing the distributions until next
> Sunday to ensure we're all on the same page. It would be appreciated if
> you could reply to this message confirming that you intend to offer a
> binary distribution this release.
>
> Otherwise, let me know if you have any trouble building your
> distribution. I have yet to push the ghc-8.2.1-rc1 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone swimmingly save a few known issues (namely #13426,
> #13233, and #13509).
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Herbert Valerio Riedel]

Hi,

On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote:
> On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
>
>> It makes additions of names to libraries far less brittle. You can
>> add a
>> new export with a mere minor version bump, and many of the situations
>> where
>> that causes breakage can be fixed by this simple rule change.
>
> It would be true only if we also allow imports to shadow each other.
> Otherwise there will be a big chance for name clash yet.
>
> Can we generalize the proposal such that subsequent imports shadow
> preceding ones?

IMO, that would be lead to fragile situations with hard to detect/debug
problems unless you take warnings serious.

With the original proposal, the semantics of your code doesn't change if
a library starts exposing a name it didn't before. There is a clear
priority of what shadows what.

However, when we allow the ordering of import statements to affect
shadowing, it gets more brittle and surprising imho:

For one, we have tooling which happily reorders/reformats import
statements which would need to be made aware that the reordering
symmetry has been broken.

Moreover, now we get into the situation that if in

  import Foo -- exports performCreditCardTransaction
  import Bar

  main = do
 -- ..
 performCreditCardTransaction ccNumber
 --

'Bar' suddenly starts exporting performCreditCardTransaction as well
(and doing something sinister with the ccNumber before handing it over
to the real performCreditCardTransaction...), it can effectively change
the semantics of a program and this would merely emit a warning which
imho rather deserves to be a hard error.

However, iirc there is a different idea to address this without breaking
reordering-symmetry, e.g. by allowing explicitly enumerated names as in

  import Foo (performCreditCardTransaction)
  import Bar

to shadow imports from other modules which didn't explicitly name the
same import; effectively introducing a higher-priority scope for names
imported explicitly.

> In that case you may e.g. list local modules after libraries' modules,
> and be sure new identifies in libraries will not clash with local
> ones. Obviously shadowing should be a warning still.

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

Allow top-level shadowing for imported names?

[Herbert Valerio Riedel]

Hi *,

I seem to recall this was already suggested in the past, but I can't
seem to find it in the archives. For simplicity I'll restate the idea:


foo :: Int -> Int -> (Int,Int)
foo x y = (bar x, bar y)
  where
bar x = x+x

results merely in a name-shadowing warning (for -Wall):

foo.hs:4:9: warning: [-Wname-shadowing]
This binding for ‘x’ shadows the existing binding
  bound at foo.hs:2:5


However,

import Data.Monoid
 
(<>) :: String -> String -> String
(<>) = (++)
 
main :: IO ()
main = putStrLn ("Hi" <> "There")

doesn't allow to shadow (<>), but rather complains about ambiguity:

bar.hs:7:23: error:
Ambiguous occurrence ‘<>’
It could refer to either ‘Data.Monoid.<>’,
 imported from ‘Data.Monoid’ at bar.hs:1:1-18
  or ‘Main.<>’, defined at bar.hs:4:1


This is of course in line with the Haskell Report, which says in
https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005.3

| The entities exported by a module may be brought into scope in another
| module with an import declaration at the beginning of the module. The
| import declaration names the module to be imported and optionally
| specifies the entities to be imported. A single module may be imported
| by more than one import declaration. Imported names serve as top level
| declarations: they scope over the entire body of the module but may be
| shadowed by *local non-top-level bindings.*


However, why don't we allow this to be relaxed via a new language
extensions, to allow top-level bindings to shadow imported names (and
of course emit a warning)?

Unless I'm missing something, this would help to keep existing and
working code compiling if new versions of libraries start exporting new
symbols (which happen to clash with local top-level defs), rather than
resulting in a fatal name-clash; and have no major downsides.

If this sounds like a good idea, I'll happily promote this into a proper
proposal over at https://github.com/ghc-proposals/ghc-proposals; I
mostly wanted to get early feedback here (and possibly find out if and
where this was proposed before), before investing more time turning
this into a fully fledged GHC proposal.

Cheers,
  HVR


pgpmTqGogQqM8.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How, precisely, can we improve?

[Herbert Valerio Riedel]

On 2016-09-28 at 03:51:22 +0200, Richard Eisenberg wrote:

[...]

> Despite agreeing that wikis are sometimes wonky, I thought of a solid
> reason against moving: we lose the Trac integration. A Trac wiki page
> can easily link to tickets and individual comments, and can use
> dynamic features such as lists of active tickets. These are useful and
> well-used features. I don't know what's best here, but thinking about
> the real loss associated with moving away from these features gives me
> pause.

I'd like to emphasize this point; Trac's main strength, design
philosophy, and selling point is its tight integration between SCM, Wiki
and Issue tracking and resulting synergies (same markup features,
extensions, syntax usable seamless), whereas the issue tracking part is
its strongest feature.

If you rip away its Wiki (and replace it by something
decoupled/non-integrated as e.g. GitHub's Git-backed Wiki[1]), you
weaken it to the point where it becomes quite harder to argue to keep
Trac at all. It's already sub-optimal we spread discussions/information
across Trac and Phabricator (you often have to read both, the Diff
discussions and the associated Trac ticket discussion to get the full
picture); I doubt a 3rd more or less isolated tool which weakens
cohesion would improve things.


 [1]: Personally, I consider GitHub's Wiki quite weak and inconvenient
  to use.  It's stylesheet is not as optimised as Trac's and
  structuring the content is also significantly worse than with
  Trac. And finally GH-flavoured Markdown is very limiting compared
  to Trac's rich extensible wiki syntax; Github's Wiki doesn't even
  recognize #123 or Git-shas like 993d20a2e9b8fb29a (and then
  provide mouse-over hoover texts with a title of the respective
  referenced commit or ticket); you have to paste full urls and
  manually include a title.

  So IMO Github's wiki is not suitable for GHC's use at all.

  A highly customized/forked Gitit instance, however, may be a more
  reasonable alternative, but then the question is who is gonna
  customize, implement and maintain it. Or we can drop the idea of a
  wiki altogether, and go for statically generated docs. Then we
  could just keep the wiki-content as restructedText (which btw is
  more expressive and extensible than .md) and have sphinx generated
  output. But then that's a totally different medium compared to a
  Wiki...

  However, I'm still missing a compelling reason in this discussion
  to justify the cost of changing the status-quo.

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

Re: Pusing to haddock

[Herbert Valerio Riedel]

On 2016-06-13 at 23:44:14 +0200, Ben Gamari wrote:
> Simon Peyton Jones  writes:
>> Devs,
>> I want to push to the haddock repo, to fix the build.  But I can’t.
>> .git/modules/utils/haddock/ contains
>>
>> [remote "origin"]
>>
>>url = git://git.haskell.org/haddock.git
>>
>> pushurl = ssh://g...@git.haskell.org/haddock.git

well, that's incorrect...

if you look in the 'packages' text-file at the top of GHC's source-tree,
you'll notice that haddock's upstream repo is declared as
ssh://g...@github.com/haskell/haddock.git

And you should have permission to push there.

git.haskell.org/haddock.git is a mirror of the GitHub repo

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

Re: Why upper bound version numbers?

[Herbert Valerio Riedel]

On 2016-06-09 at 19:43:42 +0200, David Fox wrote:
>> or even worse silent failures where the code behaves
>> subtly wrong or different than expected. Testsuites mitigate this to
>> some degree, but they too are an imperfect solution to this hard
>> problem.

> ​It seems to me that if you have any thought at all for your library's
> clients the chances of this happening are pretty insignificant.

This is a common argument, and requires for APIs to avoid changing the
semantics of existing operations in the API in a non-backward compatible
way. And instead of modifying existing APIs/operations if this can't be
done, introduce new operations ( foo, fooV2, fooV3, ...), effectively
versioning at the function-level.

If we did this consequently, we wouldn't need the PVP to provide us a
semantic contract, as upper bounds would only ever be needed/added if
somebody broke that eternal compatibility contract.

A variation would be to only allow to change the semantics of existing
symbols if the type-signature changes in a significant way, and thereby
indexing/versioning the semantics by type-signatures rather than a
numeric API version.

In both cases, we also could dispose of the PVP, as then we could use
the API signature as the contract predicting API compatibility
(c.f. Backpack)

In the former case, we could get away with lower bounds only, and since

  *the raison d'être of the PVP is predicting upper version bounds*,

again, there would be no reason to follow the PVP anymore.

The PVP is there so I have the means to communicate semantic changes to
my libraries' clients in the first place. So while I don't usually
deliberately break the API for fun, when I do, I perform using a major
version increment to communicate this to my clients.

In other words, I promise to do my best not to break my library's API
until the next major version bump, and to signal API additions via minor
version increments. That's the gist of the PVP contract. In addition to
version numbers for the cabal meta-data & solver, I typically also
provide a Changelog for humans to read, which (at the very least)
describes the reasons for minor & major version increments.

If clients of my library choose to deliberately ignore the contract I'm
promising to uphold to the best of my abilities (by e.g. leaving off
upper bounds), then it's flat-out the client library's author fault that
code breaks for disrespecting the PVP. Certainly not mine, as *I* did
follow the rules.



pgpu9IYGI13jz.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why upper bound version numbers?

[Herbert Valerio Riedel]

On 2016-06-07 at 02:58:34 +0200, Dominick Samperi wrote:
> I guess what you are saying is that this policy will prevent packages
> from installing with new versions of ghc until the maintainer has had
> a chance to test the package with the new version, and has updated the
> upper version limit. Thus, inserting those upper version limits is a
> kind of flag that indicates that the package has been "certified" for
> use with versions of base less than or equal to the upper limit.

That's one important aspect. I'm very distrustful of packages whose
maintainers declares that their packages have eternal future
compatibility (unless they have made this decision *very* carefully
based on which parts of the API they use).

In general, this runs into the fallacy that successful compilation would
be equivalent to (semantic) API compatibility, which is only half the
story. In some cases one may be lucky to get compile-time warnings
(which are often ignored anyway), or explicit run-time errors (which are
still undesirable), or even worse silent failures where the code behaves
subtly wrong or different than expected. Testsuites mitigate this to
some degree, but they too are an imperfect solution to this hard
problem.

So another aspect is that the PVP[1] provides an API contract which makes
upper bounds possible at all (for packages you don't control).

While the PVP doesn't give you a way to know for sure when compatibility
breaks, the policy gives you a least upper bound up to which your
package is guaranteed (under certain conditions) to remain
compatible. Without this contract, you'd have no choice but to
constraint your package to versions of dependencies (not under your
control) which you were able to empirically certify to be compatible
semantically, i.e. versions that were already published.

Unfortunately, GHC's `base` package has a *huge* API surface. So with
each GHC release we're usually forced to perform a major version bump to
satisfy the PVP, even if just a tiny part only very few packages use of
`base`'s API became backward in-compatible. This may be addressed by
reducing the API surface of `base` by moving infrequently used
GHC-internal-ish parts of the API out of base.

But there's also other changes which affect many more packages as
already mentioned. As already mentioned, the big AMP change was a major
breaking point.

Some packages like

  http://matrix.hackage.haskell.org/package/unordered-containers

tend to break every time a new GHC version comes out. Partly because they
happen to use the low-level parts of `base` API which tend to
change.

Ironically, in the case of `unordered-containers`, the maintainer decided
to start leaving off (or rather make ineffective) the upper bound on
`base` starting with 0.2.2.0, and this turned to be an error in
judgment, as each time a new GHC version came out, the very bound that
was left out would turned out to be necessary. So leaving off upper
bounds created actually more work and no benefit in the case of
`unordered-containers`.



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

Proposal: Left-Associative Semigroup Operator Alias in "Data.Semigroup"

[Herbert Valerio Riedel]

Hello!

In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>)
subtly conflicts with definitions of (<>) in pretty printing APIs, for
which the left-associative variant is sometimes desirable. This subtle
overloading of (<>) is error-prone, as one has to remember which version
of (<>) is currently in scope in order to be able to reason about
non-trivial expressions involving this operator.

This proposal is an attempt to resolve this unfortunate and confusing
situation by completing the `Semigroup`/`Monoid` vocabulary with a
standard left-associative alias. Please see

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp

for more details.

Discussion period: 4 weeks


pgp6aSxLC2VIF.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Stop rejecting Summary: Signed-off-by: ... OR patch Phabricator

[Herbert Valerio Riedel]

On 2016-05-13 at 00:40:03 +0200, Edward Z. Yang wrote:
> Currently the commit hooks reject commit messages that look like:
>
> Summary: Signed-off-by: Edward Z. Yang 
>
> Unfortunately, if I do a one line commit message with -s, Phabricator
> will automatically reformat my message to have this.

...and that's exactly why I invested time to write that hook in the
first place, because Phabricator blatantly violates Git convention
regarding the git commit message format. Stock Phabricator insists on
its own "structured" Git commit format, thereby breaking almost every
Git-tool which expects the usual git-trailer grammar.

I've been meaning to fix this (and another related issue of Phabricator
using whitespaces in trailer-keys[1] which unsurpisingly breaks git
tooling as well but for a different reason, as well as the annoying
issue of Signed-off-by lines sometimes confusing Phabricator...*sigh*)
in Phabricator for some time but never got to it, but...

> 2) You should patch Phabricator to stop munging the messages
> this way.  The message formatting is done server-side so as
> a client I have no way of changing it, you need to fix it.
> This URL has some guidance on how to do it:
> https://secure.phabricator.com/T6055
>
> I'd offer to edit the hook myself but there does not seem to be
> any canonical location where the hooks are versioned.

...I've tried to patch phabricator as suggested in T6055 (and commented
there), but it seems I need to tweak Phabricator's commit msg parser as
well...



 [1]: E.g. "Reviewed By:" instead of the better supported "Reviewed-by:",
  see e.g. https://git.wiki.kernel.org/index.php/CommitMessageConventions
  


pgpPHZRJLYSqF.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

[Herbert Valerio Riedel]

On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote:

[...]

> I've pushed the result to the ghc-8.0 branch and have pushed a set of
> new source tarballs to the usual URL. The new release commit is
>
> b594f8191273f4c913bc8413d30fd3061bb577c1

fyi, an easy way to verify you have the intended tarball is:

$ tar xOf ghc-8.0.1-src.tar.xz ghc-8.0.1/GIT_COMMIT_ID; echo
e99c1e2516aeb283172c7e6898508238e33cf065

(that's the old one)


PS: I've just been told the md5sum of the new tarball is
94da3386c0de519eeea37586edd90187


pgp0cXZLYZgay.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8 and Template Haskell

[Herbert Valerio Riedel]

On 2016-04-15 at 00:04:05 +0200, Iavor Diatchki wrote:
> Sure, I'd be happy to help whoever needs help---just let me know.

Great... :-)

> The change that one would have to do is:  whenever you'd used "InstaceD"
>  replace it with "InstanceD Nothing".

I've done a quick grep for InstanceD over the stackage-nightly-subset of 
Hackage:

 https://gist.githubusercontent.com/hvr/97a4f0f0f594faa9c17857b52add9a2e

so those are most likely the packages (within the stackage-subset) that
will lose their GHC 8.0-readyness (if they had it to begin with...).

As a popular package example, `lens-4.13.{1,2,2.1}` has been GHC
8.0-ready for 3 releases already; so this would require retroactively
blocking those 3 releases by tightening the template-haskell upper-bound
via cabal-edits, and making a new release of `lens` as soon as GHC 8.0
final (or RC4) gets released...

On the bright side, the amount of packages affected seems manageable...

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

Re: GHC 8 and Template Haskell

[Herbert Valerio Riedel]

On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote:

[...]

> If we were to delay things, we would ship a version of the library that has
> missing functionality *and* we'll break everyone's code on the next
> release.

>   If we make the change now, then at least when people fix their TH
> code to work with GHC 8, they'd be getting access to more
> functionality.
>
> This change does indeed change the data structure for declarations, so if
> you were working with it directly, indeed you'll have to make changes.

This so late in the process involves retroactively tighten upper bounds
on template-haskell for existing releases on Hackage which already
extended support to template-haskell-2.11.

Sadly, I have lost track of how many packages were already updated
several weeks ago since the first RC came out to work with
template-haskell-2.11 so I don't have any numbers to offer nor a
concrete list of which packages are likely candidates to become
penalized for having been early adopters of GHC 8.0.

So this will cause a regression on Hackage which will be actionable only
after GHC 8.0 final gets out (unless we happen to have a RC4), as
otherwise we'd break parts of Hackage for GHC 8.0 RC3 users
(this includes Travis jobs already including GHC 8.0 in their configs)

However, I do sympathize with the desire to get this in while it's still
relatively cheap, rather than have to wait a year until it's time for
template-haskell-2.12 ...

Would you be willing to help out with making sure popular packages
depending on template-haskell[1] are brought up speed as soon as your
proposed change lands to reduce the pain/cost of such a last-minute
change?


 [1]: http://packdeps.haskellers.com/reverse/template-haskell


> However, if you use the "smart" constructors in TH, you shouldn't need to
> change anything.
> In particular, I left `instanceD` as before---it does not add any
> overlapping pragmas, and I added a new function `instanceWithOverlapD`,
> which has an extra parameter that allows you to specify pragmas.
>
> I'd like to get this in, if possible, as I have a library that needs this
> feature.  My current work-around it quite ugly:  ask the clients of the
> library to enable "Language OverlappingInstaces", which is cumbersome,
> *and* generates deprecation warnings.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

[Herbert Valerio Riedel]

On 2016-02-18 at 13:32:59 +0100, Andrey Mokhov wrote:

[...]

> Interesting! In the new Shake-based build system we also need to
> automagically generate .hs files using Alex et al. My first
> implementation was slow but then I realised that it is possible to
> scan the source tree only once and remember where all .hs/.x/etc files
> are. This brought down the complexity from quadratic to linear in my
> case -- maybe this could be reused in cabal too?

This sounds very risky; are you suggesting to blindly traverse the
hs-src-dirs *before* you even know what is searched for?

If so, this will cause problems; we're already seeing problems with this
in the cabal nix-local-branch, which currently (it's a bug) recursively
traverses the project folder for computing a source-hash over content
that would not even make it into the source-dist...

There must be a better way to solve this...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

[Herbert Valerio Riedel]

On 2016-02-16 at 08:00:49 +0100, Sven Panne wrote:
>> I have renamed it to -Wmissing-pat-syn-signatures.
>>
>
> Hmmm, things are still wildly inconsistent:
>
>* "pat" is spelled "pattern" in other flags.
>
>* We still have both "sigs" and "signatures" as parts of the names.

I simple head-count in GHC HEAD:

-ddump-strsigs
-Wmissing-local-sigs
-Wmissing-exported-sigs

vs

-dsuppress-type-signatures
-Wmissing-signatures
-Wpartial-type-signatures


at this point I'd be fine with either

 -Wmissing-pattern-synonyms-signatures

or even

 -Wmissing-pattern-synonyms-sigs

as neither 'pattern' nor 'synonym` have any abbreviation precedent in
`ghc --show-options`, but `sig(nature)s` has a precedent, so
using `-sigs` wouldn't introduce anything new.


>* Why is "synonyms" too long, but OTOH we have monsters like
> "-Wnoncanonical-monadfail-instances"?

Well... the  -Wnoncanonical-*-instances flag family was the best I could
come up with which is reasonably self-descriptive... do you have any
better suggestions?

>* We have both "binds" and "bindings" as parts of the names.

Fwiw, `ghc --show-options | grep binding` come ups empty
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

[Herbert Valerio Riedel]

On 2016-02-15 at 21:05:29 +0100, Sven Panne wrote:

[...]

>* Given the myriad of warning-related options, It is *extremely* hard to
> figure out which one caused the actual warning in question. The solution to
> this is very easy and done this way in clang/gcc (don't remember which one,
> I'm switching quite often): Just suffix all warnings consistently with the
> option causing it, e.g.
>
> Top-level binding with no type signature: [ -Wmissing-pat-syn-sigs]:
> 

Fyi, https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings

and specifically https://ghc.haskell.org/trac/ghc/ticket/10752

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

Re: New type of ($) operator in GHC 8.0 is problematic

[Herbert Valerio Riedel]

On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote:

[...]

>> - It is possible to have unlifted types about even without
>> -XMagicHash. -XMagicHash is simply a lexer extension, nothing more.
>> By convention, we use the # suffix with unlifted things, but there's
>> no requirement here. Having -XMagicHash thus imply a flag about the
>> type system is bizarre.
>
> OK, I always forget about that. But is not it a bug already? Usually we
> don't allow code that uses GHC-specific extensions to compile without a
> language pragma. Why we don't have such pragma for levity
> polymorphism?

There are extensions which are only needed at the definition
site. Take {-# LANGUAGE PolyKinds #-} for instance; this is enabled
inside the Data.Proxy module, which defines the following type

  {-# LANGUAGE PolyKinds #-}
  module Data.Proxy where

  data Proxy t = Proxy

Now when you query via GHCi 7.10, you get the following output

  > import Data.Proxy
  > :i Proxy 
  type role Proxy phantom
  data Proxy (t :: k) = Proxy
-- Defined in ‘Data.Proxy’
  instance forall (k :: BOX) (s :: k). Bounded (Proxy s) -- Defined in 
‘Data.Proxy’
  instance forall (k :: BOX) (s :: k). Enum (Proxy s) -- Defined in ‘Data.Proxy’
  instance forall (k :: BOX) (s :: k). Eq (Proxy s) -- Defined in ‘Data.Proxy’
  instance Monad Proxy -- Defined in ‘Data.Proxy’
  instance Functor Proxy -- Defined in ‘Data.Proxy’
  instance forall (k :: BOX) (s :: k). Ord (Proxy s) -- Defined in ‘Data.Proxy’
  instance forall (k :: BOX) (s :: k). Read (Proxy s) -- Defined in ‘Data.Proxy’
  instance forall (k :: BOX) (s :: k). Show (Proxy s) -- Defined in ‘Data.Proxy’
  instance Applicative Proxy -- Defined in ‘Data.Proxy’
  instance Foldable Proxy -- Defined in ‘Data.Foldable’
  instance Traversable Proxy -- Defined in ‘Data.Traversable’
  instance forall (k :: BOX) (s :: k). Monoid (Proxy s) -- Defined in 
‘Data.Proxy’

even though you never enabled any extensions beyond what Haskell2010 provides.

Do you consider this a bug as well?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Reconsidering -Wall and -Wcompat

[Herbert Valerio Riedel]

On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote:

[...]

> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat
> never causes a build to fail even when users set -Wall -Werror.

Tbh, I don't like the "magic" part at all. In fact, I currently rely on
`-Wcompat -Werror` triggering an error in my builds.

To address the concern more generally is what

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

aims to, but without any magic. Then you'd say

  -Wall -Werror -Wno-error=compat

if -Wcompat implied by -Wall. But we ran out of time for GHC 8.0, so
#11219 will have to wait till GHC 8.2.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Reconsidering -Wall and -Wcompat

[Herbert Valerio Riedel]

On 2016-02-14 at 19:51:19 +0100, Sven Panne wrote:

[...]

> As stated on the Wiki, stuff in -Wcompat will often be non-actionable,
> so the only option I see if -Wcompat is included in -Wall will be
> -Wno-compat for all my projects.

This depends on what we mean by "actionable". I'm not sure I'd consider
the current -Wcompat warnings to be "non-actionable".

For instance, `aeson-0.11` happens to be free of

  -Wall -Wcompat -Wnoncanonical-monad-instances 
-Wnoncanonical-monadfail-instances

warnings, which didn't require any CPP, see e.g.

 - https://github.com/bos/aeson/pull/337/files
 - https://github.com/bos/aeson/pull/338/files


Also, as an example for a larger code-base, {Cabal,cabal-install} HEAD
in Git aspire to be warning-free as well[1]; so depending on your definition,
-Wcompat *is* actionable.

> -Wcompat would be restricted to a few manual local builds to see where
> things are heading.



 [1]: See  .e.g. 
https://github.com/haskell/cabal/blob/master/Cabal/Cabal.cabal#L191-L193

 if impl(ghc >= 8.0)
ghc-options: -Wcompat -Wnoncanonical-monad-instances
 -Wnoncanonical-monadfail-instances

  and the Travis job enables -Werror
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Reconsidering -Wall and -Wcompat

[Herbert Valerio Riedel]

On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote:
> On Feb 14, 2016, at 1:51 PM, Sven Panne  wrote:
>> 
>> IMHO, the distinction between "during development" and "outside of it" is 
>> purely hypothetical. 
>
> I find this comment quite interesting, as I see quite a large
> difference between these.* For example, I use -Werror during
> development, but not outside it. For me, "during development" is when
> the author can see the output from the compiler. "Outside of it" is
> when the author is not looking at the output.
>
> When I'm developing, I want to see lots and lots of warnings.
>
> When I'm building something I downloaded from Hackage, I generally don't care.
>
> So I wonder if there's a way for the tooling to distinguish between
> development builds and non-dev builds.

You may be interested in the upcoming `cabal.project`-file feature which
besides allowing to specify which .cabal files your multi-package
project is made up of (and tells cabal where your project-root is),
allows to set additional `ghc-options`, specify whether tests/benchmarks
are to be enabled, or request specific cabal flag settings (basically
most things you can set via the CLI as well), or even which GHC compiler
executable to use (rather than picking up whatever's in PATH). This can
be specified for all packages in the project or on per-package
granularity.

`cabal.project` files have only an effect when you're triggering cabal
invocations from within a source-tree, i.e. when you're in the "during
development" mode.  So that would be a good place to specify your
development-mode GHC warning-flag configuration and other
development-centric configurations.

> I know cabal better than stack, so I'll use that as my example. When I
> say `cabal configure --enable-tests; cabal build`, it means I want
> more information about how well this package works. Perhaps with
> --enable-tests, -Wall -Wcompat -Werror should be enabled by
> default. If I just say `cabal install`, I probably don't care so much
> about how well the package is working and can leave off the extra
> diagnostics.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Shaking up GHC

[Herbert Valerio Riedel]

On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote:
>> Are there any plans as to how to include it in the GHC tree? Does it
>> ship with all the libraries required to build the build system, will we
>> have a mini-build system to bootstrap it? If I recall correctly, we rely
>> on Cabal sandboxes on Linux/OSX and global Cabal library
>> installations on Windows in order to run it.
>
> The simplest way is to add the 'shake-build' folder to the GHC tree and
> ask first adopters of the new build system to globally install the
> dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh'
> and 'build.bat' scripts should work.
>
> I am open to suggestions on how to make this more convenient and
> robust. I've never used anything more advanced than a global cabal
> installation, so I'd appreciate input from more experienced users.

I think it's already quite convenient. After all, you're expected to
have a minimum GHC bootstrapping environment anyway. So having the tools
installed (as already do now, e.g. you need alex, happy, and ghc to be
able to work on GHC).

And the new cabal nix-store feature to show-case as tech-preview
together with GHC 8.0 makes this even more robust by avoiding pkg-db
breakages due to reinstalls, which would be the main reason not to
rely on "global installed dependency".

The shake-build.sh script simply needs to invoke `cabal new-build` to
generate the ghc shake build-tool executable.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Shaking up GHC

[Herbert Valerio Riedel]

On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote:

[...]

> My suggestion, and what I'd expect, is to make Shake part of GHC's
> included lib, just like process or xhtml.

please don't;  the only reason we include process and xhtml because we
*have* to. The less we *have* to bundle, the better.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

[Herbert Valerio Riedel]

On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote:
> I didn't mean to suggest that DPH should be part of every build, just
> that it should be part of *some* regular build.
>
> If we're willing to do that, then I'm certainly willing to get DPH
> back up and running.

What's the situation with the `vector`/`primitive` packages if DPH is to
be resuscitated? Does the official `vector` package need to be made
DPH-aware?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: CallStack naming

[Herbert Valerio Riedel]

On 2016-01-20 at 06:39:32 +0100, Richard Eisenberg wrote:
> I'm sure there's an easy answer to this, but I'm wondering: why is the
> CallStack feature implemented with implicit parameters instead of just
> a magical constraint? Whenever I use this feature, I don't want to
> have to enable -XImplicitParams and then make sure I get the name
> right. What would be wrong with, e.g.,
>
>> undefined :: AppendsCallStack => a
>
> Seems simpler. Is it problems with a nullary class?

Btw, would that, as a side-effect, make the currently shown
type-signature in GHCi a bit nicer than the current

,
| GHCi, version 8.1.20160117: http://www.haskell.org/ghc/  :? for help
| Loaded GHCi configuration from /home/hvr/.ghci
|
| λ:1> :info error
| error :: forall (v :: GHC.Types.Levity) (a :: TYPE v). 
?callStack::GHC.Stack.Types.CallStack => [Char] -> a   -- Defined in ‘GHC.Err’
|
| λ:2> :info undefined 
| undefined :: forall (v :: GHC.Types.Levity) (a :: TYPE v). 
?callStack::GHC.Stack.Types.CallStack => a -- Defined in ‘GHC.Err’
`

...?

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

GHC 8.0 Migration Guide & Ubuntu GHC8/cabal packages (was: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1)

[Herbert Valerio Riedel]

On 2016-01-13 at 16:43:35 +0100, Ben Gamari wrote:
> The GHC Team is very pleased to announce the first release candidate of
> the Glasgow Haskell Compiler 8.0.1 release. Source and binary
> distributions as well as the newly revised users guide can be found at
>
> http://downloads.haskell.org/~ghc/8.0.1-rc1/
>
> This is the first in a series of release candidates which will allow us
> to get wider testing of the significant changes that have occurred since
> the 7.10 series. [...]

As this wasn't explicitly mentioned in the announce, I'd like to point
your attention to

 https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0

which would benefit greatly from early adopters. More importantly, this
helps us all to reduce the boring & redundant investigative work of
rediscovering the same migration techniques by multiple parties over and
over again... :-)



I'd also like to remind you that (more or less) daily snapshots of GHC 8.0.1 for
Ubuntu {Precise,Trusty,Vivid,Wily} are already available via

  https://github.com/hvr/multi-ghc-travis

This also includes a "cabal-install-1.24" package (which currently
contains the current latest devel snapshots of cabal-install soon to
become version 1.24)

This specifically allows you to integrate GHC 8.0.1 & cabal-install 1.24
into your test-matrices in the `travis.yml` files, and thereby help
detect GHC 8.0 & Cabal 1.2[34] issues early on. The new packages have
been whitelisted for containerised Travis jobs already.

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

Re: ExprWithTySigOut

[Herbert Valerio Riedel]

Hi,

Btw, I also used that annoying pattern in

  https://phabricator.haskell.org/D1185

to represent type-signature sections before/after typechecking:
  
​  -- | Type-signature operator sections
​
​  | TySigSection(LHsType id)
​   (PostRn id [Name])  -- wildcards
​
​  | TySigSectionOut (LHsType Name)
​   (PostTc id Type)
​   (PostTc id Coercion)

I'd be interested in better ideas as well...

On 2015-12-21 at 09:46:58 +0100, Simon Peyton Jones wrote:
> Yes this is annoying.
>
> The thing is that with the first constructor only we'd get
>   (LHsSigWcType Id)
> after type checking, but we don't have such a thing. `HsTypes` are 
> typechecked to `Types`.  
>
> Perhaps we could have
>   (LHsSigWcType (StopAtRenamer d))
>
> where
>   type family StopAtRenamer a where
>   StopAtRenamer Id = Name
>   StopAtRenamer x = x
>
> If this pattern happened a lot it might be worth it.  But I think this is the 
> only occurrence.
>
> Better ideas welcome.
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan
> |  & Kim Zimmerman
> |  Sent: 19 December 2015 13:15
> |  To: ghc-devs@haskell.org
> |  Subject: ExprWithTySigOut
> |  
> |  At the moment HsExpr includes the following two constructors
> |  
> || ExprWithTySig
> |  (LHsExpr id)
> |  (LHsSigWcType id)
> |  
> || ExprWithTySigOut  -- Post typechecking
> |  (LHsExpr id)
> |  (LHsSigWcType Name)  -- Retain the signature,
> |   -- as HsSigType Name, for
> |   -- round-tripping purposes
> |  
> |  I do not understand why we need the second one, which hard-codes Name
> |  instead of id.
> |  
> |  There are a couple of places where there is an XXXOut variant with
> |  hard coded Name parameter, and these complicate creating any kind of
> |  custom class intended to work on a parameterised AST as it ripples out
> |  and forces Name instances of it everywhere.
> |  
> |  Perhaps we should introduce HsExprLR id id to cope with renaming?
> |  
> |  Alan
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c70b008fd4c5b43b
> |  3915e08d308766f7d%7c72f988bf86f141af91ab2d7cd011db47%7c1=MB%2fBX
> |  bBIUeYFlOOH5PGXV27wJpZRNKcHJV%2fTQmfI%2f%2bE%3d
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
"Elegance is not optional" -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock repo

[Herbert Valerio Riedel]

In the GHC tree:

$ grep haddock packages 
utils/haddock-   -   
ssh://g...@github.com/haskell/haddock.git

says that the upstream repo for Haddock is ssh://...

(there are some comments in the 'packages' file that explain what the
last column means)

so you have to do something like

  git push ssh://g...@github.com/haskell/haddock.git 
HEAD:wip/spj-wildcard-refactor

(the 'HEAD:' part may be optional, it just says, push what is the
current HEAD of your local repo to the remote branch wip/...)

HTH

On 2015-10-26 at 13:57:55 +0100, Simon Peyton Jones wrote:
> I can't update the haddock repository!   (I want to add a new branch for my 
> in-flight work.)
> Can anyone help?
> Thanks
> Simon
>
>
> git push --set-upstream origin wip/spj-wildcard-refactor
>
> remote: W refs/heads/wip/spj-wildcard-refactor haddock simonpj DENIED by 
> refs/.*
>
> remote: error: hook declined to update refs/heads/wip/spj-wildcard-refactor
>
> To ssh://g...@git.haskell.org/haddock.git
>
> ! [remote rejected] wip/spj-wildcard-refactor -> wip/spj-wildcard-refactor 
> (hook declined)
>
> error: failed to push some refs to 'ssh://g...@git.haskell.org/haddock.git'
>
> haddock $
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
"Elegance is not optional" -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Status of deprecation/warning features (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Herbert Valerio Riedel]

On 2015-09-28 at 04:56:13 +0200, David Feuer wrote:

[...]

> That's an excellent idea, and I think it makes sense to offer it at the
> module level as well as the class level. Just change DEPRECATED to REMOVED
> when it's actually removed. Speaking of such, has the deprecated export
> proposal made any headway?


As far as the in-flight library proposals are concerned, I plan to
rather have hardwired specific warnings implemented in the style of the
AMP warnings as it's crucial to have them available for the GHC 8.0
release to have the foundations for the migration plans in place. We can
generalize those feature later-on (maybe even in time for GHC 8.0 if
we're lucky).



As for the more general facilities the short answer is:

  They're stalled! Volunteers wanted!


There's the specification over at

 - https://ghc.haskell.org/trac/ghc/wiki/Design/MethodDeprecations

and there are 3 somewhat connected/related warning-feature tickets which
ought to be co-designed to avoid obstructing each other (if there's any
risk there).

 - https://ghc.haskell.org/trac/ghc/ticket/10071
 - https://ghc.haskell.org/trac/ghc/ticket/2119
 - https://ghc.haskell.org/trac/ghc/ticket/4879

For #10071 there's a very modest start at implementing this, which
just modifies the parser but doesn't go much farther (see wip/T10071 branch)

There's an old patch for #4879 which still works over at

 - https://phabricator.haskell.org/D638


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

Re: MIN_VERSION macros

[Herbert Valerio Riedel]

On 2015-09-25 at 20:48:52 +0200, Richard Eisenberg wrote:
> I've run into this issue, too. Post a feature request! I can't imagine
> it's too hard to implement.

For the current external CPP we'll probably have to create a temporary
file with the definitions (just like cabal does) to -include (as afaik
you can't easily pass function macros via `-D` to cpp).

However, Anthony has mentioned he's working on an embeddable CPP impl over at

 
https://www.reddit.com/r/haskell/comments/3m1wcs/call_for_nominations_haskell_prime_language/cvbp5ym

which would allow to keep the currently in-scope  MIN_VERSION_...()
definitions in-memory w/o a temporary file.


Finally, Cabal would have to be adapted to wrap the definitions with
`#ifndef`s (or omit those altogether when calling a recent enough GHC)


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

ANN: CfN for new Haskell Prime language committee

[Herbert Valerio Riedel]

Dear Haskell Community,

In short, it's time to assemble a new Haskell Prime language
committee. Please refer to the CfN at

  https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

for more details.

Cheers,
  hvr

-- 
PGP fingerprint: 427C B69A AC9D 00F2 A43C  AF1C BA3C BA3F FE22 B574


pgpoAsV3mjZtO.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: download all of Hackage?

[Herbert Valerio Riedel]

On 2015-09-14 at 16:43:44 +0200, Richard Eisenberg wrote:
> Is there an easy way to download (but not compile) all of Hackage? I
> know of the hackager package, but that's about compiling. I just want
> a whole big load of Haskell code to play with. I thought I could find
> a link on Hackage to do this, but failed.

It's quite easy, you can iterate through the list of package names and
call 'cabal get' like e.g. (untested, but I've done this already -- you
may need to protect against execution errors)

  for PKG in $(cabal list --simple | awk '{ print $1 }' | uniq); do cabal get 
$PKG;done

another variant is to construct the URLs based on the output;

you can also get a list of packages in JSON format via

 http://hackage.haskell.org/packages/.json

there's many ways to accomplish what you want...

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

Arcanist "lite" Haskell reimplementation (was: Proposal: accept pull requests on GitHub)

[Herbert Valerio Riedel]

On 2015-09-03 at 11:53:40 +0200, Thomas Miedema wrote:

[...]

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

[...]

I went ahead wasting some time and hacked up `arc-lite` for fun:

  https://github.com/haskell-infra/arc-lite

It's currently at 407 Haskell SLOCs according to sloccount(1), and
emulates the `arc` CLI as a drop-in replacement. As a proof-of-concept
I've implemented the 3 simple operations

 - `arc install-certificate`
 - `arc list`
 - `arc call-conduit`

If we wasted even more time, this could result in

 - Simplify installation of Arcanist for GHC contributors via Hacked
   (i.e. just `cabal install arc-lite`)
 - Implement a simple `arc diff`-like operation for submitting patches
   to Phabricator
 - Implement convenience operations tailored to GHC development
 - Teach arc-lite to behave more Git-idomatic
 - Make `arc-lite` automatically manage multi-commit code-reviews by
   splitting them up and submit them as multiple inter-dependendant 
code-revisions
 - ...

Any comments?

Cheers,
  hvr

--8<---cut here---start->8---
arc-list - Arcanist "lite" (CLI tool for Phabricator)

Usage: arc-lite [--verbose] [--conduit-token TOKEN] [--conduit-uri URI] COMMAND

Available options:
  -h,--helpShow this help text
  --verboseWhether to be verbose
  --conduit-token TOKENIgnore configured credentials and use an explicit API
   token instead
  --conduit-uri URIIgnore configured Conduit URI and use an explicit one
   instead

Available commands:
  list List your open Differential revisions
  call-conduit Perform raw Conduit method call
  install-certificate  Installs Conduit credentials into your ~/.arcrc for
   the given install of Phabricator
--8<---cut here---end--->8---
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Shared data type for extension flags

[Herbert Valerio Riedel]

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

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

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

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

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

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

Re: more releases

[Herbert Valerio Riedel]

On 2015-09-02 at 12:43:57 +0200, Ben Gamari wrote:

[...]

> The question is whether users want more rapid releases. Those working on
> GHC will use their own builds. Most users want something reasonably
> stable (in both the interface sense and the reliability sense) and
> therefore I suspect would stick with the releases. This leaves a
> relatively small number of potential users; namely those who want to
> play around with unreleased features yet aren't willing to do their own
> builds.

Btw, for those who are willing to use Ubuntu there's already GHC HEAD
builds available in my PPA, and I can easily keep creating GHC 7.10.3
snapshots in the same style like I usually do shortly before a stable
point-release.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Planning for the 7.12 release

[Herbert Valerio Riedel]

On 2015-09-01 at 13:57:17 +0200, Harry . wrote:
> Proposal: Make Semigroup as a superclass of Monoid
> https://mail.haskell.org/pipermail/libraries/2015-April/025590.html

The plan is to (at the very least) move Data.Semigroups and
Data.List.NonEmpty to base for GHC 7.12

If we have enough time we will also implement compile-warnings in GHC
7.12 to prepare for the next phases, if not they'll follow with the next
major release after GHC 7.12 (effectively extending/delaying the
migration-plan[1] by one year)


 [1]: https://mail.haskell.org/pipermail/libraries/2015-March/025413.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Please help beta test no-reinstall Cabal (was: Cabal and simultaneous installations of the same package)

[Herbert Valerio Riedel]

Good news, everyone!

...you may be interested to know this has finally come to fruition (just
in time for HIW):

  http://blog.ezyang.com/2015/08/help-us-beta-test-no-reinstall-cabal/

Cheers,
  hvr

On 2015-03-23 at 09:45:48 +0100, 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?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Planning for the 7.12 release

[Herbert Valerio Riedel]

For the record,

I wanted to implement this feature a couple of months ago but then got
side-tracked. If somebody wants to pick it up (which would be great),
please lemme know.

In the meantime I've created

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

and write up the little information I have on this topic already


On 2015-08-28 at 09:20:54 +0200, Simon Peyton Jones wrote:
 Lennart always says he’s going to work on it, but he’s a busy man and nothing 
 has actually happened.

 It’s a pretty easy feature to implement I think.

 Simon

 From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Sean Leather
 Sent: 28 August 2015 06:40
 To: Ben Gamari
 Cc: GHC developers
 Subject: Re: Planning for the 7.12 release

 On Thu, Aug 27, 2015 at 5:38 PM, Ben Gamari wrote:
 These items are a bit less certain but may make it in if the authors
 push forward quickly enough,


 * Support for Type Signature Sections, allowing you to write (:: ty)
   as a shorthand for (\x - x :: ty).

 Once Lennart convinced me of the usefulness of this [1], I've been finding 
 plenty of places where I wish I had it. Who's working on it? What's the 
 status? Is there a ticket for it?

 Regards,
 Sean

 [1] http://augustss.blogspot.com/2014/04/a-small-haskell-extension.html
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Elegance is not optional -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Planning for the 7.12 release

[Herbert Valerio Riedel]

On 2015-08-28 at 12:31:13 +0200, Kosyrev Serge wrote:

[...]

 * A (possible) overhaul of GHC's build system to use Shake instead
   of Make.

 Is there a breakdown of what remains to be done on this front?

Btw, here's the GitHub repo were you can track the progress:

https://github.com/snowleopard/shaking-up-ghc
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Planning for the 7.12 release: MonadFail

[Herbert Valerio Riedel]

On 2015-08-27 at 18:38:46 +0200, Simon Peyton Jones wrote:
 Great.  Is there a ticket?  If not, we'll probably lose track of it.

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

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

Querying the git commit id of GHC snapshots (was: ANNOUNCE: GHC 7.10.2 Release Candidate 1)

[Herbert Valerio Riedel]

On 2015-07-03 at 05:26:44 +0200, Greg Weber wrote:
 Is the 7.10.2 hvr ppa using this RC?

...it's easy to check, as since 7.10 we embed the Git commit id into the
source-tarball as well as into the generated ghc binary:

  $ /opt/ghc/7.10.2/bin/ghc --info | grep Git
   ,(Project Git commit id,5560861e4562a2e270e6610e6ef3cf120253bb16)

or more useful for scripting, i.e. in buildbots (but harder to remember):

  $ /opt/ghc/7.10.2/bin/ghc --print-project-git-commit-id
  5560861e4562a2e270e6610e6ef3cf120253bb16

and if you compare that with the git repo that id *currently* matches
the commit pointed to by the lightweight 'ghc-7.10.2-rc2' tag:

  http://git.haskell.org/ghc.git/shortlog/refs/tags/ghc-7.10.2-rc2


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

Re: Abstract FilePath Proposal

[Herbert Valerio Riedel]

On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote:

[...]

 I am *entirely* behind this in priciple and if it doesn't break too much
 of Hackage, also in practice, but...

 ... how much of Hackage *does* this break?

This won't be for free: I expect most packages which currently do more
than just opaquely pass around FilePaths to require fixes.

Some examples:

 - `writeFile doo/foo.bar ...`
   `_ - readFile (doo / foo . bar)`

   This will break unless -XOverloadedStrings happens to be enabled

 - Unless we generalise (++) to (), all cases where `FilePath`s are
   concatenated via (++) will break.

 - Code that uses Data.List rather than the `filepath` package for
   FilePath manipulation will need fixups (simplest fix: explicitly
   convert to/from String for the manipulation)

 - Some code, like e.g.

 fnames - System.Environment.getArgs
 forM fnames $ \fn - print = readFile fn

   will inevitably need to insert explicit conversions to/from FilePaths

I tried to simulate the effect on Hackage, but this turned out to be
more time-demanding than I hoped for and I had to abort. But the above
is what I encountered in my attempt.

 The reason that I'm in favor in principle is that paths really *are*
 opaque things -- platforms have entirely different conventions. AFAICT
 the only thing that they seem to agree on is that there is a hierarchy
 of some sort. (And not much else, including such things as case
 (in-)sensivity or character sets.).

 For example, in POSIX they're just strings of bytes without any
 specified encoding, and I'd love if they could be make to work like
 that when dealing with files in Haskell.

Yes, if you look e.g. at

  http://hackage.haskell.org/package/unix

you see a lot of API duplication, which wouldn't have been needed if
FilePath was an opaque type w/ lossless conversion to/from
ByteString.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Abstract FilePath Proposal

[Herbert Valerio Riedel]

On 2015-06-27 at 14:56:33 +0200, David Fox wrote:

[...]

 ​I've had success with a slightly different How:

What was your concrete use-case btw?

 Phase 1: Replace FilePath with a type class, with instances for the old
 FilePath (i.e. String) and the new implementation.

what would that comprise in the FilePath case?

I assume adding a transitional class whose methods are not exposed (and
whose typeclass name is exported from some GHC-specific internal-marked
module)? i.e.

  class IsFilePath a where
privateToFilePath :: a - FilePath
privateFromFilePath :: FilePath - a
   
  instance IsFilePath FilePath where
privateToFilePath   = id
privateFromFilePath = id
   
  instance IsFilePath [Char] where
privateToFilePath   = System.IO.toFilePath
privateFromFilePath = System.IO.fromFilePath

?

as well as changing a lot of type-sigs in base  filepath from
e.g.

  writeFile :: FilePath - String - IO ()
  openTempFile :: FilePath - String - IO (FilePath, Handle)

to

  writeFile:: IsFilePath a = a - String - IO ()
  openTempFile :: IsFilePath a = a - String - IO (a, Handle)


?

 Phase 2:  Wait until a suitable amount of hackage builds without the string
 instance.

I can see Stackage helping with that by using a custom GHC which lacks
the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2 could 
be
accomplished within one year for the Stackage-subset of Hackage.

 Phase 3: Deprecate the String instance - move it to an old-filepath package.

 Phase 4: Replace the type class with the new implementation

I assume this means getting rid again of the typeclass, and changing the
type-sigs back to i.e.

  writeFile :: FilePath - String - IO ()
  openTempFile :: FilePath - String - IO (FilePath, Handle)
​
(but now with with the new opaque `FilePath`)?

 This way the new implementation is available immediately, packages can
 begin converting at once, benefits can be assessed.

This scheme seems feasible at first glance, as long as the typeclass
doesn't start spreading across packages and find its way into type-sigs
(in which case it'd become more disruptive to get rid of it
again). Otoh, I'm not sure (assuming I understood how your scheme works)
it can be avoided to have the typeclass spread, since if not every API
that now has `FilePath` arguments in their type-sigs gets generalised to
have `IsFilePath a = a` arguments instead, we can't reach the goal of
Phase 2.

But I suspect that I didn't fully understand how your proposed
transition scheme works exactly... so please correct me where I got it
wrong!


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

Abstract FilePath Proposal

[Herbert Valerio Riedel]

-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

Native -XCPP Conclusion (was: RFC: Native -XCPP Proposal)

[Herbert Valerio Riedel]

Hello *,

Following up on the Native -XCPP Proposal discussion, it appears that
cpphs' current LGPL+SLE licensing doesn't pose an *objective*
showstopper problem but is rather more of an inconvenience as it causes
argumentation/discussion overhead (which then /may/ actually result in
Haskell being turned down eventually over alternatives that do without
LGPL components).

In order to acknowledge this discomfort, for GHC 7.12 we propose to follow
plan 4 according to [1] (i.e. calling out to a cpphs-executable as a
separate process), thereby avoiding pulling any LGPL-subjected cpphs
code into produced executables when linking against the 'ghc' package.

Plan 2 (i.e. embedding/linking cpphs' code directly into ghc) would
reduce fork/exec overhead, which can be substantial on Windows [2],
but plan 4 is no worse than what we have now.

Last Call: Are there any objections with GHC adopting plan 4[1]?

 [1]: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

 [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869

Thanks,
  HVR

On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote:
 Hello *,

 As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
 currently relies on the system's C-compiler bundled `cpp` program to
 provide a traditional mode c-preprocessor.

 This has caused several problems in the past, since parsing Haskell code
 with a preprocessor mode designed for use with C's tokenizer has caused
 already quite some problems[1] in the past. I'd like to see GHC 7.12
 adopt an implemntation of `-XCPP` that does not rely on the shaky
 system-`cpp` foundation. To this end I've created a wiki page

   https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

 to describe the actual problems in more detail, and a couple of possible
 ways forward. Ideally, we'd simply integrate `cpphs` into GHC
 (i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
 discussed and debated since affects the overall-license of the GHC
 code-base, which may or may not be a problem to GHC's user-base (and
 that's what I hope this discussion will help to find out).

 So please go ahead and read the Wiki page... and then speak your mind!


 Thanks,
   HVR


 [1]: ...does anybody remember the issues Haskell packages ( GHC)
  encountered when Apple switched to the Clang tool-chain, thereby
  causing code using `-XCPP` to suddenly break due to subtly
  different `cpp`-semantics?

-- 
Elegance is not optional -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC build failure

[Herbert Valerio Riedel]

On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote:
 I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
 with BuildFlavour set to devel2. I got the following error message:

 ghc/InteractiveUI.hs:68:8: error:
 Could not find module ‘Control.DeepSeq’
 It is a member of the hidden package
 ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’.
 Use -v to see a list of the files searched for.

 Any ideas what to do?

...have you ./boot'ed and ./configure'd again (and to be on the safe
side, also 'make distclean')? This sounds as if your ghc/ghc-bin.cabal
wasn't regenerated from the .in file...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MonadFail proposal (MFP): Moving fail out of Monad

[Herbert Valerio Riedel]

On 2015-06-10 at 00:42:12 +0200, David Luposchainsky wrote:

[...]

 I think there are two important consequences of MonadFail. First of all, we 
 can
 all safely write failable patterns if we so desire. Second, the compiler can
 ensure other people's codebases do not lie to us (knowingly or unknowingly).

...as a data-point, when turning on MonadFail during testing, I've seen
at least one place in GHC's own code-base that directly calls 'fail' for
a Monad instance which did *not* have its 'fail' method
overridden. Moreover, I've seen at least one (other) case, where
failable pattern matches occurred (intentionally or not[1]), but the
respective Monad instance didn't have the 'fail' method overridden
either.

 [1]: Failable patterns can in theory snuck in non-intentionally,
  e.g. they can be introduced during refactoring if e.g. a
  single-constructor type gets added new constructors. If the
  context was previously constraint to a 'Monad', after the
  refactoring the typechecker would point out that now there's a
  failable pattern not accounted for.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MonadFail proposal (MFP): Moving fail out of Monad

[Herbert Valerio Riedel]

On 2015-06-09 at 22:43:30 +0200, David Luposchainsky wrote:

[...]

 https://github.com/quchen/articles/blob/master/monad_fail.md

 Here's a short abstract:

 - Move `fail` from `Monad` into a new class `MonadFail`.

[...]

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

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

Hi Yitzchak,

On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote:

[...]

 Bardur Arantsson wrote:
 I don't see any need for an option. Just bundle cpphs together with GHC
 and build/use it as an external program. AFAICT this has absolutely no
 licensing implications for GHC, derived from GHC or anything compiled
 with GHC.

 Agreed, that would work. But I thought that the idea was that we wanted
 it actually integrated into GHC.

That would be the preferred way from a technical standpoint, as it would
avoid fork/exec and make it easier to integrate the CPP-phase tighter
into the lexer/parser.

However, due to the, sadly, mostly non-technical issues brought up, it
seems to me that isolating cpphs into a separate process (w/ the option
to configure GHC to use some other cpp implementation at your own risk
if you need to avoid the cpphs implementation at all costs) would be the
compromise acceptable to everyone in the short run while addressing the
primary goal to decouple the default-configuration of GHC from the
fragile system-cpp semantics.

NB: Nothing's been decided yet by GHC HQ


PS: As an observation,

 http://packdeps.haskellers.com/reverse/cpphs

shows that cpphs is already used by popular packages like hlint and
haskell-src-exts (and thus an indirect build-dep of the
haskell-suite project). Therefore, if LGPL+SLE is unacceptable in
some work-environments, it may require some vigilance to keep track
where cpphs may sneak into as a build-dependency... I'm surprised
there's still such resistance given the ubiquity of Linux
distributions made up of numerous (L)GPLed components, IMHO it's
kinda like tilting at windmills...

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

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote:
 On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com
 wrote:

 Performance isn't (my) motivation for avoiding fork/exec (and the
 equivalent on Win32) but rather avoiding the added complexity of
 marshalling/IPC with fork/exec, as opposed to simply calling into a
 native Haskell function and crossing process boundaries and having to
 deal with the various things that can go wrong with the additional
 moving parts you encounter when controlling an external process. So this
 would IMO simplify code paths, and moreover I'd expect opportunities to
 actually make the Haskell cpphs API richer (in case it isn't already)
 and more tailored to GHC's lexer/parser pipeline and error-reporting.

 Don't you still have to support -pgmF?

I guess so, unfortunately... so we'd have to keep a legacy code-path for
external cpp processing around, at least in the short run...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote:

[...]

 That would be the preferred way from a technical standpoint, as it would
 avoid fork/exec and make it easier to integrate the CPP-phase tighter
 into the lexer/parser.

 fork/exec is almost certainly going to be negligable compared to the
 overall compile time anyway. It's not like GHC is fast enough for it to
 matter.

Performance isn't (my) motivation for avoiding fork/exec (and the
equivalent on Win32) but rather avoiding the added complexity of
marshalling/IPC with fork/exec, as opposed to simply calling into a
native Haskell function and crossing process boundaries and having to
deal with the various things that can go wrong with the additional
moving parts you encounter when controlling an external process. So this
would IMO simplify code paths, and moreover I'd expect opportunities to
actually make the Haskell cpphs API richer (in case it isn't already)
and more tailored to GHC's lexer/parser pipeline and error-reporting.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Trac slow again

[Herbert Valerio Riedel]

On 2015-05-20 at 12:48:50 +0200, Simon Peyton Jones wrote:
 Did you manage to fix your Trac re-initialiser?  Trac is soul-destroyingly 
 slow today

...the periodic apache2 reloader is still working... not sure why it's
still slow *today*... (otoh, for me it's currently not that slow)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

Hello,

On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote:
 If the intention is to use cpphs as a library, won't the license
 affect every program built with the GHC API? That seems to be a high
 price to pay.

Yes, every program linking the `ghc` package would be affected by
LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page:

| - As a practical consequence of the //LGPL with static-linking-exception//
|   (LGPL+SLE), **if no modifications are made to the `cpphs`-parts**
|   (i.e. the LGPL+SLE covered modules) of the GHC code-base,
|   **then there is no requirement to ship (or make available) any source code**
|   together with the binaries, even if other parts of the GHC code-base
|   were modified.

However, don't forget we already have this issue w/ integer-gmp, and
with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!)

In that context, the suggestion was made[1] to handle the cpphs-code
like the GMP code, i.e. allow a compile-time configuration in the GHC
build-system to build a cpphs-free (and/or GMP-free) GHC for those
parties that need to avoid any LGPL-ish code whatsoever in their
toolchain.

Would that address this concern?


 [1]: 
http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote:
 At the risk of antagonizing some (most? all?) of you, how about...

 -XCPP stands for the native CPP
 -XGNUCPP stands for GNU's GCC CPP
 -XClangCPP stands for Clang's CPP
 -XCPPHS stands for CPPHS

Assuming this was a serious suggestion, the benefit is that you could
clearly mark what CPP you want to develop against, but OTOH, we'd lose
backward compat w/ Haskell compilers only knowing about the old -XCPP
but not the other new variants of the language-pragma.

Moreover, there can now be packages that require clang-cpp, while others
require gcc-cpp, and I don't think it can be assumed that both are
available on every GHC installation. So it could cause packages to fail
compiling simply because the respective CPP-flavor is missing.  On the
bright side, this would maybe give us the opportunity to coin the new
term CPP Hell =)

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

Re: RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote:

[...]

 Regarding licensing issues: perhaps we should simply ask Malcolm
 Wallace if he would consider changing the license for the sake of GHC?
 Or perhaps he could grant a custom-tailored license to the GHC
 project? After all, the project page [1] says:  If that's a problem
 for you, contact me to make other arrangements.

Fyi, Neil talked to him[1]:

| I talked to Malcolm. His contention is that it doesn't actually change
| the license of the ghc package. As such, it's just a single extra
| license to add to a directory full of licenses, which is no big deal.


 [1]: 
http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RFC re #10196 GHC 7.10.2: Allow Unicode Lm category for 2nd+ character on in identifiers

[Herbert Valerio Riedel]

Hello *,

As you may be aware, GHC 7.10.1 updated its Unicode catalog to version
7.0, thereby causing some subscript symbols to change character
properties, thereby causing GHC 7.10.1 to reject some Unicode-subscript
characters that GHC 7.8.4 accepted.

See https://ghc.haskell.org/trac/ghc/ticket/10196 for specific examples.

In order to address this regression, one suggestion is to allow
characters in the 'Letter, Modifier' category[1] from the 2nd position
on in an identifier. This however may do more than just fix the
regression, as it looks from [1] that it would allow many more new
identifiers than were previously possible.

So, is allowing 'Lm'-chars the the 2nd+ characters in an identifier a
sensible change for addressing #10196 or not. If it's a bad idea, are
there other suggestions worth considering?

 [1]: http://www.fileformat.info/info/unicode/category/Lm/list.htm

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

RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.

This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!


Thanks,
  HVR


[1]: ...does anybody remember the issues Haskell packages ( GHC)
 encountered when Apple switched to the Clang tool-chain, thereby
 causing code using `-XCPP` to suddenly break due to subtly
 different `cpp`-semantics?

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

Re: RFC: Native -XCPP Proposal

[Herbert Valerio Riedel]

On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote:
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.

 Yes.  This is one of my favourite things in GHC-land -- that an
 existing, good-enough, standardised, and widely-deployed solution was
 chosen over a NiH reinvention of preprocessing.  This allows other
 Haskell compilers to support CPP on basically any system (since cpp is
 so standard) without much effort, or even if the compiler does not
 support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the
 source files themselves before feeding the source into the compiler.

 Because it is a real `cpp` being used, the developmer must take care
 to follow the CPP syntax in the file that will then be transformed
 into Haskell by `cpp` in the same way that C, C++, and other
 developers have to take extra care (especially around use of # and
 end-of-line \) when using `cpp`, but this is the normal state of
 affairs for a secondary preprocessor step.  As a benefit, the source
 code will be processable by standard `cpp` implementations available
 for virtually every platform.

 In short, the current solution provides a very robust and portable way
 to do pre-compile preprocessing, and I like it very much.

The problem I have with that line of argument is that we're using the
so-called 'traditional mode' of `cpp`[1] for which afaik there is no
written down common specification different implementations commit to
adhere to (well, that's because 'traditional mode' refers to some vague
implementation-specific pre-standard cpp semantics).

And how is the developer supposed to take care to follow the
(traditional mode) CPP syntax, if he can't test it easily with all
potentially used (traditional-mode) `cpp`s out there? This already has
led to problems with Clang's cpp vs GCC's cpp.

Moreover, I was under the impression that it's only a matter of time
till `traditional mode` support may be dropped from C compiler
toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor,
as that would conflict even more heavily w/ Haskell's grammar to the
point of being inpractical.

 [1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Help wanted: working on the GHC webpage

[Herbert Valerio Riedel]

Hi Sergey,

On 2015-04-03 at 15:16:24 +0200, Sergey Bushnyak wrote:

[...]

 3) Also, it might be easier to publish blog posts on this site, like
 weekly news, without linking to `track`. I can reuse some code we are
 using for building haskell.od.ua (OdHug, Odessa Haskell User Group)

Why would it be easier? What's difficult about publishing on
https://ghc.haskell.org/trac/ghc/blog?

Moreover, the GHC weekly news are intimately linked to Trac, as they
reference Trac-tickets and Git commits, which Trac is able to annotate
with meta-data (ticket-type, -status, and -title for Ticket references,
as well as part of the Git commit msg for Git-commit refs).

Finally, GHC blog-posts are listed as events on 
https://ghc.haskell.org/trac/ghc/timeline


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

Re: wither the Platform

[Herbert Valerio Riedel]

On 2015-03-25 at 15:24:30 +0100, Mark Lentczner wrote:

[...]

 Concrete proposal based on that and the other fine input in the responses:

 *Simultaneous Release:* Since it is organizationally impractical to have
 one release, let's have GHC and Platform release at the same moment. That
 is, GHC HQ would keep a release in RC until HP was ready. By the same
 token, HP team commits to tracking GHC from RC1, and aiming to hit ready
 for release within a week of GHC being ready. Both go release in the same
 announcement. *In fact, let's version HP with the same number as GHC!*

[...]

I'm a bit worried about the aspect of delaying the GHC release schedule
for the sole purpose to provide the HP with more visibility, while
penalising those users that have no interest to use the HP anyway. Otoh,
there's usually enough time between the last RC and the actual final
release, which should give the HP at least one week of time anyway w/o
any active delay on GHC's end.

Otoh, as soon as the new HP is released, it provides users with the
perception of a new stable HP release to jump on right-away. That,
however, may lead to a poor experience if the it's the first HP release
for a given major GHC version as Hackage usually hasn't fully caught up
by the time a GHC x.y.1 is unleashed. So if we had co-released a HP
featuring GHC 7.10.1 today, there would still be enough Hackage packages
not yet compatible with GHC 7.10.1 to recommend users *not* to install
the release right-away.

So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP
would be in the HP's best interest in terms of providing a reliable and
complete development environment (which IMO requires access to Hackage,
even more so if the HP is to be reduced to contain less packages)

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

Re: wither the Platform

[Herbert Valerio Riedel]

On 2015-03-25 at 06:52:22 +0100, Mark Lentczner wrote:
 On Tue, Mar 24, 2015 at 8:20 PM, Gershom B gersh...@gmail.com wrote:

 install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package
 with an API binding for some webservice which has not been updated in two
 years and requires an old version of time, and then maybe a GUI toolkit and
 of course lens.

 That sounds like a recipe for Cabal Hell, Platform or not!

Regardless of the hellish issue, Gershom's comment indirectly highlights
of one thing where I'm wondering if the HP's growth isn't bounded by
diversity:

There are some areas which I'd expected to some degree in a
batteries-included platform, where the Haskell ecosystem has diverged
into popular but distinct package-sub-ecosystems (which all have their
respective communities/followers), such as HTTP-serving
(Yesod/Snap/Happstack/...), or which lens-abstraction to use, or at the
more fundamental level, even the streaming abstraction
(pipes/conduit/io-streams/machines/...) doesn't seem to have a clearly
recommended and agreed upon representative.

Also, to this day we don't have any TLS library support in the platform,
which also is subject to debate of which crypto-library to use (and
there's also the question whether to use OpenSSL via FFI or a native TLS
reimpl). So the platform-included `HTTP` package is not even able to
access `https://` URLs which is quite sad, as this also holds back
`cabal-install`'s ability to access `https://`-only repositories.

So, where do you see the platform's growth for those packages/areas
where you'll probably not get a reasonable majority consensus for
picking a specific package?

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

Re: wither the Platform

[Herbert Valerio Riedel]

On 2015-03-25 at 10:52:20 +0100, Simon Peyton Jones wrote:

[...]

 • Some of the package versions included with the platform have known
   and severe bugs, and cannot be reliably upgraded.

[...]

 I guess the solution is to release a new version of HP.

IMHO, if HP releases are to happen more frequently, a simple way to
upgrade would be desirable rather than having to download a new
multi-MiB full installer image each time only because a single package
was updated (and the ability to have access to multiple HP releases
side-by-side -- in case that isn't supported already)

Or put differently, how shall HP users be informed they're not running
the latest HP version with all known critical bugs fixed?

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

Re: Shake fails test with GHC 7.10 RC3

[Herbert Valerio Riedel]

On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote:
 On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote:

 [...]

 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no
 one else hit this with RC2 might just be because its a very recent
 regression.

 We -- and by that I don't mean myself... :) -- could git-bisect between
 RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's
 scriptable) if your test-case (even if it's not minimal) reliably
 triggers the bug...

I scripted up a test and git-bisected between RC2 and RC3, and the
following commit is the one where `shake-test oracle test` starts
failing

  
http://git.haskell.org/ghc.git/commitdiff/6f46fe15af397d448438c6b93babcdd68dd78df8

...which sadly is a rather large patch :-/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Shake fails test with GHC 7.10 RC3

[Herbert Valerio Riedel]

On 2015-03-18 at 16:33:00 +0100, Neil Mitchell wrote:

[...]

 I was wondering if there have been any state hack related changes or
 other potentially dangerous optimisation changes since RC2? I'll
 continue to try reducing the bug, but it's somewhat difficult as the
 larger system is quite big, and the code is very sensitive.

Fwiw, here's the Git history-fragment between RC2 and RC3:

https://github.com/ghc/ghc/compare/174082ffeb69b2f9df19e7af7b63a331dd074145...feccb32bd54e0d01d4393c0eeaf7da890760664a

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

Re: How to better parallelize GHC build.

[Herbert Valerio Riedel]

On 2015-03-07 at 11:49:53 +0100, Karel Gardas wrote:

[...]

 Is there anything else which may be done to fix that issue? Is someone
 already working on some of those? (I mean those reasonable from the
 list)?

are you aware of

  https://ghc.haskell.org/trac/ghc/wiki/Building/Shake

and

  https://github.com/snowleopard/shaking-up-ghc
?

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

Re: Proposal: Turn on ScopedTypeVariables by default

[Herbert Valerio Riedel]

On 2015-02-23 at 18:45:20 +0100, David Feuer wrote:
 I know this will be controversial, because it can break (weird) code and
 because it's not Haskell 2010, but hey, you can't make brain salad without
 breaking a few heads. 

Are you suggesting enabling -XScopedTypeVariables for -XHaskell98 and
-XHaskell2010? or rather for the default when neither of those two modes
is explicitly requested?

Just be warned though: this is somewhat of a trick-question... :-)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Behavior change of Data.Char

[Herbert Valerio Riedel]

On 2015-02-19 at 06:19:18 +0100, Kazu Yamamoto (山本和彦) wrote:
 It seems to me that some characters of GHC 7.10.1RC2 behave
 differently from those of GHC 7.8.4:

   7.8.4   7.10.1RC2
 isLower (char 170)TrueFalse  

Fwiw, the motivation for that particular change may be (I'm just
guessing here) to have the following condition hold:

  \c - isLower c `implies` (not . isLower . toUpper) c

i.e. if something is 'lower-case', then applying 'toUpper' should result
in a character that is not 'lower-case' anymore. This didn't hold with
7.8.4's Unicode 6, but now holds with 7.10.1's Unicode 7 definitions.

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

Re: Building vector with GHC HEAD

[Herbert Valerio Riedel]

On 2015-02-17 at 14:19:43 +0100, Jan Stolarek wrote:
 Devs,

 I'm not sure if this is the best place to ask this question but I'm almost 
 certain someone here 
 will have the answer. I want to build upstream master branch of vector 
 library using GHC HEAD and 
 cabal 1.22. Alas my attempts have failed:

 $ git clone g...@github.com:haskell/vector.git
 $ cd vector
 $ cabal sandbox init
 $ cabal install -w /dane/projekty/ghc/build/inplace/bin/ghc-stage2

...you need (at least) the following still unmerged PR applied for
vector's 'master':

  https://github.com/haskell/vector/pull/58


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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

[Herbert Valerio Riedel]

On 2015-02-17 at 13:47:50 +0100, Takenobu Tani wrote:
 I modified System/Process/Internals.hs locally and build on MinGW 32bit.
 Then I was successful to build on 32bit Windows 7.

 Shall I write a bug report on trac or any? or ghc7.10.1.rc2 will not
 support 32 bit Windows?

Please file a pull-request at https://github.com/haskell/process

I'm somewhat surprised this wasn't noticed before(?)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trouble pushing changes?

[Herbert Valerio Riedel]

On 2015-02-10 at 02:20:39 +0100, Iavor Diatchki wrote:

[...]

 Any ideas what that's about?  Perhaps, it is simply that I don't have
 permission to push to `deep-seq`?

You have to push to GitHub's upstream of deepseq:

  $ awk '/^libraries\/deepseq/ { print $4 }' packages 
  ssh://g...@github.com/haskell/deepseq.git

you can do that ad-hoc by

  git push ssh://g...@github.com/haskell/deepseq.git HEAD:master

from inside libraries/deepseq

it's also mentioned as a comment in the ./packages (as well as on the
GHC Wiki, I think) file that some subrepos have to be pushed somewhere
else


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

Re: Merge FlexibleContexts with FlexibleInstances?

[Herbert Valerio Riedel]

On 2015-02-06 at 07:05:35 +0100, David Feuer wrote:
 In my limited experience thus far, it seems to me that a substantial
 majority of modules that start out needing one of these end up needing the
 other one too. They appear to be two sides of the same coin, each allowing
 for (slightly) more powerful termination checking. Should the two just be
 made synonyms, to cut down a tiny bit on the boilerplate LANGUAGE pragmas?

Otoh, FlexibleInstances is only needed if you define instances, while
FlexibleContexts can also be required with code not defining any
instances (and GHC 7.10 requires FlexibleContexts more often now for
inferred type-signatures which couldn't be written w/o FlexibleContexts)

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

Re: 7.10.1RC2 compile problem? ghc: internal error: PAP object entered!

[Herbert Valerio Riedel]

On 2015-01-31 at 14:34:35 +0100, George Colpitts wrote:
 Maybe this is something I shouldn't be doing, but I thought it was worth
 mentioning in case I have found a compiler bug.
 Should I file a bug for this?

 cabal install *--allow-newer=base*  accelerate
 ...
 [10 of 10] Compiling Data.Label.Base  ( src/Data/Label/Base.hs,
 dist/build/Data/Label/Base.o )
 ghc: internal error: PAP object entered!
 (GHC version 7.10.0.20150123 for x86_64_apple_darwin)
 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

I suspect this has to do with `--allow-newer=base` allowing
template-haskell-2.9.0.0 to be re-installed (which then becomes a
build-dependency of `fclabels`). GHC 7.10, however, comes with
template-haskell-2.10.0.0

e.g. try the following in an empty sandbox:

  cabal install fclabels  --allow-newer=base --constraint 'template-haskell == 
2.9.*'

(wheares a plain `cabal install fclabels` in a fresh sandbox should
succeed w/o panics with GHC 7.10)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Make one-shot a per-registration property

[Herbert Valerio Riedel]

On 2015-01-30 at 05:36:21 +0100, Austin Seipp wrote:
 You won't have permissions to push it to 7.10. I can try to get to it soon,
 but I make no guarantees until next week (out of town atm).

 CC Herbert, who can probably get to it more promptly than I can.

I'll look into it later today


...for the future:

Please set the respective Trac tickets to which a commit belongs into
the 'fixed in HEAD, please merge to STABLE'-ticket-state, as well as
setting the proper milestone-value. That makes sure we don't miss it
when preparing releases.

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

76-fold regression GHC 7.10-7.11 in T9961 byte-allocation

[Herbert Valerio Riedel]

Hello *,

I noticed something odd while validating the GHC 7.10 branch:

  bytes allocated value is too low:
  (If this is because you have improved GHC, please
  update the test so that GHC doesn't regress again)
  ExpectedT9961(normal) bytes allocated: 772510192 +/-5%
  Lower bound T9961(normal) bytes allocated: 733884682 
  Upper bound T9961(normal) bytes allocated: 811135702 
  Actual  T9961(normal) bytes allocated:   9766160 
  Deviation   T9961(normal) bytes allocated: -98.7 %
  *** unexpected stat test failure for T9961(normal)


...then I also ran ./validate against today's GHC HEAD, and re-ran the
T9961 test:

ExpectedT9961(normal) bytes allocated: 772510192 +/-5%
Lower bound T9961(normal) bytes allocated: 733884682 
Upper bound T9961(normal) bytes allocated: 811135702 
Actual  T9961(normal) bytes allocated: 748225848 
Deviation   T9961(normal) bytes allocated:  -3.1 %


I'm not sure if it's just the test-case being broken, or there's
something real regression between 7.10 and HEAD...

However, I don't have time to investigate this.

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