Smalltalk › Cincom › VisualWorks

[vw771] dead in the water

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

51 messages Options

123

Wallen, David

Re: [vw771] dead in the water

I've had to do this a lot lately. Sam's notion would be nice to have,
instead of resorting to filing out OverridesIsUs and using the
ChangeList tool and compare its code against a completely different
image (with no such package loaded).

- Dave W

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Samuel S. Shuster
Sent: Thursday, October 27, 2011 10:10 AM
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] [vw771] dead in the water

Reinout,

> We got something working today with the new comparison tool chain :-)
> When its code stabilizes we'll hand it over to Cincom.

If I understand, this is an example of what you would like:

So, let's say you created a new package, call it OverridesIsUs, and then
overrode a lot of code from the base and put all those overrides in that
new package, now you publish it.

Now, you start a brand new image that doesn't have OverridesIsUs loaded
in it, and you want to know "What is the difference between the code
OverridesIsUs and what is loaded in the image"

I don't believe we have ever had that, but it is interesting.

And So It Goes
Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dave Stevenson-3

Re: [vw771] dead in the water

In reply to this post by Samuel S. Shuster-2

What if the base definition is overridden by some 3rd party package, then overloaded again by me?

The merge tool lets the user pick which version of a definition to compare in each pane. I'd like a tool to offer a similar feature, to choose which versions of a definition to compare:
    - from the user-selected repository version
    - from the repository version last loaded into the image
    - active in the image, if different from the repository version last loaded into the image
    - overridden in the image (possibly many)

Dave Stevenson
[hidden email]

From: Samuel S. Shuster <[hidden email]>
To: Reinout Heeck <[hidden email]>
Cc: [hidden email]
Sent: Thu, October 27, 2011 12:10:18 PM
Subject: Re: [vwnc] [vw771] dead in the water

Reinout,

> We got something working today with the new comparison tool chain :-)
> When its code stabilizes we'll hand it over to Cincom.

If I understand, this is an example of what you would like:

So, let's say you created a new package, call it OverridesIsUs, and then overrode a lot of code from the base and put all those overrides in that new package, now you publish it.

Now, you start a brand new image that doesn't have OverridesIsUs loaded in it, and you want to know "What is the difference between the code OverridesIsUs and what is loaded in the image"

I don't believe we have ever had that, but it is interesting.

And So It Goes
Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Terry Raymond

Re: [vw771] dead in the water

In reply to this post by Samuel S. Shuster-2

Sames

Yes, that is it. We also do the same thing.

We would much rather have a few packages that modify the base code than one
patch package for
each base package.

I think the reason I have not had the same problem Reinout has, is that I
was able to load our
"redefines" and check them in the image.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
===========================================================
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Samuel S. Shuster
Sent: Thursday, October 27, 2011 1:10 PM
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] [vw771] dead in the water

Reinout,

> We got something working today with the new comparison tool chain :-)
> When its code stabilizes we'll hand it over to Cincom.

If I understand, this is an example of what you would like:

So, let's say you created a new package, call it OverridesIsUs, and then
overrode a lot of code from the base and put all those overrides in that new
package, now you publish it.

Now, you start a brand new image that doesn't have OverridesIsUs loaded in
it, and you want to know "What is the difference between the code
OverridesIsUs and what is loaded in the image"

I don't believe we have ever had that, but it is interesting.

And So It Goes
Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: [vw78] dead in the water (again!)

In reply to this post by Travis Griggs-4

Travis,

To be able to do what you are suggesting you need to have a version in
your image. When integrating patches from a previous vw version this is
usually not the case. What you want is to see the differences of code
that resides in store and the same code that is in your image, in
whatever package it may live. Even if you create an empty package and
reconcile it you will only see changes between the PackageModel and
StorePackage.

I have entered case 431144 with Cincom support and uploaded our solution
to the Cincom FTP site so it can be reviewed and integrated.

Regards,

Cham

On 27-10-2011 18:13, Travis Griggs wrote:

> On Oct 27, 2011, at 1:01 AM, Reinout Heeck wrote:
>
>> On 10/26/2011 6:11 PM, Travis Griggs wrote:
>>>
>>> I'm confused. I compare with image frequently.
>> Below you are comparing with the image *version*, not with 'the image'
> No, I respectfully/apologetically think you are mistaken. Or… I'm not understanding the semantics and terms you are using. Do the following steps, all from the browser:
>
> a) Make a package ZZZ
> b) add a class FooBar to ZZZ
> c) Publish ZZZ, version 1
> d) add an instance variable to FooBar, call it 'slot'
> e) Publsh ZZZ, version 2
> f) remove the instance variable 'slot' from FooBar
> g) At this point, you should have a "dirty version of ZZZ 2"
> h) compare with… pick version 2. The result should be that it shows the difference between the live image with the inst var gone and version 2 where it was not there
>
> For your assertion to be true at this point, it would need to be that that showed no changes
>
> i) now compare with… pick version 1. The result should be "no changes"
>
> Again, for the assertion as I understand it to be true, it would need to show the difference version 2 and version 1, rather than what it does which is to tell you that the code in your image, though it started life as version 2, is now the same thing as 1.
>
> Or… is this really all about overrides? In which case, I think it would be helpful to scope the statements and frustrations along those lines.
>
> --
> Travis Griggs
> Objologist
> "I did not have time to write you a short program, so I wrote you a long one instead."
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-4

Re: [vw78] dead in the water (again!)

On Oct 27, 2011, at 11:41 AM, Cham Püschel wrote:

> Travis,
>
> To be able to do what you are suggesting you need to have a version in
> your image. When integrating patches from a previous vw version this is
> usually not the case. What you want is to see the differences of code
> that resides in store and the same code that is in your image, in
> whatever package it may live. Even if you create an empty package and
> reconcile it you will only see changes between the PackageModel and
> StorePackage.

Thank you for clarifying. You want a way to compare code captured in a bundle or packages against The Image, no interest in packages from the image.

So in this particular case, you'd never see an addition, or a removal, depending on your direction of comparison. The unloaded body of code would show things that it changed from the image, and things it added that weren't in the image at all. But it wouldn't show anything as being removed.

Does that jive?

--
Travis Griggs
Objologist
Light travels faster than sound. This is why some people appear bright until you hear them speak...

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-4

Re: [vw78] dead in the water (again!)

In reply to this post by Reinout Heeck-2

On Oct 27, 2011, at 11:41 AM, Cham Püschel wrote:

Travis,

To be able to do what you are suggesting you need to have a version in
your image. When integrating patches from a previous vw version this is
usually not the case. What you want is to see the differences of code
that resides in store and the same code that is in your image, in
whatever package it may live. Even if you create an empty package and
reconcile it you will only see changes between the PackageModel and
StorePackage.

I was intrigued enough by this, that I sat down and played with something along these lines. Spent about 75 minutes on it. My use case was:

"I want to load BottomFeeder bundle into a current st11a image, but knowing the venerable Jaro didn't mind fixing things, I'm a bit anxious about doing this without first being aware of what loading that thing is going to do to my image, regardless of packaging."

I published my work in the Open Repository as:

TAG-ModificationsToImageTool(The First)

It adds a

'Modifications to current image'

menu option to the version tools and the PublishedItems tool.

It's a first cut, see the package comment. But for the use case above, it produces this comparison tool:

Hat tip to James for overriding at least 33 methods with BottomFeeder :)

Wonder who can beat that (the count prints in the window label)?

Cham, I'll try to keep an eye out for your submission to see how much I was off what you guys are trying to do.

I do note that you can only go so far with this kind of analysis. If someone just adds the method

ByteEncodedString>>isString

^false

You'll hose your image instantly. It's not an override, but a change in the inherited API. The easy ones like this are obvious and silly. It's the harder ones that show up only in weird edge cases that are tough.

Travis Griggs

Objologist

"The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead." -- Ron Avitzur

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

giorgiof

Re: [vw78] dead in the water (again!)

hi,

I was following this discussion because it will interest me in a short time. I jump here just for one thing: thank Travis. I quite often get surprised by the passion of the people behind smalltalk.

giorgio

On Fri, Oct 28, 2011 at 9:19 AM, Travis Griggs <[hidden email]> wrote:

On Oct 27, 2011, at 11:41 AM, Cham Püschel wrote:

Travis,

To be able to do what you are suggesting you need to have a version in
your image. When integrating patches from a previous vw version this is
usually not the case. What you want is to see the differences of code
that resides in store and the same code that is in your image, in
whatever package it may live. Even if you create an empty package and
reconcile it you will only see changes between the PackageModel and
StorePackage.

I was intrigued enough by this, that I sat down and played with something along these lines. Spent about 75 minutes on it. My use case was:

"I want to load BottomFeeder bundle into a current st11a image, but knowing the venerable Jaro didn't mind fixing things, I'm a bit anxious about doing this without first being aware of what loading that thing is going to do to my image, regardless of packaging."

I published my work in the Open Repository as:

TAG-ModificationsToImageTool(The First)

It adds a

'Modifications to current image'

menu option to the version tools and the PublishedItems tool.

It's a first cut, see the package comment. But for the use case above, it produces this comparison tool:

Hat tip to James for overriding at least 33 methods with BottomFeeder :)

Wonder who can beat that (the count prints in the window label)?

Cham, I'll try to keep an eye out for your submission to see how much I was off what you guys are trying to do.

I do note that you can only go so far with this kind of analysis. If someone just adds the method

ByteEncodedString>>isString
^false

You'll hose your image instantly. It's not an override, but a change in the inherited API. The easy ones like this are obvious and silly. It's the harder ones that show up only in weird edge cases that are tough.

--
Travis Griggs
Objologist
"The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead." -- Ron Avitzur

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Jon Paynter-2

Re: [vw78] dead in the water (again!)

This looks to be a very useful tool - keep up the good work!

On Fri, Oct 28, 2011 at 2:02 AM, giorgio ferraris <[hidden email]> wrote:

hi,

I was following this discussion because it will interest me in a short time. I jump here just for one thing: thank Travis. I quite often get surprised by the passion of the people behind smalltalk.

giorgio

On Fri, Oct 28, 2011 at 9:19 AM, Travis Griggs <[hidden email]> wrote:

On Oct 27, 2011, at 11:41 AM, Cham Püschel wrote:

Travis,

To be able to do what you are suggesting you need to have a version in
your image. When integrating patches from a previous vw version this is
usually not the case. What you want is to see the differences of code
that resides in store and the same code that is in your image, in
whatever package it may live. Even if you create an empty package and
reconcile it you will only see changes between the PackageModel and
StorePackage.

I was intrigued enough by this, that I sat down and played with something along these lines. Spent about 75 minutes on it. My use case was:

"I want to load BottomFeeder bundle into a current st11a image, but knowing the venerable Jaro didn't mind fixing things, I'm a bit anxious about doing this without first being aware of what loading that thing is going to do to my image, regardless of packaging."

I published my work in the Open Repository as:

TAG-ModificationsToImageTool(The First)

It adds a

'Modifications to current image'

menu option to the version tools and the PublishedItems tool.

It's a first cut, see the package comment. But for the use case above, it produces this comparison tool:

Hat tip to James for overriding at least 33 methods with BottomFeeder :)

Wonder who can beat that (the count prints in the window label)?

Cham, I'll try to keep an eye out for your submission to see how much I was off what you guys are trying to do.

I do note that you can only go so far with this kind of analysis. If someone just adds the method

ByteEncodedString>>isString
^false

You'll hose your image instantly. It's not an override, but a change in the inherited API. The easy ones like this are obvious and silly. It's the harder ones that show up only in weird edge cases that are tough.

--
Travis Griggs
Objologist
"The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead." -- Ron Avitzur

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: [vw771] dead in the water

In reply to this post by Samuel S. Shuster-2

On 10/27/2011 7:10 PM, Samuel S. Shuster wrote:
> If I understand, this is an example of what you would like:
>
> So, let's say you created a new package, call it OverridesIsUs, and then overrode a lot of code from the base and put all those overrides in that new package, now you publish it.
>
> Now, you start a brand new image that doesn't have OverridesIsUs loaded in it, and you want to know "What is the difference between the code OverridesIsUs and what is loaded in the image"
Yes, not just the overrides (alterations) but any additions (no
counterpart in the image) as well.

> I don't believe we have ever had that, but it is interesting.

Well, that remark set me reeling, 'cause I was sure we used this
functionality in 76 (and several older versions) .

It turns out that in 76 the menu item 'compare with image' is greyed out
if the package is not loaded.
However, if I create an empty package by the same name the menu item
will be enabled.

Moreover the 76 differator will show differences with the image (not the
differences with the empty package as 78 does).
So we did have it, only in a roundabout way.

With the new differencing framework this functionality/workflow has been
removed (while we do need it).

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-4

Re: [vw771] dead in the water

On Oct 31, 2011, at 2:46 AM, Reinout Heeck wrote:

On 10/27/2011 7:10 PM, Samuel S. Shuster wrote:
If I understand, this is an example of what you would like:

So, let's say you created a new package, call it OverridesIsUs, and then overrode a lot of code from the base and put all those overrides in that new package, now you publish it.

Now, you start a brand new image that doesn't have OverridesIsUs loaded in it, and you want to know "What is the difference between the code OverridesIsUs and what is loaded in the image"
Yes, not just the overrides (alterations) but any additions (no
counterpart in the image) as well.

But not removals obviously, right? Because you can't assume the selected package had the whole image in it. So to sum this up, so I make sure I'm restating and understanding correctly.

There was a feature that would

a) treat the whole image as the left side of a comparison (the from part)

b) do 2/3's of the work (does additions, and changes, but not removals)

c) enabled by the presence of a package of the same name (but otherwise the contents of that image package were irrelevant)

and that is gone now.

Am I getting it yet? Or am I still stumbling to understand?

Travis Griggs

Objologist

Simplicity is the Ultimate Sophistication -- Leonardo da Vinci

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: [vw771] dead in the water

On 11/1/2011 2:08 AM, Travis Griggs wrote:

On Oct 31, 2011, at 2:46 AM, Reinout Heeck wrote:

On 10/27/2011 7:10 PM, Samuel S. Shuster wrote:

If I understand, this is an example of what you would like:

So, let's say you created a new package, call it OverridesIsUs, and then overrode a lot of code from the base and put all those overrides in that new package, now you publish it.

Now, you start a brand new image that doesn't have OverridesIsUs loaded in it, and you want to know "What is the difference between the code OverridesIsUs and what is loaded in the image"

Yes, not just the overrides (alterations) but any additions (no
counterpart in the image) as well.

But not removals obviously, right? Because you can't assume the selected package had the whole image in it. So to sum this up, so I make sure I'm restating and understanding correctly.

There was a feature that would

a) treat the whole image as the left side of a comparison (the from part)

b) do 2/3's of the work (does additions, and changes, but not removals)

c) enabled by the presence of a package of the same name (but otherwise the contents of that image package were irrelevant)

Yes, that's correct.

The casual bystander might find c) surprising, but it makes perfect sense in the workflow of porting patches forward:
either one loads an old version and stabilizes the image (using just the system browser)
or one creates an empty package version, reconciles it and brings in the redefinitions on-by-one using the 2/3 differator described above.

FYI: we freshly implemented one on the vw78 differator framework and uploaded it to the cindom ftp (StoreCompareWithImage431144.zip), this is tracked in support case 431144.

R
-

-- 
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

123