From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14827 invoked by alias); 12 Jun 2009 17:36:58 -0000 Received: (qmail 14818 invoked by uid 22791); 12 Jun 2009 17:36:57 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34,SARE_LWSHORTT,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Jun 2009 17:36:50 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n5CHamuq010537 for ; Fri, 12 Jun 2009 13:36:48 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5CHaluD021073 for ; Fri, 12 Jun 2009 13:36:47 -0400 Received: from opsy.redhat.com (vpn-13-111.rdu.redhat.com [10.11.13.111]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5CHalE7015463; Fri, 12 Jun 2009 13:36:47 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id C0A3F486BA; Fri, 12 Jun 2009 11:36:46 -0600 (MDT) To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: Registering pretty-printers References: <200906080310.58102.vladimir@codesourcery.com> <200906111229.04020.vladimir@codesourcery.com> From: Tom Tromey Reply-To: Tom Tromey Date: Fri, 12 Jun 2009 17:36:00 -0000 In-Reply-To: <200906111229.04020.vladimir@codesourcery.com> (Vladimir Prus's message of "Thu\, 11 Jun 2009 12\:29\:03 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00125.txt.bz2 >>>>> "Vladimir" == Vladimir Prus 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