-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
structure dumping with memory addresses and bits #6269
Comments
You can probably adapt the printing code from StrPack for at least some of this. |
Useful: the |
I think this would be a great feature. I've already blown some people's minds of how easy it is to get the native and llvm code generated by functions; it would be equally great to be able to interactively take a peak at structures and their memory layout. |
Yes, that would be cool. We need fewer ways to show things though. Or more composable ones. |
My vote is for more ways to print in a more composable way. That would require a much better structure on the whole |
Also related #5709 |
This seems very much like a feature that can live outside of Base. @JeffBezanson and/or @vtjnash, please leave open if you disagree, but otherwise just closet this. |
Yes. Something like this could live inside InteractiveUtils, but probably editor-specific designs (such as Juno, Jupyter, or my toy data exploration tool from JuliaCon London 2018) are more profitable for others to explore. |
We have
dump
andxdump
, which are IMO, both half broken so I end up trying one and then the other and one usually works but it's inconsistent which. I'd like to replace them with something that gives much better low-level information about data structures, including memory addresses and bit patterns. One of the purposes of this should be to illuminate how data is actually laid out in memory – see https://groups.google.com/forum/#!topic/julia-users/9LkAIemc5VE for example. It should be easy to see if fields are stored inline or separately allocated on the heap. I know we work hard to hide that detail, but sometimes it's pretty important and eventually, we're going to have to make documented guarantees about how different structures are laid out for the sake of C interop, if nothing else.The text was updated successfully, but these errors were encountered: