[squeak-dev] Re: Squeak 4.4 Question

David T. Lewis lewis at mail.msen.com
Thu Jan 17 00:40:42 UTC 2013


On Wed, Jan 16, 2013 at 03:59:55PM -0800, tim Rowledge wrote:
> 
> On 16-01-2013, at 2:17 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> > 
> > But I'm tired of arguing. Please propose a means that I can, with an
> > absolute minimum of effort find the sources file corresponding to a
> > given Squeak version, both for 4.4 and for arbitrary versions in the
> > future.
> > 
> > I repeat: _all I want_ is a _simple_ correspondence between a released
> > Squeak and the source file that it needs. One that a shell script can
> > calculate. One that doesn't involve scraping links off a web page.
> 
> 
> My suggestion, for what it's worth - 
> a) forget naming the individual files by version/update level etc (for releases  - for ongoing work when updates are being loaded it makes some sense)
> b) name the *directories*

I think that naming the directories does make good sense.

In the case of an image file, it is handy to be able to look at the file
name to know where it comes from. But the first thing I ever do with any
new release image is open it and resave it as squeak.image. Later on I
will resave it as squeak.1.image and squeak.2.image and so on, so if the
release image was just called squeak.image and if it was distributed
in a directory that identified the release version, that would work fine
for me.

> c) document that users should keep the image/changes files for release numpty-ump in a directory separate to their files for release diddly-squat.

+1

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

> e) for release filesets stored on squeak.org I'd suggest a directory for the release, subdirectories for each platform with the files set out however it suits the platform, another pseudo-platform with the bare sources/image/changelog/readme and quite possibly links from within the platform subtrees back to those 'originals'. 
> f) in cases where the same file is used in several releases - such as the .sources, obviously - use a link if possible so it really is the same file.
> 
> Proffered pseudo-tree on squeak.org
> release_wibble/
>   rawfiles/
>      release_wibble-2768.image
>      release_wibble-2768.changes
>      release_wibble-2768.sources
>   RISC_OS/
>     squeak.image (linked to ../rawfiles/release_wibble-2768.image)
>     etc
>     !Squeak/
>       !RunImage
>       sources (linked to ../../rawfiles/release_wibble-2768.sources)
>       plugins/
>         etc
>       etc
>     squeak.changes
> release_duckfart/
>   rawfiles/
>      release_duckfart-6502.image
>      release_duckfart-6502.changes
>      release_duckfart-6502.sources (linked to ../../release_wibble/release_wibble-2768.sources)
>   RISC_OS/
>     squeak.image (linked to ../rawfiles/release_duckfart-6502.image)
>     etc
>     !Squeak/
>       !RunImage
>       sources (linked to ../../rawfiles/release_duckfart-6502.sources)
>       plugins/
>         etc
>       etc
>     squeak.changes
> 
> Yes, if you dump the image and changes in the same directory as a previous pair you might have a problem with overwriting them. But since you really ought to be saving the 'virgin' files somewhere safe, starting up the new image and immediately saving it under a meaningful name in a working directory, that shouldn't happen.
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> .signature not found!  reformat hard drive? [Yn]
> 
> 


More information about the Squeak-dev mailing list