Hi Andrew, I updated the README for ghc-debug last week but forget to send this mail!
https://gitlab.haskell.org/ghc/ghc-debug Cheers, Matt On Wed, Jan 27, 2021 at 10:15 PM Andrew Kvapil <vil...@seznam.cz> wrote: > > Hello Ben, > > Thanks for your suggestions. The decision to adapt GHCi came out of a > discussion with my supervisor and his colleagues. At this point the > entire set of desired capabilities of the work is still unknown, however > we do consider the GHCi-compatible programs to represent a large enough > set for future analysis, and the ease of mapping breakpoints back to > source code is a significant benefit. > > I do plan on using the ghc-heap-view (I assume that's what you meant by > ghc-heap, or is there another library I don't know about?) logic in the > project, although I'm currently more focused on implementing the proper > hook mechanism. I expect that events of deeply nested thunks being > forced will be quite important. The possibility of tracking control > flow via breakpoints/tracepoints also seems appealing. I'm not aware > of any existing solutions which would allow dynamic tracing, although > it's very well possible I didn't look hard enough. > > Regarding ghc-debug, I'm not sure what kinds of trade-offs it offers > compared to the approach I'm currently taking. It looks like it's a > fairly newborn project, do you think it's mature enough for the > proposed use cases? I couldn't find docs online, although I did come > across [0] which Discourse[1] says is related. I've yet to watch the > introduction video. Support for unboxed tuples and other features not > supported by GHCi would of course be nice, although performance is not > a concern. Keeping the relationship between source code spans and > heap objects in the infotables is an intriguing idea. > > > Note that Luite's recent work on refactoring the bytecode generator to > > > produce code from STG is quite relevant here. In particular, you will > > > likely want to look at !4589 [1], which does the work of refactoring > > > Tickish to follow the Trees That Grow pattern. You would likely want to > > > do the same to capture your free variable information. > > > Excellent, I was not aware of this. Thank you! > > > Regards, > Andrew > > > > [0]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ > [1]: > https://discourse.haskell.org/t/an-introduction-to-ghc-debug-precise-memory-analysis-for-haskell-programs/1771 > > > On 26/01/2021 16:28, Ben Gamari wrote: > > Andrew Kvapil <vil...@seznam.cz> writes: > > > >> Hello, > >> > >> I'm interested in inspecting the strictness of functions at runtime > >> and the depth of thunks "in the wild." > > > > Hi Andrew, > > > > Interesting. When I first read your introduction my first thought was to > > rather walk the "normal" heap using ghc-heap or, perhaps, the relatively > > new ghc-debug library [1] rather than introduce this feature in GHCi. > > It's hard to know whether non-GHCi-based approach is viable without > > knowing more about what you are doing, but it potentially brings the > > benefit of generality: your analysis is not limited to programs with can > > be run under GHCi. > > > > Of course, it also brings some challenges: You would need to find a way > > to associate info table symbols with whatever information you need of > > from the Core program and in the presence of simplification tying your > > results back to the source program may not be possible at all. > > > > Cheers, > > > > - Ben > > > > > > [1] https://gitlab.haskell.org/ghc/ghc-debug > > > >> For this reason I'm modifying > >> GHC 8.10.2, essentially to add additional information to breakpoints. > >> I'd like to reuse the logic behind GHCi's :print command > >> (pprintClosureCommand, obtainTermFromId, ...) for which I suppose I > >> need Id's. Those however don't exist for destructuring patterns, such > >> as those in the following equations: > >> > >> last [x] = x > >> last (_:xs) = last xs > >> > >> So I'm wondering where would be a good place in the pipeline to > >> transform patterns like these into at-patterns, to give them Id's. > >> However, the breakpoint logic only looks at the free variables of the > >> right-hand sides and not transitively, which means that e.g. in the > >> following example neither ':print arg1' nor ':print as' works when the > >> interpreter hits a breakpoint in the top level expression on the RHS: > >> > >> qsort arg1@(a:as) = qsort left ++ [a] ++ qsort right > >> where (left, right) = (filter (<=a) as, filter (>a) as) > >> > >> Thus I'd also like to know how to extend the free var logic for > >> Tickish that eventually leads to CgBreakInfo and :print's ability to > >> inspect these bindings at runtime. My goal would be to determine to what > >> extent was a thunk evaluated during function application. > >> > > Note that Luite's recent work on refactoring the bytecode generator to > > produce code from STG is quite relevant here. In particular, you will > > likely want to look at !4589 [1], which does the work of refactoring > > Tickish to follow the Trees That Grow pattern. You would likely want to > > do the same to capture your free variable information. > > > > Cheers, > > > > - Ben > > > > > > [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4589 > > > _______________________________________________ > 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
