[squeak-dev] binary development (was: 3.11 and the trunk)

Eliot Miranda eliot.miranda at gmail.com
Tue Aug 25 04:37:24 UTC 2009


On Mon, Aug 24, 2009 at 7:48 PM, Jecel Assumpcao Jr <jecel at merlintec.com>wrote:

> Ronald Spengler wrote:
> > We're bumping up against the homoiconicity of the system, aren't we?
> > That code is really just a kind of data. Has anyone ever done a diff tool
> > for whole images, not just source methods?
>
> Like I said in another reply, given that Squeak objects don't have a
> fixed identity (see other thread) it isn't very easy. But I don't think
> it is impossible in practice since objects mostly exist in very
> stereotyped patterns.
>
> > It would be fantabulous if I didn't have to write an installer script for
> > my package, instead having the necessary objects brought over directly.
>
> That is what I want. And I partly had it in Smalltalk V/Win (also
> released as Smalltalk Express). In that system your image started out as
> an essentially empty v.exe file plus a bunch of .dll files with objects
> and code. Some of these had to be shipped with the application while
> many (with all the development tools) couldn't (due to the license). The
> .dll files had lots of stuff you wouldn't need but you had to ship them
> even if you only needed a single object. And there were no tools to tell
> you that you were using any objects from a .dll so you might ship if
> even if you didn't need it. But I don't think all these problems would
> be too hard to fix.


and our experience at ParcPlace-Digitalk when we compared SLLs (Smalltalk
V's system of object DLLs requiring VM support, quite similar to image
segments) with Parcels (VW's system of a conventional but optimized object
pickling format) was that parcels were as fast, if not faster, and far less
brittle.  Making the file format identical to the object format and linking
in objects to the heap instead of parsing them seems like a really cool idea
but it ties the representation far too closely to a particular
implementation of the memory manager and object model.  Going with a
"soft"pickling format allows one to concentrate on important issues like
naming assumed structure (what are the prerequisites of a component) and how
to update it in the presence of schema changes, e.g. what if a component
includes an instance of some class which has gained or lost instance
variables in the loading image when compared to the image that published the
component.


>
> > Seems like the mother of all problems is: moving things around that way
> > between images of different formats. Would some future descendant of
> > SystemTracer perhaps be of use?
>
> If you want to send messages between these different images and you want
> to be able to send over some of the arguments (instead of just a far
> reference back to the sending image) then this problem has to be solved
> anyway. Perhaps we are talking about something more like the Corba
> serialization format than the SystemTracer, but it certainly is related
> to the latter.


Again you should check-out the VW parcel system and the communications
framework OpenTalk.  The OpenTalk marshaller is influenced by the parcel
object marshaller but the two have differences.

>
>
> -- Jecel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090824/4031f03f/attachment.htm


More information about the Squeak-dev mailing list