- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]
by GitHub Dec. 4, 2015

Dec. 4, 2015

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

1 0

[pharo-project/pharo-core] 03087c: 50484
by GitHub Dec. 4, 2015

Dec. 4, 2015

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 03087c82c794c6db8cb3a15435a9e920e8b99cc9 https://github.com/pharo-project/pharo-core/commit/03087c82c794c6db8cb3a154… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-04 (Fri, 04 Dec 2015) Changed paths: M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version222_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version232_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version142_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version342_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version241_.st A GT-Inspector.package/GTExample.class/instance/private/resultCached.st M GT-Inspector.package/GTExample.class/instance/private/resultCached_.st M GT-Inspector.package/GTExampleEvaluator.class/instance/private/process_withArguments_.st A GT-Inspector.package/GTExampleNautilus.class/class/private/methodUpdated_with_.st M GT-Inspector.package/GTExampleNautilus.class/instance/private/examples_.st M GT-Inspector.package/GTExampleNautilus.class/instance/private/examples_do_.st A GT-Inspector.package/GTExampleNautilusAction.class/class/private/iconForMethod_result_.st M GT-Inspector.package/GTExampleNautilusAction.class/instance/private/iconForMethod_.st M GT-Inspector.package/GTExampleNautilusAction.class/instance/private/resultForMethod_.st M GT-Inspector.package/GTExampleResult.class/instance/ui/gtDisplaySummaryOn_.st M GT-Inspector.package/GTExampleTestCase.class/instance/private/runExample_fromContainer_.st A GT-InspectorExtensions-Core.package/extension/KMDispatcher/instance/gtAllKeyCategoryPairs.st M GT-InspectorExtensions-Core.package/extension/KMDispatcher/instance/gtInspectorMappingsIn_.st A GT-SpotterExtensions-Core.package/extension/BlockClosure/instance/gtSpotterCodePreviewIn_.st A GT-SpotterExtensions-Core.package/extension/CompiledMethod/instance/spotterForBytecodesFor_.st A GT-SpotterExtensions-Core.package/extension/Dictionary/instance/spotterForKeysFor_.st A GT-SpotterExtensions-Core.package/extension/KMDispatcher/instance/spotterForKeysFor_.st A GT-SpotterExtensions-Core.package/extension/KMKeymap/instance/gtSpotterCodePreviewIn_.st A GT-SpotterExtensions-Core.package/extension/Morph/instance/spotterForKeysFor_.st A GT-SpotterExtensions-Core.package/extension/Morph/instance/spotterForSubmorphsFor_.st A GT-SpotterExtensions-Core.package/extension/RBProgramNode/instance/gtSpotterCodePreviewIn_.st M Glamour-Morphic-Brick.package/GLMPhlowPharoMethodBrick.class/instance/phlow/installEntity.st A Glamour-Morphic-Brick.package/GLMPhlowTextBrick.class/instance/accessing/selectionInterval.st A Glamour-Morphic-Brick.package/GLMPhlowTextBrick.class/instance/accessing/selectionInterval_.st M Glamour-Morphic-Brick.package/GLMPhlowTextBrick.class/instance/phlow/installEntity.st M Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/draw.st M Rubric.package/RubSmalltalkEditor.class/instance/private/modelCurrentSelectedClass.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50483.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50484.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50483.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50484.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50484 ConfigurationOfRubric http://files.pharo.org/image/50/50484.zip

1 0

SqueakElib project
by Robert Withers Dec. 4, 2015

Dec. 4, 2015

Good morning, Here is a brief writeup of the SqueakElib project and its direction. https://github.com/SqueakCryptographySquad/Cryptography-Common/wiki/SqueakE…. All new squad members welcome. Regards, Robert

1 0

changes view broken
by Nicolai Hess Dec. 4, 2015

Dec. 4, 2015

Oh oh, I broke the changes view. For example, open Repository of Rubric, select a latest package, press changes -> no result merge -> shows the diff caused by my fix for 17148 <https://pharo.fogbugz.com/f/cases/17148/Seeing-changes-and-then-merge-them-…> Seeing changes and then merge them generates merge conflicts sorry for that.

1 0

[issue tracker] action of package maintainers needed
by Marcus Denker Dec. 4, 2015

Dec. 4, 2015

Hi, We have again 6 issues that are âfixed upstreamâ https://pharo.fogbugz.com/f/filters/138/fixed-upstream <https://pharo.fogbugz.com/f/filters/138/fixed-upstream> The maintainers of these packages should not forget to push a current version into Pharo. The easier you do that, the earlier the version gets tested. And the earlier everyone actually benefits from the fixes and improvements. Another effect is that people tend to wait till everything they did is integrated. So if you want more good things from where the fixes come from, make sure that they get to a final âDONEâ state fastâ¦ Marcus

1 0

[pharo-project/pharo-core]
by GitHub Dec. 4, 2015

Dec. 4, 2015

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

1 0

VoyageMongo and cache compaction
by Holger Freyther Dec. 4, 2015

Dec. 4, 2015

Hi guys, I started to run a production load with VoyageMongo and every day the maximum latency of it goes up a bit. Today I looked at the production system and the VOMongoRepository and the VOMongoCache and saw that the cache had around 90 entries in the "objects" WeakValueDictionary all pointing to nil 34k entries in the timestamp dictionary This is a write "heavy" workload but at no point in time more than a couple of objects will be in the cache. So somehow the VOMongoCache>>#compactIfNeeded check does not trigger and/or given the difference in the sizes of the dictionary it is possible that some of the dead objects are not removed from the timestamp cache. I have accidentally restarted one image and flushed the cache on the other but if it is of any help I can wait a day or two and then look at the compactLimit again. But even right now in one image the compactLimit is 3277, the objects dictionary has 142 entries and the timestamp one 272. Is this a known issue? Does this look like "normal"/"good" operation? kind regards holger

2 3

Explanation how to use GT Debugger and GT SUnit Debugger with DarkThem in Pharo 4.0 [was] Using Re: [Moose-dev] Re: showing a diff on #assert:equals:
by Mariano Martinez Peck Dec. 3, 2015

Dec. 3, 2015

Andrei... you rock!!! It works. I copy paste it here so that others can take advantage too. Look also the attached screenshot :) Doru...you were right..you THINK you don't need a any other tool, until someone comes with a little example as a debugger for test cases...wow... those are moldable tools!!!! The code I used (with the hack of the override) is this: http://ws.stfx.eu/ME85BCYIPSU8 (of course, I published the code via the playground hahahha) Thank you! On Thu, Dec 3, 2015 at 3:53 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Ahh. Wrong order for loading packages in my previous instructions. > You should load first DebuggerExtensions and then the debuggers. > > Cheers, > Andrei > > On Thu, Dec 3, 2015 at 7:39 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Thu, Dec 3, 2015 at 1:15 PM, Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> >>> Hi Mariano, >>> >>> To get it working in Pharo 4 you should: >>> >>> - load GT-Debugger-AndreiChis.249 from AndreiChis/GTDebuggerPharo4 >>> - load GT-SUnitDebugger-AndreiChis.18 from AndreiChis/GTDebuggerPharo4 >>> - load DebuggerExtensions-AndreiChis.9 from Pharo/Debugger >>> - register the debuggers: >>> - GTGenericStackDebugger registerExtraToolsOn: Smalltalk tools. >>> - GTSUnitDebugger registerExtraToolsOn: Smalltalk tools >>> >>> Like this the spec debugger is still the default one and you still have >>> to start GTDebugger from the pre debug window. >>> You can register GTDebugger as the default one (GTGenericStackDebugger >>> registerToolsOn: Smalltalk tools) but it will not switch to the SUnit >>> extension automatically (that only works in Pharo 5). You'll need to switch >>> to it from the context menu of the stack. >>> >>> Let me know how it goes. >>> >>> >> Hi Andrei, >> >> I tried what you said with the following script in a virgin 4.0: >> >> Gofer it >> smalltalkhubUser: 'AndreiChis' project: 'GTDebuggerPharo4'; >> version: 'GT-Debugger-AndreiChis.250'; >> version: 'GT-SUnitDebugger-AndreiChis.19'; >> load. >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'Debugger'; >> version: 'DebuggerExtensions-AndreiChis.9'; >> load. >> (Smalltalk at: #GTGenericStackDebugger) registerExtraToolsOn: Smalltalk >> tools. >> (Smalltalk at: #GTSUnitDebugger) registerExtraToolsOn: Smalltalk tools. >> >> >> However, as soon as I try to debug something I get the following error. >> It seems I am missing the class GTSUnitActivationPredicate. >> >> >> UndefinedObject(Object)>>doesNotUnderstand: #new >> GTSUnitDebugSession class>>activationPredicate >> GTSUnitDebugger class>>handlesContext: >> [ :aPair | aPair key handlesContext: aContext ] in >> PharoCommonTools(ToolRegistry)>>debuggersWithRanksForContext: in Block: [ >> :aPair | aPair key handlesContext: aContext ] >> OrderedCollection>>select: >> PharoCommonTools(ToolRegistry)>>debuggersWithRanksForContext: >> PharoCommonTools(ToolRegistry)>>debuggerDispatcherFor: >> GTTemporaryPreDebugChangeDebuggerAction>>executeAction >> GTTemporaryPreDebugChangeDebuggerAction(DebugAction)>>execute >> .... >> >> Any idea? >> >> Weird thing is that I am NOT opening a debugger of a SUnit.. but a >> regular debugger. >> Maybe the registration part of your script is wrong? >> >> Thanks in advance, >> >> >>> Cheers, >>> Andrei >>> >>> On Wed, Dec 2, 2015 at 5:37 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Wed, Dec 2, 2015 at 1:31 PM, Andrei Chis <chisvasileandrei(a)gmail.com >>>> > wrote: >>>> >>>>> >>>>> >>>>> On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck < >>>>> marianopeck(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis < >>>>>> chisvasileandrei(a)gmail.com> wrote: >>>>>> >>>>>>> I think it's not straightforward to get it to work in Pharo 4. >>>>>>> I'm not sure you can load the latest version of GTools into Pharo 4. >>>>>>> >>>>>>> >>>>>> That's what I was thinking :( >>>>>> >>>>>> >>>>>>> You can load just the packages for GT-Debugger, GT-SUnitDebugger and >>>>>>> DebuggerExtensions, however, it would not work by default as there were >>>>>>> some changes to the API of the debugger. You'll also need to backport >>>>>>> those changes, but that might be more work. >>>>>>> If you really want to use it I could make a version that uses the >>>>>>> old API. >>>>>>> >>>>>>> >>>>>> I don't want you loose much time if I am the only one wanting this. >>>>>> Personally, for my real client-paying job I won't be able to move to 5.0 >>>>>> until it's released. But then I can wait. >>>>>> >>>>> >>>>>> However, I would like to at least give it a quick try to the dirty >>>>>> solution. As you said, maybe loading those 3 packages and bringing some >>>>>> slices (the ones of the debugger api might work). mmmmm but I guess this >>>>>> will break the Spec Debugger right? Unless the slides also updates that.. >>>>>> Do you remember which were the debugger changes? >>>>>> >>>>> >>>>> There are 4 slices that you need to load >>>>> I tried loading the first one (https://pharo.fogbugz.com/f/cases/17069) >>>>> and my image hangs... >>>>> >>>>> I'll see tomorrow if I can make a quick and dirty refactoring to get >>>>> it to work just for Pharo 4. >>>>> >>>>> >>>> Super !!! Let us know! >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck < >>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis < >>>>>>>> chisvasileandrei(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> I splitted the code pane into two to also show the setUp/tearDown >>>>>>>>> code. >>>>>>>>> A button/checkbox to hide/show this pane could be next. >>>>>>>>> >>>>>>>>> >>>>>>>> Coool!!! >>>>>>>> Andrei, let me ask, would this work in Pharo 4.0? If true, then I >>>>>>>> should only load gt debugger or a new version of the whole GT suite ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Andrei >>>>>>>>> >>>>>>>>> On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < >>>>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka < >>>>>>>>>> juraj.kubelka(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Dec 1, 2015, at 17:47, Andrei Chis < >>>>>>>>>>> chisvasileandrei(a)gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Mariano >>>>>>>>>>> >>>>>>>>>>> On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < >>>>>>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < >>>>>>>>>>>> chisvasileandrei(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < >>>>>>>>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Uhhh that's very cool. Quick question, what happens if the >>>>>>>>>>>>>> textual representation of the actual vs expected is the same yet the >>>>>>>>>>>>>> objects are not #= ? >>>>>>>>>>>>>> It shows no diff and then I must go to see the inspector? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> These textual representations can be customized per each >>>>>>>>>>>>> object type, however if they are the same now it just shows the diff pane >>>>>>>>>>>>> with no differences. >>>>>>>>>>>>> Another idea would be to also show two inspectors side-by-side >>>>>>>>>>>>> apart from the diff. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A side-by-side inspector would be another really cool addition >>>>>>>>>>>> for when the string comparison won't work. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Then even if you see or not a difference in the textual diff, >>>>>>>>>>>>> you could use the inspector to look at differences between the state. >>>>>>>>>>>>> Also right now the diff is textual. Adding better diff widgets >>>>>>>>>>>>> for specific data types would help. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Oh yes. But I think that adding a side-by-side inspector would >>>>>>>>>>>> be a great second step in which you know you can always fall back no matter >>>>>>>>>>>> which kind of object. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I added two side by side inspectors. I still need to >>>>>>>>>>> improve/disable navigation in these embedded inspectors >>>>>>>>>>> >>>>>>>>>>> <debugger.png> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> BTW...since we are near Christmas... it would be terrific to >>>>>>>>>>>> have a button somewhere to show/hide the #setUp method besides the code >>>>>>>>>>>> representing the piece of stack you clicked. Sometimes when I am debugging >>>>>>>>>>>> test failures that had a setup I always have to open another window with >>>>>>>>>>>> the setup because I don't remember everything I did there and that's useful >>>>>>>>>>>> information to understand what a test could have failed. There was a >>>>>>>>>>>> Nautilus plugin for that some time ago. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sounds like an useful feature. I'll give a try implementing it. >>>>>>>>>>> Or if you are faster you can give it a try :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I like the idea. Maybe having a âsetUp tab; next to âSourceâ tab >>>>>>>>>>> whenever we browse a test case object in debugger? Or it could be part of >>>>>>>>>>> the inspector the same way you did âDiffâ tab. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I think the MAIN point for me is to be able to see the setUp AT >>>>>>>>>> THE SAME time with the code of the failing error. If I have to click >>>>>>>>>> another tab to see the setup and then another click to go back to see my >>>>>>>>>> test, then I gain nothing. Maybe splitting (either vertically or >>>>>>>>>> horizontally) the area where now you see the method source (of the selected >>>>>>>>>> stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in >>>>>>>>>> the below (expected vs current, etc) called "setUp". That way, at least I >>>>>>>>>> can see the method and the setUp all together (Ok, I cannot see the >>>>>>>>>> expected vs current, but ok) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Juraj >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Andrei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Moose-dev mailing list >>>>>>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Moose-dev mailing list >>>>>>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Moose-dev mailing list >>>>>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)list.inf.unibe.ch >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- Mariano http://marianopeck.wordpress.com

2 3

Semantic analysis doesn't compute RBArgumentNode instances
by Martin Dias Dec. 3, 2015

Dec. 3, 2015

Hi, In Pharo 4, the RBExplicitVariableParser computed the argument variables as RBArgumentNodes: (Integer >> #bitAnd:) parseTree arguments "--> an OrderedCollection(RBArgumentNode(n))" In Pharo 50191, such parser was removed (case 16026) because "semantic analysis" does the same job. However, it does not exactly the same job: argument variables are now parsed as generic variable nodes: (Integer >> #bitAnd:) parseTree doSemanticAnalysis arguments "an OrderedCollection(RBVariableNode(n))" Anyway, it works well with other variables, e.g. temporaries: (Integer >> #bitAnd:) parseTree doSemanticAnalysis temporaries "an OrderedCollection(RBTemporaryNode(norm))" Should I create a bug entry? Cheers, Martin

2 2

vm crash in SmalltalkImage>garbageCollect
by Andrei Chis Dec. 3, 2015

Dec. 3, 2015

Hi, With both the latest and stable vm I have an use case in which the vm crashed in SmalltalkImage>>garbageCollect. To set up an image that exhibits the failure , execute this with the latest pharo version: /pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]." ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2 Then attempting to run the following code triggers the failure: ./pharo Pharo.image eval --save "TestRunner open model packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll" Based on the trace below the failure happens when the test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp method. That call can be removed, however, in other runs the failure happens in other methods calling Smalltalk>>garbageCollect. Is it possible that this is a bug with the image (some broken object) or is it a vm bug? Cheers, Andrei andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]." andrei$ ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2 andrei$ ./pharo Pharo.image eval --save "TestRunner open model packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll" Segmentation fault Mon Nov 23 16:48:36 2015 https://github.com/pharo-project/pharo-vm.git Commit: 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15016 C stack backtrace: 0 Pharo 0x0004cacf reportStackState + 159 Smalltalk stack dump: 0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n) SmalltalkImage 0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n) GTInspectorExamplesTest 0x2126cb90 is not a context Most recent primitives @ basicNew @ @ @ @ @ @ @ @ @ basicNew basicNew basicNew @ @ @ @ shallowCopy new new: new: basicNew basicNew new: basicNew new: replaceFrom:to:with:startingAt: new: basicNew new: replaceFrom:to:with:startingAt: new: basicNew @ new: at:put: at:put: perform:with: perform:with: perform: @ @ basicNew @ @ @ @ @ @ basicNew @ new: at:put: at:put: perform:with: perform:with: perform: @ @ basicNew @ @ @ @ @ @ new @ @ @ @ @ basicNew @ @ new: at:put: @ @ basicNew @ @ @ @ new: at:put: at:put: at:put: at:put: new: @ at:put: @ at:put: @ at:put: @ at:put: @ @ @ @ @ @ basicNew @ @ basicNew @ @ basicNew @ @ @ @ @ shallowCopy shallowCopy @ @ new: at:put: at:put: at:put: at:put: new: @ at:put: @ at:put: @ at:put: @ at:put: @ @ @ @ @ @ basicNew @ @ basicNew @ @ basicNew @ @ @ @ @ basicNew @ @ @ @ basicNew @ @ basicNew @ @ basicNew @ @ @ @ @ basicNew @ @ @ @ basicNew @ @ perform: basicNew new: basicNew new: basicNew new: shallowCopy shallowCopy primUTCMicrosecondsClock // basicNew basicNew new: at:put: at:put: at:put: at:put: value valueNoContextSwitch basicNew new: basicNew new: new: basicNew new: replaceFrom:to:with:startingAt: primitiveGarbageCollect **IncrementalGC** **FullGC** garbageCollectMost **IncrementalGC** basicNew new: someInstance basicNew new: someInstance basicNew new: someInstance new: basicNew new: replaceFrom:to:with:startingAt: primitiveGarbageCollect **IncrementalGC** **FullGC** garbageCollectMost **IncrementalGC** wait shallowCopy shallowCopy signal wait shallowCopy shallowCopy at:put: at:put: at:put: at:put: at:put: at:put: signal wait shallowCopy shallowCopy at:put: at:put: signal new: basicNew new: replaceFrom:to:with:startingAt: primitiveGarbageCollect **IncrementalGC** **FullGC** (Segmentation fault) ./pharo: line 11: 5224 Abort trap: 6 "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@"

4 21