3.6 "full" packages

Daniel Vainsencher danielv at netvision.net.il
Tue Jul 29 11:38:09 UTC 2003


I've been thinking about this some more, and I think SAR could be a good
basis for a lot of cool installation magic, if we can replace preambles
with conventions.

For example, any SAR created from a PackageInfo could include a member
at a standard position that contains the package name. If this member is
contained, then the following can be applied

> - The DVS tools know how to load a .st file. They do this knowing that 
> they're working with a particular package. So they can delete 
> methods, classes, etc. as needed.
And -
> You do get the package 
> registered if you have DVS because of the line at the end that does 
> (the equivalent of):
> 	FilePackageManager registerPackageNamed: 'Whatever'.
I note that the latter doesn't require DVSs' FPM, PackageInfo does this.
As Avi noted in another thread, MC isn't the only tool that uses PIs -
packages and extension related to them should be registered with PI.

And generally, this separates the format question (mc/sif/.st) from the
issue of tracking what packages are loaded. If all package loaded are
properly registered this also gives us a basis for allowing users to
browse installed packages and remove them.

Daniel

Ned Konz <ned at bike-nomad.com> wrote:
> On Monday 28 July 2003 11:59 am, goran.krampe at bluefish.se wrote:
> > Ned Konz <ned at bike-nomad.com> wrote:
> > > On Monday 28 July 2003 10:43 am, goran.krampe at bluefish.se wrote:
> > > > If I understand this correctly Monticello has it's own format
> > > > that can not be loaded without Monticello being installed
> > > > (sounds fair)
> > >
> > > Though we could make a stub that would do a reasonable job of it.
> >
> > But that would still require SAR support... :-) Old Squeaks are
> > still out of luck.
> 
> But they can load the .st files exported by Monticello now.
> 
> Or for a truly bizarre experience you could output the SAR with a 
> prepended .st chunk that would load the SARInstaller from a server 
> somewhere.
> 
> > > > and can also export a package in simple .st format - but such a
> > > > file can only be filed in normally without any of the nice
> > > > Monticello functions, unlike DVS which could do "intelligent"
> > > > installation of a .st file. Right?
> > >
> > > No, we could (and should!) load those .st files in the same way
> > > as DVS. However, we should
> >
> > Ok, so this functionality is simply missing from the current
> > Monticello?
> 
> There are some differences that I can see:
> 
> - The DVS tools know how to load a .st file. They do this knowing that 
> they're working with a particular package. So they can delete 
> methods, classes, etc. as needed.
> 
> - The FileList doesn't do anything special with DVS files, since 
> they're using the .st extension and we don't have a "file in as DVS" 
> choice in the File List. So if you do a normal file-in of a DVS file 
> you don't get the deletions happening. You do get the package 
> registered if you have DVS because of the line at the end that does 
> (the equivalent of):
> 
> 	FilePackageManager registerPackageNamed: 'Whatever'.
> 
> There probably should be a bit of a preamble in these files that makes 
> sure you use DVS to load such files if you have it, instead of the 
> FileList, so you don't risk making a mess of an existing package.
> 
> - The Monticello tools don't add such a registration line to the end 
> of their .st file-out format, and they should.
> 
> - The Monticello tools don't import .st files. They want to use their 
> own formats (.mc and .mcv).
> 
> - With DVS going away, it would make sense to have some kind of safety 
> on the .st output of Monticello so that it would do more or less the 
> right thing if you happened to load the .st file into an image that 
> had Monticello installed, whether or not that package already 
> existed. This could be done with a little conditional preamble:
> 
> Smalltalk at: #MCPackage ifPresent: [ :mcPackage | mcPackage 
> prepareToLoad: 'MyPackageName' ].
> 
> which could (worst case) blow away any pre-existing contents of the 
> package before filing in the new stuff. But this is potentially 
> dangerous when you have extension methods that are actually 
> recategorized versions of pre-existing methods.
> 
> But this wouldn't work as well as just using the Monticello formats.
> 
> > > > First of all - is it really that important to be able to
> > > > install a package in an old Squeak? If you want to cater to old
> > > > Squeaks - why not simply offer a .st fileout too? An old Squeak
> > > > wouldn't know how to do an intelligent upgrade of an installed
> > > > package anyway.
> 
> I think this may be the simplest choice for backwards compatibility.
> 
> > > I think my stub idea is the best. Rather than loading another
> > > package
> >
> > Well, I was actually talking about adding support in SM for .mcv.
> >
> > > into the image, make it the responsibility of the distributor to
> > > ensure loadability (using SARBuilder would be the easy way; I
> > > have to update it too).
> >
> > Using SAR with such a stub still can't cater to old Squeaks.
> 
> True. Maybe the "dual format" is the best idea. Plus there may well be 
> other changes required for older Squeaks.
> 
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE



More information about the Squeak-dev mailing list