From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Enhancement suggestion: prin1 extension mechanism Date: Fri, 12 Sep 2008 22:22:59 -0400 Message-ID: References: <200809110325.m8B3PYFE031034@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1221272594 19224 80.91.229.12 (13 Sep 2008 02:23:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Sep 2008 02:23:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Eric M. Ludlam" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 13 04:24:10 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KeKny-0005JL-5s for ged-emacs-devel@m.gmane.org; Sat, 13 Sep 2008 04:24:10 +0200 Original-Received: from localhost ([127.0.0.1]:38800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KeKmx-0006as-Da for ged-emacs-devel@m.gmane.org; Fri, 12 Sep 2008 22:23:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KeKmt-0006aW-3Y for emacs-devel@gnu.org; Fri, 12 Sep 2008 22:23:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KeKmq-0006aK-Jw for emacs-devel@gnu.org; Fri, 12 Sep 2008 22:23:01 -0400 Original-Received: from [199.232.76.173] (port=35982 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KeKmq-0006aH-ED for emacs-devel@gnu.org; Fri, 12 Sep 2008 22:23:00 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:55414) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KeKmq-0000gs-4W for emacs-devel@gnu.org; Fri, 12 Sep 2008 22:23:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEAGzAykhFxIqP/2dsb2JhbACBY7QggWSBBg X-IronPort-AV: E=Sophos;i="4.32,392,1217822400"; d="scan'208";a="26758714" Original-Received: from 69-196-138-143.dsl.teksavvy.com (HELO ceviche.home) ([69.196.138.143]) by ironport2-out.teksavvy.com with ESMTP; 12 Sep 2008 22:22:59 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 04B79B40CD; Fri, 12 Sep 2008 22:23:00 -0400 (EDT) In-Reply-To: <200809110325.m8B3PYFE031034@projectile.siege-engine.com> (Eric M. Ludlam's message of "Wed, 10 Sep 2008 23:25:34 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103864 Archived-At: > I've used some hacks to override edebug's prin1 to replace these > objects with syntax like #, or > # where the actual printed representation from > prin1 might take a minute or so to generate. (Or, at least, longer > than I've been willing to wait during a debug session tonight.) > Fortunately, M-: prints a short form with large parts replaced with > "..." There are 2 issues: - the time to print the object - the size and shape of the output The first problem is probably a reflection of the naive way we handle cycles (i.e. by scanning a singly-linked-list of already seen objects): if someone were to fix this code to use a hash-table rather than a list, the minute would probably come down to an acceptable time. There are already some places where we disable print-circle to avoid this slowdown (but in your case, it's not an option since you data is circular). Of course, you may still want to have an ad-hoc output that hides the internal representation, even if the internal representation can be printed in an acceptable amount of time. Maybe we should introduce a notion of "object" (in the OO sense) in Emacs's internal representation, so EIEIO (and CL's defstruct) could then provide its own printer code. The simplest way to do that might be to simply introduce a new array type called `object', which would work just like array, except that when it's printed, it's passed through (run-hook-with-args-until-success 'object-print-functions obj), so EIEIO and CL could hook into object-print-functions. Or we could even stuff a "class ID" small integer inside the array's size info, so we could lookup an object-printer-table. Stefan