Re: How to get a heap visualization

[Erik de Castro Lopo]

Ben Gamari wrote:

> Yitzchak Gale  writes:
> 
> > Joachim, first and foremost, thanks for the awesome libraries
> > ghc-vis and ghc-heap-view.
> >
> > The design trade-offs for ghc-vis do make sense if you think of
> > it as a didactic tool. But as a debugging tool, the most important
> > factor is that it should "Just Work", with no big builds, no fiddling,
> > no googling. When you reach for a debugging tool, you are
> > *already* in a debugging situation; you don't have patience
> > for also debugging the tool.
> >
> I should point out that there is a differential (D3055) by erikd from
> earlier this year which folded ghc-heap-view into GHC. The goal was to
> make heap-view a supported library which could be relied upon by third
> party tools. As far as I can remember most of the hard work is done; it
> just needed some finishing touches. Perhaps you would be interested in
> picking it up?

Sorry if I gave the wrong impression, but IMO ghc-heap-view is a *long*
way from being ready to integrate into GHC. ghc-heap-view currently supports
most of the normal/simple heap object types. but has no support for more
complex objects. Furthermore, levity polymorphism adds a whole new dimension
to the problem. My estimate of the amount of work required to make ghc-heap-view
cover all the heap objects was such that I abandoned the project. I would
love to see someone pick it up and run with it.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: How to get a heap visualization

[Ben Gamari]

Yitzchak Gale  writes:

> Joachim, first and foremost, thanks for the awesome libraries
> ghc-vis and ghc-heap-view.
>
> The design trade-offs for ghc-vis do make sense if you think of
> it as a didactic tool. But as a debugging tool, the most important
> factor is that it should "Just Work", with no big builds, no fiddling,
> no googling. When you reach for a debugging tool, you are
> *already* in a debugging situation; you don't have patience
> for also debugging the tool.
>
I should point out that there is a differential (D3055) by erikd from
earlier this year which folded ghc-heap-view into GHC. The goal was to
make heap-view a supported library which could be relied upon by third
party tools. As far as I can remember most of the hard work is done; it
just needed some finishing touches. Perhaps you would be interested in
picking it up?

Cheers,

- Ben



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

Re: Spurious recompilations when using a compiler plugin

[Ben Gamari]

George Colpitts  writes:

> is it possible that this is also connected to
> https://ghc.haskell.org/trac/ghc/ticket/13604 ?
>
In that it pertains to the recompilation checker, yes. I've tried to
collect the recompilation checker bugs in play here under the
RecompilationCheck keyword in Trac. It would be great to get some eyes
on these issues as they are clearly causing real pain for some users.

Cheers,

- Ben



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

Re: Spurious recompilations when using a compiler plugin

[George Colpitts]

is it possible that this is also connected to
https://ghc.haskell.org/trac/ghc/ticket/13604 ?

On Tue, Sep 19, 2017 at 10:00 AM Ben Gamari  wrote:

> Conal Elliott  writes:
>
> > It appears that use of GHC plugins causes client code to get needlessly
> > recompiled. (See Trac issues 12567
> >  and 7414
> > .) It’s becoming more of a
> > problem for usability of the plugin
> >  I’ve been developing,
> and
> > I’m wondering what can be done. Some questions:
> >
> >- Is there any work in progress on fixing this situation?
> >- Are there serious obstacles to fixing it?
> >- Do plugin writers or users have any workarounds?
> >
> I think the real question is what sort of interface do plugin authors
> need?
>
> I suspect there are a few distinct tasks here,
>
>  * compute and record module implementation hashes in interface files
>
>  * to include plugin implementation hashes in the recompilation check
>
>  * to provide an interface allowing a plugin to compute a hash of its
>arguments which can be included into the recompilation check. One way
>of realising this would be to add a field like the following to Plugin,
>
>pluginHash :: [CommandLineOption] -> Maybe Fingerprint
>-- Nothing would denote "always rebuild"
>
>Would this help in your case?
>
> This would allow us to fix the TH problem in #7277 and fix the plugins
> problem in #7414 and #12567 in a nearly optimal way (assuming the plugin
> author is able to precisely define a hash).
>
> None of this is terribly difficult and given Nick's recent work on his
> row types plugin, it seems like it's getting more urgent.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Spurious recompilations when using a compiler plugin

[Ben Gamari]

Conal Elliott  writes:

> It appears that use of GHC plugins causes client code to get needlessly
> recompiled. (See Trac issues 12567
>  and 7414
> .) It’s becoming more of a
> problem for usability of the plugin
>  I’ve been developing, and
> I’m wondering what can be done. Some questions:
>
>- Is there any work in progress on fixing this situation?
>- Are there serious obstacles to fixing it?
>- Do plugin writers or users have any workarounds?
>
I think the real question is what sort of interface do plugin authors
need? 

I suspect there are a few distinct tasks here,

 * compute and record module implementation hashes in interface files

 * to include plugin implementation hashes in the recompilation check

 * to provide an interface allowing a plugin to compute a hash of its
   arguments which can be included into the recompilation check. One way
   of realising this would be to add a field like the following to Plugin,

   pluginHash :: [CommandLineOption] -> Maybe Fingerprint
   -- Nothing would denote "always rebuild"

   Would this help in your case?

This would allow us to fix the TH problem in #7277 and fix the plugins
problem in #7414 and #12567 in a nearly optimal way (assuming the plugin
author is able to precisely define a hash).

None of this is terribly difficult and given Nick's recent work on his
row types plugin, it seems like it's getting more urgent.

Cheers,

- Ben


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