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@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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Fractured Idiom:- ALOHA OY - Love; greetings; farewell; from such a pain you should never know