- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Eliot Miranda

Hi Guille, > On Feb 15, 2016, at 6:28 AM, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Well, the main drawback is that you'll not be able to trap any messages implemented by DNUProxy, because as they are implemented, they are understood. > > Also, the idea of Ghost was not only to use cannot interpret, but to provide a library that allowed to proxy objects as well as methods and classes. > > Finally, I'm curious about the performance difference... because the interpreter code handling DNU and cannot interpret is not much different... Maybe the JIT is not handling it (because nobody proposed it before)? The JIT optimises MNU dispatch using PICs. The idea is that a PIC can also record that a given selector is not understood and hence avoid both the failing lookup for the send that is not understood (which is very slow because it scans all classes in the receivers hierarchy searching for a selector that isn't there) and the send of doesNotUnderstand:. In spur there's also a possibility of further optimising the creation of the message which could be done in machine code, rather than as now, with a slower call into the interpreter runtime. > Guille > >> On 02/15/2016 03:11 PM, Denis Kudriashov wrote: >> I compared doesNotUnderstand: vs cannotInterpret: versions of proxies. >> >> DNUProxy>>doesNotUnderstand: aMessage >> lastMessage := aMessage. >> ^'from DNU proxy' >> >> CannotInterpretProxy>>cannotInterpret: aMessage >> lastMessage := aMessage. >> ^'from cannot interpret proxy' >> >> >> And DNU proxy works 2 times faster then #cannotInterpret proxy. >> >> [proxy someMessage] benchFor: 2 seconds. >> >> DNU: >> "a BenchmarkResult(22,377,669 iterations in 2 seconds. 11,188,835 per second)" >> >> CannotInterpet: >> "a BenchmarkResult(13,148,735 iterations in 2 seconds 2 milliseconds. 6,567,800 per second) >> >> Also DNU version is much more easy to explain. >> >> So why Ghost uses #cannotInterpret for proxies? (after reading Ghost paper I can't understand this). >> Naked proxy can be easily done by setting superclass to nil: >> >> ProtoObject subclass: #DNUProxy >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'DNUProxy'. >> DNUProxy superclass: nil >

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Eliot Miranda

Hi Denis, > On Feb 15, 2016, at 6:53 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed. >> >> If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work. > > Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). > Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions. There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Denis Kudriashov

2016-02-15 15:57 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > You mean the hierarchy because of #cannotInterpret: is sent to the > superclass? If true, then yes, it will simplify that. Yes

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Eliot Miranda

Hi Denis, > On Feb 15, 2016, at 6:53 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed. >> >> If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work. > > Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). > Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions. In principle there's no reason why

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Mariano Martinez Peck

On Mon, Feb 15, 2016 at 11:53 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> As far as I can remember (this was about 4 years ago) The use of >> #cannotInterpret: was the only way to be able to intercept everything >> without breaking the system. Subclassing from ProtoObject make your proxy >> to understand some messages. Subclassing from nil was technically possible, >> but I found out the system would simply crash as it didn't know at all how >> to handle other subclasses of nil. Even with the debugging support I added >> as you can read in the paper. Maybe things have changed. >> >> If subclassing from nil does not break the system and you can still >> inspect, debug proxies, then sure, you can give a try to Ghost using #dnu >> rather than #cannotInterpret:. In fact, I would like to have a dnu-based >> approeach that is as reliable as it was #cannotInterpret: in the sense of >> how much I can intercept. With #cannotInterpret I could trap EVERYTHING >> (everything but #==) and then decide what to do. Subclassing from nil would >> get you there too if you make it work. >> > > Actually I already implemented it many yeas ago for Mocketry. But > subclassing from nil works correctly only in VW. I got problems when > porting it to Squeak (at that time). > Exactly. And myself in Pharo 4 years ago. > Now I want to give DNU another chance. > Sure, it's a good idea. > It will simplify logic very much. It will remove strange hierarchy of > proxies which is needed for trick but raises many questions. > You mean the hierarchy because of #cannotInterpret: is sent to the superclass? If true, then yes, it will simplify that. -- Mariano http://marianopeck.wordpress.com

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Denis Kudriashov

2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > As far as I can remember (this was about 4 years ago) The use of > #cannotInterpret: was the only way to be able to intercept everything > without breaking the system. Subclassing from ProtoObject make your proxy > to understand some messages. Subclassing from nil was technically possible, > but I found out the system would simply crash as it didn't know at all how > to handle other subclasses of nil. Even with the debugging support I added > as you can read in the paper. Maybe things have changed. > > If subclassing from nil does not break the system and you can still > inspect, debug proxies, then sure, you can give a try to Ghost using #dnu > rather than #cannotInterpret:. In fact, I would like to have a dnu-based > approeach that is as reliable as it was #cannotInterpret: in the sense of > how much I can intercept. With #cannotInterpret I could trap EVERYTHING > (everything but #==) and then decide what to do. Subclassing from nil would > get you there too if you make it work. > Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Mariano Martinez Peck

On Mon, Feb 15, 2016 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I compared doesNotUnderstand: vs cannotInterpret: versions of proxies. > > DNUProxy>>doesNotUnderstand: aMessage > lastMessage := aMessage. > ^'from DNU proxy' > > CannotInterpretProxy>>cannotInterpret: aMessage > lastMessage := aMessage. > ^'from cannot interpret proxy' > > > And DNU proxy works 2 times faster then #cannotInterpret proxy. > > [proxy someMessage] benchFor: 2 seconds. > > DNU: > "a BenchmarkResult(22,377,669 iterations in 2 seconds. 11,188,835 per > second)" > > CannotInterpet: > "a BenchmarkResult(13,148,735 iterations in 2 seconds 2 > milliseconds. 6,567,800 per second) > > Also DNU version is much more easy to explain. > > So why Ghost uses #cannotInterpret for proxies? (after reading Ghost paper > I can't understand this). > Naked proxy can be easily done by setting superclass to nil: > > ProtoObject subclass: #DNUProxy > instanceVariableNames: '' > classVariableNames: '' > package: 'DNUProxy'. > DNUProxy superclass: nil > As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed. If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work. The #cannotInterpret: over #dnu: is only one of the decisions behind Ghost. That is, you can still get some of the Ghost benefits if you use dnu (separation of proxy from handler, dynamically allow debugging or not, be able to proxy and become classed and methods, etc etc). ps: I don't remember if there was something also with the fact of proxying (and becoming) classes and methods. Ghost allows to proxify classes and methods, and even leave instances of them in the system...and sending a message to those instances (whose class is a proxy) would intercept the message in the class. Ghost has several tests for all these cases. So if you want to give it a try with the DNU approach you should check if this still works... The #cannotInterpret may have some trick for when we proxy classes... I cannot remember... but maybe. Cheers, -- Mariano http://marianopeck.wordpress.com

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by Guille Polito

Well, the main drawback is that you'll not be able to trap any messages implemented by DNUProxy, because as they are implemented, they are understood. Also, the idea of Ghost was not only to use cannot interpret, but to provide a library that allowed to proxy objects as well as methods and classes. Finally, I'm curious about the performance difference... because the interpreter code handling DNU and cannot interpret is not much different... Maybe the JIT is not handling it (because nobody proposed it before)? Guille On 02/15/2016 03:11 PM, Denis Kudriashov wrote: > I compared doesNotUnderstand: vs cannotInterpret: versions of proxies. > > DNUProxy>>doesNotUnderstand: aMessage > lastMessage := aMessage. > ^'from DNU proxy' > > CannotInterpretProxy>>cannotInterpret: aMessage > lastMessage := aMessage. > ^'from cannot interpret proxy' > > > And DNU proxy works 2 times faster then #cannotInterpret proxy. > > [proxy someMessage] benchFor: 2 seconds. > > DNU: > "a BenchmarkResult(22,377,669 iterations in 2 seconds. 11,188,835 per > second)" > > CannotInterpet: > "a BenchmarkResult(13,148,735 iterations in 2 seconds 2 > milliseconds. 6,567,800 per second) > > Also DNU version is much more easy to explain. > > So why Ghost uses #cannotInterpret for proxies? (after reading Ghost > paper I can't understand this). > Naked proxy can be easily done by setting superclass to nil: > > ProtoObject subclass: #DNUProxy > instanceVariableNames: '' > classVariableNames: '' > package: 'DNUProxy'. > DNUProxy superclass: nil > >

Feb. 15, 2016

Proxy DNU vs CannotInterpret. (Ghost related)

by Denis Kudriashov

I compared doesNotUnderstand: vs cannotInterpret: versions of proxies. DNUProxy>>doesNotUnderstand: aMessage lastMessage := aMessage. ^'from DNU proxy' CannotInterpretProxy>>cannotInterpret: aMessage lastMessage := aMessage. ^'from cannot interpret proxy' And DNU proxy works 2 times faster then #cannotInterpret proxy. [proxy someMessage] benchFor: 2 seconds. DNU: "a BenchmarkResult(22,377,669 iterations in 2 seconds. 11,188,835 per second)" CannotInterpet: "a BenchmarkResult(13,148,735 iterations in 2 seconds 2 milliseconds. 6,567,800 per second) Also DNU version is much more easy to explain. So why Ghost uses #cannotInterpret for proxies? (after reading Ghost paper I can't understand this). Naked proxy can be easily done by setting superclass to nil: ProtoObject subclass: #DNUProxy instanceVariableNames: '' classVariableNames: '' package: 'DNUProxy'. DNUProxy superclass: nil

Feb. 15, 2016

Re: [Pharo-dev] More tests for new frameworks

by Mariano Martinez Peck

Stef, I know it's easy to speak with Monday's newspaper, but I wouldn't accept projects for Pharo that do not have tests. I do not pretend X number of percentage, but at least some tests. Otherwise, YOU will have to pay the costs. Max: we already have a test coverage tool already in the image since years. Open Test Runner -> Run Coverage. Cheers, On Sun, Feb 14, 2016 at 9:14 AM, stepharo <stepharo(a)free.fr> wrote: > Thanks > I do not have the cycle for that but I would love to get some feedback on > if this is possible to run > and for which packages. > > Stef > > Le 14/2/16 04:09, Alejandro Infante a Ã©crit : > > If you plan to add it to an automatic CI Job with Hapao, I would recommend >> to load the following group of Spy2: >> âââââ >> (ConfigurationOfSpy2 project version: #stable) load: #HapaoCore >> âââââ >> >> This is going to load just the core of Spy and Hapao and will not load >> Roassal, GT-Inspector and GT-Debugger extensions. >> >> Cheers, >> Alejandro >> >> On Feb 13, 2016, at 6:39 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Yes I would even buy 20% coverage right now. >>> >>> Stef >>> >>> >>> Le 13/2/16 20:22, Max Leske a Ã©crit : >>> >>>> How about enforcing coverage? I know that coverage tests donât say >>>> anything about the quality of the test cases but itâs (almost) always >>>> better to have some tests than none. I wouldnât set the bar too high either >>>> for coverage, maybe 60 or 70%. 100% is unrealistic, but 60 to 70 should be >>>> achievable with a couple of well written tests. >>>> >>>> Of course we would need a way to run coverage tests on the test suite. >>>> Do we have a tool for coverage tests? >>>> >>>> On 13 Feb 2016, at 19:35, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> Hi guys >>>>> >>>>> with damien cassou we had an interesting discussion. Basically we are >>>>> teaching tests and we see that many Pharo subsystems are not really well >>>>> tested. I wonder how we can change this. For example, we will have a new >>>>> graphical core without any tests >>>>> and this is sad because tests could be really good to make sure that >>>>> we will be able to move forward in the future. >>>>> I would like to get tests for Ring. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> > > -- Mariano http://marianopeck.wordpress.com

Feb. 15, 2016