Re: Debugging GHC with GHCi

[Ben Gamari]

Thomas Jakway  writes:

> I want to be able to load certain GHC modules in interpreted mode in 
> ghci so I can set breakpoints in them.  I have tests in the testsuite 
> that are compiled by inplace/bin/ghc-stage2 with -package ghc.  I can 
> load the tests with ghc-stage2 --interactive -package ghc but since ghc 
> is compiled I can only set breakpoints in the tests themselves.  Loading 
> the relevant files by passing them as absolute paths to :l loads them 
> but ghci doesn't stop at the breakpoints placed in them (I'm guessing 
> because ghci doesn't realize that the module I just loaded is meant to 
> replace the compiled version in -package ghc).
>
> So if I use
>
> inplace/bin/ghc-stage2 --interactive -package ghc mytest.hs
> then
> :l abs/path/to/AsmCodeGen.hs
>
> and set breakpoints, nothing happens.
>
Many of us would love to be able to load GHC into GHCi. Unfortunately,
we aren't currently in a position where this is possible. The only thing
standing in our way is the inability of GHC's interpreter to run modules
which use unboxed tuples. While there are a few modules within GHC which
use unboxed tuples, none of them are particularly interesting for
debugging purposes, so compiling them with -fobject-code should be fine.
In principle this could be accomplished by,

{-# OPTIONS_GHC -fobject-code #-}

However, as explained in #10965, GHC sadly does not allow this. I spent
a bit of time tonight trying to see if I could convince GHC to first
manually build object code for the needed modules, and then load
bytecode for the rest. Unfortunately recompilation checking fought me at
every turn.

The current state of my attempt can be found here [1]. It would be great
if someone could pick it up. This will involve,

 * Working out how to convince the GHC to use the object code for
   utils/Encoding.o instead of recompiling

 * Identifying all of the modules which can't be byte-code compiled and
   add them to $obj_modules

 * Chassing down whatever other issues that might pop up along the way

I also wouldn't be surprised if you would need this GHC patch [2].

Cheers,

- Ben


[1] https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e
[2] 
http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9903fd46246


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

Re: Debugging GHC with GHCi

[Richard Eisenberg]

> On Jan 8, 2017, at 8:33 PM, Thomas Jakway  wrote:
> 
> Currently I'm using trace & friends to do printf-style debugging but it's 
> definitely not ideal.

I don't have an answer to your question, but I can tell you that this is 
exactly what I do. It's not ideal at all. If you figure out how to do this, 
tell us!

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

Phabricator upgrade underway

[Ben Gamari]

Hello everyone,

I'll be bringing down Phabricator for an upgrade in a few minutes. I'll
let you know when things are back up.

Cheers,

- Ben


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

Re: nofib on Shake

[Joachim Breitner]

Hi,

Am Sonntag, den 08.01.2017, 13:45 -0500 schrieb Ben Gamari:
> > We could also create a cabal and stack files for `nofib-analyse` (making
> > it possible to use some libraries for it).
> >
> This would be great. This would allow me to drop a submodule from my own
> performance monitoring tool.

Exists since last April:
http://hackage.haskell.org/package/nofib-analyse

Only the binary so far, though, but good enough for
"cabal install nofib-analyse".

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: nofib on Shake

[Ben Gamari]

Michal Terepeta  writes:

> Hi all,
>
> While looking at nofib, I've found a blog post from Neil Mitchell [1],
> which describes a Shake build system for nofib. The comments mentioned
> that this should get merged, but it seems that nothing actually happened?
> Is there some fundamental reason for that?
>
Indeed there is no fundamental reason and I think it would be great to
make nofib a bit easier to run and modify.

However, I think we should be careful to maintain some degree of
compatibility. One of the nice properties of nofib is that it can be run
against a wide range of compiler versions. It would be ashame if, for
instance, Joachim's gipeda had to do different things to extract
performance metrics from logs produced by logs pre- and post-Shake
nofibs.

> We could also create a cabal and stack files for `nofib-analyse` (making
> it possible to use some libraries for it).
>
This would be great. This would allow me to drop a submodule from my own
performance monitoring tool.

Cheers,

- Ben


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

nofib on Shake

[Michal Terepeta]

Hi all,

While looking at nofib, I've found a blog post from Neil Mitchell [1],
which describes a Shake build system for nofib. The comments mentioned
that this should get merged, but it seems that nothing actually happened?
Is there some fundamental reason for that?

If not, I'd be interested picking this up - the current make-based
system is pretty confusing for me and `runstdtest` looks simply
terrifying ;-)
We could also create a cabal and stack files for `nofib-analyse` (making
it possible to use some libraries for it).

Thanks,
Michal

[1]
http://neilmitchell.blogspot.ch/2013/02/a-nofib-build-system-using-shake.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Richard Eisenberg]

> On Jan 8, 2017, at 12:40 AM, Ben Gamari  wrote:
> 
> * Metadata: Custom fields are supported.

In agreement with your comments above, I'm glad to see this. Trac's metadata 
currently is suboptimal, but I don't think this means we should throw out the 
ability to have structured metadata in its entirety.

> 
> * Flexible user interface: Custom fields can be hidden from the new
>   ticket form to prevent user confusion.

Yay.

> 
> * Familiarity: Many users may feel more at home in Phabricator's interface;
>   reMarkup's similarity to Markdown also helps.

Nitpick: Do we have any control over this? (I doubt it.) I find switching 
between GitHub Markdown, RST, and reMarkup to be a low-grade but constant 
annoyance.
> 
> * Legibility:

I seem to recall that Phab originally used gray-on-white in Diffs, but we were 
able to fix with some CSS. (Or did it require upstream intervention?) Perhaps 
we can do something similar here. I find the modern trend to use lower-contrast 
interfaces utterly maddening.

> 
> What does Trac do well?
> ---
> 
> * Convenient cross-referencing: while the syntax is a bit odd, once you
>   acclimate it is quite liberating to be able to precisely
>   cross-reference tickets, wiki documents, and comments without copying
>   links around.

Yesyesyes.

> 
> * Automation of ticket lifecycle: Trac tickets progress through their
>   lifecycle (e.g. from "new" to "patch" to "merge" to "closed"
>   statuses) through predefined actions. This means that moving a ticket
>   through its lifecycle typically only requires one click and the right
>   thing happens with no additional effort. I think this is a great model,
>   although in practice it's not clear how much we benefit from it
>   compared to a typical Maniphest workflow.

I'm less convinced about this benefit of Trac. For instance, if I close a 
ticket in error, I lose ownership. Then I have to reopen but cannot set an 
owner at the same time. Maybe it's just a configuration issue, but I imagine we 
have experienced devs doing ticket-state management and don't need strict 
controls here.
> 
> 
> What does Trac do poorly?
> -
> 
> * Active development: Trac is largely a stagnant project.

I was unaware of this. This is a significant downside in my opinion.

> * Safety: I have personally lost probably a half-dozen hours of my life
>   to Trac eating comments.

That's odd. I have not had this experience.

> 
> * Relations between tickets: Trac has essentially no first-class notion
>   of ticket relatedness. Even duplicate tickets need to be manually
>   annotated in both directions.

Yes. Frustrating.

> 
> * Keywords are hard to discover and apply

Yes. With discoverable keywords, we might be able to get more reporter buy-in.


One more issue that we should consider: email notification. Perhaps I'm stodgy, 
but I'm a big fan of email. Trac emails notifications are not quite ideal (I 
wish the new content came above the metadata), but they're very functional. How 
does Phab compare? Can we see a sample notification it might create?

Thanks!
Richard


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