- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Max Leske

> On 17 Nov 2015, at 23:50, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > > On Tue, Nov 17, 2015 at 11:44 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > I can confirm that changing #styleInBackgroundProcess: to #style: fixes the problem on my machine. > > I had tracked down a version of GTInspector-Core (StefanReichhart.310) that exhibited the problem while the immediate ancestor didnât. Unfortunately the number of changes are huge in that version. > Still, making the above change makes that version also work. My guess is, that this version leads to more of these styling requests. > > I logged the number of processes after running the examples: > without the fix: 937 > with the fix: 17 > > Is this the number of processes for running all examples? Yes. > If yes can you also measure it when running just a single example, as testBenchFor also blocks in that case. Thereâs no facility for running a single example, so I just created this method: GTInspectorExamplesTest>>testSingleExample self checkAllPresentationsOf: Collection gtExamples first Then, when I run this command line: ./pharo Pharo.image eval "| suite | suite := TestSuite named: 'x'. suite addTest: (GTInspectorExamplesTest new setTestSelector: #testSingleExample; yourself). CommandLineTestRunner runSuite: suite. suite := TestSuite named: 'y'. suite addTest: (BlockClosureTest new setTestSelector: #testBenchFor; yourself). CommandLineTestRunner runSuite: suite.â I get 17 with the fix and 19 without. Which example did you run to have #testBenchFor block? Because it didnât block for me... > > > Cheers, > Andrei > > > Sounds pretty compelling to me that this will mess with process schedulingâ¦ > > Cheers, > Max > >> On 17 Nov 2015, at 22:56, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> >> We investigated more with Max and Aliaksey, and managed to reduce the bug to executing just two tests. >> Just it would great if somebody else could reproduce it. You need to run commands only from console and save and quit the image after a change. >> >> The tests that need to be executed are GTInspectorExamplesTest>>#testAllExamples and BlockClosureTest>>#testBenchFor. >> >> Download the latest pharo image and remove GTInspectorExamplesTest>>#testGlobals, so that GTInspectorExamplesTest has one single test. >> In GTInspectorExamplesTest>>#testAllExamples replace 'Object withAllSubclasses' with 'Dictionary asOrderedCollection' (it's not the actual examples that cause problems). >> >> If you execute now the tests, BlockClosureTest>>#testBenchFor will block for around 20 seconds. >> >> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GTInspectorExamplesTest} named: 'x'. CommandLineTestRunner runClasses: {BlockClosureTest} named: 'y'" >> >> Now go to SHTextStyler>>styleInBackgroundProcess: and in the only onTimeout: block from the method add --> 'timeoute done' logCr. <--. >> >> Run again the tests and now the string 'timeoute done' is printed 4 times after 20 seconds. >> >> Replace in RubShoutStylerDecorator>>style: the call to #styleInBackgroundProcess: with #style: >> >> Running again the tests has no delay on BlockClosureTest>>#testBenchFor. >> Reverting the changes to GTInspectorExamplesTest>>#testAllExamples and running all examples again leads to no delay on BlockClosureTest>>#testBenchFor (testing all examples can take a few minutes). >> >> Running all the tests as on the CI also does not block in BlockClosureTest>>#testBenchFor. >> >> ./pharo Pharo.image test --junit-xml-output '^(?!Metacello)[A-L].*' >> (ignore the output about GTDummyExamplesInvalid which will disappear when the new version is integrated) >> (running the tests takes a bit of time) >> >> I get the same behaviour if I first load issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> >> >> If anybody else can reproduce this behaviour then the zombie processes that appear while styling in rubric are somehow interfering with the delay scheduling mechanism. >> >> Cheers, >> Andrei >> >> >> >> >> On Mon, Nov 16, 2015 at 2:45 PM, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> Also you do not have to run it from the command line to reproduce the error. >> You can just execute in a playground: >> >> CommandLineTestRunner runClasses: {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests'). >> >> But if you run the same tests using a script then there is no block: >> >> suite := TestSuite named: 'x'. >> classes := {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} >> asSortedCollection: [ :a :b | a name <= b name ]. >> classes >> do: [ :each | each addToSuiteFromSelectors: suite ]. >> runner := TestRunner new . >> Author uniqueInstance >> ifUnknownAuthorUse: 'hudson' >> during: [ runner >> runSuite: suite ]. >> >> >> >> On Mon, Nov 16, 2015 at 2:25 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> Interestingly, if I change the delay in that method from 400 to 0 I get the same effect (namely, it doesnât hang). So maybe itâs a problem with delay scheduling from low priority processes? >> >> >>> On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >>> >>> Hi, >>> >>> Any news on this? >>> >>> Might be totally unrelated but I went back and searched for the the first version where [1] blocks. >>> In my case the first version where it blocks is Pharo-40520. In Pharo-40519 it works ok. >>> 40520 integrated https://pharo.fogbugz.com/f/cases/14993 <https://pharo.fogbugz.com/f/cases/14993> which does a lot of changes, but one changed that this issue did is introduced an async tasks for updating the scrolling in inspector. >>> >>> Next if in the latest version I change in GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' >>> then #testBenchFor does not block. If I change the priority to the initial one it blocks again. At least on my machine this is consistent. >>> >>> Not sure if this fixes the bug on the CI but I updated issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to include this change. >>> Can you try to integrate the issue and see if it still blocks. >>> >>> Cheers, >>> Andrei >>> >>> >>> >>> [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" >>> >>> >>> >>> On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> I found a single test method I could use to narrow down the problem (be aware that this might not work for you. I have other (fresh) images where the issue never occurs). The method I used is EpRedoAndUndoVisitorTest>>testClassModification. >>> >>> I was able to mitigate the hang by making a small modification to the method EpUndoVisitor>>visitClassModification: Simply add >>> >>> 2 seconds asDelay wait. Smalltalk garbageCollect. >>> >>> or >>> >>> Smalltalk garbageCollect. 2 seconds asDelay wait. >>> >>> after the compilation phase. My guess is, that announcements build up (a simple printout showed 1 announcement instance before and 74 instances after the #evaluate:) and do stuff in the system that influence the process scheduling. For instance, a lot of those announcements will probably be weak and need to be finalized at some point. >>> >>> I donât have enough experience with the ClassBuilder to go on hunting but this should hopefully give you a good head start. >>> >>> >>> >>> For testing I used the following command line: >>> >>> ./pharo found_case.image eval "CommandLineTestRunner runPackages: #('Epicea' 'Kernel-Testsâ)" >>> >>> Install Epicea with >>> >>> ./pharo Pharo.image get Epicea 6.5 >>> >>> >>> To isolate the test case I simply moved test classes from Epicea to a differently named package and once I had found the class I started excluding methods (e.g. with âself fail.â at the beginning). >>> >>> >>> HTH, >>> Max >>> >>> >>> >>> >>>> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >>>> >>>> Yes! with Max Leske we have been isolating the problem and we realized that a fresh image was enough: >>>> >>>> 1) >>>> curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >>>> >>>> 2) >>>> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" >>>> >>>> Martin >>>> >>>> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>>> Then it must be that waiting on the delay never ends, which is probably a problem all by itself. >>>> >>>> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>> > >>>> > The fun thing is that I now get the same problem when integrating the GT Tools update. >>>> > >>>> > After doing the update for issue 16957, the test run hangs with >>>> > >>>> > starting testcase: BlockClosureTest>>testBenchFor ... >>>> > >>>> > >>>> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >>>> >> >>>> >> Hello, >>>> >> >>>> >> I'm trying to understand why this method hangs in certain conditions*. What happens is that the #whileTrue: in the following method is never cut. >>>> >> >>>> >> benchFor: duration >>>> >> "Run me for duration and return a BenchmarkResult" >>>> >> >>>> >> "[ 100 factorial ] benchFor: 2 seconds" >>>> >> >>>> >> | count run started | >>>> >> count := 0. >>>> >> run := true. >>>> >> [ duration wait. run := false ] forkAt: Processor timingPriority - 1. >>>> >> started := Time millisecondClockValue. >>>> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >>>> >> ^ BenchmarkResult new >>>> >> iterations: count; >>>> >> elapsedTime: (Time millisecondsSince: started) milliSeconds; >>>> >> yourself >>>> >> >>>> >> Strangely, I verified with several #logCr that the forked block starts, but the #wait never ends. >>>> >> ---> Maybe you see something I don't in the code. Any clue? >>>> >> >>>> >> I will continue trying to isolate the problem, but maybe you have some idea. >>>> >> >>>> >> * the conditions to reproduce are: >>>> >> 1) curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >>>> >> 2) ./pharo Pharo.image get Epicea 6.5 >>>> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >>>> >> >>>> >> Notes: >>>> >> - It doesn't hang when running from UI >>>> >> - it doesn't hang when running less tests, like: >>>> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >>>> >> - it *does* hang even when removing all Epicea tests >>>> >> - Epicea doesn't extend or override "kernel" behavior... >>>> >> >>>> >> Regards, >>>> >> Martin >>>> > >>>> >>>> >>>> >>> >>> >> >> >> > >

Nov. 18, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Eliot Miranda

Hi Esteban, On Tue, Nov 17, 2015 at 1:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Esteban, > > > > I think EyeInspector needs to handle classes that don't inherit from > > Object specially. Instead of asking the instance it should ask the class. > > You should be able to use the Context methods for mirror primitives to > > extract state without sending messages to the instance. Then the special > > version of EyeInspector for ProtoObject subclasses can ask this like > > Yes, an special inspector for ProtoObject subclasses would be required, > but I couldn't find one already suited for this purpose. > > > (thisContext objectClass: object) isIndexable ifTrue: > > [size := thisContext objectSize: object] > > I don't know if your code was meant to be accurate or just a guideline of > how this could be implemented, but Context doesn't implement #objectClass: > nor #objectSize: > Find attached. I think you'll find they are in the Spur version. You might think of back-porting their use in Context form Spur; that'll make the debugger able to handle proxies. > Basically both the Inspector and the Debugger's execution simulation > > machinery need to treat encapsulators such as MessageArchiver with kid > > gloves. One *must not* cause inspecting or debugging to send messages > > through the encapsulator. Instead, all access to the object should be > > through primitives that don't send messages to the objects. > > I know that dealing with Proxies and similar objects is tricky, I had to > deal with my own subclasses of ProtoObject in Dolphin, but there the class > implemented all that was needed to interact with the environment tools. > > Hiwever, to me all this is a kind of black magic, I read the blue book > years ago and can understand it, but I do understand it as I understand the > mechanics of my car, however when it breaks down I take it to the > specialist :) > Well, the thing to think of is that inside the VM objects are just a sequence of words, and the VM, while it sends messages, doesn't send messages to objects to update their state; it just accesses the state directly. So in an execution simulation method such as Context methods for instruction decoding pushReceiverVariable: offset self push: (receiver instVarAt: offset + 1) that will send the message instVarAt: to the receiver, and if the receiver is a proxy, that will go through the proixie's doesNotUnderstand: method and send instVarAt: the the object the proxy wraps, which won't do the right thing at all. Instead it needs to be written Context methods for instruction decoding pushReceiverVariable: offset self push: (self object: receiver instVarAt: offset + 1) which reaches into the object without sending any messages to it. I understand that this will appear in Spur, because I made it part of the bootstrap, but if I were you I would integrate these changes into the current version asap. The debugger won't work properly with proxies, encapsulators etc otherwise. _,,,^..^,,,_ best, Eliot

Nov. 18, 2015

Re: [Pharo-dev] A Question about Metacello's #repository:

by Dale Henrichs

On 11/17/15 1:34 PM, Sven Van Caekenberghe wrote: > Hi Dale, > > Thanks for the elaborate answer. > > Yes, I think that BaselineOf is what I was looking for, I will experiment with it. > > I do suspect that a Baseline can only be loaded using the Metacello API, not using the Pharo config handler which seems to fall back to Gofer. > The Metacello Scripting API should be used for all loads ... I know that does not always happen in Pharo, but that doesn't change the fact that the Metacello API _should_ be used:) Also make sure that you've loaded the latest Metacello into Pharo[1], because there are definitely bugs that have been fixed In Metacello that haven't made into Pharo ... Dale [1] https://github.com/dalehenrich/metacello-work#pharo30-pharo40-and-pharo50

Nov. 17, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Andrei Chis

On Tue, Nov 17, 2015 at 11:44 PM, Max Leske <maxleske(a)gmail.com> wrote: > I can confirm that changing #styleInBackgroundProcess: to #style: fixes > the problem on my machine. > > I had tracked down a version of GTInspector-Core (StefanReichhart.310) > that exhibited the problem while the immediate ancestor didnât. > Unfortunately the number of changes are huge in that version. > Still, making the above change makes that version also work. My guess is, > that this version leads to more of these styling requests. > > I logged the number of processes after running the examples: > without the fix: 937 > with the fix: 17 > Is this the number of processes for running all examples? If yes can you also measure it when running just a single example, as testBenchFor also blocks in that case. Cheers, Andrei > > Sounds pretty compelling to me that this will mess with process schedulingâ¦ > > Cheers, > Max > > On 17 Nov 2015, at 22:56, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > We investigated more with Max and Aliaksey, and managed to reduce the bug > to executing just two tests. > Just it would great if somebody else could reproduce it. You need to run > commands only from console and save and quit the image after a change. > > The tests that need to be executed > are GTInspectorExamplesTest>>#testAllExamples > and BlockClosureTest>>#testBenchFor. > > Download the latest pharo image and remove > GTInspectorExamplesTest>>#testGlobals, so that GTInspectorExamplesTest has > one single test. > In GTInspectorExamplesTest>>#testAllExamples replace 'Object > withAllSubclasses' with 'Dictionary asOrderedCollection' (it's not the > actual examples that cause problems). > > If you execute now the tests, BlockClosureTest>>#testBenchFor will block > for around 20 seconds. > > ./pharo Pharo.image eval "CommandLineTestRunner runClasses: > {GTInspectorExamplesTest} named: 'x'. CommandLineTestRunner runClasses: > {BlockClosureTest} named: 'y'" > > Now go to SHTextStyler>>styleInBackgroundProcess: and in the > only onTimeout: block from the method add --> 'timeoute done' logCr. <--. > > Run again the tests and now the string 'timeoute done' is printed 4 times > after 20 seconds. > > Replace in RubShoutStylerDecorator>>style: the call to > #styleInBackgroundProcess: with #style: > > Running again the tests has no delay on BlockClosureTest>>#testBenchFor. > Reverting the changes to GTInspectorExamplesTest>>#testAllExamples and > running all examples again leads to no delay on > BlockClosureTest>>#testBenchFor (testing all examples can take a few > minutes). > > Running all the tests as on the CI also does not block in > BlockClosureTest>>#testBenchFor. > > ./pharo Pharo.image test --junit-xml-output '^(?!Metacello)[A-L].*' > (ignore the output about GTDummyExamplesInvalid which will disappear when > the new version is integrated) > (running the tests takes a bit of time) > > I get the same behaviour if I first load issue 16957 > <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> > > If anybody else can reproduce this behaviour then the zombie processes > that appear while styling in rubric are somehow interfering with the delay > scheduling mechanism. > > Cheers, > Andrei > > > > > On Mon, Nov 16, 2015 at 2:45 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Also you do not have to run it from the command line to reproduce the >> error. >> You can just execute in a playground: >> >> CommandLineTestRunner runClasses: {GLMPagerMorphTest . >> GLMTreeMorphicTest. GLMWatcherMorphicTest} named: 'x'. >> CommandLineTestRunner runPackages: #('Kernel-Tests'). >> >> But if you run the same tests using a script then there is no block: >> >> suite := TestSuite named: 'x'. >> classes := {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} >> asSortedCollection: [ :a :b | a name <= b name ]. >> classes >> do: [ :each | each addToSuiteFromSelectors: suite ]. >> runner := TestRunner new . >> Author uniqueInstance >> ifUnknownAuthorUse: 'hudson' >> during: [ runner >> runSuite: suite ]. >> >> >> >> On Mon, Nov 16, 2015 at 2:25 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Interestingly, if I change the delay in that method from 400 to 0 I get >>> the same effect (namely, it doesnât hang). So maybe itâs a problem with >>> delay scheduling from low priority processes? >>> >>> >>> On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei(a)gmail.com> >>> wrote: >>> >>> Hi, >>> >>> Any news on this? >>> >>> Might be totally unrelated but I went back and searched for the the >>> first version where [1] blocks. >>> In my case the first version where it blocks is Pharo-40520. >>> In Pharo-40519 it works ok. >>> 40520 integrated https://pharo.fogbugz.com/f/cases/14993 which does a >>> lot of changes, but one changed that this issue did is introduced an async >>> tasks for updating the scrolling in inspector. >>> >>> Next if in the latest version I change in >>> GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from >>> 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' >>> then #testBenchFor does not block. If I change the priority to the >>> initial one it blocks again. At least on my machine this is consistent. >>> >>> Not sure if this fixes the bug on the CI but I updated issue 16957 >>> <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to >>> include this change. >>> Can you try to integrate the issue and see if it still blocks. >>> >>> Cheers, >>> Andrei >>> >>> >>> >>> [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: >>> {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. >>> CommandLineTestRunner runPackages: #('Kernel-Tests')" >>> >>> >>> >>> On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> I found a single test method I could use to narrow down the problem (be >>>> aware that this might not work for you. I have other (fresh) images where >>>> the issue never occurs). The method I used >>>> is EpRedoAndUndoVisitorTest>>testClassModification. >>>> >>>> I was able to mitigate the hang by making a small modification to the >>>> method EpUndoVisitor>>visitClassModification: Simply add >>>> >>>> 2 seconds asDelay wait. Smalltalk garbageCollect. >>>> >>>> or >>>> >>>> Smalltalk garbageCollect. 2 seconds asDelay wait. >>>> >>>> after the compilation phase. My guess is, that announcements build up >>>> (a simple printout showed 1 announcement instance before and 74 instances >>>> after the #evaluate:) and do stuff in the system that influence the process >>>> scheduling. For instance, a lot of those announcements will probably be >>>> weak and need to be finalized at some point. >>>> >>>> I donât have enough experience with the ClassBuilder to go on hunting >>>> but this should hopefully give you a good head start. >>>> >>> >>> >>>> >>>> >>>> For testing I used the following command line: >>>> >>>> ./pharo found_case.image eval "CommandLineTestRunner runPackages: >>>> #('Epicea' 'Kernel-Testsâ)" >>>> >>>> Install Epicea with >>>> >>>> ./pharo Pharo.image get Epicea 6.5 >>>> >>>> >>>> To isolate the test case I simply moved test classes from Epicea to a >>>> differently named package and once I had found the class I started >>>> excluding methods (e.g. with âself fail.â at the beginning). >>>> >>>> >>>> HTH, >>>> Max >>>> >>>> >>>> >>>> >>>> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com> wrote: >>>> >>>> Yes! with Max Leske we have been isolating the problem and we realized >>>> that a fresh image was enough: >>>> >>>> 1) >>>> curl get.pharo.org/50+vm | bash >>>> >>>> 2) >>>> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: >>>> {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. >>>> CommandLineTestRunner runPackages: #('Kernel-Tests')" >>>> >>>> Martin >>>> >>>> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>> >>>>> Then it must be that waiting on the delay never ends, which is >>>>> probably a problem all by itself. >>>>> >>>>> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr> >>>>> wrote: >>>>> > >>>>> > The fun thing is that I now get the same problem when integrating >>>>> the GT Tools update. >>>>> > >>>>> > After doing the update for issue 16957, the test run hangs with >>>>> > >>>>> > starting testcase: BlockClosureTest>>testBenchFor ... >>>>> > >>>>> > >>>>> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com> wrote: >>>>> >> >>>>> >> Hello, >>>>> >> >>>>> >> I'm trying to understand why this method hangs in certain >>>>> conditions*. What happens is that the #whileTrue: in the following method >>>>> is never cut. >>>>> >> >>>>> >> benchFor: duration >>>>> >> "Run me for duration and return a BenchmarkResult" >>>>> >> >>>>> >> "[ 100 factorial ] benchFor: 2 seconds" >>>>> >> >>>>> >> | count run started | >>>>> >> count := 0. >>>>> >> run := true. >>>>> >> [ duration wait. run := false ] forkAt: Processor >>>>> timingPriority - 1. >>>>> >> started := Time millisecondClockValue. >>>>> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >>>>> >> ^ BenchmarkResult new >>>>> >> iterations: count; >>>>> >> elapsedTime: (Time millisecondsSince: started) >>>>> milliSeconds; >>>>> >> yourself >>>>> >> >>>>> >> Strangely, I verified with several #logCr that the forked block >>>>> starts, but the #wait never ends. >>>>> >> ---> Maybe you see something I don't in the code. Any clue? >>>>> >> >>>>> >> I will continue trying to isolate the problem, but maybe you have >>>>> some idea. >>>>> >> >>>>> >> * the conditions to reproduce are: >>>>> >> 1) curl get.pharo.org/50+vm | bash >>>>> >> 2) ./pharo Pharo.image get Epicea 6.5 >>>>> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >>>>> >> >>>>> >> Notes: >>>>> >> - It doesn't hang when running from UI >>>>> >> - it doesn't hang when running less tests, like: >>>>> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >>>>> >> - it *does* hang even when removing all Epicea tests >>>>> >> - Epicea doesn't extend or override "kernel" behavior... >>>>> >> >>>>> >> Regards, >>>>> >> Martin >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > >

Nov. 17, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Max Leske

I can confirm that changing #styleInBackgroundProcess: to #style: fixes the problem on my machine. I had tracked down a version of GTInspector-Core (StefanReichhart.310) that exhibited the problem while the immediate ancestor didnât. Unfortunately the number of changes are huge in that version. Still, making the above change makes that version also work. My guess is, that this version leads to more of these styling requests. I logged the number of processes after running the examples: without the fix: 937 with the fix: 17 Sounds pretty compelling to me that this will mess with process schedulingâ¦ Cheers, Max > On 17 Nov 2015, at 22:56, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > We investigated more with Max and Aliaksey, and managed to reduce the bug to executing just two tests. > Just it would great if somebody else could reproduce it. You need to run commands only from console and save and quit the image after a change. > > The tests that need to be executed are GTInspectorExamplesTest>>#testAllExamples and BlockClosureTest>>#testBenchFor. > > Download the latest pharo image and remove GTInspectorExamplesTest>>#testGlobals, so that GTInspectorExamplesTest has one single test. > In GTInspectorExamplesTest>>#testAllExamples replace 'Object withAllSubclasses' with 'Dictionary asOrderedCollection' (it's not the actual examples that cause problems). > > If you execute now the tests, BlockClosureTest>>#testBenchFor will block for around 20 seconds. > > ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GTInspectorExamplesTest} named: 'x'. CommandLineTestRunner runClasses: {BlockClosureTest} named: 'y'" > > Now go to SHTextStyler>>styleInBackgroundProcess: and in the only onTimeout: block from the method add --> 'timeoute done' logCr. <--. > > Run again the tests and now the string 'timeoute done' is printed 4 times after 20 seconds. > > Replace in RubShoutStylerDecorator>>style: the call to #styleInBackgroundProcess: with #style: > > Running again the tests has no delay on BlockClosureTest>>#testBenchFor. > Reverting the changes to GTInspectorExamplesTest>>#testAllExamples and running all examples again leads to no delay on BlockClosureTest>>#testBenchFor (testing all examples can take a few minutes). > > Running all the tests as on the CI also does not block in BlockClosureTest>>#testBenchFor. > > ./pharo Pharo.image test --junit-xml-output '^(?!Metacello)[A-L].*' > (ignore the output about GTDummyExamplesInvalid which will disappear when the new version is integrated) > (running the tests takes a bit of time) > > I get the same behaviour if I first load issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> > > If anybody else can reproduce this behaviour then the zombie processes that appear while styling in rubric are somehow interfering with the delay scheduling mechanism. > > Cheers, > Andrei > > > > > On Mon, Nov 16, 2015 at 2:45 PM, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > Also you do not have to run it from the command line to reproduce the error. > You can just execute in a playground: > > CommandLineTestRunner runClasses: {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests'). > > But if you run the same tests using a script then there is no block: > > suite := TestSuite named: 'x'. > classes := {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} > asSortedCollection: [ :a :b | a name <= b name ]. > classes > do: [ :each | each addToSuiteFromSelectors: suite ]. > runner := TestRunner new . > Author uniqueInstance > ifUnknownAuthorUse: 'hudson' > during: [ runner > runSuite: suite ]. > > > > On Mon, Nov 16, 2015 at 2:25 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > Interestingly, if I change the delay in that method from 400 to 0 I get the same effect (namely, it doesnât hang). So maybe itâs a problem with delay scheduling from low priority processes? > > >> On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> >> Hi, >> >> Any news on this? >> >> Might be totally unrelated but I went back and searched for the the first version where [1] blocks. >> In my case the first version where it blocks is Pharo-40520. In Pharo-40519 it works ok. >> 40520 integrated https://pharo.fogbugz.com/f/cases/14993 <https://pharo.fogbugz.com/f/cases/14993> which does a lot of changes, but one changed that this issue did is introduced an async tasks for updating the scrolling in inspector. >> >> Next if in the latest version I change in GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' >> then #testBenchFor does not block. If I change the priority to the initial one it blocks again. At least on my machine this is consistent. >> >> Not sure if this fixes the bug on the CI but I updated issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to include this change. >> Can you try to integrate the issue and see if it still blocks. >> >> Cheers, >> Andrei >> >> >> >> [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" >> >> >> >> On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> I found a single test method I could use to narrow down the problem (be aware that this might not work for you. I have other (fresh) images where the issue never occurs). The method I used is EpRedoAndUndoVisitorTest>>testClassModification. >> >> I was able to mitigate the hang by making a small modification to the method EpUndoVisitor>>visitClassModification: Simply add >> >> 2 seconds asDelay wait. Smalltalk garbageCollect. >> >> or >> >> Smalltalk garbageCollect. 2 seconds asDelay wait. >> >> after the compilation phase. My guess is, that announcements build up (a simple printout showed 1 announcement instance before and 74 instances after the #evaluate:) and do stuff in the system that influence the process scheduling. For instance, a lot of those announcements will probably be weak and need to be finalized at some point. >> >> I donât have enough experience with the ClassBuilder to go on hunting but this should hopefully give you a good head start. >> >> >> >> For testing I used the following command line: >> >> ./pharo found_case.image eval "CommandLineTestRunner runPackages: #('Epicea' 'Kernel-Testsâ)" >> >> Install Epicea with >> >> ./pharo Pharo.image get Epicea 6.5 >> >> >> To isolate the test case I simply moved test classes from Epicea to a differently named package and once I had found the class I started excluding methods (e.g. with âself fail.â at the beginning). >> >> >> HTH, >> Max >> >> >> >> >>> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >>> >>> Yes! with Max Leske we have been isolating the problem and we realized that a fresh image was enough: >>> >>> 1) >>> curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >>> >>> 2) >>> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" >>> >>> Martin >>> >>> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>> Then it must be that waiting on the delay never ends, which is probably a problem all by itself. >>> >>> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> > >>> > The fun thing is that I now get the same problem when integrating the GT Tools update. >>> > >>> > After doing the update for issue 16957, the test run hangs with >>> > >>> > starting testcase: BlockClosureTest>>testBenchFor ... >>> > >>> > >>> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >>> >> >>> >> Hello, >>> >> >>> >> I'm trying to understand why this method hangs in certain conditions*. What happens is that the #whileTrue: in the following method is never cut. >>> >> >>> >> benchFor: duration >>> >> "Run me for duration and return a BenchmarkResult" >>> >> >>> >> "[ 100 factorial ] benchFor: 2 seconds" >>> >> >>> >> | count run started | >>> >> count := 0. >>> >> run := true. >>> >> [ duration wait. run := false ] forkAt: Processor timingPriority - 1. >>> >> started := Time millisecondClockValue. >>> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >>> >> ^ BenchmarkResult new >>> >> iterations: count; >>> >> elapsedTime: (Time millisecondsSince: started) milliSeconds; >>> >> yourself >>> >> >>> >> Strangely, I verified with several #logCr that the forked block starts, but the #wait never ends. >>> >> ---> Maybe you see something I don't in the code. Any clue? >>> >> >>> >> I will continue trying to isolate the problem, but maybe you have some idea. >>> >> >>> >> * the conditions to reproduce are: >>> >> 1) curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >>> >> 2) ./pharo Pharo.image get Epicea 6.5 >>> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >>> >> >>> >> Notes: >>> >> - It doesn't hang when running from UI >>> >> - it doesn't hang when running less tests, like: >>> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >>> >> - it *does* hang even when removing all Epicea tests >>> >> - Epicea doesn't extend or override "kernel" behavior... >>> >> >>> >> Regards, >>> >> Martin >>> > >>> >>> >>> >> >> > > >

Nov. 17, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Andrei Chis

We investigated more with Max and Aliaksey, and managed to reduce the bug to executing just two tests. Just it would great if somebody else could reproduce it. You need to run commands only from console and save and quit the image after a change. The tests that need to be executed are GTInspectorExamplesTest>>#testAllExamples and BlockClosureTest>>#testBenchFor. Download the latest pharo image and remove GTInspectorExamplesTest>>#testGlobals, so that GTInspectorExamplesTest has one single test. In GTInspectorExamplesTest>>#testAllExamples replace 'Object withAllSubclasses' with 'Dictionary asOrderedCollection' (it's not the actual examples that cause problems). If you execute now the tests, BlockClosureTest>>#testBenchFor will block for around 20 seconds. ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GTInspectorExamplesTest} named: 'x'. CommandLineTestRunner runClasses: {BlockClosureTest} named: 'y'" Now go to SHTextStyler>>styleInBackgroundProcess: and in the only onTimeout: block from the method add --> 'timeoute done' logCr. <--. Run again the tests and now the string 'timeoute done' is printed 4 times after 20 seconds. Replace in RubShoutStylerDecorator>>style: the call to #styleInBackgroundProcess: with #style: Running again the tests has no delay on BlockClosureTest>>#testBenchFor. Reverting the changes to GTInspectorExamplesTest>>#testAllExamples and running all examples again leads to no delay on BlockClosureTest>>#testBenchFor (testing all examples can take a few minutes). Running all the tests as on the CI also does not block in BlockClosureTest>>#testBenchFor. ./pharo Pharo.image test --junit-xml-output '^(?!Metacello)[A-L].*' (ignore the output about GTDummyExamplesInvalid which will disappear when the new version is integrated) (running the tests takes a bit of time) I get the same behaviour if I first load issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> If anybody else can reproduce this behaviour then the zombie processes that appear while styling in rubric are somehow interfering with the delay scheduling mechanism. Cheers, Andrei On Mon, Nov 16, 2015 at 2:45 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Also you do not have to run it from the command line to reproduce the > error. > You can just execute in a playground: > > CommandLineTestRunner runClasses: {GLMPagerMorphTest . GLMTreeMorphicTest. > GLMWatcherMorphicTest} named: 'x'. CommandLineTestRunner runPackages: > #('Kernel-Tests'). > > But if you run the same tests using a script then there is no block: > > suite := TestSuite named: 'x'. > classes := {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} > asSortedCollection: [ :a :b | a name <= b name ]. > classes > do: [ :each | each addToSuiteFromSelectors: suite ]. > runner := TestRunner new . > Author uniqueInstance > ifUnknownAuthorUse: 'hudson' > during: [ runner > runSuite: suite ]. > > > > On Mon, Nov 16, 2015 at 2:25 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Interestingly, if I change the delay in that method from 400 to 0 I get >> the same effect (namely, it doesnât hang). So maybe itâs a problem with >> delay scheduling from low priority processes? >> >> >> On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> Hi, >> >> Any news on this? >> >> Might be totally unrelated but I went back and searched for the the first >> version where [1] blocks. >> In my case the first version where it blocks is Pharo-40520. >> In Pharo-40519 it works ok. >> 40520 integrated https://pharo.fogbugz.com/f/cases/14993 which does a >> lot of changes, but one changed that this issue did is introduced an async >> tasks for updating the scrolling in inspector. >> >> Next if in the latest version I change in >> GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from >> 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' >> then #testBenchFor does not block. If I change the priority to the >> initial one it blocks again. At least on my machine this is consistent. >> >> Not sure if this fixes the bug on the CI but I updated issue 16957 >> <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to >> include this change. >> Can you try to integrate the issue and see if it still blocks. >> >> Cheers, >> Andrei >> >> >> >> [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: >> {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. >> CommandLineTestRunner runPackages: #('Kernel-Tests')" >> >> >> >> On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> I found a single test method I could use to narrow down the problem (be >>> aware that this might not work for you. I have other (fresh) images where >>> the issue never occurs). The method I used >>> is EpRedoAndUndoVisitorTest>>testClassModification. >>> >>> I was able to mitigate the hang by making a small modification to the >>> method EpUndoVisitor>>visitClassModification: Simply add >>> >>> 2 seconds asDelay wait. Smalltalk garbageCollect. >>> >>> or >>> >>> Smalltalk garbageCollect. 2 seconds asDelay wait. >>> >>> after the compilation phase. My guess is, that announcements build up (a >>> simple printout showed 1 announcement instance before and 74 instances >>> after the #evaluate:) and do stuff in the system that influence the process >>> scheduling. For instance, a lot of those announcements will probably be >>> weak and need to be finalized at some point. >>> >>> I donât have enough experience with the ClassBuilder to go on hunting >>> but this should hopefully give you a good head start. >>> >> >> >>> >>> >>> For testing I used the following command line: >>> >>> ./pharo found_case.image eval "CommandLineTestRunner runPackages: >>> #('Epicea' 'Kernel-Testsâ)" >>> >>> Install Epicea with >>> >>> ./pharo Pharo.image get Epicea 6.5 >>> >>> >>> To isolate the test case I simply moved test classes from Epicea to a >>> differently named package and once I had found the class I started >>> excluding methods (e.g. with âself fail.â at the beginning). >>> >>> >>> HTH, >>> Max >>> >>> >>> >>> >>> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> Yes! with Max Leske we have been isolating the problem and we realized >>> that a fresh image was enough: >>> >>> 1) >>> curl get.pharo.org/50+vm | bash >>> >>> 2) >>> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: >>> {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. >>> CommandLineTestRunner runPackages: #('Kernel-Tests')" >>> >>> Martin >>> >>> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> >>>> Then it must be that waiting on the delay never ends, which is probably >>>> a problem all by itself. >>>> >>>> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr> >>>> wrote: >>>> > >>>> > The fun thing is that I now get the same problem when integrating the >>>> GT Tools update. >>>> > >>>> > After doing the update for issue 16957, the test run hangs with >>>> > >>>> > starting testcase: BlockClosureTest>>testBenchFor ... >>>> > >>>> > >>>> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com> wrote: >>>> >> >>>> >> Hello, >>>> >> >>>> >> I'm trying to understand why this method hangs in certain >>>> conditions*. What happens is that the #whileTrue: in the following method >>>> is never cut. >>>> >> >>>> >> benchFor: duration >>>> >> "Run me for duration and return a BenchmarkResult" >>>> >> >>>> >> "[ 100 factorial ] benchFor: 2 seconds" >>>> >> >>>> >> | count run started | >>>> >> count := 0. >>>> >> run := true. >>>> >> [ duration wait. run := false ] forkAt: Processor >>>> timingPriority - 1. >>>> >> started := Time millisecondClockValue. >>>> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >>>> >> ^ BenchmarkResult new >>>> >> iterations: count; >>>> >> elapsedTime: (Time millisecondsSince: started) >>>> milliSeconds; >>>> >> yourself >>>> >> >>>> >> Strangely, I verified with several #logCr that the forked block >>>> starts, but the #wait never ends. >>>> >> ---> Maybe you see something I don't in the code. Any clue? >>>> >> >>>> >> I will continue trying to isolate the problem, but maybe you have >>>> some idea. >>>> >> >>>> >> * the conditions to reproduce are: >>>> >> 1) curl get.pharo.org/50+vm | bash >>>> >> 2) ./pharo Pharo.image get Epicea 6.5 >>>> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >>>> >> >>>> >> Notes: >>>> >> - It doesn't hang when running from UI >>>> >> - it doesn't hang when running less tests, like: >>>> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >>>> >> - it *does* hang even when removing all Epicea tests >>>> >> - Epicea doesn't extend or override "kernel" behavior... >>>> >> >>>> >> Regards, >>>> >> Martin >>>> > >>>> >>>> >>>> >>> >>> >> >> >

Nov. 17, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Esteban A. Maringolo

2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Esteban, > > I think EyeInspector needs to handle classes that don't inherit from > Object specially. Instead of asking the instance it should ask the class. > You should be able to use the Context methods for mirror primitives to > extract state without sending messages to the instance. Then the special > version of EyeInspector for ProtoObject subclasses can ask this like Yes, an special inspector for ProtoObject subclasses would be required, but I couldn't find one already suited for this purpose. > (thisContext objectClass: object) isIndexable ifTrue: > [size := thisContext objectSize: object] I don't know if your code was meant to be accurate or just a guideline of how this could be implemented, but Context doesn't implement #objectClass: nor #objectSize: > Basically both the Inspector and the Debugger's execution simulation > machinery need to treat encapsulators such as MessageArchiver with kid > gloves. One *must not* cause inspecting or debugging to send messages > through the encapsulator. Instead, all access to the object should be > through primitives that don't send messages to the objects. I know that dealing with Proxies and similar objects is tricky, I had to deal with my own subclasses of ProtoObject in Dolphin, but there the class implemented all that was needed to interact with the environment tools. Hiwever, to me all this is a kind of black magic, I read the blue book years ago and can understand it, but I do understand it as I understand the mechanics of my car, however when it breaks down I take it to the specialist :) Esteban A. Maringolo

Nov. 17, 2015

Re: [Pharo-dev] A Question about Metacello's #repository:

by Sven Van Caekenberghe

Hi Dale, Thanks for the elaborate answer. Yes, I think that BaselineOf is what I was looking for, I will experiment with it. I do suspect that a Baseline can only be loaded using the Metacello API, not using the Pharo config handler which seems to fall back to Gofer. Sven > On 17 Nov 2015, at 20:08, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Sven, > > I've read through the follow-on messages to this post and I'm not quite sure I know what you are asking, so I will just reply here ... > > On 11/17/2015 06:12 AM, Sven Van Caekenberghe wrote: >> Hi, >> >> I have a question about the way repositories are specified in Metacello (i.e. by means on #repository:). >> >> Say I use FileTree where the files come from a classic VCS or just from some archive. Using ZeroConf I can get an image+vm, etc. I can use the config command line handler to load the configuration from a local file directory (I haven't tried this yet, but I assume no scheme results in a MCDirectoryRepository). So far so good. > Okay I'll put in some examples here to make sure that we're on the same page. First here's a linek[1] to the documentation for the various schemes that can be used as Metacello repository descriptions (the arg to the #repository: message). > > If you want to use FileTree for your local repository then the repository description has the form: > > filtree://<full path to directory> > > For an MCDirectoryRepository, the repository description has the form: > > client://<full path to directory> > > or > > <full path to directory> > > [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr… >> >> The question is, what do I put in as argument to #repository: in my baseline ? >> >> baseline1: spec >> <version: '1-baseline'> >> >> spec for: #common do: [ >> spec >> blessing: #baseline; >> repository: 'http://mc.stfx.eu/Neo'; >> package: 'Neo-Console-Core'; >> group: 'default' with: #('Neo-Console-Core'); >> group: 'Core' with: #('Neo-Console-Core') ] > Okay, the baseline1: above is from your ConfigurationOfNeo configuration, correct? > > Since you are referencing `http://mc.stfx.eu/Neo`, I assume that the primary repository is on http://mc.stfx.eu, correct? > > When you ask "what do I put in as argument to #repository: in my baseline?", I am confused ... > > Perhaps my assumptions are incorrect? I assume that the above came from a ConfigurationOfNeo and that the primary location is `http://mc.stfx.eu/Neo`. >> Obviously not a remote http repository. But also not an absolute path, since I do not know where the user placed the files. > > If the Neo project's primary repository is `http://mc.stfx.eu/Neo`, then how does the user get a local copy of the repository - filetree:// or client://? > >> Ideally, it should be possible to leave out repository and let it resolve to wherever the configuration was located. Can that be done ? Or is there another way to do this ? >> > > The BaselineOf was invented to solve this particular problem and I will talk about github/git scenario, since the question of "how does the user get a local copy of the repository?" has a straightforward answer.... > > To start with let's use the Sample project[2] as an example and lets look how the project is specified in the BaselineOfSample>>baseline:[3]: > > baseline: spec > <baseline> > spec > for: #'common' > do: [ > spec package: 'Sample-Core'. > spec package: 'Sample-Tests' with: [ spec requires: 'Sample-Core' ]. > spec > group: 'default' with: #('Core'); > group: 'Core' with: #('Sample-Core'); > group: 'Tests' with: #('Sample-Tests') ] > > Note that there is no repository: specification .... which makes me think that this is the answer to the question that you are asking: >> It should be possible to leave out repository and let it resolve to wherever the configuration was located. > > A BaselineOf sets the internal repository: to the location where the BaselineOfSample spec was loaded from. So you use the following expression to load a BaselineOf into your image: > > Metacello new > baseline: 'Sample'; > repository: 'filetree://<fulll-path-to-directory>; > load. > > Given that the user knows where she's cloned the https://github.com/dalehenrich/sample.git repository, then it is reasonable for the developer to know how to load the project from that location ... > > However, this is not a complete answer to the the overall problem ... > > For example a corollary to your question is: > >> How do I ensure that other projects that reference the Sample project load from my local clone? > > So If you have a reference to the Sample project in another project, the reference is likely to look like the following: > > spec > baseline: 'Sample'; > repository: 'github://dalehenrich/sample:master/repository'; > loads: 'Core'. > > Here we've got a reference to the github repo, but we'd like to use the local filetree:// clone. There is a Metacello Scripting API command that you can use to inform Metacello that the local filetree:// clone should be used: > > Metacello new > baseline: 'Sample'; > repository: 'filetree://<fulll-path-to-directory>; > lock. > > Again we're using the full-path, but the developer is the one that knows a) the path to the local clone and b) whether or not the local clone should be used ... > > Now I will admit that having to remember and keep track of making sure that the `lock` expression get's run in each image, can be a bit difficult .... > > In tODE I've addressed this issue by creating a project entry object that is shared by "all images" and specifies not only the particulars of project locking but includes additional information about what how you want a particlar project loaded in "all images" (i.e., a specification for the `loads` expression as well) ... > > So I think I've addressed your question, but maybe I've completely missed your point:) > > Dale > > [2] https://github.com/dalehenrich/sample > [3] https://github.com/dalehenrich/sample/blob/master/repository/BaselineOfSamp… >

Nov. 17, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50451 Home: https://github.com/pharo-project/pharo-core

Nov. 17, 2015

[pharo-project/pharo-core] a2863e: 50451

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a2863ee6cdbcf4d0953a159559304892cf52af11 https://github.com/pharo-project/pharo-core/commit/a2863ee6cdbcf4d0953a1595… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-17 (Tue, 17 Nov 2015) Changed paths: A Morphic-Widgets-Basic.package/ButtonClicked.class/README.md A Morphic-Widgets-Basic.package/ButtonClicked.class/definition.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/adding/addUpAction_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/activate.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/addDownAction_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/addUpAction_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/extent_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/handlesMouseDown_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/handlesMouseOverDragging_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/handlesMouseOver_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/mouseDown_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/mouseEnterDragging_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/mouseEnter_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/mouseLeaveDragging_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/mouseLeave_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/mouseUp_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/passivate.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/privateMoveBy_.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/removeDownActions.st R Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/as yet unclassified/removeUpActions.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/handlesMouseDown_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/handlesMouseOverDragging_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/mouseDown_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/mouseEnterDragging_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/mouseEnter_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/mouseLeaveDragging_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/mouseLeave_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/mouseUp_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/geometry/extent_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/recategorized/handlesMouseOver_.st A Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/recategorized/privateMoveBy_.st A Morphic-Widgets-Windows.package/extension/MultistateButtonMorph/instance/activate.st A Morphic-Widgets-Windows.package/extension/MultistateButtonMorph/instance/passivate.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50450.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50451.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50450.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50451.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/README.md A SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/definition.st A SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/instance/accessing/label.st A SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/instance/execution/execute.st A SmartSuggestions.package/SugsBreakConditionSuggestion.class/README.md A SmartSuggestions.package/SugsBreakConditionSuggestion.class/definition.st A SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/accessing/label.st A SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/breakpoints/breakpointForCondition.st A SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/execution/execute.st A SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/execution/isValidForContext.st A SmartSuggestions.package/SugsBreakOnceSuggestion.class/README.md A SmartSuggestions.package/SugsBreakOnceSuggestion.class/definition.st A SmartSuggestions.package/SugsBreakOnceSuggestion.class/instance/accessing/label.st A SmartSuggestions.package/SugsBreakOnceSuggestion.class/instance/execution/execute.st A SmartSuggestions.package/SugsBreakOnceSuggestion.class/instance/execution/isValidForContext.st M SmartSuggestions.package/SugsBreakpointSuggestion.class/README.md M SmartSuggestions.package/SugsBreakpointSuggestion.class/instance/accessing/label.st R SmartSuggestions.package/SugsBreakpointSuggestion.class/instance/breakpoints/breakpointForCondition.st R SmartSuggestions.package/SugsBreakpointSuggestion.class/instance/breakpoints/breakpointSelectionMenu.st A SmartSuggestions.package/SugsBreakpointSuggestion.class/instance/breakpoints/selectedNodeHasBreakpoint.st R SmartSuggestions.package/SugsBreakpointSuggestion.class/instance/breakpoints/selectedNodeHasMetalink.st R SmartSuggestions.package/SugsBreakpointSuggestion.class/instance/execution/execute.st A SmartSuggestions.package/SugsSuggestionFactory.class/class/as yet unclassified/cleanUp.st R SmartSuggestions.package/SugsSuggestionFactory.class/class/methods/createBreakAtLineCommand.st A SmartSuggestions.package/SugsSuggestionFactory.class/class/methods/createBreakCommand.st A SmartSuggestions.package/SugsSuggestionFactory.class/class/methods/createBreakConditionCommand.st A SmartSuggestions.package/SugsSuggestionFactory.class/class/methods/createBreakOnceCommand.st Log Message: ----------- 50451 17010 MultistateButtonMorph to use announcement instead of #triggerEvent: https://pharo.fogbugz.com/f/cases/17010 17037 Simplify suggestions for Breakpoints https://pharo.fogbugz.com/f/cases/17037 http://files.pharo.org/image/50/50451.zip

Nov. 17, 2015