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 _______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
