Has anyone else seen
this?
PkgExt_A has methods
that extend classes defined by PkgDef. I moved the methods from PkgExt_A to
PkgExt_B and published those changes. Everything looked fine in my image.
However, when loaded into another image, from a bundle version that
includes new versions of all three packages mentioned, the new image still
had *most* of the methods in PkgExt_A; PkgExt_B only contained a few of the
methods moved to it.
I moved the methods
a second time and published again. This time, when loaded into another image,
the methods appear in PkgDef as red (implying override) but when you click on
the method it shows black and doesn't have an override tab. After the the first
click, the methods appear as defined by PkgDef as if they'd been there all
along--which they were not.
Browsing the version
of the PkgDef in StORE confirms that the moved code is not truly in PkgDef.
Browsing the version of PkgExt_B shows the methods truly were moved (and
published). Browsing versions of PkgExt_A shows the methods no longer exist
there.
In short, code
definitions moved in one image don't re-load properly in other images; they
associate with the wrong package after being
re-loaded.
Paul Baumann
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. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Were you loading these into a clean other image, or into an
image in which the methods were in the previous arrangement?
At 05:02 PM 3/10/2008, Paul Baumann wrote: Content-Transfer-Encoding: 7bitHas anyone else seen this? PkgExt_A has methods that extend classes defined by PkgDef. I moved the methods from PkgExt_A to PkgExt_B and published those changes. Everything looked fine in my image. However, when loaded into another image, from a bundle version that includes new versions of all three packages mentioned, the new image still had *most* of the methods in PkgExt_A; PkgExt_B only contained a few of the methods moved to it. I moved the methods a second time and published again. This time, when loaded into another image, the methods appear in PkgDef as red (implying override) but when you click on the method it shows black and doesn't have an override tab. After the the first click, the methods appear as defined by PkgDef as if they'd been there all along--which they were not. Browsing the version of the PkgDef in StORE confirms that the moved code is not truly in PkgDef. Browsing the version of PkgExt_B shows the methods truly were moved (and published). Browsing versions of PkgExt_A shows the methods no longer exist there. In short, code definitions moved in one image don't re-load properly in other images; they associate with the wrong package after being re-loaded. Paul Baumann 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. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --
Alan Knight [|], Cincom Smalltalk Development
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Paul Baumann
The new versions were loaded into an image that
already had the 'previous arrangement' loaded. The new package versions
were loaded by way of a new bundle version that was loaded.
Paul Baumann
From: Alan Knight [mailto:[hidden email]] Sent: Monday, March 10, 2008 5:18 PM To: Paul Baumann; VWNC Subject: Re: [vwnc] [vw7.5] Moving code between packages Importance: High At 05:02 PM 3/10/2008, Paul Baumann wrote: Content-Transfer-Encoding: 7bitHas anyone else seen this? PkgExt_A has methods that extend classes defined by PkgDef. I moved the methods from PkgExt_A to PkgExt_B and published those changes. Everything looked fine in my image. However, when loaded into another image, from a bundle version that includes new versions of all three packages mentioned, the new image still had *most* of the methods in PkgExt_A; PkgExt_B only contained a few of the methods moved to it. I moved the methods a second time and published again. This time, when loaded into another image, the methods appear in PkgDef as red (implying override) but when you click on the method it shows black and doesn't have an override tab. After the the first click, the methods appear as defined by PkgDef as if they'd been there all along--which they were not. Browsing the version of the PkgDef in StORE confirms that the moved code is not truly in PkgDef. Browsing the version of PkgExt_B shows the methods truly were moved (and published). Browsing versions of PkgExt_A shows the methods no longer exist there. In short, code definitions moved in one image don't re-load properly in other images; they associate with the wrong package after being re-loaded. Paul Baumann 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. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --
Alan Knight [|], Cincom Smalltalk Development
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. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |