[self-interest] Saving Deltas

Jecel Assumpcao Jr jecel at merlintec.com
Fri Jun 18 03:16:58 UTC 2004


On Thursday 17 June 2004 18:58, Michael Latta wrote:
> I have a configuration management issue:
>
> In Smalltalk you could file out all the changes made in a session,

That is actually done as you go, so you don't have to do anything to 
save to your changes file. When Self 4.0 first came out, it implemented 
something like this (at least the equivalent of saving doIts) but I 
think nobody used it and it was dropped. Not sure about that, though.

> which would allow changing system methods.  These deltas could then
> be loaded into a new release of the image to apply customizations. 
> The transporter seems to be more about retaining a connection between
> a slot and a module. 

A set of slots and a module. And also you can have submodules. With this 
you can have the equivalent of both class definitions and method 
definitions of a Smalltalk changes file. The only thing is that each 
time you save a module it overwrites the previous version (actually it 
makes a backup of it and eliminates the previous backup) so you don't 
have a full history as in the changes file. I just use CVS (or simply 
RCS) to make up for this.

> If I change the module of all slots I modify am
> I going to regret it? 

No - it is the proper thing to do if the modification to the "system" 
object logically belongs to your application.

> When a new image is release (4.2.2? or 5.0?)
> will I be able to load my module and overwrite the same slots coming
> from the original module in the new image?

Normally yes, but any major restructuring to the objects might cause 
conflicts with your "delta" (as it would in any language). In my 
experience it has always been pretty easy to make the modifications 
needed to work with the newer version.

> The more I dig into Self the more clear it is that this must not be
> allowed to just die, and I am compelled to come up with some way to
> make a product on top of it.

The work I am doing, called Neo Smalltalk, was previously known as 
Self/R and is my attempt to make these ideas into a product.

About your crashes: it seems that the expression

currentTime < procFirst wakeTime ifTrue: [
                   ^ setRealTimer: procFirst wakeTime - currentTime.
               ].

is trying to set the real timer to a BigInt, most likely do to 
"procFirst wakeTime" being a BigInt. It is hard to say how far back 
this was set to a bogus value and where this happened. Unfortunately, 
checking arguments hasn't been a strong point in Self. Searching for 
the senders of 'wakeTime:' shows use two options, including 
addToTimerWaiters:For: in scheduler. This method limits the delay to at 
most 5ms, so perhaps 'times real' is becoming a BigInt or there is some 
wrap-around problem after midnight GMT.

You also wrote:
> I can see wanting to reference the slots of the object under 
> construction, but it would also need to reference the
> environment.  Maybe the object under construction should have an 
> implicit slot to lobby that is removed after compilation?

We can think of some special object (let's call it "the parser") taking 
a string object and using it as a description to build a new object. 
The parser can easily access contexts that the newly constructed object 
can't.

My comment was in relation to a graphical programing environment. There 
we can point to stuff and drag an object into another that couldn't be 
named inside this second object.

-- Jecel



More information about the Self-interest mailing list