Uploading mczs to the Trunk (Was: Re: [squeak-dev] Working with Trunk and Package loading)

Levente Uzonyi 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:
>>> Folks:
>>> 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
>>> know
>>> some is wroooong.
>>> As quality test, please do Undeclared removeUnreferencedKeys; inspect.
>>> on all you upload to trunk and in all your packages .
>> IMHO:
>> 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
>> again.
>> 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:
>> FontTest>>#testParagraphFallback
>> PackageDependencyTest>>#testCompiler
>> PackageDependencyTest>>#testExceptions
>> PackageDependencyTest>>#testMorphic
>> PackageDependencyTest>>#testTools
>> SqNumberParserTest>>#testFloatGradualUnderflow
>> SqNumberParserTest>>#testFloatPrintString
>> TileMorphTest>>#testArrowAction
>> Levente
> 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).


> Nicolas
>>> Edgar

More information about the Squeak-dev mailing list