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

[pharo-project/pharo-core] 076939: 50453

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 07693925e92be86f3cb83d20b5be67b3a23319e5 https://github.com/pharo-project/pharo-core/commit/07693925e92be86f3cb83d20… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-18 (Wed, 18 Nov 2015) Changed paths: M Morphic-Base.package/HaloMorph.class/instance/private/doGrow_with_.st R Morphic-Base.package/extension/PasteUpMorph/instance/acceptDroppingMorph_event_.st R Morphic-Base.package/extension/PasteUpMorph/instance/fitAll.st R Morphic-Base.package/extension/PasteUpMorph/instance/grabLassoFromScreen_.st R Morphic-Base.package/extension/PasteUpMorph/instance/grabRubberBandFromScreen_.st R Morphic-Base.package/extension/PasteUpMorph/instance/keystrokeInWorld_.st R Morphic-Base.package/extension/PasteUpMorph/instance/modelWakeUp.st M Morphic-Base.package/extension/WorldState/class/windowsOn_.st R Morphic-Core.package/Morph.class/instance/Morphic-Base-Pluggable Widgets/beginsWith_fromList_.st A Morphic-Core.package/Morph.class/instance/Morphic-Base-Widgets/beginsWith_fromList_.st A Morphic-Core.package/Morph.class/instance/event handling/handlesMouseOver_.st A Morphic-Core.package/Morph.class/instance/event handling/mouseWheel_.st R Morphic-Core.package/Morph.class/instance/miscellaneous/setExtentFromHalo_.st R Morphic-Core.package/Morph.class/instance/other events/menuButtonMouseEnter_.st R Morphic-Core.package/Morph.class/instance/other events/menuButtonMouseLeave_.st R Morphic-Core.package/Morph.class/instance/recategorized/handlesMouseOver_.st M Morphic-Core.package/Morph.class/instance/user interface/initialExtent.st A Morphic-Core.package/PasteUpMorph.class/instance/accessing/backgroundMorph.st A Morphic-Core.package/PasteUpMorph.class/instance/accessing/backgroundMorph_.st A Morphic-Core.package/PasteUpMorph.class/instance/event handling/acceptDroppingMorph_event_.st M Morphic-Core.package/PasteUpMorph.class/instance/halos and balloon help/wantsHaloFromClick.st R Morphic-Core.package/PasteUpMorph.class/instance/recategorized/backgroundMorph.st R Morphic-Core.package/PasteUpMorph.class/instance/world menu/delayedInvokeWorldMenu_.st R Morphic-Core.package/PasteUpMorph.class/instance/world menu/extractScreenRegion_andPutSketchInHand_.st R Morphic-Core.package/PasteUpMorph.class/instance/world menu/grabDrawingFromScreen_.st R Morphic-Core.package/PasteUpMorph.class/instance/world menu/respondToCommand_bySending_to_.st R Morphic-Core.package/PasteUpMorph.class/instance/world menu/showImage_.st R Morphic-Core.package/PasteUpMorph.class/instance/world state/checkCurrentHandForObjectToPaste.st R Morphic-Core.package/PasteUpMorph.class/instance/world state/chooseClickTarget.st M Morphic-Core.package/PasteUpMorph.class/instance/world state/deleteAllHalos.st R Morphic-Core.package/WorldMorph.class/instance/event handling/mouseUp_.st A Morphic-Widgets-Taskbar.package/extension/PasteUpMorph/instance/taskList.st R Morphic-Widgets-Taskbar.package/extension/WorldMorph/instance/taskList.st A Morphic-Widgets-Windows.package/extension/Morph/instance/isWindowActive_.st A Morphic-Widgets-Windows.package/extension/Morph/instance/openModal_.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/fitAllVisibleWindows.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/isWindowActive_.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/modalLockTo_.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/modalUnlockFrom_.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/modelWakeUp.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/navigateVisibleWindowForward.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/navigateWindowBackward.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/navigateWindowForward.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/nextVisibleWindow.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/nextWindow.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/openModal_.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/previousWindow.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/systemWindows.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/visibleSystemWindows.st A Nautilus.package/AbstractNautilusUI.class/instance/styling/addIconStyle.st A Nautilus.package/AbstractNautilusUI.class/instance/styling/removeIconStyle.st A Nautilus.package/AbstractNautilusUI.class/instance/styling/resetIconStyle.st M Nautilus.package/Nautilus.class/instance/history/package_class_protocol_method_.st R Nautilus.package/Nautilus.class/instance/styling/addIconStyle.st R Polymorph-Widgets.package/extension/Morph/instance/heightToDisplayInTree_.st R Polymorph-Widgets.package/extension/Morph/instance/isWindowActive_.st R Polymorph-Widgets.package/extension/Morph/instance/mouseWheel_.st R Polymorph-Widgets.package/extension/Morph/instance/openModal_.st R Polymorph-Widgets.package/extension/Morph/instance/treeRenderOn_bounds_color_font_from_.st R Polymorph-Widgets.package/extension/Morph/instance/widthToDisplayInTree_.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/backgroundMorph_.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/isWindowActive_.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/modalLockTo_.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/modalUnlockFrom_.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/navigateVisibleWindowForward.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/navigateWindowBackward.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/navigateWindowForward.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/nextVisibleWindow.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/nextWindow.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/openModal_.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/previousWindow.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/systemWindows.st R Polymorph-Widgets.package/extension/PasteUpMorph/instance/visibleSystemWindows.st M Rubric.package/RubSmalltalkEditor.class/class/accessing/menuOn_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50452.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50453.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50452.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50453.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/extension/SmalltalkEditor/instance/smartSuggestions.st A Spec-MorphicAdapters.package/extension/Morph/instance/heightToDisplayInTree_.st A Spec-MorphicAdapters.package/extension/Morph/instance/treeRenderOn_bounds_color_font_from_.st A Spec-MorphicAdapters.package/extension/Morph/instance/widthToDisplayInTree_.st M Text-Edition.package/SmalltalkEditor.class/class/menu declaration/smalltalkEditorMenuOn_.st Log Message: ----------- 50453 17049 Morphic-Core cleanup https://pharo.fogbugz.com/f/cases/17049 17048 visualization of breakpoints logic on nautilus ui + reset logic to support remove all breakpoints on a method https://pharo.fogbugz.com/f/cases/17048 17039 Broken context menu in MessageBrowsers code pane https://pharo.fogbugz.com/f/cases/17039 http://files.pharo.org/image/50/50453.zip

Nov. 18, 2015

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

by Max Leske

I went ahead and implemented a simple fix for the styler. Not sure how well it performs but in my simple experiments it seems to work fine. Please test it and let me know what you think. https://pharo.fogbugz.com/f/cases/17050/SHTextStyler-styleInBackgroundProce… Cheers, Max > On 18 Nov 2015, at 19:02, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > Am 18.11.15 um 11:48 schrieb Andrei Chis: >> Can you try the script below in the latest Pharo image and let me know how much does it take to execute on your machine: >> >> |duration benchmarkResult| >> 100 timesRepeat: [ >> RubScrolledTextMorph new >> model: (RubScrolledTextModel new setInitialText: '1+1'; yourself); >> beForSmalltalkScripting; >> yourself >> ] . >> >> duration := 100 milliSeconds. >> benchmarkResult := [ 100 factorial ] benchFor: duration. >> >> In my case it takes around 1 minute. The inner loop finishes immediately and then most time is spend executing the benchmark. >> >> At the end I get the following result: >> "a BenchmarkResult(2,060,386 iterations in 1 minute 7 seconds 498 milliseconds. 30,525 per second)" >> >> So the benchmark is executed for over one minute before the delay expires. >> >> >> > "a BenchmarkResult(1,263,573 iterations in 37 seconds 689 milliseconds. 33,526 per second)" > (HP Z420 with Xeon E5-1620 under OpenIndiana). > > Regards > Andreas

Nov. 18, 2015

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

by Andreas Wacknitz

Am 18.11.15 um 11:48 schrieb Andrei Chis: > Can you try the script below in the latest Pharo image and let me know > how much does it take to execute on your machine: > > |duration benchmarkResult| > 100 timesRepeat: [ > RubScrolledTextMorph new > model: (RubScrolledTextModel new setInitialText: '1+1'; yourself); > beForSmalltalkScripting; > yourself > ] . > > duration := 100 milliSeconds. > benchmarkResult := [ 100 factorial ] benchFor: duration. > > In my case it takes around 1 minute. The inner loop finishes > immediately and then most time is spend executing the benchmark. > > At the end I get the following result: > "a BenchmarkResult(2,060,386 iterations in 1 minute 7 seconds 498 > milliseconds. 30,525 per second)" > > So the benchmark is executed for over one minute before the delay expires. > > > "a BenchmarkResult(1,263,573 iterations in 37 seconds 689 milliseconds. 33,526 per second)" (HP Z420 with Xeon E5-1620 under OpenIndiana). Regards Andreas

Nov. 18, 2015

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

by Andrei Chis

On Wed, Nov 18, 2015 at 3:10 PM, Ben Coman <btc(a)openinworld.com> wrote: > From Playground... > a BenchmarkResult(1,942,473 iterations in 1 minute 47 seconds 237 > milliseconds. 18,114 per second) > > Now I haven't thought hard enough about the following to know if its > the right solution, but just an early share... > changing... > ] forkAt: Processor activePriority. > to... > ] forkAt: Processor activePriority - 1. > in #styleInBackgroundProcess: has a positive impact. > > Interesting. Just somehow this seems more like a workaround. I'd really like to find out why rubric creates zombie processes when styling and how do these processes affect the delay scheduling. Replacing, in the code I previously send, the creation of a Rubric editor with just the code for styling leads to no delay. (RubSHTextStylerST80 new styleInBackgroundProcess: '1+1' asText) Ideally I'd like to find some code, independent of rubric that exhibits the bug. Something in the line of this script http://ws.stfx.eu/1P51Y1WBN9RJ , which for now does not produce any delay. For the moment I'll disable #testAllExamples so see if this actually fixes the blocking issue from the CI. Cheers, Andrei > cheers -ben > > On Wed, Nov 18, 2015 at 7:09 PM, Max Leske <maxleske(a)gmail.com> wrote: > > a BenchmarkResult(5,057,441 iterations in 3 minutes 26 seconds 74 > milliseconds. 24,542 per second) > > > > ./pharo Pharo.image eval 205,98s user 2,07s system 100% cpu 3:27,44 > total > > > >> On 18 Nov 2015, at 11:48, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> > >> Can you try the script below in the latest Pharo image and let me know > how much does it take to execute on your machine: > >> > >> |duration benchmarkResult| > >> 100 timesRepeat: [ > >> RubScrolledTextMorph new > >> model: (RubScrolledTextModel new setInitialText: > '1+1'; yourself); > >> beForSmalltalkScripting; > >> yourself > >> ] . > >> > >> duration := 100 milliSeconds. > >> benchmarkResult := [ 100 factorial ] benchFor: duration. > >> > >> In my case it takes around 1 minute. The inner loop finishes > immediately and then most time is spend executing the benchmark. > >> > >> At the end I get the following result: > >> "a BenchmarkResult(2,060,386 iterations in 1 minute 7 seconds 498 > milliseconds. 30,525 per second)" > >> > >> So the benchmark is executed for over one minute before the delay > expires. > >> > >> > >> > > > > > >

Nov. 18, 2015

[pharo-project/pharo-core] aacc4d: 50452

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: aacc4d192fdbb7f132a19b9cd861424c52f4421c https://github.com/pharo-project/pharo-core/commit/aacc4d192fdbb7f132a19b9c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-18 (Wed, 18 Nov 2015) Changed paths: M Morphic-Base.package/extension/Morph/instance/addHalo_.st A Morphic-Tests.package/MorphTest.class/instance/as yet unclassified/testHaloIsDisable.st M Nautilus.package/NautilusUI.class/instance/system announcements/metaLinkModified_.st A Reflectivity.package/ReflectiveMethod.class/instance/invalidate/decreaseLinkCount.st A Reflectivity.package/ReflectiveMethod.class/instance/invalidate/increaseLinkCount.st A Reflectivity.package/ReflectiveMethod.class/instance/invalidate/installLink_.st R Reflectivity.package/ReflectiveMethod.class/instance/invalidate/removeLink.st M Reflectivity.package/ReflectiveMethod.class/instance/invalidate/removeLink_.st R Reflectivity.package/ReflectiveMethod.class/instance/testing/decreaseLinkCount.st R Reflectivity.package/ReflectiveMethod.class/instance/testing/increaseLinkCount.st R Reflectivity.package/ReflectiveMethod.class/instance/testing/installLink_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50451.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50452.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50451.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50452.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/instance/accessing/label.st M SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/accessing/label.st M SmartSuggestions.package/SugsBreakOnceSuggestion.class/instance/accessing/label.st M Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/wireClasses.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/structure accessing/showClassDefinition.st Log Message: ----------- 50452 17046 announce link remove + fix DNU when Nautilus has no method selected https://pharo.fogbugz.com/f/cases/17046 17032 ExternalBrowser should be able to show class definitions https://pharo.fogbugz.com/f/cases/17032 17040 Morph HalosEnabled variable is not use. https://pharo.fogbugz.com/f/cases/17040 17043 Use uppercase for breakpoint menu item labels in suggestions https://pharo.fogbugz.com/f/cases/17043 http://files.pharo.org/image/50/50452.zip

Nov. 18, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 18, 2015

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

by Esteban A. Maringolo

2015-11-18 13:29 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> Iâd like to discuss also the possibility to add those low level operations >> on mirrors objects, that could be packaged separately from the kernel of the >> language. Adding them on a first step is easy, then making all tools use >> them is the hard/timeconsuming part, yes. > > > All the needed operations already exist. You can put them on your mirror > objects without any problem. Who takes the decision to put it either in EyeInspector or GtInspector? Regards!

Nov. 18, 2015

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

by ClÃ©ment Bera

2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Iâd like to discuss also the possibility to add those low level operations > on mirrors objects, that could be packaged separately from the kernel of > the language. Adding them on a first step is easy, then making all tools > use them is the hard/timeconsuming part, yes. > All the needed operations already exist. You can put them on your mirror objects without any problem. > On 18 nov 2015, at 12:35 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > Hello, > > This is known and was discussed on the bug tracker. > > The problem is that currently Pharo has many tools and classes: > EyeInspector in the debugger, GTInspector outside, the debugger itself, the > in-image interpreter in the Context class ... that need to be changed to > support debugging objects that basically cannot receive any message. > > We are aware of the solution but fixing it for all the toolkits and > classes is quite some work. In addition, if not tested, someone will break > it because he won't understand that an inspected object can't receive any > message because the expected behavior of an object with no DNU behavior and > no methods inherited from Object is to freeze the system. > > It's a lot of fun doing that though. > > Clement > > 2015-11-17 21:39 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> 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] 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-18 13:53 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Thanks Nicolai. Our monkey say it was success :) > Do you think Marcus should review it? or you confident enough? > A review would be good :) How about you, Henrik? This is an interesting bug :-) nicolai > > Cheers, > > On Wed, Nov 18, 2015 at 6:43 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 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 >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 18, 2015

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

by Esteban A. Maringolo

Hi Clement, Do you know which is the issue that covers this? I remember complaining about dealing with Proxies in the debugger a year ago and getting a similar response. How does this play with the new "slot based" variables? Regards! Esteban A. Maringolo 2015-11-18 8:35 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hello, > > This is known and was discussed on the bug tracker. > > The problem is that currently Pharo has many tools and classes: EyeInspector > in the debugger, GTInspector outside, the debugger itself, the in-image > interpreter in the Context class ... that need to be changed to support > debugging objects that basically cannot receive any message. > > We are aware of the solution but fixing it for all the toolkits and classes > is quite some work. In addition, if not tested, someone will break it > because he won't understand that an inspected object can't receive any > message because the expected behavior of an object with no DNU behavior and > no methods inherited from Object is to freeze the system. > > It's a lot of fun doing that though. > > Clement > > 2015-11-17 21:39 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> 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