SAR

Ned Konz ned at bike-nomad.com
Wed Nov 20 07:17:30 UTC 2002


On Tuesday 19 November 2002 09:50 pm, Craig Latta wrote:

> > You know, I started out having SARs [be completely
> > self-contained].
> >
> > But then I was discouraged by some discussion on the list by
> > people who thought that wasn't an important feature.
>
> 	Wow, I missed that one... I find that feature to be extremely
> useful.
>
> 	I'm just curious... did this discussion take place before or after
> 12 August, when I released/announced my self-installing thingie?
> And when did you start developing SAR?

The discussion was after that time (around a month ago), because your 
installer was mentioned and I looked at it (after I'd come up with 
something similar on my own, unfortunately).

http://aspn.activestate.com/ASPN/Mail/Message/1404843

It looks like you were part of the discussion <g>...

> > Part of the problem, of course, is that you have to do something
> > like Craig did to actually find the zip stream (he went up the
> > caller stack...).
>
> 	What's the problem?

No huge problem; it is sensitive to the fact that the stream itself is 
doing the fileIn (which is the case in Squeak so far but could 
change).

But there are some complications:

I'd like these to be valid Zip files (i.e. with correct member offsets 
in the central directory) so we can use the usual zip tools for 
validation and checking on them. So just sticking a stub on the front 
of an existing zip file won't cut it.

There aren't any interactive tools for writing valid zips with 
prepended data that I know of, other than my ArchiveViewer. And the 
ArchiveViewer can only prepend data from a file, so I'd like to have 
a fixed stub to ease creating these things by hand.

Another reason for a fixed stub is to make the actual mechanics of 
extraction visible to standard (non-Squeak) tools. The SAR format 
puts everything into files, which lets you use any zip tool that you 
want to construct them.

With a fixed stub, the extraction of individual members wouldn't be in 
the stub, it'd be in the preamble and postscript as it is now with 
SARs.

And I'd like to be able to install these SARs both by file-in and by 
the SARInstaller (which also can handle change-set renaming, 
registration with DVS, etc.). So I'd like the stub to be responsible 
for filing in the preamble and postscript, but these expect to have 
"self" set to an installer. Which doesn't work with the stock 
PositionableStream>>fileInAnnouncing: because self is set to nil. So 
I'd have to load some methods to allow this, which I'd then have to 
delete from the current change set. These methods could be in a 
compressed member that's loaded first by the stub, though.

> > ...the code to do the installs would have to be added to each
> > SAR, and can't be compressed itself (it has to be vanilla
> > Smalltalk code).
>
> 	Is it big enough to matter?

It might be in excess of 500 bytes. I'd have to play with it a bit to 
see.

> > However, since most SARs will be appearing in SqueakMap, it seems
> > like we should probably just install the SARInstaller stuff (it's
> > small, anyway) along with SqueakMap.
>
> 	I still like the idea of having an installer that's completely
> self-contained (or rather, it only depends on parts of the system
> which are decades old :).

I didn't write the Zip stuff until Feb 2001, apparently. Though it 
seems that I did it earlier; I'm not sure. The GZip stuff only dates 
back to late 1998, as far as I can tell.

The idea is still appealing; I may still add it to the SARBuilder 
package. But I'm not sure that it's worth the effort.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE




More information about the Squeak-dev mailing list