September 2013 - Pharo-users

Re: [Pharo-users] Capturing messages

by Marcus Denker

On Sep 24, 2013, at 9:41 AM, Alejandro Pulver <alepulver(a)gmail.com> wrote: > I see. But what about sampling? It shouldn't slow down the program nearly as much as these "instrumentation" like mechanisms. > > And as I'm going to count them anyways, missing the most unused ones won't be such a problem. > > That combined with complete capture for a small run (like a test or block) would be enough for our needs. > > Yes, one could just use some random selection (I really like the idea of shotgun sequencingâ¦ http://en.wikipedia.org/wiki/Shotgun_sequencing) The resulting information should be quite good. But the first step is that we need a really good, very dynamic, very general and powerful basisâ¦ this is what we want to build with Reflectivity2 (and Reflectivity3 will have to hook deeper into the JIT of the VM, but that is another story). Related to step 3), another source for interesting data is the VM itself (e.g. caches). But step by stepâ¦ The idea is to take the new possibilities we have in Pharo3 and make a well engineered realization of partial behavioral reflection, with two extensions: -> meta links on instance variables. Very cool possibilities now that instance variables are reified objects ("Slot") -> object specific meta links by integrating with a good proxy implementation This will already bring amazing capabilities to the system (and subsume MethodWrappers, simple CLOS style MOPs, perfect for breakpoints, watchpoints and debugging in general, and it can be the basis for AOP like things). Marcus

Sept. 24, 2013

Image taking up 100% CPU

by Bernat Romagosa

Hi list, A couple months ago I deployed an Iliad application in a Debian VPS, which has been working great except for the fact that about every two weeks the image takes up 100% of the CPU and, of course, the app becomes unusable. Does anyone have a method for finding out what's going on? I've been trying to debug the problem, but as I don't know what triggers it, it's pretty impossible to detect... I've checked the running threads and nothing seems unusual. I've also profiled the app for a whole day of real usage with end users and not a single method took more time than what I expected, so I'm completely lost here. Any help will be appreciated! :) Cheers, Bernat. -- Bernat Romagosa.

Sept. 24, 2013

Re: [Pharo-users] Capturing messages

by Alejandro Pulver

I see. But what about sampling? It shouldn't slow down the program nearly as much as these "instrumentation" like mechanisms. And as I'm going to count them anyways, missing the most unused ones won't be such a problem. That combined with complete capture for a small run (like a test or block) would be enough for our needs. On Tue, Sep 24, 2013 at 4:19 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Sep 24, 2013, at 9:09 AM, Alejandro Pulver <alepulver(a)gmail.com> wrote: > > > Thanks for the reply, but the links mentioned in the forum are down. > Also, I would a solution that works in Pharo 2. > > > > Wrapping every method in the system doesn't look like an efficient > solution. I know about Bifrost but it's implemented in 1.0 and not likely > to be ported to 3 soon (according to a discussion I found recently). > > > > Do you know a reason why the profiler of changing perform won't work? > > > perform: is not called when doing a message send. Reason: it would be too > slow to explicitly call a method to do a message send. Everything is in the > VM. > > We are working (slowly) on a new version of Reflectivity (Partial > Behavioral Reflection) that is the basis of bifrost. > But even then, if you replace every message send by multiple ones, the > result will be a *very* slow system. > > This is in the end the real problem of behavioral reflection: it is not > only difficult to find a good model and implement it in a way that it works > for real even in strange cases (e.g. kernel classes that are used by the > reflective layer itself). > > The real challenge is to make it fast. And that is not easy: just > replacing the message send byte code by o multiple reflective sends will > slow things down quite a lot, regardless how clever you are. > > Marcus >

Sept. 24, 2013

Re: [Pharo-users] New Mars examples: Package Browser and Test Runner

by Damien Cassou

Hi Carla, you did a really great job, thank you. For the Jenkins stuff, you need to create an account on http://ci.inria.fr/ and ask to be a member of the pharo-contribution project. On Tue, Sep 24, 2013 at 5:22 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I love native windowing. This looks really well! > > This statement from your blog: > "Now I really think that âmore handsâ should be involved to grow and improve > this working version." > > It is really important. There are lots of interesting projects and tools > that were practically abandoned because the creator dedicated his/her time > to something new. Pareto principle everywhere. > > > Thank you! > > Esteban A. Maringolo > > > 2013/9/23 Carla F. Griggio <carla.griggio(a)gmail.com> > >> Hi everyone! >> I want to let you know that I've just posted a screencast in my blog about >> the new Mars Package Browser and Test Runner. >> These examples are not really intended as being the definitive package >> browser or test runner, but to start experiencing how is it to build a real >> application using Mars and to showcase some widgets. Anyway, it's cool :) >> The Package browser is not so different to the system browser example I >> showed before, but the Test Runner is definitely my favorite example so far. >> >> I give more details in the screencast and the blog post. Any feedback is >> appreciated! >> >> Cheers, >> Carla. > > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 24, 2013

Re: [Pharo-users] Capturing messages

by Marcus Denker

On Sep 24, 2013, at 9:09 AM, Alejandro Pulver <alepulver(a)gmail.com> wrote: > Thanks for the reply, but the links mentioned in the forum are down. Also, I would a solution that works in Pharo 2. > > Wrapping every method in the system doesn't look like an efficient solution. I know about Bifrost but it's implemented in 1.0 and not likely to be ported to 3 soon (according to a discussion I found recently). > > Do you know a reason why the profiler of changing perform won't work? > perform: is not called when doing a message send. Reason: it would be too slow to explicitly call a method to do a message send. Everything is in the VM. We are working (slowly) on a new version of Reflectivity (Partial Behavioral Reflection) that is the basis of bifrost. But even then, if you replace every message send by multiple ones, the result will be a *very* slow system. This is in the end the real problem of behavioral reflection: it is not only difficult to find a good model and implement it in a way that it works for real even in strange cases (e.g. kernel classes that are used by the reflective layer itself). The real challenge is to make it fast. And that is not easy: just replacing the message send byte code by o multiple reflective sends will slow things down quite a lot, regardless how clever you are. Marcus

Sept. 24, 2013

Re: [Pharo-users] [Esug-list] New Mars examples: Package Browser and Test Runner

by Carla F. Griggio

Nope! I should learn how to do that :P I'll try to do it this week. On Tue, Sep 24, 2013 at 9:04 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi Carla, > > this is cool ! Is there a ready Pharo + Mars image built by jenkins server > ? > > Cheers, > > Laurent > > > On Tue, Sep 24, 2013 at 4:42 AM, Carla F. Griggio <carla.griggio(a)gmail.com > > wrote: > >> Hi everyone! >> I want to let you know that I've just posted a screencast in my blog >> about the new Mars Package Browser and Test Runner<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…> >> . >> These examples are not really intended as being the definitive package >> browser or test runner, but to start experiencing how is it to build a real >> application using Mars and to showcase some widgets. Anyway, it's cool :) >> The Package browser is not so different to the system browser example I >> showed before, but the Test Runner is definitely my favorite example so far. >> >> I give more details in the screencast<http://www.youtube.com/watch?v=RlBr42uaqxE>and the blog >> post<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…>. >> Any feedback is appreciated! >> >> Cheers, >> Carla. >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> >

Sept. 24, 2013

Re: [Pharo-users] Capturing messages

by Alejandro Pulver

Thanks for the reply, but the links mentioned in the forum are down. Also, I would a solution that works in Pharo 2. Wrapping every method in the system doesn't look like an efficient solution. I know about Bifrost but it's implemented in 1.0 and not likely to be ported to 3 soon (according to a discussion I found recently). Do you know a reason why the profiler of changing perform won't work? On Mon, Sep 23, 2013 at 3:11 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Maybe you should use MethodWrappers. > > > http://forum.world.st/MethodWrappers-td3829576.html > > > > On 09/23/2013 09:56 AM, Alejandro Pulver wrote: > > Hello, > > > > I would like to intercept all messages sent in the system, as part of a > > small project to investigate if the information can be used in useful > > ways (autocompletion, object compatibility detection, etc). > > > > It will also involve filtering, aggregating and enabling/disabling it > > for space and time conservation, > > > > I'm new to Pharo, but had some success by changing the main perform > > (perform:withArguments: IIRC) method in Object, and making others use it > > instead of the primitives. > > Someone told me it doesn't capture most messages because of > > optimizations done by the system. > > > > My other thought was to use the profiler's spyOn as an approximation. > > > > What do you think? > > > > Thanks in Advance, > > Alejandro > > >

Sept. 24, 2013

Re: [Pharo-users] [Esug-list] New Mars examples: Package Browser and Test Runner

by laurent laffont

Hi Carla, this is cool ! Is there a ready Pharo + Mars image built by jenkins server ? Cheers, Laurent On Tue, Sep 24, 2013 at 4:42 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Hi everyone! > I want to let you know that I've just posted a screencast in my blog about > the new Mars Package Browser and Test Runner<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…> > . > These examples are not really intended as being the definitive package > browser or test runner, but to start experiencing how is it to build a real > application using Mars and to showcase some widgets. Anyway, it's cool :) > The Package browser is not so different to the system browser example I > showed before, but the Test Runner is definitely my favorite example so far. > > I give more details in the screencast<http://www.youtube.com/watch?v=RlBr42uaqxE>and the blog > post<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…>. > Any feedback is appreciated! > > Cheers, > Carla. > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >

Sept. 24, 2013

Re: [Pharo-users] www.smalltalkhub.com not reachable from digitalocean host in NewYork2

by Yanni Chiu

On 24/09/13 12:45 AM, btc(a)openinworld.com wrote: > > Can you try traceroute from those hosts. traceroute to www.smalltalkhub.com (88.190.31.116), 30 hops max, 60 byte packets 1 ... 3.148 ms 3.198 ms 3.287 ms 2 nyk-b6-link.telia.net (62.115.35.101) 30.006 ms 30.012 ms 30.005 ms 3 nyk-b5-link.telia.net (213.155.131.116) 0.362 ms nyk-b5-link.telia.net (213.155.131.254) 0.413 ms 0.422 ms 4 cogent-ic-151338-nyk-b5.c.telia.net (213.248.85.106) 0.954 ms cogent-ic-151337-nyk-b5.c.telia.net (213.248.73.198) 0.711 ms cogent-ic-151338-nyk-b5.c.telia.net (213.248.85.106) 1.006 ms 5 be2063.mpd22.jfk02.atlas.cogentco.com (154.54.47.57) 0.955 ms be2062.mpd21.jfk02.atlas.cogentco.com (154.54.7.13) 1.290 ms be2063.mpd22.jfk02.atlas.cogentco.com (154.54.47.57) 1.068 ms 6 te0-0-0-9.mpd22.par01.atlas.cogentco.com (154.54.46.106) 72.081 ms te0-0-0-9.ccr22.par01.atlas.cogentco.com (154.54.46.102) 72.745 ms te0-7-0-11.mpd21.par01.atlas.cogentco.com (154.54.46.110) 72.160 ms 7 be2039.mag21.par01.atlas.cogentco.com (154.54.75.2) 74.243 ms be2041.mag21.par01.atlas.cogentco.com (154.54.78.42) 73.472 ms be2039.mag21.par01.atlas.cogentco.com (154.54.75.2) 76.817 ms 8 snsci.demarc.cogentco.com (149.6.160.50) 73.537 ms 149.6.160.102 (149.6.160.102) 73.453 ms 149.6.115.26 (149.6.115.26) 73.872 ms 9 bzn-crs16-1-be1106.intf.routers.proxad.net (212.27.59.101) 81.011 ms 78.111 ms 87.806 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

Sept. 24, 2013

Re: [Pharo-users] www.smalltalkhub.com not reachable from digitalocean host in NewYork2

by btc＠openinworld.com

Sept. 24, 2013