February 2016 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Improving Ghost proxies

by Mariano Martinez Peck

On Mon, Feb 15, 2016 at 7:15 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I think it is important to get single proxy framework for Pharo. It should > provide required integration support for our tools. > > I want push Ghost in that direction. Debuggers and inspectors should work > correctly with proxies which based on Ghost. > > Hi Denis, I welcome you push on Ghost. The original source of Ghost was in SS3 and then, the CAR team move it to Shub and hence why it is there. I THINK they did not do many changes from the "upstream" project, so it should be safe to take that one. I guess you should ask Luc Fabrese about that. Debugging, inspecting, etc was some of the problems that Ghost did solve. I was able to do all that. And you were able to enable/disabled debugging capabilities dynamically. What I really really really recommend you is that before doing anything with Ghost, please read the whole journal paper as there is a lot of discussion, possibilities, explanations of why we took path X, etc etc: https://hal.inria.fr/hal-01081236/file/Mart14z-Ghost-Final.pdf > Now Ghost is stored in CAR team repository. Should we move it to Pharo? > > I know that is is subjective, but from my latest experience with git, if I were to make the move of a repository (which requires some effort) I would do it to github. Finally, let me say something.... what I got from my Ghost proxies experience is that Ghost could serve as a proxy library for "common" usage. The code of Ghost is very very little. What is most important is the idea, not the code. This is why, many of the people that got interested in using Ghost for a project X, they ended up "forking" the original Ghost code and adapt it. So...while Ghost can be used and extended for different purposes, I think it's not bad either that someone forks it and adjusts it for his needs. P.S. Ghost has one failed tests due to Spur problem 17536 > <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…> > . > > Best regards, > Denis > -- Mariano http://marianopeck.wordpress.com

Feb. 15, 2016

Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder?

by Tudor Girba

Hi, > On Feb 15, 2016, at 1:43 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > >> Except shift-enter in Finder input field still brings up Spotter. > Spotter is a global key-bind meaning that any user of km-dispatcher will by default bring up spotter on shift-enter... > Perhaps it would be better to move this to those that actually uses it; in the WorldMorph bring up the default spotter, in Nautilus bring up a spotter with entries based on the context, etc..? Exactly. I argued for this a long time ago and I still think it would be the right thing to do. Doru > Forking it shows the expected result, but the input fetcher is running its own thread so this information should be available even though the UI is blocked by the wait ? > > [2 seconds wait. > InputEventSensor default shiftPressed logCr ] fork. > > ---- > Delay delaySchedulerClass. " DelayMicrosecondScheduler " > Should not one of the experimental ones be the default scheduler class? > https://pharo.fogbugz.com/f/cases/13756/Delay-scheduling-deadlock. > "Delay initialize" sets the default one to DelayMicrosecondScheduler, and I guess it was re-initialized for the new session manager. > > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman > Sent: Monday, February 15, 2016 12:39 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder? > > On Mon, Feb 15, 2016 at 5:48 PM, stepharo <stepharo(a)free.fr> wrote: >> Hi guys >> >> you cannot imagine the amount of energy I'm losing because of the flux >> of the tools. >> why spotter shows up when I type enter in the inputfield of the finder? >> Is it on purpose? >> This is 5 times that I'm redoing a videos for the mooc. :( > > I can't make this happen in 50581 - 32-bit Linux. > Except shift-enter in Finder input field still brings up Spotter. > My first thought is maybe your shift key is somehow stuck. > > > An aside: > I thought to check behaviour by holding <shift> after evaluating... > 2 second wait. > InputEventSensor default shiftPressed inspect > > but inspector shows false. Is this expected? > cheers -ben > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Feb. 15, 2016

Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder?

by Volkert

Have not problems here ... Pharo5.0 Latest update: #50581 Ubuntu 14.04 On 15.02.2016 10:48, stepharo wrote: > Hi guys > > you cannot imagine the amount of energy I'm losing because of the flux > of the tools. > why spotter shows up when I type enter in the inputfield of the finder? > Is it on purpose? > This is 5 times that I'm redoing a videos for the mooc. :( > > > Stef >

Feb. 15, 2016

Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder?

by Henrik Nergaard

>Except shift-enter in Finder input field still brings up Spotter. Spotter is a global key-bind meaning that any user of km-dispatcher will by default bring up spotter on shift-enter... Perhaps it would be better to move this to those that actually uses it; in the WorldMorph bring up the default spotter, in Nautilus bring up a spotter with entries based on the context, etc..? Forking it shows the expected result, but the input fetcher is running its own thread so this information should be available even though the UI is blocked by the wait ? [2 seconds wait. InputEventSensor default shiftPressed logCr ] fork. ---- Delay delaySchedulerClass. " DelayMicrosecondScheduler " Should not one of the experimental ones be the default scheduler class? https://pharo.fogbugz.com/f/cases/13756/Delay-scheduling-deadlock. "Delay initialize" sets the default one to DelayMicrosecondScheduler, and I guess it was re-initialized for the new session manager. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Monday, February 15, 2016 12:39 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder? On Mon, Feb 15, 2016 at 5:48 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > you cannot imagine the amount of energy I'm losing because of the flux > of the tools. > why spotter shows up when I type enter in the inputfield of the finder? > Is it on purpose? > This is 5 times that I'm redoing a videos for the mooc. :( I can't make this happen in 50581 - 32-bit Linux. Except shift-enter in Finder input field still brings up Spotter. My first thought is maybe your shift key is somehow stuck. An aside: I thought to check behaviour by holding <shift> after evaluating... 2 second wait. InputEventSensor default shiftPressed inspect but inspector shows false. Is this expected? cheers -ben

Feb. 15, 2016

Re: [Pharo-dev] Is there a problem in latest pharo with refresh?

by stepharo

No I was programming my counter for newbies and the refresh got broken so I got windows not removed on the background. Stef Le 15/2/16 12:23, Ben Coman a Ã©crit : > On Mon, Feb 15, 2016 at 6:57 PM, stepharo <stepharo(a)free.fr> wrote: >> Hi >> >> I cannot produce videos with the latest pharo image because when I move a >> window then all the previous windows >> stay on the screen. >> >> Do you see the same? > Do you mean something like... > https://pharo.fogbugz.com/default.asp?7350 > > I don't see it in 32-bit Debian Jessie Pharo build 50581. > What platform? > > cheers -ben > >

Feb. 15, 2016

Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder?

by stepharo

Lucky you. Le 15/2/16 12:16, Marcus Denker a Ã©crit : > > > On Mon, Feb 15, 2016 at 10:48 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > you cannot imagine the amount of energy I'm losing because of the > flux of the tools. > why spotter shows up when I type enter in the inputfield of the > finder? > > > I just tried to reproduce that but for me this does not happen. > > Marcus >

Feb. 15, 2016

Re: [Pharo-dev] How do remove the setup empty pane in the GTdebugger?

by stepharo

And I'm the idiot that have to explain what it is in videos. I can tell you that I regret to use Pharo 50 for the Pharo mooc. Stef Le 15/2/16 13:01, Nicolai Hess a Ã©crit : > > > 2016-02-15 12:28 GMT+01:00 Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>>: > > On Mon, Feb 15, 2016 at 7:00 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > > > Why pharo tools are getting more complex? > > How do remove the setup empty pane in the GTdebugger? > > :( > > Its not clear to me what you mean. What steps are required to come to > this? Or maybe a screen snapshot? > cheers -ben > > > I think this is about the empty SetUp/TearDown page that shows up in > GT-Debugger, debugging test cases. > The pane is always shown, even if the methods are empty. >

Feb. 15, 2016