Working with Trunk and Package loading

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

Working with Trunk and Package loading

Edgar De Cleene
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


Reply | Threaded
Open this post in threaded view
|

Re: Working with Trunk and Package loading

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

Reply | Threaded
Open this post in threaded view
|

Re: Working with Trunk and Package loading

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

Reply | Threaded
Open this post in threaded view
|

Re: Working with Trunk and Package loading

Bert Freudenberg
On 07.03.2010, at 15:27, Nicolas Cellier wrote:

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


I checked a couple of days ago and was glad to not see a single undeclared variable.

- Bert -



Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi-2
In reply to this post by Edgar De Cleene
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

>
> Edgar
>

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
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,
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.

Nicolas

>>
>> Edgar
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Uploading mczs to the Trunk (Was: Re: Working with Trunk and Package loading)

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

Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi-2
In reply to this post by Nicolas Cellier
On Sun, 7 Mar 2010, Nicolas Cellier wrote:

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

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


Levente

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

Reply | Threaded
Open this post in threaded view
|

Re: Uploading mczs to the Trunk (Was: Re: Working with Trunk and Package loading)

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

Cheers,
   - Andreas

> from PackageDependencyTest>>#testPackage:dependsOnlyOn: seems to be
> fixing all failures (except #testTools, because Tools also depends on
> Monticello which it shouldn't).

Reply | Threaded
Open this post in threaded view
|

Re: Uploading mczs to the Trunk (Was: Re: Working with Trunk and Package loading)

Levente Uzonyi-2
On Sun, 7 Mar 2010, Andreas Raab wrote:

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

I like the idea. This gives us another reason to run the tests before
uploading packages.


Levente

>
> Cheers,
>  - Andreas
>
>> from PackageDependencyTest>>#testPackage:dependsOnlyOn: seems to be
>> fixing all failures (except #testTools, because Tools also depends on
>> Monticello which it shouldn't).
>
>

Reply | Threaded
Open this post in threaded view
|

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

Edgar De Cleene
In reply to this post by Levente Uzonyi-2



On 3/7/10 7:42 PM, "Levente Uzonyi" <[hidden email]> wrote:

> 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


Ok, very good tip.
This remains me a old idea of having a CustomOfficer class dealing with any
trying to load into the image.
Like a real CustomOfficer search for any you don't wish affect your country.
And was some like the odd case of dictionary keys and trying to save
projects, which test and Undeclared don't show but bites you anyway.

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Uploading mczs to the Trunk (Was: Re: Working with Trunk and Package loading)

Nicolas Cellier
In reply to this post by Andreas.Raab
2010/3/7 Andreas Raab <[hidden email]>:

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

I think so.
Open MC.
Browse a Pharo repository,
open Merge window for a few Collection-* packages.
This should register some packageInfo in PackageOrganizer default and
make the dependency tests fail.
(since PakageOrganizer default packages are extracted from a
Dictionary, I can't really predict the order, but once
Collections-Sequenceable is before Collections, you're done...)

I don't understand anything to these Package*...
They seem to register but never unregister,
Too many levels and to few comments for my taste...

Nicolas