Dear all
[Squeak 4.4] I just found that Monticello injects #workingCopy into Class like this
Class>>#workingCopy
^ self packageInfo workingCopy
However, #workingCopy is defined neither on Class/Behavior etc nor on Object. What was the intended behavior?
Best -Tobias
On 2 April 2013 10:38, Tobias Pape Das.Linux@gmx.de wrote:
Dear all
[Squeak 4.4] I just found that Monticello injects #workingCopy into Class like this
Class>>#workingCopy
^ self packageInfo workingCopyHowever, #workingCopy is defined neither on Class/Behavior etc nor on Object. What was the intended behavior?
Do you mean #packageInfo instead of #workingCopy?
frank
Best -Tobias
Am 02.04.2013 um 12:51 schrieb Frank Shearar frank.shearar@gmail.com:
On 2 April 2013 10:38, Tobias Pape Das.Linux@gmx.de wrote:
Dear all
[Squeak 4.4] I just found that Monticello injects #workingCopy into Class like this
Class>>#workingCopy
^ self packageInfo workingCopy
However, #workingCopy is defined neither on Class/Behavior etc nor on Object. What was the intended behavior?
Do you mean #packageInfo instead of #workingCopy?
yes
Best -Tobias
Did you get your question answered? If not, please clarify..
On Tue, Apr 2, 2013 at 6:33 AM, Tobias Pape Das.Linux@gmx.de wrote:
Am 02.04.2013 um 12:51 schrieb Frank Shearar frank.shearar@gmail.com:
On 2 April 2013 10:38, Tobias Pape Das.Linux@gmx.de wrote:
Dear all
[Squeak 4.4] I just found that Monticello injects #workingCopy into Class like this
Class>>#workingCopy
^ self packageInfo workingCopy
However, #workingCopy is defined neither on Class/Behavior etc nor on Object. What was the intended behavior?
Do you mean #packageInfo instead of #workingCopy?
yes
Best -Tobias
Hey Chris, hey list
Am 02.04.2013 um 19:51 schrieb Chris Muller asqueaker@gmail.com:
Did you get your question answered? If not, please clarify..
No I did not.
Suppose, you execute TestRunner workingCopy you get a NMU of TestRunner class dNU #packageInfo
The same holds for MethodReference: (MethodReference class: TestRunner selector: #runAll) workingCopy
#workingCopy is injected by the Monticello Package.
My Question:
Is the relatively new (2011) #workingCopy on Class and MethodReference just implemented wrongly or is something wrong with PackageInfo?
Best -Tobias
On 02.04.2013, at 22:46, Tobias Pape Das.Linux@gmx.de wrote:
Hey Chris, hey list
Am 02.04.2013 um 19:51 schrieb Chris Muller asqueaker@gmail.com:
Did you get your question answered? If not, please clarify..
No I did not.
Suppose, you execute TestRunner workingCopy you get a NMU of TestRunner class dNU #packageInfo
The same holds for MethodReference: (MethodReference class: TestRunner selector: #runAll) workingCopy
#workingCopy is injected by the Monticello Package.
My Question:
Is the relatively new (2011) #workingCopy on Class and MethodReference just implemented wrongly or is something wrong with PackageInfo?
Best -Tobias
This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
IMNSHO the #workingCopy method should be removed. It's not used in the system yet, fortunately.
- Bert -
This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
(Why such strong words?) A class can only be defined in one package, just as in Monticello, and this method simply associates its MC equivalent to PackageInfo domain objects. Why do you say a class can belong to multiple packages -- because of extensions?
IMNSHO the #workingCopy method should be removed. It's not used in the system yet, fortunately.
It's used by external utilities for automating the building of .sar packages which should be included in the system.
On Wed, Apr 3, 2013 at 11:37 AM, Chris Muller asqueaker@gmail.com wrote:
This "feature" is misguided because a class can belong to multiple
packages. So asking a class for its single package info is wrong.
(Why such strong words?) A class can only be defined in one package, just as in Monticello, and this method simply associates its MC equivalent to PackageInfo domain objects. Why do you say a class can belong to multiple packages -- because of extensions?
A class *can* be part of multiple packages.
Imagine you have two packages, 'Foo' and 'Foo-Bar'. All the classes that belong to 'Foo-Bar' are also part of 'Foo'.
Colin
Doing that causes issues and confusion -- for example changing a method in the Foo-Bar package means both the Foo package and Foo-Bar packages are dirty.
By my understanding this is why most folks append suffixes to their package names like "-Core". That way, you have "Foo-Core" and "Foo-Bar" and "Foo-UI", etc. Three packages, no overlap, no ambiguity. Simple.
Do we have any examples today of methods/classes belonging to multiple packages today?
On Wed, Apr 3, 2013 at 2:01 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Apr 3, 2013 at 11:37 AM, Chris Muller asqueaker@gmail.com wrote:
This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
(Why such strong words?) A class can only be defined in one package, just as in Monticello, and this method simply associates its MC equivalent to PackageInfo domain objects. Why do you say a class can belong to multiple packages -- because of extensions?
A class *can* be part of multiple packages.
Imagine you have two packages, 'Foo' and 'Foo-Bar'. All the classes that belong to 'Foo-Bar' are also part of 'Foo'.
Colin
On 03.04.2013, at 12:07, Chris Muller asqueaker@gmail.com wrote:
Doing that causes issues and confusion -- for example changing a method in the Foo-Bar package means both the Foo package and Foo-Bar packages are dirty.
By my understanding this is why most folks append suffixes to their package names like "-Core". That way, you have "Foo-Core" and "Foo-Bar" and "Foo-UI", etc. Three packages, no overlap, no ambiguity. Simple.
Do we have any examples today of methods/classes belonging to multiple packages today?
Yes. E.g., there are some projects that provide both separate "hyphen-packages" and one "combined" package. The former is better for development, the latter simpler for users. Balloon3D is an example.
Also, OMeta uses custom package infos for bootstrapping. You have two package infos for the very same classes and methods.
- Bert -
On Wed, Apr 3, 2013 at 2:01 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Apr 3, 2013 at 11:37 AM, Chris Muller asqueaker@gmail.com wrote:
This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
(Why such strong words?) A class can only be defined in one package, just as in Monticello, and this method simply associates its MC equivalent to PackageInfo domain objects. Why do you say a class can belong to multiple packages -- because of extensions?
A class *can* be part of multiple packages.
Imagine you have two packages, 'Foo' and 'Foo-Bar'. All the classes that belong to 'Foo-Bar' are also part of 'Foo'.
Colin
On 03.04.2013, at 11:37, Chris Muller asqueaker@gmail.com wrote:
This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
(Why such strong words?)
Sorry, I didn't want to sound offensive.
A class can only be defined in one package,
That is exactly the misconception I wanted to point out.
just as in Monticello, and this method simply associates its MC equivalent to PackageInfo domain objects. Why do you say a class can belong to multiple packages -- because of extensions?
A class is included in all packages that answer true to includesClass:. For example, even with the default PackageInfo a class would be in both "Foo-Bar" and "Foo".
IMNSHO the #workingCopy method should be removed. It's not used in the system yet, fortunately.
It's used by external utilities for automating the building of .sar packages which should be included in the system.
As I wrote in the other message (too bad discussion threads are constantly broken), the code should be written to deal with zero, one, or more packages containing the class. Possibly it should raise an error if more than one package includes the class. Monticello itself avoids this problem by always starting from the package/working copy instead from a class, and IMHO this is a good general principle.
- Bert -
On Wed, Apr 3, 2013 at 2:07 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 03.04.2013, at 11:37, Chris Muller asqueaker@gmail.com wrote:
This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
(Why such strong words?)
Sorry, I didn't want to sound offensive.
A class can only be defined in one package,
That is exactly the misconception I wanted to point out.
Ok, lets talk specifics. In a recent trunk image:
Smalltalk allClasses select: [ : eachClass | (PackageInfo allPackages count: [ : eachInfo | eachInfo includesClass: eachClass ])>1]
---> "{MCMockClassH . MCMockClassD . MCMockClassB . MCMockClassE . MCMockClassA . MCMockASubclass . MCMockClassF . MCMockClassG . MCMockClassI}"
Clearly, these "Mock" classes are a special case that occurs because, back in 2004, Avi defined his own PackageInfo subclass (something you once said you disagree with). Even to this day, there is not agreement about the semantics of PackageInfo but I'd bet we could find a way to "fix" this special-case (not that anyone would notice even if we didn't).
So, we don't have any good examples in the image, what is the reason any external packages would want to do it? You mentioned Balloon-3D -- it happens our package is named "Balloon" why shouldn't it be "Balloon-Core" and "Balloon-3D"? I don't know about OMeta -- might be another special-case..? Why does it want a class to belong in two PackageInfos?
just as in Monticello, and this method simply associates its MC equivalent to PackageInfo domain objects. Why do you say a class can belong to multiple packages -- because of extensions?
A class is included in all packages that answer true to includesClass:. For example, even with the default PackageInfo a class would be in both "Foo-Bar" and "Foo".
IMNSHO the #workingCopy method should be removed. It's not used in the system yet, fortunately.
It's used by external utilities for automating the building of .sar packages which should be included in the system.
As I wrote in the other message (too bad discussion threads are constantly broken), the code should be written to deal with zero, one, or more packages containing the class. Possibly it should raise an error if more than one package includes the class. Monticello itself avoids this problem by always starting from the package/working copy instead from a class, and IMHO this is a good general principle.
- Bert -
If I'm asking why a class should belong in two PackageInfos it's only fair I answer why it shouldn't: Because by the PackageInfo domain model mirroring MC's model, they are able to work together better. For example, the use-case I cited previously was one-click building .sar packages (MaSarPackage on SqueakMap). Utilities like that are much easier to build and maintain when the cardinalities between the models match.
On Wed, Apr 3, 2013 at 2:18 PM, Chris Muller asqueaker@gmail.com wrote:
On Wed, Apr 3, 2013 at 2:07 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 03.04.2013, at 11:37, Chris Muller asqueaker@gmail.com wrote:
This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
(Why such strong words?)
Sorry, I didn't want to sound offensive.
A class can only be defined in one package,
That is exactly the misconception I wanted to point out.
Ok, lets talk specifics. In a recent trunk image:
Smalltalk allClasses select: [ : eachClass | (PackageInfoallPackages count: [ : eachInfo | eachInfo includesClass: eachClass ])>1]
---> "{MCMockClassH . MCMockClassD . MCMockClassB . MCMockClassE . MCMockClassA . MCMockASubclass . MCMockClassF . MCMockClassG . MCMockClassI}"
Clearly, these "Mock" classes are a special case that occurs because, back in 2004, Avi defined his own PackageInfo subclass (something you once said you disagree with). Even to this day, there is not agreement about the semantics of PackageInfo but I'd bet we could find a way to "fix" this special-case (not that anyone would notice even if we didn't).
So, we don't have any good examples in the image, what is the reason any external packages would want to do it? You mentioned Balloon-3D -- it happens our package is named "Balloon" why shouldn't it be "Balloon-Core" and "Balloon-3D"? I don't know about OMeta -- might be another special-case..? Why does it want a class to belong in two PackageInfos?
just as in Monticello, and this method simply associates its MC equivalent to PackageInfo domain objects. Why do you say a class can belong to multiple packages -- because of extensions?
A class is included in all packages that answer true to includesClass:. For example, even with the default PackageInfo a class would be in both "Foo-Bar" and "Foo".
IMNSHO the #workingCopy method should be removed. It's not used in the system yet, fortunately.
It's used by external utilities for automating the building of .sar packages which should be included in the system.
As I wrote in the other message (too bad discussion threads are constantly broken), the code should be written to deal with zero, one, or more packages containing the class. Possibly it should raise an error if more than one package includes the class. Monticello itself avoids this problem by always starting from the package/working copy instead from a class, and IMHO this is a good general principle.
- Bert -
On Wed, Apr 3, 2013 at 12:37 PM, Chris Muller asqueaker@gmail.com wrote:
If I'm asking why a class should belong in two PackageInfos it's only fair I answer why it shouldn't: Because by the PackageInfo domain model mirroring MC's model, they are able to work together better. For example, the use-case I cited previously was one-click building .sar packages (MaSarPackage on SqueakMap). Utilities like that are much easier to build and maintain when the cardinalities between the models match.
A class can belong to more than one Monticello package too.
Colin
If I'm asking why a class should belong in two PackageInfos it's only fair I answer why it shouldn't: Because by the PackageInfo domain model mirroring MC's model, they are able to work together better. For example, the use-case I cited previously was one-click building .sar packages (MaSarPackage on SqueakMap). Utilities like that are much easier to build and maintain when the cardinalities between the models match.
A class can belong to more than one Monticello package too.
By "belong to" I assume you mean "defined in". Even still, "could" does mean "should". Again, I ask for practical usage-scenarios where this is helpful -- in fact, you might start with why is it /not detrimental/?
The prior example about being detrimental was ignored -- If you have package "Foo" and package "Foo-Bar" and make a change to a method in Foo-Bar, you now have two dirty packages. Which one are you gonna save? Which one are you gonna load? They're stepping on each other so what normal use-case is this?
My goal w.r.t. this issue is to have a simple, practical model useful for connecting Monticello elements with their in-image counterparts. What's yours?
On Wed, Apr 03, 2013 at 05:55:14PM -0500, Chris Muller wrote:
If I'm asking why a class should belong in two PackageInfos it's only fair I answer why it shouldn't: Because by the PackageInfo domain model mirroring MC's model, they are able to work together better. For example, the use-case I cited previously was one-click building .sar packages (MaSarPackage on SqueakMap). Utilities like that are much easier to build and maintain when the cardinalities between the models match.
A class can belong to more than one Monticello package too.
By "belong to" I assume you mean "defined in". Even still, "could" does mean "should". Again, I ask for practical usage-scenarios where this is helpful -- in fact, you might start with why is it /not detrimental/?
My practical use case is that I have a package called OSProcess that I have been maintaining for many years. The package can logically be split into a number of sub-packages (OSProcess-Base, OSProcess-Unix, etc). At some point in the past I managed to convince myself that it would be a good idea to split OSProcess into sub-packages because I thought that this would be "more modular". So I did that, and now I have lots of very modular looking packages. But I also kept the original OSProcess package, because it turned out that in real life nobody cared about the sub-packages, and it ended up being a big pain to keep track of all the versions of sub-packages when most people just wanted to load OSProcess, and for me maintaining the package the only thing I cared about was "what version of OSProcess do you have installed that is causing a problem."
In a perfect world, people would not make strategic blunders like this. But I am not perfect, so now I have classes that are part of both the OSProcess package and the OSProcess-Base package. I regret the mistake, but I am happy that the tools do not prevent me from managing my way through its consequences. For people who use OSProcess, nobody even seems to have noticed the mess. They just load it from SqueakMap or ConfigurationOfOSProcess and something that works gets installed.
So for me it is important that a class can belong to more than one package.
Dave
On Wed, Apr 3, 2013 at 4:36 PM, David T. Lewis lewis@mail.msen.com wrote:
So for me it is important that a class can belong to more than one package.
Me too. I've used this feature while splitting monolithic packages into multiple packages that can be loaded independently, not to manage a mistake, but to make the process easier as I went.
I've also used it when developing tools like Monticello and OmniBrowser. The tests inevitably involve making code changes, and I've found it handy to have a sub-package containing only those bogus classes that get changed by the tests. When things don't get cleaned up properly because of broken tests or tools, I can fix things by just loading the sub-package to revert all changes.
Colin
In Dave's case, I'm wondering whether simply renaming OSProcess-Base et al back to OSProcess would be appropriate.
In Colin's case, it wasn't clear to me how the 1:many cardinality helps -- e.g., whether the packages are OmniBrowser-Core + OmniBrowser-TestFixtures (2 distinct packages) or just OmniBrowser + OmniBrowser-TestFixtures (a hierarchy of 2 packages); under either case the fact of the broken OB code leaves a dirty OmniBrowser-TestFixtures package is still the same solution -- reloading OmniBrowser-TestFixtures. The only difference I see is that OmniBrowser package would report dirty too, even if it wasn't, just by having run the tests.
So I remain skeptical but it seems I'm outvoted. Thank you for discussing it nonetheless -- some of our best decisions as a community were because of good discussions.
On Thu, Apr 4, 2013 at 11:44 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Apr 3, 2013 at 4:36 PM, David T. Lewis lewis@mail.msen.com wrote:
So for me it is important that a class can belong to more than one package.
Me too. I've used this feature while splitting monolithic packages into multiple packages that can be loaded independently, not to manage a mistake, but to make the process easier as I went.
I've also used it when developing tools like Monticello and OmniBrowser. The tests inevitably involve making code changes, and I've found it handy to have a sub-package containing only those bogus classes that get changed by the tests. When things don't get cleaned up properly because of broken tests or tools, I can fix things by just loading the sub-package to revert all changes.
Colin
You mean "String workingCopy" throws a DNU but should not?
-- Marcel
-- View this message in context: http://forum.world.st/Monticello-and-PackageInfo-tp4679280p4679341.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Looks like it got broken sometime during the 4.4 release..
On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel < marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
You mean "String workingCopy" throws a DNU but should not?
-- Marcel
-- View this message in context: http://forum.world.st/Monticello-and-PackageInfo-tp4679280p4679341.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
That works in 4.3, but not 4.4.
On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel < marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
You mean "String workingCopy" throws a DNU but should not?
-- Marcel
-- View this message in context: http://forum.world.st/Monticello-and-PackageInfo-tp4679280p4679341.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Am 03.04.2013 um 03:05 schrieb Chris Muller asqueaker@gmail.com:
That works in 4.3, but not 4.4.
On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel marcel.taeumel@student.hpi.uni-potsdam.de wrote: You mean "String workingCopy" throws a DNU but should not?
-- Marcel
I have 'bisected' and the #workingCopy was introduced in 2011:
Name: Monticello-cmm.436 Time: 10 March 2011, 1:46:11.144 pm
- Added several methods for tracing MethodReferences and Classes back to their MC counterparts; their #workingCopy, and #repositoryGroup. - Ability to convert MethodReferences to equivalent MCMethodDefinitions, and classes to MCClassDefinitions. - Added MCRepository>>allVersionsDo:.
Chris, what PackageInfo do you have that injects #packageInfo into Class and MethodReference? I've looked in several images and repositories and cannot find a PackageInfo that provides those :/
Best -Tobias
Hi Tobias, ok, I understand what you mean by "injected" -- you mean "extended". :) When a package adds a method to a class defined in another package, the first is said to "extend" the second.
I looked more closely and found that I have extended Class with the following method:
packageInfo ^ PackageInfo allPackages detect: [ : each | each includesClass: self ] ifNone: [ nil ]
We should include this in the base image.
Also #workingCopy should be changed to handle the possibility of it returning nil.
On Wed, Apr 3, 2013 at 1:28 AM, Tobias Pape Das.Linux@gmx.de wrote:
Am 03.04.2013 um 03:05 schrieb Chris Muller asqueaker@gmail.com:
That works in 4.3, but not 4.4.
On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel <
marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
You mean "String workingCopy" throws a DNU but should not?
-- Marcel
I have 'bisected' and the #workingCopy was introduced in 2011:
Name: Monticello-cmm.436 Time: 10 March 2011, 1:46:11.144 pm
- Added several methods for tracing MethodReferences and Classes back to
their MC counterparts; their #workingCopy, and #repositoryGroup.
- Ability to convert MethodReferences to equivalent MCMethodDefinitions,
and classes to MCClassDefinitions.
- Added MCRepository>>allVersionsDo:.
Chris, what PackageInfo do you have that injects #packageInfo into Class and MethodReference? I've looked in several images and repositories and cannot find a PackageInfo that provides those :/
Best -Tobias
I think we should rather add this code:
Class>>packageInfo ^ PackageOrganizer default packageOfClass: self
Best, Marcel
-- View this message in context: http://forum.world.st/Monticello-and-PackageInfo-tp4679280p4679431.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 03.04.2013, at 07:40, Chris Muller asqueaker@gmail.com wrote:
Hi Tobias, ok, I understand what you mean by "injected" -- you mean "extended". :) When a package adds a method to a class defined in another package, the first is said to "extend" the second.
I looked more closely and found that I have extended Class with the following method:
packageInfo ^ PackageInfo allPackages detect: [ : each | each includesClass: self ] ifNone: [ nil ]
We should include this in the base image.
Also #workingCopy should be changed to handle the possibility of it returning nil.
-1.
Either the methods should be removed (my preference), or be changed to return collections, to account for the possibility of having zero, one, or more package infos / working copies / repositories.
- Bert -
On Wed, Apr 3, 2013 at 1:28 AM, Tobias Pape Das.Linux@gmx.de wrote: Am 03.04.2013 um 03:05 schrieb Chris Muller asqueaker@gmail.com:
That works in 4.3, but not 4.4.
On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel marcel.taeumel@student.hpi.uni-potsdam.de wrote: You mean "String workingCopy" throws a DNU but should not?
-- Marcel
I have 'bisected' and the #workingCopy was introduced in 2011:
Name: Monticello-cmm.436 Time: 10 March 2011, 1:46:11.144 pm
- Added several methods for tracing MethodReferences and Classes back to their MC counterparts; their #workingCopy, and #repositoryGroup.
- Ability to convert MethodReferences to equivalent MCMethodDefinitions, and classes to MCClassDefinitions.
- Added MCRepository>>allVersionsDo:.
Chris, what PackageInfo do you have that injects #packageInfo into Class and MethodReference? I've looked in several images and repositories and cannot find a PackageInfo that provides those :/
Best -Tobias
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Chris Muller -
Colin Putney -
David T. Lewis -
Frank Shearar -
Marcel Taeumel -
Tobias Pape