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

[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

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

by stepharo

this nice discussion should be turned into a blog/chapter :) Any taker? Stef On 23/10/14 20:16, Esteban A. Maringolo wrote: > tl;dr version: > > I'd like to be able to do something like > > $PATH/app/pharo-vm/pharo --nodisplay app.image st setup-worker.st --port 8091 > and: > $PATH/app/pharo-vm/pharo --nodisplay app.image st setup-worker.st --port 8092 > etc. > > Do I have to define a subclass of STCommandLineHandler? > > How can I capture the --port argument? For what I saw, only "boolean" > parameters can be defined (--quit, --save, etc, without arguments). It > is, no getopts compatibility. > > > Long version: > For my apps I have a pool of worker images with Zinc+Seaside behind an > nginx proxy. > > Each "upstream" (aka "worker") server, is started by supervisord, > using a separate startup smalltalk script, where the only thing I > change is the port of ZnZincServerAdaptor to start on a different > port. The rest is identical. > > The startup is something like: > $PATH/app/pharo-vm/pharo --nodisplay app.image st setup-worker1.st > and for worker2: > $PATH/app/pharo-vm/pharo --nodisplay app.image st setup-worker2.st > and for worker3: > $PATH/app/pharo-vm/pharo --nodisplay app.image st setup-worker3.st > etc. > > Is there a better way to perform this without having to copy > setup-worker1.st to setup-workerN.st for each worker image? > > How do you manage this? > > Regards, > > Esteban A. Maringolo > >

Oct. 24, 2014

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

by Kris Gybels

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

Oct. 24, 2014

[ANN] iStoa 14.10

by Hilaire

iStoa 14.10 for GNU/Linux released! It is a Pharo desktop application. iStoa is a corpus of math interactive exercises for grade 1. It comes with about 25 set of exercises, presented in categories. The project is in active development, new set of exercises are regularly added. http://istoa.drgeo.eu Thanks for feedbacks, suggestions and contributions. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 24, 2014

Re: [Pharo-users] [squeak-dev] VM crash

by Annick Fron

Hi Eliot, It seems the problem comes from my C program called by FFI. Thank you Annick Le 23 oct. 2014 Ã 06:01, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > Hi Annick, > > On Wed, Oct 22, 2014 at 5:46 AM, Annick Fron <list(a)afceurope.com> wrote: > I have an error : > > Â« donât know how to derive register state from a ucontext_t on this platform Â» > > That's just telling you that the VM doesn't know how to print the register state in a signal handler on this platform. What is your platform? What VM are you using? (vm -version) At least on Mac and x86 linux the VM /can/ do this, and hence print useful information when there's a crash. > > > Where could that come from ? > > Annick > > > > -- > best, > Eliot

Oct. 24, 2014