On Wed, Jan 16, 2013 at 06:45:13PM -0800, tim Rowledge wrote:
> 
> On 16-01-2013, at 4:40 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
> >> d) the best places to keep the VM and .sources file varies by platform. For OS X it could well make sense to keep it in VM bundle, though that might end up with a copy in each version of a VM during development. Disc is cheap, so is it really a problem? For RISC OS I've *always* kept the sources file inside the VM application folder (which is essentially what Apple copied the bundle idea from), For Windows and unices I have no idea what is best because I simply don't use them anymore. Would it make sense to put a suitable link in each release's directory, pointing back to a real file? Links are supposed to work, aren't they?
> > 
> > It would make sense, but unfortunately I don't think that links necessarily
> > work on all file systems. Most notably, memory sticks are often formatted
> > with lowest common denominator file systems (VFAT) that do not support
> > links. So it is not a good idea to rely on this.
> 
> 
> That's an interesting point; I didn't know that FAT couldn't do links. Do links work within a zip or other archive format? If so, at least they're transmittable in some reasonably convenient fashion.
> 

I think some versions of zip can handle symbolic links, but I don't know
if it is portable.

> For unices I guess it makes sense to have the vm in some shared place, the sources file probably ditto, and image/changes pairs in user directories. That presumably implies an install script as part of the download, which would makes links as well. How does it cope with having more than one version installed, possibly requiring several different VMs and/or sources files?
> 

Yes, the unix VM is provided either in the form of an install script
(http://squeakvm.org/unix/release/Squeak-4.10.2.2614-linux_x86_64.sh) or
as a tar archive that has the necessary directory structure.

The VM runs from a shell script (e.g. /usr/local/bin/squeak) and that
script locates the subdirectory that contains the VM, plugins, etc.
These subdirectories are named based on version (VMMaker version and
SVN source version), and also based on whether the VM is for 32-bit or
64-bit images (the /usr/local/bin/squeak script figures that out too).

I think this is pretty much in line with the directory based naming
convention that you suggest. Among other things, this scheme makes
it very easy to go back to another version of the VM (just change the
script) or to install both Cog and interpreter VM on the same machine
(I personally keep separate /usr/local/bin/cog and /usr/local/bin/squeak
scripts but that's just my own personal convention).

The only down side is that an untidy person like myself can end up
wasting a lot of disk space.

Dave 


> Many years ago I used to have the old Archimedes Smalltalk stuff save the image/changes within application directories so that it was hard work to separate them. So, saving your image as 'fred' would create a !fred directory and copy the changes into !fred.changes and save the image as !fred.image. Remembering of course that RISC OS uses '.' as the directory separator.
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Resistance is useless!  (If << 1 ohm)
> 
>