Re: [Help-smalltalk] [RFC] handle paths in a saner way

[Mike Anderson]

Paolo Bonzini wrote:
> I started implementing the --kernel-directory and --image-directory
> options, but I got carried away and ended up reimplementing a lot of the
> startup sequence, and in particular the way kernel files are looked up.
>  This had interesting ramifications.
> 
> The changes can be summed up like this:
> 
> - the `~/.stinit' and `~/.stpre' files are now named `~/.st/init.st' and
> `~/.st/pre.st'
> 
> - files requested with the `-K' command-line option are sought for in
> the `~/.st' directory too
> 
> - kernel files may be overridden by placing them in `.st/kernel'; they
> will be used when you do `gst -i' but you cannot write to
> `/usr/local/share/smalltalk'
> 
> - a site-wide customization file can be placed in
> `/usr/local/share/smalltalk/site-pre.st'.  It will be loaded whenever
> users create images with `gst -i', before the snapshot and before the
> `~/.st/pre.st' file.

I don't create new images - I always copy the image file. Is that a bad
idea?

> - the kernel path is stored in the image when it's created; it's not
> changed when the image is loaded.  In addition, `Directory systemKernel'
> and `Directory localKernel' are not used anymore, and just return the
> same as `Directory kernel'.
> 
> - Smalltalk programs have access to the aforementioned `~/.st' directory
> as `Directory userKernel' (name subject to change).  A `packages.xml'
> file can be put in the directory too -- I like this a lot.

I'm not sure if I've said this before, but I'm greatly in favour of
having a search path for package files. The user (well, me, anyway) is
likely to have packages that fall into a number of categories. In
particular, packages that they have written themselves and unstable
versions of those packages.

For example, I have an applet on my desktop that shows a clock. This
requires a package which provides access to the Cairo library. If I am
developing another application that requires changes to that library, I
want that to use a different set of code so that the clock does not
crash. On the other hand, I don't want to duplicate the other standard
libraries I have written - if I upgrade them, I want all of my
applications to pick up the changes.

Also, why XML, when we don't even have an XML parser in the standard
libraries? (OK, I know I've said that before).

> Now, apart from scrutinizing the code (which I'll appreciate), I'm
> looking for:
> 
> - alternative names for `Directory userKernel', which is really `~/.st';
>  I thought of `Directory userRoot' but I don't really like it;
> 
> - if you don't like the semantics (details are in the manual, in the
> Startup Sequence node), suggestions on how to improve them;

I have read through this (I had never noticed it before!). It suggests
that the image is rebuilt if it is older than any of the kernel files. I
presume that doesn't happen if -I is given, but it doesn't say that.

Whilst kind of nice, I'm not too keen on the automatic building of the
image in the first place. I'd rather manually rebuild it when I change
the kernel source. Under what circumstances will you have a gst
executable but no valid image? Also, it takes time to check the kernel
files, no?

It's not clear what is done with .stpre, but I guess that "If the image
lies in the current directory, or if at least a kernel file was found
outside of the system default path, a user-dependant `.stpre'(1)" should
end with "is also loaded".

> - whether root (or any other user who can write to /usr/local/share)
> should be forbidden from having a ~/.st directory;

The implication is that the .stpre and .stinit of that user would be
built into the new image that is written to /usr/local/share? That
doesn't sound like a good idea, not least because #methodSourceString
will be broken. However, I don't think that that means they shouldn't be
able to have local packages in ~/.st.

> - whether `~/.st/init.st' makes sense at all; I'm inclined to remove it;

I don't think it makes sense.

Mike