[Pkg] Squeak3.11 Contributions: MethodAuthorship-mtf.19.mcz

Bert Freudenberg bert at freudenbergs.de
Mon Feb 9 17:16:26 UTC 2009

On 09.02.2009, at 18:01, Matthew Fulmer wrote:

> On Mon, Feb 09, 2009 at 01:20:37PM +0100, Bert Freudenberg wrote:
>> Hi Matthew,
>>> + ----- Method: FileDirectory>>relativeReadOnlyFileNamed: (in
>>> category '*methodauthorship') -----
>>> + relativeReadOnlyFileNamed: aFileName
>>> + 	
>>> + 	| path |
>>> + 	(self pathName beginsWith: FileDirectory default pathName)
>>> + 		ifFalse: [^ self readOnlyFileNamed: aFileName].
>>> + 	path := (self fullPathFor: aFileName) allButFirst: (FileDirectory
>>> default pathName size + 1).
>>> + 	^ FileStream concreteStream new open: path forWrite: false!
>> may I ask what's the purpose of this file logic mangling? It assumes
>> that "FileDirectory default" is the same as the VM's idea of a  
>> current
>> working directory, if I understand correctly. This may work on some
>> platforms, but not in general. FilePlugin's primitiveFileOpen expects
>> an absolute path.
> The idea is to get the source code for the method versions out
> of the image, and store RemoteStrings instead, saving 60MB of
> image space, and letting me work on the relicense on my XO.
> However, FileStreams have an obsession with converting the path
> to an absolute path about 5 times before it ever reaches the
> FileStream. Thus, an image with naive use of FileStream is
> littered with absolute path names which bind to non-existent
> files when the image is resumed on a different machine.

So you have tons of FileStreams open at the same time? Say you have  
1000 files open and the common path is 100 characters long that would  
save 100 KB. Are you sure this problem is severe enough to warrant  
such evil hacks?

> If the plugin expects an absolute path, I'd say FileStream
> should store a relative path, and only convert it to absolute
> path only in StandardFileStream >> open:forWrite:

I'd say it's not a FileStream instance's business to know about  
default directories.

> This would probably save a lot of startup logic for files that
> are always in a place relative to the image.

This assumes the default directory is the same as the image directory,  
which is not always the case. It also assumes the VM's cwd is the same  
as the default directory, which is usually not the case (unless you  
run squeak from the command line).

> Also, I FileDirectory default is the current directory as far as
> file opening is concerned (see FileStream class >> fullName:)

Not sure what you mean here. "Current directory" and "default  
directory" are distinct ideas. There is no default mapping from  
current directory to default directory unless you explicitly provide  

- Bert -

More information about the Packages mailing list