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

[Matthew Fulmer]

On Mon, Feb 09, 2009 at 06:16:26PM +0100, Bert Freudenberg wrote:
> 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?

Yes. Before, the source code for every single method in the
update stream was stored in the history image:

MethodHistoryChangeRecord allInstances size -> 158547

Now, I changed MethodHistoryChangeRecord to use a (closed)
FileStream instance and pointer, as its superclass ChangeRecord
already does.

This worked great and reduced the image size from 93MB to 35MB,
and stoped it from segfaulting on my XO due to running out of
memory.

The only issue is that the FileStream instances had absolute
path names, like so:

MultiByteFileStream: '/home/tapple/celery/squeak/3.11/squeak4/history/Squeak39g-7056+3102-7179.changes'

These FileStreams don't work on another computer. Thus, I evilly
hacked the database generator to store relative file names in
the FileStreams in the MethodHistoryChangeRecords, which allows
the history image to both run and work correctly on computers
with not a lot of memory.

Given that this image and the MethodAuthorship package are only
useful for the next month, while we relicense squeak, and not
thereafter, I think the hackery is justifiable.

> > 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.

You're right. it's not. It's probably not it's business to know
its filename or how to reopen on startup either, but that's
another discussion.

> > 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  one.

Thanks for the clarification. I'll use FileStreams properly from
now on.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/