Uploading mczs to the Trunk (Was: Re: [squeak-dev] Working with
Trunk and Package loading)
leves at elte.hu
Sun Mar 7 23:18:37 UTC 2010
On Sun, 7 Mar 2010, Nicolas Cellier wrote:
> 2010/3/7 Levente Uzonyi <leves at elte.hu>:
>> On Sun, 7 Mar 2010, Edgar J. De Cleene wrote:
>>> I re testing the tomorrow version of FunSqueak and as each time , discover
>>> new things and old bugs shows again
>>> The particular point I wish all working in Trunk should note is:
>>> Your .mcz don?t should give any Undeclared
>>> Just now going to 9633
>>> Undeclared removeUnreferencedKeys; inspect.
>>> a Dictionary(#Definitions->nil #Instances->nil #activatorDockingBar->nil
>>> #arguments->nil #current->a SmalltalkImage #dirFlag->nil
>>> #objectsToFinalize->nil #updateSelector->nil #updater->nil )
>>> And of course, no packages should bring Undeclared things to .image.
>>> In 3.10 I put some in Monticello raising a error just for this, so you
>>> some is wroooong.
>>> As quality test, please do Undeclared removeUnreferencedKeys; inspect.
>>> on all you upload to trunk and in all your packages .
>> It's easier to do that by running all the tests before uploading your new
>> package version. (If ReleaseTest >> #testUndeclared is failing, then there
>> are some undeclared variables/classes hanging around.) This should be done
>> by everyone who uploads to the Trunk or the Inbox.
>> If your package may affect package loading, you should also load your mcz to
>> a clean image an run the tests after that to be sure that everything works
>> as it should.
>> If your changes may affect system startup/shutdown, you should also save the
>> clean image with the package loaded, then restart it and run the tests
>> On my pc running the tests takes a bit more than 2 minutes and it's still
>> less than 4 minutes if I include the long testcases too.
>> In the last few weeks a few new failures/errors occured, which could
>> possibly be avoided by running the tests. These are:
> Good idea.
> It does not work that well for me because VMMaker has some Undeclared,
I have a clean image for this purpose.
> and PackageDependency fails probably because a lot of Package-Info are
> still around after comparing with Pharo (which split the packages),
> but I will probably find a workaround.
I think there's an unnecessary assert in
PackageDependencyTest>>#testPackage:dependsOnlyOn: which causes failure if
the package doesn't depend on a package which is contained by pkgList.
For example Compiler doesn't depend on Tools (according to
DependecyBrowser), but PackageDependencyTest>>#testCompiler passes Tools
as a possible dependency.
Removing this line
self assert: (pkgDeps includesKey: pkg).
from PackageDependencyTest>>#testPackage:dependsOnlyOn: seems to be fixing
all failures (except #testTools, because Tools also depends on Monticello
which it shouldn't).
More information about the Squeak-dev