I decided to take a look at the Browser>findMethod improvements Jon H.
provided a while ago. How often does one suffer a 'Space is low' when
filing in a small changeset?

Select the .gz file (BetterFindMethod-jon.3.cs.gz) and hit the filein
button....

The #displayProgress... asks the incoming stream for a name to use. This
is fine for a FileStream since it has a sensible name. Usually
reasonably short. Unfortunately a ReadStream provides its #printString
as a name. Dumbness number 1. So now we have a DisplayText being built
with the entire changeset contents.

Somehow this DisplayText, via the TextMorph used to create it, ends up
with a boundingBox of, wait for it, 2359 at 2042 !  Thus when a Form is
built it is 4817078 words in length. Now maybe on a machine with
virtual memory this is an acceptable thing to do - though it will waste
plenty of time at it I think - but really. Dumbness number 2.

As it happens, my machine set is just able to supply the bitmap but
later in the process the affected area of the screen is saved with a
'Form fromDisplay:' and making another 20Mb bitmap is too much to ask.
Dumbness number 3 - why is the progress bar still working by direct
blatting on Display?

Clearly something very odd is happening since 'view decompressed' on
the same file works perfectly - ie displaying the self-same text.
Selecting the text and using 'file it in' works, with the progress bar
showing 'Filing in from a Stream' rather than attempting the nonsense
above.

Jon's change works nicely though...

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Fractured Idiom:- ALOHA OY - Love; greetings; farewell; from such a pain you should never know