November 2015 - Pharo-dev - lists.pharo.org

News about FastTable

by Ferlicot D. Cyril

Hi everyone! I just wanted to say that I added a first version of Tree in FastTable and I corrected some bugs. If someone want to try it and give some feedback you can see some examples on the latest Pharo 5 in FTExamples class. With Usman we also worked on the glamour version of FastTable begun by Esteban. You can see some examples of FastList, FastTable, FastOutlineList and FastTree in the GLMExamplesBrowser after executing this: (ConfigurationOfFastTable project version: #stable) load: #glamour Every feedback is welcome :) -- Cyril Ferlicot (cyril.ferlicot(a)synectique.eu) http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Nov. 18, 2015

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Nicolai Hess

2015-11-17 14:21 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Nicolai, > Thanks for sharing an updated cs. I can confirm that this version DOES > work and fixes my VM crash as well. > I have updated https://pharo.fogbugz.com/f/cases/13854 > > Thanks Nicolai!! > Hi Mariano, I am glad that it works! I reviewed the fix again (wasn't sure if all changes were needed - but yes they are) and added a slice for issue 13854. If it passes the tests and works in Pharo 5.0, we can create another issue and slice for Pharo 4.0 too. nicolai > > On Tue, Nov 17, 2015 at 6:36 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2015-11-17 1:35 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> >>> >>> On Mon, Nov 16, 2015 at 8:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> 2015-11-16 22:16 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com >>>> >: >>>> >>>>> >>>>> >>>>> On Mon, Nov 16, 2015 at 5:37 PM, Mariano Martinez Peck < >>>>> marianopeck(a)gmail.com> wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> So I found out the exact method that is causing the VM crash. If I >>>>>> compile the method with Opal, it crashes the VM when I execute the code >>>>>> that use that method. If I compile it with old compiler, the code does work >>>>>> correctly. >>>>>> >>>>>> I tried comparing both compiled methods compiled from both Compilers >>>>>> and I cannot see real differences. They both seem to have similar (same?) >>>>>> bytecodes, literals, decompiled string, etc. The only difference I see is >>>>>> in #frameSize (old compiler one is 16 while Opal one is 56). >>>>>> Any idea what else can I check/compare? >>>>>> >>>>>> I also tried in Pharo 5.0 but same results. >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> >>>>> OK, it seems my issue may be related to: >>>>> https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li… >>>>> But the attached cs in there does NOT fixes mine. >>>>> >>>> >>>> You need to: >>>> switch to old compiler in settings >>>> >>> >>> I was doing that via >>> >>> Smalltalk compilerClass: XXX. >>> >>> (I didn't know there was setting). >>> >>> >>>> load change set fix_closure_stack_frame_size_computation.1.cs (not >>>> fix_closure_stack_frame_size_computation.2.cs!) >>>> switch back to opal >>>> recompile all >>>> >>> >>> Yes, I did that. >>> >>> >>>> But the change set is old, and does not work for recent images (not >>>> even for pharo 4.0 release), because there are many >>>> changes for the bytecodegenerator. >>>> >>> >>> Uhhhh. Yes, I saw some. For example, i changed from >>> IRAbstractBytecodeGenerator to IRBytecodeGenerator >>> >>> Do you think we can re-create your fix with latest 4.0 or 5.0 so that I >>> can see if the issue was the same? >>> >> >> >> you can try this one, (I just changed all the code that makes this run >> for pharo 4, but I need more time to check if all of >> this code is necessary - and correct) : >> fix_closure_stack_size_4.0.cs (tested with Pharo 4.0 40624). >> >> >>> >>> >>> >>>> >>>> >>>> >>>>> I can confirm it's a problem with the number of temp vars defined. As >>>>> soon as I remove any of the temp vars, it works again. >>>>> >>>>> The method is this (a bit ugly, yes) pasted below. >>>>> But the key point is: *As soon as I remove ANY tempVar the code >>>>> starts to work again.* >>>>> >>>>> Any clues? >>>>> >>>>> createZacksAccountingRulesFromTable: t1 >>>>> | t2 t3 t4 | >>>>> t2 := FaUserContextInformation current dbAccessor >>>>> db: 'zacks' >>>>> getTableAccessorOn: t1 >>>>> indexOn: nil. >>>>> t3 := OrderedCollection new. >>>>> t4 := FaFileTranscript named: 'create-zacks-rules.txt'. >>>>> FaApplicationDB session >>>>> inUnitOfWorkDo: [:t5 | >>>>> | t6 | >>>>> t6 := FaUserContextInformation current userDisplayName. >>>>> t2 >>>>> doWithRowDictionaries: [:t7 | (t7 at: 'label') >>>>> == FaNullDatum instance >>>>> ifFalse: [{{'Annual'. 'ZACKS_A_'}. {'Quarterly'. 'ZACKS_Q_'}} >>>>> do: [:t8 | >>>>> *| t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 |* >>>>> t4 crLog: t8 first. >>>>> t9 := t8 at: 1. >>>>> t16 := t7 at: 'label'. >>>>> t18 := t7 at: 'TTM'. >>>>> t10 := t7 at: 'quuveKeyEquivalent'. >>>>> t12 := (t7 at: 'zacksKey') asUppercase. >>>>> t13 := 'ZACKS_' , t12. >>>>> t14 := 'ZACKS_Q_' , t12. >>>>> t15 := 'ZACKS_A_' , t12. >>>>> t11 := (t8 at: 2) >>>>> , t12. >>>>> t17 := FaAccountingRule new label: t16; >>>>> selector: t13 asSymbol; >>>>> context: 'Zacks' , t9 , 'Override'; >>>>> argumentTypesSpecification: '{FaProcessorProxy}'; >>>>> returnTypeSpecification: 'FaDatedFnSeries'; >>>>> isReturnValueConstant: true; >>>>> action: (self >>>>> getZacksDataAtScriptForCache: t11 >>>>> forZacksKey: t11 >>>>> fromSet: t9); >>>>> comment: (nil >>>>> ifNil: [t16]); >>>>> isSensitive: true; >>>>> definedBy: t6; >>>>> ownedBy: t6; >>>>> lastEditBy: t6; >>>>> yourself. >>>>> t5 register: t17. >>>>> t3 add: 'Successfully added ' , t17 selector , '/' , t17 context. >>>>> t4 crLog: t3 last]]]]. >>>>> ^ t3 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >>>>>> marianopeck(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess < >>>>>>>> nicolaihess(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Hi Mariano, if you know the method that may cause this crash can >>>>>>>>> you check >>>>>>>>> if it works if you recompile this method with the old compiler, >>>>>>>>> maybe this issue is responsible - wrong stack frame size : >>>>>>>>> 13854 >>>>>>>>> <https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li…> >>>>>>>>> frameSize calculated wrongly for #lineSegmentsDo: >>>>>>>>> >>>>>>>>> >>>>>>>> Hi Nicolai, >>>>>>>> >>>>>>>> Thanks for the pointer. I tried with your fix and I still get the >>>>>>>> same results (even after recompiling). >>>>>>>> However...if I swap back to old Compiler rather than OpalCompiler >>>>>>>> and I recompile everything, then I do not have anymore the crash. >>>>>>>> So it's definitively something related to Opal compilation, and >>>>>>>> probably, related to closures compilation. >>>>>>>> I will see if I find other opal issues opened in 4.0. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-11-16 17:00 GMT+01:00 Mariano Martinez Peck < >>>>>>>>> marianopeck(a)gmail.com>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> I am debugging a Pharo VM crash I am having and I cannot figure >>>>>>>>>> out what it is exactly. I suspect it might be related to block closures >>>>>>>>>> compilation but I am not sure. I have a reproducible crash test under Pharo >>>>>>>>>> 4.0 and OSX. >>>>>>>>>> >>>>>>>>>> I built a VM in debug mode and I run it via gdb. This is the kind >>>>>>>>>> of info I am able to see: >>>>>>>>>> >>>>>>>>>> *Program received signal SIGSEGV, Segmentation fault.* >>>>>>>>>> *0x000ab66b in updatePointersInRangeFromto (memStart=924623948, >>>>>>>>>> memEnd=928201420) at >>>>>>>>>> /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40444* >>>>>>>>>> *40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {* >>>>>>>>>> *(gdb) call printAllStacks()* >>>>>>>>>> *Process 0x30e228c4 priority 40* >>>>>>>>>> *0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction >>>>>>>>>> class* >>>>>>>>>> *0xbffb2e30 M BlockClosure(FaMemoryStoreSession)>register: >>>>>>>>>> 0x371d0968: a(n) BlockClosure* >>>>>>>>>> *0xbffb2e4c M INVALID RECEIVER>register: 0x371cfd54: a(n) bad >>>>>>>>>> class* >>>>>>>>>> >>>>>>>>>> *(callerContextOrNil == (nilObject())) || >>>>>>>>>> (isContext(callerContextOrNil)) 48626* >>>>>>>>>> *0x3721e1f0 is not a context* >>>>>>>>>> *0x371c34b4 is not a context* >>>>>>>>>> >>>>>>>>>> And another crash: >>>>>>>>>> >>>>>>>>>> *Program received signal SIGSEGV, Segmentation fault.* >>>>>>>>>> *0x000ab66b in updatePointersInRangeFromto (memStart=924677864, >>>>>>>>>> memEnd=928262300) at >>>>>>>>>> /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40444* >>>>>>>>>> *40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {* >>>>>>>>>> *(gdb) call printAllStacks()* >>>>>>>>>> *Process 0x30e228c4 priority 40* >>>>>>>>>> *0xbffb2de0 M INVALID RECEIVER>initialize 0x3722b9a0: a(n) bad >>>>>>>>>> class* >>>>>>>>>> *0xbffb2df8 M FaAction class(Behavior)>new 0x20ebb104: a(n) >>>>>>>>>> FaAction class* >>>>>>>>>> *0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction >>>>>>>>>> class* >>>>>>>>>> *0xbffb2e30 M INVALID RECEIVER>register: 0x371ddee0: a(n) bad >>>>>>>>>> class* >>>>>>>>>> *0xbffb2e4c M INVALID RECEIVER>register: 0x371dd328 is in old >>>>>>>>>> space* >>>>>>>>>> >>>>>>>>>> *(callerContextOrNil == (nilObject())) || >>>>>>>>>> (isContext(callerContextOrNil)) 48626* >>>>>>>>>> *0x3722b750 is not a context* >>>>>>>>>> *[New Thread 0x1b43 of process 5886]* >>>>>>>>>> *[New Thread 0x1d2f of process 5886]* >>>>>>>>>> *[New Thread 0x1f07 of process 5886]* >>>>>>>>>> *[New Thread 0x1e07 of process 5886]* >>>>>>>>>> >>>>>>>>>> From what I can see in *#printActivationNameFor: aMethod >>>>>>>>>> receiver: anObject isBlock: isBlock firstTemporary: maybeMessage* >>>>>>>>>> It looks like if the memory address is not an OOP, nor forwarding >>>>>>>>>> pointer nor... >>>>>>>>>> >>>>>>>>>> It also seems like the above stack I can get is not the real >>>>>>>>>> cause but a side effect that makes GC to crash >>>>>>>>>> (#updatePointersInRangeFromto) >>>>>>>>>> >>>>>>>>>> As said, I have a way to reproduce the crash, and I already have >>>>>>>>>> the VM compiled in debug and gdb running. I can also attach the full output >>>>>>>>>> of the gdb stack. >>>>>>>>>> >>>>>>>>>> BTW.... in the output of the gdb I see lots of printings like: >>>>>>>>>> >>>>>>>>>> *(numStack + ReceiverIndex) < (lengthOf(theContext)) 45421* >>>>>>>>>> *(ReceiverIndex + contextSize) < (lengthOfbaseHeaderformat(oop, >>>>>>>>>> header2, fmt)) 40416* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Any pointer is appreciated. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mariano >>>>>>> http://marianopeck.wordpress.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 18, 2015

Re: [Pharo-dev] Resolving issue 16760

by Nicolai Hess

2015-11-04 21:01 GMT+01:00 monty <monty2(a)programmer.net>: > > https://pharo.fogbugz.com/f/cases/16760/Dictionary-breaks-when-comparing-id… > > The newest fix that changes Dictionary>>= and related = methods to use > species == tests can go in. or I can redo the older more complex fix that > allows some cross class equality comparisons (like between Dictionary and > SmallDictionary and between IdentityDictionary and > OrderedIdentityDictionary). But the current behavior is clearly wrong and > needs to be changed. > > please, we need more people reviewing and commenting on this issue. Question, should we: 1. Integrate (may break external code, or not - I don't know) 2. Modify this solution, so it may not break existing code I am for (1) but I really don't know. What would you expect by comparing two dictionaries with the same elements, by #=, if one is a Dictionary and the other one a SmallDictionary? (Maybe SmallDictionaries aren't often used?)

Nov. 18, 2015

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