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