I just found out that doing MCWorkingCopy flushObsoletePackageInfos breaks the PackageDependencyTest. This fixes the test. It should only be loaded after the flushing, because without the flushing it breaks the test. :-/
The reason is that PackageInfos can overlap. There is an obsolete PackageInfo named 'PackageInfo' and a PackageInfo named 'PackageInfo-Base' Monticello knows about.
The method PackageOrganizer>>packageOfClass:ifNone: does not deal with this potential overlapping. It just answers the obsolete one because it comes first in its list of packages.
IMO the overlapping should be regarded as an error because it will probably lead to a lot of unintended side effects. Does anyone know a good reason for allowing overlapping PackageInfos?
Cheers, Bernhard
Am 31.10.2010 um 17:51 schrieb commits@source.squeak.org:
A new version of Tests was added to project The Inbox: http://source.squeak.org/inbox/Tests-bp.99.mcz
==================== Summary ====================
Name: Tests-bp.99 Author: bp Time: 31 October 2010, 6:44:26.559 pm UUID: d573b35d-7413-43c2-96f7-1c47d39d8f27 Ancestors: Tests-ul.98
Fix dependencies on obsolete PackageInfos.
=============== Diff against Tests-ul.98 ===============
Item was changed: ----- Method: PackageDependencyTest>>testMonticello (in category 'tests') ----- testMonticello self testPackage: 'Monticello' dependsExactlyOn: #( Collections Compiler Compression Exceptions Files Graphics Kernel Morphic Network
'PackageInfo-Base'
PackageInfoItem was changed: ----- Method: PackageDependencyTest>>testMorphic (in category 'tests') ----- testMorphic self testPackage: 'Morphic' dependsExactlyOn: #( Balloon Collections Compiler EToys Exceptions Files Graphics Kernel Monticello MonticelloConfigurations
'Morphic-TrueType' "????"Item was changed: ----- Method: PackageDependencyTest>>testSUnitGUI (in category 'tests') ----- testSUnitGUI self testPackage: 'SUnitGUI' dependsExactlyOn: #( Collections Graphics Kernel
'PackageInfo-Base'
PackageInfoItem was changed: ----- Method: PackageDependencyTest>>testServices (in category 'tests') ----- testServices self testPackage: 'Services-Base' dependsExactlyOn: #( Collections Compiler Exceptions Graphics Kernel Morphic
'PackageInfo-Base'
PackageInfoItem was changed: ----- Method: PackageDependencyTest>>testSystem (in category 'tests') ----- testSystem self testPackage: 'System' dependsExactlyOn: #( Collections Balloon Compiler Compression Exceptions Files Graphics Kernel Monticello MonticelloConfigurations Morphic MorphicExtras Multilingual Network
'PackageInfo-Base'
PackageInfoItem was changed: ----- Method: PackageDependencyTest>>testToolBuilderMVC (in category 'tests') ----- testToolBuilderMVC self testPackage: 'ToolBuilder-MVC' dependsExactlyOn: #( Collections Exceptions Graphics ST80
ToolBuilderItem was changed: ----- Method: PackageDependencyTest>>testToolBuilderSUnit (in category 'tests') ----- testToolBuilderSUnit self testPackage: 'ToolBuilder-SUnit' dependsExactlyOn: #( Collections Kernel
ToolBuilderItem was changed: ----- Method: PackageDependencyTest>>testTools (in category 'tests') ----- testTools self testPackage: 'Tools' dependsExactlyOn: #( Collections Compiler Compression Exceptions Files Graphics Kernel Morphic MorphicExtras Multilingual Network
'PackageInfo-Base'
PackageInfo
2010/10/31 Bernhard Pieber bernhard@pieber.com:
I just found out that doing MCWorkingCopy flushObsoletePackageInfos breaks the PackageDependencyTest. This fixes the test. It should only be loaded after the flushing, because without the flushing it breaks the test. :-/
The reason is that PackageInfos can overlap. There is an obsolete PackageInfo named 'PackageInfo' and a PackageInfo named 'PackageInfo-Base' Monticello knows about.
The method PackageOrganizer>>packageOfClass:ifNone: does not deal with this potential overlapping. It just answers the obsolete one because it comes first in its list of packages.
IMO the overlapping should be regarded as an error because it will probably lead to a lot of unintended side effects. Does anyone know a good reason for allowing overlapping PackageInfos?
Cheers, Bernhard
One reason could be that it enables comparing Pharo/Collections-Abstract with Squeak/Collections within MC, but I'm not sure.
Nicolas
Am 31.10.2010 um 17:51 schrieb commits@source.squeak.org:
A new version of Tests was added to project The Inbox: http://source.squeak.org/inbox/Tests-bp.99.mcz
==================== Summary ====================
Name: Tests-bp.99 Author: bp Time: 31 October 2010, 6:44:26.559 pm UUID: d573b35d-7413-43c2-96f7-1c47d39d8f27 Ancestors: Tests-ul.98
Fix dependencies on obsolete PackageInfos.
=============== Diff against Tests-ul.98 ===============
Item was changed: ----- Method: PackageDependencyTest>>testMonticello (in category 'tests') ----- testMonticello self testPackage: 'Monticello' dependsExactlyOn: #( Collections Compiler Compression Exceptions Files Graphics Kernel Morphic Network
- 'PackageInfo-Base'
- PackageInfo
System Tests 'ToolBuilder-Kernel' 'ToolBuilder-Morphic' Tools ).!
Item was changed: ----- Method: PackageDependencyTest>>testMorphic (in category 'tests') ----- testMorphic self testPackage: 'Morphic' dependsExactlyOn: #( Balloon Collections Compiler EToys Exceptions Files Graphics Kernel Monticello MonticelloConfigurations
- 'Morphic-TrueType' "????"
MorphicExtras Multilingual Network ST80 Sound System 'ToolBuilder-Kernel' 'ToolBuilder-Morphic' Tools TrueType ).!
Item was changed: ----- Method: PackageDependencyTest>>testSUnitGUI (in category 'tests') ----- testSUnitGUI self testPackage: 'SUnitGUI' dependsExactlyOn: #( Collections Graphics Kernel
- 'PackageInfo-Base'
- PackageInfo
SUnit System 'ToolBuilder-Kernel' Tools ).!
Item was changed: ----- Method: PackageDependencyTest>>testServices (in category 'tests') ----- testServices self testPackage: 'Services-Base' dependsExactlyOn: #( Collections Compiler Exceptions Graphics Kernel Morphic
- 'PackageInfo-Base'
- PackageInfo
PreferenceBrowser System 'ToolBuilder-Kernel' Tools ).!
Item was changed: ----- Method: PackageDependencyTest>>testSystem (in category 'tests') ----- testSystem self testPackage: 'System' dependsExactlyOn: #( Collections Balloon Compiler Compression Exceptions Files Graphics Kernel Monticello MonticelloConfigurations Morphic MorphicExtras Multilingual Network
- 'PackageInfo-Base'
- PackageInfo
Sound 'ToolBuilder-Kernel' Tools TrueType ).!
Item was changed: ----- Method: PackageDependencyTest>>testToolBuilderMVC (in category 'tests') ----- testToolBuilderMVC self testPackage: 'ToolBuilder-MVC' dependsExactlyOn: #( Collections Exceptions Graphics ST80
- ToolBuilder
'ToolBuilder-Kernel' Tools ).!
Item was changed: ----- Method: PackageDependencyTest>>testToolBuilderSUnit (in category 'tests') ----- testToolBuilderSUnit self testPackage: 'ToolBuilder-SUnit' dependsExactlyOn: #( Collections Kernel
- ToolBuilder
'ToolBuilder-Kernel' ).!
Item was changed: ----- Method: PackageDependencyTest>>testTools (in category 'tests') ----- testTools self testPackage: 'Tools' dependsExactlyOn: #( Collections Compiler Compression Exceptions Files Graphics Kernel Morphic MorphicExtras Multilingual Network
- 'PackageInfo-Base'
- PackageInfo
ST80 System 'ToolBuilder-Kernel' ).!
On 31.10.2010, at 19:12, Nicolas Cellier wrote:
2010/10/31 Bernhard Pieber bernhard@pieber.com:
I just found out that doing MCWorkingCopy flushObsoletePackageInfos breaks the PackageDependencyTest. This fixes the test. It should only be loaded after the flushing, because without the flushing it breaks the test. :-/
The reason is that PackageInfos can overlap. There is an obsolete PackageInfo named 'PackageInfo' and a PackageInfo named 'PackageInfo-Base' Monticello knows about.
The method PackageOrganizer>>packageOfClass:ifNone: does not deal with this potential overlapping. It just answers the obsolete one because it comes first in its list of packages.
That seems to be a bug, all code should iterate through all packages a class belongs to. E.g., Monticello does.
IMO the overlapping should be regarded as an error because it will probably lead to a lot of unintended side effects. Does anyone know a good reason for allowing overlapping PackageInfos?
Cheers, Bernhard
One reason could be that it enables comparing Pharo/Collections-Abstract with Squeak/Collections within MC, but I'm not sure.
Nicolas
PackageInfo was designed to be universal. It is an arbitrary collection of classes and methods. It is not a partitioning - this is only how we use it in trunk with Monticello. But neither PackageInfo nor Monticello enforces that. Overlaps are perfectly normal even though we do not use them in the trunk process.
- Bert -
Hi Bert,
Thanks for your answer. See my comments below.
Am 01.11.2010 um 09:41 schrieb Bert Freudenberg:
2010/10/31 Bernhard Pieber bernhard@pieber.com:
The reason is that PackageInfos can overlap. There is an obsolete PackageInfo named 'PackageInfo' and a PackageInfo named 'PackageInfo-Base' Monticello knows about.
The method PackageOrganizer>>packageOfClass:ifNone: does not deal with this potential overlapping. It just answers the obsolete one because it comes first in its list of packages.
That seems to be a bug, all code should iterate through all packages a class belongs to. E.g., Monticello does.
OK. But what would be a good way to fix the bug? Should the messages #packageOfClass: and #packageOfClass:ifNone: be there at all? In the trunk they are only used by the DependencyBrowser and PackageDependendyTest.
With overlaps one could have #packagesOfClass: and #packagesOfClass:ifEmpty: instead. But how would the PackageDependencyTest be written with those? E.g. with the overlapping packages PackageInfo and PackageInfo-Base, which one should e.g. Monticello depend on? Or should it depende both of them?
IMO the overlapping should be regarded as an error because it will probably lead to a lot of unintended side effects. Does anyone know a good reason for allowing overlapping PackageInfos?
PackageInfo was designed to be universal. It is an arbitrary collection of classes and methods. It is not a partitioning - this is only how we use it in trunk with Monticello. But neither PackageInfo nor Monticello enforces that. Overlaps are perfectly normal even though we do not use them in the trunk process.
I am still skeptical that overlaps are worth the additional complexity and potiential confusion they cause, especially as in the trunk process we use packages to achieve a partioning. IMHO it is very easy to introduce subtle bugs by writing code based on the partioning assumption like the above example. Has someone ever used overlapping packages? If yes, for what exaclty?
As a compromise one could imagine a code layer above PackageInfo and Monticello which introduces the partitioning assumption and associated APIs like #packageOfClass: which could be used for the DependencyBrowser and the PackageDependencyTest. But that would add even more complexity. What do you think?
Cheers, Bernhard
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Bert Freudenberg -
Nicolas Cellier