Intended meaning of nubBy use in GHC's compiler/cmm/Debug.hs

[David Feuer]

The meaning of nubBy when applied to functions other than equivalence 
relations changed around the time you created compiler/cmm/Debug.hs. This 
makes it extra tricky to figure out exactly what that nubBy is expected to do. 
Do you think you could explain? Furthermore, it would be helpful to know what 
(if anything) is known about the relationships between the source spans in the 
the argument to the nubBy. This code is proving to be a bit of a hot spot in 
#11095 and the better we understand what's going on the better our chances of 
coming up with good solutions.

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

RE: Floating lazy primops

[David Feuer]

I've opened #13182 to explore one possible approach to dataToTag# that strikes 
me as likely to be simpler and to have fewer potential gotchas. But there could 
be critical points I'm missing about why we do it as we do now.
 Original message From: Simon Peyton Jones 
 Date: 1/23/17  4:47 PM  (GMT-05:00) To: David Feuer 
 Cc: ghc-devs@haskell.org Subject: RE: Floating lazy 
primops 
We should have this conversation on a ticket, perhaps #13027.

| good at the time). Are there actually any primops with lifted arguments
| where we *want* speculation? Perhaps the most important primop to
| consider is seq#, which is

I don't understand this question.  comment:23 of #13027 specifically says to 
skip the ok-for-spec test for lifted args. So you as "are the any" whereas 
comment:23 says "all".

| 2. If dataToTag# is marked can_fail (an aspect of https://
| phabricator.haskell.org/rGHC5a9a1738023a), is it still possible for it to
| end up being applied to an unevaluated argument? If not, perhaps the
| CorePrep specials can be removed altogether.

That may be true, but it's not easy to GUARANTEE in the way that Lint 
guarantees types.   So I'm happier leaving in the CorePrep stuff.. but please 
do add a comment there that points to the Note in primops.txt.pp and says that 
it seems unlikely this will ever occur.

| One more question: do you think it's *better* to let dataToTag# float and
| then fix it up later, or better to mark it can_fail? Unlike
| reallyUnsafePtrEquality#, dataToTag# is used all over the place, so it is
| important that it interacts as well as possible with the optimizer,
| whatever that entails.

I think better to do as now. That way the simplifier has the opportunity to 
common-up multiple evals into one.  If we add them later that's harder.  

By all means add Notes to explain this.

Thanks!

Simon


| -Original Message-
| From: David Feuer [mailto:da...@well-typed.com]
| Sent: 18 January 2017 19:45
| To: Simon Peyton Jones 
| Cc: ghc-devs@haskell.org
| Subject: Floating lazy primops
| 
| I opened up https://phabricator.haskell.org/D2987 to mark
| reallyUnsafePtrEquality# can_fail, but in the process I realized a couple
| things.
| 
| 1. Part of https://phabricator.haskell.org/rGHC5a9a1738023a may actually
| not have been such a hot idea after all (although it certainly sounded
| good at the time). Are there actually any primops with lifted arguments
| where we *want* speculation? Perhaps the most important primop to
| consider is seq#, which is
| (mysteriously?) marked neither can_fail nor has_side_effects, but another
| to look at is unpackClosure#, which seems likely to give different
| results before and after forcing. Most other primops with lifted
| arguments are marked has_side_effects, and therefore won't be floated out
| anyway.
| 
| 2. If dataToTag# is marked can_fail (an aspect of https://
| phabricator.haskell.org/rGHC5a9a1738023a), is it still possible for it to
| end up being applied to an unevaluated argument? If not, perhaps the
| CorePrep specials can be removed altogether.
| 
| David Feuer

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

Re: Next steps of the trac-to-maniphest migration?

[Simon Marlow]

On 24 January 2017 at 14:09, Matthew Pickering 
wrote:

> On Tue, Jan 24, 2017 at 1:26 PM, Simon Marlow  wrote:
>
> > Can we have custom fields with Maniphest?  I like the rich metadata we
> have
> > with OS / Architecture / Component / Failure types.  It's true that we
> don't
> > use it consistently, but at least when we do use it there's an obvious
> and
> > standard way to do it.  When I search for RTS bugs I know that at least
> all
> > the bugs I'm seeing are RTS bugs, even if I'm not seeing all the RTS
> bugs.
> > People responsible for particular architectures can keep their metadata
> up
> > to date to make it easier to manage their ticket lists.
>
> There was a long discussion about this on the original thread with
> people echoing this sentiment. I am of the opinion that projects would
> be a better fit as
>
> 1. They integrate better with the rest of phabricator
> 2. They are not relevant to every ticket. There are tickets about
> infrastructure matters for which the concept of OS is irrelevant for
> example.
>
> I like to think of projects as structured unstructured metadata.
> The structure is that you
> can group different project tags together as subprojects of a parent
> project but adding projects to a ticket is unstructured.
> This is how "architecture" is implemented currently -
> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/pr
> oject/view/101/
> On trac, keywords are not very useful as they are completely
> unstructured and not discoverable. I think projects greatly improve on
> this.
>

I think the problem here is that it's not obvious which projects should be
added to tickets.  As a ticket submitter, if I have metadata I'm not likely
to add it, and as developers we'll probably forget which fields we could
add.

Yes, Trac keywords are even more useless.  But we don't generally use
keywords; the point here is about the other metadata fields (OS,
Architecture, etc.).  Just having some text on the ticket creation page to
suggest adding OS / Architecture would help a lot.

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

Re: Next steps of the trac-to-maniphest migration?

[Matthew Pickering]

Thinking about this, it would probably make sense to at least transfer
the newcomer page as most of its instructions would reference things
on phab rather than trac if we migrated the tracker.

On Tue, Jan 24, 2017 at 4:00 PM, Joachim Breitner
 wrote:
> Hi,
>
> Am Dienstag, den 24.01.2017, 10:37 + schrieb Matthew Pickering:
>> If you have any example queries that you run often or queries which
>> you have embedded into wikipages then it would be useful to share
>> them so I can investigate.
>
> the embedded query on
> https://ghc.haskell.org/trac/ghc/wiki/Newcomers
> is pretty useful. But as you point out, that is still possible (if we
> migrate the wiki as well…)
>
> Greetings,
> Joachim
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Next steps of the trac-to-maniphest migration?

[Joachim Breitner]

Hi,

Am Dienstag, den 24.01.2017, 10:37 + schrieb Matthew Pickering:
> If you have any example queries that you run often or queries which
> you have embedded into wikipages then it would be useful to share
> them so I can investigate.

the embedded query on
https://ghc.haskell.org/trac/ghc/wiki/Newcomers
is pretty useful. But as you point out, that is still possible (if we
migrate the wiki as well…)

Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Next steps of the trac-to-maniphest migration?

[Matthew Pickering]

On Tue, Jan 24, 2017 at 1:26 PM, Simon Marlow  wrote:
> On 24 January 2017 at 10:37, Matthew Pickering 
> wrote:
>>
>> Thank you Simon.
>>
>> If you have any example queries that you run often or queries which
>> you have embedded into wikipages then it would be useful to share them
>> so I can investigate.
>
>
> The 8.2.1 status page has queries embedded:
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1
>
> Personally I do queries like "all open bugs where Component = RuntimeSystem
> ordered by priority".  It looks like we can probably do that with Maniphest.
>
> I couldn't take a look at the interface for creating a ticket because I have
> to create an account, and it says my account is pending approval.
>
> Does Maniphest have a concept of ticket dependencies? i.e. ticket X is
> blocked by Y.

Yes, see for example -
http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T7724

>
> Can we have custom fields with Maniphest?  I like the rich metadata we have
> with OS / Architecture / Component / Failure types.  It's true that we don't
> use it consistently, but at least when we do use it there's an obvious and
> standard way to do it.  When I search for RTS bugs I know that at least all
> the bugs I'm seeing are RTS bugs, even if I'm not seeing all the RTS bugs.
> People responsible for particular architectures can keep their metadata up
> to date to make it easier to manage their ticket lists.

There was a long discussion about this on the original thread with
people echoing this sentiment. I am of the opinion that projects would
be a better fit as

1. They integrate better with the rest of phabricator
2. They are not relevant to every ticket. There are tickets about
infrastructure matters for which the concept of OS is irrelevant for
example.

I like to think of projects as structured unstructured metadata.
The structure is that you
can group different project tags together as subprojects of a parent
project but adding projects to a ticket is unstructured.
This is how "architecture" is implemented currently -
http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/project/view/101/
On trac, keywords are not very useful as they are completely
unstructured and not discoverable. I think projects greatly improve on
this.

I also posted some images about the different work flows of projects,
subprojects and custom fields.

https://phabricator.haskell.org/M3/3/

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/M1

>
>> With regards to the last point. This is possible in a more structured
>> way. You can create a dashboard with a single query embedded and then
>> embed this using standard remarkup syntax.
>>
>> For example on a project page, I embedded a query which matched
>> tickets with "PatternSynonyms" and "newcomer".
>>
>>
>> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/project/profile/165/
>>
>> You can embed this panel anywhere where remarkup is accepted. For
>> example, in a wiki page -
>> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/w/ or
>> tickets http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T12548
>
>
> Ok, it's good to know that Phabricator can embed queries, but we're not
> planning to move the wiki, correct?

I am not proposing that but if there is interest it could be
investigated. The migration would be trickier due to the complicated
ways that people use markup in wiki pages.

>
>>
>> It is a bit more heavyweight to setup but much easier to get right due
>> to the structured editing interface which trac doesn't provide for
>> these kinds of queries.
>>
>> Matt
>>
>> On Tue, Jan 24, 2017 at 9:41 AM, Simon Marlow  wrote:
>> > On 21 January 2017 at 22:21, Matthew Pickering
>> > 
>> > wrote:
>> >>
>> >> Hello devs,
>> >>
>> >> Thanks to everyone so far who has looked at and commented on the
>> >> prototype. It seems that the response is generally positive so I would
>> >> like to drive the process forwards.
>> >>
>> >> In order for that to happen, someone needs to decide whether we as a
>> >> community think it is a good idea. It seems to make sense if those who
>> >> use the tracker most make this decision so I propose that Simon and
>> >> Ben should ultimately be the ones to do this.
>> >>
>> >> Therefore, I propose this timeline
>> >>
>> >> 1. Before 11th Feb (3 weeks from today) we decide whether we want to
>> >> migrate the issue tracker.
>> >> 2. A working group is established who will work through the details of
>> >> the migration with the minimum of a final prototype built from a clone
>> >> of the actual installation.
>> >> 3. Migration would happen before the end of March.
>> >
>> >
>> > Sounds good to me.  I personally have only glanced at it so far, but
>> > I'll
>> > give it some attention.  I'm pretty attached to Trac's ability to do
>> > complex
>> > queries on tickets and the ability to embed ticket queries into wiki
>> > pages,
>> > so the gains would have to be compelling to outweigh the losses for me.
>> > But
>> > 

Re: Next steps of the trac-to-maniphest migration?

[Simon Marlow]

On 24 January 2017 at 10:37, Matthew Pickering 
wrote:

> Thank you Simon.
>
> If you have any example queries that you run often or queries which
> you have embedded into wikipages then it would be useful to share them
> so I can investigate.
>

The 8.2.1 status page has queries embedded:
https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1

Personally I do queries like "all open bugs where Component = RuntimeSystem
ordered by priority".  It looks like we can probably do that with Maniphest.

I couldn't take a look at the interface for creating a ticket because I
have to create an account, and it says my account is pending approval.

Does Maniphest have a concept of ticket dependencies? i.e. ticket X is
blocked by Y.

Can we have custom fields with Maniphest?  I like the rich metadata we have
with OS / Architecture / Component / Failure types.  It's true that we
don't use it consistently, but at least when we do use it there's an
obvious and standard way to do it.  When I search for RTS bugs I know that
at least all the bugs I'm seeing are RTS bugs, even if I'm not seeing all
the RTS bugs. People responsible for particular architectures can keep
their metadata up to date to make it easier to manage their ticket lists.

With regards to the last point. This is possible in a more structured
> way. You can create a dashboard with a single query embedded and then
> embed this using standard remarkup syntax.
>
> For example on a project page, I embedded a query which matched
> tickets with "PatternSynonyms" and "newcomer".
>
> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/
> project/profile/165/
>
> You can embed this panel anywhere where remarkup is accepted. For
> example, in a wiki page -
> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/w/ or
> tickets http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T12548
>

Ok, it's good to know that Phabricator can embed queries, but we're not
planning to move the wiki, correct?


> It is a bit more heavyweight to setup but much easier to get right due
> to the structured editing interface which trac doesn't provide for
> these kinds of queries.
>
> Matt
>
> On Tue, Jan 24, 2017 at 9:41 AM, Simon Marlow  wrote:
> > On 21 January 2017 at 22:21, Matthew Pickering <
> matthewtpicker...@gmail.com>
> > wrote:
> >>
> >> Hello devs,
> >>
> >> Thanks to everyone so far who has looked at and commented on the
> >> prototype. It seems that the response is generally positive so I would
> >> like to drive the process forwards.
> >>
> >> In order for that to happen, someone needs to decide whether we as a
> >> community think it is a good idea. It seems to make sense if those who
> >> use the tracker most make this decision so I propose that Simon and
> >> Ben should ultimately be the ones to do this.
> >>
> >> Therefore, I propose this timeline
> >>
> >> 1. Before 11th Feb (3 weeks from today) we decide whether we want to
> >> migrate the issue tracker.
> >> 2. A working group is established who will work through the details of
> >> the migration with the minimum of a final prototype built from a clone
> >> of the actual installation.
> >> 3. Migration would happen before the end of March.
> >
> >
> > Sounds good to me.  I personally have only glanced at it so far, but I'll
> > give it some attention.  I'm pretty attached to Trac's ability to do
> complex
> > queries on tickets and the ability to embed ticket queries into wiki
> pages,
> > so the gains would have to be compelling to outweigh the losses for me.
> But
> > I'll give it a closer look.
> >
> > Cheers
> > Simon
> >
> >>
> >> I think Ben summarised the discussions quite well on the wiki page -
> >> https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Maniphest
> >>
> >> And the prototype continues to exist here.
> >> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/
> >>
> >> As always, any comments welcome.
> >>
> >> 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: StablePtr / StableName ?

[Johannes Waldmann]

Dear Simon,

thanks for looking into this.

> is StableName in the inner loop? 

Yes. This application's inner loop uses a
HashMap (StableName Expression) Int  for memoization.

This is the Tseitin transform: for each node, build a literal.
Each node is stable-named.

I guess the RTS's hashmap performance comes into play
only when pointers are moved (in GC).
The application's hashmap cost will dominate,
because it's used more often.

> You'd have to measure it.

I did. It seems we're good on StableNames, and time goes elsewhere.
https://github.com/ekmett/ersatz/issues/30#issuecomment-274775792

- Johannes.

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

Re: Next steps of the trac-to-maniphest migration?

[Matthew Pickering]

Thank you Simon.

If you have any example queries that you run often or queries which
you have embedded into wikipages then it would be useful to share them
so I can investigate.

With regards to the last point. This is possible in a more structured
way. You can create a dashboard with a single query embedded and then
embed this using standard remarkup syntax.

For example on a project page, I embedded a query which matched
tickets with "PatternSynonyms" and "newcomer".

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/project/profile/165/

You can embed this panel anywhere where remarkup is accepted. For
example, in a wiki page -
http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/w/ or
tickets http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T12548

It is a bit more heavyweight to setup but much easier to get right due
to the structured editing interface which trac doesn't provide for
these kinds of queries.

Matt

On Tue, Jan 24, 2017 at 9:41 AM, Simon Marlow  wrote:
> On 21 January 2017 at 22:21, Matthew Pickering 
> wrote:
>>
>> Hello devs,
>>
>> Thanks to everyone so far who has looked at and commented on the
>> prototype. It seems that the response is generally positive so I would
>> like to drive the process forwards.
>>
>> In order for that to happen, someone needs to decide whether we as a
>> community think it is a good idea. It seems to make sense if those who
>> use the tracker most make this decision so I propose that Simon and
>> Ben should ultimately be the ones to do this.
>>
>> Therefore, I propose this timeline
>>
>> 1. Before 11th Feb (3 weeks from today) we decide whether we want to
>> migrate the issue tracker.
>> 2. A working group is established who will work through the details of
>> the migration with the minimum of a final prototype built from a clone
>> of the actual installation.
>> 3. Migration would happen before the end of March.
>
>
> Sounds good to me.  I personally have only glanced at it so far, but I'll
> give it some attention.  I'm pretty attached to Trac's ability to do complex
> queries on tickets and the ability to embed ticket queries into wiki pages,
> so the gains would have to be compelling to outweigh the losses for me.  But
> I'll give it a closer look.
>
> Cheers
> Simon
>
>>
>> I think Ben summarised the discussions quite well on the wiki page -
>> https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Maniphest
>>
>> And the prototype continues to exist here.
>> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/
>>
>> As always, any comments welcome.
>>
>> 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: StablePtr / StableName ?

[Simon Peyton Jones via ghc-devs]

Add this conversation to #13165?

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Marlow
Sent: 24 January 2017 09:38
To: Johannes Waldmann 
Cc: ghc-devs@haskell.org
Subject: Re: StablePtr / StableName ?

StableNames do use the RTS hash table implementation, but StablePtr does *not*, 
the ticket is incorrect.  But to be clear, nothing has changed - StableName has 
always used this hash table implementation.  No doubt it could be faster if we 
used a better hash table, but whether it matters to you or not depends on what 
else your application is doing - is StableName in the inner loop? You'd have to 
measure it.

Cheers
Simon

On 22 January 2017 at 16:09, Johannes Waldmann 
mailto:johannes.waldm...@htwk-leipzig.de>> 
wrote:
Dear ghc devs,

would the StablePtr performance issue (slow hash table)
https://ghc.haskell.org/trac/ghc/ticket/13165
also affect StableNames?
Cf. 
https://github.com/ekmett/ersatz/issues/30

Could making 10^5 stable names, and accessing each just once,
take noticeable time? Where would this show up in a profile?

I guess there's no easy way to change the ersatz library
(StableName this is the fundamental mechanism for detecting sharing)
but if these issues are related, then ersatz provides a
performance test case.

Thanks, Johannes.
___
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: Next steps of the trac-to-maniphest migration?

[Simon Marlow]

On 21 January 2017 at 22:21, Matthew Pickering 
wrote:

> Hello devs,
>
> Thanks to everyone so far who has looked at and commented on the
> prototype. It seems that the response is generally positive so I would
> like to drive the process forwards.
>
> In order for that to happen, someone needs to decide whether we as a
> community think it is a good idea. It seems to make sense if those who
> use the tracker most make this decision so I propose that Simon and
> Ben should ultimately be the ones to do this.
>
> Therefore, I propose this timeline
>
> 1. Before 11th Feb (3 weeks from today) we decide whether we want to
> migrate the issue tracker.
> 2. A working group is established who will work through the details of
> the migration with the minimum of a final prototype built from a clone
> of the actual installation.
> 3. Migration would happen before the end of March.
>

Sounds good to me.  I personally have only glanced at it so far, but I'll
give it some attention.  I'm pretty attached to Trac's ability to do
complex queries on tickets and the ability to embed ticket queries into
wiki pages, so the gains would have to be compelling to outweigh the losses
for me.  But I'll give it a closer look.

Cheers
Simon


> I think Ben summarised the discussions quite well on the wiki page -
> https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Maniphest
>
> And the prototype continues to exist here.
> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/
>
> As always, any comments welcome.
>
> 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: StablePtr / StableName ?

[Simon Marlow]

StableNames do use the RTS hash table implementation, but StablePtr does
*not*, the ticket is incorrect.  But to be clear, nothing has changed -
StableName has always used this hash table implementation.  No doubt it
could be faster if we used a better hash table, but whether it matters to
you or not depends on what else your application is doing - is StableName
in the inner loop? You'd have to measure it.

Cheers
Simon

On 22 January 2017 at 16:09, Johannes Waldmann <
johannes.waldm...@htwk-leipzig.de> wrote:

> Dear ghc devs,
>
> would the StablePtr performance issue (slow hash table)
> https://ghc.haskell.org/trac/ghc/ticket/13165
> also affect StableNames?
> Cf. https://github.com/ekmett/ersatz/issues/30
>
> Could making 10^5 stable names, and accessing each just once,
> take noticeable time? Where would this show up in a profile?
>
> I guess there's no easy way to change the ersatz library
> (StableName this is the fundamental mechanism for detecting sharing)
> but if these issues are related, then ersatz provides a
> performance test case.
>
> Thanks, Johannes.
> ___
> 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