the future is Supertool...

Some thoughts
> The future , as Goran said on Supertool, is not Monticello.
> Monticello is good for some, but is not the silver bullet.
>
>  
I dont agree with this SuperTool is the future approach, having lived
with MC2 is the future for all too long.

It has taken years for the use cases to form around the current tools
and some of these are non trivial. I expect any new tool will do the
easy stuff and fail to do the difficult stuff and we will be back where
we started. It takes a lot of effort and "going around the loop"  to dot
all the i's and cross all the t's. So I think we would be better off
actually finishing one tool (MC) or even its successor (MC2) before
starting on another.

For example the case where you want to maintain several versions of the
one method in the image:

You want the original method to stay with its original package so that
when you save the original package that package does not get broken. You
want your changes to stay with your package so that that does not get
broken. This is not as easy as it sounds.

A second example, however you do it,  the out-of-order loading supported
by MC1.5 requires a cache of not-yet-loadable elements, I call this the
orphanage. Orphans get rehomed once the parents arrive!

So whatever tool you come up with will have the same basic elements,
like MC1 has MCMethodDefinition MCClassDefinition
MCClassVariableDefinition etc and a loader to apply them, browsers to
look at them, differs to compare them etc. Why have 1 technology when
you can have 4. (MC MC2 SuperTool and SystemEditor)

I mention SystemEditor because I think that a persisted system editor
would make a useful binary package distribution format which only needs
SystemEditor to atomically load!

MC supports Diffs in theory, so the "packages are too big" argument can
be tackled.

I started to add changset support to MC1.5 as well. This makes sense
because MC already has browsers for all this stuff.

By all means improve the recent changes and change sets support, this
will help all tools to work better. But is the changeset functionality
not wired in a deep way in all of the forks that this is aiming to
support? Migrating everyone to this new scheme is not going to be easy.

Personally I think that MC1.5 with SystemEditor working (MC1.5 is ready
its SystemEditor that is not trested) would be a winning combination. I
also think that MC can be simplified and slimmed down a lot with
SystemEditor support working.

I am disappointed that we are unable to raise the effort to get
SystemEditor tested and usable. This is a bottleneck for all the
initiatives which want to use it MC1.5 MC2. and Supertool, so I think it
should be THE priority task. (I am a bit snowed under for now myself)

sorry for being overly cynical

Keith

El 8/15/07 10:53 AM, "Keith Hodges" <[hidden email]> escribió:

> I dont agree with this SuperTool is the future approach, having lived
> with MC2 is the future for all too long.

>  I think that MC1.5 with SystemEditor working (MC1.5 is ready
> its SystemEditor that is not trested) would be a winning combination.

Two futures ? (sounds like a Les Luthiers humoristic song)

For having Dan thing in Mantis 2788, the image need a huge change
The next update on stream is some like:

ReleaseBuilderFor3dot10 new updatePackages: 'Collections-edc.90(89).mcd
CollectionsTests-edc.74(73).mcd
Graphics-edc.42(41).mcd
Kernel-edc.166(165).mcd
KernelTests-edc.58(57).mcd
Monticello-edc.313(312).mcd
Morphic-edc.129(128).mcd
MorphicExtras-edc.34(33).mcd
Multilingual-edc.29(28).mcd
ST80-edc.40(39).mcd
System-edc.106(105).mcd
Tests-edc.33(32).mcd
Tools-edc.85(84).mcd'.

ReleaseBuilderFor3dot10 new loadTogether: #('EToys-edc.25.mcz'
'Network-edc.34.mcz' 'Traits-edc.230.mcz' 'XML-Parser-edc.4.mcz') merge:
false.

 
And then could happened more ripping , the Maurice Raab new sources scheme.

Thanks to Ralph , we have a process, the process is working, the process is
improving.

Edgar

Hi all!

Keith Hodges <[hidden email]> wrote:
> Some thoughts
> > The future , as Goran said on Supertool, is not Monticello.
> > Monticello is good for some, but is not the silver bullet.

Btw, I don't think I said anything like that. :)

> I dont agree with this SuperTool is the future approach, having lived
> with MC2 is the future for all too long.
>
> It has taken years for the use cases to form around the current tools
> and some of these are non trivial. I expect any new tool will do the
> easy stuff and fail to do the difficult stuff and we will be back where
> we started.

Note that IMHO DeltaStreams is not meant to replace MC/MC2. I see them
as complementary, at least for the foreseable future.

So the idea is to make DeltaStreams be good at its primary job - which
in my book is not the same as MC/MC2 tackles.

Also - it is driven by another principle - instead of making a very
smart tool that handles "difficult stuff" I want DeltaStreams to be
relatively "dumb" but through that dumbness enable developers to use
them and leverage them in a variety of ways and in situations where
smart tools fail - like for example harvesting "foreign fixes" into a
forked image which is quite different.

Sure, this all sounds ruther fuzzy - I agree. :)

> It takes a lot of effort and "going around the loop"  to dot
> all the i's and cross all the t's. So I think we would be better off
> actually finishing one tool (MC) or even its successor (MC2) before
> starting on another.

Well, it is not an "either or" situation. I would probably never muster
to contribute to MC/MC2 - but I do feel strongly for DeltaStreams.
Others feel different of course.

Both situations sound like they perhaps are not in the primary field of
DeltaStreams.
And if they turn up as interesting problems to solve in the context of
DeltaStreams I believe they would be approached differently - the first
one possibly by using a "patch queue" approach as Mercurial has. The
second at least partially by loading Deltas out-of-order.

But again, I don't want to solve the same problems as MC/MC2 is trying
to solve - nor using the same ideas.

> So whatever tool you come up with will have the same basic elements,
> like MC1 has MCMethodDefinition MCClassDefinition
> MCClassVariableDefinition etc and a loader to apply them, browsers to
> look at them, differs to compare them etc. Why have 1 technology when
> you can have 4. (MC MC2 SuperTool and SystemEditor)
>
> I mention SystemEditor because I think that a persisted system editor
> would make a useful binary package distribution format which only needs
> SystemEditor to atomically load!

I consider MC/MC1.5/MC2 to be variations of the same tool. They all are
our preferred advanced SCM tool(s) for maintaining packageswith full
defined history and advanced merging through that.

SystemEditor is IMHO not a tool but a low level library, at least at
this point.

DeltaStreams does not try to replace the MC-family. It tries to
complement our toolbox by offering a fine granular "pipe network" for
enabling a flow of fixes/enhancements between teams/forks/projects.

It could also work as a "commit tool" for grouping changes, temporarily
hiding or reapplying changes (patch queues) and possibly even replace
the .changes file eventually. This would then work just fine on top of
any of the MC-family tools - just like ChangeSets do today.

I am not envisioning a migration away from the MC-family.

> Personally I think that MC1.5 with SystemEditor working (MC1.5 is ready
> its SystemEditor that is not trested) would be a winning combination. I
> also think that MC can be simplified and slimmed down a lot with
> SystemEditor support working.

That sounds reasonable and I really like that work on the MC-family is
revived like this.
 
> I am disappointed that we are unable to raise the effort to get
> SystemEditor tested and usable. This is a bottleneck for all the
> initiatives which want to use it MC1.5 MC2. and Supertool, so I think it
> should be THE priority task. (I am a bit snowed under for now myself)

I don't yet have the insight into it to make much - but since I intend
to use it I guess I will eventually get there.

> sorry for being overly cynical

No problem! All views are valid in some sense.
 
> Keith

regards, Göran

Dear Goran, thanks for the explanation I think I am understanding a
little better now.

How about this for a simplish idea:

Use the chunk file format in the traditional manner, where the result of
evaluating one chunk is the reader for the next chunk, however instead
of evaluating the chunk completely, the typical deltaStream reader
places itself as the receiver of each of the messages in the chunk.

! "special first chunk" DeltaStreamContentBrowser asDeltaStreamReader !
! addInstVar: 'test' toClassNamed: 'TestClass' !
! removeInstVar: 'not wanted' fromClassNamed: 'TestClass' !

The first chunk evaluates to the default reader, so that the existing
fileIn support works. However if you ignore the first chunk, you can
supply any reader that you wish.

e.g.

"To browse in a contents browser"
1, (DeltaStreamContentBrowser read: file) open.

2.
"to apply and unnapply a change set"
doSystemEditor := SystemEditor read: file
undoDeltaStream := doSystemEditor antithesis asDeltaStream.

doSystemEditor commit.
(SystemEditor read: undoDeltaStream) commit.

3.
"interworking with other tools"
mySystemEditorPopulatedFromMC asDeltaStream

--
At present the chunk format reader has some state, such as which method
category is being read. If this scheme were to be adopted then I would
group items together in a more human readable and editable form e.g.

!""""!
! inClassNamed: 'MyClass' !
! addInstVar: 'a' !
! addInstVar: 'b' !
!""""!
! inClassNamed: MyClass' !
! inCategory: 'new' !
! addMethod: #myMethod !
#myMethod
    ^self

!""""!
! inClassNamed: MyClass' inCategory: 'new' addMethod: #myMethod !
#myMethod2
    ^ self

!""""!

You could also arrange that instead of compiling and evaluating each
chunk, the file could be pre-processed into a single evaluable expression.

For example, any chunks beginning with # are replaced with
! addSource: '"escaped \'code\' here\!" !

Then initial '!' are replaced with 'reader ', and ending '!', with '.'.

Finally for those who dont like the chunk format in their vi or emacs,
just removing all '!' will not distrurb the integrity of this format
since each action is on one line, and each method is started by a # and
terminated by a blank line.

ok if its a silly idea then I really should get some sleep

Keith