SBCL

Bug #309471
Comment #2

Comment 2 for bug 309471

Revision history for this message

kr (kr-u) wrote on 2016-01-24:

sbcl-1-3-1-format-indent-after-prompt-bug-patch Edit (1.0 KiB, text/plain)

i'll post the following both for bugs #439286 and #309471 , so
hopefully somebody will see it. i don't understand yet what the
implications are regarding duplicated bugs on launchpad.

i ran across this too, while investigating some other pretty-printing
bug having to do with indentation, which i will report at some other
point, later. even after my attempted fix, the first line looked
horribly confused, because of this bug here.

reply to YP:
> Yes, indeed (sb-kernel:charpos) returns 2.The question is - why?

after investigating this for a while (not having previously ever
looked at the stream implementation stuff), i concluded that this
basically reflects the change of the stream done by printing the
prompt in the toplevel repl. the default function bound by
SB-INT:*REPL-PROMPT-FUN* prints "* " , which is 2 characters.

there is a slot called output-column in the low-level fd-stream
structure that somehow gets updated during printing, and which
(sb-kernel:charpos) reads in some rather indirect way.

my proposed fix is to simply reset that slot to 0, after the prompt
was printed. maybe a bit of a hack, but it seems to work quite well.

here is the reported test case with my fix (i changed my sbcl version to 1.3.1.1) :

===========
This is SBCL 1.3.1.1, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (format t "~3tXXX~%~3tYYY~%")
XXX
YYY
NIL
*
===========

as one can see, a new side-effect of my fix is that there is no
extraneous newline being printed anymore, before the results are
printed. i think i prefer this in any event. it is also more similar
to franz allegro acl-9, which doesn't have the extra linefeed.

i'll attach a patch against sbcl-1.3.1 . with this, it rebuilds fine
and there does not seem to be any real change in the tests that are
run.

so, hopefully, now bugs #439286 and #309471 can be resolved.

i'll post the following both for bugs #439286 and #309471 , so
hopefully somebody will see it.  i don't understand yet what the
implications are regarding duplicated bugs on launchpad.

i ran across this too, while investigating some other pretty-printing
bug having to do with indentation, which i will report at some other
point, later.  even after my attempted fix, the first line looked
horribly confused, because of this bug here.

reply to YP:
> Yes, indeed (sb-kernel:charpos) returns 2.The question is - why?

after investigating this for a while (not having previously ever
looked at the stream implementation stuff), i concluded that this
basically reflects the change of the stream done by printing the
prompt in the toplevel repl.  the default function bound by
SB-INT:*REPL-PROMPT-FUN* prints "* " , which is 2 characters.

there is a slot called output-column in the low-level fd-stream
structure that somehow gets updated during printing, and which
(sb-kernel:charpos) reads in some rather indirect way.

my proposed fix is to simply reset that slot to 0, after the prompt
was printed.  maybe a bit of a hack, but it seems to work quite well.

here is the reported test case with my fix (i changed my sbcl version to 1.3.1.1) :

===========
This is SBCL 1.3.1.1, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (format t "~3tXXX~%~3tYYY~%")
   XXX
   YYY
NIL
* 
===========

as one can see, a new side-effect of my fix is that there is no
extraneous newline being printed anymore, before the results are
printed.  i think i prefer this in any event.  it is also more similar
to franz allegro acl-9, which doesn't have the extra linefeed.

i'll attach a patch against sbcl-1.3.1 .  with this, it rebuilds fine
and there does not seem to be any real change in the tests that are
run.

so, hopefully, now bugs #439286 and #309471 can be resolved.