Re: Registering pretty-printers

[Tom Tromey <tromey@redhat.com>]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> To begin with, this works only if there's linking.

Yeah.

Vladimir> I think it's generally wrong to assume that pretty-printers
Vladimir> are either:
Vladimir> 1. Always distributed with the library they provide
Vladimir> pretty-printing for
Vladimir> 2. Are associated with any separately compiled code.

What we actually have is a setup that makes it very easy to auto-load
pretty-printers in this situation, which I believe will be the most
common one in the long run.

This setup is constructed by gluing together a couple generic pieces:
objfile hook auto-loading and per-objfile pretty-printer lookup
functions.

Because this functionality is generic, we can actually load
pretty-printers any other way.  When doing development I just "python
execfile" them into my gdb session; in the printers I write I use the
convention that if the current objfile is None, then the code
registers the printers globally.  Well, in theory -- I see I broke
this for libstdc++.

(I think we ought do document this convention btw.)

I would like to solve the remaining problems.  I just don't know how
to do it, in a way that preserves the qualities I care about.  What I
care about is, more or less, embedded in what I implemented: make it
super easy for printers to be developed alongside applications and
libraries, and be made available automatically without user
intervention.

Vladimir> Therefore, we should make up some conventions how a
Vladimir> pretty-printer can be packaged separately, preferably as a
Vladimir> single file, and how IDE, given name of the file and nothing
Vladimir> else, can enable pretty printing.

That would be fine by me.

Vladimir> Say, how about tar.gz, which is unpacked by IDE, whose top-level
Vladimir> directory is added to PYTHONPATH, and which should have top-level
Vladimir> file called init.py, with a function 'init_pretty_printers'?

I don't see how it is better than the hook file approach we already
have.  Your IDE could easily send "python execfile" to load any given
hook file.  Defining a function in that file doesn't add anything that
I can see.

It seems to me that you could make a .tar holding all the files from
libstdc++/python, then have your IDE unpack these somewhere, update
sys.path, and execfile the file(s) in the topmost directory.  Assuming
these files follow the "None convention", it will work fine.

Packaging as a .tar or whatever would have to be IDE-specific, I think.
I don't think it would work for my situation.

Another thing I've contemplated is having a generic event that is
fired when an objfile is loaded.  Then you could avoid the
file-name-based auto-loading scheme and roll your own in Python.  I
don't know if this would help you or not.

Tom> For case #2 ... to me this seems like a short term problem, so I have
Tom> not been worrying about it much.  We could put a HOWTO on the wiki,
Tom> for example.  That would suffice for many users.

Vladimir> I suspect you approach this from a bit of Fedora-centric
Vladimir> approach.

I'm sure you're right.

Tom