search

timholy / MethodAnalysis.jl

Utilities to analyze Julia's method tables
https://timholy.github.io/MethodAnalysis.jl/stable/
MIT License
94 stars 3 forks source link

Might find some useful analyses in LookingGlass.jl? #9

Open NHDaly opened 4 years ago

NHDaly commented 4 years ago

Hi @timholy! :)

I'm super stoked to see this package, and i want more people to be able to inspect things like this! :)

If you haven't already, you might enjoy having a look at https://github.com/NHDaly/LookingGlass.jl, where I've put together some very similar functions, with a similar aim of making inspection and reflection easier! I've found these to be really helpful when understanding how specializations and backedges are added by julia.

For example: https://github.com/NHDaly/LookingGlass.jl/blob/8a599f84a1e16afb96027b31d93ecdbfb295eb6f/src/LookingGlass.jl#L59-L69

I think we have overlapping content here, and it looks like your work is more fleshed out and might catch more corner cases? So i'm happy to merge these packages as well, if you think that makes sense! :)

Thanks for your time, @timholy! :)

timholy commented 4 years ago

That does look similar! Sorry I didn't discover it when I created this package.

For the specific one you linked, to answer the question in your comment: m.specializations can be a SimpleVector, a TypeMapEntry, or a TypeMapLevel. Julia's base/reflection.jl has the visit function to iterate through these objects, and so this package is basically designed around extending the visit interface. It adds a wrinkle: the function you pass to visit should return true if you want to keep descending into the object, and false if you want to not pursue that branch any further. This allows one to do stuff like "only grab the modules" or "descend to all CodeInstances, but only for 2-argument methods" fairly easily. This is both powerful (and lets you write efficient code), but also annoying because if you forget to return a Bool you get an error.

I'd be happy to do whatever you think is best. From a brief glance, it looks like there are some differences in offerings (especially the Bindings stuff, cool!). We could indeed try to merge them, which might be best for the community in the long run. Alternatively, I could link to LookingGlass from the README of this package.

If we do merge them, I suggest we put the combined package in some organization, just so it's a "neutral" ownership. I'm not exactly sure what organization to suggest, though. JuliaDebug?

vchuravy commented 2 years ago

I'm not exactly sure what organization to suggest, though. JuliaDebug?

That's where Cthulhu lives so I think that's a good fit.

timholy commented 2 years ago

I'd be happy to move this package to JuliaDebug. Shall we combine it and LookingGlass, @NHDaly? It will take some work but presumably the community will be better off in the long run.

I'd be happy to go with your package name (it's both more poetic and captures the fact that we can both analyze more than just methods). For the functionality, I'd say lets combine where possible. Or we could come up with a new name.

I do think the visit architecture here is a solid foundation so I think we should adopt it as the core of the package.

NHDaly commented 2 years ago

Thanks @timholy! Sorry for my delay (-- among other things, I got married! 🎉) :)

Awesome! Moving to JuliaDebug sounds great. 👍 +1 to that. Yeah, I definitely defer to your opinions on this: I hacked together most of LookingGlass.jl over a couple days, and I wouldn't vouch for its design. I agree that I like the name, and it's poetic, so I'm happy to merge into that name, but also happy with anything else. Very little preference from me.

I'm still a bit occupied in development mode these days at work, but in maybe 2-4 weeks I'll probably be ramping back up on a more performance-analysis heavy mode at work, and I'd have more time to contribute here! Please feel free to make any decisions in my absence, but i'm looking forward to helping more when i'm able!