This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: *print-right-margin* ineffective for write


On 11/30/2011 03:43 PM, Charles Turner wrote:
On 30/11/11 22:49, Charles Turner wrote:
On 30/11/11 20:13, Taylor Venable wrote:
Hi there. I've hit what looks like it might be a problem with
*print-right-margin* and display vs write.

Yep, that's definitely a problem. For reasons currently unknown to me.
The reasons are now clear :-). What's happening is that instead of
starting a list print calling PrettyWriter#startLogicalBlock, WRITE
starts with PrettyWriter#writePositionMarker. This is an SRFI-38
specific thing, which DISPLAY is oblivious to.
PrettyWriter#writePositionMarker wasn't checking the new printing
environment, so when that check occurred in startLogicalBlock, there was
already a QITEM_POSNMARKER in the queue (due to writePositionMarker
being called first), hence the invariant was broken.

A solution is to factor the <check printing environment> stuff out of
startLogicalBlock and call it from writePositionMarker.

That only works when printSharing is true.


Perhaps a better place for the test might be enqueue.

However, I suspect an even better place at the start of each write/display call
(with a check that queueSize == 0 && bufferFillPointer == 0).


In general we should have a set of actions that we perform at the start
and end of 'top-level" calls to write/display.  Not just checking fluid
parameters, but also the initializing and clearing the ID hash for sharing,
for example.

(At list in Common Lisp you might have nested calls to write, and you
probably don't want these start/finish actions in those cases.)

This isn't very
efficient, since writePosnMarker is called a *lot* for large lists, and
most of the time the check is an unnecessary burden on the call stack.

Checking queueSize == 0 && bufferFillPointer == 0 isn't very expensive,
and we should only do the fluid lookups when that condition is true. I think.
--
--Per Bothner
per@bothner.com http://per.bothner.com/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]