[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