GNU bug report logs -
#30070
27.0.50; cl-print sometimes prints self-referencing objects as #1=#<thing>
Previous Next
To reply to this bug, email your comments to 30070 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30070
; Package
emacs
.
(Wed, 10 Jan 2018 19:40:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 10 Jan 2018 19:40:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
my use case is like this:
--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t -*-
(require 'cl-lib)
(require 'cl-print)
(cl-defstruct thing
thing-object)
(cl-defmethod cl-print-object ((_object thing) stream)
(princ "#<thing>" stream))
(let ((print-circle t))
(cl-prin1-to-string
(letrec ((me (make-thing :thing-object (lambda () me))))
me)))
--8<---------------cut here---------------end--------------->8---
That gives me "#1=#<thing>". That's weird because the printed
representation of the thing doesn't refer to itself. This can happen in
real life: that the thing-object in the example is a closure referencing
the thing itself might be coincidence, so one can't assume that the
printed representation of a self-referential object always includes a
reference to the top-level object.
TIA,
Michael.
In GNU Emacs 27.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2018-01-10 built on drachen
Repository revision: bf38966965384b07621839db892b90932b8754a6
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description: Debian GNU/Linux testing (buster)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30070
; Package
emacs
.
(Wed, 10 Jan 2018 20:37:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
> That gives me "#1=#<thing>". That's weird because the printed
> representation of the thing doesn't refer to itself.
Yes, it's a known misfeature (to me at least). I don't know how we
could fix it, tho: the cycle-detection is done in a preprocessing phase
which doesn't know about any print format (nor about cl-print), so by
the time we learn the the object will be printed as "#<thing>", we have
already printed "#1=".
To fix it, I have the impression that we'd have to make cl-print a lot
more complex, and potentially its API as well (e.g. add a matching
cl-preprocess method additionally to cl-print-object).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30070
; Package
emacs
.
(Thu, 11 Jan 2018 14:46:01 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
> > That gives me "#1=#<thing>". That's weird because the printed
> > representation of the thing doesn't refer to itself.
>
> Yes, it's a known misfeature (to me at least). I don't know how we
> could fix it, tho: the cycle-detection is done in a preprocessing phase
> which doesn't know about any print format (nor about cl-print), so by
> the time we learn the the object will be printed as "#<thing>", we have
> already printed "#1=".
>
> To fix it, I have the impression that we'd have to make cl-print a lot
> more complex, and potentially its API as well (e.g. add a matching
> cl-preprocess method additionally to cl-print-object).
Yes, that's what I expected.
Would it make sense to cache what is being printed, post-process it, and
print it at once?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30070
; Package
emacs
.
(Thu, 11 Jan 2018 15:11:02 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
> Would it make sense to cache what is being printed, post-process it, and
> print it at once?
We could try, but we'd have to somehow distinguish the "#N=" and "#N#"
that are used for such sharing references from those that may appear as
part of "normal user output".
Stefan
This bug report was last modified 7 years and 156 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.