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

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

by Esteban A. Maringolo

Hi Elliot, 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: >> > (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. I added your methods to Context and created a EyeProtoInspector class which uses the mirror methods to access the object size and class. So far it works, or at least doesn't give me walkbalks, but if you do a little more than that you'll get fireworks :) >> 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. > 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 > > [snip] > > 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. Yes, it doesn't right now, but not only for the debugger, but the problem as stated in other mails is with the tools, that seems to be designed without considering these special cases. Regards! Esteban A. Maringolo

Nov. 18, 2015

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

by Max Leske

> On 18 Nov 2015, at 15:10, 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. That would definitely help. Another thing I think should be different is the 5 second delay in that process. The 5 seconds might make some sense for a regular user but they pose a problem for automated tests (as we have seen here). > > 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

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

by Ben Coman

>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. 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

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 Mariano Martinez Peck

Thanks Nicolai. Our monkey say it was success :) Do you think Marcus should review it? or you confident enough? 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

Smalltalkhub: Cannot add user to team: "Invalid username or password"

by Mariano Martinez Peck

Hi guys, I am trying to add a registered user into my team via Edit Team -> add button and I get a "Invalid username or password" error. Note that I selected the user from the autocomplete... so the username should be correct. Any ideas? -- Mariano http://marianopeck.wordpress.com

Nov. 18, 2015

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

by Guillermo Polito

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. > 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 <mailto:eliot.miranda@gmail.com>>: > Hi Esteban, > > On Tue, Nov 17, 2015 at 1:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > 2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@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] EyeInspector with subclasses of ProtoObject

by ClÃ©ment Bera

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] Never ending BlockClosure>>benchFor:

by Max Leske

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

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

by 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.

Nov. 18, 2015

Re: [Pharo-dev] News about FastTable

by Tudor Girba

Hi, Great. Please package the Glamour presentations in the Glamour repository and in the ConfigurationOfGlamour. It would preserve the cleanliness of dependencies. Cheers, Doru > On Nov 18, 2015, at 10:53 AM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > 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 > -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Nov. 18, 2015