[BUG]UndefinedObject(Object)>>doesNotUnderstand: #<

Ned Konz ned at squeakland.org
Tue Feb 22 23:12:32 UTC 2005


On Tuesday 22 February 2005 1:10 pm, Michal wrote:
> For the record, I've had that happening too intermittently on a debian
> server. I have never been able to nail it down (or reproduce it
> consistently), but it looked like some previous UUID generator was
> locking up /dev/urandom. Simple 'cat'-ing /dev/urandom used to cure
> the situation, as did an ugly variety of workarounds...

I believe that what was happening may have been that the UTF-8 text converter 
attached to the stream may have been trying to interpret the bytes.

I just posted a fix for that possibility, but that may not have been the 
problem, on further consideration.

An aside:

Is it just me, or does anyone else think that the current way we open files 
that we're going to use as simple streams of bytes is a bit inefficient?

Right now, if someone just says 'readOnlyFileNamed:', this is what happens:

* get the full name from the given name
* convert the full name into a local name
* compare that with the local name for the sources file
* if the names are the same (that is, for any file named 'SqueakV3.sources') 
then set the converter to a new MacRomanTextConverter, otherwise set it to a 
new UTF8TextConverter.

But what happens if we just want a stream of uninterpreted bytes? Well, we 
have change the converter to a Latin1TextConverter, which does nothing to the 
incoming text, other than slow down the reading. So we go through the 
construction of a UTF8TextConverter, then throw it away.

Look at the time comparison between two ways of opening a file and reading 
1000 uninterpreted binary bytes:

Time millisecondsToRun: [ 1000 timesRepeat: [ | s | s := StandardFileStream 
readOnlyFileNamed: '/dev/zero'. s binary. s next: 1000. s close ] ] 
 => 119

Time millisecondsToRun: [ 1000 timesRepeat: [ | s | s := FileStream 
readOnlyFileNamed: '/dev/zero'. s converter: Latin1TextConverter new. s 
binary.  s next: 1000. s close ] ] 
 => 251

40% of the second example's time is spent doing the above comparison of local 
names with the sources file.

I'm curious as to why this comparison with the local name of the sources file 
is actually needed; don't we generally know how we're using a file, and so 
could just set the text converter to the proper one in the case of the 
sources file?

And it still seems to me that having 'binary' flavors of the file opening 
routines would help in the cases where we know that we're not dealing with 
text.

-- 
Ned Konz
http://bike-nomad.com/squeak/



More information about the Squeak-dev mailing list