Re: [Pharo-users] Starting a pool of worker images using command line parameters
Hi Sven and Phil, Thanks for your answers. So I already use the zeroconf handlers ;-) The problem is that I do not benefit from the cache well enough because our command line tool (pharo-based and installed by this script http://car.mines-douai.fr/scripts/PhaROS) is dedicated to create custom images at specific path and currently I rebuild everything to have an up-to-date version at creation time (vm,pharo, code). I should probably create all images in the directory and then move them. Thanks, #Luc 2014-10-24 8:12 GMT+02:00 p...@highoctane.be : > On Fri, Oct 24, 2014 at 12:50 AM, Luc Fabresse > wrote: > >> Hi, >> >> >>> 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. >>> >> >> what are zeroconf "handlers"? >> > > the things you get in the list when you do ./pharo someimage.image --list > > So "save" is one. > > There is one in here if you like a sample. > https://github.com/philippeback/Bubble > > >> because I use zeroconf to rebuild images and it is slow because it >> downloads the vm, the image, the mcz then installing, ... >> did I missed something? >> > > No, but as my full build takes half an hour on a powerful box, this is not > practical to do like that. > So: > > CI JOB 1 (half an hour, every once in a while) > --- > - get pharo > - get image > - build "baseworker" image with standard packages etc > > CI JOB2 (whenever a commit is done in git, lasts a minute max) > -- > - take baseworker > - pull from repo > - build user code upon the base worker > > HTH > Phil > >> >> thx, Sven and Esteban, I like reading development and deployment >> processes from experienced people! >> >> #Luc >> >> >>> >>> > 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. >>> >>> > 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. >>> >>> > Regards, >>> > >>> > Esteban A. Maringolo >>> > >>> >>> >>> >> >
Re: [Pharo-users] Pharo program examples
Le 23/10/2014 22:48, Peter Uhnák a écrit : > But if you want introductory-level then there is "A first application" > chapter in Pharo by Example book (http://pharobyexample.org/) This book is a good resource to learn. To test the examples be sure to download the matching "Pharo by Example" image because some examples may not work out of the box with a more rencent Pharo. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
[Pharo-users] [ANN] iStoa 14.10
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
Re: [Pharo-users] Client cerificate authentication with ZnClient?
Op 22-okt.-2014, om 13:39 heeft Sven Van Caekenberghe 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 Description: Binary data
Re: [Pharo-users] Starting a pool of worker images using command line parameters
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
Re: [Pharo-users] Client cerificate authentication with ZnClient?
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 wrote: > > Op 22-okt.-2014, om 13:39 heeft Sven Van Caekenberghe 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 > >
[Pharo-users] Teaching fork
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
Re: [Pharo-users] Teaching fork
you can also use: 1 second wait. 2 seconds wait. ;-) Luc 2014-10-24 14:11 GMT+02:00 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 >
Re: [Pharo-users] Starting a pool of worker images using command line parameters
>> 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/
Re: [Pharo-users] Starting a pool of worker images using command line parameters
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 :
>>> 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/
[Pharo-users] [ANN] new GT features: disk memory, ws.stfx.eu sharing, closeable panes and others
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-memory-sharing-and-others/ Let us know what you think. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
