From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7512 invoked by alias); 20 Jan 2013 15:13:58 -0000 Received: (qmail 7500 invoked by uid 22791); 20 Jan 2013 15:13:57 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Jan 2013 15:13:51 +0000 Received: by mail-la0-f46.google.com with SMTP id fq12so2844137lab.33 for ; Sun, 20 Jan 2013 07:13:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.25.70 with SMTP id a6mr6314515lbg.117.1358694829059; Sun, 20 Jan 2013 07:13:49 -0800 (PST) Received: by 10.114.97.35 with HTTP; Sun, 20 Jan 2013 07:13:48 -0800 (PST) In-Reply-To: <8738y2jmmb.fsf@fleche.redhat.com> References: <87fw22jq1g.fsf@fleche.redhat.com> <8738y2jmmb.fsf@fleche.redhat.com> Date: Sun, 20 Jan 2013 15:13:00 -0000 Message-ID: Subject: Re: Colors in gdb From: Matt Rice To: Tom Tromey Cc: Kevin Pouget , Surya Kiran Gullapalli , gdb@sourceware.org Content-Type: multipart/mixed; boundary=bcaec55556b0a4ef3504d3b9ca9d X-IsSubscribed: yes 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: 2013-01/txt/msg00067.txt.bz2 --bcaec55556b0a4ef3504d3b9ca9d Content-Type: text/plain; charset=ISO-8859-1 Content-length: 2950 On Tue, Jan 15, 2013 at 11:02 AM, Tom Tromey wrote: >>>>>> "Kevin" == Kevin Pouget writes: > > Kevin> I have colors in my gdb Python prompt since quite a while, I wonder > Kevin> what could be different in the context of prompt printing and pretty > Kevin> printing ? > > For ordinary printing, there's just no place to hook into gdb. its worth noting that the standard python print function works with escape sequences, > For printing via Python pretty-printers, strings are further processed > by gdb before printing, and in particular the escape sequences are > turned into plain text. attached is a silly modification to the example pretty printer from the docs[1]: it contains an additional method 'to_color_string', tested like: py print gdb.default_visualizer(gdb.parse_and_eval("x")).to_color_string() which could be easily shoved into a 'define' or something (would be nice if it fell back to normal to_string method) maybe i'm old in not liking the idea of making these work with the standard 'print' command, because the escape sequences are terminal type dependent, which is IMO fine for a prompt set by a gdbinit, but less so for a pretty printer distributed with a library... this opinion is only strengthened by considering a std::string containing an escape sequence. until there is a common cross platform escape sequence generator deal at least (IIRC there is one, but it either requires a newer python, and/or is a 3rd party module not a standard python one) so I probably should have included something like the 'color_dict' from gaudy_prompt, as an argument to to_color_string, with a default argument of a 'no_colors' dict, that way one could just implement to_string() as calling to_color_string, there are some issues in that the gaudy_prompt color dicts generate '\[ and \] as \001 and \002 escape sequences to inform readline about non-printing characters, these escape sequences get printed as junk since py print doesn't grok them. I suppose they should be replaced with classes (readline colors class subclassing a colors class) i'm fairly steadfast that just having random escape sequences embedded in pretty printers as i implemented it is entirely the wrong thing to do, and we need some level of indirection that can be set in .gdbinit that pretty printers can query it would probably be a good idea to settle on a declaration for a to_color_string method so it isn't done totally ad-hoc for each pretty-printer that wants to do so. I'll leave coming up with that declaration to someone actually implementing one that is not a silly example... FWIW running the pretty printers this way doesn't set the gdb numbered convenience variable, like print does. since the pretty printing API needs to remain compatible, please keep us in the loop :) [1] http://sourceware.org/gdb/current/onlinedocs/gdb/Writing-a-Pretty_002dPrinter.html#Writing-a-Pretty_002dPrinter --bcaec55556b0a4ef3504d3b9ca9d Content-Type: application/octet-stream; name="foo.py" Content-Disposition: attachment; filename="foo.py" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hc687vg40 Content-length: 1517 ZnJvbSBjdXJzZXMgaW1wb3J0ICoKCmRlZiBjb2xvcml6ZShzdHIsIGNvbG9y KToKICByZXR1cm4gdHBhcm0odGlnZXRzdHIoInNldGFmIiksIGNvbG9yKSAr IHN0ciArIHRpZ2V0c3RyKCJzZ3IwIikKCmNsYXNzIGZvb1ByaW50ZXI6CiAg IiIiUHJpbnQgYSBmb28gb2JqZWN0LiIiIgogICAgIAogIGRlZiBfX2luaXRf XyhzZWxmLCB2YWwpOgogICAgIHNlbGYudmFsID0gdmFsCiAgICAgCiAgZGVm IHRvX3N0cmluZyhzZWxmKToKICAgICByZXR1cm4gKCJhPTwiICsgc3RyKHNl bGYudmFsWyJhIl0pICsKICAgICAgICAgICAgICI+IGI9PCIgKyBzdHIoc2Vs Zi52YWxbImIiXSkgKyAiPiIpCgogIGRlZiB0b19jb2xvcl9zdHJpbmcoc2Vs Zik6CiAgICAgcmV0dXJuIChjb2xvcml6ZSgiYSIsIENPTE9SX1JFRCkgKyBj b2xvcml6ZSgiPSIsIENPTE9SX0JMVUUpICsgY29sb3JpemUoIjwiLCBDT0xP Ul9HUkVFTikgKyBzdHIoc2VsZi52YWxbImEiXSkgKwogICAgICAgICAgICAg Y29sb3JpemUoIj4iLCBDT0xPUl9HUkVFTikgKyAiYj08IiArIHN0cihzZWxm LnZhbFsiYiJdKSArICI+IikKICAgICAKY2xhc3MgYmFyUHJpbnRlcjoKICAi IiJQcmludCBhIGJhciBvYmplY3QuIiIiCiAgICAgCiAgZGVmIF9faW5pdF9f KHNlbGYsIHZhbCk6CiAgICAgc2VsZi52YWwgPSB2YWwKICAgICAKICBkZWYg dG9fc3RyaW5nKHNlbGYpOgogICAgIHJldHVybiAoIng9PCIgKyBzdHIoc2Vs Zi52YWxbIngiXSkgKwogICAgICAgICAgICAgICAgICAgICAiPiB5PTwiICsg c3RyKHNlbGYudmFsWyJ5Il0pICsgIj4iKQppbXBvcnQgZ2RiLnByaW50aW5n CiAgICAgCmRlZiBidWlsZF9wcmV0dHlfcHJpbnRlcigpOgogICBwcCA9IGdk Yi5wcmludGluZy5SZWdleHBDb2xsZWN0aW9uUHJldHR5UHJpbnRlcigibXlf bGlicmFyeSIpCiAgIHBwLmFkZF9wcmludGVyKCdmb28nLCAnXmZvbyQnLCBm b29QcmludGVyKQogICBwcC5hZGRfcHJpbnRlcignYmFyJywgJ15iYXIkJywg YmFyUHJpbnRlcikKICAgcmV0dXJuIHBwCgpnZGIucHJpbnRpbmcucmVnaXN0 ZXJfcHJldHR5X3ByaW50ZXIoZ2RiLmN1cnJlbnRfb2JqZmlsZSgpLGJ1aWxk X3ByZXR0eV9wcmludGVyKCkpCnNldHVwdGVybShOb25lLCAxKTsK --bcaec55556b0a4ef3504d3b9ca9d--