Method history - deep thinking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Method history - deep thinking

rush
When I select method history in almost virgin image, it causes some very
deep never returning thinking.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/


Reply | Threaded
Open this post in threaded view
|

Re: Method history - deep thinking

Ian Bartholomew-20
rush,

> When I select method history in almost virgin image, it causes some very
> deep never returning thinking.


Thanks Rush.  I hadn't noticed it before as it only happens when the change
log is less than 8192 bytes long.As I don't normally compress sources  (the
only real way to get a change log that small) I hadn't spotted the problem.

It's caused by a strange condition in the change logs FileStream where the
streams readLimit becomes 2 bytes larger than its logicalFileSize.  This
makes it impossible to read to the end of the stream, although it keeps
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).

Anyway, I've added a patch to the latest version of the goodie so that it
that works around the problem.

Ian


Reply | Threaded
Open this post in threaded view
|

Re: Method history - deep thinking

Ian Bartholomew-20
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


Reply | Threaded
Open this post in threaded view
|

Re: Method history - deep thinking

Ian Bartholomew-20
Ooops, forgot to append the workspace demo (lack of sleep I expect).
Evaluate the following in a workspace and you willl need Ctrl-Break to get
out of the loop

fs := FileStream readWrite: 'test.txt'.
fs nextPutAll: 'hello'; cr.
fs flush.
fs cr.
fs reset.
[fs atEnd] whileFalse: [fs nextAvailable: 1000]

Ian