October 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] new GT features: disk memory, ws.stfx.eu sharing, closeable panes and others

by Sven Van Caekenberghe

Very nice. What would be the correct way to load this ahead of integration in Pharo 4 ? ConfigurationOfGTPlayground loadDevelopment ? I improved the deployment of ws.stfx.eu a bit, it is very old. Browser detection was broken. I am trying to improve the look, but I am not yet finished. I would like to use solarized dark styling. We also need a way to open a shared workspace in/as a GT Playground, give a URL on the clipboard or typed in. Then I can updated the contents of the help workspace, http://ws.stfx.eu/1WS4U I like the 'save in cloud' formulation ! Sven > On 25 Oct 2014, at 06:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are quite actively working on GT. > > First of all, thanks everyone for the feedback. We take it quite seriously and we do our best to take it into account. Please keep the discussions flowing. > > I summarized some of the things that happened recently in the playground and inspector here: > http://www.humane-assessment.com/blog/gt-developments-endless-playground-me… > > Let us know what you think. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 25, 2014

Re: [Pharo-users] Slow at browsing

by Thierry Goubier

Le 25/10/2014 12:39, Nicolai Hess a Ã©crit : > Maybe this one: > > 12535 <https://pharo.fogbugz.com/default.asp?12535> To many updates on > the methods list You certainly seems to be onto something there. 12535? 12931 as well? Looks like some have computers that are too fast to notice the slowdown ;) Thierry

Oct. 25, 2014

Self-removing announcement subscription?

by Jan B.

Hi all Today I come with a question regarding announcements. I would like to make announcement subscription which would remove itself after first use. Something like... anObject announcer subscribe: TRMouseDragEnd do: [ :event | self thisMethodWith: differentParameters. "anObject announcer removeSubscription: ...this one..." ]. All I was able to do is write there anObject announcer unsubscribe: self. which somehow works, but this instance could have multiple subscriptions and it would remove even those I don't want to remove, I need to remove only this specific one... Jan -- View this message in context: http://forum.world.st/Self-removing-announcement-subscription-tp4786622.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 25, 2014

Re: [Pharo-users] Slow at browsing

by Nicolai Hess

Maybe this one: 12535 <https://pharo.fogbugz.com/default.asp?12535> To many updates on the methods list 2014-10-25 12:06 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Hilaire, > > maybe profiling could show something. Nautilus could benefit from some > love in making it faster :) > > I know that my browser, AltBrowser, is a lot faster on a slow machine (x7 > faster on startup time compared to Nautilus, x3 faster than the old system > browser). So it could be done. > > (and Spur could give us a x2 boost on top of all those times :) :) ) > > Thierry > > Le 25/10/2014 11:55, Hilaire a Ã©crit : > > Hello, >> >> In Pharo 3.0 (and with Pharo 2.0), I noted an important slowness when >> browsing importantly populated class. >> >> For example, clicking on a method category of the Morph class, it takes >> about 3 seconds to reveals its methods. With Pharo 1.4 it is immediate >> with the same Morph class. >> >> My computer is a slow dog but it is not a good reason for this slowness. >> >> Hilaire >> >> >> > >

Oct. 25, 2014

Re: [Pharo-users] Slow at browsing

by Hilaire

Le 25/10/2014 12:15, Sven Van Caekenberghe a Ã©crit : >> > Hi Hilaire, >> > >> > maybe profiling could show something. Nautilus could benefit from some love in making it faster :) > Yes, help is always welcome. > > There is a lot of caching going on, things should work faster after the first time. > It is rather a flat response time: in that part, it does not get faster the more I browse and rebrowse on the same method category. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 25, 2014

Re: [Pharo-users] Slow at browsing

by Sven Van Caekenberghe

> On 25 Oct 2014, at 12:06, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Hilaire, > > maybe profiling could show something. Nautilus could benefit from some love in making it faster :) Yes, help is always welcome. There is a lot of caching going on, things should work faster after the first time. > I know that my browser, AltBrowser, is a lot faster on a slow machine (x7 faster on startup time compared to Nautilus, x3 faster than the old system browser). So it could be done. > > (and Spur could give us a x2 boost on top of all those times :) :) ) > > Thierry > > Le 25/10/2014 11:55, Hilaire a Ã©crit : >> Hello, >> >> In Pharo 3.0 (and with Pharo 2.0), I noted an important slowness when >> browsing importantly populated class. >> >> For example, clicking on a method category of the Morph class, it takes >> about 3 seconds to reveals its methods. With Pharo 1.4 it is immediate >> with the same Morph class. >> >> My computer is a slow dog but it is not a good reason for this slowness. >> >> Hilaire >> >> > >

Oct. 25, 2014

Embracing Morph

by Hilaire

Hello, I fell like asking this question is ridiculous, but I can't see it in the Morph populations. I would like an owner Morph where I add submorph at random positions, then I want the owner morph to automatically shrink its extent to its submorphs. Apparently it does not exist. Am I missing somethings? Thanks Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 25, 2014

Re: [Pharo-users] Slow at browsing

by Thierry Goubier

Hi Hilaire, maybe profiling could show something. Nautilus could benefit from some love in making it faster :) I know that my browser, AltBrowser, is a lot faster on a slow machine (x7 faster on startup time compared to Nautilus, x3 faster than the old system browser). So it could be done. (and Spur could give us a x2 boost on top of all those times :) :) ) Thierry Le 25/10/2014 11:55, Hilaire a Ã©crit : > Hello, > > In Pharo 3.0 (and with Pharo 2.0), I noted an important slowness when > browsing importantly populated class. > > For example, clicking on a method category of the Morph class, it takes > about 3 seconds to reveals its methods. With Pharo 1.4 it is immediate > with the same Morph class. > > My computer is a slow dog but it is not a good reason for this slowness. > > Hilaire > >

Oct. 25, 2014

Slow at browsing

by Hilaire

Hello, In Pharo 3.0 (and with Pharo 2.0), I noted an important slowness when browsing importantly populated class. For example, clicking on a method category of the Morph class, it takes about 3 seconds to reveals its methods. With Pharo 1.4 it is immediate with the same Morph class. My computer is a slow dog but it is not a good reason for this slowness. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 25, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by Norbert Hartl

There is a lot of polling going on. You can't get rid of it completely. To lower the cpu usage it might be good to suspend the ui thread. You need some external trigger to resume it if you want to connect via RFB. Norbert > Am 24.10.2014 um 22:18 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > > Ah, I forgot. > > The only drawback here is the 5% permanent idle load per image. > Every image I add adds a 5% load to the server, even when it's only standby. > > That's a totally bummer, though manageable if you have less than 10 > images like I do :) > > > > > > Esteban A. Maringolo > > > 2014-10-24 16:29 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >>>> I'd like to know the development process of others, from SCM to >>>> building, deploying and server provisioning. >>> >>> I would say the standard approach is: >>> >>> - use Monticello with any repo type >>> - split your code in some big modules, some private, some from public source >>> - have a single overarching Metacello configuration >>> - use zeroconf to build images >>> - optionally use a CI >>> >>> Note that zeroconf handlers allow you to build images incrementally (the image is saved after each build), which is way faster than always starting from scratch. >> >> I'm good then, I'm doing everything you listed except CI. >> >>>> After a year o Pharo development I think I'm ready to embrace a CI >>>> server (I already use scripts to build images), but I think I will >>>> move all my repositories to git before. >>> >>> These are orthogonal decisions, most CI jobs on the Pharo contribution server run against StHub. >> >> I want git because I want to use BitBucket to store my code :) >> >>>> However, my remote server provisioning is still manual, and too >>>> rudimentary even for my own taste. If I could speed up this, I would >>>> deliver features faster to my customers. Now everything runs inside a >>>> two week sprint window. >> >>> I am not into provisioning myself, but more automation is always good, though sometimes setting up and maintaining all these things takes a lot of time as well. >> >> It does take time, and "in theory" it works. I have this printed in my >> desktop: http://xkcd.com/1319/ :) >> >> >> Wrapping up, I implemented your no-commandline handler solution. >> >> I added a few servers to the upstreams of my site nginx configuration like this: >> >> upstream seaside { >> ip_hash; >> server 127.0.0.1:8080; >> server 127.0.0.1:8081; >> server 127.0.0.1:8082; >> server 127.0.0.1:8083; >> } >> >> upstream apimobile { >> server 127.0.0.1:8180; >> server 127.0.0.1:8181; >> } >> >> >> And added the following to my following supervisord.conf [1] >> >> [program:app_webworker] >> command=/home/trentosur/app/pharo app.image webworker.st 818%(process_num)1d >> process_name=%(program_name)s_%(process_num)02d ; process_name expr >> (default %(program_name)s) >> numprocs=4 >> directory=/home/trentosur/app >> autostart=true >> autorestart=true >> user=trentosur >> stopasgroup=true >> killasgroup=true >> >> [program:app_apiworker] >> command=/home/trentosur/app/pharo app.image apiworker.st 918%(process_num)1d >> process_name=%(program_name)s_%(process_num)02d ; process_name expr >> (default %(program_name)s) >> numprocs=2 >> directory=/home/trentosur/app >> autostart=true >> autorestart=true >> user=trentosur >> stopasgroup=true >> killasgroup=true >> >> >> Then this will spawn a [numproc] number of monitored processes, using >> the process number (process_num, in terms of pool) as a parameter to >> the startup script. >> The good thing here is, IMO, I can add more workers without having to >> modify anything on the Pharo side, it is... I can delegate this to >> regular sysadmin :) >> >> >> Best regards, >> >> >> Esteban A. Maringolo >> >> [1] http://supervisord.org/ >

Oct. 25, 2014