How to fix all package dependency tests in trunk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
bpi
Reply | Threaded
Open this post in threaded view
|

How to fix all package dependency tests in trunk

bpi
Dear Squeakers,

I just saved three versions to the inbox which fix all remaining failures in PackageDependencyTest. This should work in every trunk image without the need to do Smalltalk cleanUp: aggressive.

1. Load PackageInfo-Base-bp.47.
2. Load Graphics-bp.173.
3. Load Morphic-bp.509.
4. You get a warning that there are unsaved changes to the Morphic package. Proceed.
5. Run PackageDependencyTest to verify that all tests are green. :-)

Cheers,
Bernhard
Reply | Threaded
Open this post in threaded view
|

Re: How to fix all package dependency tests in trunk

Andreas.Raab
One small comment on this: The purpose of PackageDependencyTest is to
document dependencies. If we find that new dependencies are reasonable,
we should add the dependency to the test instead of having to stand on
our heads trying to avoid the dependency.

I'm not saying that you stood on your head here, just that we should
evaluate new dependencies to decide whether to avoid the dependency or
whether to simply document it.

Cheers,
   - Andreas

On 1/8/2011 2:35 PM, Bernhard Pieber wrote:

> Dear Squeakers,
>
> I just saved three versions to the inbox which fix all remaining failures in PackageDependencyTest. This should work in every trunk image without the need to do Smalltalk cleanUp: aggressive.
>
> 1. Load PackageInfo-Base-bp.47.
> 2. Load Graphics-bp.173.
> 3. Load Morphic-bp.509.
> 4. You get a warning that there are unsaved changes to the Morphic package. Proceed.
> 5. Run PackageDependencyTest to verify that all tests are green. :-)
>
> Cheers,
> Bernhard
>


bpi
Reply | Threaded
Open this post in threaded view
|

Re: How to fix all package dependency tests in trunk

bpi
Hi Andreas,

I completely agree! I have considered it in all cases. It would have been much easier to fix it by introducing the dependencies. ;-) But maybe I should have discussed my choices on the list before.

1. IMHO package dependency tests should not rely on "obsolete", i.e. non-Monticello PackageInfos.
2. TestRunner should not depend on Morphic, just because it uses LayoutFrame. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156081.html
3. TheWorldMainDockingBar>>helpMenuOn: was already coded to avoid a dependency on HelpSystem-Core by using (Smalltalk classNamed: #HelpBrowser) ifNotNil:. Therefore it did not feel right to me to introduce a dependency on the more specific Help-Squeak-TerseGuide. Furthermore Help-Squeak-TerseGuide is a separate package. So it could potentially be unloaded even when HelpSystem-Core is loaded. IMHO those packages should be added to your unloadAllKnownPackages.

Cheers,
Bernhard

Am 08.01.2011 um 14:47 schrieb Andreas Raab:

> One small comment on this: The purpose of PackageDependencyTest is to document dependencies. If we find that new dependencies are reasonable, we should add the dependency to the test instead of having to stand on our heads trying to avoid the dependency.
>
> I'm not saying that you stood on your head here, just that we should evaluate new dependencies to decide whether to avoid the dependency or whether to simply document it.
> On 1/8/2011 2:35 PM, Bernhard Pieber wrote:
>> I just saved three versions to the inbox which fix all remaining failures in PackageDependencyTest. This should work in every trunk image without the need to do Smalltalk cleanUp: aggressive.
>>
>> 1. Load PackageInfo-Base-bp.47.
>> 2. Load Graphics-bp.173.
>> 3. Load Morphic-bp.509.
>> 4. You get a warning that there are unsaved changes to the Morphic package. Proceed.
>> 5. Run PackageDependencyTest to verify that all tests are green. :-)