[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