[climacs-devel] Case missing from class regexp's print-object method
Derek Peschel
dpeschel at eskimo.com
Sun Aug 28 22:14:50 UTC 2005
On Sun, Aug 28, 2005 at 12:03:18PM -0700, Aleksandar Bakic wrote:
> Surprise! We are talking about string-regexp, where both "{nilkind}" and
> "#<...>" are parsable. It's in regexp-automaton that the latter may not be
> accepted.
You're right. Wow, I was sure the code would reject a letter after
a brace. But it does parse it. Inside a character class it definitely
parses it since braces aren't special there.
> BTW, with the currenct code, in SBCL debugger's backtrace you get:
>
> 1: (AUTOMATON::CHECK #<error printing object>)
> 2: (AUTOMATON::PARSE-COMPLEMENT-EXP #<error printing object>)
> 3: (AUTOMATON::PARSE-REPEAT-EXP #<error printing object>)
> 4: (AUTOMATON::PARSE-CONCATENATION-EXP #<error printing object>)
> 5: (AUTOMATON::PARSE-INTERSECTION-EXP #<error printing object>)
> 6: (AUTOMATON::PARSE-UNION-EXP #<error printing object>)
>
> which seems fine to me.
By "current" do you mean without the patch?
Without the patch, I get the "#<error printing object>" sometimes, but when
calling a traced function I get a debugger prompt. Then I ask to print
the local variables, the debugger tries to print the object again,
and I get a second debugger prompt. Very frustrating. I wouldn't say
that seems fine. If this makes any difference, I loaded regexp.lisp after
(declaim (optimize (debug 3) (safety 3) (speed 0)))
With the patch and the optimize settings above, the trace logs don't enter
the debugger. I assume the "#<error printing object>" printouts go away too
but I haven't checked.
-- Derek
More information about the climacs-devel
mailing list