Working with Trunk and Package loading

> 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 .
>
> Edgar
>

> 2010/3/7 Edgar J. De Cleene <[hidden email]>:
>> 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 .
>>
>> Edgar
>>
>
> True,
> thanks for reminding.
>

>
> 2010/3/7 Nicolas Cellier <[hidden email]>:
>> 2010/3/7 Edgar J. De Cleene <[hidden email]>:
>>> 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 .
>>>
>>> Edgar
>>>
>>
>> True,
>> thanks for reminding.
>>
>
> Strange, I checked my own image (updated 9633) and didn't notice any
> Undeclared (except from VMMaker).
>
> Nicolas

> 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 .

> 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
>

> 2010/3/7 Levente Uzonyi <[hidden email]>:
>> 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,

>
> Nicolas
>
>>>
>>> Edgar
>>>
>>
>>
>
>

> On 3/7/2010 3:18 PM, Levente Uzonyi wrote:
>> 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).
>
> This choice was originally deliberate, since I'd like us to keep track of 'em
> explicitly, so if we remove a dependency we should update the test and try
> hard not to reintroduce it. However, since this test is supposed to help us
> in our work, we might reconsider the choice, if people feel that's not
> appropriate.

> 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

> On 3/7/2010 2:18 PM, Nicolas Cellier wrote:
>>
>> It does not work that well for me because VMMaker has some Undeclared,
>> 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.
>
> Is there an easy way to recreate this problem?
>
> Cheers,
>  - Andreas
>
>