- Pharo-users - lists.pharo.org

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

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

by Tudor Girba

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] Starting a pool of worker images using command line parameters

by Esteban A. Maringolo

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. 24, 2014

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

by Esteban A. Maringolo

>> 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. 24, 2014

Re: [Pharo-users] Teaching fork

by Luc Fabresse

you can also use: 1 second wait. 2 seconds wait. ;-) Luc 2014-10-24 14:11 GMT+02:00 Annick Fron <list(a)afceurope.com>: > > Here is a simple example about fork. > > Try the following : > > 10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript show: âhelloâ;cr]. > > Then the following : > [10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript show: > âhelloâ;cr]] fork. > > I think this should go in an introduction to Pharo. > > Annick >

Oct. 24, 2014

Teaching fork

by Annick Fron

Here is a simple example about fork. Try the following : 10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript show: âhelloâ;cr]. Then the following : [10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript show: âhelloâ;cr]] fork. I think this should go in an introduction to Pharo. Annick

Oct. 24, 2014

Re: [Pharo-users] Client cerificate authentication with ZnClient?

by Sven Van Caekenberghe

Kris, I merged your changes in (except for the default being false instead of true for logging) - Thanks! === Name: Zodiac-Core-SvenVanCaekenberghe.35 Author: SvenVanCaekenberghe Time: 24 October 2014, 1:56:40.080389 pm UUID: d27bbfa1-187d-4ab9-b7e8-5a77a34aeb6a Ancestors: Zodiac-Core-KrisGybels.32 Merging in Kris' code to enable logging of the native code inside the plugin (Thx Kris Gybels) Disabled the experimental changes in 32 Jumping over some versions that exist out there === Sven > On 24 Oct 2014, at 12:55, Kris Gybels <kris(a)yesplan.be> wrote: > > Op 22-okt.-2014, om 13:39 heeft Sven Van Caekenberghe <sven(a)stfx.eu> het volgende geschreven: > >> I do not know how to enable the logging inside the plugin, Chris Gybels just told me that he got that working, maybe he can answer. Kris ? > > Here's a version of Zodiac-Core with ZdcPluginSSLSession changed to enable the logging done by the SSL plugin, if that helps. > > On a Mac, to see the output of the plugin, you need to run the VM from the Terminal. If you execute [ ZnClient new url: 'https://www.google.com'; get ] in a workspace, you should see some output like this in the Terminal: > > $ /Applications/Pharo.app/Contents/MacOS/Pharo Pharo.image > sqConnectSSL: 2d9a30 > sqConnectSSL: input token 0 bytes > sqConnectSSL: Setting up SSL > sqSetupSSL: Setting up new context > SqueakSSLWrite: Writing 158 bytes, having 17408 free > SqueakSSLRead: Requesting 1 bytes, having 0 bytes > sqConnectSSL: Produced 158 token bytes > sqConnectSSL: 2d9a30 > [...] > > The output on Linux / Windows will be somewhat different I assume, I haven't tried it. To understand what is being logged, you'll need to look at the C code of the plugin: > > https://code.google.com/p/squeakssl/source/browse/src/#src > > <Zodiac-Core-KrisGybels.32.mcz>

Oct. 24, 2014