DeltaStreams moving forward
Locked
 
|
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 |
Re: DeltaStreams moving forward
|
|
Sounds excellent, thanks for the update!
|
Re: DeltaStreams moving forward
|
|
In reply to this post by Göran Krampe
(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 -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
Re: DeltaStreams moving forward
|
|
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'. -- Best regards, Igor Stasenko AKA sig. |
|
|
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 |
Re: DeltaStreams moving forward
|
|
On 06/09/07, Göran Krampe <[hidden email]> 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? > 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 > > > -- Best regards, Igor Stasenko AKA sig. |
Re: DeltaStreams moving forward
|
|
In reply to this post by Göran Krampe
On 9/6/07, Göran Krampe <[hidden email]> 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. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |