How does VW decide which method to load?
Locked
How does VW decide which method to load?
 
|
I'm struggling
with VW 7.3.1 method overrides. I have base GemStone code
stored in a package called GS_Globals. Other packages define methods that
override [replace] methods defined in GS_Globals. All the packages are usually
loaded from a single root bundle with GS_Globals sequenced before the
others. When the code is loaded, sometimes methods defined in GS_Globals "win"
and are considered overrides of methods that were intended to override the
methods in GS_Globals. I've messed with definitions in the "Overridden" tab to
get things cleaned up. I've republished several times once things seemed well.
Later things are screwed up again. Sometimes the overrides are correct after
reloading a couple times, but not always.
When two packages
define the same method, how does VW determine which is loaded in the image?
Right now it seems inconsistent. Why does reloading a few times sometimes
correct the situation? Are VW overrides somehow correct for different execution
contexts?
If it is truly as
random as it appears then I have a suggestion for loading the right method
definition most of the time. A method from a package that extends a class
should "win" over a method from a package that defines the class. If
there is more than one method definition from packages that do not define the
class then perhaps last-loaded should win. Can anybody point me to the VW code
that determines which method is loaded when there is a conflicting
definition?
|
Re: How does VW decide which method to load?
|
|
Paul Baumann wrote:
> I'm struggling with VW 7.3.1 method overrides. I have base GemStone code > stored in a package called GS_Globals. Other packages define methods > that override [replace] methods defined in GS_Globals. All the packages > are usually loaded from a single root bundle with GS_Globals sequenced > before the others. When the code is loaded, sometimes methods defined in > GS_Globals "win" and are considered overrides of methods that were > intended to override the methods in GS_Globals. I've messed with > definitions in the "Overridden" tab to get things cleaned up. I've > republished several times once things seemed well. Later things are > screwed up again. Sometimes the overrides are correct after reloading a > couple times, but not always. > > When two packages define the same method, how does VW determine which is > loaded in the image? Right now it seems inconsistent. Why does reloading > a few times sometimes correct the situation? Are VW overrides somehow > correct for different execution contexts? > > If it is truly as random as it appears then I have a suggestion for > loading the right method definition most of the time. A method from a > package that extends a class should "win" over a method from a package > that defines the class. If there is more than one method definition from > packages that do not define the class then perhaps last-loaded should > win. Can anybody point me to the VW code that determines which method is > loaded when there is a conflicting definition? > I *think* it's just "last loaded wins". This means that in order to get predictable behavior, you need to force a definite load order. We most often do that by putting packages in bundles in the desired load order, and never loading packages alone, but always loading the top-level bundle. It's possible that this isn't sufficient for all cases, but it has seemed to work for us. -Martin |
Re: How does VW decide which method to load?
|
|
In reply to this post by Paul Baumann
In general, it is "last loaded wins". However,
note that overrides within bundles (that is, packages within a bundle
overriding other packages within the same bundle) are not supported, and
you should be warned if attempting to publish with that situation (but
maybe not in 7.3.1, I'm not sure when that came in)).
Note that it is last loaded on a package basis. So, if you have a bundle, and you load a newer version in which only the first package is different, then that first package will be reloaded and will override anything else in the image, or in that bundle that defines the same thing. The planned rule is to be ordered by the first load of a package. So if you load A first, then B overrides it, then B will always be overriding A. This is plannedto be in 7.5.1. At 02:09 PM 2/12/2007, Paul Baumann wrote: I'm struggling with VW 7.3.1 method overrides. I have base GemStone code stored in a package called GS_Globals. Other packages define methods that override [replace] methods defined in GS_Globals. All the packages are usually loaded from a single root bundle with GS_Globals sequenced before the others. When the code is loaded, sometimes methods defined in GS_Globals "win" and are considered overrides of methods that were intended to override the methods in GS_Globals. I've messed with definitions in the "Overridden" tab to get things cleaned up. I've republished several times once things seemed well. Later things are screwed up again. Sometimes the overrides are correct after reloading a couple times, but not always. --
Alan Knight [|], Cincom Smalltalk Development
"The Static Typing Philosophy: Make it fast. Make it right.
Make it run." - Niall Ross
|
RE: How does VW decide which method to load?
|
|
In reply to this post by Martin McClure
Hi Martin,
It may be "last loaded wins" with some consideration of existing overrides (which can be screwed up). I've found that unloading code and reloading seems to straighten most of the overrides out. Only occasionally is a full sequential reload able to correct overrides of code that is already loaded--if it doesn't work the second attempt then it never does. The problem with unloading is that I'd have to unload most of the code in my image to get the overrides to load cleanly. I might as well reload into a clean image every time overrides get confused. It may have been loading individual package versions alone that screwed overrides up. If that is the problem then I'm wondering how I'd load other package versions to publish them into a new bundle version. It seems I'd have to always merge newer package code instead of loading it. I'm concerned that if I publish while overrides are loaded incorrectly then they'll remain screwed up later; maybe I should try it to see if it would publish correctly despite being loaded incorrectly. --Paul -----Original Message----- From: Martin McClure [mailto:[hidden email]] Sent: Monday, February 12, 2007 2:17 PM To: Paul Baumann Cc: VWNC, Subject: Re: How does VW decide which method to load? Importance: High ... I *think* it's just "last loaded wins". This means that in order to get predictable behavior, you need to force a definite load order. We most often do that by putting packages in bundles in the desired load order, and never loading packages alone, but always loading the top-level bundle. It's possible that this isn't sufficient for all cases, but it has seemed to work for us. -Martin -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
RE: How does VW decide which method to load?
|
|
In reply to this post by Alan Knight-2
>> From: Alan Knight [mailto:[hidden email]] >> Sent: Monday, February 12, 2007 2:52 PM >> >> In general, it is "last loaded wins". However, note that >> overrides within bundles (that is, packages within a bundle >> overriding other packages within the same bundle) are not >> supported, and you should be warned if attempting to publish >> with that situation (but maybe not in 7.3.1, I'm not sure >> when that came in)). That warning is in 7.3.1. I didn't think it was anything more than a "hey you might be doing something you didn't intend" kind of warning. I was hoping to turn that damn message off. I'd found that publishing with version-specific prerequisites had load problems so I tried a using using bundles to relate pundle versions--kind of like ENVY config maps. It seemed the "Base VisualWorks" bundle was an example of that being a good approach. If "overrides within bundles" are not supported then I'm back to figuring out a viable way to record version relationships while allowing load flexibility for publishing new versions. >> Note that it is last loaded on a package basis. So, if you >> have a bundle, and you load a newer version in which only >> the first package is different, then that first package will >> be reloaded and will override anything else in the image, or >> in that bundle that defines the same thing. That explains how it gets screwed up and how it can sometimes get repaired by reloading. Thank you. >> The planned rule is to be ordered by the first load of a package. >> So if you load A first, then B overrides it, then B will always >> be overriding A. This is plannedto be in 7.5.1. 7.5.1 seems a long way off for us. I'm hopeful it can be hacked until then. --Paul -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
RE: How does VW decide which method to load?
|
|
At 04:07 PM 2/12/2007, Paul Baumann wrote:
I'd found that publishing with version-specific prerequisites had load Well, in that respect, it pretty much does behave like ENVY config maps. Those would, by default, fail the load if methods were defined in one package. And if you set the option to enable loading, then it was again, last-loaded-wins, and re-loading packages that had been scratched by the loading of another package that defined the same method, then the newly loaded package would in turn scratch that one. --
Alan Knight [|], Cincom Smalltalk Development
"The Static Typing Philosophy: Make it fast. Make it right.
Make it run." - Niall Ross
|
RE: How does VW decide which method to load?
|
|
Interesting response Alan. True, VW fails to load duplicate
definitions in a way that is similar to how ENVY would. Of course there is
the notion that VW is supposed to support overrides were ENVY wasn't
designed to. Note that VW scratching the package is an
unanticipated modification where an override is more appropriate to
preserve image knowledge of the definition. You've said that VW isn't
designed to handle "overrides in bundles". It seems obvious that it should.
I'm glad to see an override fix is in progress.
I poked around in the VW code. Notable parts
were that Store.Bundle>>loadSrc catches RedefinitionNotifications and handles override
installs and that ClassDescription>>compile:notifying:attributes:selectorBlock:ifFail:
is most central to the method install. I didn't see that VW knew how
to convert an existing method into an override method and install the
loading method as an overridden method. Presumably that should be done when
the loading package [forcedPackage] defines the class of the method
involved in a redefinition. It looks like a
couple hour hack with challenges that could possibly stretch
a couple days. I need to focus effort
elsewhere.
Thanks for your help Alan.
Paul
Baumann IntercontinentalExchange | ICE <A title=mailto:chris.loonam@theice.com style="COLOR: #333333; TEXT-DECORATION: none" href="BLOCKED::mailto:paul.baumann@theice.com">paul.baumann@... From: Alan Knight [mailto:[hidden email]] Sent: Monday, February 12, 2007 6:22 PM To: Paul Baumann; VWNC, Subject: RE: How does VW decide which method to load? Importance: High I'd found that publishing with version-specific prerequisites had load Well, in that respect, it pretty much does behave like ENVY config maps. Those would, by default, fail the load if methods were defined in one package. And if you set the option to enable loading, then it was again, last-loaded-wins, and re-loading packages that had been scratched by the loading of another package that defined the same method, then the newly loaded package would in turn scratch that one. --
Alan Knight [|], Cincom Smalltalk Development
"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
Niall Ross
|
AW: How does VW decide which method to load?
|
|
Paul, Starting with VisualWorks
7.5 there will be a setting to allow overrides inside bundles. The help text
says: “Create Overrides in Bundles when Loading - The normal bundle
behaviour is to not allow packages in the bundle to override each other. The
system will warn the user if a bundle is being published with overrides, and on
load, the overrides will be treated as moves, using the definition in the last
package to be loaded. “If this setting is
turned on, then if two or more packages within the bundle define the same
thing, an override will be created, with the later-loaded package overriding
the earlier-loaded. “Note: With this
setting turned on, the order of overrides is *NOT* maintained. If packages are
re-loaded, either individually or as part of a bundle reload, then the newly
loaded packages can in turn override those loaded earlier. So a new version of
an overridden method can override the installed method in special cases. This
is the same behavior as if the packages were separate, and not contained in a
bundle. ObjectStudio 8 requires this setting to be on.” As is only a few weeks
until we all hope that 7.5 will be out of the door, stay tuned… Georg Georg Heeg eK, Dortmund
und Köthen, HR Dortmund A 12812 Von: Paul Baumann
[mailto:[hidden email]] Interesting response Alan. True, VW fails
to load duplicate definitions in a way that is similar to how ENVY would.
Of course there is the notion that VW is supposed to support overrides
were ENVY wasn't designed to. Note that VW scratching the package is an
unanticipated modification where an override is more appropriate to
preserve image knowledge of the definition. You've said that VW isn't
designed to handle "overrides in bundles". It seems obvious that it
should. I'm glad to see an override fix is in progress. I poked around in the VW code. Notable
parts were that Store.Bundle>>loadSrc catches
RedefinitionNotifications and handles override installs and that
ClassDescription>>compile:notifying:attributes:selectorBlock:ifFail: is
most central to the method install. I didn't see that VW knew how to
convert an existing method into an override method and install the loading
method as an overridden method. Presumably that should be done when the
loading package [forcedPackage] defines the class of the method involved
in a redefinition. It looks like a couple hour hack with challenges
that could possibly stretch a couple days. I need to focus
effort elsewhere. Thanks for your help Alan. Paul Baumann From:
Alan Knight [mailto:[hidden email]] At 04:07 PM 2/12/2007, Paul Baumann wrote: I'd found that publishing with version-specific prerequisites had load
-- Alan Knight [|], Cincom Smalltalk Development "The Static Typing Philosophy: Make it fast. Make it right. Make
it run." - Niall Ross
|
Re: How does VW decide which method to load?
|
|
In reply to this post by Paul Baumann
On Feb 12, 2007, at 10:07 PM, Paul Baumann wrote: > I'd found that publishing with version-specific prerequisites had load > problems so I tried a using using bundles to relate pundle > versions--kind of like ENVY config maps. It seemed the "Base > VisualWorks" bundle was an example of that being a good approach. If > "overrides within bundles" are not supported then I'm back to figuring > out a viable way to record version relationships while allowing load > flexibility for publishing new versions. You could try to automate managing these relationships using Configs and Lineups. This won't solve your override ordering problems though - it is just an alternative to bundles. http://www.cincomsmalltalk.com/userblogs/travis/blogView? showComments=true&entry=3265388740 Perhaps a better workaround is to create a post-processing tool: hand it a total ordering on the loaded packages (ie. as implied by a top level bundle or a Lineup) and it will reorder the overrides according to that order.... R - |
RE: How does VW decide which method to load?
|
|
In reply to this post by Georg Heeg
Georg,
Thanks for the notes for 7.5.
It is unfortunate that a (presumably) global setting
needs to be configured to load a specific unit of code. I hope the new setting
is ON by default in 7.5--to preserve knowledge of conflicting methods. I'm
thinking I should be able to load code and re-version it, and the new version
should be identical to the original. Any methods that had load conflicts
should make it to the new version--as released in the original version.
Under what circumstances would someone want the pre-7.5 behavior
of mangling code that is loaded [from a bundle]? If none, remove the
configuration option.
Alan said it won't be until 7.5.1 before VW
continues a to use the same override sequence that was first loaded. That
will give consistent override behavior as new package versions are loaded.
The combination of the 7.5 fix along with the 7.5.1 fix will probably do
the trick.
From: Georg Heeg [mailto:[hidden email]] Sent: Tuesday, February 13, 2007 2:32 AM To: Paul Baumann; 'Alan Knight'; 'VWNC,' Subject: AW: How does VW decide which method to load? Importance: High Paul, Starting with
VisualWorks 7.5 there will be a setting to allow overrides inside bundles. The
help text says: "Create Overrides in Bundles when Loading - The normal bundle
behaviour is to not allow packages in the bundle to override each other. The
system will warn the user if a bundle is being published with overrides, and on
load, the overrides will be treated as moves, using the definition in the last
package to be loaded. "If this setting is
turned on, then if two or more packages within the bundle define the same thing,
an override will be created, with the later-loaded package overriding the
earlier-loaded. "Note: With this
setting turned on, the order of overrides is *NOT* maintained. If packages are
re-loaded, either individually or as part of a bundle reload, then the newly
loaded packages can in turn override those loaded earlier. So a new version of
an overridden method can override the installed method in special cases. This is
the same behavior as if the packages were separate, and not contained in a
bundle. ObjectStudio 8 requires this setting to be
on." As is only a few weeks
until we all hope that 7.5 will be out of the door, stay
tuned. Georg Georg Heeg eK,
Dortmund und Köthen, HR Dortmund A 12812 Von: Paul
Baumann [mailto:[hidden email]] Interesting response
Alan. True, VW fails to load duplicate definitions in a way that is similar to
how ENVY would. Of course there is the notion that VW is supposed to
support overrides were ENVY wasn't designed to. Note that VW scratching the
package is an unanticipated modification where an override is more
appropriate to preserve image knowledge of the definition. You've said
that VW isn't designed to handle "overrides in bundles". It seems obvious
that it should. I'm glad to see an override fix is in
progress. I poked around in the
VW code. Notable parts were that Store.Bundle>>loadSrc catches
RedefinitionNotifications and handles override installs and that
ClassDescription>>compile:notifying:attributes:selectorBlock:ifFail: is
most central to the method install. I didn't see that VW knew how to
convert an existing method into an override method and install the loading
method as an overridden method. Presumably that should be done when the
loading package [forcedPackage] defines the class of the method involved in
a redefinition. It looks like a couple hour hack with challenges
that could possibly stretch a couple days. I need to focus effort
elsewhere. Thanks for your help
Alan. Paul
Baumann From: Alan Knight
[mailto:[hidden email]] At 04:07 PM 2/12/2007, Paul Baumann
wrote: I'd found that publishing with version-specific
prerequisites had load
-- Alan Knight [|], Cincom Smalltalk
Development "The Static Typing Philosophy: Make it fast. Make it
right. Make it run." - Niall Ross
|
AW: How does VW decide which method to load?
|
|
Paul, The default is set to backward
compatibility. We have used this setting (which is basically just a single line
of code in difference compared to 7.4.1 and before) set to ON throughout the
ObjectStudio 8 project without any issue, but in lengthy discussions we found a
test case with unwanted behaviour: You have a bundle B with
packages P1 and P2. And you have two versions of B: B v1 contains P1 v1 and
P2 v1. B v2 contains P1 v2 and
P2 v1. P1 v1 implements a
message m as ^1. P2 v1 implements a
message m as ^2. P1 v2 implements a
message m as ^3. You set Allow overrided
to ON: Now you load B v1 from
scratch. You will get m (^2) as override of m (^1). You unload B v1 Now you load B v2 from
scratch. You will get m (^2) as override of m (^3). But if you Now you load B v1 from
scratch. You will get m (^2) as override of m (^1). Now you load B v2 over B
v1. You will get m (^3) as override of m (^2). You set Allow overrided
to OFF: Now you load B v1 from
scratch. You will get m (^2) and m (^1) deleted silently. You unload B v1 Now you load B v2 from
scratch. You will get m (^2) and m (^3) deleted silently. And if you Now you load B v1 from
scratch. You will get m (^2) and m (^1) deleted silently. Now you load B v2 over B
v1. You will get m (^2) and m (^3) deleted silently. We never had this
situation in practical life. So we were much better off setting the switch to
ON. There one line change
which also works in 7.4 and 7.4.1 that hardcodes this behavior in
Bundle>>loadSrc: Instead of [
:note | ( leafNames includes: note currentPackage name ) Try: [
:note | (self name = note currentPackage name) Georg Georg Heeg eK, Dortmund
und Köthen, HR Dortmund A 12812 Von: Paul Baumann
[mailto:[hidden email]] Georg, Thanks for the notes for 7.5. It is unfortunate that a (presumably)
global setting needs to be configured to load a specific unit of code. I hope
the new setting is ON by default in 7.5--to preserve knowledge of conflicting
methods. I'm thinking I should be able to load code and re-version it, and the
new version should be identical to the original. Any methods that had load
conflicts should make it to the new version--as released in the original
version. Under what circumstances would someone want the pre-7.5 behavior
of mangling code that is loaded [from a bundle]? If none, remove the configuration
option. Alan said it won't be
until 7.5.1 before VW continues a to use the same override sequence that
was first loaded. That will give consistent override behavior as new
package versions are loaded. The combination of the 7.5 fix along with the
7.5.1 fix will probably do the trick. Paul Baumann From:
Georg Heeg [mailto:[hidden email]] Paul, Starting with VisualWorks
7.5 there will be a setting to allow overrides inside bundles. The help text
says: "Create Overrides in Bundles when Loading - The normal bundle
behaviour is to not allow packages in the bundle to override each other. The
system will warn the user if a bundle is being published with overrides, and on
load, the overrides will be treated as moves, using the definition in the last
package to be loaded. "If this setting is
turned on, then if two or more packages within the bundle define the same
thing, an override will be created, with the later-loaded package overriding
the earlier-loaded. "Note: With this
setting turned on, the order of overrides is *NOT* maintained. If packages are
re-loaded, either individually or as part of a bundle reload, then the newly loaded
packages can in turn override those loaded earlier. So a new version of an
overridden method can override the installed method in special cases. This is
the same behavior as if the packages were separate, and not contained in a
bundle. ObjectStudio 8 requires this setting to be on." As is only a few weeks
until we all hope that 7.5 will be out of the door, stay tuned. Georg Georg Heeg eK, Dortmund
und Köthen, HR Dortmund A 12812 Von: Paul Baumann
[mailto:[hidden email]] Interesting response Alan. True, VW fails
to load duplicate definitions in a way that is similar to how ENVY would.
Of course there is the notion that VW is supposed to support overrides
were ENVY wasn't designed to. Note that VW scratching the package is an
unanticipated modification where an override is more appropriate to
preserve image knowledge of the definition. You've said that VW isn't designed
to handle "overrides in bundles". It seems obvious that it
should. I'm glad to see an override fix is in progress. I poked around in the VW code. Notable
parts were that Store.Bundle>>loadSrc catches
RedefinitionNotifications and handles override installs and that
ClassDescription>>compile:notifying:attributes:selectorBlock:ifFail: is
most central to the method install. I didn't see that VW knew how to
convert an existing method into an override method and install the loading
method as an overridden method. Presumably that should be done when the
loading package [forcedPackage] defines the class of the method involved
in a redefinition. It looks like a couple hour hack with challenges
that could possibly stretch a couple days. I need to focus
effort elsewhere. Thanks for your help Alan. Paul Baumann From:
Alan Knight [mailto:[hidden email]] At 04:07 PM 2/12/2007, Paul Baumann wrote: I'd found that publishing with version-specific prerequisites had load
-- Alan Knight [|], Cincom Smalltalk Development "The Static Typing Philosophy: Make it fast. Make it right. Make
it run." - Niall Ross
|
RE: How does VW decide which method to load?
|
|
I've experienced the deleted methods scenario--it is the
only option in 7.3.1. When code was loaded a second time then the deleted
methods are restored as overrides--and the code that should be an
override is now overridden. It makes it really difficult to create a
new version of code when you can't get it loaded properly into your image and
you can't configure unloaded bundles. The overrides need to be redone to
get the image in a good state to version--and then you have to reversion code
that you didn't really want to change so that the top bundle can be
versioned.
The scenario you've presented is good at showing how
having "allow overrided" set ON can give inconsistent
results while the traditional way gives consistent results [for that scenario]
whether you are loading or reloading. The scenario I just presented shows
that even the traditional way can give inconsistent load results. I'm
thinking the new override continuance feature of 7.5.1 will make the
traditional way completely obsolete. I hope the option to turn OFF "allow
overrided" can go away once 7.5.1 is released. I appreciate the explanation
for why the setting seemed relevant for 7.5.
Thanks
for passing along that change. I can see how it would retain more existing
methods as overrides instead of replacing them. At least an override
can be managed where lost code can not. I may give that a
try.
From: Georg Heeg [mailto:[hidden email]] Sent: Tuesday, February 13, 2007 11:59 AM To: Paul Baumann; 'Alan Knight'; 'VWNC,' Subject: AW: How does VW decide which method to load? Importance: High Paul, The default is set to
backward compatibility. We have used this setting (which is basically just a
single line of code in difference compared to 7.4.1 and before) set to ON
throughout the ObjectStudio 8 project without any issue, but in lengthy
discussions we found a test case with unwanted
behaviour: You have a bundle B
with packages P1 and P2. And you have two versions of
B: B v1 contains P1 v1 and
P2 v1. B v2 contains P1 v2 and
P2 v1. P1 v1 implements a
message m as ^1. P2 v1 implements a
message m as ^2. P1 v2 implements a
message m as ^3. You set Allow overrided
to ON: Now you load B v1 from
scratch. You will get m (^2) as override of m (^1). You unload B
v1 Now you load B v2 from
scratch. You will get m (^2) as override of m (^3). But if you
Now you load B v1 from
scratch. You will get m (^2) as override of m (^1). Now you load B v2 over
B v1. You will get m (^3) as override of m (^2). You set Allow overrided
to OFF: Now you load B v1 from
scratch. You will get m (^2) and m (^1) deleted
silently. You unload B
v1 Now you load B v2 from
scratch. You will get m (^2) and m (^3) deleted
silently. And if you
Now you load B v1 from
scratch. You will get m (^2) and m (^1) deleted
silently. Now you load B v2 over
B v1. You will get m (^2) and m (^3) deleted
silently. We never had this
situation in practical life. So we were much better off setting the switch to
ON. There one line change
which also works in 7.4 and 7.4.1 that hardcodes this behavior in
Bundle>>loadSrc: Instead
of
[ :note | ( leafNames includes: note currentPackage name
) Try:
[ :note | (self name = note currentPackage name) Georg Georg Heeg eK,
Dortmund und Köthen, HR Dortmund A 12812 Von: Paul
Baumann [mailto:[hidden email]] Georg, Thanks for the notes
for 7.5. It is unfortunate
that a (presumably) global setting needs to be configured to load a
specific unit of code. I hope the new setting is ON by default in 7.5--to
preserve knowledge of conflicting methods. I'm thinking I should be able to load
code and re-version it, and the new version should be identical to the original.
Any methods that had load conflicts should make it to the new version--as
released in the original version. Under what circumstances would someone want
the pre-7.5 behavior of mangling code that is loaded [from a bundle]? If
none, remove the configuration option. Alan said it won't
be until 7.5.1 before VW continues a to use the same override sequence that
was first loaded. That will give consistent override behavior as new
package versions are loaded. The combination of the 7.5 fix along with the
7.5.1 fix will probably do the trick. Paul
Baumann From: Georg Heeg [mailto:[hidden email]]
Paul, Starting with
VisualWorks 7.5 there will be a setting to allow overrides inside bundles. The
help text says: "Create Overrides in Bundles when Loading - The normal bundle
behaviour is to not allow packages in the bundle to override each other. The
system will warn the user if a bundle is being published with overrides, and on
load, the overrides will be treated as moves, using the definition in the last
package to be loaded. "If this setting is
turned on, then if two or more packages within the bundle define the same thing,
an override will be created, with the later-loaded package overriding the
earlier-loaded. "Note: With this
setting turned on, the order of overrides is *NOT* maintained. If packages are
re-loaded, either individually or as part of a bundle reload, then the newly
loaded packages can in turn override those loaded earlier. So a new version of
an overridden method can override the installed method in special cases. This is
the same behavior as if the packages were separate, and not contained in a
bundle. ObjectStudio 8 requires this setting to be
on." As is only a few weeks
until we all hope that 7.5 will be out of the door, stay
tuned. Georg Georg Heeg eK,
Dortmund und Köthen, HR Dortmund A
12812 Von: Paul
Baumann [mailto:[hidden email]] Interesting response
Alan. True, VW fails to load duplicate definitions in a way that is similar to
how ENVY would. Of course there is the notion that VW is supposed to
support overrides were ENVY wasn't designed to. Note that VW scratching the
package is an unanticipated modification where an override is more
appropriate to preserve image knowledge of the definition. You've said
that VW isn't designed to handle "overrides in bundles". It seems obvious
that it should. I'm glad to see an override fix is in
progress. I poked around in the
VW code. Notable parts were that Store.Bundle>>loadSrc catches
RedefinitionNotifications and handles override installs and that
ClassDescription>>compile:notifying:attributes:selectorBlock:ifFail: is
most central to the method install. I didn't see that VW knew how to
convert an existing method into an override method and install the loading
method as an overridden method. Presumably that should be done when the
loading package [forcedPackage] defines the class of the method involved in
a redefinition. It looks like a couple hour hack with challenges
that could possibly stretch a couple days. I need to focus effort
elsewhere. Thanks for your help
Alan. Paul
Baumann From: Alan Knight
[mailto:[hidden email]] At 04:07 PM 2/12/2007, Paul Baumann
wrote: I'd found that publishing with version-specific
prerequisites had load
-- Alan Knight [|], Cincom Smalltalk
Development "The Static Typing Philosophy: Make it fast. Make it
right. Make it run." - Niall
Ross
|
| Free forum by Nabble | Edit this page |