From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.bugs Subject: bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug) Date: Sat, 31 Dec 2016 10:56:44 -0800 Message-ID: <87d1g8apw3.fsf@ericabrahamsen.net> References: <87pokampa4.fsf@ericabrahamsen.net> <8760m2mmlq.fsf@ericabrahamsen.net> <87bmvu84lj.fsf@users.sourceforge.net> <01696DFE-7C0E-4FAC-8893-B6826DF7BCA8@ericabrahamsen.net> <87y3yw7inw.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1483210635 20225 195.159.176.226 (31 Dec 2016 18:57:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 18:57:15 +0000 (UTC) User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/26.0.50 (gnu/linux) Cc: 25295@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 31 19:57:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNOq6-0004Sw-Dj for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 19:57:10 +0100 Original-Received: from localhost ([::1]:45142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNOqB-0002Vb-9R for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 13:57:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNOq4-0002VW-9p for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:57:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNOpy-0001Zr-9D for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:57:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46310) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNOpy-0001Zb-5z for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNOpx-0002h5-Ku for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eric Abrahamsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Dec 2016 18:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25295 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25295-submit@debbugs.gnu.org id=B25295.148321061010338 (code B ref 25295); Sat, 31 Dec 2016 18:57:01 +0000 Original-Received: (at 25295) by debbugs.gnu.org; 31 Dec 2016 18:56:50 +0000 Original-Received: from localhost ([127.0.0.1]:33476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNOpl-0002gg-VF for submit@debbugs.gnu.org; Sat, 31 Dec 2016 13:56:50 -0500 Original-Received: from mail.ericabrahamsen.net ([50.56.99.223]:41254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNOpk-0002gY-Ii for 25295@debbugs.gnu.org; Sat, 31 Dec 2016 13:56:48 -0500 Original-Received: from localhost (71-212-13-2.tukw.qwest.net [71.212.13.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 865DDBC903; Sat, 31 Dec 2016 18:56:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.ericabrahamsen.net; s=mail; t=1483210606; bh=wNfv5LBvo4q7SpmzeaHrpEB64MTMTbFU3GEpR7mvFbI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=tM9aEJ9EgDNifvt1OSDcunep1lUulpE4RZXuj8Hi29RTAv9HURuD6QAHCfsQXASe8 aX9xL/7hQoLOJegj1JDuZ9KisMBOn1K9cI9Jyq66qF+XaGrQDWUdl60wnfnqz2N1QS O9M1i8F9URP7huATxGI2Dqh6snHnWF5PSojbSJBs= In-Reply-To: <87y3yw7inw.fsf@users.sourceforge.net> (npostavs's message of "Sat, 31 Dec 2016 00:48:51 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127643 Archived-At: On 12/31/16 00:48 AM, npostavs@users.sourceforge.net wrote: > Eric Abrahamsen writes: [...] >> I don't see how we could hijack at the lisp level, though. Functions >> like `eval-expression' and `backtrace--print-frame' simply toss whole >> lisp structures to prin1, there's no way to know that there's an eieio >> object somewhere in that structure. >> > > I think the only way to integrate `object-print' with the existing > `print' functions, would be to make it follow the same protocol. That > is, currently `object-print' is really `object-to-string', it should be > changed (or perhaps a new function (e.g., `print-object') would be a > better idea, so as not to break existing code too much) to accept a > PRINTCHARFUN argument, and print to it. The problem is that pretty much all of the printing happens at the C level. Whole lisp structures are sent directly to C, and it's the C code that recurses through them and decides how to print everything it finds inside. Lisp code never gets a chance (except in a few very specific situations). For example: when an error is raised, `backtrace--print-frame' gets all the contents of the error as a single argument. It simply punts that to `prin1', and then it's done. There's no chance to pick apart that single argument and see if there is an object inside. `eval-expression' essentially does the same thing. >> Personally, I'd be willing to lose the ability to customize object >> representations with `object-print', if it meant that print_object could >> produce a #> C test like INSTANCEP or what have you. >> > > That's easier, of course, but a non-customized representation would be > pretty uninformative. Having looked at the code, I'm not too optimistic about achieving the ideal solution. Getting eval-expression and backtraces to stop exploding seems like enough for now.