Re: Decorating exceptions with backtrace information

[Michael Sloan]

Thanks so much for making a proposal for this, Ben!!  It's great to see
progress here.

I'm also glad that there is now a proposal process.  I made a fairly
similar proposal almost exactly 5 years ago to the libraries list -
https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but
without the subtlety of particular backtrace representations.  Skimming the
ensuing thread may still be informative.

In particular, there is one thing I would like to highlight from that old
proposal.  I think it'd be good to have a standard way to represent a chain
of exceptions, and build this into `catch` and `finally`.  Python and Java
both have a mechanism for this, and both refer to it as a "cause"
exception.  When an exception is thrown during exception handling, the
exception being handled is preserved as its "cause".  I find this mechanism
to be incredibly useful in Java, it has made the underlying issue much
clearer in many cases, and in other cases at least provides helpful
context.  I have no doubt such a mechanism would have saved me many hours
of debugging exceptions in Haskell systems I've worked on in the past.

I considered commenting about that directly on the proposal, but I figure
this is a better place to suggest expanding the scope of the change :) .
Totally understandable if you want to keep this proposal focused on
stacktraces, but I think it'd be good to consider this as a potential
future improvement.

-Michael

On Thu, May 7, 2020 at 3:55 PM Ben Gamari  wrote:

>
> Hi everyone,
>
> After a nice discussion on IRC about the unfortunate state of error
> reporting in Haskell, I felt compelled to write down some long-lingering
> thoughts regarding backtraces on exceptions. The result is GHC proposal
> #330 [1]. I think the approach is viable and perhaps even
> straightforward. I have the sketch of an implementation here [2].
>
> Please have a look at the proposal and leave your comments. If there is
> consensus it is possible that we could have this done for 8.12.
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330
> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236
> ___
> 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 and improved ghc-in-ghci target

[Michael Sloan]

Cool!  That's very nice that it only takes a few minutes from a clean tree.

I sometimes find it useful to also be able to run code from the repl.
Might be good to support both usage modes via hadrian.  Though,
perhaps it's sufficient to have both this and
`utils/ghc-in-ghci/run.sh`

-Michael

On Tue, Mar 12, 2019 at 6:31 AM Matthew Pickering
 wrote:
>
> Hi all,
>
> My patch to improve the ghc-in-ghci target just got merged a few
> minutes ago. Now from a clean tree it  only takes a few minutes to
> launch the target. You can now load ghc into ghci by running the
> following script:
>
> ./hadrian/ghci.sh
>
> https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian#fast-feedback-using-ghci
>
> Please try it out and open tickets if there are any issues on your system.
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work

[Michael Sloan]

Ah, probably so, thanks!

On Sat, Mar 9, 2019 at 6:05 PM Brandon Allbery  wrote:
>
> I think the public name is pointed to the staging site because the main one 
> is down for the trac to github migration.
>
> On Sat, Mar 9, 2019 at 8:59 PM Michael Sloan  wrote:
>>
>> Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also
>> trying to use the gitlab.staging.haskell.org cert.  I can't get chrome
>> to ignore the cert error because it's using HSTS - HTTP Strict
>> Transport Security.
>>
>> On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan  wrote:
>> >
>> > I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 
>> > machine:
>> >
>> > > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server 
>> > > certificate verification failed. CAfile: 
>> > > /etc/ssl/certs/ca-certificates.crt CRLfile: none
>> >
>> > Chrome also believes that the certificate of
>> > https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the
>> > "Proceed to ... (unsafe)" link.  Chrome's certificate viewer shows
>> > that the certificate is for "gitlab.staging.haskell.org" whereas the
>> > domain is "gitlab.haskell.org", so I'm guessing that's the problem.
>> > I'm not very experienced with such cert stuff, but  perhaps a wildcard
>> > cert like "*.haskell.org" could allow using the same cert regardless
>> > of whether it's on staging vs prod.
>> >
>> > For now I've just done "git config --global http.sslverify false"
>> > temporarily to do the pull.  Perhaps this is Shayne Fletcher's cheeky
>> > workaround? :)
>> >
>> > -Michael
>> >
>> > On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari  wrote:
>> > >
>> > > Shayne Fletcher via ghc-devs  writes:
>> > >
>> > > > I appreciate this isn't really "our" problem :) Nonetheless, if 
>> > > > there's any
>> > > > config we can do on the repo on gitlab, that would be cool. Other URLs
>> > > > (like github) for example are fine - something specific to gitlab.
>> > > >
>> > > I feel like I'm missing something here. I recall you mentioned this in
>> > > your previous message but there I'm still lacking crucial context. Can
>> > > you offer any additional details? How exactly does it fail?
>> > >
>> > > In principle there is no reason why cloning from gitlab.haskell.org from
>> > > Travis shouldn't work. I'd be happy to fix the issue if there is one but
>> > > without knowing more I'm pretty powerless to change the situation.
>> > >
>> > > 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
>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work

[Michael Sloan]

Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also
trying to use the gitlab.staging.haskell.org cert.  I can't get chrome
to ignore the cert error because it's using HSTS - HTTP Strict
Transport Security.

On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan  wrote:
>
> I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine:
>
> > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server 
> > certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
> > CRLfile: none
>
> Chrome also believes that the certificate of
> https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the
> "Proceed to ... (unsafe)" link.  Chrome's certificate viewer shows
> that the certificate is for "gitlab.staging.haskell.org" whereas the
> domain is "gitlab.haskell.org", so I'm guessing that's the problem.
> I'm not very experienced with such cert stuff, but  perhaps a wildcard
> cert like "*.haskell.org" could allow using the same cert regardless
> of whether it's on staging vs prod.
>
> For now I've just done "git config --global http.sslverify false"
> temporarily to do the pull.  Perhaps this is Shayne Fletcher's cheeky
> workaround? :)
>
> -Michael
>
> On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari  wrote:
> >
> > Shayne Fletcher via ghc-devs  writes:
> >
> > > I appreciate this isn't really "our" problem :) Nonetheless, if there's 
> > > any
> > > config we can do on the repo on gitlab, that would be cool. Other URLs
> > > (like github) for example are fine - something specific to gitlab.
> > >
> > I feel like I'm missing something here. I recall you mentioned this in
> > your previous message but there I'm still lacking crucial context. Can
> > you offer any additional details? How exactly does it fail?
> >
> > In principle there is no reason why cloning from gitlab.haskell.org from
> > Travis shouldn't work. I'd be happy to fix the issue if there is one but
> > without knowing more I'm pretty powerless to change the situation.
> >
> > 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: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work

[Michael Sloan]

I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine:

> fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server 
> certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
> CRLfile: none

Chrome also believes that the certificate of
https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the
"Proceed to ... (unsafe)" link.  Chrome's certificate viewer shows
that the certificate is for "gitlab.staging.haskell.org" whereas the
domain is "gitlab.haskell.org", so I'm guessing that's the problem.
I'm not very experienced with such cert stuff, but  perhaps a wildcard
cert like "*.haskell.org" could allow using the same cert regardless
of whether it's on staging vs prod.

For now I've just done "git config --global http.sslverify false"
temporarily to do the pull.  Perhaps this is Shayne Fletcher's cheeky
workaround? :)

-Michael

On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari  wrote:
>
> Shayne Fletcher via ghc-devs  writes:
>
> > I appreciate this isn't really "our" problem :) Nonetheless, if there's any
> > config we can do on the repo on gitlab, that would be cool. Other URLs
> > (like github) for example are fine - something specific to gitlab.
> >
> I feel like I'm missing something here. I recall you mentioned this in
> your previous message but there I'm still lacking crucial context. Can
> you offer any additional details? How exactly does it fail?
>
> In principle there is no reason why cloning from gitlab.haskell.org from
> Travis shouldn't work. I'd be happy to fix the issue if there is one but
> without knowing more I'm pretty powerless to change the situation.
>
> 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: Reproducing bugs without Stack

[Michael Sloan]

I don't have a good answer to your overall question, particularly when
reproducing the issue necessarily requires a large set of build
dependencies.  However, one thing that may be helpful is to use `stack
build --cabal-verbose`.  This will pass `--verbose` when running
Setup.hs, and ghc invocations are included in its verbose output.

Assuming your terminal's current dir is the package that the ghc
invocation is building, and the dependencies are built, you can run
paste the ghc invocation after `stack exec -- ` and it should work.
So, for example:

```
stack exec -- /home/mgsloan/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc
--make -no-link -fbuilding-cabal-package ...
```

Then, perhaps you can try removing arguments of the ghc invocation to
attempt to arrive at a more minimal reproduction.

-Michael

On Sat, Jan 19, 2019 at 9:08 PM Eric Crockett  wrote:
>
> Devs,
>
> I use Stack for all of my Haskell development. I recently ran into several 
> bugs, which I suspected to be GHC bugs. In the process of creating new 
> tickets, I noticed a banner reading "Please try to provide reproduction 
> instructions which do not require "Stack"." The request is reasonable to help 
> weed out bugs in Stack itself, but I could use some advice on how to do that.
>
> In particular, I'm having trouble reproducing bugs related to profiling. For 
> example, #16182 is about runtime crashes with the -hr profiling option. This 
> was clearly a GHC bug rather than a problem with stack, yet I have so far 
> been unable to produce the bug without Stack. Similarly, for #16166, I filed 
> the ticket, then after failing to reproduce the bug with cabal, assumed it 
> must be a stack bug. Fortunately, RyanGlScott noticed and was able to confirm 
> that it is in fact a GHC bug. Ryan explained that my problem reproducing with 
> cabal is due to differences in the profiling options used by stack and cabal.
>
> In summary, it would be helpful to have some instructions on how to take a 
> bug produced using Stack to one produced without. For example, if `stack 
> build [--profile] foo` produces a compile bug, how should I use cabal to 
> definitively determine if the bug is a problem with Stack or GHC? Presumably 
> it would begin with `cabal sandbox init`. Are there special options to put in 
> the cabal.config file so that cabal uses the same profiling options as stack? 
> Will those options be used when building all dependencies?
>
> Thanks,
> Eric Crockett
> ___
> 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: Understanding bind in template haskell

[Michael Sloan]

Hi Yotam,

Template Haskell expression quotes must start with either `[|` or
`[e|`, but instead these start with `[e |` - note the space. They are
list comprehensions which filter to just the elements of `es` that
match the `(dL -> L _ (Present _ e))`.  Also, the `dL -> ...` portion
is a view pattern that is equivalent to `id`, since since the
arguments are already wrapped in `L`.

For something like `runQ [| Foo b <- Foo 1 |]` to work, there'd need
to be a quotation for `Stmt`, but there are only quotations for `Exp`
/ `[Dec]` / `Type` / `Pat`.

I hope that's helpful!

-Michael


On Sat, Dec 8, 2018 at 3:30 AM Yotam Ohad  wrote:
>
> Hi,
> In the function DsMeta.repE there is a format being repeated:
> For example in:
>
> repE e@(ExplicitTuple _ es boxed)
>   | not (all tupArgPresent es) = notHandled "Tuple sections" (ppr e)
>   | isBoxed boxed = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es]
>; repTup xs }
>   | otherwise = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es]
>; repUnboxedTup xs }
>
> There is  `(dL->L _ (Present _ e)) <- es`. I don't understand how this type 
> checks correctly.
> If I'll try to do
>
>  data Foo a = Foo a
> runQ [| Foo b <- Foo 1 |]
>
> in ghciI get an error. What is the difference?
>
> Yotam
> ___
> 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-in-ghci memory usage

[Michael Sloan]

Great, I'm glad it's working well for you!

I've realized that when working on ghc-in-ghci, I didn't know about
freezing stage 1 to speed up GHC builds.  For me the primary
motivation was that otherwise builds took quite long.  Of course,
ghc-in-ghci is still quite useful, due to being able to use the repl,
avoiding static link times, etc.

I'm not sure what the best way would be to effectively communicate
with newcomers about freezing stage 1, but it seems important for
build times.  It may be easy to get dissuaded if every development
iteration involves a ton of waiting for the build.  Perhaps hadrian
can be more intelligent about avoiding stage 1 rebuilds?  I realize
that's likely to be tricky from a correctness perspective.

One thing I'm keen on for ghc-in-ghci is getting it to load without
-fobject-code.  This would often mean a much longer initial start (no
use of stored object files), but should make reloads quite a lot
faster, since it's generating bytecode instead.  The main tricky bit
there is the use of unboxed tuples, since ghci cannot bytecode-compile
code that uses them.  So, this either means adding support for unboxed
tuples to bytecode, which seems quite challenging, or having something
clever that only uses object-code compilation where needed.

-Michael

On Tue, Oct 30, 2018 at 7:56 AM Matthew Pickering
 wrote:
>
> I just tried using the ghc-in-ghci script again and it appears that
> the memory usage problems have been resolved. Probably thanks to Simon
> Marlow who fixed a lot of space leaks in ghc.
>
> A reminder of how to use it:
>
> ./utils/ghc-in-ghci/run.sh -j
>
> will load ghc into ghci so you can `:r` to recompile when you make a change.
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations

[Michael Sloan]

Good point, I have added a note about it to the wiki page.  Surprising
that it would be hard to kill.  Do you have swap setup?

For me it takes ~2.7GB initially and 3.5GB after the first reload.  In
the past I've seen it get all the way up to 9GB so there may be some
memory leakage.

I have 40GB of ram in my laptop, so I don't notice this much.  I
highly recommend investing in more memory if it's within your
financial means.  The productivity boon of being able to use GHCi on
large projects, or run multiple concurrent docker containers or VMs,
is huge.

A bit off topic, but sometimes folks are surprised that I spend
hundreds of dollars on keyboards like the kinesis advantage 2 (which
is fantastic, btw) or the keyboard.io (really nice too!).  My answer
is that if I'm using some equipment many hours per day, the cost
amortizes out.  I ask myself "Would I pay 3 cents to use this keyboard
for an hour?", in the case of those keyboards, my answer is an
emphatic YES!  I apply similar reasoning to my main computer hardware,
though people are used to that being $$$ vs the surprise of $350
keyboards.

-Michael

On Wed, Aug 8, 2018 at 3:31 PM, Matthew Pickering
 wrote:
> In practice, how much memory does this use?
>
> I find that with 4gb of memory that it is unusable and hard to kill.
> Perhaps we should add some sort of warning to the page about this.
>
> Cheers
>
> Matt
>
> On Wed, Aug 8, 2018 at 11:12 PM, Michael Sloan  wrote:
>> Now that [D5015] is merged (thanks, monoidal!), -fobject-code no
>> longer needs to be provided manually.  This also means that you can
>> run [ghcid] directly in the root of the repo without any arguments.  I
>> have updated https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci to
>> use the simpler invocations.
>>
>> [D5015]: https://phabricator.haskell.org/D5015
>> [ghcid]: https://github.com/ndmitchell/ghcid
>>
>> On Mon, Aug 6, 2018 at 1:03 AM, Michael Sloan  wrote:
>>> Thanks a bunch for updating the wiki page, Artem!  It was on my todo
>>> list, but it's been a rather busy week.  I've added an update
>>> mentioning that it will be possible to run "ghcid" directly without
>>> args once D5105 is merged.
>>>
>>> On Mon, Aug 6, 2018 at 12:55 AM, Artem Pelenitsyn
>>>  wrote:
>>>> I added this to the wiki. It would be nice to have a wrapper similar to
>>>> `run.sh` but for starting ghcid, I believe.
>>>>
>>>> --
>>>> Best wishes,
>>>> Artem
>>>>
>>>> On Sun, 29 Jul 2018 at 10:41 Matthew Pickering 
>>>> 
>>>> wrote:
>>>>>
>>>>> Can you please update the wiki page?
>>>>>
>>>>> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci
>>>>>
>>>>> Matt
>>>>>
>>>>> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan  wrote:
>>>>> > Hello GHC developers!
>>>>> >
>>>>> > Now that D4904 and D4986 are merged, if you have recently built GHC
>>>>> > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load
>>>>> > GHC into GHCi (throwing on a "-j8" helps too).  For me, this makes
>>>>> > development far more pleasant, as often I can make a change and try it
>>>>> > out in only 15 or 20 seconds.  Thanks to Csongor Kiss for writing the
>>>>> > initial ghci script, and Matthew Pickering for posting about it to the
>>>>> > mailinglist, as otherwise I probably wouldn't have known about it.
>>>>> >
>>>>> > I wrote a blog post about the topic on my new blog:
>>>>> > http://www.mgsloan.com/posts/ghcinception/
>>>>> >
>>>>> > Once D5015 is merged, the explicit "-fobject-code" won't be needed.
>>>>> > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it
>>>>> > might not be needed at all, leading to even faster loading ;)
>>>>> >
>>>>> > Happy ghci-ing!
>>>>> > -Michael
>>>>> > ___
>>>>> > 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: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations

[Michael Sloan]

Now that [D5015] is merged (thanks, monoidal!), -fobject-code no
longer needs to be provided manually.  This also means that you can
run [ghcid] directly in the root of the repo without any arguments.  I
have updated https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci to
use the simpler invocations.

[D5015]: https://phabricator.haskell.org/D5015
[ghcid]: https://github.com/ndmitchell/ghcid

On Mon, Aug 6, 2018 at 1:03 AM, Michael Sloan  wrote:
> Thanks a bunch for updating the wiki page, Artem!  It was on my todo
> list, but it's been a rather busy week.  I've added an update
> mentioning that it will be possible to run "ghcid" directly without
> args once D5105 is merged.
>
> On Mon, Aug 6, 2018 at 12:55 AM, Artem Pelenitsyn
>  wrote:
>> I added this to the wiki. It would be nice to have a wrapper similar to
>> `run.sh` but for starting ghcid, I believe.
>>
>> --
>> Best wishes,
>> Artem
>>
>> On Sun, 29 Jul 2018 at 10:41 Matthew Pickering 
>> wrote:
>>>
>>> Can you please update the wiki page?
>>>
>>> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci
>>>
>>> Matt
>>>
>>> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan  wrote:
>>> > Hello GHC developers!
>>> >
>>> > Now that D4904 and D4986 are merged, if you have recently built GHC
>>> > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load
>>> > GHC into GHCi (throwing on a "-j8" helps too).  For me, this makes
>>> > development far more pleasant, as often I can make a change and try it
>>> > out in only 15 or 20 seconds.  Thanks to Csongor Kiss for writing the
>>> > initial ghci script, and Matthew Pickering for posting about it to the
>>> > mailinglist, as otherwise I probably wouldn't have known about it.
>>> >
>>> > I wrote a blog post about the topic on my new blog:
>>> > http://www.mgsloan.com/posts/ghcinception/
>>> >
>>> > Once D5015 is merged, the explicit "-fobject-code" won't be needed.
>>> > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it
>>> > might not be needed at all, leading to even faster loading ;)
>>> >
>>> > Happy ghci-ing!
>>> > -Michael
>>> > ___
>>> > 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: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations

[Michael Sloan]

Thanks a bunch for updating the wiki page, Artem!  It was on my todo
list, but it's been a rather busy week.  I've added an update
mentioning that it will be possible to run "ghcid" directly without
args once D5105 is merged.

On Mon, Aug 6, 2018 at 12:55 AM, Artem Pelenitsyn
 wrote:
> I added this to the wiki. It would be nice to have a wrapper similar to
> `run.sh` but for starting ghcid, I believe.
>
> --
> Best wishes,
> Artem
>
> On Sun, 29 Jul 2018 at 10:41 Matthew Pickering 
> wrote:
>>
>> Can you please update the wiki page?
>>
>> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci
>>
>> Matt
>>
>> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan  wrote:
>> > Hello GHC developers!
>> >
>> > Now that D4904 and D4986 are merged, if you have recently built GHC
>> > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load
>> > GHC into GHCi (throwing on a "-j8" helps too).  For me, this makes
>> > development far more pleasant, as often I can make a change and try it
>> > out in only 15 or 20 seconds.  Thanks to Csongor Kiss for writing the
>> > initial ghci script, and Matthew Pickering for posting about it to the
>> > mailinglist, as otherwise I probably wouldn't have known about it.
>> >
>> > I wrote a blog post about the topic on my new blog:
>> > http://www.mgsloan.com/posts/ghcinception/
>> >
>> > Once D5015 is merged, the explicit "-fobject-code" won't be needed.
>> > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it
>> > might not be needed at all, leading to even faster loading ;)
>> >
>> > Happy ghci-ing!
>> > -Michael
>> > ___
>> > 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

Scripts merged for easily loading and running GHC in GHCi, for fast development iterations

[Michael Sloan]

Hello GHC developers!

Now that D4904 and D4986 are merged, if you have recently built GHC
then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load
GHC into GHCi (throwing on a "-j8" helps too).  For me, this makes
development far more pleasant, as often I can make a change and try it
out in only 15 or 20 seconds.  Thanks to Csongor Kiss for writing the
initial ghci script, and Matthew Pickering for posting about it to the
mailinglist, as otherwise I probably wouldn't have known about it.

I wrote a blog post about the topic on my new blog:
http://www.mgsloan.com/posts/ghcinception/

Once D5015 is merged, the explicit "-fobject-code" won't be needed.
Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it
might not be needed at all, leading to even faster loading ;)

Happy ghci-ing!
-Michael
___
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)

[Michael Sloan]

Here is the diff adding ghci scripts and some related code changes:
https://phabricator.haskell.org/D4904

This has made development iterations drastically quicker for me, which
for me really lowers the friction to contribution.  All of my diffs in
the past week were developed by using ghc-in-ghci.

-Michael
On Wed, Jun 27, 2018 at 10:48 PM Michael Sloan  wrote:
>
> Wow!  This is an absolute game changer for me with regards to ghc
> development.  My usual workflow on large haskell projects is to use
> GHCI as much as possible for quick iterations.  I'm really glad
> Csongor figured this out and that you sent an email about it.
>
> I've been messing with this for a bit today, and after a few code
> changes, I can to load GHCI into GHCI!!  For example, I can modify
> "ghciWelcomeMessage", reload, and enter into the nested ghci:
>
> λ :r
> [491 of 492] Compiling GHCi.UI  ( ../ghc/GHCi/UI.hs, tmp/GHCi/UI.o )
> Ok, 492 modules loaded.
> λ :main -ignore-dot-ghci --interactive
> GHCi inception, version 8.7.20180627: http://www.haskell.org/ghc/  :? for help
> Prelude> unwords ["it", "works!"]
> "it works!"
> Prelude> :q
> Leaving GHCi.
> λ Prelude.unwords ["now,", "in", "outer", "GHCi"]
> "now, in outer GHCi"
>
> I will be opening up a PR soon that makes this convenient, once I've
> polished it up.
>
> -Michael
> On Wed, May 30, 2018 at 1:43 PM Matthew Pickering
>  wrote:
> >
> > Hi all,
> >
> > Csongor has informed me that he has worked out how to load GHC into
> > GHCi which can then be used with ghcid for a more interactive
> > development experience.
> >
> > 1. Put this .ghci file in compiler/
> >
> > https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c
> >
> > 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> > from inside compiler/
> >
> > It may take a while and require a little bit of memory but in the end
> > all 500 or so modules will be loaded.
> >
> > It can also be used with ghcid.
> >
> > ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> >
> > Hopefully someone who has more RAM than I.
> >
> > Can anyone suggest the suitable place on the wiki for this information?
> >
> > Cheers,
> >
> > Matt
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Michael Sloan]

Wow!  This is an absolute game changer for me with regards to ghc
development.  My usual workflow on large haskell projects is to use
GHCI as much as possible for quick iterations.  I'm really glad
Csongor figured this out and that you sent an email about it.

I've been messing with this for a bit today, and after a few code
changes, I can to load GHCI into GHCI!!  For example, I can modify
"ghciWelcomeMessage", reload, and enter into the nested ghci:

λ :r
[491 of 492] Compiling GHCi.UI  ( ../ghc/GHCi/UI.hs, tmp/GHCi/UI.o )
Ok, 492 modules loaded.
λ :main -ignore-dot-ghci --interactive
GHCi inception, version 8.7.20180627: http://www.haskell.org/ghc/  :? for help
Prelude> unwords ["it", "works!"]
"it works!"
Prelude> :q
Leaving GHCi.
λ Prelude.unwords ["now,", "in", "outer", "GHCi"]
"now, in outer GHCi"

I will be opening up a PR soon that makes this convenient, once I've
polished it up.

-Michael
On Wed, May 30, 2018 at 1:43 PM Matthew Pickering
 wrote:
>
> Hi all,
>
> Csongor has informed me that he has worked out how to load GHC into
> GHCi which can then be used with ghcid for a more interactive
> development experience.
>
> 1. Put this .ghci file in compiler/
>
> https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c
>
> 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> from inside compiler/
>
> It may take a while and require a little bit of memory but in the end
> all 500 or so modules will be loaded.
>
> It can also be used with ghcid.
>
> ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
>
> Hopefully someone who has more RAM than I.
>
> Can anyone suggest the suitable place on the wiki for this information?
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Michael Sloan]

On Wednesday, September 28, 2016, Eric Seidel  wrote:

> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> > Moritz Angermann > writes:
> >
> > > All that arc essentially does is, compute the diff from an offset
> > > (e.g. master) to the current HEAD and upload that to a new or existing
> > > (--update) differential. It also adds some meta information about the
> > > range, such that arc patch supposedly knows into which commit to apply
> > > the patch to.
> > >
> > Sure, but this leads to generally unreviewable patches IMHO. In order to
> > stay sane I generally split up my work into a set of standalone patches
> > with git rebase and then create a Diff of each of these commits.
> > Phabricator supports this by having a notion of dependencies between
> > Diffs, but arcanist has no sensible scheme for taking a branch and
> > conveniently producing a series of Diffs.
>
> I completely understand how this would be frustrating for core
> contributors (more specifically for people submitting large patches),
> but for new or casual contributors it's actually quite freeing. I don't
> have to worry about how messy my local history gets, because arc will
> throw it all away regardless! It absolves me of an extra responsibility,
> and lowers the barrier to contributing.


I dislike this workflow because I am already used to doing a lot of git
rebasing / amending / auto squashing.  So using arc means taking away my
ability to write multi commit stories of how the change was crafted. For
large changes there are often multiple logical inter related steps.
Squashing them into one big commit makes it much harder to review.  I can
easily do that myself by marking everything as squash in a rebase. It feels
like arcanist is just taking away power, not giving it (note i have not
used it much - voice of a newbie here)

I am beginning to change my feelings on this, away from thinking of GitHub
as an auxilliary source of didferentials.  Instead perhaps GitHub's new
review system may be the way forward for GHC. It allows you to easily use
git in the way it's meant to be used.

-Michael


>
> It would be nice to support both workflows though :)
> ___
> 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: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari  wrote:
> That being said, I ultimately decided it would be easier to just
> continue carrying out this workflow by hand considering I don't post
> large series of patches *that* often. I'm also a bit more eager to
> squash now than I used to be, in part due to the pain of submitting
> fine-grained patch sets. On the whole I do wish that Phabricator were
> more Git-like.

Indeed, I do not know the details of phab / arc, but when encountering
them, the workflow seemed unlike ordinary git workflows.  It felt like
it is working hard to implement an atypical git workflow, and learning
this new workflow takes work.  From the perspective of a contributor,
it seemed strange since git's usual workflows are wildly successful
and popular.  Granted, it is easy for people to screw those up too,
such as by using "git pull" instead of "git pull --rebase" orso.

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

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

[Michael Sloan]

Exactly!  So we will be using Phabricator for the review process, but
with the github PRs you can use plain git.  This means that new
contributors will only need to learn about phabricator, and arc will
be non-mandatory though probably recommended.

Glad you like the idea :)

-Michael

On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg <r...@cs.brynmawr.edu> wrote:
> So you're suggesting that GitHub would function as a sort of alternate 
> front-end to Phab. While I've grown to enjoy Phab quite a bit, I still 
> strongly dislike arc, which tries to be too clever for my tastes. Provided 
> the integration works smoothly, I quite like this idea.
>
> Richard
>
>> On Sep 27, 2016, at 5:32 PM, Michael Sloan <mgsl...@gmail.com> wrote:
>>
>> You're welcome Richard!  I look forward to helping make it happen.  In
>> the other thread, Alexander Vershilov mentioned that we might instead
>> consider the following more straightforward workflow:
>>
>> 0) Have a bot that watches github for PRs.
>> 1) Submit whatever you want to github as a PR.
>> 2) It will be automatically closed and migrated to Phabricator.  I
>> would like it to automatically create a Phabricator account if you do
>> not already have one.  The message from the bot will tell you about
>> this action, and explain how to log in, perhaps even linking to
>> resources about Phabricator.
>>
>> Is this worth it?  I think it is for the one-off cases.  However, you
>> will have to be prepared that this means that people won't have
>> arcanist setup, and therefore are less likely to actually iterate on
>> their PR.  Perhaps we should extend this to the following:
>>
>> 3) Subsequent pushes to the branch for the PR will update the
>> Phabricator differential as if you had pushed via Arcanist.  I think
>> with this in place, we would have a fully streamlined system that
>> allows people to use their familiar GitHub workflows, without needing
>> to learn Arcanist.  Interactions would then still occur on , of
>> course.
>>
>> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
>> tool!  Could name the bot that, though!
>>
>> Thoughts?  I think it would be great for this to be proposed formally
>> soon so that we can make it happen.  I am eager to be able to use my
>> normal git workflows, as my little experience with Arcanist induced
>> some head-scratching.  Not the fault of the tool, just a result of
>> lack of familiarity.
>>
>> -Michael
>>
>> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg <r...@cs.brynmawr.edu> 
>> wrote:
>>> To sum up, this proposes the following:
>>>
>>> 1. Allow PRs on GitHub.
>>>
>>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks 
>>> interfacing between GitHub and Phab. This utility would be used only by GHC 
>>> HQ and not by contributors.
>>>
>>> 3. Small GitHub PRs can be merged directly, by ghc-hub.
>>>
>>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor 
>>> would be issued a polite email explaining how to set up a Phab account to 
>>> continue to follow their contribution.
>>>
>>> Have I captured this accurately? If so, a resounding +1 from me. I’ve 
>>> wanted exactly this for a while.
>>>
>>> Is this worth sending through ghc-proposals?
>>>
>>> Thanks for volunteering item (2), Michael!
>>>
>>> Richard
>>>
>>> -=-=-=-=-=-=-=-=-=-=-
>>> Richard A. Eisenberg
>>> Asst. Prof. of Computer Science
>>> Bryn Mawr College
>>> Bryn Mawr, PA, USA
>>> cs.brynmawr.edu/~rae
>>>
>>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty 
>>>> <c...@justtesting.org> wrote:
>>>>
>>>> Sounds like a great idea to me and might alleviate SimonM’s concerns about 
>>>> fragmentation of dev attention.
>>>>
>>>> Manuel
>>>>
>>>>> Michael Sloan <mgsl...@gmail.com>:
>>>>>
>>>>> 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 G

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

[Michael Sloan]

On Tue, Sep 27, 2016 at 6:49 PM, Moritz Angermann <mor...@lichtzwerge.de> wrote:
> Hi,
>
> I think it would be great if this was proposed formally. If we could
> integrate this with the improved ghc development proposal[1], this
> would be great! Or turn it into a separate proposal and remove the
> similar parts from the one mentioned.

Cool!  Should I do the integration?  I wouldn't mind if someone else
took these thoughts and integrated them, though I'd like to see how
they get integrated!

> However, on the topic, I’d like to share a few thoughts:
>
> Do we know how many of these GitHub Pull Requests we will actually
> receive? If we migrate *everything* over to phabricator, isn’t that
> just going to increase complexity for most of the minor pull request?

We don't know how many, hopefully lots, right?

What's the usual complexity for a minor patch to GHC - does it just
skip differential and end up getting committed directly to master?  In
that case, yes this would cause there to be a lot more differentials.
Is that a bad thing?  We could certainly consider something more like
the "ghc-hub" tool I've described elsewhere.  This would give more
direct control of what happens to GitHub PRs, but would also require
manual oversight of incoming GitHub PRs.

> If someone fixes a spelling mistake or adds a short comment to
> explain something in more detail, I see no reason why we need to employ
> any heavy machinery and duplication across different tools. These, so
> I would hope, would be trivially merged by a small team of ghc devs
> watching the GitHub PR, especially if we don’t even know how much PRs
> we will receive through GitHub.
>
> On the other hand, if a PR is non-trivial (yes this is a bit of an
> ambiguous term), I’m in favor of asking the person who issued the PR
> to open an account with Phabricator[2], and run `$ arc diff origin/master`
> on his branch, or let us know that he considers this too much effort
> (and is willing to have someone else take over, should there be interest).

> The reasoning behind this is the following: first of all it’s the persons
> work, and unless someone else is willing to take it through the review
> process, this is going to end up being a dead diff in phabricator which
> adds additional overhead there. If there is not enough interest to follow
> a simple few steps document on how to push a non-trivial patch to
> phabricator, can we expect there to be sufficient interest in actually
> following up on the review process?
>
> I see this more as an onboarding problem than a continuous development
> issue. Those who are in the phabricator workflow, will likely just
> continue using it, no? I certainly would! However I might be browsing
> ghc source on GH just because I don’t have that code locally available
> right now and stumble on a spelling mistake, quickly use the editor
> provided by GH and submit one of these trivial PRs.

Exactly!  GH has great support for creating trivial PRs.  It is also a
workflow people are familiar with.  As soon as you ask people to
install a piece of software and learn to use it (arcanist), there is
immediately a cognitive barrier.  Even if the software is easy to
learn.  I recall being confused about arcanist squashing, for example.
I haven't used it in a long time, so I don't recall details.

I can see the attitude of "Well, if you're hacking on GHC, you are
probably capable of learning some new tools."  This is true, but this
stuff is adding cognitive load atop the existing cognitive load of
creating a patch for GHC.

> Those who haven’t used phabricator yet, but are accustomed to the GH
> PR Flow, would start there and then be gently guided towards using
> phabricator and arc. We can do much better at explaining and showing
> the phabricator and arc workflow.

Yup!  That's how I see this as well.  It is leveraging GH PRs as an
easy way to attract contribution, but also guiding people towards
Phabricator.  As things stand, you need to learn both Phabricator and
Arcanist at the same time.  This way, we can start with onboarding
people with phabricator, and later get them to start using archanist
directly.  Some won't make it to that stage, but it will still be
valuable to get GH PRs from them!

> In essence I’d like us see accepting GH Pull Requests and then do
> more data-driven on-demand incremental improvements, instead of trying
> to go all out with excessive tooling.

This is a wise approach!  I think it makes sense to try the manual
labor version of this process before automating it.  Automation should
be on the minds of those doing the work, though, and they can be
reassured that it will get easier once automation is in place.

> Cheers,
>  Moritz
>
>
> [1]: 
> https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/proposals/00

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

[Michael Sloan]

You're welcome Richard!  I look forward to helping make it happen.  In
the other thread, Alexander Vershilov mentioned that we might instead
consider the following more straightforward workflow:

0) Have a bot that watches github for PRs.
1) Submit whatever you want to github as a PR.
2) It will be automatically closed and migrated to Phabricator.  I
would like it to automatically create a Phabricator account if you do
not already have one.  The message from the bot will tell you about
this action, and explain how to log in, perhaps even linking to
resources about Phabricator.

Is this worth it?  I think it is for the one-off cases.  However, you
will have to be prepared that this means that people won't have
arcanist setup, and therefore are less likely to actually iterate on
their PR.  Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the
Phabricator differential as if you had pushed via Arcanist.  I think
with this in place, we would have a fully streamlined system that
allows people to use their familiar GitHub workflows, without needing
to learn Arcanist.  Interactions would then still occur on , of
course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
tool!  Could name the bot that, though!

Thoughts?  I think it would be great for this to be proposed formally
soon so that we can make it happen.  I am eager to be able to use my
normal git workflows, as my little experience with Arcanist induced
some head-scratching.  Not the fault of the tool, just a result of
lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg <r...@cs.brynmawr.edu> wrote:
> To sum up, this proposes the following:
>
> 1. Allow PRs on GitHub.
>
> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks 
> interfacing between GitHub and Phab. This utility would be used only by GHC 
> HQ and not by contributors.
>
> 3. Small GitHub PRs can be merged directly, by ghc-hub.
>
> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor 
> would be issued a polite email explaining how to set up a Phab account to 
> continue to follow their contribution.
>
> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted 
> exactly this for a while.
>
> Is this worth sending through ghc-proposals?
>
> Thanks for volunteering item (2), Michael!
>
> Richard
>
> -=-=-=-=-=-=-=-=-=-=-
> Richard A. Eisenberg
> Asst. Prof. of Computer Science
> Bryn Mawr College
> Bryn Mawr, PA, USA
> cs.brynmawr.edu/~rae
>
>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty <c...@justtesting.org> 
>> wrote:
>>
>> Sounds like a great idea to me and might alleviate SimonM’s concerns about 
>> fragmentation of dev attention.
>>
>> Manuel
>>
>>> Michael Sloan <mgsl...@gmail.com>:
>>>
>>> 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 <mgsl...@gmail.com> 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 

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

[Michael Sloan]

On Mon, Sep 26, 2016 at 12:40 PM, Simon Marlow  wrote:
> On 26 September 2016 at 20:13, Ben Gamari  wrote:
>>
>> Simon Marlow  writes:
>>
>> > I would rather we *didn't* accept contributions via github, even for
>> > small
>> > patches, and instead put more effort into streamlining the Phabricator
>> > workflow.
>> >
>> >
>> >- Adding another input method complicates the workflow, users have to
>> >decide which one to use
>> >
>> I think we would want to try to sell the GitHub route as "if you would
>> like to contribute then we would strongly prefer you use Phabricator,
>> but if you must and it's a small patch, we will accept it via GitHub."
>
>
> But this is opening the floodgates a crack... how do we know what a "small"
> patch is?  What happens when someone submits a patch that's too large?  The
> patches will get larger, we'll have to do code reviews on two different
> tools, and it will be really hard to go back.  I just have a bad feeling
> about this.

I agree that this would certainly happen - people would get used to
the new workflow and want to use it for large patches.  I've said
similar things in a post I made to Carter's thread about a
ghc-simple-patch-propose list.  Please consider this approach:

If a patch requires substantial revision, move it to Phabricator.  How
do we know when it requires substantial revision?  There are two
conditions for this:

1) When it is clear to the reviewer that it will take multiple iterations

2) After a single iteration of review has occurred on GitHub, and
there is still more to do.

This way, any substantial review process will be captured as a differential.

We need a way to make this as easy and efficient as possible for
maintainers and contributors alike.  In particular, maintainer /
reviewer time is very valuable.  As such, I propose the following:

1) A tool called "ghc-hub", which supports "ghc-hub migrate URL", to
migrate a PR to a Differential, without migrating any review metadata
(to keep the implementation simple).  It would also support "ghc-hub
merge URL", .  Using PR URLs on the commandline like this is inspired
by github's hub tool - https://github.com/github/hub .

2) Eventually, have a GitHub bot which does the following:

  * Notices if a patch is particularly large, and recommends using the
"ghc-hub" tool to perform the migration.

  * Notices if a patch has already gone through a review and hasn't
been merged for a while, and automatically migrates it to a
differential.

Note that having these tools ready is not necessary to begin this new
workflow, but I think they will be helpful for making this new
workflow a sustainable approach.

If you guys are on board with this approach, I would enjoy writing the
initial version of "ghc-hub". Though I cannot at this time guarantee
that I would be willing to entirely champion / maintain it - I'll need
some help.

>> >- Github is not integrated with our other infrastructure, while
>> >Phabricator is
>> >
>> True, but I suspect for the small documentation patches that we are
>> currently consider this shouldn't matter so much.
>>
>> >- Mutliple sources of contributions makes life harder for maintainers
>> >
>> It does certainly put yet another task on our plates, but I would argue
>> that it's actually easier than accepting patches via Trac, which we
>> already do.
>
>
> We should stop accepting patches via Trac too :)
>
> Cheers
> Simon
>
>
>
>>
>> >- I also like the idea of auto-push if validate succeeds.  Or a
>> > button
>> >that you can press on the diff that would do the same thing, so you
>> > can get
>> >code review first.
>> >
>> To be clear, I'm a bit weary of opening up the auto-push feature to new
>> contributors. While regular contributors know what changes can be safely
>> pushed and which require review, we have no guarantee that a new
>> contributor has developed these sensibilities.
>>
>> >- +1 to making the manual easier to build.  The same goes for
>> > Haddocks;
>> >it's really hard to make a simple patch to the docs and test it right
>> > now.
>> >
>> The users guide should be quite possible to do.
>>
>> I don't believe there is any reliable way to allow a contributor to
>> build the haddocks without having built GHC (since you need GHC master to
>> parse `base`, et al.); that being said, we could have Harbormaster
>> upload built documentation somewhere and then leave a link to it on the
>> Diff.
>>
>> > One other thing that came up but wasn't mentioned in the notes: let's be
>> > more prompt about reverting patches that break validate, even if they
>> > only
>> > break a test.  Now that we have better CI support, we can easily
>> > identify
>> > breaking patches and revert them.
>> >
>> Agreed.
>>
>> Cheers,
>>
>> - Ben
>>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> 

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

[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 <mgsl...@gmail.com> 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 <b...@smart-cactus.org> wrote:
>> Carter Schonwald <carter.schonw...@gmail.com> 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

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

[Michael Sloan]

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

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

[Michael Sloan]

I like this solution a lot, Carter!

Mailing patches directly to the ghc-devs list could be intimidating
for newcomers.  Having a list specific to patch review could make the
process less intimidating.  From a perspective of overall contribution
intimidation, these 2 pages make it seem like a ton of extra work to
contribute to GHC:

1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs
2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures

Of course, I understand that these exist for a reason.  Contributing
to GHC isn't easy, and it does need processes, and those processes
should be followed!

However, for documentation patches and minor fixes, these pages make
it seem like you really have to put in quite a bit to get started, and
that the process is bureaucratic.  Atop getting accounts setup and
figuring out how to get ghc compiled, the amount of time investment to
get in a simple patch already seems like it is on the order of hours,
if not a full days worth of work.

At the risk of accumulating spam, perhaps the list shouldn't even
require membership?  Just have it filter based on containing an
attachment (perhaps even require a "*.patch" attachment?)

I also think that there should be an easy way to put a stop to
iterating via email and sending .patch files, and escalate to a
phabricator review.  Perhaps this could be scripted?  Is there any way
for people to use phabricator without using archanist?  Not a
criticism of the tech, but it is more to learn, and foreign to most.


One thing I've learned from maintaining stack, is that it can be
really helpful to accept patches that are imperfect.  Here's how this
works:

1) Some user wants to fix something, and doesn't quite nail it.  Maybe
makes some style mistakes, spelling errors in comments, or perhaps
writes some part of the code in a less direct way than possible

2) If the overall change is an improvement and the fixes are easy, I
go ahead and merge the imperfect patch, and then commit my own fixes
to the issues I saw.  I then say something like "Thanks for the
patch!!  I fixed a few things in e5cbda"

I feel like this is a highly valuable approach.  The contributor
appreciates being thanked, and also appreciates directly seeing the
ways that their patch could have been better.

This is antithetical to the "google style" of code review, where every
single thing is nit-picked and the author must fix it.  I think that
approach only works well when you already have an established
membership to that culture of code review (particularly if you are
getting paid for it).  With that approach, all of the bad behaviors
get beaten out of contributors, and they eventually learn their
lesson, and either leave or become good contributors.  I think this
can scare some people off, that might otherwise become regular
contributors.


Who knows if this will work out, but I think it is really worth a
shot!  Especially if the wiki is updated to indicate that there is now
an "easy mode" for contributing to ghc.

-Michael

On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald
 wrote:
> 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!
>
> What's even nice about this is its future proof and even agnostic to how the
> contributor made the change set locally! They could use mercurial or fossil
> for all we care. Or github. Or whatever!
>
>
>
> My personal stance is that ghc already way easier to contribute to / get
> involved with than it was 2-5 years ago.  This is even more impressive when
> you consider the number of contributors (who aren't students) that focus on
> ghc work full time has actually DECREASED over that period.
>
> Community engagement / management is a totally orthogonal skill from
> contributing. Both take effort.  Guiding new contributors requires both.
>
> My personal stance is that ghc keeps on getting better and getting more
> contributors.  And occasionally chatting about ways to make things better
> that we have the bandwidth to do is something that should happen every year
> or so. Like a health checkup.
>
> I suspect one funnel for improvement may be figuring out how to make it more
> visible how many contributors / how actively deved various subsystems are.
> I feel like many new folks veer towards subsystems that are already actively
> worked on, which are often the ones that are both the most mature and thus
> hardest to easily contribute to! Perhaps I should see if there's an easy way
> to quantify that in a way that's easy to communicate to new contributors.
> There's an interesting data presentation challenge in that!
>
> I've definitely found that for new potential 

Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

Ideally, sure, having Mozilla backing would be great and thoroughly
appreciated!

I understand that change takes effort.  I think the core problem is
participant psychology.  How do we encourage people to take ownership for
these problems?  Perhaps more importantly, how does power get delegated
such that things get done by new enthusiastic contributors?

I am not very involved in GHC development (yet!  we'll see - I've got a lot
to do elsewhere), so I don't have a very concrete proposal.  To me, seems
imminently reasonable to directly emulate the approach of similar
opensource projects,which have healthy, inspiring participation.  I am not
saying that GHC dev is sickly - we all appreciate the massive amount of
effort you guys undertake on a regular basis.  I am saying that we should
strive to reduce participation friction and lower the barrier to entry.

Lowering the barrier to entry is not trivial, it can also be accompanied by
a reduction in quality.  However, I think in the long run having many more
contributors, many more eyes on the code, will be a net boon, even if
individual contribution quality is initially lower than the current high
bar of excellence.

Directly emulating projects like Rust can cut through the indecision and
give a direct way to reuse the efforts that community has already
undertaken to solve these systemic issues.

On the code review side of things, I have my preferences (github), due to
its popularity and my personal familiarity with it, but I also understand
that there is a lot of momentum and expertise around phabricator.  If we
can knock down these barriers without a herculean effort, why not give it a
try?

-Michael Sloan

On Sat, Sep 24, 2016 at 6:56 PM, Brandon Allbery <allber...@gmail.com
<javascript:;>> wrote:
>
> On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan <mgsl...@gmail.com
<javascript:;>> wrote:
>>
>> It is irrelevant why Rust has an advantage. Lets please emulate their
>> successful strategies instead of in-fighting.
>
>
> Does that include having Mozilla Corp. backing them? What is your
suggestion
> for this?
>
> I understand that you think this is an important cause for the dearth of
> contributors --- I've watched enough would-be contributors bounce off the
> code base (long before even considering the tooling) and give up to have
> major doubts, as underlined by Richard's recent message --- but throwing
> everything out and building a new infrastructure is not something that
> happens by itself. It needs *people* and it needs *time*. And it's harder
> (and needs more people and more time) when you have a couple decades'
worth
> of history (which Rust did not). If you have a solution to this problem,
I'm
> sure people would like to hear it.
>
> --
> brandon s allbery kf8nh   sine nomine
associates
> allber...@gmail.com <javascript:;>
ballb...@sinenomine.net <javascript:;>
> unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net
___
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

[Michael Sloan]

Sorry, but I see little sense in what you are bringjng to this discussion.
Chris's points sre explaining some systemic reasons WHY there is a dearth
of contributors, and attempting to make a constructive plan to address
them.  Why should GHC not try to emulate a community that has fantasic
cohesion, unity, and participation?

It is irrelevant why Rust has an advantage. Lets please emulate their
successful strategies instead of in-fighting.

To me it seems you are just attacking his view with bluster and ad hominem,
with undertones of a personal vendetta against Rust.

On Saturday, September 24, 2016, Brandon Allbery 
wrote:

>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <
> c...@justtesting.org
> > wrote:
>
>> 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.
>
>
> It may be in good faith. but it's not in good sense. There is a lot in the
> background that made Rust's setup possible, and he's not bringing that to
> the table, just assuming it'll somehow happen or that everyone else will
> drop everything for the next few months and make it happen. And I feel like
> he's being really pushy about committing already overworked people to this
> --- and insisting that anyone opposed must have a hidden agenda or
> otherwise cannot possibly have good reason to be opposed. It's not helpful
> at all; it's basically a good way to stall ghc for the next few months at
> least.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com 
>  ballb...@sinenomine.net
> 
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
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

[Michael Sloan]

As a side observer, I find Christopher's comments to be spot on.  My
lack of familiarity with phab has definitely de-railed my in-flight
patch, adding implicit parameter and recursive do support to Template
Haskell.  Certainly my own fault, but also induced by friction that
feels unnecessary.

On Sat, Sep 24, 2016 at 5:40 PM, Brandon Allbery  wrote:
>
> 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: Custom warning suppression

[Michael Sloan]

Interesting ideas!

What if #1 was implemented as a new declaration type that is allowed
in where clauses?

f x = SomeConstant where { unused x }

For #2, I would love to have a general system for declaring new types
of warnings that come with a way to dispatch the specific warning.
So, picking some random new names for these:

{-# NEW_VALUE_WARNING partial "This function is partial, and so should
be used with care" #-}

{-# VALUE_WARNING partial unsafePerformIO #-}   -- Additional detail
text is optional!!

Lots of potential for bike shedding, a variety of choices in the
tradeoff between complexity and boilerplate.

On Wed, Sep 7, 2016 at 7:39 AM, David Feuer  wrote:
> Currently, the only way to suppress custom warnings and deprecations is with
> -fno-warn-warnings-deprecations, which is a rather large hammer. I see two
> ways we can improve this, and I propose that we should do both.
>
> 1. Per-binding suppression
>
> Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and
> -fdeprecate-binding options. These would take the (optionally qualified)
> name of a binding and control warnings tied to it. So if you invoked
> -fno-warn-binding "sillyFunction", then GHC would not warn you about the
> silliness of anything named sillyFunction. -fno-warn-binding
> "Data.Silly.sillyFunction" would limit the suppression to the silly function
> in Data.Silly. -fno-deprecate-binding would refrain from emitting
> deprecation warnings for the binding in question. -fno-deprecate-binding
> would presumably imply no-warn-binding, since someone who doesn't care that
> a function is going to be removed probably also doesn't care what else is
> wrong with it.
>
> 2. Named warning classes
>
> I'd like to add an optional "warning class" to the WARNING pragma, preceding
> the warning description. This would be a short string indicating what sort
> of warning is involved. This would be totally free-form, but the
> documentation would suggest a few conventional options such as "partial" and
> "slow". Then whole warning classes could be controlled with -fno-warn-class
> and -first-class.
>
>
> ___
> 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: Template Haskell determinism

[Michael Sloan]

Also, revisiting this issue, I don't think it is worth solving, just
worth documenting.

Why?  Because TH already lets you do lots of incorrect things.  TH
already allows you to shoot yourself in the foot all over the place,
and that's ok.  I'd much rather it be a dangerous power tool than a
weak safe tool.

When writing TH, you are writing something that's part of the
compiler, and the code can often resemble the sort of involved in the
middle bits of a compiler.  For the cases where stable Ord on Name
matters even for local names, you're definitely writing something
that's a fairly fancy, nearly compiler-like transformation.  Concerns
like the stability of Names should be handled by the TH user.

-Michael

On Wed, Jun 29, 2016 at 10:41 AM, Michael Sloan <mgsl...@gmail.com> wrote:
> No, NameU and NameL both lack package key / package id.
>
> -Michael
>
> On Wed, Jun 29, 2016 at 7:34 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
>> No, nameBase is not the right thing to use here; you also need the
>> unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id
>> in GHC 7.8 and before).  If you have that information, then
>> GHC establishes an invariant that if two names compare stably equal,
>> then the uniques associated with them are the same.
>>
>> Edward
>>
>> Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400:
>>> Hey, sorry for not getting back to this sooner!
>>>
>>> Perhaps I should have added the following to my list of goals in contention:
>>>
>>> (3) (==) shouldn't yield True for Names that have different unique ids.
>>>
>>> We can only have stable comparisons if goal (3) isn't met, and two
>>> different unique Names would be considered to be equivalent based on the
>>> nameBase.  This is because Ord is a total order, not a partial order.  As
>>> described in my prior email, PartialOrd could be added, but it'd be
>>> inconvenient to use with existing Ord based containers.
>>>
>>> -Michael
>>>
>>> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
>>>
>>> > I must admit, I am a bit confused by this discussion.
>>> >
>>> > It is true that every Name is associated with a Unique.  But you don't
>>> > need the Unique to equality/ordering tests; the names also contain
>>> > enough (stable) information for stable comparisons of that sort.  So
>>> > why don't we expose that instead of the Unique?
>>> >
>>> > Edward
>>> >
>>> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
>>> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
>>> > simo...@microsoft.com>
>>> > > wrote:
>>> > >
>>> > > > If names get different ordering keys when reified from different
>>> > modules
>>> > > > (seems like they'd have to, particularly given ghc's "-j"), then we
>>> > end up
>>> > > > with an unpleasant circumstance where these do not compare as equal
>>> > > >
>>> > > >
>>> > > >
>>> > > > The I believe that global, top level names (NameG) are not subject to
>>> > this
>>> > > > ordering stuff, so I don’t think this problem can occur.
>>> > > >
>>> > >
>>> > > True, top level names are NameG.  The reified Info for a top level Dec
>>> > may
>>> > > include NameU, though.  For example, the type variables in 'Maybe' are
>>> > > NameU:
>>> > >
>>> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
>>> > >  lift (show nf))
>>> > >
>>> > > The resulting expression is something like "NameU 822083586"
>>> > >
>>> > > > This is a breaking change and it doesn't fix the problem that
>>> > NameFlavour
>>> > > > is
>>> > > >
>>> > > > not abstract and leaks the Uniques. It would break at least:
>>> > > >
>>> > > >
>>> > > >
>>> > > > But why is NameU exposed to clients?   GHC needs to know, but clients
>>> > > > don’t.  What use are these packages making of it?
>>> > > >
>>> > >
>>> > > It's being leaked in the public inteface via Ord.  The Eq instance is
>>> > fine,
>>> > > because these are Uniques, so the res

Re: Template Haskell determinism

[Michael Sloan]

No, NameU and NameL both lack package key / package id.

-Michael

On Wed, Jun 29, 2016 at 7:34 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
> No, nameBase is not the right thing to use here; you also need the
> unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id
> in GHC 7.8 and before).  If you have that information, then
> GHC establishes an invariant that if two names compare stably equal,
> then the uniques associated with them are the same.
>
> Edward
>
> Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400:
>> Hey, sorry for not getting back to this sooner!
>>
>> Perhaps I should have added the following to my list of goals in contention:
>>
>> (3) (==) shouldn't yield True for Names that have different unique ids.
>>
>> We can only have stable comparisons if goal (3) isn't met, and two
>> different unique Names would be considered to be equivalent based on the
>> nameBase.  This is because Ord is a total order, not a partial order.  As
>> described in my prior email, PartialOrd could be added, but it'd be
>> inconvenient to use with existing Ord based containers.
>>
>> -Michael
>>
>> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
>>
>> > I must admit, I am a bit confused by this discussion.
>> >
>> > It is true that every Name is associated with a Unique.  But you don't
>> > need the Unique to equality/ordering tests; the names also contain
>> > enough (stable) information for stable comparisons of that sort.  So
>> > why don't we expose that instead of the Unique?
>> >
>> > Edward
>> >
>> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
>> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
>> > simo...@microsoft.com>
>> > > wrote:
>> > >
>> > > > If names get different ordering keys when reified from different
>> > modules
>> > > > (seems like they'd have to, particularly given ghc's "-j"), then we
>> > end up
>> > > > with an unpleasant circumstance where these do not compare as equal
>> > > >
>> > > >
>> > > >
>> > > > The I believe that global, top level names (NameG) are not subject to
>> > this
>> > > > ordering stuff, so I don’t think this problem can occur.
>> > > >
>> > >
>> > > True, top level names are NameG.  The reified Info for a top level Dec
>> > may
>> > > include NameU, though.  For example, the type variables in 'Maybe' are
>> > > NameU:
>> > >
>> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
>> > >  lift (show nf))
>> > >
>> > > The resulting expression is something like "NameU 822083586"
>> > >
>> > > > This is a breaking change and it doesn't fix the problem that
>> > NameFlavour
>> > > > is
>> > > >
>> > > > not abstract and leaks the Uniques. It would break at least:
>> > > >
>> > > >
>> > > >
>> > > > But why is NameU exposed to clients?   GHC needs to know, but clients
>> > > > don’t.  What use are these packages making of it?
>> > > >
>> > >
>> > > It's being leaked in the public inteface via Ord.  The Eq instance is
>> > fine,
>> > > because these are Uniques, so the results should be consistent.
>> > >
>> > > There are two goals in contention here:
>> > >
>> > > 1) Having some ordering on Names so that they can be used in Map or Set
>> > > 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
>> > > really handle these well.  In that case, the ordering would be based on
>> > > everything but the NameU int, but 'Eq' would still follow it
>> > >
>> > > A few ideas for different approaches to resolving this:
>> > >
>> > > 1) Document it.  Less appealing than fixing it in the API, but still
>> > would
>> > > be good.
>> > >
>> > > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
>> > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
>> > newtype
>> > > (current behavior).  A trickyness of this approach is that you'd need
>> > > containers that can handle (PartialOrd k, Eq k) keys.  In lots

Re: Template Haskell determinism

[Michael Sloan]

Hey, sorry for not getting back to this sooner!

Perhaps I should have added the following to my list of goals in contention:

(3) (==) shouldn't yield True for Names that have different unique ids.

We can only have stable comparisons if goal (3) isn't met, and two
different unique Names would be considered to be equivalent based on the
nameBase.  This is because Ord is a total order, not a partial order.  As
described in my prior email, PartialOrd could be added, but it'd be
inconvenient to use with existing Ord based containers.

-Michael

On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang <ezy...@mit.edu> wrote:

> I must admit, I am a bit confused by this discussion.
>
> It is true that every Name is associated with a Unique.  But you don't
> need the Unique to equality/ordering tests; the names also contain
> enough (stable) information for stable comparisons of that sort.  So
> why don't we expose that instead of the Unique?
>
> Edward
>
> Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
> > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
> simo...@microsoft.com>
> > wrote:
> >
> > > If names get different ordering keys when reified from different
> modules
> > > (seems like they'd have to, particularly given ghc's "-j"), then we
> end up
> > > with an unpleasant circumstance where these do not compare as equal
> > >
> > >
> > >
> > > The I believe that global, top level names (NameG) are not subject to
> this
> > > ordering stuff, so I don’t think this problem can occur.
> > >
> >
> > True, top level names are NameG.  The reified Info for a top level Dec
> may
> > include NameU, though.  For example, the type variables in 'Maybe' are
> > NameU:
> >
> > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
> >  lift (show nf))
> >
> > The resulting expression is something like "NameU 822083586"
> >
> > > This is a breaking change and it doesn't fix the problem that
> NameFlavour
> > > is
> > >
> > > not abstract and leaks the Uniques. It would break at least:
> > >
> > >
> > >
> > > But why is NameU exposed to clients?   GHC needs to know, but clients
> > > don’t.  What use are these packages making of it?
> > >
> >
> > It's being leaked in the public inteface via Ord.  The Eq instance is
> fine,
> > because these are Uniques, so the results should be consistent.
> >
> > There are two goals in contention here:
> >
> > 1) Having some ordering on Names so that they can be used in Map or Set
> > 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
> > really handle these well.  In that case, the ordering would be based on
> > everything but the NameU int, but 'Eq' would still follow it
> >
> > A few ideas for different approaches to resolving this:
> >
> > 1) Document it.  Less appealing than fixing it in the API, but still
> would
> > be good.
> >
> > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
> > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
> newtype
> > (current behavior).  A trickyness of this approach is that you'd need
> > containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
> > people are using the 'Ord' instance with 'Name's that are not 'NameU', so
> > this would break a lot of code that was already deterministic.
> >
> > 3) Some approaches like this ordering key, but I'm not sure how it will
> > help when comparing NameUs from different modules?
> >
> > > S
> > >
> > >
> > >
> > >
> > >
> > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
> *Michael
> > > Sloan
> > > *Sent:* 02 June 2016 02:07
> > > *To:* Bartosz Nitka <nite...@gmail.com>
> > > *Cc:* ghc-devs Devs <ghc-devs@haskell.org>
> > > *Subject:* Re: Template Haskell determinism
> > >
> > >
> > >
> > > +1 to solving this.  Not sure about the approach, but assuming the
> > > following concerns are addressed, I'm (+1) on it too:
> > >
> > >
> > >
> > > This solution is clever!  However, I think there is some difficulty to
> > > determining this ordering key.  Namely, what happens when I construct
> the
> > > (Set Name) using results from multiple reifies?
> > >
> > >
> > >
> > > One solution is to have the ordering key be a consecut

Re: Why upper bound version numbers?

[Michael Sloan]

Right, part of the issue with having dependency solving at the core of your
workflow is that you never really know who's to blame.  When running into
this circumstance, either:

1) Some maintainer made a mistake.
2) Some maintainer did not have perfect knowledge of the future and has not
yet updated some upper bounds.  Or, upper bounds didn't get retroactively
bumped (usual).
3) You're asking cabal to do something that can't be done.
4) There's a bug in the solver.

So the only thing to do is to say "something went wrong".  In a way it is
similar to type inference, it is difficult to give specific, concrete error
messages without making some arbitrary choices about which constraints have
gotten pushed around.

I think upper bounds could potentially be made viable by having both hard
and soft constraints.  Until then, people are putting 2 meanings into one
thing.  By having the distinction, I think cabal-install could provide much
better errors than it does currently.  This has come up before, I'm not
sure what came of those discussions.  My thoughts on how this would work:

* The dependency solver would prioritize hard constraints, and tell you
which soft constraints need to be lifted.  I believe the solver even
already has this.  Stack's integration with the solver will actually first
try to get a plan that doesn't override any snapshot versions, by
specifying them as hard constraints.  If that doesn't work, it tries again
with soft constraints.

* "--allow-soft" or something would ignore soft constraints.  Ideally this
would be selective on a per package / upper vs lower.

* It may be worth having the default be "--allow-soft" + be noisy about
which constraints got ignored.  Then, you could have a "--pedantic-bounds"
flag that forces following soft bounds.

I could get behind upper bounds if they allowed maintainers to actually
communicate their intention, and if we had good automation for their
maintenance.  As is, putting upper bounds on everything seems to cause more
problems than it solves.

-Michael

On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier  wrote:

>
> On 8 Jun 2016, at 6:19 pm, Reid Barton  wrote:
>
>  Suppose you maintain a library that is used by a lot of first year uni
>> students (like gloss). Suppose the next GHC version comes around and your
>> library hasn’t been updated yet because you’re waiting on some dependencies
>> to get fixed before you can release your own. Do you want your students to
>> get a “cannot install on this version” error, or some confusing build error
>> which they don’t understand?
>>
>
> This is a popular but ultimately silly argument. First, cabal dependency
> solver error messages are terrible; there's no way a new user would figure
> out from a bunch of solver output about things like "base-4.7.0.2" and
> "Dependency tree exhaustively searched" that the solution is to build with
> an older version of GHC.
>
>
> :-) At least “Dependency tree exhaustively searched” sounds like it’s not
> the maintainer’s problem. I prefer the complaints to say “can you please
> bump the bounds on this package” rather than “your package is broken”.
>
> 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: Template Haskell determinism

[Michael Sloan]

On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <simo...@microsoft.com>
wrote:

> If names get different ordering keys when reified from different modules
> (seems like they'd have to, particularly given ghc's "-j"), then we end up
> with an unpleasant circumstance where these do not compare as equal
>
>
>
> The I believe that global, top level names (NameG) are not subject to this
> ordering stuff, so I don’t think this problem can occur.
>

True, top level names are NameG.  The reified Info for a top level Dec may
include NameU, though.  For example, the type variables in 'Maybe' are
NameU:

$(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
 lift (show nf))

The resulting expression is something like "NameU 822083586"


> This is a breaking change and it doesn't fix the problem that NameFlavour
> is
>
> not abstract and leaks the Uniques. It would break at least:
>
>
>
> But why is NameU exposed to clients?   GHC needs to know, but clients
> don’t.  What use are these packages making of it?
>

It's being leaked in the public inteface via Ord.  The Eq instance is fine,
because these are Uniques, so the results should be consistent.

There are two goals in contention here:

1) Having some ordering on Names so that they can be used in Map or Set
2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
really handle these well.  In that case, the ordering would be based on
everything but the NameU int, but 'Eq' would still follow it

A few ideas for different approaches to resolving this:

1) Document it.  Less appealing than fixing it in the API, but still would
be good.

2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
newtype (partial ord on the non-unique info), or 'UnstableNameOrd' newtype
(current behavior).  A trickyness of this approach is that you'd need
containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
people are using the 'Ord' instance with 'Name's that are not 'NameU', so
this would break a lot of code that was already deterministic.

3) Some approaches like this ordering key, but I'm not sure how it will
help when comparing NameUs from different modules?


> S
>
>
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Michael
> Sloan
> *Sent:* 02 June 2016 02:07
> *To:* Bartosz Nitka <nite...@gmail.com>
> *Cc:* ghc-devs Devs <ghc-devs@haskell.org>
> *Subject:* Re: Template Haskell determinism
>
>
>
> +1 to solving this.  Not sure about the approach, but assuming the
> following concerns are addressed, I'm (+1) on it too:
>
>
>
> This solution is clever!  However, I think there is some difficulty to
> determining this ordering key.  Namely, what happens when I construct the
> (Set Name) using results from multiple reifies?
>
>
>
> One solution is to have the ordering key be a consecutive supply that's
> initialized on a per-module basis.  There is still an issue there, though,
> which is that you might store one of these names in a global IORef that's
> used by a later TH splice.  Or, similarly, serialize the names to a file
> and later load them.  At least in those cases you need to use 'runIO' to
> break determinism.
>
>
>
> If names get different ordering keys when reified from different modules
> (seems like they'd have to, particularly given ghc's "-j"), then we end up
> with an unpleasant circumstance where these do not compare as equal.  How
> about having the Eq instance ignore the ordering key?  I think that mostly
> resolves this concern.  This implies that the Ord instance should also
> yield EQ and ignore the ordering key, when the unique key matches.
>
>
>
> One issue with this is that switching the order of reify could
> unexpectedly vary the behavior.
>
>
>
> Does the map in TcGblEnv imply that a reify from a later module will get
> the same ordering key?  So does this mean that the keys used in a given
> reify depend on which things have already been reified?  In that case, then
> this is also an issue with your solution.  Now, it's not a big problem at
> all, just surprising to the user.
>
>
>
>
>
> If the internal API for Name does change, may as well address
> https://ghc.haskell.org/trac/ghc/ticket/10311 too.  I agree with SPJ's
> suggested solution of having both the traditional package identifier and
> package keys in 'Name'.
>
>
>
> -Michael
>
>
>
> On Tue, May 31, 2016 at 6:54 AM, Bartosz Nitka <nite...@gmail.com> wrote:
>
> Template Haskell with its ability to do arbitrary IO is non-deterministic
> by
>
> design. You could for example embed the current date in a file. There is
>
> however one kind of non-determinist

Re: Template Haskell determinism

[Michael Sloan]

+1 to solving this.  Not sure about the approach, but assuming the
following concerns are addressed, I'm (+1) on it too:

This solution is clever!  However, I think there is some difficulty to
determining this ordering key.  Namely, what happens when I construct the
(Set Name) using results from multiple reifies?

One solution is to have the ordering key be a consecutive supply that's
initialized on a per-module basis.  There is still an issue there, though,
which is that you might store one of these names in a global IORef that's
used by a later TH splice.  Or, similarly, serialize the names to a file
and later load them.  At least in those cases you need to use 'runIO' to
break determinism.

If names get different ordering keys when reified from different modules
(seems like they'd have to, particularly given ghc's "-j"), then we end up
with an unpleasant circumstance where these do not compare as equal.  How
about having the Eq instance ignore the ordering key?  I think that mostly
resolves this concern.  This implies that the Ord instance should also
yield EQ and ignore the ordering key, when the unique key matches.

One issue with this is that switching the order of reify could unexpectedly
vary the behavior.

Does the map in TcGblEnv imply that a reify from a later module will get
the same ordering key?  So does this mean that the keys used in a given
reify depend on which things have already been reified?  In that case, then
this is also an issue with your solution.  Now, it's not a big problem at
all, just surprising to the user.


If the internal API for Name does change, may as well address
https://ghc.haskell.org/trac/ghc/ticket/10311 too.  I agree with SPJ's
suggested solution of having both the traditional package identifier and
package keys in 'Name'.

-Michael

On Tue, May 31, 2016 at 6:54 AM, Bartosz Nitka  wrote:

> Template Haskell with its ability to do arbitrary IO is non-deterministic
> by
> design. You could for example embed the current date in a file. There is
> however one kind of non-deterministic behavior that you can trigger
> accidentally. It has to do with how Names are reified. If you take a look
> at
> the definition of reifyName you can see that it puts the assigned Unique
> in a
> NameU:
>
>   reifyName :: NamedThing n => n -> TH.Name
>   reifyName thing
> | isExternalName name = mk_varg pkg_str mod_str occ_str
> | otherwise   = TH.mkNameU occ_str (getKey (getUnique name))
> ...
> NameFlavour which NameU is a constructor of has a default Ord instance,
> meaning
> that it ends up comparing the Uniques. The relative ordering of Uniques is
> not
> guaranteed to be stable across recompilations [1], so this can lead to
> ABI-incompatible binaries.
>
> This isn't an abstract problem and it actually happens in practice. The
> microlens package keeps Names in a Set and later turns that set into a
> list.
> The results have different orders of TyVars resulting in different ABI
> hashes
> and can potentially be optimized differently.
>
> I believe it's worth to handle this case in a deterministic way and I have
> a
> solution in mind. The idea is to extend NameU (and potentially NameL) with
> an
> ordering key. To be more concrete:
>
> -   | NameU !Int
> +   | NameU !Int !Int
>
> This way the Ord instance can use a stable key and the problem reduces to
> ensuring the keys are stable. To generate stable keys we can use the fact
> that
> reify traverses the expressions in the same order every time and
> sequentially
> allocate new keys based on traversal order. The way I have it implemented
> now
> is to add a new field in TcGblEnv which maps Uniques to allocated keys:
>
> +tcg_th_names :: TcRef (UniqFM Int, Int),
>
> Then the reifyName and qNewName do the necessary bookkeeping and translate
> the
> Uniques on the fly.
>
> This is a breaking change and it doesn't fix the problem that NameFlavour
> is
> not abstract and leaks the Uniques. It would break at least:
>
> - singletons
> - th-lift
> - haskell-src-meta
> - shakespeare
> - distributed-closure
>
> I'd like to get feedback if this is an acceptable solution and if the
> problem
> is worth solving.
>
> Cheers,
> Bartosz
>
> [1]
> https://ghc.haskell.org/trac/ghc/wiki/DeterministicBuilds#NondeterministicUniques
>
> ___
> 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: Reification of out-of-scope variables?

[Michael Sloan]

I have considered how to add this capability some in the past, it's
something I'd also like to have.  Collecting the type info in the module
finalizer is an interesting idea!  This may well be the cheapest way to get
the info necessary for this usecase.

As far as I understand it, currently we're in the middle of typechecking
when quasiquotes get run, so we don't yet have concrete.  The types of
reified variables may well depend upon the type of the expression generated
by the quasi-quote.  There seems to be a straightforward-ish way to resolve
this - run typechecking twice.  The first typechecking pass uses
quasi-quotes substituted with stub versions of their output.  For this
example, it'd be (undefined :: IO double).  To support this, we'd add a
(Maybe ExpQ) field to QuasiQuoter, hopefully doing this in a way that
preserves backwards compatibility (via pattern syns, or adding a new
constructor to QuasiQuoter).

For consistency, we would want to ensure that the stub unifies with the
expression that actually gets used.  To enforce this, we'd typecheck
something equivalent to

case True of
True -> ... -- generated code
False -> (undefined :: IO Double)  -- stub

My particular use case is similar, in that it's related to FFI.  What I
want to do is have quasiquoters for typescript in GHCJS code.  Since GHCJS
already runs TH in node, we can actually load up the typescript compiler
and do the typechecking directly at the quasi-quote location.  For the
first-pass stubs, we pretend like all the captured variables are the "Any"
type, and ask typescript what it thinks the overall type is.  For the
second pass, we have the types of the anti-quotes, and so can typecheck the
whole expression.

It'd also be really cool if we could generated code + typecheck anti-quotes
during the first pass.  This would make it possible to use anti-quotes
which are more complicated than just a variable.

-Michael

On Fri, Apr 8, 2016 at 6:48 AM, Boespflug, Mathieu  wrote:

> Hi all,
>
> the community is increasingly using quasiquotation as a means to
> interoperate with foreign languages. E.g. language-c-inline, inline-c
> and inline-r allow calling foreign functions using foreign language
> syntax, rather than "foreign import" declarations. There are efforts
> underway for Java, Javascript and other languages too. The pattern
> common to most of these libraries is:
>
> * collect the content of all quasiquotes that appear in a module,
> generate a compilable foreign source file based on that, and then link
> the object code resulting from compiling that.
>
> When the foreign language is itself statically typed, we need to make
> sure we generate code with proper type annotations, including for any
> antiquotation variables. In older versions of GHC, we could derive the
> type annotations from the inferred Haskell types, but this is not
> possible since 7.8 because the types of any variable in the current
> "declaration group" are not made available. So libraries like inline-c
> ask for some extra verbosity from the user:
>
> mycossin1 :: Double -> IO Double
> mycossin1 somex = [cexp| double { cos($(double somex)) * sin($(double
> somex)) } |]
>
> The type annotations inside the quasiquote are redundant with the
> explicitly provided type signature. C types are typically short
> enough, but other languages (e.g. C++, Java), have really long fully
> qualified type names, so the extra annotations are a cost.
>
> The are good reasons why types aren't available from within a
> declaration group (it was possible to observe the order in which type
> inference works), hence why the extra annotations are necessary. But
> by the time type checking of the whole module is finished, types are
> fixed once and for all. So the question is:
>
> * Could we make it possible to query the types of local variables at
> the end of type checking?
>
> The reason I ask is: with 'addModFinalizer' and friends that TH
> provides, we're tantalizingly close to being able to generate foreign
> code wrappers that have the right types that match those of the
> antiquotation variables present in a module.
>
> Template Haskell already provides 'addModFinalizer'. You feed it a Q
> action, which will run once the whole module is type checked. If at
> that point we could ask, "what's the type of somex (above)?", then we
> could let the user write
>
> mycossin2 :: Double -> IO Double
> mycossin2 somex = [cexp| cos($somex) * sin($somex) |]
>
> and yet still generate a C file capturing the content of above
> quasiquote with the right types:
>
> double module_foo_qq1(double v1)
> {
> return (cos(v1) * sin(v1));
> }
>
> since we know that somex :: Double and that the Haskell type "Double"
> corresponds to C's "double" primitive type.
>
> Bound variables have a unique name associated to them, which we can
> get hold of in Template Haskell using the 'var syntax, but
>
> f x = $(let name = 'x in addModFinalizer (reify name >>= \info ->
> runIO (print 

Re: Initial compile time benchmarks

[Michael Sloan]

Great! Thanks for y'all putting effort towards performance. It really is
crucial
for developer productivity.

In the particular case of haskell-src-exts, I found that removing many of
the
more complicated typeclasses from deriving (Data, Generics, etc) brought the
compilation time way down. IIRC it was pretty drastic, like 40 seconds vs 10
seconds (that could be just the timing for that one types module though, I
don't recall).  Could be valuable to investigate exactly what's going on
there.

-Michael

On Tue, Mar 29, 2016 at 2:00 PM, Ömer Sinan Ağacan 
wrote:

> Hi all,
>
> Using Ben's timing patch [^1], Cabal, and a Haskell program to parse
> generated
> logs [^2], I generated some tables that show compile times of modules in
> hxt,
> haskell-src-exts, lens, and all of their dependencies:
>
>
> https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/raw/5d46b0e7006c7ef9fae913f7d6932b74c83835f1/gistfile1.txt
>
> Some notes:
>
> - Modules and passes in modules are sorted.
>
> - At the end of the file you can see the cumulative numbers for the
> passes. In
>   fact, that's a small table so I'm just going to paste it here:
>
> ==Total==
> CodeGen41.32%
> Simplifier 34.83%
> Renamer/typechecker12.22%
> Desugar 2.11%
> CorePrep1.90%
> Demand analysis 1.44%
> CoreTidy1.35%
> Called arity analysis   1.10%
> Float inwards   0.96%
> Common sub-expression   0.87%
> Parser  0.75%
> SpecConstr  0.57%
> Specialise  0.30%
> Worker Wrapper binds0.17%
> Liberate case   0.12%
> ByteCodeGen 0.00%
> Simplify0.00%
>
> I don't know how to make use of this yet, but I thought ghc-devs may find
> it
> useful.
>
> As a next thing I'm hoping to add some more `withTiming` calls. The analyze
> program can handle nested `withTiming` calls and renders passes as a tree
> (GHC
> HEAD doesn't have nested `withTiming`s so we don't see it in the file
> above),
> so we can benchmark things in more details. I also want to experiment a
> little
> bit with different `force` parameters to `withTiming`. If anyone has any
> other
> ideas I can also try those.
>
> ---
>
> [^1]: https://phabricator.haskell.org/D1959
> [^2]: https://github.com/osa1/analyze-ghc-timings
> ___
> 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: Unused type variables with non-linear patterns

[Michael Sloan]

I definitely think this should be considered a usage.  Ideally, you should
always be able to resolve warnings, but there'd be no straightforward way
to do so if LHS-only usages cause warnings.  Also, It's quite useful to use
type variables only on the LHS.  Usage example:
https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Type.Equality.html#EqStar

-Michael

On Thu, Dec 10, 2015 at 6:48 AM, Jan Stolarek 
wrote:

> An intersting thing came up when implementing warnings for unused type
> variables in type family
> patterns (#10982 / D1576):
>
> type family X a b where
>   X a a = Int
>
> Should we emit a warning that `a` is unused? It does not appear in the RHS
> but it is actually used
> because of non-linear pattern. We can fix this by prefixing both
> appearances of `a` with an
> underscore - this silences the warning and maintains semantics.
> Nevertheless, if a variable is
> unused it should be perfectly valid to replace it with an underscore -
> that is not the case in
> this example. Thoughts?
>
> Janek
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message
> in error,
> please notify the sender and delete it from your system.
> ___
> 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: Plugins: How to determine ghc vs ghci

[Michael Sloan]

The executable-path package wraps this up nicely with its `getScriptPath`
function:

https://hackage.haskell.org/package/executable-path-0.0.3/docs/System-Environment-Executable.html#v:getScriptPath

Probably best to use this existing function.  Then, if a less fragile
solution comes along, getScriptPath can do that instead.

-Michael

On Tue, Nov 24, 2015 at 5:58 PM, Levent Erkok  wrote:

> Thanks! That indeed does work.
>
> I'm a bit surprised though that there isn't already an internal boolean
> set somewhere; checking for a string in the arguments sounds a bit fragile.
>
> On Tue, Nov 24, 2015 at 12:28 AM, Aycan İrican 
> wrote:
>
>> How about `GHC.Environment.getFullArgs` which includes “—interactive”
>> when you’re in GHCi?
>>
>>
>> > On 24 Nov 2015, at 09:37, Levent Erkok  wrote:
>> >
>> > I'm working on a plugin, and would like to be able to tell if it's GHC
>> or GHCi that's running.
>> >
>> > I tried:
>> >
>> >df   <- getDynFlags
>> >let isGHCi = ghcMode df == CompManager
>> >
>> > Alas, while that correctly tells apart "ghci" from "ghc -c", it also
>> returns True when ghc is called without the "-c" argument.
>> >
>> > Is there a better/more robust way of figuring out whether we're in an
>> interactive session?
>> >
>> > -Levent.
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Anonymous FFI calls

[Michael Sloan]

I'd love for the implementation to be as powerful as the documentation
suggests it is :D

However, yes, in the meantime, fixing the documentation would be great!

Also, I meant to say that addTopDecls is only exported by
Language.Haskell.TH.Syntax.  While this is a digression, there are a
few other handy functions that are oddly left out of
Language.Haskell.TH: addDependentFile, addModFinalizer, and possibly
more.

-Michael

On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones
simo...@microsoft.com wrote:
 I would LOVE someone to improve the documentation for addTopDecls.  Manuel 
 Chakravarty and Geoff Mainland were responsible for the implementation.

 Simon

 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael
 | Sloan
 | Sent: 11 February 2015 23:19
 | To: Francesco Mazzoli
 | Cc: ghc-devs@haskell.org; haskell
 | Subject: Re: [Haskell-cafe] Anonymous FFI calls
 |
 | It seems like addTopDecls[1] will able to help here.  Unfortunately,
 | the function is not well documented and not very discoverable because
 | it's only exported by Language.Haskell.TH.
 |
 | The documentation doesn't mention that it can only be used to create
 | new top level functions and FFI imports[2].  I think that adding FFI
 | imports was the main motivation for implementing it.   In the past
 | I've wanted to generate instances via this function, but unfortunately
 | it's not implemented..
 |
 | Hope that helps!
 | -Michael
 |
 | [1] http://hackage.haskell.org/package/template-haskell-
 | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls
 |
 | [2]
 | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/
 | compiler/typecheck/TcSplice.hs#L818
 |
 | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli f...@mazzo.li wrote:
 |  Hi,
 | 
 |  I am in a situation where it would be very useful to call C functions
 |  without an explicit FFI import.  For example, I'd like to be able to do
 | 
 |  (foreign import ccall cadd :: CInt - CInt - CInt) 1 2
 | 
 |  instead of declaring the foreign import explicitely at the top level.
 | 
 |  Is there a way to do this or to achieve similar results in some other
 |  way?
 | 
 |  If not, I imagine it would be easy to implement such a facility in GHC,
 |  given that the code implementing calling to C functions must already be
 |  present to implement proper FFI imports.  I think such an addition
 |  would be useful in many cases.
 | 
 |  Thanks,
 |  Francesco
 |  ___
 |  Haskell-Cafe mailing list
 |  haskell-c...@haskell.org
 |  http://www.haskell.org/mailman/listinfo/haskell-cafe
 | ___
 | 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: [Haskell-cafe] Anonymous FFI calls

[Michael Sloan]

It seems like addTopDecls[1] will able to help here.  Unfortunately,
the function is not well documented and not very discoverable because
it's only exported by Language.Haskell.TH.

The documentation doesn't mention that it can only be used to create
new top level functions and FFI imports[2].  I think that adding FFI
imports was the main motivation for implementing it.   In the past
I've wanted to generate instances via this function, but unfortunately
it's not implemented..

Hope that helps!
-Michael

[1] 
http://hackage.haskell.org/package/template-haskell-2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls

[2] 
https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/compiler/typecheck/TcSplice.hs#L818

On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli f...@mazzo.li wrote:
 Hi,

 I am in a situation where it would be very useful to call C functions
 without an explicit FFI import.  For example, I'd like to be able to do

 (foreign import ccall cadd :: CInt - CInt - CInt) 1 2

 instead of declaring the foreign import explicitely at the top level.

 Is there a way to do this or to achieve similar results in some other
 way?

 If not, I imagine it would be easy to implement such a facility in GHC,
 given that the code implementing calling to C functions must already be
 present to implement proper FFI imports.  I think such an addition
 would be useful in many cases.

 Thanks,
 Francesco
 ___
 Haskell-Cafe mailing list
 haskell-c...@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Anonymous FFI calls

[Michael Sloan]

Hi!

I don't mean to be accusatory with the whole documentation thing - I
totally understand that most folks have a lot going on!  In this
particular case, I got very excited when I initially saw addTopDecls,
because it says it allows you to Add additional top-level
declarations.  After implementing something to use it, I got rather
disappointed as it couldn't add instances.

So, when I say not implemented, it's just that the docs say it
allows you to add additional top-level decls, when you can really only
add functions, variable bindings, and foreign import decls.

I didn't realize that not re-exporting these functions is due to their
experimental status.  That makes sense!  I'm glad it was a conscious
decision.  I just tried writing a demo of addTopDecls, but
unfortunately using it to add a function and referencing this function
causes a GHC internal error:
https://gist.github.com/mgsloan/53d7fa50338c696e5c80 .  I haven't
tried it with a foreign import yet.

-Michael

On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland
mainl...@cs.drexel.edu wrote:
 Typed Template Haskell happened at the end of my tenure at MSR, and
 there was a mad rush to get it in to the compiler in time for 7.8.3 at
 the same time I was starting a new job. I'm afraid the documentation is
 indeed wanting, but the alternative was no typed Template Haskell.

 One side-effect was that the functions you note as present only in
 Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't
 re-export them from Language.Haskell.TH.

 I am willing to help with documentation if people want to use this
 functionality. Has anyone attempted to use addTopDecls? Michael, when
 you say it's not implemented, what do you mean? What, exactly, is not
 implemented?

 Cheers,
 Geoff

 On 2/11/15 6:32 PM, Michael Sloan wrote:
 I'd love for the implementation to be as powerful as the documentation
 suggests it is :D

 However, yes, in the meantime, fixing the documentation would be great!

 Also, I meant to say that addTopDecls is only exported by
 Language.Haskell.TH.Syntax.  While this is a digression, there are a
 few other handy functions that are oddly left out of
 Language.Haskell.TH: addDependentFile, addModFinalizer, and possibly
 more.

 -Michael

 On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones
 simo...@microsoft.com wrote:
 I would LOVE someone to improve the documentation for addTopDecls.  Manuel 
 Chakravarty and Geoff Mainland were responsible for the implementation.

 Simon

 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael
 | Sloan
 | Sent: 11 February 2015 23:19
 | To: Francesco Mazzoli
 | Cc: ghc-devs@haskell.org; haskell
 | Subject: Re: [Haskell-cafe] Anonymous FFI calls
 |
 | It seems like addTopDecls[1] will able to help here.  Unfortunately,
 | the function is not well documented and not very discoverable because
 | it's only exported by Language.Haskell.TH.
 |
 | The documentation doesn't mention that it can only be used to create
 | new top level functions and FFI imports[2].  I think that adding FFI
 | imports was the main motivation for implementing it.   In the past
 | I've wanted to generate instances via this function, but unfortunately
 | it's not implemented..
 |
 | Hope that helps!
 | -Michael
 |
 | [1] http://hackage.haskell.org/package/template-haskell-
 | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls
 |
 | [2]
 | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/
 | compiler/typecheck/TcSplice.hs#L818
 |
 | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli f...@mazzo.li wrote:
 |  Hi,
 | 
 |  I am in a situation where it would be very useful to call C functions
 |  without an explicit FFI import.  For example, I'd like to be able to do
 | 
 |  (foreign import ccall cadd :: CInt - CInt - CInt) 1 2
 | 
 |  instead of declaring the foreign import explicitely at the top level.
 | 
 |  Is there a way to do this or to achieve similar results in some other
 |  way?
 | 
 |  If not, I imagine it would be easy to implement such a facility in GHC,
 |  given that the code implementing calling to C functions must already be
 |  present to implement proper FFI imports.  I think such an addition
 |  would be useful in many cases.
 | 
 |  Thanks,
 |  Francesco
 |  ___
 |  Haskell-Cafe mailing list
 |  haskell-c...@haskell.org
 |  http://www.haskell.org/mailman/listinfo/haskell-cafe
 | ___
 | 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: [Haskell-cafe] Anonymous FFI calls

[Michael Sloan]

It works, cool!  So at least this ought to address Francesco's use-case.

Is there anything wrong with my code?  It definitely looks like a GHC bug.

Yes, I've successfully generated instance declarations from the
top-level.  I may as well describe the usecase: pretty printing a
value of any type in GHCI.  While this feature list isn't the main
point here, it'd be very cool to do things like:

* Look up the value of mutable references such as IORefs
* Print out functions as just their type
* Be able to evaluate particular subtrees of the pretty print output
(like present [1])
* Select a subportion of the output and get a variable out of it

Usage would look like $(pretty 'x).  This would reify the type of x
and transitively generate `Pretty` instances for things, by using my
th-reify-many package [2].  It then generates an expression which
invokes `pretty` on `x`, using these new instances.  This instance
generation can do clever things like check if a type has a Data
instance, and use it if available.

In this way, we can construct a pretty printer for ghci which will
work for any type.  Certainly, this is still possible without instance
generation, but it'd be quite clever to not need to re-generate the
pretty printing code for every invocation.

-Michael

[1] https://github.com/chrisdone/present
[2] https://github.com/mgsloan/th-reify-many

On Wed, Feb 11, 2015 at 6:51 PM, Geoffrey Mainland
mainl...@cs.drexel.edu wrote:
 Hi Michael,

 Try this out:

 https://gist.github.com/mainland/f18cf3827c4b0b64b835

 Have you had success generating instance declarations from top-level
 splices?

 Geoff

 On 02/11/2015 07:41 PM, Michael Sloan wrote:
 Hi!

 I don't mean to be accusatory with the whole documentation thing - I
 totally understand that most folks have a lot going on!  In this
 particular case, I got very excited when I initially saw addTopDecls,
 because it says it allows you to Add additional top-level
 declarations.  After implementing something to use it, I got rather
 disappointed as it couldn't add instances.

 So, when I say not implemented, it's just that the docs say it
 allows you to add additional top-level decls, when you can really only
 add functions, variable bindings, and foreign import decls.

 I didn't realize that not re-exporting these functions is due to their
 experimental status.  That makes sense!  I'm glad it was a conscious
 decision.  I just tried writing a demo of addTopDecls, but
 unfortunately using it to add a function and referencing this function
 causes a GHC internal error:
 https://gist.github.com/mgsloan/53d7fa50338c696e5c80 .  I haven't
 tried it with a foreign import yet.

 -Michael

 On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland
 mainl...@cs.drexel.edu wrote:
 Typed Template Haskell happened at the end of my tenure at MSR, and
 there was a mad rush to get it in to the compiler in time for 7.8.3 at
 the same time I was starting a new job. I'm afraid the documentation is
 indeed wanting, but the alternative was no typed Template Haskell.

 One side-effect was that the functions you note as present only in
 Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't
 re-export them from Language.Haskell.TH.

 I am willing to help with documentation if people want to use this
 functionality. Has anyone attempted to use addTopDecls? Michael, when
 you say it's not implemented, what do you mean? What, exactly, is not
 implemented?

 Cheers,
 Geoff

 On 2/11/15 6:32 PM, Michael Sloan wrote:
 I'd love for the implementation to be as powerful as the documentation
 suggests it is :D

 However, yes, in the meantime, fixing the documentation would be great!

 Also, I meant to say that addTopDecls is only exported by
 Language.Haskell.TH.Syntax.  While this is a digression, there are a
 few other handy functions that are oddly left out of
 Language.Haskell.TH: addDependentFile, addModFinalizer, and possibly
 more.

 -Michael

 On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones
 simo...@microsoft.com wrote:
 I would LOVE someone to improve the documentation for addTopDecls.  
 Manuel Chakravarty and Geoff Mainland were responsible for the 
 implementation.

 Simon

 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of 
 Michael
 | Sloan
 | Sent: 11 February 2015 23:19
 | To: Francesco Mazzoli
 | Cc: ghc-devs@haskell.org; haskell
 | Subject: Re: [Haskell-cafe] Anonymous FFI calls
 |
 | It seems like addTopDecls[1] will able to help here.  Unfortunately,
 | the function is not well documented and not very discoverable because
 | it's only exported by Language.Haskell.TH.
 |
 | The documentation doesn't mention that it can only be used to create
 | new top level functions and FFI imports[2].  I think that adding FFI
 | imports was the main motivation for implementing it.   In the past
 | I've wanted to generate instances via this function, but unfortunately
 | it's not implemented..
 |
 | Hope that helps!
 | -Michael

Re: Redundant constraints

[Michael Sloan]

One option for avoiding the warning without runtime overhead would be
to do something like this:

 f :: Ord a = a - a - Bool
 f x y = True
   where
 _ = x  y


On Wed, Jan 7, 2015 at 7:27 AM, Johan Tibell johan.tib...@gmail.com wrote:
 I think this probably makes sense, especially since you can silence the
 warning when you intend to add an unnecessary constraint.

 I had one thought though: consider an abstract data type with functions that
 operates over it. I might want to require e.g Ord in the definition of a
 function so I have freedom to change my implementation later, even though
 the current implementation doesn't need Ord. Think of it as separating
 specification and implementation. An example is 'nub'. I initially might
 implement it as a O(n^2) algorithm using only Eq, but I might want to leave
 the door open to using Ord to create something better, without later having
 to break backwards compatibility.

 On Wed, Jan 7, 2015 at 4:19 PM, Simon Peyton Jones simo...@microsoft.com
 wrote:

 Friends

 I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by
 default).  It tells you when a constraint in a signature is unnecessary,
 e.g.

  f :: Ord a = a - a - Bool

  f x y = True

 I think I have done all the necessary library updates etc, so everything
 should build fine.

 Four libraries which we don’t maintain have such warnings (MANY of them in
 transformers) so I’m ccing the maintainers:

 o   containers

 o   haskeline

 o   transformers

 o   binary



 Enjoy!



 Simon


 ___
 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