ANN: IOHK is looking for Functional Compiler Engineers

[Manuel M T Chakravarty]

The IOHK Plutus Team, which works on a Haskell-based platform for contracts on 
the Cardano blockchain, is looking for new team members:

  https://iohk.io/careers/#op-341518-functional-compiler-engineer

See also Phil Wadler’s blog post: 
http://wadler.blogspot.com/2019/08/iohk-is-hiring.html

A core component of the Plutus Platform is a GHC plugin that translates GHC 
Core to the on-chain Plutus Core language. A central part of the underlying 
transformation scheme is described in 

  
https://iohk.io/research/library/#unraveling-recursion-compiling-an-ir-with-recursion-to-system-f

Manuel

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

Re: GitHub Mirror is broken

[Manuel M T Chakravarty]

Thanks!
Manuel

> Am 31.03.2019 um 17:09 schrieb Ben Gamari :
> 
> Manuel M T Chakravarty  writes:
> 
>> I think, it also only mirrors master, but not other branches, which is 
>> unfortunate especially for release branches.
>> 
> Fixed on both counts. The GitHub mirror should be both up-to-date and
> include all branches.
> 
> 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: GitHub Mirror is broken

[Manuel M T Chakravarty]

I think, it also only mirrors master, but not other branches, which is 
unfortunate especially for release branches.

Manuel

> Am 31.03.2019 um 05:52 schrieb Phyx :
> 
> Hi Ben,
> 
> I think the mirror is stuck again. Hasn't updated in 8 days.
> 
> Cheers,
> Tamar
> 
> On Tue, Feb 19, 2019 at 6:30 AM Ben Gamari  > wrote:
> Artem Pelenitsyn mailto:a.pelenit...@gmail.com>> 
> writes:
> 
> > Hello devs,
> >
> > This is just to let you know that the latestes commit on GitHub ghc/ghc
> > repo dates back to 22th of January. Personally, I find GitHub mirror quite
> > useful for ocasional searches over the code base. Therefore, I'd
> > appreciated repairing the mirror.
> >
> Fixed. It seems like the mirroring service got stuck.
> 
> 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

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

ANN: Multiple positions for GHC developers

[Manuel M T Chakravarty]

Please excuse this non-technical message, but I assume this is interesting for 
the members of this list: 

  https://iohk.io/careers/#op-302245-ghc-web-backend-developer

(There are multiple positions, same spec.)

Cheers,
Manuel

___
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

[Manuel M T Chakravarty]

> Am 30.10.2018 um 10:07 schrieb Simon Marlow :
> 
> I'm entirely happy to move, provided (1) whatever we move to provides the 
> functionality we need, and (2) it's clearly what the community wants 
> (considering both current and future contributors). In the past when moving 
> to GitHub was brought up, there were a handful of core contributors who 
> argued strongly in favour of Phabricator, do we think that's changed? Do we 
> have any indication of whether the survey respondents who were 
> anti-Phabricator would be pro- or anti-GitLab?

FWIW, while I still think GitHub is preferable, GitLab would be an improvement 
over Phabricator IMHO.

Cheers,
Manuel

___
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

[Manuel M T Chakravarty]

Hi Ben,

Thanks a lot for the summary of the situation.

As you know, I do dislike Phabricator for the many reasons that you are 
listing, and it would be nice to finally move to a better system. In 
particular, it is worth emphasising the fact highlighted by the survey, namely 
that "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.”

One the one hand, we want broader participation in GHC development; on the 
other hand, we constantly ignore the single largest source of frustration for 
contributors. That just doesn’t make a lot of sense to me, even if it can be 
explained by the inertia of some existing developers.

Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires 
the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At 
least, that is my current understanding. Please correct me if I am wrong.)

Given that large organisations work with large code bases on GitHub, I am still 
puzzled why GHC somehow cannot do that. (I do understand that the dev process 
that has been established within GHC is naturally focused around Phabricator 
and its tools. However, that doesn’t mean it couldn’t be changed to work as 
well as before, but with another tool.)

In any case, I think, you didn’t mention one of the options we did discuss 
previously, namely to use GitHub together with a service that adds more 
sophisticated code review functionality, such as

  https://reviewable.io 

This would solve the CI issues without further ado.

Cheers,
Manuel

> Am 30.10.2018 um 05:54 schrieb Ben Gamari :
> 
> 
> 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.
> 
> 
> # The problem
> 
> There are a number of reasons why I am currently uncertain about
> Phabricator.
> 
> For one, at this point we have no options for support in the event that
> something goes wrong as the company responsible for Phabricator,
> Phacility, has closed their support channels to non-paying customers.
> 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. This makes me thing that there may indeed be potential
> contributoes that we are leaving on the table.
> 
> 
> # What to do
> 
> With Rackspace support ending at the end of year, now may be a good
> time to consider whether we really want to continue on this road.
> Phabricator is great at code review but I am less and less certain that
> it is worth the maintenance uncertainty and potential lost contributors
> that it costs.
> 
> Moreover, good alternatives seem closer at-hand than they were when we
> deployed Phabricator.
> 
> 
> ## Move to GitHub
> 
> When people complain about our infrastructure, they often use GitHub as
> the example of what they would like to see. However, realistically I
> have a hard time seeing GitHub as a viable option. Its feature set is simply
> insufficient enough to handle the needs of a larger project like GHC
> without significant external tooling (as seen in the case of Rust-lang).
> 
> The concrete reasons have 

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

[Manuel M T Chakravarty]

Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed 
at Tweag I/O in the context of the GHC DevOps group. Have a look at

  https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

  https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers,
Manuel

> Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :
> 
> Hi,
> 
> I'd like to test some GHC builds + some compile and runtime flag combinations
> against a large set of packages by building them and running test suites. For
> this I need
> 
> - A set of packages that are known to work with latest GHC
> - A way to build them and run their test suites (if I could specify compile 
> and
>  runtime flags that'd be even better)
> 
> I think stackage can serve as (1) but I don't know how to do (2). Can anyone
> point me to the right direction? I vaguely remember some nix-based solution 
> for
> this that was being discussed on the IRC channel, but can't recall any 
> details.
> 
> Thanks,
> 
> Ömer
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



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

Re: Loading GHC into GHCi (and ghcid)

[Manuel M T Chakravarty]

> Am 09.06.2018 um 02:30 schrieb Evan Laforge :
> Currently -fdefer-type-errors is broken:
> https://ghc.haskell.org/trac/ghc/ticket/14963  This is not related to
> loading .o files, but ghci in general.

Which is a good indication that out CI story is still crap.

Cheers,
Manuel



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

Re: HsVectInstIn is dead code?

[Manuel M T Chakravarty]

Hi Alan,

You can remove ’HsVectInstIn’ as well as ’HsVectInstOut’ for that matter.

Thanks,
Manuel

> 20.04.2018 23:21 Alan & Kim Zimmerman :
> 
> If I grep through the GHC source, or do a github search[1]
> 
> It seems that HsVectInst exists, and can be renamed, typechecked, zonked, 
> desugared.
> 
> But it does not get parse, and does not appear to be introduced in any other 
> way.
> 
> Am I missing something? Should it be deleted (as hinted at in one of the 
> comments?)
> 
> Alan
> 
> [1] https://github.com/ghc/ghc/search?utf8=%E2%9C%93=HsVectInstIn= 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



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

Re: Can't push to haddock

[Manuel M T Chakravarty]

I think, what Sven is getting at here —and I do have to say, I concur— is that 
there is a bit of NIH (Not Invented Here) syndrome in parts of the Haskell 
community. I think, part of it is just inertia and the desire to keep things 
the same, because that is easier and more familiar.

One aspect that complicates this discussion significantly is that GHC dev has 
developed certain work arounds and ways of doing things, where third party 
infrastructure seems lacking in features, because it doesn’t support all these 
quirks. However, it turns out that if we are only prepared to change our 
workflow and processes to align with modern software development practices, 
many of theses ”features” aren’t actually necessary. We have seen quite a bit 
of that in the CI discussion. 

I am not writing this to blame anything or anybody. I think, it is a normal 
part of a healthy process of change. However, it complicates the discussion as 
people get hung up on individual technicalities, such as this or that feature 
is missing, without considering the big picture.

Generally, I think, a worthwhile golden rule in ops is that custom 
infrastructure is bad. It creates extra work, technical debt, and failure 
points. So, IMHO the default ought to be to use 3rd part infrastructure (like 
GitHub) and only augment that where absolutely necessary. This will simply 
leave us with more time to write Haskell code in GHC instead of building, 
maintaining, and supporting GHC infrastructure. 

Cheers,
Manuel

> 19.12.2017 20:47 Simon Peyton Jones via ghc-devs :
> 
> It seems to me that there is some hostility towards GitHub in GHC HQ, but I 
> don't really understand why. GitHub serves other similar projects quite well, 
> e.g. Rust, and I can't see why we should be special.
> 
> Speaking for myself, I have no hostility towards GitHub, and there is no 
> GHC-HQ bias against it that I know of.  If it serves the purpose better, we 
> should use it.   Indeed that’s why I asked my original question.  I agree 
> with your point that data may actually be safer in GitHub than in our own 
> repo.   (And there is nothing to stop a belt-and-braces mirror backup system.)
>  
> The issue is: does GitHub serve the purpose better?   We have frequently 
> debated this multi-dimensional question.  And we should continue to do so: 
> the answers may change over time (GitHub’s facilities are not static; and its 
> increasing dominance is itself a cultural familiarity factor that simply was 
> not the case five years ago).
>  
> Simon
>  
> From: Sven Panne [mailto:svenpa...@gmail.com] 
> Sent: 19 December 2017 09:30
> To: Herbert Valerio Riedel 
> Cc: Simon Peyton Jones ; ghc-devs@haskell.org Devs 
> 
> Subject: Re: Can't push to haddock
>  
> 2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel  >:
> 
> 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.
> 
>  
> 
> I think this is a question of perspective: Having the master repository on 
> GitHub doesn't mean you are in immediate danger or lose your "family jewels". 
> IMHO it's quite the contrary: I'm e.g. sure that in case that something goes 
> wrong with GitHub, there is far more manpower behind it to fix that than for 
> any self-hosted repository. And you can of course have some mirror of your 
> GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco 
> area... ;-)
> 
>  
> 
> It seems to me that there is some hostility towards GitHub in GHC HQ, but I 
> don't really understand why. GitHub serves other similar projects quite well, 
> e.g. Rust, and I can't see why we should be special.
> 
>  
> 
> 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;
> 
>  
> 
> This is by no means different than saying: "I want to run 'validate' in the 
> commit hook, otherwise it's a big mess." We don't do this for obvious 
> reasons, and what is the "big mess" if there is some incorrect submodule 
> reference for a short time span? How is that different from somebody 
> introducing e.g. a subtle compiler bug in a commit?
> 
>  
> 
> 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. [...]
> 
>  
> 
> Because the whole repository structure is overly complicated and simply 
> hosting everything on GitHub would simplify things. Again: I'm well aware 
> that there are tradeoffs involved, but I would really appreciate 
> simplifications. I have the impression that the entry barrier to GHC 

Re: Can't push to haddock

[Manuel M T Chakravarty]

Thank you for that word of reason.

(In addition to your very well stated point, the whole point of Git is that it 
is a *distributed* RCS. I don’t think, anything less than a full scale 
planetary nuclear war could really wipe out the GHC source code at this point.)

Manuel

> 20.12.2017 05:02 Gershom B :
> 
>> You're also assuming github doesn't suddenly pull a SourceForge (or a
>> Gitorious for that matter). Business cares not what it steamrolls in the
>> name of profit.
>> 
>> I fail to understand why, with multiple examples of the folly of this
>> belief out there, people are still willing to bet on *this* company being
>> *different* from all others and absolutely safe to trust.
> 
> What the heck is everyone arguing over? The initial statement was that
> even if we moved everything to github "We'd need mirroring anyway".
> That's it! There's no either/or involved. Just a statement that when
> you have data in one location, no matter how trustworthy, you want a
> backup as well. And ideally you want the backup under your control.
> 
> We can debate moving anything anywhere all we want, but the idea that
> stuff should also be backed up, regardless, in a source not under
> third-party control, seems inoffensive and besides the point.
> 
> --Gershom
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: [GHC DevOps Group] Release policies

[Manuel M T Chakravarty]

Thanks for the terminology clarification, Gershom.

As a general note, adding features or completing hitherto incomplete features 
on the release branch is something that should be avoided as much as possible. 
For starters, it is generally more work than doing it before the release branch 
is cut as things need to be added to master and the release branch, which 
slowly diverge. Moreover, the main purpose of the release branch is to 
stabilise the code base and to do so in a timely manner. As an example, if 
there is a new type system extension, but the error message are still bad, it 
may be allowed on the release branch with the understanding that the error 
messages are going to be fixed during the first month or so of the release 
branch lifecycle (i.e., the bulk of the work is done and tested before the 
release branch is cut). 

This in particular implies that everything merged to the release branch has to 
have been well tested (the wiki page states, ”[o]nly previously agreed on, 
stable and tested new functionality is allowed in.”) Implicitly adding new 
functionality by depending on a moving library dependency, which is out of the 
quality control of the GHC team, is not something that I would call ”stable and 
tested functionality".

If we depend on the release version of a library on the release branch, we are 
still free to bump the library version if that is necessary to fix bugs (which 
may creep up due to GHC testing as you suggest) — I would expect that to be 
patch level bumps, though. If new library features are not sufficiently stable 
to move to that less tightly coupled process from T-3, then that feature set 
simply has to wait for the next GHC release (which by the new schedule will 
come much more quickly than before).

Let me reiterate that the tighter release process is aimed at being able to 
achieve more frequent and more predictable GHC releases. This again ought to 
help the library development, too. In other words, we slow down at the right 
place to move faster overall (an old Kung Fu trick ;)

Cheers,
Manuel

> 20.12.2017, 04:28 Gershom B :
> 
> Good questions. In my below proposal I think I made an error in naming
> things. I checked back at the wiki page for the new release calendar
> schedule: 
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedule
> 
> Based on that, what I was calling "freeze" is really just cutting the
> branch. But it isn't intended as a full freeze. That happens 3 months
> before release. The "feature freeze" in that calendar only comes with
> the first RC, 1 month before release.
> 
> I think that this timing still works with the proposal I have however
> -- bundled libs branch when GHC branches (T-3), and cut releases when
> GHC cuts the first RC (T-1). For bundled libs, I think we'd want to
> treat that branch (T-3) as closer to a feature freeze.
> 
> However, and here I disagree with Manuel, I think there's plenty of
> reason to _not_ cut release versions of libs at the time of the T-3
> branch. In particular, due to the coupling, this may cause trouble if
> there are cross-cutting changes that need to be implemented for the
> sake of GHC working properly over the three month duration of the
> alpha. If there's a feature in a library designed to work in
> conjunction with a change in GHC, and that change in GHC needs to be
> altered in the course of the alpha (which may not be uncommon -- bug
> testing can often reveal such things) then it is likely the library
> may need to be changed too. I don't see any concrete goal solved in
> making this process significantly more difficult. I thought Moritz'
> examples in this thread were very revealing with regards to such
> possibilities. It is not clear what cost function the stronger
> proposal is trying to optimize for.
> 
> If it is that we want a branch that is "always ready to be cut for
> release" (why? is such a thing even possible anytime in the
> foreseeable future?), one middle ground may be to cut _candidate_
> releases of bundled libs on branch (T-3).
> 
> --Gershom
> 
> 
> On Tue, Dec 19, 2017 at 10:12 AM, Michael Snoyman  wrote:
>> Thanks for spelling this out Gershom. Reading it through, here are my
>> questions:
>> 
>> 1. What's the definition of "feature freeze"? Does it mean API stability?
>> Does it mean not code changes at all except to fix a bug? Are performance
>> fixes allowed in that case?
>> 2. What's the minimum time between GHC cutting a feature-freeze branch and
>> the first release candidate? And the minimum time between first release
>> candidate and official release? Obviously, if each of these is 1 week (which
>> I can't imagine would be the case), then these libraries could cut a
>> feature-freeze branch after the official release, which obviously isn't
>> intended. I apologize if these timings are already well established, I'm not
>> familiar enough with GHC release cadence to know.
>> 
>> I can't 

Re: [GHC DevOps Group] Release policies

[Manuel M T Chakravarty]

I believe the standard policy would be to say that even master may only 
dependent on released versions of dependencies. That is after all the only way 
to have a master that is always ready to be cut for a release (as per modern CI 
practices).

Given the tight coupling of some of the dependencies of GHC with GHC, maybe we 
need to consider something weaker, but I think, the weakest reasonable (from a 
CI standpoint) policy is to say that, while master may depend on pre-release 
versions, release branches can *only* depend on released dependencies. In other 
words, a release branch can only be cut when master has progressed to a point 
where it only depends on released versions of its dependencies.

Under that compromise, cutting a GHC release branch may be delayed by a delayed 
upstream release, but hopefully the approx 3 month release process has enough 
slack to tolerate that. (It is obviously not ideal, though.)

Cheers,
Manuel

PS: Simon, I am sorry, but IMHO it is too early for a summary and policy 
proposal as the discussion hasn’t really converged yet. In any case, I am happy 
to write a summary Trac page once we are there. Is that ok?

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

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

Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)

[Manuel M T Chakravarty]

> Ben Gamari :
> 
> On November 11, 2017 10:03:37 PM EST, Joachim Breitner 
> > wrote:
>> Hi Alan,
>> 
>> the combined effect of 
>> 
>> commit e3ec2e7ae94524ebd111963faf34b84d942265b4
>> WIP on combined Step 1 and 3 for Trees That Grow, HsExpr
>> 
>> 
>> and 
>> 
>> commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905
>> WIP on Doing a combined Step 1 and 3 for Trees That Grow
>> 
>> 
>> causes a 15% regression in the time it takes to build GHC, according to
>> https://perf.haskell.org/ghc/#compare/fe6848f544c2a14086bcef388c46f4070c22d287/e3ec2e7ae94524ebd111963faf34b84d942265b4
>> 
>> 
>> Is that a known, expected and accepted regression?
>> 
>> Joachim
> 
> I noted this on D4177 and discussed the effect with Alan. Indeed there is 
> quite a sizeable regression in compilation time but thankfully this is not 
> because GHC itself is slower. Rather, it simply requires more work to 
> compile. I did a set of nofib runs with and without the first TTG patch and 
> found that compiler allocations remained essentially unchanged.
> 
> A 15% regression in the compilation time of GHC is indeed hard to stomach but 
> Alan had said that much of this will likely disappear in the future. If this 
> is the case then a temporary regression is in my opinion acceptable.

Hmm, on what grounds does he think that this is going to disappear and how 
likely is likely? This doesn’t sound convincing TBH.

Cheers,
Manuel

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

Re: perf.haskell.org functional again

[Manuel M T Chakravarty]

> Am 24.10.2017 um 14:46 schrieb Joachim Breitner <m...@joachim-breitner.de 
> <mailto:m...@joachim-breitner.de>>:
> 
> Is CircleCI the future now?

Yes, as per

  https://ghc.haskell.org/trac/ghc/wiki/ContinuousIntegration 
<https://ghc.haskell.org/trac/ghc/wiki/ContinuousIntegration>

> In general, yes. But it’s running fine for now, so I would not
> prematurely throw it over.
> 
> My requirements are: 
> 
> * needs to run on every commit (not just every push), including 
>   branches.
> * needs to be able to push to a repository¹, so it needs access to 
>   some secret token for depolyment.
>   Alternatively, the CI could simply keep track of the build log
>   and the perf.haskell.org <http://perf.haskell.org/> dashboard scrapes it 
> from there.
> * Occasionally, I find that I want to rebuild a fair number of commits
>   that are already in the repository. So a good way to trigger
>   rebuilds would be nice.

No need to mess with a working system, but as long as performance counters are 
the basis, I think, these constraints can all be met. In particular, CircleCI 
has facilities to allow deployments including managing of secrets. (That is a 
pretty common requirements for CIs.)

Cheers,
Manuel

> 
> Greetings,
> Joachim
> 
> ¹ https://github.com/nomeata/ghc-speed-logs/commits/master 
> <https://github.com/nomeata/ghc-speed-logs/commits/master>
> 
> Am Dienstag, den 24.10.2017, 12:18 +1100 schrieb Manuel M T
> Chakravarty:
>> Hi Joachim,
>> 
>> Great! Just because you mention CI infrastructure and our effort around GHC 
>> CI at the moment, do you think, it would make sense to move this to CircleCI 
>> eventually?
>> 
>> Cheers,
>> Manuel
>> 
>>> Am 24.10.2017 um 11:02 schrieb Joachim Breitner <m...@joachim-breitner.de 
>>> <mailto:m...@joachim-breitner.de>>:
>>> 
>>> Hi,
>>> 
>>> after a system upgrade to avoid weird linker errors, and after some fixes 
>>> in the nofib submodule, http://perf.haskell.org/ghc 
>>> <http://perf.haskell.org/ghc> is running again.
>>> 
>>> I am collecting instruction counts instead of runtime, because the latter 
>>> was just too often varying too wildly. I hope this will yield less false 
>>> alarms.
>>> 
>>> I am also running nofib with mode=fast. This way, building GHC, running the 
>>> testsuite and nofib takes a bit over one hour. I hope this can keep up with 
>>> y'all's commits (when it took 2h it couldn't).
>>> 
>>> Now nothing of the setup requires a quiet dedicated machine, so if there is 
>>> a need, we could move these builds into the cloud or into some CI 
>>> infrastructure - but no changes are immediately planned.
>>> 
>>> Enjoy, Joachim 
> -- 
> Joachim Breitner
>  m...@joachim-breitner.de <mailto:m...@joachim-breitner.de>
>  http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> <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: Relocatable dist

[Manuel M T Chakravarty]

That doesn’t mean it can’t be used for cross-compilation once it is in the tree.

> Am 25.10.2017 um 11:06 schrieb Brandon Allbery <allber...@gmail.com>:
> 
> Discussion I've been seeing is Hadrian will not be ready for production use 
> for 8.4. Pulling it in tree is scheduled for 8.4 mostly to make it easier to 
> keep up to date with other changes and to make it easier to work on and test 
> the various missing pieces: as I understand it, Hadrian can't yet deal with 
> all of the various platform special cases, etc. that an actual release 
> requires. 
> 
> On Tue, Oct 24, 2017 at 8:02 PM, Manuel M T Chakravarty <c...@justtesting.org 
> <mailto:c...@justtesting.org>> wrote:
> Why are you saying that? 
> 
> I think, Moritz is right. Hadrian is supposed to be the build system for 8.4. 
> Adding new functionality for cross-compilation to the old build system is 
> frustrating.
> 
> Manuel
> 
>> Brandon Allbery <allber...@gmail.com <mailto:allber...@gmail.com>>:
>> 
>> On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann 
>> <moritz.angerm...@gmail.com <mailto:moritz.angerm...@gmail.com>> wrote:
>> However, I am now again at the point where I start hacking on the build
>> system, while Hadrian is imminent.  And this is quite depressing
>> 
>> Realistically, while Hadrian going into the tree may be imminent, as I 
>> understand it Hadrian becoming the primary build system --- or even a viable 
>> alternative build system --- is not. It's more of a repo logistics speed 
>> bump. Just let it go for now.
>> 
>> -- 
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com <mailto:allber...@gmail.com> 
>>  ballb...@sinenomine.net <mailto:ballb...@sinenomine.net>
>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net 
>> <http://sinenomine.net/>___
>> ghc-devs mailing list
>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
> 
> 
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com <mailto:allber...@gmail.com>  
> ballb...@sinenomine.net <mailto:ballb...@sinenomine.net>
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net 
> <http://sinenomine.net/>___
> 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: Relocatable dist

[Manuel M T Chakravarty]

> Am 24.10.2017 um 20:02 schrieb Moritz Angermann <moritz.angerm...@gmail.com>:
> 
> Hi *,
> 
> so I've given this a stab[1].  While getting the wrapper requirement,
> and the .conf files sorted was rather easy. (We already have 
> getExecutablePath,
> and the relocatable logic for windows.  As well as $topdir and ${pkgroot} 
> support for paths in .conf files.)

Awesome!

> Now as Manuel laid out the dynamic libraries situation is a bit annoying.
> Specifically as the ghc-stage2 we build *in-tree*, and the libraries have
> a completely different layout from the final install location.  And as such
> setting @rpath, and @loader_path, is quite tricky, as essentially the
> installation is not a relocation of the stage1 or stage2 compiler.

Yes, that’s why I took the hacky short-cut of running the normal install 
procedure and then patching the libs up in place with ’install_name_tool’. 
(BTW, a not too widely known tool that makes messing with dylibs, RPATHs, and 
signatures way nicer than otool is <http://newosxbook.com/tools/jtool.html 
<http://newosxbook.com/tools/jtool.html>> — the output is so much more 
readable.)

> However, I am now again at the point where I start hacking on the build
> system, while Hadrian is imminent.  And this is quite depressing.

I hear you.

Cheers,
Manuel

> Cheers,
> Moritz
> 
> --
> [1]: https://phabricator.haskell.org/D4121
>> On Oct 24, 2017, at 9:54 AM, Moritz Angermann <moritz.angerm...@gmail.com> 
>> wrote:
>> 
>> Hi Manuel,
>> 
>> thanks for the link!  Ahh yes lovely RPATH (this reminds me, I should look
>> to verify if I can make GHC link recursively.)  The conf files came up on
>> #ghc yesterday as well. Maybe we need some $home, $sysroot or similar marker
>> to make them relocatable.
>> 
>> I'll probably take a crack at this today.  Not sure how far I get though.
>> The primary motivation is that packaging the cross compilers in a neat
>> way looks like layering patched upon patches onto the configure script. And
>> in light of Hadrian, we might just want to package up a directory and not
>> deal with the binary-dist logic where we can?
>> 
>> Cheers,
>> Moritz
>> 
>>> On Oct 24, 2017, at 9:45 AM, Manuel M T Chakravarty <c...@justtesting.org> 
>>> wrote:
>>> 
>>> Hi Moritz,
>>> 
>>> Haskell for Mac is fully relocatable (as every Mac users expects this of a 
>>> Mac app).
>>> 
>>> Unfortunately, it is not just the libdir in the wrapper scripts that’s in 
>>> the way of a relocatable GHC. Additional problems are (1) the (at least, as 
>>> of 8.0) still not macOS-friendly RPATHs in dynamic libraries and (2) the 
>>> absolute paths in package .conf files.
>>> 
>>> In Haskell for Mac, I use two arguably hacky solutions to those two issues. 
>>> I rewrite all RPATHs in .dylibs to be relative and I have got a little tool 
>>> that relocates .conf files. I’d certainly prefer a cleaner solution!
>>> 
>>> Those aspects of Haskell for Mac are actually in a separate framework 
>>> (GHC.framework) that wraps GHC and some other tools. This is all in a 
>>> public repo if you like to have a look
>>> 
>>> https://github.com/haskellformac/GHCframework
>>> 
>>> I haven’t put a license on it, but I’d be happy to make it all BSD3. It is 
>>> of course all highly Mac specific and requires Xcode to build for all the 
>>> code signing, sandboxing, etc.
>>> 
>>> Cheers,
>>> Manuel
>>> 
>>>> Am 23.10.2017 um 17:04 schrieb Moritz Angermann 
>>>> <moritz.angerm...@gmail.com>:
>>>> 
>>>> Hi,
>>>> 
>>>> while trying to make the binary-distribution logic work for
>>>> cross compilers.  I've come wonder, how hard it could be to
>>>> make GHC relocatable. (e.g. just unpack the distribution, 
>>>> and use the compiler from the `bin` folder within).
>>>> 
>>>> Right now this does not work due to the need for the path to
>>>> package.conf, and this is hardcoded in the wrapper script to
>>>> provide the proper libdir to ghc via -B[1]. Supposedly this
>>>> is not an issue on Windows, as a relative path is common on
>>>> windows and finding the location of the executable can be done
>>>> safely. Or that's at least how I understand[1].
>>>> 
>>>> For macOS there is the haskell-platform, and ghc-dot-app[2]
>>>> 
>>>> From [3], it sounds like automake is a build, and not a packaging
>>

Re: Relocatable dist

[Manuel M T Chakravarty]

Hi Moritz,

Haskell for Mac is fully relocatable (as every Mac users expects this of a Mac 
app).

Unfortunately, it is not just the libdir in the wrapper scripts that’s in the 
way of a relocatable GHC. Additional problems are (1) the (at least, as of 8.0) 
still not macOS-friendly RPATHs in dynamic libraries and (2) the absolute paths 
in package .conf files.

In Haskell for Mac, I use two arguably hacky solutions to those two issues. I 
rewrite all RPATHs in .dylibs to be relative and I have got a little tool that 
relocates .conf files. I’d certainly prefer a cleaner solution!

Those aspects of Haskell for Mac are actually in a separate framework 
(GHC.framework) that wraps GHC and some other tools. This is all in a public 
repo if you like to have a look

  https://github.com/haskellformac/GHCframework 


I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of 
course all highly Mac specific and requires Xcode to build for all the code 
signing, sandboxing, etc.

Cheers,
Manuel

> Am 23.10.2017 um 17:04 schrieb Moritz Angermann :
> 
> Hi,
> 
> while trying to make the binary-distribution logic work for
> cross compilers.  I've come wonder, how hard it could be to
> make GHC relocatable. (e.g. just unpack the distribution, 
> and use the compiler from the `bin` folder within).
> 
> Right now this does not work due to the need for the path to
> package.conf, and this is hardcoded in the wrapper script to
> provide the proper libdir to ghc via -B[1]. Supposedly this
> is not an issue on Windows, as a relative path is common on
> windows and finding the location of the executable can be done
> safely. Or that's at least how I understand[1].
> 
> For macOS there is the haskell-platform, and ghc-dot-app[2]
> 
> From [3], it sounds like automake is a build, and not a packaging
> system, and the binary dist usecase with configure is not
> really a standard use case.
> 
> So why do I bring this up NOW? Apart from me trying to make
> cross compiler binary distributions working?  The reason is
> that we are also trying to move towards hadrian, and by "starting
> from scratch", maybe we have a chance to reconsider how we
> do things?
> 
> I must admit, I'm quite happy to use packages like llvm, by
> just downloading a package and adding the `bin` path to my
> $PATH.
> 
> There is however one thing that the current configure appraoch
> does, which I think is quite noteworthy (apart from setting
> $prefix).  That is, it does check for compilers and sets them
> accordingly, which might be desirable.
> 
> Cheers,
> Moritz
> 
> --
> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg5.html
> ___
> 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: perf.haskell.org functional again

[Manuel M T Chakravarty]

Hi Joachim,

Great! Just because you mention CI infrastructure and our effort around GHC CI 
at the moment, do you think, it would make sense to move this to CircleCI 
eventually?

Cheers,
Manuel

> Am 24.10.2017 um 11:02 schrieb Joachim Breitner :
> 
> Hi,
> 
> after a system upgrade to avoid weird linker errors, and after some fixes in 
> the nofib submodule, http://perf.haskell.org/ghc is running again.
> 
> I am collecting instruction counts instead of runtime, because the latter was 
> just too often varying too wildly. I hope this will yield less false alarms.
> 
> I am also running nofib with mode=fast. This way, building GHC, running the 
> testsuite and nofib takes a bit over one hour. I hope this can keep up with 
> y'all's commits (when it took 2h it couldn't).
> 
> Now nothing of the setup requires a quiet dedicated machine, so if there is a 
> need, we could move these builds into the cloud or into some CI 
> infrastructure - but no changes are immediately planned.
> 
> Enjoy, Joachim 
> ___
> 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

[ANN] GHC DevOps Group

[Manuel M T Chakravarty]

We announced the GHC DevOps Group at the Haskell Implementors’ Workshop in 
Oxford earlier this year in Simon PJ’s ”Progress on GHC” session. (The videos 
are unfortunately not yet online.) To finally announce it more broadly, I wrote 
a blog post:

  http://www.tweag.io/posts/2017-10-19-ghc-devops-group.html

Cheers,
Manuel

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

Re: Call for features for GHC 8.4

[Manuel M T Chakravarty]

Just as a general note, with the push towards regular releases at 6 month 
intervals whose final release doesn’t drag out 2-3 month after the expected 
release date, I think, having few items on the status page is a Good Thing. So, 
let’s not cram too much in, as Ben wrote, 8.6 will not be that much further of.

Cheers,
Manuel

> Ben Gamari :
> 
> Hello everyone,
> 
> The release of GHC 8.4 is quickly approaching, with a release targetted
> for February 2018. To allow plenty of time for stabilization, we would
> like to cut the ghc-8.4 branch sometime in November. Currently there are
> relatively few items on the 8.4 status page [1]. If you have a feature
> which you would like to see in 8.4 but is not listed there please do
> add it soon.
> 
> Also note that if things go according to plan, 8.6 will come a mere six
> months after 8.4 so if you have a large feature which won't make it for
> 8.4, do not fret; another release will be just around the corner.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1
> ___
> 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: GHC staus

[Manuel M T Chakravarty]

I’ll only arrive Wednesday during the day, so maybe sometime second half of the 
week?

> Moritz Angermann <moritz.angerm...@gmail.com>:
> 
> I'm around all week. I actually do have remote ghci on my todo list ;-)
> 
> Cheers,
>  Moritz
> Sent from my iPhone
> 
> On 4 Sep 2017, at 11:21 AM, Simon Marlow <marlo...@gmail.com 
> <mailto:marlo...@gmail.com>> wrote:
> 
>> I have a vested interest in the cross-compilation story because it's very 
>> related to Remote GHCi, so I'd love to join in if you have a discussion 
>> about that :)
>> 
>> On 4 September 2017 at 11:16, Manuel M T Chakravarty <c...@justtesting.org 
>> <mailto:c...@justtesting.org>> wrote:
>> +1 for a lighting talk on that! (You can tell the organisers that ;)
>> 
>> Also, we should make sure to meet and talk about cross-compilation and GHC 
>> for iOS :)
>> 
>> Manuel
>> 
>>> Moritz Angermann <moritz.angerm...@gmail.com 
>>> <mailto:moritz.angerm...@gmail.com>>:
>>> 
>>> Hi,
>>> 
>>> not sure if this is noteworthy:
>>> 
>>> The following is or will hopefully make(*) it
>>> into 8.4 as well
>>> 
>>> - (1) iserv-remote (run iserv on a remote device over the network)
>>> - (2) arm / aarch64 linker for elf and mach-o
>>> - (3*) `-staticlib` support for Linux and BSD derivatives (was darwin 
>>> only): 
>>> - (4*) `-llvmng` new llvm bitcode code gen
>>> - (5*) refactored llvm pipeline
>>> 
>>> This essentially is all part of making GHC natively
>>> support cross compiling (including support for Template Haskell) to 
>>> android/iOS/RaspberryPi.
>>> 
>>> I hope to give a lighting talk around those, if I get a slot.
>>> 
>>> Cheers,
>>>  Moritz
>>> 
>>> Sent from my iPhone
>>> 
>>> On 4 Sep 2017, at 8:01 AM, Iavor Diatchki <iavor.diatc...@gmail.com 
>>> <mailto:iavor.diatc...@gmail.com>> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> Trevor Elliott and I have been slowly working on implementing Simon M's  
>>>> "Mutable Constructor Fields" proposal [1].
>>>> 
>>>> The current state of the code is here:
>>>> https://github.com/yav/ghc/tree/wip/mutable-fields 
>>>> <https://github.com/yav/ghc/tree/wip/mutable-fields>
>>>> 
>>>> I am not sure if this would be ready in time for 8.4 as I don't know what 
>>>> the time-line looks like, and also, the actual proposal is still in the 
>>>> process of being reviewed by the GHC committee.
>>>> 
>>>> -Iavor 
>>>> 
>>>> [1] 
>>>> https://github.com/simonmar/ghc-proposals/blob/mutable-fields/proposals/-mutable-fields.rst
>>>>  
>>>> <https://github.com/simonmar/ghc-proposals/blob/mutable-fields/proposals/-mutable-fields.rst>
>>>> 
>>>> 
>>>> 
>>>> On Sun, Sep 3, 2017 at 2:15 PM Simon Peyton Jones via ghc-devs 
>>>> <ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>> wrote:
>>>> Ben, Simon, and ghc-devs
>>>> 
>>>> I have to write slides for the GHC status talk in the Haskell 
>>>> Implementor’s meeting.
>>>> 
>>>> Usually we have
>>>> 
>>>> Current status (current release)
>>>> What’s cooking for the next release
>>>> GHC community comments
>>>> As background we have
>>>> 
>>>> Our Apr 17 status page <https://ghc.haskell.org/trac/ghc/wiki/Status/Apr17>
>>>> Our 8.2 release notes 
>>>> <https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/8.2.1-notes.html>
>>>> Our 8.4 status page 
>>>> <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1>
>>>> What would you put under (1-3)?  Anything you’d like to see highlighted?
>>>> 
>>>> 
>>>> Simon
>>>> 
>>>> ___
>>>> ghc-devs mailing list
>>>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
>>>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>>> ___
>>>> ghc-devs mailing list
>>>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
>>>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
>>> <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: GHC staus

[Manuel M T Chakravarty]

+1 for a lighting talk on that! (You can tell the organisers that ;)

Also, we should make sure to meet and talk about cross-compilation and GHC for 
iOS :)

Manuel

> Moritz Angermann :
> 
> Hi,
> 
> not sure if this is noteworthy:
> 
> The following is or will hopefully make(*) it
> into 8.4 as well
> 
> - (1) iserv-remote (run iserv on a remote device over the network)
> - (2) arm / aarch64 linker for elf and mach-o
> - (3*) `-staticlib` support for Linux and BSD derivatives (was darwin only): 
> - (4*) `-llvmng` new llvm bitcode code gen
> - (5*) refactored llvm pipeline
> 
> This essentially is all part of making GHC natively
> support cross compiling (including support for Template Haskell) to 
> android/iOS/RaspberryPi.
> 
> I hope to give a lighting talk around those, if I get a slot.
> 
> Cheers,
>  Moritz
> 
> Sent from my iPhone
> 
> On 4 Sep 2017, at 8:01 AM, Iavor Diatchki  > wrote:
> 
>> Hello,
>> 
>> Trevor Elliott and I have been slowly working on implementing Simon M's  
>> "Mutable Constructor Fields" proposal [1].
>> 
>> The current state of the code is here:
>> https://github.com/yav/ghc/tree/wip/mutable-fields 
>> 
>> 
>> I am not sure if this would be ready in time for 8.4 as I don't know what 
>> the time-line looks like, and also, the actual proposal is still in the 
>> process of being reviewed by the GHC committee.
>> 
>> -Iavor 
>> 
>> [1] 
>> https://github.com/simonmar/ghc-proposals/blob/mutable-fields/proposals/-mutable-fields.rst
>>  
>> 
>> 
>> 
>> 
>> On Sun, Sep 3, 2017 at 2:15 PM Simon Peyton Jones via ghc-devs 
>> > wrote:
>> Ben, Simon, and ghc-devs
>> 
>> I have to write slides for the GHC status talk in the Haskell Implementor’s 
>> meeting.
>> 
>> Usually we have
>> 
>> Current status (current release)
>> What’s cooking for the next release
>> GHC community comments
>> As background we have
>> 
>> Our Apr 17 status page 
>> Our 8.2 release notes 
>> 
>> Our 8.4 status page 
>> What would you put under (1-3)?  Anything you’d like to see highlighted?
>> 
>> 
>> Simon
>> 
>> ___
>> 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: Trac to Phabricator (Maniphest) migration prototype

[Manuel M T Chakravarty]

This looks good!

Manuel

> Am 21.12.2016 um 21:12 schrieb Matthew Pickering 
> :
> 
> Dear devs,
> 
> I have completed writing a migration which moves tickets from trac to
> phabricator. The conversion is essentially lossless. The trac
> transaction history is replayed which means all events are transferred
> with their original authors and timestamps. I welcome comments on the
> work I have done so far, especially bugs as I have definitely not
> looked at all 12000 tickets.
> 
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
> 
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
> 
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
> 
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
> 
> Further information below!
> 
> Matt
> 
> =
> 
> Reasons
> ==
> 
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
> 
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
> 
> 
> Why is Phabricator better?
> 
> 
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the usability of the
> issue tracker. I will list a few but I urge you to try it out.
> 
> * Commits which mention ticket numbers are currently posted as trac
> comments. There is better integration in phabricator as linking to
> commits has first-class support.
> * Links with differentials are also more direct than the current
> custom field which means you must update two places when posting a
> differential.
> * Fields are verified so that mispelling user names is not possible
> (see #12623 where Ben mispelled his name for example)
> * This is also true for projects and other fields. Inspecting these
> fields on trac you will find that the formatting on each ticket is
> often quite different.
> * Keywords are much more useful as the set of used keywords is discoverable.
> * Related tickets are much more substantial as the status of related
> tickets is reflected to parent ticket.
> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
> 
> Implementation
> 
> 
> Keywords are implemented as projects. A project is a combination of a
> tag which can be used with any Phabricator object, a workboard to
> organise tasks and a group of people who care about the topic. Not all
> keywords are migrated. Only keywords with at least 5 tickets were
> added to avoid lots of useless projects. The state of keywords is
> still a bit unsatisfactory but I wanted to take this chance to clean
> them up.
> 
> Custom fields such as architecture and OS are replaced by *projects*
> just like keywords. This has the same advantage as other projects.
> Users can be subscribed to projects and receive emails when new
> tickets are tagged with a project. The large majority of tickets have
> very little additional metadata set. I also implemented these as
> custom fields but found the the result to be less satisfactory.
> 
> Some users who have trac accounts do not have phab accounts.
> Fortunately it is easy to create new user accounts for these users
> which have empty passwords which can be recovered by the appropriate
> email address. This means tickets can be properly attributed in the
> migration.
> 
> The ticket numbers are maintained. I still advocate moving the
> infrastructure tickets in order to maintain this mapping. Especially
> as there has been little activity in thr the last year.
> 
> Tickets are linked to the relevant commits, differentials and other
> tickets. There are 3000 dummy differentials which are used to test
> that the linking works correctly. Of course with real data, the proper
> differential would be
> linked.(http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T11044)
> 
> There are a couple of 

Re: Telemetry (WAS: Attempt at a real world benchmark)

[Manuel M T Chakravarty]

> Am 10.12.2016 um 19:10 schrieb Moritz Angermann <mor...@lichtzwerge.de>:
> Two items I would like to note, that *do* phone home and are *out out*:
> 
> - homebrew[1] package manager that I assume quite a few people use (because 
> it works
>  rather well), see the Analytics.md[2], especially the opt-out section[3].
> - cocoapods[4] (iOS/macOS library repository), which sends back statistics 
> about package
>  usage[5]
> 

Package managers are inherently different to compilers as the *core* 
functionality of a package manager requires network traffic. As network traffic 
on every sane server infrastructure is logged, the use of a package manager 
obviously creates a trail. Now, the package manager can capture more or less 
local information and server side the data can be kept for varying amounts of 
time.

In contrast, it is a reasonable expectation that a compiler does not initiate 
any network traffic as it is not needed for its core functionality.

In other words, adding more analytics to cabal would probably be fairly 
uncontroversial (if it anonymises the data properly), but adding it to GHC will 
make some people very unhappy.

Manuel

> 
>> On Dec 10, 2016, at 1:34 PM, Manuel M T Chakravarty <c...@justtesting.org> 
>> wrote:
>> 
>>> Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>:
>>> 
>>> Just to say:
>>> 
>>> · Telemetry is a good topic
>>> · It is clearly a delicate one as we’ve already seen from two 
>>> widely differing reactions.  That’s why I have never seriously contemplated 
>>> doing anything about it.
>>> · I’m love a consensus to emerge on this, but I don’t have the 
>>> bandwidth to drive it.
>>> 
>>> Incidentally, when I said “telemetry is common” I meant that almost every 
>>> piece of software I run on my PC these days automatically checks for 
>>> updates.  It no longer even asks me if I want to do that.. it just does it. 
>>>  That’s telemetry right there: the supplier knows how many people are 
>>> running each version of their software.
>> 
>> I think, it is important to notice that the expectations of users varies 
>> quite significantly from platform to platform. For example, macOS users on 
>> average expect more privacy protections than Windows users and Linux users 
>> expect more than macOS users. In particular, a lot of 3rd party software on 
>> macOS still asks whether you want to enable automatic update checks.
>> 
>> Moreover, while most people tolerate that end user GUI software performs 
>> some analytics, I am sure that most users of command line (and especially 
>> developer tools) would be very surprised to learn that it performs analytics.
>> 
>> Finally, once you gather analytics you need to have a privacy policy in 
>> many/most jurisdictions (certainly in EU and AU) these days, which explains 
>> what data is gathered, where it is stored, etc. This typically also involves 
>> statements about sharing that data. All quite easily covered by a software 
>> business, but hard to do in an open source project unless you limit access 
>> to the data to a few people. (Even if you ask users for permission to gather 
>> data, I am quite sure, you still need a privacy policy.)
>> 
>> Manuel
>> 
>> 
>>> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of MarLinn 
>>> via ghc-devs
>>> Sent: 09 December 2016 14:52
>>> To: ghc-devs@haskell.org
>>> Subject: Re: Telemetry (WAS: Attempt at a real world benchmark)
>>> 
>>> 
>>> 
>>> It could tell us which language features are most used. 
>>> 
>>> Language features are hard if they are not available in separate libs. If 
>>> in libs, then IIRC debian is packaging those in separate packages, again 
>>> you can use their package contest.
>>> 
>>> What in particular makes them hard? Sorry if this seems like a stupid 
>>> question to you, I'm just not that knowledgeable yet. One reason I can 
>>> think of would be that we would want attribution, i.e. did the developer 
>>> turn on the extension himself, or is it just used in a lib or template – 
>>> but that should be easy to solve with a source hash, right? That source 
>>> hash itself might need a bit of thought though. Maybe it should not be a 
>>> hash of a source file, but of the parse tree.
>>> 
>>> 
>>> The big issue is (a) design and implementation effort, and (b) dealing with 
>>> the privacy issues.  I think (b) used to be a big deal, but nowadays people 
>>>

Re: Telemetry (WAS: Attempt at a real world benchmark)

[Manuel M T Chakravarty]

> Simon Peyton Jones via ghc-devs :
> 
> Just to say:
>  
> · Telemetry is a good topic
> · It is clearly a delicate one as we’ve already seen from two widely 
> differing reactions.  That’s why I have never seriously contemplated doing 
> anything about it.
> · I’m love a consensus to emerge on this, but I don’t have the 
> bandwidth to drive it.
>  
> Incidentally, when I said “telemetry is common” I meant that almost every 
> piece of software I run on my PC these days automatically checks for updates. 
>  It no longer even asks me if I want to do that.. it just does it.  That’s 
> telemetry right there: the supplier knows how many people are running each 
> version of their software.

I think, it is important to notice that the expectations of users varies quite 
significantly from platform to platform. For example, macOS users on average 
expect more privacy protections than Windows users and Linux users expect more 
than macOS users. In particular, a lot of 3rd party software on macOS still 
asks whether you want to enable automatic update checks.

Moreover, while most people tolerate that end user GUI software performs some 
analytics, I am sure that most users of command line (and especially developer 
tools) would be very surprised to learn that it performs analytics.

Finally, once you gather analytics you need to have a privacy policy in 
many/most jurisdictions (certainly in EU and AU) these days, which explains 
what data is gathered, where it is stored, etc. This typically also involves 
statements about sharing that data. All quite easily covered by a software 
business, but hard to do in an open source project unless you limit access to 
the data to a few people. (Even if you ask users for permission to gather data, 
I am quite sure, you still need a privacy policy.)

Manuel


> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of MarLinn via 
> ghc-devs
> Sent: 09 December 2016 14:52
> To: ghc-devs@haskell.org
> Subject: Re: Telemetry (WAS: Attempt at a real world benchmark)
>  
> 
> 
> It could tell us which language features are most used. 
> 
> Language features are hard if they are not available in separate libs. If in 
> libs, then IIRC debian is packaging those in separate packages, again you can 
> use their package contest.
> 
> What in particular makes them hard? Sorry if this seems like a stupid 
> question to you, I'm just not that knowledgeable yet. One reason I can think 
> of would be that we would want attribution, i.e. did the developer turn on 
> the extension himself, or is it just used in a lib or template – but that 
> should be easy to solve with a source hash, right? That source hash itself 
> might need a bit of thought though. Maybe it should not be a hash of a source 
> file, but of the parse tree.
> 
> 
> The big issue is (a) design and implementation effort, and (b) dealing with 
> the privacy issues.  I think (b) used to be a big deal, but nowadays people 
> mostly assume that their software is doing telemetry, so it feels more 
> plausible.  But someone would need to work out whether it had to be opt-in or 
> opt-out, and how to actually make it work in practice.
> 
> Privacy here is complete can of worms (keep in mind you are dealing with a 
> lot of different law systems), I strongly suggest not to even think about it 
> for a second. Your note "but nowadays people mostly assume that their 
> software is doing telemetry" may perhaps be true in sick mobile apps world, 
> but I guess is not true in the world of developing secure and security 
> related applications for either server usage or embedded.
>  
> My first reaction to "nowadays people mostly assume that their software is 
> doing telemetry" was to amend it with "* in the USA" in my mind. But yes, 
> mobile is another place. Nowadays I do assume most software uses some sort of 
> phone-home feature, but that's because it's on my To Do list of things to 
> search for on first configuration. Note that I am using "phone home" instead 
> of "telemetry" because some companies hide it in "check for updates" or mix 
> it with some useless "account" stuff. Finding out where it's hidden and how 
> much information they give about the details tells a lot about the 
> developers, as does opt-in vs opt-out. Therefore it can be a reason to not 
> choose a piece of software or even an ecosystem after a first try. (Let's say 
> an operating system almost forces me to create an online account on 
> installation. That not only tells me I might not want to use that operating 
> system, it also sends a marketing message that the whole ecosystem is 
> potentially toxic to my privacy because they live in a bubble where that 
> appears to be acceptable.) So I do have that aversion even in 
> non-security-related contexts.
> 
> I would say people are aware that telemetry exists, and developers in 
> particular. I would also say developers are aware of the potential 

Re: Making (useful subsets of) bytecode portable between targets

[Manuel M T Chakravarty]

I totally agree that GHC with TH is crippled and that this is a major 
restriction off the cross-compilation story. All I am saying is that I see a 
device runner (and to a degree a simulator runner) not as a solution to this 
*important* problem. Architecture independent interpretable byte code seems a 
much more attractive avenue for me. (Sorry if I didn’t make this clear.)

Manuel

> Moritz Angermann <mor...@lichtzwerge.de>:
> 
> Aren’t we taking this a bit too far off topic? I feared as much when I wrote 
> my
> initial reply. Please excuse.
> 
> I agree that ghc + runner is not an optimal, and maybe even for some tasks 
> (iOS)
> a pretty convoluted solution.
> 
> This is only if we follow the proven solution to TH that luite in ghcjs 
> pioneered,
> and which later found it’s way into ghc through iserv.  If someone proposes a
> solution to TH that does not require a runner and allows the TH to be fully
> evaluated on the host with no need to evaluate on the target for cross 
> compilation,
> that would be great!
> 
> If the runner would just require the same architecture, maybe qemu would be a 
> solution
> that would not require a device running?  Then again I’m not sure how that 
> would
> work with TH that directly or indirectly accesses libraries only available on 
> iOS for
> example.
> 
> Please don’t get me wrong. IMO ghc without TH is quite crippled, and 
> therefore so is a 
> cross compiling ghc. From the solutions I saw to this problem (zeroth, 
> evil-splicer, and
> the ghcjs runner approach), the ghcjs runner approach, seems to me at least 
> as the most
> promising, that would work for the largest subset of TH.
> 
> To get this back on topic, if we have a architecture independent 
> interpretable bytecode,
> for ghc, could we sidestep the runner solution altogether and have TH for the 
> target
> be evaluated on the host?  Is this what Shea initially wanted to go after?
> 
> cheers,
> moritz
> 
>> On Nov 25, 2016, at 2:38 PM, Manuel M T Chakravarty <c...@justtesting.org> 
>> wrote:
>> 
>> Ok, I am not saying that it is technical impossible. I am saying that it is 
>> *impractical*. 
>> 
>> Imagine Travis CI needing to run stuff on my phone that is attached to my 
>> Mac (if we are lucky), which is behind NAT somewhere in Australia. 
>> 
>> Running stuff in the simulator during a build would be pretty awkward, but 
>> running it on the device is not practical.
>> 
>> Manuel
>> 
>> PS: BTW, shipping binary code to the device means it has to be code signed 
>> using a distribution profile of a registered developer. That is one thing if 
>> Xcode does all the magic behind the scenes, but do you really want to make 
>> that part of the GHC build process?
>> 
>>> Edward Z. Yang <ezy...@mit.edu>:
>>> 
>>> At least for Travis, you can generate a private key that only Travis
>>> has access to, and use this to authenticate access to the runner.
>>> See https://docs.travis-ci.com/user/encryption-keys/
>>> 
>>> Edward
>>> 
>>> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100:
>>>> If you use Travis CI or such, do you really want to have a runner 
>>>> accessible from an arbitrary host on the Internet?
>>>> 
>>>>> Moritz Angermann <mor...@lichtzwerge.de>:
>>>>> 
>>>>> It's certainly far from ideal, but for CI, what obstacles are there 
>>>>> besides needing a runner accessible from cross compiling machine?
>>>>> 
>>>>> E.g. Start the runner app on an iPhone plugged in into a USB power source 
>>>>> and leave it there?
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty 
>>>>>> <c...@justtesting.org> wrote:
>>>>>> 
>>>>>> Sorry, but I don’t think running on the device is practical. How do you 
>>>>>> want to do CI, for example?
>>>>>> 
>>>>>> Manuel
>>>>>> 
>>>>>>> Moritz Angermann <mor...@lichtzwerge.de>:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow <marlo...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> […]
>>>>>>>> 
>>>>>>>> My question would be: are you *sure* you can't run target code at 
>>>>>>>> compile time?  Not eve

Re: Making (useful subsets of) bytecode portable between targets

[Manuel M T Chakravarty]

Ok, I am not saying that it is technical impossible. I am saying that it is 
*impractical*. 

Imagine Travis CI needing to run stuff on my phone that is attached to my Mac 
(if we are lucky), which is behind NAT somewhere in Australia. 

Running stuff in the simulator during a build would be pretty awkward, but 
running it on the device is not practical.

Manuel

PS: BTW, shipping binary code to the device means it has to be code signed 
using a distribution profile of a registered developer. That is one thing if 
Xcode does all the magic behind the scenes, but do you really want to make that 
part of the GHC build process?

> Edward Z. Yang <ezy...@mit.edu>:
> 
> At least for Travis, you can generate a private key that only Travis
> has access to, and use this to authenticate access to the runner.
> See https://docs.travis-ci.com/user/encryption-keys/
> 
> Edward
> 
> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100:
>> If you use Travis CI or such, do you really want to have a runner accessible 
>> from an arbitrary host on the Internet?
>> 
>>> Moritz Angermann <mor...@lichtzwerge.de>:
>>> 
>>> It's certainly far from ideal, but for CI, what obstacles are there besides 
>>> needing a runner accessible from cross compiling machine?
>>> 
>>> E.g. Start the runner app on an iPhone plugged in into a USB power source 
>>> and leave it there?
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty <c...@justtesting.org> 
>>>> wrote:
>>>> 
>>>> Sorry, but I don’t think running on the device is practical. How do you 
>>>> want to do CI, for example?
>>>> 
>>>> Manuel
>>>> 
>>>>> Moritz Angermann <mor...@lichtzwerge.de>:
>>>>> 
>>>>> 
>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow <marlo...@gmail.com> wrote:
>>>>>> 
>>>>>> […]
>>>>>> 
>>>>>> My question would be: are you *sure* you can't run target code at 
>>>>>> compile time?  Not even with an iphone simulator?
>>>>> 
>>>>> This should be possible. However for proper development one would need to 
>>>>> run on the
>>>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or 
>>>>> x86_64.
>>>>> 
>>>>> There is a bit of additional engineering required here to get the 
>>>>> shipping of
>>>>> code from ghc to the runner on the target required (e.g. via network).  
>>>>> As executing
>>>>> and controlling applications on the actual hardware is limited, I guess a 
>>>>> custom
>>>>> ghc-runner application would have to be manually started on the device, 
>>>>> which could
>>>>> trivially be discovered using bonjour/zeroconf (or just giving ghc the 
>>>>> host:port information).
>>>>> 
>>>>> In general though, the runner does not have to obey all the restrictions 
>>>>> apple puts
>>>>> onto app-store distributed apps, as I expect that everyone could build 
>>>>> and install
>>>>> the runner themselves when intending to do iOS development with ghc.
>>>>> 
>>>>> cheers,
>>>>> moritz
>>>>> ___
>>>>> 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: Making (useful subsets of) bytecode portable between targets

[Manuel M T Chakravarty]

If you use Travis CI or such, do you really want to have a runner accessible 
from an arbitrary host on the Internet?

> Moritz Angermann <mor...@lichtzwerge.de>:
> 
> It's certainly far from ideal, but for CI, what obstacles are there besides 
> needing a runner accessible from cross compiling machine?
> 
> E.g. Start the runner app on an iPhone plugged in into a USB power source and 
> leave it there?
> 
> Sent from my iPhone
> 
>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty <c...@justtesting.org> 
>> wrote:
>> 
>> Sorry, but I don’t think running on the device is practical. How do you want 
>> to do CI, for example?
>> 
>> Manuel
>> 
>>> Moritz Angermann <mor...@lichtzwerge.de>:
>>> 
>>> 
>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow <marlo...@gmail.com> wrote:
>>>> 
>>>> […]
>>>> 
>>>> My question would be: are you *sure* you can't run target code at compile 
>>>> time?  Not even with an iphone simulator?
>>> 
>>> This should be possible. However for proper development one would need to 
>>> run on the
>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or 
>>> x86_64.
>>> 
>>> There is a bit of additional engineering required here to get the shipping 
>>> of
>>> code from ghc to the runner on the target required (e.g. via network).  As 
>>> executing
>>> and controlling applications on the actual hardware is limited, I guess a 
>>> custom
>>> ghc-runner application would have to be manually started on the device, 
>>> which could
>>> trivially be discovered using bonjour/zeroconf (or just giving ghc the 
>>> host:port information).
>>> 
>>> In general though, the runner does not have to obey all the restrictions 
>>> apple puts
>>> onto app-store distributed apps, as I expect that everyone could build and 
>>> install
>>> the runner themselves when intending to do iOS development with ghc.
>>> 
>>> cheers,
>>> moritz
>>> ___
>>> 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: Making (useful subsets of) bytecode portable between targets

[Manuel M T Chakravarty]

Sorry, but I don’t think running on the device is practical. How do you want to 
do CI, for example?

Manuel

> Moritz Angermann :
> 
> 
>> On Nov 23, 2016, at 7:50 PM, Simon Marlow  wrote:
>> 
>> […]
>> 
>> My question would be: are you *sure* you can't run target code at compile 
>> time?  Not even with an iphone simulator?
> 
> This should be possible. However for proper development one would need to run 
> on the
> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or 
> x86_64.
> 
> There is a bit of additional engineering required here to get the shipping of
> code from ghc to the runner on the target required (e.g. via network).  As 
> executing
> and controlling applications on the actual hardware is limited, I guess a 
> custom
> ghc-runner application would have to be manually started on the device, which 
> could
> trivially be discovered using bonjour/zeroconf (or just giving ghc the 
> host:port information).
> 
> In general though, the runner does not have to obey all the restrictions 
> apple puts
> onto app-store distributed apps, as I expect that everyone could build and 
> install
> the runner themselves when intending to do iOS development with ghc.
> 
> cheers,
> moritz
> ___
> 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: How, precisely, can we improve?

[Manuel M T Chakravarty]

Michael’s arguments are compelling.

Manuel

> Simon Peyton Jones via ghc-devs :
> 
> Interesting article.  Michael suggests using markdown in repo-controlled 
> files rather than a wiki.  I can see the force of that. Maybe we should 
> consider it.
>  
> Simon
>   <>
> From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com] 
> Sent: 27 September 2016 15:54
> To: Simon Peyton Jones 
> Cc: Sven Panne ; ghc-devs 
> Subject: Re: How, precisely, can we improve?
>  
> I think this is relevant to the dicussion: 
> http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation 
> 
> Alan
>  
> On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs 
> > wrote:
> We currently have *3* wikis:
>  
> https://wiki.haskell.org/Haskell 
> 
> https://ghc.haskell.org/trac/ghc 
> https://phabricator.haskell.org/w/ 
> 
>  
> I didn’t even know about  the third of these, but the first two have clearly 
> differentiated goals:
> ·https://wiki.haskell.org/Haskell 
> 
>  is about user-facing, and often user-generated, documentation.  Guidance 
> about improving performance, programming idioms, tutorials etc.
> 
> ·https://ghc.haskell.org/trac/ghc  
> is about GHC’s implementation, oriented to people who want to understand how 
> GHC works, and how to modify it.
> 
>  
> I think this separation is actually quite helpful.
>  
> I agree with what you and others say about the difficulty of keeping wikis 
> organised. But that’s not primarily a technology issue: there is a genuinely 
> difficult challenge here.  How do you build and maintain up-to-date, 
> navigable, well-organised information about a large, complex, and rapidly 
> changing artefact like GHC?  A wiki is one approach that has the merit that 
> anyone can improve it; control is not centralised.  But I’d love there to be 
> other, better solutions.
>  
> Simon
>   <>
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org 
> ] On Behalf Of Sven Panne
> Sent: 27 September 2016 08:46
> To: ghc-devs >
> Subject: Re: How, precisely, can we improve?
>  
> Just a remark from my side: The documentation/tooling landscape is a bit more 
> fragmented than it needs to be IMHO. More concretely:
>  
>* We currently have *3* wikis:
>  
> https://wiki.haskell.org/Haskell 
> 
> https://ghc.haskell.org/trac/ghc 
> https://phabricator.haskell.org/w/ 
> 
>  
>  
>  It's clear to me that they have different emphases and different 
> origins, but in the end this results in valuable information being scattered 
> around. Wikis in general are already quite hard to navigate (due to their 
> inherent chaotic "structure"), so having 3 of them makes things even worse. 
> It would be great to have *the* single Haskell Wiki directly on haskell.org 
> 
>  in an easily reachable place.
>  
>* To be an active Haskell community member, you need quite a few different 
> logins: Some for the Wikis mentioned above, one for Hackage, another one for 
> Phabricator, perhaps an SSH key here and there... Phabricator is a notable 
> exception: It accepts your GitHub/Google+/... logins. It would be great if 
> the other parts of the Haskell ecosystem accepted those kinds of logins, too.
>  
>* https://haskell-lang.org/ 
> 

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Manuel M T Chakravarty]

Sounds like a great idea to me and might alleviate SimonM’s concerns about 
fragmentation of dev attention.

Manuel

> Michael Sloan :
> 
> Argh, sent too soon.  The first paragraph, revised:
> 
> This sounds like an ideal solution, Ben!  As has been discussed many
> times before, GitHub has many users familiar with its interface.  By
> allowing GitHub PRs, the initial contribution barrier will be lowered. If
> there is an easy and straightforward process for shifting big patches
> to Phabricator, then people who are regularly contributing via GitHub
> PRs can be incrementally on-boarded to the Phabricator / Arcanist
> workflow.
> 
> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan  wrote:
>> This sounds like an ideal solution, Ben!  As has been discussed many
>> times before, GitHub has many users familiar with its interface.  By
>> allowing GitHub PRs, the initial contribution
>> 
>> I think it would be acceptable for larger GitHub PRs to have some
>> automated boilerplate response.  Ideally this would look like:
>> 
>> """
>> Thanks for making this patch!  I've turned this into a Phab
>> Differential xxx and closed this PR.  Please create a differential
>> account associated with your email address ..."
>> """
>> 
>> The email address can be automatically pulled from commit metadata.
>> If one is absent, then this automated process isn't possible.  If it
>> is present and
>> 
>> So, I'm imagining a utility that interfaces between both GitHub and
>> Phab,allowing the following commands:
>> 
>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1; - migrates the
>> patch to differential.  It may attempt to migrate body and title of
>> the initial post, but lets not bother with migrating any review data.
>> 
>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1; - merges the
>> patch.  This is used for merging small patches.  It would not do an
>> automated push.  Maybe have "--push" also perform the push?  So like
>> if you are on master, then "ghc-hub merge
>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and
>> push to master.
>> 
>> How does this sound?  I like the idea a lot, and would enjoy helping
>> with implementation, time permitting.  I could possibly start hacking
>> on it if others give the go ahead of "Yes, lets do that".
>> 
>> -Michael
>> 
>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari  wrote:
>>> Carter Schonwald  writes:
>>> 
 In writing the following huge wall of text, I had and idea that I think
 many folks would find palatable:
 
 What if simple small patches (such as hypothetical drive by doc patches )
 had a mailing list where folks could email the simple / small patches as
 email attachments plus a body text that summarizes the patch, what it does,
 and why it's simple!
 
>>> I completely agree that for small (e.g. documentation) patches our
>>> current system is quite heavy. For this reason I suggested at ICFP that
>>> we simply begin accepting small patches via GitHub pull requests.
>>> Frankly, this is less work for me than merging patches from a mailing
>>> list and I believe many users feel that GitHub is more accessible than a
>>> mailing list.
>>> 
>>> The problem of course is what subset of patches do we want to allow to
>>> be taken via GitHub. My suggested answer to that is any patch which, if
>>> I were to write it myself, I would feel comfortable pushing directly to
>>> the tree.
>>> 
>>> Then there is the question of what do we do with pull requests opened
>>> which do not satisfy this criterion. In this case I would likely open a
>>> Phabricator Differential with the pull request and close the pull
>>> request with a link to the Diff. In the ideal case this will inspire the
>>> contributor to join the review process on Phabricator; in the worst case
>>> review turns up issues in the patch and the user gives up. Either way, at
>>> least the contributor feels his patch has been seen and given the
>>> attention it deserves.
>>> 
>>> 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

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

Re: Notes from Ben's "contribute to ghc" discussion

[Manuel M T Chakravarty]

Why are you so hostile to Chris? I don’t think that this is an appropriate way 
to treat somebody who is making a suggestion in good faith.

Chris may not have contributed to GHC, but apart from co-authoring the 
currently most popular Haskell book, he has consistently contributed to helping 
people who are new to the language (on Slack, IRC, in blog posts, etc). He has 
suck a ton of time into moving the language forward.

Moreover, he knows a thing or two about helping newcomers in an effective 
manner. And he is right in his critique that it is hard to contribute to GHC.

For example, I recently wrote a patch concerning compatibility with macOS 
Sierra and even posted about it on this list:

  https://mail.haskell.org/pipermail/ghc-devs/2016-July/012512.html 


It’s a small patch, and I just don’t have the time to jump through all the 
hoops to get it into the repo.

And now before you accuse me of not having contributed to GHC, maybe check the 
git logs first.

In summary, if you don’t want to consider that maybe it is harder to contribute 
to GHC than it has to be and making it easier maybe would lead to more 
contributions, that is one thing. However, I do insist that suggestions made in 
good faith on this list are treated politely and not being brutally shot down.

Simon, I imagine you agree with me here.

Manuel

> Brandon Allbery :
> 
> 
> On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen  > wrote:
> This is so short-sighted and wrong that I don't think there's any
> point in my saying more. You've made it clear you don't care.
> 
> And --- note that I am not a ghc developer --- have made it clear that you do 
> not care how much extra work you make for already massively overworked ghc 
> developers.
> You're not contributing. You're not helping. You're derailing.
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com   
> ballb...@sinenomine.net 
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net 
> ___
> 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: Adding ConApp to Core

[Manuel M T Chakravarty]

I like this. Having the DataCon only in IdDetails always felt a bit off.

Manuel

> Simon Peyton Jones via ghc-devs :
> 
> Andres, Richard, Stephanie
>  
> The more I think about our idea of introducing ConApp the more I like it.  I 
> wrote it up in a ticket
>  
> https://ghc.haskell.org/trac/ghc/ticket/12618 
> 
>  
> Simon
>  
> ___
> 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: macOS 10.12

[Manuel M T Chakravarty]

BTW, here is an alternative fix (against 7.10.3) that uses the minimum 
deployment target to determine whether to use the new ’clock_gettime()’ on 
macOS to avoid the problem I mentioned in my previous message:

  
https://github.com/mchakravarty/ghc/commit/da87a6551a528d51dfd4277c4468c57d5039ab59

(So far only tested by compiling against the macOS 10.12 SDK w/ Xcode 8 and 
running it on macOS 10.11.)

Manuel

> Manuel M T Chakravarty <c...@justtesting.org>:
> 
> Yes, it is exactly the issue Brandon references. Thanks.
> 
> I have got one concern with this fix, though: doesn’t that mean that a GHC 
> *build* on macOS 10.12 will not run on earlier versions of macOS?
> 
> In the meantime, I found,
> 
>   
> https://github.com/Homebrew/homebrew-core/issues/1957#issuecomment-226328001 
> <https://github.com/Homebrew/homebrew-core/issues/1957#issuecomment-226328001>
> 
> which explains the issue. Now, when you compile on macOS 10.12 with this fix, 
> GHC RTS will use ’clock_gettime’. However, that symbol is not available in 
> the system libraries of earlier version of macOS, which will lead to a dyld 
> failure when trying to run the executable.
> 
> In fact, given this is in the RTS, any Haskell program compiled with such as 
> build of GHC would be unable to run on macOS versions older than 10.12 
> (unless I am mistaken). Has this been considered?
> 
> Manuel
> 
>> Brandon Allbery <allber...@gmail.com <mailto:allber...@gmail.com>>:
>> 
>> fwiw I suspect this is 
>> http://git.haskell.org/ghc.git/commit/a0f1809742160ca0c07778f91f3e2a8ea147c0a4
>>  
>> <http://git.haskell.org/ghc.git/commit/a0f1809742160ca0c07778f91f3e2a8ea147c0a4>
>> 
>> On Thu, Jul 28, 2016 at 5:13 PM, Carter Schonwald 
>> <carter.schonw...@gmail.com <mailto:carter.schonw...@gmail.com>> wrote:
>> Could you share your error messages ?
>> 
>> 
>> On Wednesday, July 27, 2016, Manuel M T Chakravarty <c...@justtesting.org 
>> <mailto:c...@justtesting.org>> wrote:
>> Has anybody tried compiling GHC with the (beta) macOS 10.12 Sierra SDK? I 
>> just gave it a shot trying to compile GHC 7.8.3 and ran into a problem with 
>> GetTime.c in the RTS. (I haven’t tried GHC 8.0.1.)
>> 
>> Manuel
>> 
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org <>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>> 
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>> 
>> 
>> 
>> 
>> -- 
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com <mailto:allber...@gmail.com> 
>>  ballb...@sinenomine.net <mailto:ballb...@sinenomine.net>
>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net 
>> <http://sinenomine.net/>___
>> ghc-devs mailing list
>> ghc-devs@haskell.org <mailto: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

macOS 10.12

[Manuel M T Chakravarty]

Has anybody tried compiling GHC with the (beta) macOS 10.12 Sierra SDK? I just 
gave it a shot trying to compile GHC 7.8.3 and ran into a problem with 
GetTime.c in the RTS. (I haven’t tried GHC 8.0.1.)

Manuel

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

Re: Unicode, strings, and Show

[Manuel M T Chakravarty]

> Brandon Allbery <allber...@gmail.com>:
> 
> On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty <c...@justtesting.org 
> <mailto:c...@justtesting.org>> wrote:
> Firstly, we have
> 
>   isPrint :: Char -> Bool
> 
> Are you saying that this type is wrong?
> 
> Secondly, how often do you feed the output of ’show’ to ’read’ in another 
> locale versus how often is everybody whose whole life is outside of ASCII 
> (i.e., not anglo-centric people) bothered by this shortcoming? (*)
> 
> Moreover, the argument on the ticket was that changing the current 
> implementation would go against the standard. Now that I am saying, the 
> current implementation is not conforming to the standard, the standard 
> suddenly doesn’t seem to matter. Personally, I would say, when we wrote that 
> standard, we knew what we were doing.
> 
> The standard I am aware of is the Report, which deliberately limited the 
> output to the subset which is guaranteed to be usable in all locales. show 
> conforms to this; apparently people want it to *not* conform, and in a way 
> which requires some locale to become the One True Locale.

Where does it say that in the Report?

> isPrint is, as per the language Report, based on what Char is --- which is 
> Unicode codepoints. Using it for output — or for input, for that matter --- 
> gets you into locale issues because nobody anywhere guarantees that Unicode 
> codepoints that pass isPrint are representable in every locale. isPrint is 
> not the place to verify that a character can actually be displayed in the 
> current locale.

Yet, this is apparently what the report requires.

IMHO, it also makes sense. We have seen that either set up (the current or 
using ’isPrint’) has imperfections. However, getting \ is rarely 
helpful, whereas using ’isPrint’ is going to be helpful most of the time.

Manuel

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

Re: Unicode, strings, and Show

[Manuel M T Chakravarty]

Thank you for all the replies and especially pointing to this ticket.

I think, the discussion on this ticket is actually misleading and there is a 
simple solution, which I added as a comment.

Manuel

> Thomas Miedema :
> 
> 
> It would be great if someone could create a Trac ticket
> 
> Existing ticket: https://ghc.haskell.org/trac/ghc/ticket/11529 
>  ("Show instance of Char 
> should print literals for non-ascii printable charcters")

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

Unicode, strings, and Show

[Manuel M T Chakravarty]

Why are we doing this?

  GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
  Prelude> "文字"
  "\25991\23383"
  Prelude> 

After all, we don’t print ’a’ as ’\97’.

Manuel

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

Re: 7.10.3 fails to build with Xcode 7.3

[Manuel M T Chakravarty]

At HVR’s suggestion, I tried passing —with-nm=…/nm-classic to configure and 
that indeed fixes the problem, confirming that this is #11744.

A fix is simple in this case, check whether

  `xcode-select -p`/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic

or

  `xcode-select -p`/usr/bin/nm-classic

exists. If yes, use that instead of ’nm’; otherwise, use ’nm’ as usual. (You 
need to check for both, because the former is what comes with Xcode and the 
latter is what comes with the standalone command line tool package.)

Thanks,
Manuel

> Am 26 Mar 2016 um 20:53  schrieb Erik de Castro Lopo <mle...@mega-nerd.com>:
> 
> Manuel M T Chakravarty wrote:
> 
>> I just noticed that GHC 7.10.3 (latest release version) fails to build
>> with version 7.3 of Xcode (which just came out of beta). Maybe this is due to
>> 
>>  https://ghc.haskell.org/trac/ghc/ticket/11744
> 
> Yes, pretty sure that is the problem. I believe Carter (and maybe Luite)
> are working on it.
> 
> Erik
> -- 
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

7.10.3 fails to build with Xcode 7.3

[Manuel M T Chakravarty]

I just noticed that GHC 7.10.3 (latest release version) fails to build with 
version 7.3 of Xcode (which just came out of beta). Maybe this is due to

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

The problem manifests in the form of a SEGV when dll-split is invoked for the 
first time — specifically lldb has the following to say,

Process 17348 launched: '../lib/bin/dll-split' (x86_64)
Process 17348 stopped
* thread #1: tid = 0x4a821e, 0x000100e26357 
libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7, queue = 
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1e)
frame #0: 0x000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop 
+ 7
libHSrts-ghc7.10.3.dylib`stg_returnToStackTop:
->  0x100e26357 <+7>:  movq   0x1e(%rax), %rbx
0x100e2635b <+11>: movq   0x10(%rbx), %rbp
0x100e2635f <+15>: leaq   0x126(%rbx), %r15
0x100e26366 <+22>: movq   $0x0, 0x904(%r13)

Interestingly, the GHC 8.0.1-rc2 build does not exhibit that same failure. It 
does, however, fail to build due to an undefined symbol:

Undefined symbols for architecture x86_64:
  "_stg_sel_18_upd_info", referenced from:
  _sc9J_info in Monad.dyn_o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
make: *** [all] Error 2

(This may be unrelated to Xcode 7.3 and a known problem on OS X with that RC. I 
didn’t follow the 8.0.1-rc2 tickets in detail.)

As I assume that there will be no further 7.10 release, I am posting this here 
just to save others the time to track the problem down.

Manuel

PS: I wish I had the time to check GHC builds with Xcode beta releases, but 
alas, I usually don’t.___
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

[Manuel M T Chakravarty]

Two notable differences between Racket and the situation in Haskell is that (1) 
Racket has a full blown IDE to support the staged languages and (2) AFIK any 
Racket program in a simpler language is still a valid Racket program in a more 
advanced language. (The latter wouldn’t be the case with, e.g., a Prelude 
omitting type classes as you need to introduce new names —to avoid overloading— 
that are no longer valid in the full Prelude.)

Manuel

> Eric Seidel :
> 
> On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote:
>> I have tried a beginner's Prelude with people. I don't have a lot of data
>> because it was clearly a failure early on so I bailed them out into the
>> usual thing. It's just not worth it and it deprives them of the
>> preparedness to go write real Haskell code. That's not something I'm
>> willing to give up just so I can teach _less_.
> 
> Chris, have you written about your experiences teaching with a
> beginner's Prelude? I'd be quite interested to read about it, as (1) it
> seems like a natural thing to do and (2) the Racket folks seem to have
> had good success with their staged teaching languages.
> 
> In particular, I'm curious if your experience is in the context of
> teaching people with no experience programming at all, vs programming
> experience but no Haskell (or generally FP) experience. The Racket "How
> to Design Programs" curriculum seems very much geared towards absolute
> beginners, and that could be a relevant distinction.
> 
> Thanks!
> Eric
> ___
> 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: New type of ($) operator in GHC 8.0 is problematic

[Manuel M T Chakravarty]

Hi Takenobu,

> Takenobu Tani :
> 
> Hi Manuel,
> 
> > * Introduce the concept of overloading right away. People get that easily,
> > because they use overloaded arithmetic functions in math, too.
> > (Num and Show are the typical classes to explain it at.)
> > As an example, see how we do that in the first chapter of our new Haskell
> > tutorial: http://learn.hfm.io/first_steps.html 
> > 
> 
> This is straightforward and elegance tutorial! I like this.

You are very kind. Thank you.

> As you know, I'll share one point to list.
> 
> It's better to assume that "beginners are not only students in universities".
> Beginners are also engineers, hobbyist, teenager, your friends and your 
> family.
> Someone of them will touch to Haskell alone and learn with self study
> in a little bit of knowledge.
> 
> If they feel complex at first impression in their 1st week,
> they would go back before they realize beauty of Haskell.
> 
> Sometimes, I’m worried about it.

I do worry about the same thing. The Haskell ecosystem is very much geared 
towards experts and tinkerers (with laudable exceptions, such as, for example, 
the great work done by Chris Allen). Being an expert and tinkerer that didn’t 
worry me too much, but lately I am trying to make functional programming and 
Haskell accessible to a broader audience and it is an uphill battle. Even many 
professional software developers are put off even trying to install the 
toolchain. It is not that they wouldn’t been able to do it if they wanted. They 
just can’t be bothered because they are not convinced of the value of doing so 
at this stage — exactly as you are saying.

We should make it easier to get started, not harder.

Manuel

___
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

[Manuel M T Chakravarty]

> Christopher Allen :
> > Sorry for the mostly off-topic post, but since a beginner’s Prelude was 
> > mentioned here multiple times recently as a countermeasure to making the 
> > real Prelude more complicated, I just want to say, don’t put too much hope 
> > into a ”solution” you never actually tried.
> 
> I have tried a beginner's Prelude with people. I don't have a lot of data 
> because it was clearly a failure early on so I bailed them out into the usual 
> thing. It's just not worth it and it deprives them of the preparedness to go 
> write real Haskell code. That’s not something I'm willing to give up just so 
> I can teach _less_.

That is a valuable data point. Thanks!

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

[Manuel M T Chakravarty]

We have tried variations of this. This approach has two problems. 

(1) It’s generally easier to use something than to define it and, e.g., in the 
case of lists, Haskell ”magic” syntax is more intuitive to use.

For example, we use lists for a while before we define them. Even recursive 
definitions with pattern matching on [] and (:) are fairly easy to explain and 
for students to write quite a while before we discuss data declarations.

The build-in syntax for lists is convenient for using collections before 
properly explaining the full structure of terms and the concept of data 
constructors etc.

(2) We repeatedly found that any for-teaching-only definitions come with quite 
a bit of hidden costs.

At some point, you need to make the transition from the for-teaching-only 
definitions to the ”real” definitions. At this point, you invariably lose the 
students who managed to just get everything up to that point — i.e., those 
students that were struggling anyway. For us, alpha renaming is a trivial 
process. However, learners (and esp. the weaker learners) are rather tied to 
syntax and concrete names. They don’t deal well with alpha renaming.

Additionally, by introducing for-teaching-only definitions, you basically cut 
learners of from all the online resources that they could otherwise access. You 
probably won’t be able to match it up with a textbook unless you write one 
yourself. (Even if there is a book, this book then becomes the only resource.) 
This is an enormous disadvantage.

Manuel

> Joachim Breitner <m...@joachim-breitner.de>:
> Am Mittwoch, den 17.02.2016, 10:05 +1100 schrieb Manuel M T Chakravarty:
>> * Be careful in designing your exercises/assignments (esp early
>> ones), to make it unlikely for students to run into class related 
>> errors.
> 
> have you, or someone else, considered or tried to simply have students
> start with their own list data type, i.e.
> 
>data List a = Nil | Cons a (List a)
> 
> and have them implement the combinators they need themselves? Of
> course, you’d have to tell them to use names that do not clash with
> Prelude-exported, but this would avoid Foldable et. al. and be more
> educational (at the expense of maybe a slower progress, and not having
> nice syntax).
> 
> Similarly, one could teach them about the non-magicness of $ and side-
> step the issue with $ by having them write 
> 
>($$)   :: (a -> b) -> a -> b
>f $$ x =  f x
>infixr 0  $
> 
> (or whatever symbol they fancy).
> 
> 
> This would be akin to using a beginner’s prelude, only that the
> students would be writing it themselves, which IMHO is a big difference
> from an educational point of view.
> 
> 
> Greetings,
> Joachim
> 
> -- 
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
> 
> ___
> 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: New type of ($) operator in GHC 8.0 is problematic

[Manuel M T Chakravarty]

> Richard Eisenberg :
> 
> On Feb 16, 2016, at 5:35 AM, Ben Gamari  wrote:
>> Indeed. I'll just say that I envision that a beginner's prelude would be
>> for learning and nothing more. The goal is that it would be used in the
>> first dozen hours of picking up the language and nothing more.
>> 
>> I'd be interested to hear what Richard had in mind when he has time
>> again.
> 
> Yes, that's right. And, of course, it doesn't even need to be something 
> released with GHC.
> 
> I hope to have the opportunity to teach intro Haskell in the not-too-distant 
> future. Maybe even this coming fall. Though I have yet to look closely at 
> Chris's book, which will be one of the first things I do to prep, I suspect 
> I'll be writing a custom Prelude for my first few weeks of the class, 
> eliminating all type-classes. No Foldable, no Monoid, no Num. And then, by 
> week 3 or 4, bring all that back in.

As somebody who has taught Haskell to hordes of students (literally, 1000s), I 
am not at all convinced that this is going to be helpful. This is for the 
following reasons:

* Students understand the basic idea of overloading for Num, Show, etc easily 
(week 1 or 2). We actually tried both doing basic overloading very early or 
delaying it until later. The former worked much better.

* You are not in a position to explain Foldable and probably not Monoid by week 
3 or 4. So, either you need to have more than one beginner Prelude, delay 
overloading until much later (awkward), or we are really only talking about the 
impact of Show, Num, etc here.

* Changing things (i.e., one Prelude to another) always confuses some people — 
i.e., there is an intellectual cost to all this.

* Students will want to use Haskell on their own computers. Then, you need to 
make sure, they import the right Prelude and that they stop importing the 
beginner Prelude when you switch back to the normal one. A certain percentage 
of students will mess that up and be confused.

What we found works best is the following:

* Introduce the concept of overloading right away. People get that easily, 
because they use overloaded arithmetic functions in math, too. (Num and Show 
are the typical classes to explain it at.) As an example, see how we do that in 
the first chapter of our new Haskell tutorial: 
http://learn.hfm.io/first_steps.html

* Be careful in designing your exercises/assignments (esp early ones), to make 
it unlikely for students to run into class related errors.

Sorry for the mostly off-topic post, but since a beginner’s Prelude was 
mentioned here multiple times recently as a countermeasure to making the real 
Prelude more complicated, I just want to say, don’t put too much hope into a 
”solution” you never actually tried.

Manuel

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

Re: Reconsidering -Wall and -Wcompat

[Manuel M T Chakravarty]

Just as one data point, the Swift compiler is by default showing warnings about 
upcoming changes. Just like deprecation warnings, I do find that helpful. Based 
on that experience, including -Wcompat in -Wall seems like a good plan to me.

Manuel

> Ben Gamari :
> 
> tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
>   advance notice of coming library changes. We want to know whether
>   you think this set should be included in -Wall. See the Wiki [4]
>   and voice your opinion via the linked poll.
> 
> 
> Hello everyone,
> 
> GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
> the MonadFail proposal discussion [1] late last year. This warning set
> is intended to provide a means of informing users of coming changes in
> GHC's core libraries.
> 
> We would like to solicit the community's feedback on whether this new
> flag set should be implied by -Wall.
> 
> This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
> 
> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, given its current role we wouldn't want to add options to it
> that would cause undue burden for users.
> 
> So, we are asking for your opinion: should -Wcompat be implied by -Wall?
> You can find a more thorough description of the precise proposal on the
> GHC Wiki [4]. It would be very much appreciated if you could take a few
> minutes familiarize yourself with the options and provide your thoughts
> via this quick poll,
> 
>
> https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform
> 
> Feel free to discuss the issue further in this thread.
> 
> Thank you for sharing,
> 
> - Ben
> 
> 
> 
> [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html
> 
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html
> 
> [3] In a rather unscientific study, nearly half of packages on Hackage
>include it in ghc-options,
> 
>$ tar -xf ~/.cabal/packages/00-INDEX.tar
>$ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) 
> | xargs grep -L '\-Wall' | wc -l
>4352
>$ ls | wc -l 
>9347
>   
> [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

[Manuel M T Chakravarty]

There is currently an interesting discussion on Reddit on GHC compile times

  
https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/

I feel that this is a serious problem; so, it probably ought to be discussed 
here as well.

Manuel

___
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

[Manuel M T Chakravarty]

That makes a lot of sense to me.

Manuel

> Roman Cheplyaka :
> 
> On 02/05/2016 01:31 AM, Edward Z. Yang wrote:
>> I'm not really sure how you would change the type of 'id' based on
>> a language pragma.
>> 
>> How do people feel about a cosmetic fix, where we introduce a new
>> pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity
>> arguments/TYPE.  It's off by default but gets turned on by some
>> extensions like MagicHash (i.e. we only show levity if you have
>> enabled extensions where the distinction matters).
> 
> Yes, I am surprised this isn't the way it's been done. The levity
> arguments should totally be hidden unless requested explicitly.
> 
> I'd only expect this to be a ghc flag (-fshow-levity), not a language
> pragma, since it should only affect the way types are /shown/.
> 
> Roman
> 
> ___
> 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: New type of ($) operator in GHC 8.0 is problematic

[Manuel M T Chakravarty]

To be honest, I think, it is quite problematic if an obscure and untested 
language extension (sorry, but that’s what it is right now) bleeds through into 
supposedly simple standard functionality. The beauty of most of GHC’s language 
extensions is that you can ignore them until you need them.

Has this ever been discussed more widely? I expect that every single person 
teaching Haskell is going to be unhappy about it.

Manuel


> Richard Eisenberg :
> 
> I agree with everything that's been said in this thread, including the 
> unstated "that type for ($) is sure ugly".
> 
> Currently, saturated (a -> b) is like a language construct, and it has its 
> own typing rule, independent of the type of the type constructor (->). But 
> reading the comment that Ben linked to, I think that comment is out of date. 
> Now that we have levity polymorphism, we can probably to the Right Thing and 
> make the kind of (->) more flexible.
> 
> Richard
> 
> On Feb 4, 2016, at 3:27 PM, Ryan Scott  wrote:
> 
>>> My understanding was that the implicitly polymorphic levity, did (->) not 
>>> change because it's a type constructor?
>> 
>> The kind of (->) as GHCi reports it is technically correct. As a kind
>> constructor, (->) has precisely the kind * -> * -> *. What's special
>> about (->) is that when you have a saturated application of it, it
>> takes on a levity-polymorphic kind. For example, this:
>> 
>>   :k (->) Int# Int#
>> 
>> would yield a kind error, but
>> 
>>   :k Int# -> Int#
>> 
>> is okay. Now, if you want an explanation as to WHY that's the case, I
>> don't think I could give one, as I simply got this information from
>> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or
>> Richard Eisenberg could give a little insight here.
>> 
>>> Also does this encapsulate the implicit impredicativity of ($) for making 
>>> runST $ work? I don't presently see how it would.
>> 
>> You're right, the impredicativity hack is a completely different
>> thing. So while you won't be able to define your own ($) and be able
>> to (runST $ do ...), you can at least define your own ($) and have it
>> work with unlifted return types. :)
>> 
>> Ryan S.
>> -
>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds
>> 
>> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen  wrote:
>>> My understanding was that the implicitly polymorphic levity, did (->) not
>>> change because it's a type constructor?
>>> 
>>> Prelude> :info (->)
>>> data (->) a b -- Defined in ‘GHC.Prim’
>>> Prelude> :k (->)
>>> (->) :: * -> * -> *
>>> 
>>> Basically I'm asking why ($) changed and (->) did not when (->) had similar
>>> properties WRT * and #.
>>> 
>>> Also does this encapsulate the implicit impredicativity of ($) for making
>>> runST $ work? I don't presently see how it would.
>>> 
>>> Worry not about the book, we already hand-wave FTP effectively. One more
>>> type shouldn't change much.
>>> 
>>> Thank you very much for answering, this has been very helpful already :)
>>> 
>>> --- Chris
>>> 
>>> 
>>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott  wrote:
 
 Hi Chris,
 
 The change to ($)'s type is indeed intentional. The short answer is
 that ($)'s type prior to GHC 8.0 was lying a little bit. If you
 defined something like this:
 
   unwrapInt :: Int -> Int#
   unwrapInt (I# i) = i
 
 You could write an expression like (unwrapInt $ 42), and it would
 typecheck. But that technically shouldn't be happening, since ($) ::
 (a -> b) -> a -> b, and we all know that polymorphic types have to
 live in kind *. But if you look at unwrapInt :: Int -> Int#, the type
 Int# certainly doesn't live in *. So why is this happening?
 
 The long answer is that prior to GHC 8.0, in the type signature ($) ::
 (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind.
 OpenKind is an awful hack that allows both lifted (kind *) and
 unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42)
 typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg
 extended the type system with levity polymorphism [1] to indicate in
 the type signature where these kind of scenarios are happening.
 
 So in the "new" type signature for ($):
 
   ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b
 
 The type b can either live in kind * (which is now a synonym for TYPE
 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is
 indicated by the fact that TYPE w is polymorphic in its levity type w.
 
 Truth be told, there aren't that many Haskell functions that actually
 levity polymorphic, since normally having an argument type that could
 live in either * or # would wreak havoc with the RTS (otherwise, how
 would it know if it's dealing with a pointer or a value on the
 stack?). But as it turns 

Re: Birthday greetings

[Manuel M T Chakravarty]

Dear Simon!

Happy Birthday!!! :)

Thank you so much for all the incredible work that you have done and the 
guidance that you have provided over the many years. I personally have profited 
enormously from your kindness, and I am very grateful for that. In addition, 
your unwavering enthusiasm for and work on GHC, in particular, and functional 
programming, in general, have always been a great inspiration.

Thank you very much and all the best for this and many more years!!
Manuel

PS: I have declared email defeat long ago. I am impressed that you could keep 
up with it for so long.

> Simon Peyton Jones :
> 
> Dear GHC devs (all 600+ of you),
> 
> It’s my birthday (well it was a few minutes ago, but I became distracted by 
> #11379).   I am 58.  GHC is alive and well and, happily, so am I.
> 
> However, of late I have found that my GHC inbox, which I used to be able to 
> keep under control, just grows and grows.  Mostly this is good; it reflects 
> the fact that GHC has lots of users, that they vigorously expand up to (and 
> often well beyond) the limits of what GHC can do, and that increasingly GHC a 
> lot of developers contributing actively to its code base. 
> 
> But it has its downsides.   I used to be able to keep up with the Trac and 
> email traffic.  Trusty techniques like “delete anything mentioning ‘dynamic 
> linking’ or ‘Unicode’” would cut the traffic in half.   But that doesn’t work 
> any more.   Too many interesting things are happening.
> 
> So this email is to say three things:
> 
> · First, thank you to the increasingly large number of you who are 
> contributing actively to GHC’s development.   GHC is a big system, and no one 
> person can be on top of all of it.   GHC no longer depends on one of two 
> people: it depends on all of you.  You know who you are – thank you.
> 
> · Second, apologies to anyone who is stuck waiting for me.   Although 
> there are large chunks of GHC that I know little about, there are other parts 
> that are dear to my heart: the renamer, typechecker, Core, optimisation, and 
> so on.  I write code most days and enjoy it.  So I do want to continue to 
> play a very active supporting and reviewing role, as well as authoring, in 
> these parts.  But I’m conscious that doing so puts me in a lot of critical 
> paths.
> 
> Here’s a suggestion: if you are blocked on something from me, email me 
> directly.   By all means copy ghc-devs if you want others in the 
> conversation, but make it clear that you need my input.  That’ll work better 
> than putting up a Phab review, or a Trac comment, and hoping I’ll see it.  I 
> probably will, but it won’t stick out from other 20 Phab reviews that I would 
> like to do.  I don’t promise to turn everything around fast, but it’ll 
> increase the chances!
> 
> · Third, in a vain attempt to at least keep some kind of handle on 
> the state of play, I keep an ill-organised page of tickets that I’m 
> interested in .  A 
> cursory glance will confirm that there is zero chance that I will attend to 
> them all.So please do pick up some of them and dig in.  Not many are 
> trivial; most require some investigation, some design work, some discussion 
> of alternatives, etc.  But most of them would benefit from love and 
> attention.  If you are looking for suggestions for things to do, that might 
> be a good place to start.
> 
> Thanks!
> 
> Simon
> 
>  
> 
>  
> 
> ___
> 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: ok to do reformatting commits?

[Manuel M T Chakravarty]

I used to be a 80 chars kind of guy, but working with Simon on the type 
checker, I did get into the habit of using 120. It has stuck with me. 
Especially in Haskell, there is a lot of value in that additional space, 
especially if you like to have descriptive identifiers.

(In statement-oriented languages, 80 chars are far less limiting.)

Manuel

> Simon Peyton Jones :
> 
> I don’t have a strong view but like Richard I find 80 chars limiting.
> 
> I agree that we should resolve this and write down the result on the coding 
> style page
> 
> Simon
> 
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Richard Eisenberg
> |  Sent: 25 November 2015 03:23
> |  To: Evan Laforge 
> |  Cc: ghc-devs@haskell.org
> |  Subject: Re: ok to do reformatting commits?
> |  
> |  Thanks for volunteering to do this work, but I'm afraid now is a
> |  terrible time to do it. I know of three significant patches that are
> |  about to be committed, and your reformatting would cause quite a few
> |  merge conflicts. If there is a lull between a feature freeze and a
> |  ghc-8.0 fork, that would be the ideal time, to my mind.
> |  
> |  That said, I remain unconvinced that a rigid commitment to 80-char
> |  lines is in our best interest. My personal vote is to continue to have
> |  80 characters as a guideline but to keep the current practice of
> |  allowing programmer discretion.
> |  
> |  Richard
> |  
> |  On Nov 24, 2015, at 10:14 PM, Evan Laforge  wrote:
> |  
> |  > When I was doing a recent patch, I was annoyed by lint errors about
> |  >> 80 lines when I was just conforming to the existing style.  To
> |  avoid
> |  > cluttering my commit with unrelated changes, I decided to fix the
> |  > lints in a formatting-only commit afterwards.  Looking in the
> |  > archives, I see there was some recent discussion about this, but I
> |  > didn't see anyone volunteering to just go wrap a bunch of files, or
> |  > saying that they didn't want anyone to do this (usual reason being
> |  > cluttering the history, which as a rationale to not do formatting
> |  only
> |  > changes never sat too well with me).
> |  >
> |  > Would anyone mind if I went and wrapped a bunch of files, say
> |  > typecheck/*.hs?  This seems simpler than either constant hassling
> |  from
> |  > arc or coming up with more elaborate rules for arc.  I would have to
> |  > make some formatting decisions, so likely to some eyes I would be
> |  > messing some stuff up, but since there's no real standard that is
> |  > probably unavoidable.
> |  > ___
> |  > 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%7csi
> |  >
> |  monpj%40064d.mgd.microsoft.com%7c27ba726d65bd49df735d08d2f547c211%7c72
> |  >
> |  f988bf86f141af91ab2d7cd011db47%7c1=iGQx%2bYYoG%2bv7xCd6Su%2bzN1L
> |  > gIjx5FxEqmWOSpIbLnjY%3d
> |  
> |  ___
> |  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%7c27ba726d65bd49d
> |  f735d08d2f547c211%7c72f988bf86f141af91ab2d7cd011db47%7c1=iGQx%2b
> |  YYoG%2bv7xCd6Su%2bzN1LgIjx5FxEqmWOSpIbLnjY%3d
> ___
> 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: Remote GHCi

[Manuel M T Chakravarty]

Hi Simon,

Sounds great! 

This may very well what you have got in mind anyway, but I could imagine to run 
the interpreter on a different thread in the -fno-external-interpreter case and 
arrange communication through the same messaging API that you outlined for the 
seperate-process interpreter. Then, the essential difference between the two 
modes would be whether memory is shared or not (i.e., multithreading vs 
multi-process).

Cheers,
Manuel

> Simon Marlow <marlo...@gmail.com>:
> 
> Hi Manuel,
> 
> Thanks for the detailed reply, I have a much better understanding of your 
> requirements now.
> 
> I'm going to support both models of running interpreted code.  The current 
> plan is to have a flag, -fexternal-interpreter, which GHC will use by default 
> when running Template Haskell during compilation, and perhaps for GHCi, but 
> for compatibility with applications like yours I'll probably leave it off for 
> GHC API users.
> 
> There's really no downside to doing this, it's not much more complicated than 
> implementing the separate-process model.
> 
> Cheers,
> Simon
> 
> On 21/11/2015 03:38, Manuel M T Chakravarty wrote:
>>> Simon Marlow <marlo...@gmail.com>:
>>> On 18/11/2015 01:41, Manuel M T Chakravarty wrote:
>>>> Hi Simon,
>>>> 
>>>> While this is an interesting proposal, Haskell for Mac strongly
>>>> relies on running interpreted code in the same process. I’m using
>>>> ’dynCompileExpr’ as well as ’hscStmtWithLocation’ and some other
>>>> stuff.
>>> 
>>> Let me say first of all that I'm not going to remove anything, so there's 
>>> no need to worry.  But I'd like to explore exactly what you need, so that 
>>> we can see whether there's a way to accommodate it with a separate-process 
>>> implementation.
>>> 
>>> hscStmtWithLocation is part of the core GHCi functionality, it is 
>>> definitely supported.  It has a slightly different signature:
>>> 
>>> hscStmtWithLocation :: HscEnv
>>>-> String -- ^ The statement
>>>-> String -- ^ The source
>>>-> Int-- ^ Starting line
>>>-> IO ( Maybe ([Id]
>>>  , RemoteHValue {- IO [HValue] -}
>>>  , FixityEnv))
>>> 
>>> RemoteHValue is a reference to a value in the interpreter's context. These 
>>> have to be evaluated via an explicit API, rather than just unsafeCoercing 
>>> Value as we do now.  (this is not strictly speaking part of the GHC API, so 
>>> a separate but interesting question is: why did you need to use this 
>>> directly, and what should we add to the GHC API?)
>> 
>> The GHC API basically assumes that the ”result” of statement execution is 
>> the *side-effect* of printing the result to stdout. This is not sufficient 
>> for an interactive graphical environment as
>> 
>> (1) I want to have the result (even if it is a string) separate from 
>> anything else interpreted code execution writes to stdout. (In Haskell for 
>> Mac, these things are displayed in different places.)
>> 
>> (2) I want results that are not just strings. For example, a result (of 
>> running Haskell code) may be a ForeignPtr to a C-land data structure 
>> representing an image (e.g., an in-memory representation of a PNG image 
>> rendered by Diagrams).
>> 
>> For the latter, I’m actually using `compileExpr`, then `unsafeCoerce` the 
>> `hValue` into `IO (ForeignPtr ())` and `try` that (to also catch any 
>> exceptions). When this code runs, in some cases, it calls back and forth 
>> between interpreted Haskell code and the host application using the FFI.
>> 
>>> I believe that many uses of dynCompileExpr can be changed so that the code 
>>> using the resulting value is moved into the interpreter’s context, and then 
>>> there’s no problem.
>> 
>> This is difficult in my case, because the resulting value is used in the GUI 
>> code written in Swift. Code running in a different process cannot call the 
>> Cocoa framework methods for the GUI of the main process.
>> 
>>>> This is quite crucial for some of the interactive
>>>> functionality. Imagine a game where the game engine is in Swift
>>>> linked into the main application and the game logic is in
>>>> *interpreted* Haskell code. The engine calls into the Haskell code
>>>> multiple times per frame of the animation and for all
>>>> keyboard/mouse/etc input (using StablePtr and Forei

Re: Remote GHCi

[Manuel M T Chakravarty]

> Simon Marlow <marlo...@gmail.com>:
> On 18/11/2015 01:41, Manuel M T Chakravarty wrote:
>> Hi Simon,
>> 
>> While this is an interesting proposal, Haskell for Mac strongly
>> relies on running interpreted code in the same process. I’m using
>> ’dynCompileExpr’ as well as ’hscStmtWithLocation’ and some other
>> stuff.
> 
> Let me say first of all that I'm not going to remove anything, so there's no 
> need to worry.  But I'd like to explore exactly what you need, so that we can 
> see whether there's a way to accommodate it with a separate-process 
> implementation.
> 
> hscStmtWithLocation is part of the core GHCi functionality, it is definitely 
> supported.  It has a slightly different signature:
> 
> hscStmtWithLocation :: HscEnv
>-> String -- ^ The statement
>-> String -- ^ The source
>-> Int-- ^ Starting line
>-> IO ( Maybe ([Id]
>  , RemoteHValue {- IO [HValue] -}
>  , FixityEnv))
> 
> RemoteHValue is a reference to a value in the interpreter's context. These 
> have to be evaluated via an explicit API, rather than just unsafeCoercing 
> Value as we do now.  (this is not strictly speaking part of the GHC API, so a 
> separate but interesting question is: why did you need to use this directly, 
> and what should we add to the GHC API?)

The GHC API basically assumes that the ”result” of statement execution is the 
*side-effect* of printing the result to stdout. This is not sufficient for an 
interactive graphical environment as

(1) I want to have the result (even if it is a string) separate from anything 
else interpreted code execution writes to stdout. (In Haskell for Mac, these 
things are displayed in different places.)

(2) I want results that are not just strings. For example, a result (of running 
Haskell code) may be a ForeignPtr to a C-land data structure representing an 
image (e.g., an in-memory representation of a PNG image rendered by Diagrams).

For the latter, I’m actually using `compileExpr`, then `unsafeCoerce` the 
`hValue` into `IO (ForeignPtr ())` and `try` that (to also catch any 
exceptions). When this code runs, in some cases, it calls back and forth 
between interpreted Haskell code and the host application using the FFI.

> I believe that many uses of dynCompileExpr can be changed so that the code 
> using the resulting value is moved into the interpreter’s context, and then 
> there’s no problem.

This is difficult in my case, because the resulting value is used in the GUI 
code written in Swift. Code running in a different process cannot call the 
Cocoa framework methods for the GUI of the main process.

>> This is quite crucial for some of the interactive
>> functionality. Imagine a game where the game engine is in Swift
>> linked into the main application and the game logic is in
>> *interpreted* Haskell code. The engine calls into the Haskell code
>> multiple times per frame of the animation and for all
>> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct
>> the scene graph across the Swift and Haskell heap).
> 
> So my question is, why wouldn't you run the whole game engine in the 
> interpreter's context?  That’s what would happen if you were to load the 
> program into GHCi and run it.

On a fundamental level: The game engine runs on OpenGL. If it is in a different 
process, it cannot access the OpenGL context of the main process (which it 
needs to do to render into a specific view of a specific window of the main 
process).

In practice, it is not just an OpenGL problem as I’m using a framework called 
SpriteKit with its own event and rendering loop that in turn uses OpenGL for 
the actual rendering. It does a lot of things behind the scenes (which makes it 
convenient to use), which requires you to be careful which threads you use to 
execute some operations. Running in an entire different process is surely going 
to break things.

>   Directly calling back and forth between the client of the GHC API and the 
> program being interpreted is arguably a strange thing to do, and it’s kind of 
> accidental that we allow it.

I understand that, but I also think that it is an artefact of Haskell mostly 
being used in a command line program set up. I don’t think, it is just by 
chance that the IHaskell people do some quite similar things to at least some 
of what I’m doing. Once you want a more interactive experience, call patterns 
get more complicated.

>> I actually also might have a use for the architecture that you are
>> proposing. However, I really would like to keep the ability to, at
>> least, optionally run interpreted code in the same process (without
>> profiling etc). Do you think we could 

Re: [ANNOUNCE] 7.10.3 release candidate 3

[Manuel M T Chakravarty]

> Ben Gamari :

> Lastly, I'd like to take a moment to acknowledge Futureice [2], who have
> donated a brand new Mac Mini for use by GHC developers to help support
> this platform. Their generosity is the reason we are able to offer OS X
> builds to you today.
> 
> Many thanks to Futureice for this donation!

> [2] http://futurice.com/

Wow — that is generous! Many thanks to them!

Manuel

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

Re: Remote GHCi

[Manuel M T Chakravarty]

Hi Simon,

While this is an interesting proposal, Haskell for Mac strongly relies on 
running interpreted code in the same process. I’m using ’dynCompileExpr’ as 
well as ’hscStmtWithLocation’ and some other stuff. This is quite crucial for 
some of the interactive functionality. Imagine a game where the game engine is 
in Swift linked into the main application and the game logic is in 
*interpreted* Haskell code. The engine calls into the Haskell code multiple 
times per frame of the animation and for all keyboard/mouse/etc input (using 
StablePtr and ForeignPtr to construct the scene graph across the Swift and 
Haskell heap).

This is an intricate dance (e.g, exceptions in either language don’t play nice 
across the language boundary and using multi-threading in both worlds adds to 
the fun), but it allows for a very nice interactive and responsive user 
experience.

I actually also might have a use for the architecture that you are proposing. 
However, I really would like to keep the ability to, at least, optionally run 
interpreted code in the same process (without profiling etc). Do you think we 
could have both?

Cheers,
Manuel

> Simon Marlow :
> 
> Hi folks - I've been thinking about changing the way we run interpreted code 
> so that it would be run in a separate process.  It turns out this has quite a 
> few benefits, and would let us kill some of the really awkward hacks we have 
> in GHC to work around problems that arise because we're running interpreted 
> code and the compiler on the same runtime.
> 
> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
> 
> I'd be interested to hear if anyone has any thoughts around this, 
> particularly if doing this would make your life difficult in some way. Are 
> people relying on dynCompileExpr for anything?
> 
> Cheers,
> Simon
> ___
> 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: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang

[Manuel M T Chakravarty]

Apple has started to move away from OpenSSL for quite a while. This post 
summarises it quite nicely

  
http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-technote-about-openssl-on

In recent times, you could add as a reason for avoiding OpenSSL its shaky 
security track record. (Heartbleed anyone).

Manuel

> Carter Schonwald :
> 
> My understanding is that they now use libre ssl. So definitely not OpenSSL.  
> If you want open ssl instead you need to install it via brew or the like 
> 
> On Monday, November 16, 2015, George Colpitts  > wrote:
> Sorry, it seems that this is a known problem with Mac OS 10.11. From 
> https://github.com/phonohawk/HsOpenSSL/issues/41 
> 
> 
> openssl libs and includes are not included in OS X 10.11. I'm not sure if 
> this is permanent or just an effect of the beta release but we should keep 
> our eye on it so when 10.11 is released, HsOpenSSL will work smoothly.
> 
> 
> On Mon, Nov 16, 2015 at 9:14 AM, George Colpitts  > wrote:
> 
> find /usr/local -iname asn1.h
> /usr/local/Cellar/nettle/2.7.1/include/nettle/asn1.h
> /usr/local/Cellar/openssl/1.0.1j/include/openssl/asn1.h
> /usr/local/Cellar/openssl/1.0.1j_1/include/openssl/asn1.h
> /usr/local/Cellar/openssl/1.0.1l/include/openssl/asn1.h
> /usr/local/Cellar/openssl/1.0.2a-1/include/openssl/asn1.h
> /usr/local/Cellar/openssl/1.0.2c/include/openssl/asn1.h
> /usr/local/Cellar/openssl/1.0.2d_1/include/openssl/asn1.h
> 
> ​As you might guess​ from the above I've successfully installed this in the 
> past with other versions of ghc :)
> 
> Thanks for all your help here
> 
> Cheers
> George
> 
> 
> On Mon, Nov 16, 2015 at 8:52 AM, Ben Gamari  > wrote:
> George Colpitts  > writes:
> 
> > As I mentioned above from brew:
> >
> > $ brew upgrade openssl
> > brew upgrade openssl
> > Error: openssl 1.0.2d_1 already installed
> >
> I see. Does the file in question exist?
> 
> What does
> 
> find /usr/local -iname asn1.h
> 
> say?
> 
> 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: Context for typed holes

[Manuel M T Chakravarty]

I think, this is a good point. Maybe you should make a ticket for it.

Manuel

> David Feuer :
> 
> Unless something has changed really recently that I've missed, the typed 
> holes messages are missing some really important information: instance 
> information for types in scope. When I am trying to fill in a hole, I look to 
> the "relevant bindings" to show me what pieces I have available to use. Those 
> pieces don't include contexts! Is there something fundamentally hard about 
> adding this information? I'd only want instance information for type 
> variables--providing it for concrete types would make too much noise. I'd 
> also want information on equality constraints, of course.
> 
> ___
> 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: GHC and LLVM

[Manuel M T Chakravarty]

Hi Erik,

That sounds great. Can your Jenkins instance maybe also push the reports to one 
of the GHC lists, so everybody can see what the state of play is?

Thanks,
Manuel

> Erik de Castro Lopo :
> 
> Hi all,
> 
> As some of you may have noticed the LLVM requirements for GHC HEAD
> has just switched from version 3.6 to 3.7. This was mainly to support
> Arm64 (aka AArch64 aka Armv8-a), for which llvm-3.6 was badly broken.
> 
> Since figuring out what needed to change from 3.6 to 3.7 was rather
> painful, I decided to set up a small project to help us GHC devs
> keep up with what happens in the LLVM dev world.
> 
>  http://github.com/erikd/ghc-llvm-next/
> 
> The project is a build script (actually a Makefile) and a set of
> patches) which does the followiing:
> 
> * clones/updates LLVM from git, builds it and installs it locally
> * clones/updates GHC from git
> * applies patches git GHC so that GHC builds against the locally
> build LLVM tools.
> * builds GHC and then runs the testsuite
> 
> I plan on running the above build on a daily basis in my own 
> personal Jenkins instance in order to track changes in GHC and
> LLVM.
> 
> Others are free to do the same and I'm happy to take pull requests.
> This project may also be interesting or useful for people testing
> out up-coming LLVM features with GHC.
> 
> Cheers,
> Erik
> -- 
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Applicative Comprehensions

[Manuel M T Chakravarty]

I certainly second that!

Manuel

> Joachim Breitner :
> 
> Hi,
> 
> Am Montag, den 12.10.2015, 08:09 + schrieb David A Roberts:
>> I understand that comprehensions tend not to be used much in
>> idiomatic Haskell,
> 
> quite contrary! I use them extensively in real-world-projects, and I
> claim to write idomatic code :-)
> 
> Greetings,
> Joachim
> 
> 
> -- 
> Joachim “nomeata” Breitner
> m...@joachim-breitner.de • http://www.joachim-breitner.de/
> Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
> Debian Developer: nome...@debian.org
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://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: ArrayArrays

[Manuel M T Chakravarty]

That’s an interesting idea.

Manuel

 Edward Kmett ekm...@gmail.com:
 
 Would it be possible to add unsafe primops to add Array# and SmallArray# 
 entries to an ArrayArray#? The fact that the ArrayArray# entries are all 
 directly unlifted avoiding a level of indirection for the containing 
 structure is amazing, but I can only currently use it if my leaf level data 
 can be 100% unboxed and distributed among ByteArray#s. It'd be nice to be 
 able to have the ability to put SmallArray# a stuff down at the leaves to 
 hold lifted contents.
 
 I accept fully that if I name the wrong type when I go to access one of the 
 fields it'll lie to me, but I suppose it'd do that if i tried to use one of 
 the members that held a nested ArrayArray# as a ByteArray# anyways, so it 
 isn't like there is a safety story preventing this.
 
 I've been hunting for ways to try to kill the indirection problems I get with 
 Haskell and mutable structures, and I could shoehorn a number of them into 
 ArrayArrays if this worked.
 
 Right now I'm stuck paying for 2 or 3 levels of unnecessary indirection 
 compared to c/java and this could reduce that pain to just 1 level of 
 unnecessary indirection.
 
 -Edward
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: wither the Platform

[Manuel M T Chakravarty]

 Gershom B gersh...@gmail.com:
 
 On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty 
 (c...@cse.unsw.edu.au) wrote:
 
 Look. I guess, I count as a power user ;) I rarely use sandboxes. They are 
 great for a particular  
 type of use, but you can do many things quite happily without them. (Ask 
 SimonPJ; I reckon  
 he doesn’t use sandboxes either.)
 
 Ironically, the only time I have had to use a sandbox was in doing work on 
 the new Haskell homepage (it is written in Yesod). In fact, that was 
 insufficient for some reason and I had to install hsenv as well and use that 
 for an even “stronger” sandbox. As I have said, I also install the platform 
 whenever possible. Believe me, you are preaching to the choir!

Then, I don’t understand why the Platform isn’t the recommended this is what 
you install if you don’t know better on the homepage.

 The mistake here is to try to make this a one-size-fits all. I honestly 
 don’t care about  
 a platform that is ideal for everybody. I want something that I can point 
 newbies at that  
 makes them happy quickly. That needs to be one download with all the 
 packages that you  
 need to get going included.
 ..
 Well, we have got people who want to learn Haskell now and who use Haskell 
 as part of their 
 coursework now. Why make them wait for future work which will probably take 
 longer than 
 planned, needs to be rolled out, etc?
 
 I do not understand this. The platform still exists, is still great, is not 
 going anywhere, and as far as I can tell, is on track to become even better. 
 You can point people at https://www.haskell.org/platform/ or you can point 
 them at downloads.haskell.org which links to there or you can point them at 
 www.haskell.org and tell them “the downloads page gives you options, pick the 
 platform option.” Nobody who wants to use the platform must wait for anything.
 
 Nobody has taken anything from you, or anyone else. Nobody wants to take 
 anything from you, or anyone else.

I know, but look at the subject of this message (and the original post in this 
thread). Mark’s questions was —as I read it— do we still need the platform. 
Then, lots of power users jumped up and down criticising the flaws in the 
platform and why other approaches are better.

To which I say, other approaches are better for you (plural)[1], but not to a 
large class of novices. That is all.

Also, to reiterate, I’m arguing with you because you replied to my message. I 
definitely do appreciate all the effort you (and others) are putting into the 
homepage and infrastructure.

Manuel

[1] English is such an awkward language :P

 We just want to recognize that this other set of users — those coming from 
 other languages, and wanting to “from the gate” install large sets of 
 dependencies — this set of users has grown and is growing and if we don’t 
 want them to become frustrated and bounce off Haskell, then we need to 
 provide resources for them too, and steer them to things that meet _their_ 
 needs as well. They are not lucky enough to be in your class and be guided by 
 an instructor.
 
 If you want to patch the downloads page so that it more clearly highlights 
 the platform option or makes clear that if you want to be a “power user” and 
 manage lots of dependencies with abandon you may want the minimal installers, 
 and if you want “a good, wide-ranging set of defaults to experiment and learn 
 with” then you want the platform, or some other wording that is perhaps 
 clearer, or anything at all like that, then there is again a ticket on the 
 github homepage to improve the language, and pull requests are welcome. The 
 compromise wording on the page now is just that: a compromise. I don’t even 
 claim it to be a great one, just what was settled on. If you (or anyone) can 
 improve it to present both sorts of installers and the tradeoffs more clearly 
 and more simply, please do!
 
 There are different types of beginners, and meeting all their needs (as well 
 as the needs of long-timers of various stripes, etc) all at once is a tricky 
 task. Again, the main advantage that students have is that they have 
 instructors who can guide them in what they recommend to download, how to get 
 started, etc. So, for the moment, I would argue that students are not the 
 most fundamental target audience for that snippet of text on the downloads 
 page. But, that does not mean the language cannot be better for students too. 
 And I would very much like it to be!
 
 Beyond that I don’t feel we’re discussing anything as metaphysical as 
 flexibility or simplicity. And I don’t feel my own preferences are 
 necessarily better or worse than others — I just want two things, as do we 
 all I think. A) To have the best possible toolsets available for all types of 
 users in all possible development setups, and B) To somehow condense the core 
 of that information into an easily digestible form to help steer visitors to 
 the Haskell homepage to the setup

Re: wither the Platform

[Manuel M T Chakravarty]

Simon Peyton Jones simo...@microsoft.com:
 So that was the plan.  I still think it’s a good plan.  But it clearly is not 
 working well, and I’m hazy about why.  Possible reasons:
 
 · Possible diagnosis 1.   Installing HP somehow screws up the world 
 for power users, or for a beginner who grows into a power user.  Surely we 
 can fix this!  Installing HP should not get in the way.  I suppose that, even 
 if installing HP doesn’t get in the way, it might be a waste of internet 
 bandwidth and disk space for some power users.  But that is a smaller problem.
 
 · Possible diagnosis 2.  We have not shared the plan as a community; 
 that is, we have focused lots of attention on GHC releases, and little 
 attention on HP releases.  It should be the other way around. 
 

I’d say, both. 

Re 1, a big part of the problem is the whole cabal, package dependency and 
versioning morass. 

Re 2, I think, there are multiple factors. The delays in putting out the HP (as 
previously mentioned). Power users reading GHC Status reports and wanting to 
get the goodies as quickly as possible. The HP just being quite a bit of hard 
work people like to avoid.

Manuel

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

Re: Delaying 7.10?

[Manuel M T Chakravarty]

A safety issue of that magnitude is a valid reason to hold up a release at the 
last minute IMHO.

Manuel

 Simon Peyton Jones simo...@microsoft.com:
 
 Friends
 
 In a call with a bunch of type hackers, we were discussing
 
https://ghc.haskell.org/trac/ghc/ticket/9858 
 https://ghc.haskell.org/trac/ghc/ticket/9858
 This is a pretty serious bug.  It allows a malicious person to construct his 
 own unsafeCoerce, and so completely subverts Safe Haskell.
 
 Actually there are two bugs (see comment:19).  The first is easily fixed.  
 But the second is not.
 
 We explored various quick fixes, but the real solution is not far out of 
 reach.  It amounts to this:
 
 ·Every data type is automatically in Typeable.  No need to say 
 “deriving(Typeable)” or “AutoDeriveTypeable” (which would become deprecated)
 
 ·In implementation terms, the constraint solver treats Typeable 
 specially, much as it already treats Coercible specially.
 
 It’s not a huge job.  It’d probably take a couple of days of implementation 
 work, and some time for shaking out bugs and consequential changes.  The 
 biggest thing might be simply working out implementation design choices.  
 (For example, there is a modest code-size cost to making everything Typeable, 
 esp because that includes the data constructors of the type (which can be 
 used in types, with DataKinds).  Does that matter?  Should we provide a way 
 to suppress it?  If so, we’d also need a way to express whether or not the 
 Typable instance exists in the interface file.)  
 
 But it is a substantial change that will touch a lot of lines of code.  
 Moreover, someone has to do it, and Iavor (who heroically volunteered) 
 happens to be travelling next week.
 
 So it’s really not the kind of thing we would usually do after RC2.
 
 But (a) it’s serious and, as it happens, (b) there is also the BBP Prelude 
 debate going on. 
 
 Hence the question: should we simply delay 7.10  by, say, a month?  After 
 all, the timetable is up to us.  Doing so might give a bit more breathing 
 space to the BBP debate, which might allow time for reflection and/or 
 implementation of modest features to help the transition.  (I know that 
 several are under discussion.)  Plus, anyone waiting for 7.10 can simply use 
 RC2, which is pretty good.
 
 Would that be a relief to the BBP debate?  Or any other opinions.
 
 Simon
 
 PS: I know, I know: there is endless pressure to delay releases to get stuff 
 in.  If we give in to that pressure, we never make a release.  But we should 
 know when to break our own rules.  Perhaps this is such an occasion.
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org mailto:ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs 
 http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: vectorisation code?

[Manuel M T Chakravarty]

The way I see it, the main cost of keeping DPH around is to handle breakages 
such as that with vector. I can’t promise to address those in a timely manner, 
which is why I agreed to disable/remove DPH.

However, as Geoff stepped forward, this issue is solved. As for the overhead in 
compile time etc, I don’t think, it is that much of a deal. During development, 
most compiles runs are incremental anyway.

Concerning handling of the DPH libraries, since Austin was looking at putting 
some love into the —slow test suite. Maybe we could re-active the DPH tests, 
and hence, DPH library builds for ”slow” testing. The DPH libraries have shaken 
out many GHC bugs in the past. Adding them to ”slow” would ensure they don’t 
bit rot, improve the test suite, but keep it out of the main path for dev 
builds.

Manuel

 Geoffrey Mainland mainl...@apeiron.net:
 
 On 01/22/2015 10:50 AM, Herbert Valerio Riedel wrote:
 On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote:
 The current situation is that DPH is not being built or maintained at
 all. Given this state of affairs, it is hard to justify keeping it
 around---DPH is just bitrotting.
 
 I am proposing that we reconnect it to the build and keep it building,
 putting it in minimal maintenance mode. 
 Ok, but how do we avoid issues like
 
 http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/
 
 in the future then? DPH became painful back then, because we didn't know
 what to do with 'vector' (which as a package at the time also suffered
 from neglect of maintainership)
 
 
 Cheers,
  hvr
 
 
 That's part of minimal maintenance mode. Yes, keeping DPH will impose
 some burden. I am not pretending that keeping DPH imposes no cost, but
 instead asking what cost we are willing to pay to keep DPH
 working---maybe the answer is none.
 
 As for the particular issue you mentioned, I patched DPH to fix
 compatibility with the new vector. Those changes have been in the tree
 for some time, but DPH was never reconnected to the build, so it has
 bitrotted again.
 
 Note that vector *also* no longer builds with the other libraries in the
 tree, so if we excise DPH, we should excise vector.
 
 I am willing to put some effort into fixing these sorts of problems when
 they come up. That may still impose too much burden on the other developers.
 
 Geoff
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: vectorisation code?

[Manuel M T Chakravarty]

Thanks for the offer, Geoff.

Under these circumstances, I would also very much prefer for Geoff getting the 
code in order and leaving it in GHC.

Manuel

 Geoffrey Mainland mainl...@apeiron.net:
 
 I'm sorry I'm a bit late to the game here, but there is also the option
 of reconnecting DPH to the build.
 
 When I patched DPH for the new version of the vector library, I did not
 perform this step---now I'm sorry I didn't.
 
 I am willing to get DPH in working order again---I believe the required
 work will be minimal. However, that only makes sense if we 1) re-enable
 DPH in the nightly builds (and also by default for validate?), and 2)
 folks will not object too strenuously to having DPH stick around.
 
 My fear is that without making it part of the nightly builds,
 accumulated bitrot will make it extremely difficult to ever re-integrate
 DPH. I would hate to see that happen.
 
 Geoff
 
 On 01/21/2015 04:11 PM, Simon Peyton Jones wrote:
 
 I’ve had a chat to Manuel.  He is content for us to remove DPH code
 altogether (not just CPP/comment it out), provided we are careful to
 signpost what has gone and how to get it back.
 
 
 
 I am no Git expert, so can I leave it to you guys to work out what to
 do?  The specification is:
 
 ·It should be clear how to revert the change; that is, to
 re-introduce the deleted code.  I guess that might be “git revert
 some horrible hash”
 
 ·If someone trips over more DPH code later, and wants to
 remove that too, it should be clear how to add it to the list of
 things to be revertred.
 
 ·We should have a Trac ticket “Resume work on DPH and
 vectorisation” or something like that, which summarises the reversion
 process.
 
 
 
 Just to be clear, this does not indicate any lack of interest in DPH
 on my part.  (Quite the reverse.)   It’s just that while no one is
 actually working on it, we should use our source code control system
 to move it out of the way, as others on this thread have persuasively
 argued.
 
 
 
 Manuel, yell if I got anything wrong.
 
 
 
 Thanks!
 
 
 
 Simon
 
 
 
 
 
 
 
 
 
 
 
 *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
 *Carter Schonwald
 *Sent:* 21 January 2015 03:32
 *To:* RodLogic
 *Cc:* Manuel M T Chakravarty; ghc-devs@haskell.org
 *Subject:* Re: vectorisation code?
 
 
 
 moving it to its own submodule is just a complicated version of
 cutting a branch that has the code Right before deleting it from master. 
 
 afaik, the amount of love needed is roughly one or more full time
 grad students really owning it, though i could be wrong. 
 
 
 
 
 
 On Tue, Jan 20, 2015 at 5:39 AM, RodLogic d...@rodlogic.net
 mailto:d...@rodlogic.net wrote:
 
(disclaimer: I know nothing about the vectorization code)
 
 
 
Now, is the vectorization code really dead code or it is code that
needs love to come back to life? By removing it from the code
base, you are probably sealing it's fate as dead code as we are
limiting new or existing contributors to act on it (even if it's a
commit hash away). If it is code that needs love to come back to
life, grep noise or conditional compilation is a small price to
pay here, imho.
 
 
 
As a compromise, is it possible to move vectorization code into
it's own submodule in git or is it too intertwined with core GHC?
So that it can be worked on independent of GHC?
 
 
 
 
 
On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel
hvrie...@gmail.com mailto:hvrie...@gmail.com wrote:
 
On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote:
 Here's an alternate suggestion: in SimplCore, keep the call
to vectorise
 around, but commented out
 
 Yuck. Carter and Brandon are right here - we have git, let
it do the
 job. I propose that we remove vectorization code, create a
Trac ticket
 about vectorization  DPH needing love and record the commit
hash in
 the ticket so that we can revert it easily in the future.
 
I'm also against commenting out dead code in the presence of a
VCS.
 
Btw, here's two links discussing the issues related to
commenting out if
anyone's interested in knowing more:
 
 -

 http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation
 
 -

 http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad
 
 
Cheers,
  hvr
 
 
 
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: vectorisation code?

[Manuel M T Chakravarty]

Given the vectorisation code is in its own subdirectory already, it’s quite 
easy to spot in a grep, I would say.

Manuel

 Richard Eisenberg e...@cis.upenn.edu:
 
 With all due respect to Manuel's request, could I opt for a different 
 resolution? I frequently (several times during most minutes of GHC 
 programming) grep the GHC source code for this or that. If the vectorisation 
 code is CPP'd away but still present in the compiler/ directory, these greps 
 will find hits in the code. Furthermore, without the specific knowledge that 
 there is a `#if 0` at the top of the file, the code will look quite active. 
 Of course, I could modify my grep macro to skip the vectorise directory, but 
 the next dev down the road might not know to do this.
 
 Here's an alternate suggestion: in SimplCore, keep the call to vectorise 
 around, but commented out (not just with CPP, for better syntax 
 highlighting). Include a Note explaining what `vectorise` does and why it's 
 not there at the moment. However, move the actual vectorisation code 
 somewhere else in the repo, outside of the source directories (`utils`? a new 
 `attic` directory?).
 
 Manuel, is this acceptable to you? Other devs, thoughts? Perhaps we should 
 also make a Trac ticket asking for some love to be given to this feature.
 
 Thanks,
 Richard
 
 On Jan 19, 2015, at 9:21 AM, Simon Peyton Jones simo...@microsoft.com wrote:
 
 Austin, (or anyone else)
 
 Manuel says:
 
 |   Would it be ok if we left it in the repo, but CPP'd it out so that
 |  we
 |   didn't compile everything?  (The DPH library is in the same state at
 |   the moment.)
 |  
 |   It might suffer bit-rot, but it’d still be there for resurrection.
 |  
 |  Sure, that’s ok.
 
 Could you action this?  Just avoid compiling anything in 'vectorise/', using 
 (I suppose) cpp to create a stub where necessary.
 
 Leave enough comments to explain!
 
 Simon
 
 |  
 |  I hope everything is fine in Cambridge!
 |  Manuel
 |  
 |   |  -Original Message-
 |   |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
 |   | Manuel M T Chakravarty
 |   |  Sent: 16 January 2015 02:58
 |   |  To: Richard Eisenberg
 |   |  Cc: ghc-devs@haskell.org Devs
 |   |  Subject: Re: vectorisation code?
 |   |
 |   |  [Sorry, sent from the wrong account at first.]
 |   |
 |   |  We currently don’t have the resources to work on DPH. I would
 |   | obviously prefer to leave the code in, in the hope that we will be
 |   | able to return to it.
 |   |
 |   |  Manuel
 |   |
 |   |   Richard Eisenberg e...@cis.upenn.edu:
 |   |  
 |   |   Hi devs,
 |   |  
 |   |   There's a sizable number of modules in the `vectorise`
 |   | subdirectory  of GHC. I'm sure these do all sorts of wonderful
 |   | things. But what,  exactly? And, does anyone make use of these
 |  wonderful things?
 |   |  
 |   |   A quick poking through the code shows a tiny link between the
 |   | vectorise code and the rest of GHC -- the function `vectorise`
 |   | exported from the module `Vectorise`, which is named in exactly
 |  one
 |   | place from SimplCore. From what I can tell, the function will be
 |   | called only when `-fvectorise` is specified, and then it seems to
 |   | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE
 |   | #-}`  doesn't appear in the manual at all, and `-fvectorise` is
 |   | given only a  cursory explanation. It seems these work with DPH...
 |   | which has been  disabled, no? Searching online finds several hits,
 |   | but nothing more  recent than 2012.
 |   |  
 |   |   I hope this question doesn't offend -- it seems that
 |   | vectorisation  probably has amazing performance gains. Yet, the
 |   | feature also seems  unloved. In the meantime, compiling (and
 |   | recompiling, and
 |   |  recompiling...) the modules takes time, as does going through
 |  them
 |   | to  propagate changes from elsewhere. If this feature is truly
 |   | orphaned,  unloved, and unused at the moment, is it reasonable to
 |   | consider  putting it on furlough?
 |   |  
 |   |   Thanks,
 |   |   Richard
 |   |   ___
 |   |   ghc-devs mailing list
 |   |   ghc-devs@haskell.org
 |   |   http://www.haskell.org/mailman/listinfo/ghc-devs
 |   |
 |   |  ___
 |   |  ghc-devs mailing list
 |   |  ghc-devs@haskell.org
 |   |  http://www.haskell.org/mailman/listinfo/ghc-devs
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs
 
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: vectorisation code?

[Manuel M T Chakravarty]

[Sorry, sent from the wrong account at first.]

We currently don’t have the resources to work on DPH. I would obviously prefer 
to leave the code in, in the hope that we will be able to return to it.

Manuel

 Richard Eisenberg e...@cis.upenn.edu:
 
 Hi devs,
 
 There's a sizable number of modules in the `vectorise` subdirectory of GHC. 
 I'm sure these do all sorts of wonderful things. But what, exactly? And, does 
 anyone make use of these wonderful things?
 
 A quick poking through the code shows a tiny link between the vectorise code 
 and the rest of GHC -- the function `vectorise` exported from the module 
 `Vectorise`, which is named in exactly one place from SimplCore. From what I 
 can tell, the function will be called only when `-fvectorise` is specified, 
 and then it seems to interact with a {-# VECTORISE #-} pragma. However, `{-# 
 VECTORISE #-}` doesn't appear in the manual at all, and `-fvectorise` is 
 given only a cursory explanation. It seems these work with DPH... which has 
 been disabled, no? Searching online finds several hits, but nothing more 
 recent than 2012.
 
 I hope this question doesn't offend -- it seems that vectorisation probably 
 has amazing performance gains. Yet, the feature also seems unloved. In the 
 meantime, compiling (and recompiling, and recompiling...) the modules takes 
 time, as does going through them to propagate changes from elsewhere. If this 
 feature is truly orphaned, unloved, and unused at the moment, is it 
 reasonable to consider putting it on furlough?
 
 Thanks,
 Richard
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: I'm going to disable DPH until someone starts maintaining it

[Manuel M T Chakravarty]

Sounds good to me.

Thanks, Geoff, for doing this!

Manuel

Austin Seipp aus...@well-typed.com:
 On Mon, Aug 4, 2014 at 8:49 AM, Geoffrey Mainland mainl...@apeiron.net 
 wrote:
 I have patches for DPH that let it work with vector 0.11 as of a few
 months ago. I would be happy to submit them via phabricator if that is
 agreeable (we have to coordinate with the import of vector 0.11
 though...I can instead leave them in a wip branch for Austin to merge as
 he sees fit). I am also willing to commit some time to keep DPH at least
 working in its current state.
 
 That would be quite nice if you could submit patches to get it to
 work! Thanks so much.
 
 As we've moved to submodules, having our own forks is becoming less
 palatable; we'd like to start tracking upstream closely, and having
 people submit changes there first and foremost. This creates a bit of
 a lag time between changes, but I think this is acceptable (and most
 of our maintainers are quite responsive to GHC needs!)
 
 It's also great you're willing to help maintain DPH a bit - but based
 on what Ben said, it seems like a significant rewrite will happen
 eventually.
 
 Geoff, here's my proposal:
 
 1) I'll disable DPH for right now, so it won't pop up during
 ./validate. This will probably happen today.
 2) We can coordinate the update of vector to 0.11, making it track
 the official master. (Perhaps an email thread or even Skype would
 work)
 3) We can fix DPH at the same time.
 4) Afterwords, we can re-enable it for ./validate
 
 If you submit Phabricator patches, that would be fantastic - we can
 add the DPH repository to Phabricator with little issue.
 
 In the long run, I think we should sync up with Ben and perhaps Simon
  Co to see what will happen long-term for the DPH libraries.
 
 Geoff
 
 On 8/4/14 8:18 AM, Ben Lippmeier wrote:
 On 4 Aug 2014, at 21:47 , Austin Seipp aus...@well-typed.com wrote:
 
 Why? Because I'm afraid I just don't have any more patience for DPH,
 I'm tired of fixing it, and it takes up a lot of extra time to build,
 and time to maintain.
 I'm not going to argue against cutting it lose.
 
 
 So - why are we still building it, exactly?
 It can be a good stress test for the simplifier, especially the SpecConstr 
 transform. The fact that it takes so long to build is part of the reason 
 it's a good stress test.
 
 
 [1] And by 'speak up', I mean I'd like to see someone actively step
 forward address my concerns above in a decisive manner. With patches.
 I thought that in the original conversation we agreed that if the DPH code 
 became too much of a burden it was fine to switch it off and let it become 
 unmaintained. I don't have time to maintain it anymore myself.
 
 The original DPH project has fractured into a few different research 
 streams, none of which work directly with the implementation in GHC, or 
 with the DPH libraries that are bundled with the GHC build.
 
 The short of it is that the array fusion mechanism implemented in DPH 
 (based on stream fusion) is inadequate for the task. A few people are 
 working on replacement fusion systems that aim to solve this problem, but 
 merging this work back into DPH will entail an almost complete rewrite of 
 the backend libraries. If it the existing code has become a maintenance 
 burden then it's fine to switch it off.
 
 Sorry for the trouble.
 Ben.
 
 
 
 
 
 -- 
 Regards,
 
 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: style cleanup guidelines for GHC, and related bikeshedding

[Manuel M T Chakravarty]

Johan Tibell johan.tib...@gmail.com:
 
 On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones
 simo...@microsoft.com wrote:
 | I used to be a 80 column guy, but moved away from that the last years.
 | But you are right, there must be an upper limit and, if 80 is a
 | problem for code reviews, then it's a reasonable choice.
 
 As laptop screens have successively more horizontal pixels and fewer 
 vertical pixels, longer lines use screen real estate better.  80 columns now 
 seems a bit narrow to me.  100 would be better.
 
 But I'm not going to die for this
 
 Here we go!
 
 * Wider screens let you have several Emacs buffers next to each
 other. At 80 chars you can have about 2 buffers next to each other on
 a 13 screen.

I think that was SimonM's premise for code reviews, that you want lines short 
enough to have two versions besides each other.

 * The average line length is about 30-35 characters in Python. If
 it's anything similar in Haskell shorter line length are more
 efficient, looking how much of the lines times columns space is filled
 with characters.

The problem is that indentation and long identifiers push you towards longer 
lines.

 * The eye has trouble traveling back to the next line if lines get
 too long (at least when reading prose). Research says around 60-70
 characters is optimal, if I recall correctly.

I think we read code differently to prose (and prose is not much indented), so 
I don't think these numbers transfer. 

Manuel

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

Re: RFC: style cleanup guidelines for GHC, and related bikeshedding

[Manuel M T Chakravarty]

Simon Marlow marlo...@gmail.com:
 Austin didn't mention this, so I will: we have a wiki page for style
 
 https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle
 
 It has a pretty clear set of guidelines for imports/exports, for example 
 (that we don't follow as much as we should).
 
 I'd be in favour of changing .lhs files to .hs files, replacing all the 
 \begin{code}...\end{code} with -}...{-.  As I said in my reply to Simon, 
 literate source files aren't providing any real benefit to us, and in the 
 name of consistency this would be a positive step.  I’m all in favour of 
 gardening the code base to clean up things like this.

Yes!

 However, the best time for a big stylistic sweep is a time that minimizes the 
 number of merges we have to do across these commits.  That would be just 
 before we branch for a new major release; hopefully at that point most of the 
 feature branches will be merged and we're not going to merge any further 
 patches into the previous release branch.
 
 I'm less enthusiastic about fixing whitespace things.  It's a tough call, but 
 I'm guessing that fixing it would cause more pain than not fixing it.  
 Opinions might differ, and I wouldn’t mind at all if the consensus were to do 
 a whitespace sweep too.

I think, the tabs should go — it’s been dragging on for a long time now. (The 
rest is less important.)

 One other thing I'd like to propose is an 80-column limit on new code. 
 Personally I've always used an 80-column limit for various reasons. This is 
 the biggest bikeshed ever and we could talk all day about it, but here are a 
 couple of concrete points that I think are uncontroversial:
 
 - there has to be *some* limit, so that we know how wide to make our
   windows.  The only valid discussion is what the limit should be.
 
 - Phabricator's side-by-side diffs are hard to read on a laptop screen
   when lines go beyond 80 columns.
 
 And I think 80 is a good enough number, especially for Haskell where you can 
 pack a lot into an 80-column line.  Phabricator is already flagging up 80 
 column lines in its linter, which is its default setting.

I used to be a 80 column guy, but moved away from that the last years. But you 
are right, there must be an upper limit and, if 80 is a problem for code 
reviews, then it’s a reasonable choice.

Cheers,
Manuel

 On 02/07/2014 12:59, Austin Seipp wrote:
 Hi *,
 
 First off, WARNING: BIKESHEDDING AHEAD.
 
 With that out of the way - today on IRC, there was some discussion
 about some stylistic/consistency issues in GHC, and being spurred by
 Johans recent proposal for top-level documentation, I figured perhaps
 we should beat the drum on this issue as well.
 
 The TL;DR is that GHC has a lot of inconsistent style issues,
 including things like:
 
  - Mixing literate haskell with non-literate haskell files
  - Legacy code with tabs and spaces intermixed
  - Related to the last one, trailing whitespace
  - Mixing styles of do notation in different parts of the compiler
 (braces vs no braces)
  - Probably things like indentation mismatches even in the same code
  - Probably many other things I've missed, obvious or not.
 
 These issues by themselves aren't too bad, but together they make the
 coding style for GHC very inconsistent, and this hurts maintainability
 a bit I feel. Furthermore, some of these issues block related
 improvements - for example,
 https://ghc.haskell.org/trac/ghc/ticket/9230 which is probably quite
 reasonable will likely be a bit annoying to implement until GHC itself
 is de-tabbed - we use -Werror during ./validate. This particular issue
 is what started the discussion.
 
 Also, with developers now using arcanist and phabricator, they have
 linting enabled for new patches, but they will often warn about
 surrounding issues, mostly tabs and trailing spaces. This is a bit
 annoying for submitters, and would be fixed by enforcing it.
 
 First attack plan
 ~~~
 
 So, to start, I'd like to propose that we make some guidelines for
 these kinds of things, and also a plan to fix some of them. To start:
 
  #1) We should really consider going ahead and detabbing the remaining
 files that have them. We already enforce this on new commits with git
 hooks, but by doing this, we can make -fwarn-tabs a default flag and
 then validate with -Werror in the development process.
 
  #2) Similarly, we should kill all the trailing whitespace. (I think
 this is less controversial than #1)
 
  #3) We should most certainly move the remaining files from literate
 haskell to non-literate haskell. Most of the files in the compiler are
 already in this form, and the literate haskell documentation can't be
 used to generate PDFs or anything similar. I suggest we get rid of it.
 More Haskell users use non-literate files anyway. This is probably the
 least controversial.
 
 Merge issues
 ~
 
 The reason we haven't done the above three things historically is that
 it makes merge conflicts nastier. A 

Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code

[Manuel M T Chakravarty]

Which makes a lot of GHC code more readable — I’m serious!

Manuel

PS: I have resisted it for a while, but after slogging through GHC for extended 
periods, I’ve come to appreciate the additional clarity in large and tricky 
functions (e.g., in the type checker  renamer).

Edward Kmett ekm...@gmail.com:
 That has a high chance of backfiring and requiring everyone to use do { ...; 
 ... } with explicit braces and semis. ;)
 
 -Edward
 
 
 On Wed, Jul 2, 2014 at 4:08 AM, Simon Marlow marlo...@gmail.com wrote:
 Agreed, let's do it.  Thanks for the well-argued proposal.
 
 Next up: consistent style :-)
 
 Cheers,
 Simon
 
 
 On 27/06/2014 10:51, Johan Tibell wrote:
 Hi!
 
 I found myself exploring new parts of the GHC code base the last few
 weeks (exciting!), which again reminded me of my biggest frustration
 when working on GHC: the lack of per-function/type (Haddock) comments.
 
 GHC code is sometimes commented with notes, which are great but tend
 to (1) mostly cover the exceptional cases and (2) talk about the
 implementation of a function, not how a caller might use it or why.
 
 Lack of documentation, in GHC and other software projects, usually has
 (at least) two causes:
 
   * Programmers comment code they think is complex enough to warrant a
 
 comment. The problem is that the author is usually a poor judge of
 what's complex enough, because he/she is too familiar with the code
 and tends to under-document code when following this principle.
   * Documenting is boring and tends to have little benefit the person
 
 writing to documentation. Given lack of incentives we tend to
 document less than we ought to.
 
 I've only seen one successful way to combat the lack of documentation
 that stems from the above: have the project's style guide mandate that
 top-level functions and types (or at least those that are exported) have
 documentation. This works well at Google.
 
 Anecdote: we have one code base inside Google that was until recently
 exempt from this rule and documentation is almost completely absent in
 that code base, even though hundreds of engineers work on and need to
 understand it every day. This breeds institutional knowledge problems
 i.e. if the author of a core piece of code leaves, lots of knowledge is
 lost.
 
 *Proposal: *I propose that we require that new top-level functions and
 
 types have Haddock comments, even if they start out as a single, humble
 sentence.
 
 I've found that putting even that one sentence (1) helps new users and
 (2) establishes a place for improvements to be made. There's a strong
 broken window effect to lack of comments, in that lack of comments
 breeds more lack of comments as developers follow established practices.
 
 We should add this requirement to the style guide. Having it as a
 written down policy tends to prevent having to re-hash the whole
 argument about documentation over and over again. This has also helped
 us a lot at Google, because programmers can spend endless amount of time
 arguing about comments, placement of curly braces, etc. and having a
 written policy helps cut down on that.
 
 To give an idea of how to write good comments, here are two examples of
 undocumented code I ran into in GHC and how better comments would have
 helped.
 
 *First example*
 
 In compiler/nativeGen/X86/Instr.hs there's a (local) function called
 mkRUR, which is a helper function use when computing instruction
 register usage.
 
 The first question that I asked upon seeing uses of that function was
 what does RUR stand for? Given the context the function is in, I
 guessed it stands for read-update-read, because R is used to mean read
 in the enclosing function and updating is related to reading so that
 must be what U stands for. It turns out that it stands for
 RegUsageReadonly. Here's a comment that would have captured, in a single
 sentence, what this function is for:
 
  -- | Create register usage info for instruction that only
  -- reads registers.
  mkRUR src = src' `seq` RU src' []
  where src' = filter (interesting platform) src
 
 That already a big improvement. A note about the register filtering,
 which means that not all registers you pass to the function will be
 recorded as being read in the end, could also be useful.
 
 Aside: providing a type signature, which would have made it clear that
 the return type is RU, might also have helped in this particular case.
 
 *Second example*
 
 In the same file there a function called x86_regUsageOfInstr. It's the
 function that encloses the local function mkRUR above.
 
 I could figure out that this function has something to do with register
 usage, of the instruction passed as an argument, and that register usage
 is important for the register allocator. However, trying to understand
 in more detail what that meant was more of challenge than it needed to
 be. First, a comment more clearly explaining what computing register
 usage means in practice would be 

Re: Cabal for GHC 7.8

[Manuel M T Chakravarty]

Thanks, Herbert.

I eventually noticed that it the Cabal repo is a submodule, but I wasn’t aware 
of the Git’s support to rewrite URLs.

To answer your questions: cloning from GitHub is useful as I can fork the repos 
on GitHub. At haskell.org, I need to use branches, which I don’t like.

Manuel

Herbert Valerio Riedel hvrie...@gmail.com:
 On 2014-06-28 at 07:48:16 +0200, Manuel M T Chakravarty wrote:
 I noticed that the Cabal package doesn’t have a branch for ghc-7.8:
 
  http://git.haskell.org/packages/Cabal.git
 
 Is that intended?
 
 A ghc-7.8 branch is not really needed, as Cabal is registered as
 submodule in ghc.git's ghc-7.8 branch. It's just sync-all that 
 
 Maybe as a result the instructions at 
 
  https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources
 
 to check out a branch from the *GitHub mirror repos* doesn’t work
 either. 
 
 For cloning via the GitHub-mirror[1] I'd recommend using the scheme as
 described in [2]. That is, set up url-rewrites (that take also into
 account the 'packages/foo' - 'packages-foo' rewriting):
 
  git config --global url.git://github.com/ghc/.insteadOf 
 git://git.haskell.org/
  git config --global url.git://github.com/ghc/packages-.insteadOf 
 git://git.haskell.org/packages/
 
 and then clone as if you would from git://git.haskell.org
 
   git clone -b ghc-7.8 git://git.haskell.org/ghc.git ghc-7.8
   cd ghc-7.8
   ./sync-all get -b ghc-7.8
 
 all network access will be redirected to github.com instead.
 
 
 [1]: Btw, why do you want to use the github mirror instead of 
 git://git.haskell.org?
 
 [2]: 
 https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingtheGitHubGHCMirror
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Cabal for GHC 7.8

[Manuel M T Chakravarty]

I noticed that the Cabal package doesn’t have a branch for ghc-7.8:

  http://git.haskell.org/packages/Cabal.git

Is that intended? Maybe as a result the instructions at 

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

to check out a branch from the *GitHub mirror repos* doesn’t work either. It 
fails with

== running git submodule update
Cloning into 'libraries/Cabal'...
fatal: remote error: 
  ghc/packages/Cabal is not a valid repository name
  Email supp...@github.com for help
Clone of 'g...@github.com:ghc/packages/Cabal.git' into submodule path 
'libraries/Cabal' failed
git failed: 256 at ./sync-all line 122.

Manuel

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

Re: Associated type instances

[Manuel M T Chakravarty]

Simon,

I’m not sure when this ”feature” was added, but I’m pretty sure that my 
original implementation of associated types was exactly what you describe in 
the solution. Or did I miss anything?

Manuel

Simon Peyton Jones simo...@microsoft.com:
 Friends
 
 I want to make withdraw (or, rather, simplify) a little-known feature in GHC, 
 but before I do so I want to check that no one is going to have a heart 
 attack.
 
 Relevant bits of the user manual: 
 http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
 
 All of this arose when thinking about fixing Trac #9063.
 
 I believe that this change will affect essentially nobody, and I propose to 
 implement forthwith in HEAD (and hence 7.10). 
 
 Does anyone object?
 
 Thanks
 
 Simon
 
  
 
 The issue
 
 Consider this:
 
 class C a where
type T a b :: *
  
 instance C [x] where
type T [x] b = x - b
 That is just what you’d expect.  But currently this is allowed too:
 
 instance C [x] where
type T [x] Int = x - Int
type T [x] Bool = Bool - x
 That is, GHC 7.8 allows many associated type instances, provided they don’t 
 overlap.  But, oddly you can’t further instantiate the instance pattern. This 
 would make just as much sense, but isn’t allowed:
 
 instance C [x] where
type T [Int] b = b - Int
type T [Bool] b = Bool - b
 Moreover, as the user manual says, for an open kind like *, none of this 
 really makes sense. It really only makes sense for a closed kind. Something 
 like
 
 class D a where
type S (b :: Bool) a :: *
 Now this would make some kind of sense:
 
 instance D [x] where
type S True [x] = x - x
type S False [x] = x
 But for closed kinds, you really want a closed type family.  So this would be 
 better:
 
 instance D [x] where
type S b [x] = SHelp x b
  
 type family SHelp x b where
   SHelp x True = x - x
   SHelp x False = x
  
 So yes, you do have to declare a named helper type, but you get something 
 much more perspicuous and explicit in exchange.
 
 All of this also applies to the default declaration(s) which you can supply 
 for an associated type (see 7.7.3.2 in the link above), only it’s a bit more 
 complicated and indirect.
 
 My solution
 
 I propose to simplify substantially, as follows:
 
 · The “shared arguments” of an associated type are the argument 
 positions that mention a type variable from the class header.  So in class C 
 above, the first argument position of T is “shared”; and in class D, the 
 second argument position of S is shared.
 
 · A instance for an associated type (in a class instance declaration) 
 cf 7.7.3.1 must have
 
 o   type variables in the non-shared argument positions, and
 
 o   an exact copy of the corresponding instance header type in the shared 
 positions
 
 · For each associated type you can have
 
 o   at most one default declaration in the class declaration
 
 o   at most one type instance declaration in the class instance declaration
 
  
 
  
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: GHC 7.8.3 release

[Manuel M T Chakravarty]

As far as I can see, the proposed fixes are all compiler and RTS fixes. (At 
least, it should be easy to restrict 6.8.3 to that. Austin?)

So, I don’t think it would affect the packages. And of what use is a platform 
that includes a compiler of which we know that it has serious problems?

Manuel

Yitzchak Gale g...@sefer.org:
 Herbert Valerio Riedel wrote:
 What kind of version tweaks are you thinking about? (Afaics, the GHC
 bundled libraries don't have any version bumps.)
 
 Well for one thing, wouldn't the version of base be bumped?
 
 If the bugs fixed in 7.8.3 affect any packages in the platform,
 we would want to make whatever changes are needed to make sure
 that the fixes work for them - at least bumping base. Then
 everything would need to be re-built and re-tested. And if
 no packages in the platform are affected, then given the
 ridiculous delay of the platform release already, it's harder
 justify waiting any longer. Like I said - it would be a difficult
 decision (and not mine to make).
 
 -Yitz
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: GHC 7.8.3 release

[Manuel M T Chakravarty]

Mark, 

Did you see this thread?

Manuel

Yitzchak Gale g...@sefer.org:

 OK then. It's just a question of updating some scripts,
 rebuilding and retesting. If these are serious generable
 usability issues, you are right that it sounds compelling.
 Still, it will add time, so Mark will have to decide.
 
 Thanks,
 Yitz
 
 On Tue, May 27, 2014 at 2:29 PM, Herbert Valerio Riedel
 hvrie...@gmail.com wrote:
 On 2014-05-27 at 12:47:53 +0200, Yitzchak Gale wrote:
 Herbert Valerio Riedel wrote:
 What kind of version tweaks are you thinking about? (Afaics, the GHC
 bundled libraries don't have any version bumps.)
 
 Well for one thing, wouldn't the version of base be bumped?
 
 There's not been any change yet to base in the ghc-7.8 branch since the
 7.8.2 release:
 
  http://git.haskell.org/packages/base.git/shortlog/refs/heads/ghc-7.8
 
 as you can see from
 
  https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory
 
 it's happened in the past already, that 'base' was not bumped for every
 (minor) GHC release. It's rather the exception when `base` version
 bumps are performed for minor GHC releases.
 
 If the bugs fixed in 7.8.3 affect any packages in the platform,
 we would want to make whatever changes are needed to make sure
 that the fixes work for them - at least bumping base.
 
 While I appreciate there may be packages affected by GHC 7.8.2/7.8.3
 changes, I still fail to see how artificially bumping base would help
 here.
 
 Then everything would need to be re-built and re-tested. And if no
 packages in the platform are affected, then given the ridiculous delay
 of the platform release already, it's harder justify waiting any
 longer. Like I said - it would be a difficult decision (and not mine
 to make).
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: Status updates

[Manuel M T Chakravarty]

Austin,

Could we please make sure to include this bug for 7.8.3?

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

The ticket already includes a patch that solves the problem for us.

As remarked by Levent, this bug will probably affect all EDSL that use Andy’s 
StableName-based observable sharing trick.

Cheers,
Manuel

Austin Seipp aus...@well-typed.com:
 Hello all,
 
 It has been another slow week here, and there wasn't a lot I touched
 in the tree this week. The primary highlights:
 
 * The AMP battle rages on! It turns out the addition of `join` to
 `Monad` has had some subtle implications for GND/Roles. See here for
 more: https://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html
 
 * Simon is still reviewing the ORF work, as far as I know. Hopefully
 it will Land Real Soon Now.
 
 * Patches! Lots of them! I'm reviewing and merging several of them
 right now. In particular, all the ones slated for 7.8.3 are up for
 grabs[1] by me right now, but I do need to double-check some of them
 e.g. on Windows, to make sure nothing breaks.
 
 * Many branches have been deleted. Something like 20-30 of them, I
 think. Yay! Sorry for the spam to the commits list too, but it was a
 necessary evil.
 
 * I'm working away at some of the bugs. #7602 is building right now,
 with some nice improvements. That will go into the 7.8.3 branch, so OS
 X users will get a big performance gain, yay!
 
 * Another bug: #8736. I had a patch for this, but this one is tricky
 to fix because when we load object files, we don't actually know if
 they're static or dynamic. This is encoded in the interface file, but
 there are some tricky semantics about what to do in some cases of
 (legitimately) needing to re-read interface files that are a bit
 subtle. I'll be trying to revive my patch for this today.
 
 Other than that, there really hasn't been a lot to mention. Please, do
 get down on reviewing some bugs and helping fix them![1] I'm more than
 willing to help in any way I can.
 
 I'd also like some feedback: what do people think about the current
 list? Are there any of you readers who see one *you* think is truly
 critical? Maybe we can get some input to help narrow the scope if
 needed.
 
 Thanks!
 
 [1] 
 https://ghc.haskell.org/trac/ghc/query?status=infoneededstatus=mergestatus=newstatus=patchgroup=statusmilestone=7.8.3
 
 -- 
 Regards,
 
 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: FFI: c/c++ struct on stack as an argument or return value

[Manuel M T Chakravarty]

Yuras Shumovich shumovi...@gmail.com:
 I think the compiler is the right place. It is impossible to have
 efficient implementation in a library.
 
 For dynamic wrapper (foreign import wrapper stuff) ghc generates piece
 of executable code at runtime. There are native implementations for a
 number of platforms, and libffi is used as a fall back for other
 platforms (see rts/Adjustor.c). AFAIK it is done that way because libffi
 is slower then native implementation.
 
 Library implementation can't generate native dynamic wrapper, it has to
 use slow libffi.

When we first implemented the FFI, there was no libffi. Maintaining the 
adjustor code for all platforms is a PITA; hence, using libffi was a welcome 
way to improve portability.

Making the adjustor code more complicated by adding more functionality doesn’t 
sound like a good plan to me.

Besides, there are other overheads in addition to the actual marshalling in FFI 
calls and most of the time we are calling out to library functions for which 
the FFI call overhead is only a small portion of the runtime.

 i think the crux of Manuel's point is mainly that any good proposal
 has to
 at least give a roadmap to support on all the various platforms etc
 etc
 
 I don't think you are expecting detailed schedule from me. Passing
 structure by value is possible on all platforms ghc supports, and it can
 be implemented for any particular platform if somebody is interested.
 
 From my point of view, at this point it is more important to agree on
 the next question: do we want such functionality in ghc at all? I don't
 want to waste time on it if nobody wants to see it merged.

I still don’t see the benefit in further complicating an already murky corner 
of the compiler. Moreover, for this to make sense, it would need to work on all 
supported platforms. Unless you are volunteering to implement it on multiple 
platforms, this would mean, we’d use libffi for most platforms anyway. This 
brings me to my original point, a library or tool is the better place for this.

Manuel

PS: I’d happily accept language-c-inline patches for marshalling structs.

 On Sat, 2014-03-15 at 00:37 -0400, Carter Schonwald wrote:
 I'm not opposing that, in fact, theres a GHC ticket discussing some stuff
 related to this (related to complex numbers).
 
 i think the crux of Manuel's point is mainly that any good proposal has to
 at least give a roadmap to support on all the various platforms etc etc
 
 
 On Sat, Mar 15, 2014 at 12:33 AM, Edward Kmett ekm...@gmail.com wrote:
 
 I don't care enough to fight and try to win the battle, but I just want to
 point out that Storable structs are far more brittle and platform dependent
 than borrowing the already correct platform logic for struct passing from
 libffi.
 
 I do think the existing FFI extension made the right call under the 32 bit
 ABIs that were in use at the time it was defined. That said, with 64-bit
 ABIs saying that 2 32-bit ints should be passed in a single 64 bit
 register, you wind up with large chunks of third party APIs we just can't
 call out to directly any more, requiring many one-off manual C shims.
 
 -Edward
 
 
 
 
 On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald 
 carter.schonw...@gmail.com wrote:
 
 indeed, its very very easy to do storable instances that correspond to
 the struct type you want,
 
 the ``with`` function in
 http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils
  actually gets you most of the way there!
 
 
 
 
 On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty 
 c...@cse.unsw.edu.au wrote:
 
 Yuras,
 
 I’m not convinced that the compiler is the right place for this kind of
 functionality. In fact, when we designed the Haskell FFI, we explicit
 decided against what you propose. There are a few reasons for this.
 
 Firstly, compilers are complex beasts, and secondly, it takes a long
 time until a change in the compiler goes into production. Hence, as a
 general rule, it is advisable to move complexity from the compiler into
 libraries as this reduces compiler complexity. Libraries are less complex
 and changes can be rolled out much more quickly (it’s essentially a 
 Hackage
 upload versus waiting for the next GHC and Haskell Platform release).
 
 Thirdly, we have got the Haskell standard for a reason and modifying the
 compiler implies a language extension.
 
 The design goal for the Haskell FFI was to provide the absolute minimum
 as part of the language and compiler, and to layer additional conveniences
 on top of that in the form of libraries and tools.
 
 Have you considered the library or tool route?
 
 Manuel
 
 Yuras Shumovich shumovi...@gmail.com:
 Hi,
 
 Right now ghc's FFI doesn't support c/c++ structures.
 
 Whenever we have foreign function that accepts or returns struct by
 value, we have to create wrapper that accepts or returns pointer to
 struct. It is inconvenient, but actually not a big deal.
 
 But there is no easy

Re: FFI: c/c++ struct on stack as an argument or return value

[Manuel M T Chakravarty]

Yuras,

I’m not convinced that the compiler is the right place for this kind of 
functionality. In fact, when we designed the Haskell FFI, we explicit decided 
against what you propose. There are a few reasons for this.

Firstly, compilers are complex beasts, and secondly, it takes a long time until 
a change in the compiler goes into production. Hence, as a general rule, it is 
advisable to move complexity from the compiler into libraries as this reduces 
compiler complexity. Libraries are less complex and changes can be rolled out 
much more quickly (it’s essentially a Hackage upload versus waiting for the 
next GHC and Haskell Platform release).

Thirdly, we have got the Haskell standard for a reason and modifying the 
compiler implies a language extension.

The design goal for the Haskell FFI was to provide the absolute minimum as part 
of the language and compiler, and to layer additional conveniences on top of 
that in the form of libraries and tools.

Have you considered the library or tool route?

Manuel

Yuras Shumovich shumovi...@gmail.com:
 Hi,
 
 Right now ghc's FFI doesn't support c/c++ structures.
 
 Whenever we have foreign function that accepts or returns struct by
 value, we have to create wrapper that accepts or returns pointer to
 struct. It is inconvenient, but actually not a big deal.
 
 But there is no easy workaround when you want to export haskell function
 to use it with c/c++ API that requires structures to be passed by value
 (Usually it is a callback in c/c++ API. You can't change it's signature,
 and if it doesn't provide some kind of void* userdata, then you are
 stuck.)
 
 I'm interested in fixing that. I'm going to start with 'foreign import
 wrapper ...' stuff.
 
 Calling conventions for passing c/c++ structures by value are pretty
 tricky and platform/compiler specific. So initially I'll use libffi for
 that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
 rts/Adjustor.c). It will allow me to explore design space without
 bothering about low level implementation details. Later it could be
 implemented for native (non-libffi) adjustors.
 
 Is anybody interested it that? I appreciate any comments/ideas.
 
 Right now I don't have clear design. It would be nice to support plain
 haskell data types that are 1) not recursive, 2) has one constructor and
 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
 ideas are welcome.
 
 An example how to use libffi with structures:
 http://www.atmark-techno.com/~yashi/libffi.html#Structures
 
 Thanks,
 Yuras
 
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: GHC API: Using runGhc twice or from multiple threads?

[Manuel M T Chakravarty]

Simon Marlow marlo...@gmail.com:
 And what about this one:
 
 main = do
forkIO $ runGhc libdir $ do ...
forkIO $ runGhc libdir $ do ...
 
 The problem with this is the RTS linker, which is a single piece of shared 
 global state.  We could actually fix that if it became important.  If you’re 
 not running interpreted code, this should be fine (apart from the static 
 flags issue mentioned above).

I’m curious, what is the issue with interpreted code? Does the interpreter 
store interpreter state in the RTS, which would get mixed up between the two 
instances?

If so, wouldn’t the same thing happen if I use forkIO in interpreted code?

Manuel

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

Re: Turning ForceSpecConstr/NoSpecConstr into pragmas?

[Manuel M T Chakravarty]

It's also used by vector, which is widely deployed and, I think, doesn't use TH 
otherwise.

Manuel


Simon Peyton-Jones simo...@microsoft.com:
 It's true that I suggested making it an annotation.  The DPH libraries use a 
 lot of Template Haskell and so have to be compiled with a stage2 compiler 
 anyway. 
 
 The thing about ForceSpecConstr is that it is an unprincipled hack that I 
 hate with a passion. It clearly is not the Right Thing. I just don't yet know 
 a better way to do it.  Johan suggests a more principled approach, about 
 eliminating uses of the stream constructor. I know that Roman considered that 
 but could not make it work.  I'm afraid I can't remember why.
 
 Because it is such a hack I'm reluctant to bake it more deeply into the 
 compiler, and to sink further effort into doing so.  Also I'm not sure what 
 problem we are trying to solve here. If it's compiling DPH libraries with 
 stage1, that won't work because they use TH.
 
 All that said, I don't seriously object to someone making it a pragma if you 
 want.   Just make clear that it's a horrible hack.
 
 Simon
 
 
 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Manuel
 | M T Chakravarty
 | Sent: 10 October 2013 04:03
 | To: Austin Seipp
 | Cc: Roman Leshchinskiy; ghc-devs@haskell.org
 | Subject: Re: Turning ForceSpecConstr/NoSpecConstr into pragmas?
 | 
 | This feature was implemented as an annotation by Roman in part because
 | Simon was keen to see the then new annotation feature used, in part
 | because we were unsure whether the design would last, and it part as it
 | seemed easier than hacking it into GHC.
 | 
 | Personally, I would have always preferred it to be a proper pragma,
 | mainly for the reason that causes grief now (i.e., because it requires
 | stage2). So, as far as I'm concerned, please make it a pragma.
 | 
 | Manuel
 | 
 | Austin Seipp aus...@well-typed.com:
 |  Hello all,
 | 
 |  Early last week I was reminded of something, which was that vector/dph
 |  depend on the stage2 compiler - this is because both packages use
 |  annotations to specify ForceSpecConstr and NoSpecConstr on several key
 |  datatypes.
 | 
 |  For most of our platforms (now including ARM,) this should generally
 |  be OK, because we have stage2 and the linker available to support it.
 | 
 |  But in particular, it makes vector and dph unusable for cross
 |  compilers. This might be somewhat problematic for e.g. iOS or an RPi,
 |  where we only have a stage1 cross compiler - but it's reasonable to
 |  assume we may want to use vector there! And more and more libraries
 |  depend on vector these days.
 | 
 |  I believe these are the only instances in which vector/dph needs
 |  stage2. So I ask: is it reasonable to change this to a pragma built
 |  into the compiler? That is,
 | 
 |  
 |  data SPEC = SPEC | SPEC2
 |  {-# ANN type SPEC ForceSpecConstr #-}
 | 
 |  data PArray a
 | = PArray Int# (PData  a)
 |  {-# ANN type PArray NoSpecConstr #-}
 |  -
 | 
 |  becomes something like:
 | 
 |  -
 |  data SPEC = SPEC | SPEC2
 |  {-# SPECIALIZE Constructor SPEC #-}
 | 
 |  data PArray a
 | = PArray Int# (PData  a)
 |  {-# NOSPECIALIZE Constructor PArray #-}
 |  -
 | 
 |  I'm not particularly interested in a bikeshedding discussion about the
 |  exact syntax for the pragma (although this somewhat falls in line with
 |  'INLINE ConLike' as a special case,) - I just want to know if this
 |  sounds reasonable.
 | 
 |  Looking at SpecConstr in the compiler, there seems to be quite a lot
 |  of note summarising that we need a better design - in particular,
 |  notes about nuking NoSpecConstr (as it appeared before
 |  ForceSpecConstr,) and turning ForceSpecConstr into a library type of
 |  some sort. I don't propose changing any of this really, just removing
 |  the dependency on the annotations.
 | 
 |  But if someone thinks a library type would be better suited for this -
 |  I'm totally fine with that too and am all-ears for a suggestion.
 | 
 |  And of course, both of these can continue to be supported for a while,
 |  although the patches to vector, at least, would be trivial to switch
 |  it over.
 | 
 |  Ben, Manuel, Simon - you three are the experts here I believe.
 |  Thoughts? Perhaps I'm missing something key here?
 | 
 |  --
 |  Regards,
 | 
 |  Austin Seipp, Haskell Consultant
 |  Well-Typed LLP, http://www.well-typed.com/
 |  ___
 |  ghc-devs mailing list
 |  ghc-devs@haskell.org
 |  http://www.haskell.org/mailman/listinfo/ghc-devs
 | 
 | ___
 | ghc-devs mailing list
 | ghc-devs@haskell.org
 | http://www.haskell.org/mailman/listinfo/ghc-devs

Re: PSA: GHC can now be built with Clang

[Manuel M T Chakravarty]

Austin Seipp ase...@pobox.com:
 * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
 * I have a small, 6-line patch to Clang to fix the build failure in
 primitive (Clang was too eager to stringify something.) Once this fix
 is integrated into Clang (hopefully very soon,) it will be possible to
 build GHC entirely including all stage2 libraries without any patches.
 The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am
 hoping this will also make it into XCode 5.

Xcode 5 DP2's tools are still based on 3.3svn.

 As for the infamous ticket #7602, the large performance regression on
 Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS
 approach.
 
 ./gc_bench.slow-tls 19 50 5 22 +RTS -H180m -N7 -RTS  395.57s user
 173.18s system 138% cpu 6:50.71 total
 
 vs
 
 ./gc_bench.fast-tls 19 50 5 22 +RTS -H180m -N7 -RTS  322.98s user
 132.37s system 132% cpu 5:44.65 total
 
 Now, this probably looks totally awful from a scalability POV. And,
 well, yeah, it is. But I am almost 100% certain there is something
 extremely screwy going on with my machine here. I base this on the
 fact that during gc_bench, kernel_task was eating up about ~600% of my
 CPU consistently, giving user threads no time to run. I've noticed
 this with other applications that were totally unrelated too (close
 tweetbot - 800% CPU usage,) so I guess it's time to learn DTrace. Or
 turn it on and off again or something. Ugh.
 
 Anyway, if you look at the user times, you get a nice 30% speedup
 which is about what we expect!

I'm very glad to hear that!

Manuel


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

Re: status of template haskell + cross compiling plans for 7.8?

[Manuel M T Chakravarty]

Carter,

As you can imagine, I would be extremely happy about cross-compilation support 
for TH. However, I don't know of anybody working on it at the moment, 
unfortunately.

Manuel

Carter Schonwald carter.schonw...@gmail.com:
 Hey All,
 Whats the story planned for template haskell + cross compiler support come 
 ghc 7.8?
 I understand theres a lot of Template Haskell design underway, some of which 
 will help support tools like Manuel's Inline-Objective-C work. Does this mean 
 that factored out within this reorganization is a better story for cross 
 compilation? 
 
 Especially since one kill app for the Inline-Objective-C template haskell 
 work would be writing IOS applications. Though I guess that also touches on 
 the need to sort out supporting FAT ARM binaries too, right?
 
 This intersects with a few different large subsets of tickets, so i'm not 
 sure if any single ticket is the right fora for this question.
 
 thanks!
 -Carter
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs


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

Re: how to checkout proper submodules

[Manuel M T Chakravarty]

I agree with Austin and Johan. It's a bizarre setup. Submodules have their pain 
points (which we already have to deal with), but the ability to properly 
snapshot and branch the whole tree would be a serious benefit IMO.

Manuel

PS: While we are at it, why don't we just have the main repos on GitHub and use 
forks and pull requests like the rest of the world? (Using Git, but not 
GitHub's superb infrastructure, seems like a terrible waste to me.)

Simon Peyton-Jones simo...@microsoft.com:
 For the avoidance of doubt, I totally support what Austin and Johan are 
 saying:
 
 I find the current setup confusing too.
 
 I'm totally persuaded of the merits of git bisect etc.
 
 I am the opposite of a git power-user (a git weedy-user?).  I will be content 
 to do whatever I'm told workflow-wise, provided I am told clearly in words of 
 one syllable.
 
 I *very strongly* want to reduce barriers to entry for would-be contributors, 
 and this is clearly a barrier we could lower.  Making Kazu, Austin, Johan, 
 etc more productive is massively valuable.
 
 There may be some history to how we arrived at this point, but that should 
 not constrain for the future.  We can change our workflow.   I would want Ian 
 and Simon to be thoroughly on board, but I regard the current setup as 
 totally open to improvement.  Please!
 
 BTW, Ian has written it up quite carefully here: 
 http://hackage.haskell.org/trac/ghc/wiki/Repositories, and the linked page 
 http://hackage.haskell.org/trac/ghc/wiki/Repositories/Upstream. 
 
 Simon
 
 
 
 | -Original Message-
 | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
 | On Behalf Of Austin Seipp
 | Sent: 05 June 2013 07:35
 | To: Johan Tibell
 | Cc: ghc-devs@haskell.org
 | Subject: Re: how to checkout proper submodules
 | 
 | I absolutely agree here, FWIW. We should only do this if there is a
 | clear consensus on doing so and everyone doing active development is
 | comfortable with it. And it's entirely possible submodules are
 | inadequate for some reason that I'm not aware of which is a
 | show-stopper.
 | 
 | However, the notion of impact-on-contributors cuts both ways. GHC has
 | an extremely small team of hackers as it stands, and we are lucky to
 | have *amazing* contributors like Kazu, Andreas, yourself, Simon 
 | Simon, and numerous others help make GHC what it is. Much of this is
 | volunteer work. But as the Haskell community grows, and we are at a
 | loss of other full-time contributors like Simon Marlow, I think we are
 | beginning to see the strain on GHC and its current contributors. So,
 | it's important to evaluate what we're doing right and wrong. This
 | feedback loop is always present even if seasoned contributors can live
 | with it - but new contributors will definitely be impacted.
 | 
 | In this instance, I honestly find it disheartening that the answer to
 | things like getting older revisions of the source code in HEAD, or
 | techniques like bisection is basically that doesn't work. The second
 | is unfortunate, but the latter is pretty legitimately worrying. It
 | would be one thing if this was a one-off occurrence of some odd
 | developer-workflow. But I have answered the fundamental question here
 | (submodules vs free-floating clones) a handful of times myself at
 | least, experienced the pain of the decision myself when doing
 | rollbacks, and I'm sure other contributors can say the same.
 | 
 | GHC is already a large, industry-strength software project with years
 | of work put behind it. The barrier to entry and contribution is not
 | exactly small, but I think we've all done a good job. I'd love to see
 | more people contributing. But I cannot help but find these discussions
 | a bit sad, where contributors are impaired due to regular/traditional
 | development workflows like rollbacks are rendered useless - due to
 | some odd source control discrepancy that nobody else on the planet
 | seems to suffer from.
 | 
 | I guess the short version is basically that that you're absolutely
 | right: the time of Simon, Ian, and other high-profile contributors is
 | *extremely* important. But I'd also rather not have people like Kazu
 | potentially spend hours or even days doing what simple automation can
 | achieve in what is literally a few keystrokes, and not only that - par
 | for the course for other projects. This ultimately impacts the
 | development cycles of *everybody*. And even if Kazu deals with it -
 | what about the next person?
 | 
 | On Wed, Jun 5, 2013 at 12:12 AM, Johan Tibell johan.tib...@gmail.com
 | wrote:
 |  The latest git release has improved submodules support some so if we now
 |  thing the benefits of submodules outweigh the costs we can discuss if we
 |  want to change to policy. I don't want to make that decision for other GHC
 |  developers that spend much more time on GHC than I (e.g. SPJ). Their
 |  productivity is more important than any inconveniences the lack of
 |  consistent use of submodules 

Re: how to checkout proper submodules

[Manuel M T Chakravarty]

David Terei davidte...@gmail.com:
 On 5 June 2013 01:43, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote:
 I agree with Austin and Johan. It's a bizarre setup. Submodules have their 
 pain points (which we already have to deal with), but the ability to properly 
 snapshot and branch the whole tree would be a serious benefit IMO.
 
 Manuel
 
 PS: While we are at it, why don't we just have the main repos on GitHub and 
 use forks and pull requests like the rest of the world? (Using Git, but not 
 GitHub's superb infrastructure, seems like a terrible waste to me.)
 
 I'd be all for this. We partially use the GitHub infrastructure since trac 
 broke and I changed the emails to point to GitHub instead. I also often do 
 code reviews with other devs on a personal GHC fork on github before merging 
 in.
 
 I believe it would also help encourage more contributors (especially for 
 libraries) but others have expressed disagreement with this point of view in 
 the past and I'm not in hold of data.

For the compiler, the barriers to contribution are probably elsewhere, but for 
the libraries, I'm sure, it would lower the barrier to entry. For example, to 
fix some documentation, I personally would never bother to create a patch file 
and attach it to some Trac ticket (where I first have to create an account). In 
contrast, a pull request on GitHub is a matter of a few clicks.

Manuel

PS: Anybody who doubts this needs to post their GitHub account name, so we can 
check that they actually ever used GitHub properly ;)___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Why do Names defined in the current module lack a module name?

[Manuel M T Chakravarty]

Johan Tibell johan.tib...@gmail.com:
 On Tue, Apr 2, 2013 at 3:31 AM, Simon Peyton-Jones
 simo...@microsoft.com wrote:
 A bit, but it's still not clear to me exactly when user defined
 exported entities will have full (i.e. including module) names.
 
 Something that starts top-level may not finish up as top-level.  Nested 
 bindings are never qualified.
 
 After TidyPgm, externally-visible names (to the linker) are qualified, ones 
 local to the .o file are not.
 
 Here's my example program:
 
 ```haskell
 module Test
( mysum
) where
 
 import Data.List (foldl')
 
 import Import (imported)
 
 mysum :: [Int] - Int
 mysum xs = foldl' (+) imported xs
 ```
 
 As you see it has a top-level exported thing (mysum). My problem is
 that I'm traversing the type-checked AST (i.e. returned by
 `typecheckedSource module`) trying to collect all the names so I can
 index them for a code search project I'm working on. It's a bit
 similar to the GHC ctags/etags tool, except I'm trying to index all
 the source code.
 
 So for every Name I run into in the source code I need to figure out
 what kind of name it is. That's made quite tricky by the fact that
 name resolution isn't actually quite done by the time we have the
 typed AST (i.e. mysum ought to have the name Test.mysum, but it has
 the name mysum). I can try to implement this last resolution step
 myself, but then I need to understand how to identify names such as
 mysum above, while traversing the AST.

I'm not sure what information you are trying to collect, but if you can 
traverse the Core program after TidyPgm instead of the type checked AST, that 
would have all names cleaned up (as Simon wrote) and still have valid source 
positions.

Otherwise, there are predicates on 'Id's and 'Name's that determine their 
categories, e.g., 'isExportedId'. Just keep in mind that in GHC-speak a local 
'Id' is one that is defined in the currently compiled module. It may still be a 
top-level 'Id' that is exported. (Not your classic definition of local, I 
guess ;)

Manuel


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

Re: Restrictions on polytypes with type families

[Manuel M T Chakravarty]

Simon Peyton-Jones simo...@microsoft.com:
 isn't this moving directly into the territory of impredicative types?  
  
 Ahem, maybe you are right.  Impredicativity means that you can
   instantiate a type variable with a polytype
   
 So if we allow, say (Eq (forall a.a-a)) then we’ve instantiated Eq’s type 
 variable with a polytype.  Ditto Maybe (forall a. a-a).
  
 But this is only bad from an inference point of view, especially for implicit 
 instantiation.  Eg if we had
   class C a where
 op :: Int - a
  
 then if we have
   f :: C (forall a. a-a) =...
   f = ...op...
  
 do we expect op to be polymorphic??
  
 For type families maybe things are easier because there is no implicit 
 instantiation.  
  
 But I’m not sure

These kinds of issues are the reason that my conclusion at the time was (as 
Richard put it)

 Or, are
 | there any that are restricted because someone needs to think hard before
 | lifting it, and no one has yet done that thinking?

At the time, there were also problems with what the type equality solver was 
supposed to do with foralls.

 I know, for example,
 | that the unify function in types/Unify.lhs will have to be completed to
 | work with foralls, but this doesn't seem hard.

The solver changed quite a bit since I rewrote Tom's original prototype. So, 
maybe it is easy now, but maybe it is more tricky than you think. The idea of 
rewriting complex terms into equalities at the point of each application of a 
type synonym family (aka type function) assumes that you can pull subterms out 
of a term into a separate equality, but how is this going to work if a forall 
is in the way?  E.g., given

  type family F a :: *

the equality

  Maybe (forall a. F [a]) ~ G b

would need to be broken down to

  x ~  F [a], Maybe (forall a. x) ~ G b

but you cannot do that, because you just moved 'a' out of its scope. Maybe you 
can move the forall out as well?

Manuel



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

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Peyton-Jones simo...@microsoft.com:
 |   You may ask what use is a GHC release that doesn't cause a wave of 
 updates?
 |  And hence that doesn't work with at least some libraries.  Well, it's a 
 very useful
 |  forcing function to get new features actually out and tested.
 |  
 |  But the way you test new features is to write programs that use them,
 |  and programs depend on libraries.
 
 That is of course ideal, but the ideal carries costs.  A half way house is a 
 release whose library support will be patchy.  Not such good testing, but 
 much lower costs.  But still (I think) a lot more testing than compile HEAD 
 gives us.

I don't think so. In my experience, library support is not patchy, but 
virtually non-existent as some of the very widely used libraries (like Text) 
break, and everything else depends on them in one way or another.

If we don't make sure that the commonly used libraries work with these 
preview releases, I don't think those releases are worth the effort.

I understand that we can't really guarantee API backwards compatibility for the 
GHC API (but that's ok as few packages depend on that). Critical are all the 
libraries bundled with GHC. Adding to them is fine, but no API definitions 
should change or be removed.

Manuel


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

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Peyton-Jones simo...@microsoft.com:
 If there's a path to having a release strategy as Manuel suggests, and having 
 an intermediate release  with the new vector primops, type extensions and 
 such goodness, then I'm all for it.  A lot of these bits are things ill start 
 using almost immediately in production / real software, esp if I'm not 
 needing to patch every stable library beyond maybe relaxing versioning 
 constraints.
 
 Let me suggest once more a possible path, along the lines you suggest
 ·For people who value stability: use the Haskell Platform.  Ignore 
 GHC releases.
 ·For people who want as many features as possible: use GHC releases.
 ·For people who want to live on the bleeding edge: build HEAD from 
 source
  
 The Haskell Platform decides which GHC release to use, advertises that to 
 package authors who do whatever updates are needed.  HP may perfectly 
 sensibly skip an entire release entirely.
  
 In short, I think we already have the situation that you desire.  Perhaps we 
 just need to market it better? 
  
 Or am I mistaken?

There is one kink: for GHC releases to be *useful* substitutes for the HP for 
people who want medium stability, they must not change (expect maybe add to) 
the APIs in GHC versions that do not coincide with HP releases. 

Why? If they change APIs, many of the packages on Hackage will not build with 
these intermediate GHC releases, which makes them useless for anything, but 
testing GHC.

Otherwise, I am perfectly happy with your suggestion. However, this is not the 
status quo. All (major) GHC releases do break critical packages on Hackage.

Manuel


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

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

I completely agree with Johan. The problem is to change core APIs too fast. 
Adding, say, SIMD instructions or having a new type extension (that needs to be 
explicitly activated with a -X option) shouldn't break packages.

I'm all for restricting major API changes to once a year, but why can't we have 
multiple updates to the code generator per year or generally release that don't 
affect a large number of packages on Hackage?

Manuel

Johan Tibell johan.tib...@gmail.com:
 On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote:
 For a while we've been doing one major release per year, and 1-2 minor 
 releases.  We have a big sign at the top of the download page directing 
 people to the platform.  We arrived here after various discussions in the 
 past - there were always a group of people that wanted stability, and a 
 roughly equally vocal group of people who wanted the latest bits.  So we 
 settled on one API-breaking change per year as a compromise.
 
 Since then, the number of packages has ballooned, and there's a new factor in 
 the equation: the cost to the ecosystem of an API-breaking release of GHC.  
 All that updating of packages collectively costs the community a lot of time, 
 for little benefit.  Lots of package updates contributes to Cabal Hell.  The 
 package updates need to happen before the platform picks up the GHC release, 
 so that when it goes into the platform, the packages are ready.
 
 So I think, if anything, there's pressure to have fewer major releases of 
 GHC.  However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 
 was 6 months, 7.4 to 7.6 was 7 months.  We're getting too efficient at making 
 releases!
 
 I think we want to decouple GHC major releases (as in, we did lots of work) 
 from API breaking releases. For example, GCC has lots of major (or big) 
 releases, but rarely, if ever, break programs.
 
 I'd be delighted to see a release once in a while that made my programs 
 faster/smaller/buggy without breaking any of them.
 
 -- Johan

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

Re: [commit: ghc] master: Follow random submodule change (ca5d15a)

[Manuel M T Chakravarty]

Ian,

That still doesn't work:

 Cloning into 'libraries/random'...
 fatal: reference is not a tree: 2117e38729adaa4f465f3c5b7a8c5c4d77702d3f
 Unable to checkout '2117e38729adaa4f465f3c5b7a8c5c4d77702d3f' in submodule 
 path 'libraries/random'

Also: http://darcs.haskell.org/ghcBuilder/builders/tn23/826/3.html

Manuel


Ian Lynagh ig...@earth.li:
 Repository : ssh://darcs.haskell.org//srv/darcs/ghc
 
 On branch  : master
 
 http://hackage.haskell.org/trac/ghc/changeset/ca5d15a61c45d6ea763872df46efe5c7b33f8186
 
 ---
 
 commit ca5d15a61c45d6ea763872df46efe5c7b33f8186
 Author: Ian Lynagh ig...@earth.li
 Date:   Sun Feb 3 16:29:17 2013 +
 
Follow random submodule change
 
 ---
 
 libraries/random |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/libraries/random b/libraries/random
 index 69bfde2..2117e38 16
 --- a/libraries/random
 +++ b/libraries/random
 @@ -1 +1 @@
 -Subproject commit 69bfde219bab869729fdbe9c1496371f912bf41e
 +Subproject commit 2117e38729adaa4f465f3c5b7a8c5c4d77702d3f
 
 
 
 ___
 ghc-commits mailing list
 ghc-comm...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-commits


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