|
I writted ...
> trying, and results in a never ending loop. I can't replicate the problem
> outside of the change log ReadStream so I guess it's just "one of those
> things" (if Andy or Blair want to have a look at it then let me know).
Thinking about this kept me awake last night (yawn) so I got up early to try
and track it down.
It turns out that the problem only arises when the change log is less than
8192 bytes long and last item is a chunk emitted by the
SourceManager>>logComment:to: method (obscure or what!). At this point the
streams #lastPosition is two bytes greater than it's #logicalFileSize and it
causes an infinite loop when I attempt to reset/read the change log.
The root cause seems to be in the SourceManager>>logComment:to: method. I
don't know if it can be considered a bug but it's an easy fix to make in the
default image so I'm hoping OA will look kindly on it :-).
Currently SourceManager>>logComment:to: method. contains ...
aSourceFiler emitComment: TimeStamp current displayString, ': ', aString;
cr
the #emitComment: method outputs the string to the change log and then
flushes it. The above _then_ appends another cr to the end of the flushed
stream.
If it was changed to ...
aSourceFiler emitComment: TimeStamp current displayString , ': ' , aString
, String lineDelimiter
... then the extra cr will be flushed along with the rest of the stream and
my problem with reading the change log will disappear.
Ian
|