Overrides

I'm not sure what you mean. There should be no problem publishing into Store a package that has been overridden. If you want to modify a method which has been overridden, and publish that, then you would probably need to restore the overridden version while editing it. That's a bit painful, but still do-able.

It's possible that you're confusing publishing behaviour with loading behaviour. When you load a new version of a package or bundle that has been overridden, whichever thing was loaded most recently is the one that overrides the other definitions. But it still won't move things between packages.

At 08:01 PM 11/2/2006, Charlie Adams wrote:

(I should explain first that we have published of all of the VW 7.4 code in our postgres database. This includes Base VW and many of the loose packages like the Debugger, Store, etc.)
 
If I want to modify a package overridden by the debugger, how do I do that without using overrides myself? I want to create a new version of the VW package but this will cause problems with the debugger's overrides in that same package. In fact, it will strip out the overridden method and assign it to the debugger package as an extension. This is an unintended consequence.
 
Charles Adams   

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 9:27 AM

Subject: Re: Overrides

I'm not sure what you mean. There should be no problem publishing into Store a package that has been overridden. If you want to modify a method which has been overridden, and publish that, then you would probably need to restore the overridden version while editing it. That's a bit painful, but still do-able.

It's possible that you're confusing publishing behaviour with loading behaviour. When you load a new version of a package or bundle that has been overridden, whichever thing was loaded most recently is the one that overrides the other definitions. But it still won't move things between packages.

At 08:01 PM 11/2/2006, Charlie Adams wrote:

(I should explain first that we have published of all of the VW 7.4 code in our postgres database. This includes Base VW and many of the loose packages like the Debugger, Store, etc.)
 
If I want to modify a package overridden by the debugger, how do I do that without using overrides myself? I want to create a new version of the VW package but this will cause problems with the debugger's overrides in that same package. In fact, it will strip out the overridden method and assign it to the debugger package as an extension. This is an unintended consequence.
 
Charles Adams   

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

At 04:35 PM 11/6/2006, Charlie Adams wrote:

I had overridden Process>>printOn: from Kernel-Processes in my own package.
 
I restored the original implementation and changed it in place instead. This gave me a new version of Kernel-Processes and no override of Process>>printOn:.
 
Debug-Support overrides ProcessorScheduler>>interruptActiveUserProcess -- also found in Kernel-Processes.
 
The act of versioning Kernel-Processes caused it (Kernel-Processes) to re-override ProcessorScheduler>>interruptActiveUserProcess. Now it looks like Kernel-Processes is overriding Debug-Support.

That's not what I see. I did exactly that, and the interruptActiveUserProcess method is still the same. It's in Debugger-Support, overriding Kernel-Processes. In general, I think it's unlikely that the act of publishing would re-arrange overrides within the image. The act of loading might.

I've tried reloading Debug-Support  and reversioning Debug-Support but it will not reassert its override. I know its out there. The library shows it implementing ProcessorScheduler>>interruptActiveUserProcess.
 
The attempt to version my bundle containing my version of Kernel-Processes threw up a dialog:
 
    One or more of the components in MyBundle overrides another. Publishing will cause one to replace the other when loading.
    It is recommend [sic] that you resolve these redundancies before publishing.
            Continue?
 
How do I resolve the redundancies? To be precise, I have not included Debugger-Support in my bundle. So, the first statement does not make sense to me. And, yes, this is only one example of many that I am dealing with at this time, as we have many overrides that I am trying to convert to straight up changes. I think this is a fairly isolated example and hope it is not being influenced by some other change I've made.

Ah, so this is not likely related to overriding in general, but specifically to overriding within bundles. Without knowing what your bundle structure is, it's hard to say.  However, a useful way of finding out what Store thinks the problem is is to hit control-Y when you get a dialog you don't understand, and go look at why it's telling you this.

 
----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 9:27 AM

Subject: Re: Overrides

I'm not sure what you mean. There should be no problem publishing into Store a package that has been overridden. If you want to modify a method which has been overridden, and publish that, then you would probably need to restore the overridden version while editing it. That's a bit painful, but still do-able.

It's possible that you're confusing publishing behaviour with loading behaviour. When you load a new version of a package or bundle that has been overridden, whichever thing was loaded most recently is the one that overrides the other definitions. But it still won't move things between packages.

At 08:01 PM 11/2/2006, Charlie Adams wrote:

(I should explain first that we have published of all of the VW 7.4 code in our postgres database. This includes Base VW and many of the loose packages like the Debugger, Store, etc.)

 

If I want to modify a package overridden by the debugger, how do I do that without using overrides myself? I want to create a new version of the VW package but this will cause problems with the debugger's overrides in that same package. In fact, it will strip out the overridden method and assign it to the debugger package as an extension. This is an unintended consequence.

 

Charles Adams   

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 4:58 PM

Subject: Re: Overrides

At 04:35 PM 11/6/2006, Charlie Adams wrote:

I had overridden Process>>printOn: from Kernel-Processes in my own package.
 
I restored the original implementation and changed it in place instead. This gave me a new version of Kernel-Processes and no override of Process>>printOn:.
 
Debug-Support overrides ProcessorScheduler>>interruptActiveUserProcess -- also found in Kernel-Processes.
 
The act of versioning Kernel-Processes caused it (Kernel-Processes) to re-override ProcessorScheduler>>interruptActiveUserProcess. Now it looks like Kernel-Processes is overriding Debug-Support.

That's not what I see. I did exactly that, and the interruptActiveUserProcess method is still the same. It's in Debugger-Support, overriding Kernel-Processes. In general, I think it's unlikely that the act of publishing would re-arrange overrides within the image. The act of loading might.

I've tried reloading Debug-Support  and reversioning Debug-Support but it will not reassert its override. I know its out there. The library shows it implementing ProcessorScheduler>>interruptActiveUserProcess.
 
The attempt to version my bundle containing my version of Kernel-Processes threw up a dialog:
 
    One or more of the components in MyBundle overrides another. Publishing will cause one to replace the other when loading.
    It is recommend [sic] that you resolve these redundancies before publishing.
            Continue?
 
How do I resolve the redundancies? To be precise, I have not included Debugger-Support in my bundle. So, the first statement does not make sense to me. And, yes, this is only one example of many that I am dealing with at this time, as we have many overrides that I am trying to convert to straight up changes. I think this is a fairly isolated example and hope it is not being influenced by some other change I've made.

Ah, so this is not likely related to overriding in general, but specifically to overriding within bundles. Without knowing what your bundle structure is, it's hard to say.  However, a useful way of finding out what Store thinks the problem is is to hit control-Y when you get a dialog you don't understand, and go look at why it's telling you this.

 

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 9:27 AM

Subject: Re: Overrides

I'm not sure what you mean. There should be no problem publishing into Store a package that has been overridden. If you want to modify a method which has been overridden, and publish that, then you would probably need to restore the overridden version while editing it. That's a bit painful, but still do-able.

It's possible that you're confusing publishing behaviour with loading behaviour. When you load a new version of a package or bundle that has been overridden, whichever thing was loaded most recently is the one that overrides the other definitions. But it still won't move things between packages.

At 08:01 PM 11/2/2006, Charlie Adams wrote:

(I should explain first that we have published of all of the VW 7.4 code in our postgres database. This includes Base VW and many of the loose packages like the Debugger, Store, etc.)

 

If I want to modify a package overridden by the debugger, how do I do that without using overrides myself? I want to create a new version of the VW package but this will cause problems with the debugger's overrides in that same package. In fact, it will strip out the overridden method and assign it to the debugger package as an extension. This is an unintended consequence.

 

Charles Adams   

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 8:45 PM

Subject: Re: Overrides

 

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 4:58 PM

Subject: Re: Overrides

At 04:35 PM 11/6/2006, Charlie Adams wrote:

I had overridden Process>>printOn: from Kernel-Processes in my own package.
 
I restored the original implementation and changed it in place instead. This gave me a new version of Kernel-Processes and no override of Process>>printOn:.
 
Debug-Support overrides ProcessorScheduler>>interruptActiveUserProcess -- also found in Kernel-Processes.
 
The act of versioning Kernel-Processes caused it (Kernel-Processes) to re-override ProcessorScheduler>>interruptActiveUserProcess. Now it looks like Kernel-Processes is overriding Debug-Support.

That's not what I see. I did exactly that, and the interruptActiveUserProcess method is still the same. It's in Debugger-Support, overriding Kernel-Processes. In general, I think it's unlikely that the act of publishing would re-arrange overrides within the image. The act of loading might.

I've tried reloading Debug-Support  and reversioning Debug-Support but it will not reassert its override. I know its out there. The library shows it implementing ProcessorScheduler>>interruptActiveUserProcess.
 
The attempt to version my bundle containing my version of Kernel-Processes threw up a dialog:
 
    One or more of the components in MyBundle overrides another. Publishing will cause one to replace the other when loading.
    It is recommend [sic] that you resolve these redundancies before publishing.
            Continue?
 
How do I resolve the redundancies? To be precise, I have not included Debugger-Support in my bundle. So, the first statement does not make sense to me. And, yes, this is only one example of many that I am dealing with at this time, as we have many overrides that I am trying to convert to straight up changes. I think this is a fairly isolated example and hope it is not being influenced by some other change I've made.

Ah, so this is not likely related to overriding in general, but specifically to overriding within bundles. Without knowing what your bundle structure is, it's hard to say.  However, a useful way of finding out what Store thinks the problem is is to hit control-Y when you get a dialog you don't understand, and go look at why it's telling you this.

 

What would the role of the bundle be here? As I said, Debugger-Support is not in my bundle. The original version of Kernel-Processes is not in my bundle. Only my new version of Kernel-Processes is in my bundle. I don't see how my bundle structure could be the problem.

 

I know what the dialog is telling me and I know what it is doing. My question is why or how can this be the correct behavior? I am in the middle of porting a customer. I do not have time to deal with problems like this.

 

 

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 9:27 AM

Subject: Re: Overrides

I'm not sure what you mean. There should be no problem publishing into Store a package that has been overridden. If you want to modify a method which has been overridden, and publish that, then you would probably need to restore the overridden version while editing it. That's a bit painful, but still do-able.

It's possible that you're confusing publishing behaviour with loading behaviour. When you load a new version of a package or bundle that has been overridden, whichever thing was loaded most recently is the one that overrides the other definitions. But it still won't move things between packages.

At 08:01 PM 11/2/2006, Charlie Adams wrote:

(I should explain first that we have published of all of the VW 7.4 code in our postgres database. This includes Base VW and many of the loose packages like the Debugger, Store, etc.)

 

If I want to modify a package overridden by the debugger, how do I do that without using overrides myself? I want to create a new version of the VW package but this will cause problems with the debugger's overrides in that same package. In fact, it will strip out the overridden method and assign it to the debugger package as an extension. This is an unintended consequence.

 

Charles Adams   

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Phew. And please do let me know if you get it reproducible.

At 12:02 PM 11/7/2006, Charlie Adams wrote:

Alan,
 
Sorry to waste your time. I can no longer reproduce the results I was getting. If and when I can build a reproducible test case, I'll submit it.

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 8:45 PM

Subject: Re: Overrides

 

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 4:58 PM

Subject: Re: Overrides

At 04:35 PM 11/6/2006, Charlie Adams wrote:

I had overridden Process>>printOn: from Kernel-Processes in my own package.

 

I restored the original implementation and changed it in place instead. This gave me a new version of Kernel-Processes and no override of Process>>printOn:.

 

Debug-Support overrides ProcessorScheduler>>interruptActiveUserProcess -- also found in Kernel-Processes.

 

The act of versioning Kernel-Processes caused it (Kernel-Processes) to re-override ProcessorScheduler>>interruptActiveUserProcess. Now it looks like Kernel-Processes is overriding Debug-Support.

That's not what I see. I did exactly that, and the interruptActiveUserProcess method is still the same. It's in Debugger-Support, overriding Kernel-Processes. In general, I think it's unlikely that the act of publishing would re-arrange overrides within the image. The act of loading might.

I've tried reloading Debug-Support  and reversioning Debug-Support but it will not reassert its override. I know its out there. The library shows it implementing ProcessorScheduler>>interruptActiveUserProcess.

 

The attempt to version my bundle containing my version of Kernel-Processes threw up a dialog:

 

    One or more of the components in MyBundle overrides another. Publishing will cause one to replace the other when loading.

    It is recommend [sic] that you resolve these redundancies before publishing.

            Continue?

 

How do I resolve the redundancies? To be precise, I have not included Debugger-Support in my bundle. So, the first statement does not make sense to me. And, yes, this is only one example of many that I am dealing with at this time, as we have many overrides that I am trying to convert to straight up changes. I think this is a fairly isolated example and hope it is not being influenced by some other change I've made.

Ah, so this is not likely related to overriding in general, but specifically to overriding within bundles. Without knowing what your bundle structure is, it's hard to say.  However, a useful way of finding out what Store thinks the problem is is to hit control-Y when you get a dialog you don't understand, and go look at why it's telling you this.

 

What would the role of the bundle be here? As I said, Debugger-Support is not in my bundle. The original version of Kernel-Processes is not in my bundle. Only my new version of Kernel-Processes is in my bundle. I don't see how my bundle structure could be the problem.

 

I know what the dialog is telling me and I know what it is doing. My question is why or how can this be the correct behavior? I am in the middle of porting a customer. I do not have time to deal with problems like this.

 

 

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 9:27 AM

Subject: Re: Overrides

I'm not sure what you mean. There should be no problem publishing into Store a package that has been overridden. If you want to modify a method which has been overridden, and publish that, then you would probably need to restore the overridden version while editing it. That's a bit painful, but still do-able.

It's possible that you're confusing publishing behaviour with loading behaviour. When you load a new version of a package or bundle that has been overridden, whichever thing was loaded most recently is the one that overrides the other definitions. But it still won't move things between packages.

At 08:01 PM 11/2/2006, Charlie Adams wrote:

(I should explain first that we have published of all of the VW 7.4 code in our postgres database. This includes Base VW and many of the loose packages like the Debugger, Store, etc.)

 

If I want to modify a package overridden by the debugger, how do I do that without using overrides myself? I want to create a new version of the VW package but this will cause problems with the debugger's overrides in that same package. In fact, it will strip out the overridden method and assign it to the debugger package as an extension. This is an unintended consequence.

 

Charles Adams   

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Tuesday, November 07, 2006 12:38 PM

Subject: Re: Overrides

Phew. And please do let me know if you get it reproducible.

At 12:02 PM 11/7/2006, Charlie Adams wrote:

Alan,
 
Sorry to waste your time. I can no longer reproduce the results I was getting. If and when I can build a reproducible test case, I'll submit it.

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 8:45 PM

Subject: Re: Overrides

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 4:58 PM

Subject: Re: Overrides

At 04:35 PM 11/6/2006, Charlie Adams wrote:

I had overridden Process>>printOn: from Kernel-Processes in my own package.

 

I restored the original implementation and changed it in place instead. This gave me a new version of Kernel-Processes and no override of Process>>printOn:.

 

Debug-Support overrides ProcessorScheduler>>interruptActiveUserProcess -- also found in Kernel-Processes.

 

The act of versioning Kernel-Processes caused it (Kernel-Processes) to re-override ProcessorScheduler>>interruptActiveUserProcess. Now it looks like Kernel-Processes is overriding Debug-Support.

That's not what I see. I did exactly that, and the interruptActiveUserProcess method is still the same. It's in Debugger-Support, overriding Kernel-Processes. In general, I think it's unlikely that the act of publishing would re-arrange overrides within the image. The act of loading might.

I've tried reloading Debug-Support  and reversioning Debug-Support but it will not reassert its override. I know its out there. The library shows it implementing ProcessorScheduler>>interruptActiveUserProcess.

 

The attempt to version my bundle containing my version of Kernel-Processes threw up a dialog:

 

    One or more of the components in MyBundle overrides another. Publishing will cause one to replace the other when loading.

    It is recommend [sic] that you resolve these redundancies before publishing.

            Continue?

 

How do I resolve the redundancies? To be precise, I have not included Debugger-Support in my bundle. So, the first statement does not make sense to me. And, yes, this is only one example of many that I am dealing with at this time, as we have many overrides that I am trying to convert to straight up changes. I think this is a fairly isolated example and hope it is not being influenced by some other change I've made.

Ah, so this is not likely related to overriding in general, but specifically to overriding within bundles. Without knowing what your bundle structure is, it's hard to say.  However, a useful way of finding out what Store thinks the problem is is to hit control-Y when you get a dialog you don't understand, and go look at why it's telling you this.

 

What would the role of the bundle be here? As I said, Debugger-Support is not in my bundle. The original version of Kernel-Processes is not in my bundle. Only my new version of Kernel-Processes is in my bundle. I don't see how my bundle structure could be the problem.

 

I know what the dialog is telling me and I know what it is doing. My question is why or how can this be the correct behavior? I am in the middle of porting a customer. I do not have time to deal with problems like this.

 

----- Original Message -----

From: [hidden email]

To: [hidden email] ; [hidden email]

Sent: Monday, November 06, 2006 9:27 AM

Subject: Re: Overrides

I'm not sure what you mean. There should be no problem publishing into Store a package that has been overridden. If you want to modify a method which has been overridden, and publish that, then you would probably need to restore the overridden version while editing it. That's a bit painful, but still do-able.

It's possible that you're confusing publishing behaviour with loading behaviour. When you load a new version of a package or bundle that has been overridden, whichever thing was loaded most recently is the one that overrides the other definitions. But it still won't move things between packages.

At 08:01 PM 11/2/2006, Charlie Adams wrote:

(I should explain first that we have published of all of the VW 7.4 code in our postgres database. This includes Base VW and many of the loose packages like the Debugger, Store, etc.)

 

If I want to modify a package overridden by the debugger, how do I do that without using overrides myself? I want to create a new version of the VW package but this will cause problems with the debugger's overrides in that same package. In fact, it will strip out the overridden method and assign it to the debugger package as an extension. This is an unintended consequence.

 

Charles Adams   

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross