April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Delays Semaphores and Processes

by Nicolas Cellier

My 16 KernelTests-Processes are green :) Forget all the SLICE-DelayFixFromMantis7321 stuff, it only add pain and complexity... I checked that entire changes related to mantis 7321 list can be loaded with following instructions: Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load. If ever a problem occur, try again in several steps: (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.299.mcz' 'KernelTests-nice.95.mcz' 'System-Support-nice.11.mcz')) load. Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz')) load. Or even in smaller grain... Cheers Nicolas 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > OK, I checked that mantis 6576 is superseded by 7321. > > To install DelayCleanup.1.cs it is necessary to write a ScriptLoader > script like: > script363 > Delay startTimerEventLoop. > (self buildConfigurationMapFor: > #('Kernel-nice.renggli.300.mcz')) load > > Now, last thing to fix is remove SmallInteger maxVal//2 protection and test. > > 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Andreas answered that the SmallInteger limit is obsolete since >> http://bugs.squeak.org/view.php?id=6576 which was included in 3.10 >> >> So I will check that mantis 6576+7321, and change the DelayTests>>#testBounds >> >> Then only the PREAMBLE problem will remain. >> But I see this preamble can simply go in a ScriptLoader script. >> >> 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> I took a look at http://bugs.squeak.org/view.php?id=7321 and >>> http://code.google.com/p/pharo/issues/detail?id=688 >>> >>> I started publishing PharoInbox/SLICE-DelayFixFromMantis7321-nice to >>> integrate Andreas' changes. >>> >>> Now I did integrate all but DelayCleanup.1.cs >>> This change set does cure the failing testSemaphore in Pharo, but has >>> two problems: >>> 1) It requires a preamble, and I don't know how they are handled in Monticello >>> 2) It probably does not include change about LargeInteger delays included in 3.9 >>> (Dave kindly pointed me to http://bugs.squeak.org/view.php?id=854) >>> 3) it makes DelayTests>>#testBounds fail >>> >>> >>> I think that the limit of (SmallInteger maxVal//2) is not necessary... >>> if LargeInteger delay fix is in the image. >>> I can try to fix 2) mixing Andreas and Tim fixes. >>> What about 1) ? >>> >> >

April 19, 2009

Re: [Pharo-project] Delays Semaphores and Processes

by Nicolas Cellier

OK, I checked that mantis 6576 is superseded by 7321. To install DelayCleanup.1.cs it is necessary to write a ScriptLoader script like: script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load Now, last thing to fix is remove SmallInteger maxVal//2 protection and test. 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Andreas answered that the SmallInteger limit is obsolete since > http://bugs.squeak.org/view.php?id=6576 which was included in 3.10 > > So I will check that mantis 6576+7321, and change the DelayTests>>#testBounds > > Then only the PREAMBLE problem will remain. > But I see this preamble can simply go in a ScriptLoader script. > > 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> I took a look at http://bugs.squeak.org/view.php?id=7321 and >> http://code.google.com/p/pharo/issues/detail?id=688 >> >> I started publishing PharoInbox/SLICE-DelayFixFromMantis7321-nice to >> integrate Andreas' changes. >> >> Now I did integrate all but DelayCleanup.1.cs >> This change set does cure the failing testSemaphore in Pharo, but has >> two problems: >> 1) It requires a preamble, and I don't know how they are handled in Monticello >> 2) It probably does not include change about LargeInteger delays included in 3.9 >> (Dave kindly pointed me to http://bugs.squeak.org/view.php?id=854) >> 3) it makes DelayTests>>#testBounds fail >> >> >> I think that the limit of (SmallInteger maxVal//2) is not necessary... >> if LargeInteger delay fix is in the image. >> I can try to fix 2) mixing Andreas and Tim fixes. >> What about 1) ? >> >

April 19, 2009

Re: [Pharo-project] Delays Semaphores and Processes

by Nicolas Cellier

Andreas answered that the SmallInteger limit is obsolete since http://bugs.squeak.org/view.php?id=6576 which was included in 3.10 So I will check that mantis 6576+7321, and change the DelayTests>>#testBounds Then only the PREAMBLE problem will remain. But I see this preamble can simply go in a ScriptLoader script. 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I took a look at http://bugs.squeak.org/view.php?id=7321 and > http://code.google.com/p/pharo/issues/detail?id=688 > > I started publishing PharoInbox/SLICE-DelayFixFromMantis7321-nice to > integrate Andreas' changes. > > Now I did integrate all but DelayCleanup.1.cs > This change set does cure the failing testSemaphore in Pharo, but has > two problems: > 1) It requires a preamble, and I don't know how they are handled in Monticello > 2) It probably does not include change about LargeInteger delays included in 3.9 > (Dave kindly pointed me to http://bugs.squeak.org/view.php?id=854) > 3) it makes DelayTests>>#testBounds fail > > > I think that the limit of (SmallInteger maxVal//2) is not necessary... > if LargeInteger delay fix is in the image. > I can try to fix 2) mixing Andreas and Tim fixes. > What about 1) ? >

April 19, 2009

Re: [Pharo-project] Trapped by self buildConfigurationMapFor:

by Nicolas Cellier

Well, no, that is not a problem of buildConfigurationMapFor: That only happens when restarting within the Debugger... 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I just tried this in a ScriptLoader: > > self buildConfigurationMapFor: > #('Kernel-nice.renggli.300') > > Hehe, it would iterate on characters $K, $e etc... >

April 19, 2009

[Pharo-project] Trapped by self buildConfigurationMapFor:

by Nicolas Cellier

I just tried this in a ScriptLoader: self buildConfigurationMapFor: #('Kernel-nice.renggli.300') Hehe, it would iterate on characters $K, $e etc...

April 19, 2009

[Pharo-project] Delays Semaphores and Processes

by Nicolas Cellier

I took a look at http://bugs.squeak.org/view.php?id=7321 and http://code.google.com/p/pharo/issues/detail?id=688 I started publishing PharoInbox/SLICE-DelayFixFromMantis7321-nice to integrate Andreas' changes. Now I did integrate all but DelayCleanup.1.cs This change set does cure the failing testSemaphore in Pharo, but has two problems: 1) It requires a preamble, and I don't know how they are handled in Monticello 2) It probably does not include change about LargeInteger delays included in 3.9 (Dave kindly pointed me to http://bugs.squeak.org/view.php?id=854) 3) it makes DelayTests>>#testBounds fail I think that the limit of (SmallInteger maxVal//2) is not necessary... if LargeInteger delay fix is in the image. I can try to fix 2) mixing Andreas and Tim fixes. What about 1) ?

April 19, 2009

Re: [Pharo-project] Infinite loop in Monticello MCWorkingCopy needsSavings

by StÃ©phane Ducasse

I'm sorry about that. This is true that the addition to MC are quite draft but useful and not tested on large scenario. I imagine myself really doing the same. On Apr 19, 2009, at 5:43 PM, Nicolas Cellier wrote: > I experimented other unaware beotian stupid manipulations (just to > workaround the oter bug) : > > 1) modify Kernel > 2) add a SLICE-A requiring Kernel > 3) Publish SLICE-A -> SLICE-A.1 Kernel.1 > 4) modify Kernel again > 5) add a new SLICE-B requiring all dirty packages, that is Kernel > and SLICE-A > 6) Publish SLICE-B -> SLICE-B-1 Kernel.2 > > Now SLICE-B.1 depends on SLICE-A.1 and Kernel.2 > BUT SLICE-A.1 depends on Kernel.1 > > 7) quit the image, restart and load SLICE-B.1 > > Doing this, I ended up with Kernel.1 in the image... GRR My advice is: if your changes in simple and touch only one package don't bother create a slice even if this is cool because I clean regularly the inbox and sometimes it is difficult to understand what is what. if your changes touched a lot of package slice is important. Stef > > > 2009/4/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> No and I'm expert in stupid manipulations and computer freezing :) >> but did not succeed this one >> On Apr 19, 2009, at 4:41 PM, Nicolas Cellier wrote: >> >>> Did anyone experimented an Infinite loop in Monticello MCWorkingCopy >>> needsSavings ? >>> >>> I had a SLICE previously saved. >>> I added a new required pakage dependency to this SLICE. >>> I tried to save again -> InfiniteLoop... >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

Re: [Pharo-project] Infinite loop in Monticello MCWorkingCopy needsSavings

by Nicolas Cellier

I experimented other unaware beotian stupid manipulations (just to workaround the oter bug) : 1) modify Kernel 2) add a SLICE-A requiring Kernel 3) Publish SLICE-A -> SLICE-A.1 Kernel.1 4) modify Kernel again 5) add a new SLICE-B requiring all dirty packages, that is Kernel and SLICE-A 6) Publish SLICE-B -> SLICE-B-1 Kernel.2 Now SLICE-B.1 depends on SLICE-A.1 and Kernel.2 BUT SLICE-A.1 depends on Kernel.1 7) quit the image, restart and load SLICE-B.1 Doing this, I ended up with Kernel.1 in the image... GRR 2009/4/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > No and I'm expert in stupid manipulations and computer freezing :) > but did not succeed this one > On Apr 19, 2009, at 4:41 PM, Nicolas Cellier wrote: > >> Did anyone experimented an Infinite loop in Monticello MCWorkingCopy >> needsSavings ? >> >> I had a SLICE previously saved. >> I added a new required pakage dependency to this SLICE. >> I tried to save again -> InfiniteLoop... >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

Re: [Pharo-project] Postgresql + pharo

by StÃ©phane Ducasse

thanks! This is really cool to see all this good energy. We are building something really "chouette" (which means cool in french) and powerful. This is where you see that a group is much more than the mere sum of its members. Stef On Apr 19, 2009, at 9:14 AM, MichaelA wrote: > > John, > I have loaded the files to > > http://idisk.mac.com/michaelatkisson1-Public?view=web > > Thanks for your help! > > > Well if you can put an image/changes file ready to go somewhere I can > take a look at it. > > On Sat, Apr 18, 2009 at 9:22 PM, MichaelA <michael_atkisson(a)comcast.net > > wrote: >> >> >> All I am trying to do at this point is to get the Postgres test to >> run. On >> a 10263 image using the Squeak 3.8.21beta1U image using the same >> default connection arg setup it works. >> -- >> View this message in context: http://n2.nabble.com/Postgresql-%2B-pharo-tp2621714p2658136.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > View this message in context: http://n2.nabble.com/Postgresql-%2B-pharo-tp2621714p2658434.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

Re: [Pharo-project] Infinite loop in Monticello MCWorkingCopy needsSavings

by StÃ©phane Ducasse

No and I'm expert in stupid manipulations and computer freezing :) but did not succeed this one On Apr 19, 2009, at 4:41 PM, Nicolas Cellier wrote: > Did anyone experimented an Infinite loop in Monticello MCWorkingCopy > needsSavings ? > > I had a SLICE previously saved. > I added a new required pakage dependency to this SLICE. > I tried to save again -> InfiniteLoop... > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009