SAR

Stephen Pair spair at acm.org
Wed Nov 20 15:24:04 UTC 2002


Yes, I may not be the brightest person, but I do know they are zip files and
I know you want to put other stuff in there.

What I'm proposing is to generalize things a bit and make it so that the
file in mechanism gives you enough support that you can put a chunk of code
at the beginning of a zip file and then manipulate that zip file in whatever
way you want (i.e. load the change set and package members, copy images and
other files to a certain location, etc).  That would be entirely
complementary to the SAR conventions.

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of
> Andreas.Raab at gmx.de
> Sent: Wednesday, November 20, 2002 9:44 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: SAR
>
>
> Stephen,
>
> I think you are missing a critical point here - SAR files _are_ zip files
> following a certain convention. Just like .jar files. You might
> want to look at
> the Balloon3D.sar file (just download and rename it to Balloon3D.zip) and
> then you'll see that it contains besides code some other stuff (images and
> meshes) which are during installation loaded from the zip and
> installed into the
> Wonderland pool dictionary.
>
> So everything you are talking about is already present in SAR.
>
> Cheers,
>   - Andreas
>
> > I have not had any problems using WinZip with an archive that contains
> > Squeak code at the front of it.  So I don't think that physically having
> > something there will hurt anything.
> >
> > Perhaps the approach should be to change the Squeak file-in
> mechanism with
> > this capability in mind.  You could make it so that your
> file-in code has
> > access the relevant information without needing to do hacky things like
> > Craig had to do (ie. have "installer" variable bound to the installer,
> > give
> > access to the directory and file name that you're filing in,
> provide some
> > framework for making it simple to access the members of a zip
> file, etc).
> >
> > I think this would be very useful to have in conjunction with a SAR
> > specification for what a Squeak ARchive should actually contain (naming
> > conventions, etc).  But, it would also be generally useful if someone
> > needed/wanted to distribute something in a zip file that didn't have a
> > standard SAR layout.
> >
> > So, I'd say let's make the file-in mechanism a little more
> intelligent to
> > accomodate zip archives and that would benefit anyone wanting to
> > distribute
> > Squeak stuff in an easily loadable zip file.  BTW, I've often wanted to
> > access the file name in a file-in...so I think there are some other
> > benefits
> > to be had in the file-in process in general.
> >
> > - Stephen
> >
> > > -----Original Message-----
> > > From: squeak-dev-admin at lists.squeakfoundation.org
> > > [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Ned
> > > Konz
> > > Sent: Wednesday, November 20, 2002 2:18 AM
> > > To: squeak-dev at lists.squeakfoundation.org
> > > Subject: Re: SAR
> > >
> > >
> > > 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
> > >
> > >
> > >
> >
> >
>
> --
> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
> NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
>
>
>




More information about the Squeak-dev mailing list