linux installation & squeak.sh confusions

One of the interesting things that happens when you try to introduce someone new to Squeak is that you come up against all the habits you've built up about how to do stuff and how they don't necessarily match current reality.

In this case, I noticed that installing Squeak on a linux machine has some curious issues. To start with, we don't actually seem to have any advice on what to install where, which makes it hard to tell people to RTFM.

There are three plausible packages to install and each has a different shell script! The linux current 5.2b package squeak.sh is different to the all-in-one squeak.sh which is different to the version included in any locally built or grabbed from bintray package. Oh, and the version included in Raspbian is again different! We should probably try to improve that, wouldn't you say?

Once upon a time(long ago), the norm was for the .sources file to live where the vm executable did. I'd sorta-kinda noticed that it could also be in the same directory as the image too, but we seem to have drifted a bit from that earlier rule. The only install details mentioned on https://squeak.org/downloads/ actually specify only the 'same directory as image' part. This is not the best option for anyone wanting to keep images for different purposes spread in various directories. The code in SourceFileArray does actually look for a sources file in the vm path *but* with the unix approach of having date/time coded vm paths - not to mention the more general idea of the 'shared' assets directory - this isn't going to be that useful; '/usr/lib/squeak/5.0-201907192337' is ok until you update to 5.2-201908031yyyy'. Then again, anyone having several VMs in different places will have some fun if paths based on the vm location are relied upon!

I know that part of this is the result of the rather varied rules different unixes have for storing loaded applications. I don't know very much about those rules - and I really, really, don't want to have to care - so maybe somebody has ideas that might help have a decent shared location for the sources file that would fit? Could we just use vmPath/../ for 'normal' installs?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A conscience is what hurts when all your other parts feel so good.

Oh, and what about Windows? There are several files in addition to the image/changes - what is the best way to place them? Surely you don't just leave them sitting in the image directory?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Maybe Computer Science should be in the College of Theology

        On 01/08/19 4:08 AM, tim Rowledge wrote:
> I know that part of this is the result of the rather varied rules
> different unixes have for storing loaded applications. I don't know
> very much about those rules - and I really, really, don't want to
> have to care - so maybe somebody has ideas that might help have a
> decent shared location for the sources file that would fit? Could we
> just use vmPath/../ for 'normal' installs?

The *.sources is a read-only file, so it is first searched in VM path
where it is protected from accidental modifications and caters to the
case when the same VM is used to run images located in multiple
directories. It is part of the image, so it could also be placed in the
image directory if VM path is not writable (multi-user case). This will
get the beginners started quickly with minimum fuss.

For more advanced uses, we could change the image to look for an
override, say $SQUEAK_SOURCES, to override these hard-coded paths.

Or, we could place sources file in $HOME/.squeak/ and symlink it from
different image directories. This can be added to the launch script.

SQUEAK_SOURCES=....
IMAGE_DIR=...
VM_DIR=...

ensure_sources() {
test -f $VM_DIR/$1 || \
   test -f $IMAGE_DIR/$1 || \
   ln -s "$HOME/.squeak/$1" "$IMAGE_DIR/$1"
}

ensure_sources $SQUEAK_SOURCES

Regards .. Subbu

Yeah, I'm pretty familiar with the original rules about using the vmPath prim; I might even have been one of the original suggesters. Too long ago (like, 1996) to recall.

The practical problem with 'sources in the vmpath directory' for unix *these days* is that we  have an intermediate directory that we did not used to have. Thus the (probably) smarter heuristic would be  to use 'Smalltalk vmPath asFileDirectory containingDirectory ' as the path.

Of course, this is only appropriate for unix, and only if one decides to not make use of the fairly common unix idiom of putting stuff like that in one of the various 'shared' directory trees. /usr/share? /usr/local/share? Or maybe /var/squeak/share? *This* is the bit I don't know about; just enough to know it confuses me and seems to be somewhat variable around unixes.

Yes, one could use links to simplify, I guess. Again, rather unix specific unless Windows & Mac OS have started doing links properly. (In which case it is high time we added link handling stuff to FileDirectory etc!)


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SDR: Shift Disk Right