[Vm-dev] Extending primitiveDirectoryEntry

Alistair Grant akgrant0710 at gmail.com
Mon Apr 24 14:26:35 UTC 2017


On Mon, Apr 24, 2017 at 04:03:42PM +0530, K K Subbu wrote:
> On Sunday 23 April 2017 10:26 PM, Alistair Grant wrote:
> >While I was profiling this I noticed that
> >DiskStore>>defaultWorkingDirectory is the most called method by a factor
> >of about 3, as it is called every time a filename is resolved.
> >
> >#defaultWorkingDirectory is relatively expensive as it calls a primitive
> >to get the image directory, converts the resulting ByteString to a byte
> >array, calls ZnCharacterEncoder to decode it, converts the string to a
> >path, and finally gets the parent.
> 
> Directory paths like these are really part of the host environment. Is there
> any need to reify them within an image?

Pharo uses the image directory as its current working directory.  If you
supply a relative path, it is resolved against the image directory.

I find this a bit unintuitive, I'd expect the defaultWorkingDirectory to
be the same as the parent process, e.g. the result of running pwd in a
shell.  But changing it now would probably break a lot of code.


> As long as we use only relative
> paths, then paths like VM, Plugin, Image, current directory etc. can be
> encoded using special prefixes (say "$vm" or "~vm" or "vm:") in persistent
> image variables and expanded into full paths by VM (through plugins) at run
> time using environment variables or command line options.

FileLocator provides access to all these locations.  I'm in two minds
about providing string substitution.


> The plugin can
> cache these nodes to improve performance.

This is part of what I'm looking at.

Cheers,
Alistair



More information about the Vm-dev mailing list