Hi folks!
A quick report from the DeltaStreams project. I and Matthew Fulmer have been cranking out code in a decent speed actually and stuff is starting to work for real.
We are currently implementing DSDelta, DSChange (with 24 subclasses, each representing a particular kind of change) and DSSystemEditorApplier which is the visitor that actually can apply (make the actual changes) a DSDelta to the image.
A DSDelta currently listens to SystemChangeNotifier just like ChangeSet does and captures all (I think) possible kinds of changes in an OrderedCollection. Each change instance can answer with its antiChange and a DSDelta can produce its own antiDelta by responding to asAntiDelta.
DSDelta implements #revert basically as "self asAntiDelta apply" and the actual "apply" is done using a simple double dispatch visiting scheme. The current code uses SystemEditor from Colin Putney - we have made several bug fixes to it and I think our current test failures seems to be rooted in SystemEditor.
Currently we have 81 tests, 66 passes with 11 failures, these include a bunch of revert-tests.
Matthew just recently started thinking about implementing a tool UI on top - a la change sorter and we are targeting ToolBuilder - if anyone has views on that we are all ears. Our prime targets for this project are 3.7-3.10 + Croquet.
Serialization formats, DSDelta normalization, DSDelta analysis (conflict detection, analysis on how/if it can be applied properly to the image etc) and transport (streams) have not been started yet.
regards, Göran
(hey, a message without mentioning double semicolon on squeak-dev :)
Great job G¨oran, Matthew, looks good (especially #asAntiDelta).
Q: when you say SystemEditor, will that make ClassBuilder and/or any other class(es) obsolete? or will ClassBuilder still have to be maintained, parallel to SystemEditor?
/Klaus
On Wed, 05 Sep 2007 21:29:56 +0200, G¨oran Krampe wrote:
Hi folks!
A quick report from the DeltaStreams project. I and Matthew Fulmer have been cranking out code in a decent speed actually and stuff is starting to work for real.
We are currently implementing DSDelta, DSChange (with 24 subclasses, each representing a particular kind of change) and DSSystemEditorApplier which is the visitor that actually can apply (make the actual changes) a DSDelta to the image.
A DSDelta currently listens to SystemChangeNotifier just like ChangeSet does and captures all (I think) possible kinds of changes in an OrderedCollection. Each change instance can answer with its antiChange and a DSDelta can produce its own antiDelta by responding to asAntiDelta.
DSDelta implements #revert basically as "self asAntiDelta apply" and the actual "apply" is done using a simple double dispatch visiting scheme. The current code uses SystemEditor from Colin Putney - we have made several bug fixes to it and I think our current test failures seems to be rooted in SystemEditor.
Currently we have 81 tests, 66 passes with 11 failures, these include a bunch of revert-tests.
Matthew just recently started thinking about implementing a tool UI on top
- a la change sorter and we are targeting ToolBuilder - if anyone has
views on that we are all ears. Our prime targets for this project are 3.7-3.10 + Croquet.
Serialization formats, DSDelta normalization, DSDelta analysis (conflict detection, analysis on how/if it can be applied properly to the image etc) and transport (streams) have not been started yet.
regards, Göran
On Thu, Sep 06, 2007 at 12:43:31AM +0200, Klaus D. Witzel wrote:
(hey, a message without mentioning double semicolon on squeak-dev :)
Great job G??oran, Matthew, looks good (especially #asAntiDelta).
Q: when you say SystemEditor, will that make ClassBuilder and/or any other class(es) obsolete? or will ClassBuilder still have to be maintained, parallel to SystemEditor?
No; SystemEditor is a library, developed for Monticello 2, that provides a holding ground for system changes (class additions, edits, method changes, etc) and allows those to be committed atomically to the image, in order to avoid seeing problems when things are loaded in the wrong order. For now, it is not used, but I don't think it is intended to replace ClassBuilder and friends. Colin could tell you more
A small remark about #asAntiDelta.
I think its better to rename it to one of: #asReverseDelta #reversed
then code can look more nicely:
self reversed apply
or even:
self reverseApply (which will do exactly 'self reversed apply')
I'm just don't like word 'Anti' in this context. For me, a words 'reverse changes' have more closer meaning to 'undoing changes' than 'anti changes'.
Hi!
A small remark about #asAntiDelta.
I think its better to rename it to one of: #asReverseDelta #reversed
then code can look more nicely:
self reversed apply
or even:
self reverseApply (which will do exactly 'self reversed apply')
I'm just don't like word 'Anti' in this context. For me, a words 'reverse changes' have more closer meaning to 'undoing changes' than 'anti changes'.
Possibly so, yes, I probably agree. The base idea is of course that we only have one #apply method and we accomplish its "opposite" by instead constructing a Delta that does the opposite.
There are also other "distinctions" we could make. For example, will a revert be exactly the same as if I had manually made changes to undo the previous changes? Or would it be exactly like an undo - leaving no trace that the original changes ever happened (like for example "versions" of methods)?
And if we want both mechanisms - what will we call them? Should we use #revert (that does "self asReverseDelta apply" and thus adds a new Delta to the list of "applied Deltas") and #unapply for this "real" undo mechanism (that I guess would actually remove the Delta from the list of "applied Deltas")? Or is a real undo even considered a dangerous idea?
Darcs has them both IIRC.
And oh, lists of applied Deltas etc - these are also "new concepts" in the Squeak realm. SOooo many questions... :)
regards, Göran
On 06/09/07, Göran Krampe goran@krampe.se wrote:
Hi!
A small remark about #asAntiDelta.
I think its better to rename it to one of: #asReverseDelta #reversed
then code can look more nicely:
self reversed apply
or even:
self reverseApply (which will do exactly 'self reversed apply')
I'm just don't like word 'Anti' in this context. For me, a words 'reverse changes' have more closer meaning to 'undoing changes' than 'anti changes'.
Possibly so, yes, I probably agree. The base idea is of course that we only have one #apply method and we accomplish its "opposite" by instead constructing a Delta that does the opposite.
There are also other "distinctions" we could make. For example, will a revert be exactly the same as if I had manually made changes to undo the previous changes? Or would it be exactly like an undo - leaving no trace that the original changes ever happened (like for example "versions" of methods)?
And if we want both mechanisms - what will we call them? Should we use #revert (that does "self asReverseDelta apply" and thus adds a new Delta to the list of "applied Deltas") and #unapply for this "real" undo mechanism (that I guess would actually remove the Delta from the list of "applied Deltas")? Or is a real undo even considered a dangerous idea?
I think this ambiguousness can be solved trivially, at least at delta level: If delta includes action 'add self to list of deltas', then reverse should remove it from list.
For higher level tools , like delta updater (or whatever) it can be done in following way: - load delta - envelop loaded delta in "logged delta" - apply "logged delta", which will actually applies loaded delta and adds itself to list of applied deltas.
And i don't think that deltas should care about having 2 or more ways how it can be 'unapplied'. As you always saying - KISS :)
Darcs has them both IIRC.
And oh, lists of applied Deltas etc - these are also "new concepts" in the Squeak realm. SOooo many questions... :)
regards, Göran
On 9/6/07, Göran Krampe goran@krampe.se wrote:
There are also other "distinctions" we could make. For example, will a revert be exactly the same as if I had manually made changes to undo the previous changes? Or would it be exactly like an undo - leaving no trace that the original changes ever happened (like for example "versions" of methods)?
Thinking about how the low level Deltas would be used, I would say that reverting a delta should make the system as though it was never there. If higher level tools want to revert but keep the history for some reason they only need to fetch the Delta from the "to revert to" time and apply it again.
And if we want both mechanisms - what will we call them? Should we use #revert (that does "self asReverseDelta apply" and thus adds a new Delta to the list of "applied Deltas") and #unapply for this "real" undo mechanism (that I guess would actually remove the Delta from the list of "applied Deltas")? Or is a real undo even considered a dangerous idea?
Darcs has them both IIRC.
Darcs has a "unrecord that I made these changes but keep them in the file" and a "revert to a previous version" operation, but I think this is a consequence of working on files (that is, Darcs doesn't find out about the changes until after the fact). In Smalltalk what is in your system should *always* be under some kind of change set, so therefor the first option makes no sense here.
squeak-dev@lists.squeakfoundation.org
-
Göran Krampe -
Igor Stasenko -
Jason Johnson -
Klaus D. Witzel -
Matthew Fulmer -
Simon Michael