Re: [Pharo-users] pharo bash script with startup

[Otto Behrens]

Thanks for the effort guys.

I tried to download the image, sources and vm separately (basically
extracted what https://get.pharo.org/64/61+vm does), but ran into fresh
trouble.

Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in
terms of security? It should be quite possible to inject a lovely trojan
horse with this, or not?

Secondly, the pharo bash script that it generates is different to the one
in the zip. The directory structure (where the image & vm goes) is also
different. Why is that?

I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with
the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and
got the following, which I tried to do, but that did not take the message
away:

pthread_setschedparam failed: Operation not permitted
This VM uses a separate heartbeat thread to update its internal clock
and handle events.  For best operation, this thread should run at a
higher priority, however the VM was unable to change the priority.  The
effect is that heavily loaded systems may experience some latency
issues.  If this occurs, please create the appropriate configuration
file in /etc/security/limits.d/ as shown below:

cat < wrote:

> When we get confirmation of success - we need to make sure this gets
> applied to both zeroconf and official downloads.
>
> Anything we can do to simplify and make it robust is gratefully
> appreciated as there is nothing worse than falling at the lunch hurdle.
>
> It’s cool to see so many clever minds on this.
>
> Tim
>
> Sent from my iPhone
>
> > On 27 Jun 2018, at 19:52, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
> >
> > 2018-06-27 10:50 GMT-03:00 K K Subbu :
> >>> On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
> >>>
> >>>
> >>> The double quotes are required here to skip splitting arguments with
> >>> embedded spaces into different words.
> >>>
> >>> I suspect the error is earlier in the image=$@ assignment. This
> requires
> >>> double quotes. Double quotes are also required while calling zenity to
> avoid
> >>> word splitting.
> >>
> >>
> >> My earlier fix is also in error, Sorry!
> >>
> >> Essentially, we are mixing up single value variable (image) with
> argument
> >> array ($@). I found a cleaner fix :
> >>
> >> 
> >> if [ $# -eq 0 ]; then
> >>image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l`
> >>if [ "$image_count"  -eq 1 ]; then
> >>set -- "$RESOURCES"/*.image
> >>elif which zenity &>/dev/null; then
> >>set -- "$(zenity --title 'Select an image'
> --file-selection
> >> --filename "$RESOURCES/" --file-filter '*.image' --file-
> >> filter '*')"
> >>else
> >>set -- "$RESOURCES/Pharo6.1-64.image"
> >>fi
> >> fi
> >>
> >
> > Use $() instead of backticks for command substitution:
> > http://mywiki.wooledge.org/BashFAQ/082
> >
> > Cheers,
> >
> > Hernán
> >
> >> # execute
> >> exec "$LINUX/pharo" \
> >>--plugins "$LINUX" \
> >>--encoding utf8 \
> >>-vm-display-X11 \
> >>"$@"
> >> 
> >>
> >> HTH .. Subbu
> >>
> >
>
>
>

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

[Tim Mackinnon]

For the record - I get the same error using those steps on Ubuntu as well. So I 
must be doing something wrong?

(Note in my message when I pasted the command used - I neglected the git in 
front of: log --diff-filter=D --summary —pretty="format:%cd | %h | %H | %cn%n-> 
%s%n”)



Tim

> On 28 Jun 2018, at 00:46, Tim Mackinnon  wrote:
> 
> And just to add to this - I just did a git clone (git clone g...@github.com 
> :pharo-project/pharo.git)  in a fresh directory and 
> can see that same deleted file - and when I try to do a checkout, it gives 
> the path spec error.
> 
> This is very weird - is it some osx thing? I will try it on ubuntu - but I 
> feel I must be missing something, like do I need a different prefix on path 
> names (but you didn’t seem to need one)?
> 
> I’d be very worried if git is acting up… but I still suspect user error here.
> 
> Tim
> 
> 
>> On 28 Jun 2018, at 00:38, Tim Mackinnon > > wrote:
>> 
>> Hey thanks Ben - this still doesn’t work for me… good idea to try on the 
>> Pharo repo itself.
>> 
>> I have a fork of it, which I catch up periodically - so I tried a similar 
>> suggestion to you - went into my directory (underneath the src folder) and 
>> typed:
>> 
>> log --diff-filter=D --summary --graph --pretty='format:%cd | %h | %H | 
>> %cn%n-> %s%n’
>> 
>> This gave me:
>> 
>> Tue Jun 19 19:28:37 2018 +0200 | 13e81343e | 
>> 13e81343e8a23a8d6ca43f1c77b804b8134fc986 | CyrilFerlicot
>> -> Remove now useless logs
>> 
>>  delete mode 100755 bootstrap/scripts/printFolderContent.sh
>> 
>> Mon Jun 18 16:50:19 2018 +0200 | 0433d908d | 
>> 0433d908de2987fa0069a47dee1f0794ccbb52c2 | GitHub
>> -> Revert "22161-Add-more-log-to-bootstrap"
>> 
>>  delete mode 100755 bootstrap/scripts/printFolderContent.sh
>> 
>> Thu Jun 14 11:41:16 2018 +0200 | b4a285a61 | 
>> b4a285a61d3eb0cc1e642b2fcc242dac7092617f | Marcus Denker
>> -> fix the last sender of #asIcon 
>> https://pharo.fogbugz.com/f/cases/22139/fix-the-last-sender-of-asIcon 
>> 
>> 
>>  delete mode 100644 src/Polymorph-Widgets-Rules/IconShortcutRule.class.st 
>> 
>> 
>> So then I tried to recover that last one (again at root underneath the src 
>> directory)
>> 
>> git checkout b4a285a61 src/Polymorph-Widgets-Rules/IconShortcutRule.class.st 
>> 
>> error: pathspec 'src/Polymorph-Widgets-Rules/IconShortcutRule.class.st 
>> ' did not match any file(s) known to git.
>> 
>> And I still get that dreaded pathspec error. This is on OSX (not windows) - 
>> so I’m struggling to understand what I could be doing wrong. It must be 
>> something obvious - but damned if I can see how I’m doing anything different 
>> to you. And it wouldn’t make sense that git is broken on OSX?
>> 
>> Tim
>> 
>>> On 25 Jun 2018, at 14:21, Ben Coman >> > wrote:
>>> 
>>> On 25 June 2018 at 19:41, Tim Mackinnon >> > wrote:
>>> I’d be really interested if someone with lower level GIT knowledge might 
>>> try a:
>>> 
>>> git checkout  src//.class.st 
>>>  
>>> 
>>> For their project - as I don’t understand what I’m doing wrong - and I’d 
>>> like the comfort of knowing that our source is in a place/state where we 
>>> can rely on normal git tools in a case of emergency. At the moment, I’m a 
>>> bit nervous that we are corrupting something .
>>> 
>>> Tim
>>> 
>>> I'm not sure if this is what you wanted, but I found a test case for for 
>>> Pharo 7, a deleted class "MultiByteFileStreamTest.class.st 
>>> "
>>> https://github.com/pharo-project/pharo/pull/1031/files#diff-750a25fb99d29cda8c2c388dc18f6c1cL1
>>>  
>>> 
>>> 
>>> From Windows 10 cmd.exe I tried the following (I can't remember which tool 
>>> installed `git`)...
>>> 
>>> > mkdir C:\temp\test
>>> > cd C:\temp\test
>>> > git clone g...@github.com :pharo-project/pharo.git
>>> > cd pharo\src\Deprecated70
>>> > dir  Multi*
>>> no result
>>> > git checkout e74308e67d9f84 MultiByteFileStreamTest.class.st 
>>> > 
>>> > dir Multi*
>>> MultiByteFileStreamTest.class.st 
>>> 
>>> Then I compared the file I checked out to the raw file on github and they 
>>> were identical...
>>> https://www.diffchecker.com/gVCpJzFe 
>>> 
>>> 
>>> btw, I did get a momentary error "error: pathspec 
>>> 'src/Deprecated70/MultiByteFileStreamTest.class.st 
>>> ' did not match any file(s) known 
>>> to git."
>>> when I incorrectly did...
>>> > cd pharo\src\Deprecated70
>>> > git  git checkout e74308e67d9f84  
>>> > src/Deprecated7

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

[Tim Mackinnon]

And just to add to this - I just did a git clone (git clone g...@github.com 
:pharo-project/pharo.git)  in a fresh directory and can 
see that same deleted file - and when I try to do a checkout, it gives the path 
spec error.

This is very weird - is it some osx thing? I will try it on ubuntu - but I feel 
I must be missing something, like do I need a different prefix on path names 
(but you didn’t seem to need one)?

I’d be very worried if git is acting up… but I still suspect user error here.

Tim


> On 28 Jun 2018, at 00:38, Tim Mackinnon  wrote:
> 
> Hey thanks Ben - this still doesn’t work for me… good idea to try on the 
> Pharo repo itself.
> 
> I have a fork of it, which I catch up periodically - so I tried a similar 
> suggestion to you - went into my directory (underneath the src folder) and 
> typed:
> 
> log --diff-filter=D --summary --graph --pretty='format:%cd | %h | %H | 
> %cn%n-> %s%n’
> 
> This gave me:
> 
> Tue Jun 19 19:28:37 2018 +0200 | 13e81343e | 
> 13e81343e8a23a8d6ca43f1c77b804b8134fc986 | CyrilFerlicot
> -> Remove now useless logs
> 
>  delete mode 100755 bootstrap/scripts/printFolderContent.sh
> 
> Mon Jun 18 16:50:19 2018 +0200 | 0433d908d | 
> 0433d908de2987fa0069a47dee1f0794ccbb52c2 | GitHub
> -> Revert "22161-Add-more-log-to-bootstrap"
> 
>  delete mode 100755 bootstrap/scripts/printFolderContent.sh
> 
> Thu Jun 14 11:41:16 2018 +0200 | b4a285a61 | 
> b4a285a61d3eb0cc1e642b2fcc242dac7092617f | Marcus Denker
> -> fix the last sender of #asIcon 
> https://pharo.fogbugz.com/f/cases/22139/fix-the-last-sender-of-asIcon 
> 
> 
>  delete mode 100644 src/Polymorph-Widgets-Rules/IconShortcutRule.class.st 
> 
> 
> So then I tried to recover that last one (again at root underneath the src 
> directory)
> 
> git checkout b4a285a61 src/Polymorph-Widgets-Rules/IconShortcutRule.class.st 
> 
> error: pathspec 'src/Polymorph-Widgets-Rules/IconShortcutRule.class.st 
> ' did not match any file(s) known to git.
> 
> And I still get that dreaded pathspec error. This is on OSX (not windows) - 
> so I’m struggling to understand what I could be doing wrong. It must be 
> something obvious - but damned if I can see how I’m doing anything different 
> to you. And it wouldn’t make sense that git is broken on OSX?
> 
> Tim
> 
>> On 25 Jun 2018, at 14:21, Ben Coman > > wrote:
>> 
>> On 25 June 2018 at 19:41, Tim Mackinnon > > wrote:
>> I’d be really interested if someone with lower level GIT knowledge might try 
>> a:
>> 
>> git checkout  src//.class.st 
>>  
>> 
>> For their project - as I don’t understand what I’m doing wrong - and I’d 
>> like the comfort of knowing that our source is in a place/state where we can 
>> rely on normal git tools in a case of emergency. At the moment, I’m a bit 
>> nervous that we are corrupting something .
>> 
>> Tim
>> 
>> I'm not sure if this is what you wanted, but I found a test case for for 
>> Pharo 7, a deleted class "MultiByteFileStreamTest.class.st 
>> "
>> https://github.com/pharo-project/pharo/pull/1031/files#diff-750a25fb99d29cda8c2c388dc18f6c1cL1
>>  
>> 
>> 
>> From Windows 10 cmd.exe I tried the following (I can't remember which tool 
>> installed `git`)...
>> 
>> > mkdir C:\temp\test
>> > cd C:\temp\test
>> > git clone g...@github.com :pharo-project/pharo.git
>> > cd pharo\src\Deprecated70
>> > dir  Multi*
>> no result
>> > git checkout e74308e67d9f84 MultiByteFileStreamTest.class.st 
>> > 
>> > dir Multi*
>> MultiByteFileStreamTest.class.st 
>> 
>> Then I compared the file I checked out to the raw file on github and they 
>> were identical...
>> https://www.diffchecker.com/gVCpJzFe 
>> 
>> 
>> btw, I did get a momentary error "error: pathspec 
>> 'src/Deprecated70/MultiByteFileStreamTest.class.st 
>> ' did not match any file(s) known 
>> to git."
>> when I incorrectly did...
>> > cd pharo\src\Deprecated70
>> > git  git checkout e74308e67d9f84  
>> > src/Deprecated70/MultiByteFileStreamTest.class.st 
>> > 
>> 
>> 
>> This worked with the longer path... 
>> > cd pharo
>> > git  git checkout e74308e67d9f84  
>> > src/Deprecated70/MultiByteFileStreamTest.class.st 
>> > 
>> cheers -ben
> 

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

[Tim Mackinnon]

Hey thanks Ben - this still doesn’t work for me… good idea to try on the Pharo 
repo itself.

I have a fork of it, which I catch up periodically - so I tried a similar 
suggestion to you - went into my directory (underneath the src folder) and 
typed:

log --diff-filter=D --summary --graph --pretty='format:%cd | %h | %H | %cn%n-> 
%s%n’

This gave me:

Tue Jun 19 19:28:37 2018 +0200 | 13e81343e | 
13e81343e8a23a8d6ca43f1c77b804b8134fc986 | CyrilFerlicot
-> Remove now useless logs

 delete mode 100755 bootstrap/scripts/printFolderContent.sh

Mon Jun 18 16:50:19 2018 +0200 | 0433d908d | 
0433d908de2987fa0069a47dee1f0794ccbb52c2 | GitHub
-> Revert "22161-Add-more-log-to-bootstrap"

 delete mode 100755 bootstrap/scripts/printFolderContent.sh

Thu Jun 14 11:41:16 2018 +0200 | b4a285a61 | 
b4a285a61d3eb0cc1e642b2fcc242dac7092617f | Marcus Denker
-> fix the last sender of #asIcon 
https://pharo.fogbugz.com/f/cases/22139/fix-the-last-sender-of-asIcon

 delete mode 100644 src/Polymorph-Widgets-Rules/IconShortcutRule.class.st

So then I tried to recover that last one (again at root underneath the src 
directory)

git checkout b4a285a61 src/Polymorph-Widgets-Rules/IconShortcutRule.class.st
error: pathspec 'src/Polymorph-Widgets-Rules/IconShortcutRule.class.st' did not 
match any file(s) known to git.

And I still get that dreaded pathspec error. This is on OSX (not windows) - so 
I’m struggling to understand what I could be doing wrong. It must be something 
obvious - but damned if I can see how I’m doing anything different to you. And 
it wouldn’t make sense that git is broken on OSX?

Tim

> On 25 Jun 2018, at 14:21, Ben Coman  wrote:
> 
> On 25 June 2018 at 19:41, Tim Mackinnon  > wrote:
> I’d be really interested if someone with lower level GIT knowledge might try 
> a:
> 
> git checkout  src//.class.st 
>  
> 
> For their project - as I don’t understand what I’m doing wrong - and I’d like 
> the comfort of knowing that our source is in a place/state where we can rely 
> on normal git tools in a case of emergency. At the moment, I’m a bit nervous 
> that we are corrupting something .
> 
> Tim
> 
> I'm not sure if this is what you wanted, but I found a test case for for 
> Pharo 7, a deleted class "MultiByteFileStreamTest.class.st 
> "
> https://github.com/pharo-project/pharo/pull/1031/files#diff-750a25fb99d29cda8c2c388dc18f6c1cL1
>  
> 
> 
> From Windows 10 cmd.exe I tried the following (I can't remember which tool 
> installed `git`)...
> 
> > mkdir C:\temp\test
> > cd C:\temp\test
> > git clone g...@github.com:pharo-project/pharo.git
> > cd pharo\src\Deprecated70
> > dir  Multi*
> no result
> > git checkout e74308e67d9f84 MultiByteFileStreamTest.class.st 
> > 
> > dir Multi*
> MultiByteFileStreamTest.class.st 
> 
> Then I compared the file I checked out to the raw file on github and they 
> were identical...
> https://www.diffchecker.com/gVCpJzFe 
> 
> 
> btw, I did get a momentary error "error: pathspec 
> 'src/Deprecated70/MultiByteFileStreamTest.class.st 
> ' did not match any file(s) known 
> to git."
> when I incorrectly did...
> > cd pharo\src\Deprecated70
> > git  git checkout e74308e67d9f84  
> > src/Deprecated70/MultiByteFileStreamTest.class.st 
> > 
> 
> 
> This worked with the longer path... 
> > cd pharo
> > git  git checkout e74308e67d9f84  
> > src/Deprecated70/MultiByteFileStreamTest.class.st 
> > 
> cheers -ben

Re: [Pharo-users] pharo bash script with startup

[Tim Mackinnon]

When we get confirmation of success - we need to make sure this gets applied to 
both zeroconf and official downloads.

Anything we can do to simplify and make it robust is gratefully appreciated as 
there is nothing worse than falling at the lunch hurdle.

It’s cool to see so many clever minds on this.

Tim

Sent from my iPhone

> On 27 Jun 2018, at 19:52, Hernán Morales Durand  
> wrote:
> 
> 2018-06-27 10:50 GMT-03:00 K K Subbu :
>>> On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
>>> 
>>> 
>>> The double quotes are required here to skip splitting arguments with
>>> embedded spaces into different words.
>>> 
>>> I suspect the error is earlier in the image=$@ assignment. This requires
>>> double quotes. Double quotes are also required while calling zenity to avoid
>>> word splitting.
>> 
>> 
>> My earlier fix is also in error, Sorry!
>> 
>> Essentially, we are mixing up single value variable (image) with argument
>> array ($@). I found a cleaner fix :
>> 
>> 
>> if [ $# -eq 0 ]; then
>>image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l`
>>if [ "$image_count"  -eq 1 ]; then
>>set -- "$RESOURCES"/*.image
>>elif which zenity &>/dev/null; then
>>set -- "$(zenity --title 'Select an image' --file-selection
>> --filename "$RESOURCES/" --file-filter '*.image' --file-
>> filter '*')"
>>else
>>set -- "$RESOURCES/Pharo6.1-64.image"
>>fi
>> fi
>> 
> 
> Use $() instead of backticks for command substitution:
> http://mywiki.wooledge.org/BashFAQ/082
> 
> Cheers,
> 
> Hernán
> 
>> # execute
>> exec "$LINUX/pharo" \
>>--plugins "$LINUX" \
>>--encoding utf8 \
>>-vm-display-X11 \
>>"$@"
>> 
>> 
>> HTH .. Subbu
>> 
> 

Re: [Pharo-users] pharo bash script with startup

[Hernán Morales Durand]

2018-06-27 10:50 GMT-03:00 K K Subbu :
> On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
>>
>>
>> The double quotes are required here to skip splitting arguments with
>> embedded spaces into different words.
>>
>> I suspect the error is earlier in the image=$@ assignment. This requires
>> double quotes. Double quotes are also required while calling zenity to avoid
>> word splitting.
>
>
> My earlier fix is also in error, Sorry!
>
> Essentially, we are mixing up single value variable (image) with argument
> array ($@). I found a cleaner fix :
>
> 
> if [ $# -eq 0 ]; then
> image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l`
> if [ "$image_count"  -eq 1 ]; then
> set -- "$RESOURCES"/*.image
> elif which zenity &>/dev/null; then
> set -- "$(zenity --title 'Select an image' --file-selection
> --filename "$RESOURCES/" --file-filter '*.image' --file-
> filter '*')"
> else
> set -- "$RESOURCES/Pharo6.1-64.image"
> fi
> fi
>

Use $() instead of backticks for command substitution:
http://mywiki.wooledge.org/BashFAQ/082

Cheers,

Hernán

> # execute
> exec "$LINUX/pharo" \
> --plugins "$LINUX" \
> --encoding utf8 \
> -vm-display-X11 \
> "$@"
> 
>
> HTH .. Subbu
>

Re: [Pharo-users] Yet another Pharo in docker

[Herbert Vojčík]

Updated with 60541 release of 6.1.

Herby Vojčík wrote on 18. 10. 2017 22:17:

Herby Vojčík wrote:

https://hub.docker.com/r/herbysk/pharo/


Thanks to gotchas@dockerhub whose scripts I adapted.

Re: [Pharo-users] pharo bash script with startup

[K K Subbu]

On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:


The double quotes are required here to skip splitting arguments with 
embedded spaces into different words.


I suspect the error is earlier in the image=$@ assignment. This requires 
double quotes. Double quotes are also required while calling zenity to 
avoid word splitting.


My earlier fix is also in error, Sorry!

Essentially, we are mixing up single value variable (image) with 
argument array ($@). I found a cleaner fix :



if [ $# -eq 0 ]; then
image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l`
if [ "$image_count"  -eq 1 ]; then
set -- "$RESOURCES"/*.image
elif which zenity &>/dev/null; then
		set -- "$(zenity --title 'Select an image' --file-selection --filename 
"$RESOURCES/" --file-filter '*.image' --file-

filter '*')"
else
set -- "$RESOURCES/Pharo6.1-64.image" 
fi
fi

# execute
exec "$LINUX/pharo" \
--plugins "$LINUX" \
--encoding utf8 \
-vm-display-X11 \
"$@"


HTH .. Subbu

Re: [Pharo-users] [Pharo-dev] [Ann] OSSubprocess v1.0.1

[Mariano Martinez Peck]

Excellent catch! Thanks Guille and the rest of the crew!

On Tue, Jun 26, 2018 at 11:25 AM Guillermo Polito 
wrote:

> Hi all,
>
> There is a new version of OSSubprocess available. This is a Bugfix
> release. This release fixes a problem with waitpid that happened
> regularly and randomly in OSSubprocess users mostly in the CI. For those
> interesting, the details of the bug can be read in:
>
> https://github.com/pharo-contributions/OSSubprocess/issues/36
> Bugfix list
>
> #39 
> travis_wait hides smalltalkCI output
> #36  Often
> get waitpid() -1 in CI
>
> Thanks a lot to Pablo and Santi that helped me debugging,
> Enjoy,
> Guille
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] Microservices using Pharo

[Norbert Hartl]

> Am 27.06.2018 um 15:08 schrieb Andrei Stebakov :
> 
> Thank you guys for your insiteful answers. I wish we could have some kind of 
> article summarizing those approaches so that next devs wouldn't have to 
> reinvent the wheel but start with some tried approach and maybe improve it.
> As I only scratched the surface learning Pharo, I may have some naive 
> questions.
> Does the fact (fact?) that Pharo uses green threads (not native os threads) 
> impact the performance? 

Yes and no. There is nothing wrong with green threads. They are super 
lightweight and enable some sort of parallelism. If you look at Erlang/OTP it 
handles ten thousands of green threads easily. The performance bottleneck is 
due to the fact that you cannot utilize multiple cores of a CPU. So it is usual 
to have some images being spread out to separate cores and the images handle 
things concurrently. 

> With two Pharo images running in parallel on two core system, how does it 
> handle multiple requests at a time? There must always be some unblocked 
> thread waiting for connections and delegating requests to request handlers in 
> different green threads (using fork operation). Is my understanding correct?

Not completely. It is also a green thread accepting connections. The priority 
is given due to a socket waiting on a system resource that gets signalled if a 
connection comes in. 

> So even if one of those threads has to wait on a long IO operation (say from 
> DB2) that shouldn't impact the performance of other handlers?

Exactly. That is the way through orchestration to have maximum throughput.

> I think that in most cases the CPU time for request processing is minal as 
> the bottleneck is in lengthy IO operations , DB waits and calling external 
> REST-ful services. So two images on two cores should be enough to handle 
> hundreds of simultaneous requests since most of the times the threads will 
> wait on external operations, not using the local CPU.

Yes, it depends on the use case of course.

> Please let me know if this summary that I got from this thread makes sense.
> Yes, I fully agree that using docker pharo containers under some load 
> balancing is the way to go. 
> 
I think your summary is pretty accurate. Docker also the advantage that it uses 
a lot of shared memory. So starting 100 pharo images most resources including 
the vm are in memory only once. 

Hope it helps,

Norbert
>> On Wed, Jun 27, 2018, 04:10 jtuc...@objektfabrik.de 
>>  wrote:
>> Norbert,
>> 
>> 
>> thanks for your insighgts, explanations and thoughts. It is good to read and 
>> learn from people who are a step or two ahead...
>> 
>>> Am 27.06.18 um 09:31 schrieb Norbert Hartl:
>>> Joachim,
>>> 
 Am 27.06.2018 um 07:42 schrieb jtuc...@objektfabrik.de:
 
 Norbert,
 
> Am 26.06.18 um 21:41 schrieb Norbert Hartl:
> 
> 
> Am 26.06.2018 um 20:44 schrieb Andrei Stebakov :
> 
>> What would be an example for load balancer for Pharo images? Can we run 
>> multiple images on the same server or for the sake of balancing 
>> configuration we can only run one image per server?
>> 
> There are a lot of possibilities. You can start multiple images on 
> different ports and use nginx with an upstream rule to load balance. I 
> would recommend using docker for spawning multiple images on a host. 
> Again with nginx as frontend load balancer. The point is that you can 
> have at least twice as muh inages running then you have CPU cores. And of 
> course a lot more.
> 
 
 the last time I checked nginx, the load balancing and sticky session stuff 
 was not available in the free edition. So I guess you either pay for nginx 
 (which I think is good) or you know some free 3d party addons...
 
>>> there is the upstream module which provides load balancing. But you are 
>>> right I think sticky sessions is not part of it. The closest you get IIRC 
>>> is IP based hashing.
>> I see.
>> 
>>> 
 I wonder what exactly the benefit of Docker is in that game? On our 
 servers we run 10 images on 4 cores with HT (8 virtual cores) and very 
 rareley have real performance problems. We use Glorp, so there is a lot of 
 SQL queriing going on for quite basic things already. So my guess would be 
 that your "2 images per core"  are conservative and leave air for even a 
 third one, depending on all the factors already discussed here.
  
>>> Docker is pretty nice. You can have the exact same deployment artefact 
>>> started multiple times. I used tools like daemontools, monit, etc. 
>>> before but starting the image, assigning ports etc. you have to do yourself 
>>> which is cumbersome and I don’t like any of those tools anymore. If you 
>>> created your docker image you can start that multiple times because 
>>> networking is virtualized all images can have the same port serving e.g.
>> 
>> oh, I see. This is a plus. We're not using any contain

Re: [Pharo-users] Microservices using Pharo

[Norbert Hartl]

> Am 27.06.2018 um 10:09 schrieb "jtuc...@objektfabrik.de" 
> :
> 
> Norbert,
> 
> 
> thanks for your insighgts, explanations and thoughts. It is good to read and 
> learn from people who are a step or two ahead...
> 
>> Am 27.06.18 um 09:31 schrieb Norbert Hartl:
>> Joachim,
>> 
>>> Am 27.06.2018 um 07:42 schrieb jtuc...@objektfabrik.de:
>>> 
>>> Norbert,
>>> 
 Am 26.06.18 um 21:41 schrieb Norbert Hartl:
 
 
 Am 26.06.2018 um 20:44 schrieb Andrei Stebakov :
 
> What would be an example for load balancer for Pharo images? Can we run 
> multiple images on the same server or for the sake of balancing 
> configuration we can only run one image per server?
> 
 There are a lot of possibilities. You can start multiple images on 
 different ports and use nginx with an upstream rule to load balance. I 
 would recommend using docker for spawning multiple images on a host. Again 
 with nginx as frontend load balancer. The point is that you can have at 
 least twice as muh inages running then you have CPU cores. And of course a 
 lot more.
 
>>> 
>>> the last time I checked nginx, the load balancing and sticky session stuff 
>>> was not available in the free edition. So I guess you either pay for nginx 
>>> (which I think is good) or you know some free 3d party addons...
>>> 
>> there is the upstream module which provides load balancing. But you are 
>> right I think sticky sessions is not part of it. The closest you get IIRC is 
>> IP based hashing.
> I see.
> 
>> 
>>> I wonder what exactly the benefit of Docker is in that game? On our servers 
>>> we run 10 images on 4 cores with HT (8 virtual cores) and very rareley have 
>>> real performance problems. We use Glorp, so there is a lot of SQL queriing 
>>> going on for quite basic things already. So my guess would be that your "2 
>>> images per core"  are conservative and leave air for even a third one, 
>>> depending on all the factors already discussed here.
>>>  
>> Docker is pretty nice. You can have the exact same deployment artefact 
>> started multiple times. I used tools like daemontools, monit, etc. before 
>> but starting the image, assigning ports etc. you have to do yourself which 
>> is cumbersome and I don’t like any of those tools anymore. If you created 
>> your docker image you can start that multiple times because networking is 
>> virtualized all images can have the same port serving e.g.
> 
> oh, I see. This is a plus. We're not using any containers and have to provide 
> individual configurations for each image we start up. Works well, not too 
> many moving parts (our resources are very limited) and we try to keep things 
> as simple as possible. As long as we can live with providing a statically 
> sized pool of machines and images and load doesn't vary too much, this is not 
> too bad. But once you need to dynamically add and remove images for coping 
> with load peeks and lows, our approach will probably become cumbersome and 
> complicated.

Sure. Your situation is exactly the one I had before. We have now a project 
that really needs to scale and managing resources is cumbersome. Docker helps a 
lot here. But I cannot say how hard the learning curve is because I‘m used to 
this kind of system stuff.

> OTOH, I guess usind Docker just means solving the same problems on another 
> level - but I guess there are lots of toosl in the Container area that can 
> help here (like the trafik thing mentioned in another thread).
> 
It is called traefik. You need that if you want load balancing to be dynamic. 
traefik listens to the docker daemon and figures out containers that need load 
balancing and adds them at runtime. And it supports sticky sessions. Or you use 
the commercial nginx which can do the same. 

Norbert
>> 
>> I think talking about performance these days is not easy. Modern machines 
>> are so fast that you need a lot of users before you experience any problems.
> ... depending on your usage of resources. As I said, we're using SQL heavily 
> because of the way Glorp works. So it is easy to introduce bottlenecks even 
> for smaller jobs.
>> The mention of „2 images per core“ I need to explain. A CPU core can execute 
>> only one thing at a time. Therefor 1 image per core would be enough. The 
>> second one is for that time slices where there are gaps in processing 
>> meaning the process is suspended, switched etc. It is just the rule of thumb 
>> that it is good to have one process waiting in the scheduling queue so it 
>> can step in as soon as there is free cycles. The „2 images per core“ have 
>> the assumption that you can put an arbitrary load on one image. So with this 
>> assumption a third image won’t give you anything because it cannot do 
>> anything the other two images cannot do.
>> So according to the „hard“ facts it does not help having more than two 
>> images. On the other hand each image is single threaded and using more 
>> images lowers the probabil

Re: [Pharo-users] pharo bash script with startup

[K K Subbu]

On Wednesday 27 June 2018 01:08 PM, Otto Behrens wrote:

I am running with an absolute image path.

The issue is definitely exec "$image" in the script. If I remove the
"", i.e. exec $image, then it works.


The double quotes are required here to skip splitting arguments with 
embedded spaces into different words.


I suspect the error is earlier in the image=$@ assignment. This requires 
double quotes. Double quotes are also required while calling zenity to 
avoid word splitting.


Also, the image_count should be checked before calling zenity.

Can you try with this version?


if [ $# -eq 0 ]; then
image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l`
if [ "$image_count"  -eq 1 ]; then
image="$RESOURCES"/*.image
elif which zenity &>/dev/null; then
		image="$(zenity --title 'Select an image' --file-selection --filename 
"$RESOURCES/" --file-filter '*.image' --file-filter '*')"

else
image="$RESOURCES/Pharo6.1-64.image"  
fi
else
image="$@"
fi

# execute
exec "$LINUX/pharo" \
--plugins "$LINUX" \
--encoding utf8 \
-vm-display-X11 \
"$image"


HTH .. Subbu

Re: [Pharo-users] Microservices using Pharo

[Andrei Stebakov]

Thank you guys for your insiteful answers. I wish we could have some kind
of article summarizing those approaches so that next devs wouldn't have to
reinvent the wheel but start with some tried approach and maybe improve it.
As I only scratched the surface learning Pharo, I may have some naive
questions.
Does the fact (fact?) that Pharo uses green threads (not native os threads)
impact the performance?
With two Pharo images running in parallel on two core system, how does it
handle multiple requests at a time? There must always be some unblocked
thread waiting for connections and delegating requests to request handlers
in different green threads (using fork operation). Is my understanding
correct?
So even if one of those threads has to wait on a long IO operation (say
from DB2) that shouldn't impact the performance of other handlers?
I think that in most cases the CPU time for request processing is minal as
the bottleneck is in lengthy IO operations , DB waits and calling external
REST-ful services. So two images on two cores should be enough to handle
hundreds of simultaneous requests since most of the times the threads will
wait on external operations, not using the local CPU.
Please let me know if this summary that I got from this thread makes sense.
Yes, I fully agree that using docker pharo containers under some load
balancing is the way to go.

On Wed, Jun 27, 2018, 04:10 jtuc...@objektfabrik.de 
wrote:

> Norbert,
>
>
> thanks for your insighgts, explanations and thoughts. It is good to read
> and learn from people who are a step or two ahead...
>
> Am 27.06.18 um 09:31 schrieb Norbert Hartl:
>
> Joachim,
>
> Am 27.06.2018 um 07:42 schrieb jtuc...@objektfabrik.de:
>
> Norbert,
>
> Am 26.06.18 um 21:41 schrieb Norbert Hartl:
>
>
>
> Am 26.06.2018 um 20:44 schrieb Andrei Stebakov :
>
> What would be an example for load balancer for Pharo images? Can we run
> multiple images on the same server or for the sake of balancing
> configuration we can only run one image per server?
>
> There are a lot of possibilities. You can start multiple images on
> different ports and use nginx with an upstream rule to load balance. I
> would recommend using docker for spawning multiple images on a host. Again
> with nginx as frontend load balancer. The point is that you can have at
> least twice as muh inages running then you have CPU cores. And of course a
> lot more.
>
>
> the last time I checked nginx, the load balancing and sticky session stuff
> was not available in the free edition. So I guess you either pay for nginx
> (which I think is good) or you know some free 3d party addons...
>
> there is the upstream module which provides load balancing. But you are
> right I think sticky sessions is not part of it. The closest you get IIRC
> is IP based hashing.
>
> I see.
>
>
> I wonder what exactly the benefit of Docker is in that game? On our
> servers we run 10 images on 4 cores with HT (8 virtual cores) and very
> rareley have real performance problems. We use Glorp, so there is a lot of
> SQL queriing going on for quite basic things already. So my guess would be
> that your "2 images per core"  are conservative and leave air for even a
> third one, depending on all the factors already discussed here.
>
>
> Docker is pretty nice. You can have the exact same deployment artefact
> started multiple times. I used tools like daemontools, monit, etc. before
> but starting the image, assigning ports etc. you have to do yourself which
> is cumbersome and I don’t like any of those tools anymore. If you created
> your docker image you can start that multiple times because networking is
> virtualized all images can have the same port serving e.g.
>
>
> oh, I see. This is a plus. We're not using any containers and have to
> provide individual configurations for each image we start up. Works well,
> not too many moving parts (our resources are very limited) and we try to
> keep things as simple as possible. As long as we can live with providing a
> statically sized pool of machines and images and load doesn't vary too
> much, this is not too bad. But once you need to dynamically add and remove
> images for coping with load peeks and lows, our approach will probably
> become cumbersome and complicated.
> OTOH, I guess usind Docker just means solving the same problems on another
> level - but I guess there are lots of toosl in the Container area that can
> help here (like the trafik thing mentioned in another thread).
>
>
> I think talking about performance these days is not easy. Modern machines
> are so fast that you need a lot of users before you experience any
> problems.
>
> ... depending on your usage of resources. As I said, we're using SQL
> heavily because of the way Glorp works. So it is easy to introduce
> bottlenecks even for smaller jobs.
>
> The mention of „2 images per core“ I need to explain. A CPU core can
> execute only one thing at a time. Therefor 1 image per core would be
> enough. The second one is for that t

Re: [Pharo-users] pharo bash script with startup

[Otto Behrens]

Thanks, but it does not. I give a full path for both the image and the
startup files. It must have something to do with the stuff packaged in the
zip file.



On Wed, Jun 27, 2018 at 9:59 AM, Norbert Hartl  wrote:

>
>
> Am 27.06.2018 um 09:38 schrieb Otto Behrens :
>
> I am running with an absolute image path.
>
> The issue is definitely exec "$image" in the script. If I remove the "",
> i.e. exec $image, then it works.
>
> /opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image
> startup.st"
>
> Does just giving a path still work. I use the commandline option
>
> vm pharo.image *st* path/to/script.st
>
> Norbert
>
> gives me the same problem
>
> On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri  wrote:
>
>> Try with ./pharo or try with an absolute image path.
>>
>> On Wed, Jun 27, 2018, 04:03 Tim Mackinnon  wrote:
>>
>>> I’ve not noticed that problem on ubuntu or AWS lambda so there must be
>>> something different going on.
>>>
>>> Sent from my iPhone
>>>
>>> On 27 Jun 2018, at 07:30, Otto Behrens  wrote:
>>>
>>> Hi,
>>>
>>> I just installed pharo 6.1 using the .zip file (
>>> http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to
>>> start up pharo with arguments.
>>>
>>> The issue is that the pharo bash script (in the extracted home dir)
>>> quotes all arguments:
>>>
>>> # execute
>>> exec "$LINUX/pharo" \
>>> --plugins "$LINUX" \
>>> --encoding utf8 \
>>> -vm-display-X11 \
>>> "$image"
>>>
>>> where
>>>
>>> image = $*
>>>
>>> The impact is that if I want to run a startup script, eg.
>>>
>>> pharo my.image startup.st
>>>
>>> pharo complains with "Could not open the Pharo image file: 'my.image
>>> startup.st'
>>>
>>> So I must run the executable directly?
>>>
>>> If so, some questions about the options that the bash script passes in:
>>> --plugins "$LINUX"is this necessary? will the default not be enough?
>>> --encoding utf8  the usage output says for example --textenc
>>> default is "UTF-8". Is utf8 the same thing?
>>> -vm-display-X11I tried starting without this, and it worked. Do
>>> I need to explicitly start with this?
>>>
>>> Thanks
>>> Otto
>>>
>>>
>
>

Re: [Pharo-users] Microservices using Pharo

[jtuc...@objektfabrik.de]

Norbert,


thanks for your insighgts, explanations and thoughts. It is good to read 
and learn from people who are a step or two ahead...


Am 27.06.18 um 09:31 schrieb Norbert Hartl:

Joachim,

Am 27.06.2018 um 07:42 schrieb jtuc...@objektfabrik.de 
:


Norbert,

Am 26.06.18 um 21:41 schrieb Norbert Hartl:



Am 26.06.2018 um 20:44 schrieb Andrei Stebakov >:


What would be an example for load balancer for Pharo images? Can we 
run multiple images on the same server or for the sake of balancing 
configuration we can only run one image per server?


There are a lot of possibilities. You can start multiple images on 
different ports and use nginx with an upstream rule to load balance. 
I would recommend using docker for spawning multiple images on a 
host. Again with nginx as frontend load balancer. The point is that 
you can have at least twice as muh inages running then you have CPU 
cores. And of course a lot more.




the last time I checked nginx, the load balancing and sticky session 
stuff was not available in the free edition. So I guess you either 
pay for nginx (which I think is good) or you know some free 3d party 
addons...


there is the upstream module which provides load balancing. But you 
are right I think sticky sessions is not part of it. The closest you 
get IIRC is IP based hashing.

I see.



I wonder what exactly the benefit of Docker is in that game? On our 
servers we run 10 images on 4 cores with HT (8 virtual cores) and 
very rareley have real performance problems. We use Glorp, so there 
is a lot of SQL queriing going on for quite basic things already. So 
my guess would be that your "2 images per core"  are conservative and 
leave air for even a third one, depending on all the factors already 
discussed here.
Docker is pretty nice. You can have the exact same deployment artefact 
started multiple times. I used tools like daemontools, monit, etc. 
before but starting the image, assigning ports etc. you have to do 
yourself which is cumbersome and I don’t like any of those tools 
anymore. If you created your docker image you can start that multiple 
times because networking is virtualized all images can have the same 
port serving e.g.


oh, I see. This is a plus. We're not using any containers and have to 
provide individual configurations for each image we start up. Works 
well, not too many moving parts (our resources are very limited) and we 
try to keep things as simple as possible. As long as we can live with 
providing a statically sized pool of machines and images and load 
doesn't vary too much, this is not too bad. But once you need to 
dynamically add and remove images for coping with load peeks and lows, 
our approach will probably become cumbersome and complicated.
OTOH, I guess usind Docker just means solving the same problems on 
another level - but I guess there are lots of toosl in the Container 
area that can help here (like the trafik thing mentioned in another thread).




I think talking about performance these days is not easy. Modern 
machines are so fast that you need a lot of users before you 
experience any problems.
... depending on your usage of resources. As I said, we're using SQL 
heavily because of the way Glorp works. So it is easy to introduce 
bottlenecks even for smaller jobs.
The mention of „2 images per core“ I need to explain. A CPU core can 
execute only one thing at a time. Therefor 1 image per core would be 
enough. The second one is for that time slices where there are gaps in 
processing meaning the process is suspended, switched etc. It is just 
the rule of thumb that it is good to have one process waiting in the 
scheduling queue so it can step in as soon as there is free cycles. 
The „2 images per core“ have the assumption that you can put an 
arbitrary load on one image. So with this assumption a third image 
won’t give you anything because it cannot do anything the other two 
images cannot do.
So according to the „hard“ facts it does not help having more than two 
images. On the other hand each image is single threaded and using more 
images lowers the probability that processes get blocked because they 
are executed within one image. On yet another hand if you use a 
database a lot of the time for a process is waiting for the response 
of the database so other processes can be executed. And and and…. So 
in the end you have to try it.


You are correct. The third image con anly jump in if both the others are 
in a wait state. It "feels" as if there was enough air for a third one 
to operate, but we'd have to try if that holds true.




What's not to underestimate is all the stuff around monitoring and 
restarting images when things go wrong, but that's another story...


Docker has a restart policy so restarting shouldn’t be an issue with 
it. Monitoring is always hard. I use prometheus with grafana but that 
is quite a bit to set up. But in the end you get graphs and you

Re: [Pharo-users] pharo bash script with startup

[Otto Behrens]

I extracted the file that I downloaded again and checked. The file (
http://files.pharo.org/platform/Pharo6.1-64-linux.zip) seems to have an old
VM zipped:

/opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955

What I get with

wget -O - https://get.pharo.org/64/61+vm | bash

is:

pharo-vm/lib/pharo/5.0-201805090836



On Wed, Jun 27, 2018 at 9:45 AM, Guillermo Polito  wrote:

> That's strange, is this a new problem or you always had it?
>
> I've just tested it, pharo 61 64 bits.
>
>  $ wget -O - https://get.pharo.org/64/61+vm | bash
> [SNIP]
> $ ./pharo Pharo.image eval 1+1
> 2
>
> Maybe the so called starter scripts (pharo, pharo-ui) are not the same
> using zeroconf and by downloading a plain vm like that?
>
> On Wed, Jun 27, 2018 at 9:38 AM Otto Behrens  wrote:
>
>> I am running with an absolute image path.
>>
>> The issue is definitely exec "$image" in the script. If I remove the "",
>> i.e. exec $image, then it works.
>>
>> /opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image
>> startup.st"
>>
>> gives me the same problem
>>
>> On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri 
>> wrote:
>>
>>> Try with ./pharo or try with an absolute image path.
>>>
>>> On Wed, Jun 27, 2018, 04:03 Tim Mackinnon  wrote:
>>>
 I’ve not noticed that problem on ubuntu or AWS lambda so there must be
 something different going on.

 Sent from my iPhone

 On 27 Jun 2018, at 07:30, Otto Behrens  wrote:

 Hi,

 I just installed pharo 6.1 using the .zip file (http://files.pharo.org/
 platform/Pharo6.1-64-linux.zip) and battled to start up pharo with
 arguments.

 The issue is that the pharo bash script (in the extracted home dir)
 quotes all arguments:

 # execute
 exec "$LINUX/pharo" \
 --plugins "$LINUX" \
 --encoding utf8 \
 -vm-display-X11 \
 "$image"

 where

 image = $*

 The impact is that if I want to run a startup script, eg.

 pharo my.image startup.st

 pharo complains with "Could not open the Pharo image file: 'my.image
 startup.st'

 So I must run the executable directly?

 If so, some questions about the options that the bash script passes in:
 --plugins "$LINUX"is this necessary? will the default not be enough?
 --encoding utf8  the usage output says for example --textenc
 default is "UTF-8". Is utf8 the same thing?
 -vm-display-X11I tried starting without this, and it worked. Do
 I need to explicitly start with this?

 Thanks
 Otto


>>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>

Re: [Pharo-users] pharo bash script with startup

[Norbert Hartl]

> Am 27.06.2018 um 09:38 schrieb Otto Behrens :
> 
> I am running with an absolute image path. 
> 
> The issue is definitely exec "$image" in the script. If I remove the "", i.e. 
> exec $image, then it works. 
> 
> /opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image 
> startup.st "
> 
Does just giving a path still work. I use the commandline option

vm pharo.image st path/to/script.st 

Norbert

> gives me the same problem
> 
> On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri  > wrote:
> Try with ./pharo or try with an absolute image path.
> 
> On Wed, Jun 27, 2018, 04:03 Tim Mackinnon  wrote:
> I’ve not noticed that problem on ubuntu or AWS lambda so there must be 
> something different going on.
> 
> Sent from my iPhone
> 
> On 27 Jun 2018, at 07:30, Otto Behrens  > wrote:
> 
>> Hi,
>> 
>> I just installed pharo 6.1 using the .zip file 
>> (http://files.pharo.org/platform/Pharo6.1-64-linux.zip 
>> ) and battled to 
>> start up pharo with arguments.
>> 
>> The issue is that the pharo bash script (in the extracted home dir) quotes 
>> all arguments:
>> 
>> # execute
>> exec "$LINUX/pharo" \
>> --plugins "$LINUX" \
>> --encoding utf8 \
>> -vm-display-X11 \
>> "$image"
>> 
>> where
>> 
>> image = $*
>> 
>> The impact is that if I want to run a startup script, eg.
>> 
>> pharo my.image startup.st 
>> 
>> pharo complains with "Could not open the Pharo image file: 'my.image 
>> startup.st '
>> 
>> So I must run the executable directly?
>> 
>> If so, some questions about the options that the bash script passes in:
>> --plugins "$LINUX"is this necessary? will the default not be enough?
>> --encoding utf8  the usage output says for example --textenc default 
>> is "UTF-8". Is utf8 the same thing?
>> -vm-display-X11I tried starting without this, and it worked. Do I 
>> need to explicitly start with this?
>> 
>> Thanks
>> Otto
> 

Re: [Pharo-users] pharo bash script with startup

[Guillermo Polito]

That's strange, is this a new problem or you always had it?

I've just tested it, pharo 61 64 bits.

 $ wget -O - https://get.pharo.org/64/61+vm | bash
[SNIP]
$ ./pharo Pharo.image eval 1+1
2

Maybe the so called starter scripts (pharo, pharo-ui) are not the same
using zeroconf and by downloading a plain vm like that?

On Wed, Jun 27, 2018 at 9:38 AM Otto Behrens  wrote:

> I am running with an absolute image path.
>
> The issue is definitely exec "$image" in the script. If I remove the "",
> i.e. exec $image, then it works.
>
> /opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image
> startup.st"
>
> gives me the same problem
>
> On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri  wrote:
>
>> Try with ./pharo or try with an absolute image path.
>>
>> On Wed, Jun 27, 2018, 04:03 Tim Mackinnon  wrote:
>>
>>> I’ve not noticed that problem on ubuntu or AWS lambda so there must be
>>> something different going on.
>>>
>>> Sent from my iPhone
>>>
>>> On 27 Jun 2018, at 07:30, Otto Behrens  wrote:
>>>
>>> Hi,
>>>
>>> I just installed pharo 6.1 using the .zip file (
>>> http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to
>>> start up pharo with arguments.
>>>
>>> The issue is that the pharo bash script (in the extracted home dir)
>>> quotes all arguments:
>>>
>>> # execute
>>> exec "$LINUX/pharo" \
>>> --plugins "$LINUX" \
>>> --encoding utf8 \
>>> -vm-display-X11 \
>>> "$image"
>>>
>>> where
>>>
>>> image = $*
>>>
>>> The impact is that if I want to run a startup script, eg.
>>>
>>> pharo my.image startup.st
>>>
>>> pharo complains with "Could not open the Pharo image file: 'my.image
>>> startup.st'
>>>
>>> So I must run the executable directly?
>>>
>>> If so, some questions about the options that the bash script passes in:
>>> --plugins "$LINUX"is this necessary? will the default not be enough?
>>> --encoding utf8  the usage output says for example --textenc
>>> default is "UTF-8". Is utf8 the same thing?
>>> -vm-display-X11I tried starting without this, and it worked. Do
>>> I need to explicitly start with this?
>>>
>>> Thanks
>>> Otto
>>>
>>>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] pharo bash script with startup

[Otto Behrens]

I am running with an absolute image path.

The issue is definitely exec "$image" in the script. If I remove the "",
i.e. exec $image, then it works.

/opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image
startup.st"

gives me the same problem

On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri  wrote:

> Try with ./pharo or try with an absolute image path.
>
> On Wed, Jun 27, 2018, 04:03 Tim Mackinnon  wrote:
>
>> I’ve not noticed that problem on ubuntu or AWS lambda so there must be
>> something different going on.
>>
>> Sent from my iPhone
>>
>> On 27 Jun 2018, at 07:30, Otto Behrens  wrote:
>>
>> Hi,
>>
>> I just installed pharo 6.1 using the .zip file (http://files.pharo.org/
>> platform/Pharo6.1-64-linux.zip) and battled to start up pharo with
>> arguments.
>>
>> The issue is that the pharo bash script (in the extracted home dir)
>> quotes all arguments:
>>
>> # execute
>> exec "$LINUX/pharo" \
>> --plugins "$LINUX" \
>> --encoding utf8 \
>> -vm-display-X11 \
>> "$image"
>>
>> where
>>
>> image = $*
>>
>> The impact is that if I want to run a startup script, eg.
>>
>> pharo my.image startup.st
>>
>> pharo complains with "Could not open the Pharo image file: 'my.image
>> startup.st'
>>
>> So I must run the executable directly?
>>
>> If so, some questions about the options that the bash script passes in:
>> --plugins "$LINUX"is this necessary? will the default not be enough?
>> --encoding utf8  the usage output says for example --textenc
>> default is "UTF-8". Is utf8 the same thing?
>> -vm-display-X11I tried starting without this, and it worked. Do I
>> need to explicitly start with this?
>>
>> Thanks
>> Otto
>>
>>

Re: [Pharo-users] Microservices using Pharo

[Norbert Hartl]

Joachim,

> Am 27.06.2018 um 07:42 schrieb jtuc...@objektfabrik.de:
> 
> Norbert,
> 
> Am 26.06.18 um 21:41 schrieb Norbert Hartl:
>> 
>> 
>> Am 26.06.2018 um 20:44 schrieb Andrei Stebakov > >:
>> 
>>> What would be an example for load balancer for Pharo images? Can we run 
>>> multiple images on the same server or for the sake of balancing 
>>> configuration we can only run one image per server?
>>> 
>> There are a lot of possibilities. You can start multiple images on different 
>> ports and use nginx with an upstream rule to load balance. I would recommend 
>> using docker for spawning multiple images on a host. Again with nginx as 
>> frontend load balancer. The point is that you can have at least twice as muh 
>> inages running then you have CPU cores. And of course a lot more.
>> 
> 
> the last time I checked nginx, the load balancing and sticky session stuff 
> was not available in the free edition. So I guess you either pay for nginx 
> (which I think is good) or you know some free 3d party addons...
> 
there is the upstream module which provides load balancing. But you are right I 
think sticky sessions is not part of it. The closest you get IIRC is IP based 
hashing.

> I wonder what exactly the benefit of Docker is in that game? On our servers 
> we run 10 images on 4 cores with HT (8 virtual cores) and very rareley have 
> real performance problems. We use Glorp, so there is a lot of SQL queriing 
> going on for quite basic things already. So my guess would be that your "2 
> images per core"  are conservative and leave air for even a third one, 
> depending on all the factors already discussed here.
>  
Docker is pretty nice. You can have the exact same deployment artefact started 
multiple times. I used tools like daemontools, monit, etc. before but starting 
the image, assigning ports etc. you have to do yourself which is cumbersome and 
I don’t like any of those tools anymore. If you created your docker image you 
can start that multiple times because networking is virtualized all images can 
have the same port serving e.g.

I think talking about performance these days is not easy. Modern machines are 
so fast that you need a lot of users before you experience any problems. The 
mention of „2 images per core“ I need to explain. A CPU core can execute only 
one thing at a time. Therefor 1 image per core would be enough. The second one 
is for that time slices where there are gaps in processing meaning the process 
is suspended, switched etc. It is just the rule of thumb that it is good to 
have one process waiting in the scheduling queue so it can step in as soon as 
there is free cycles. The „2 images per core“ have the assumption that you can 
put an arbitrary load on one image. So with this assumption a third image won’t 
give you anything because it cannot do anything the other two images cannot do.
So according to the „hard“ facts it does not help having more than two images. 
On the other hand each image is single threaded and using more images lowers 
the probability that processes get blocked because they are executed within one 
image. On yet another hand if you use a database a lot of the time for a 
process is waiting for the response of the database so other processes can be 
executed. And and and…. So in the end you have to try it. 

> What's not to underestimate is all the stuff around monitoring and restarting 
> images when things go wrong, but that's another story...
> 
Docker has a restart policy so restarting shouldn’t be an issue with it. 
Monitoring is always hard. I use prometheus with grafana but that is quite a 
bit to set up. But in the end you get graphs and you can define alerts for 
system value thresholds. 
If the topic gets accepted Marcus and me will tell about these things at ESUG. 

 
Norbert
> Joachim
> 
>  
> -- 
> ---
> Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de 
> 
> Fliederweg 1 http://www.objektfabrik.de 
> 
> D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com 
> 
> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
> 

Re: [Pharo-users] pharo bash script with startup

[Julián Maestri]

Try with ./pharo or try with an absolute image path.

On Wed, Jun 27, 2018, 04:03 Tim Mackinnon  wrote:

> I’ve not noticed that problem on ubuntu or AWS lambda so there must be
> something different going on.
>
> Sent from my iPhone
>
> On 27 Jun 2018, at 07:30, Otto Behrens  wrote:
>
> Hi,
>
> I just installed pharo 6.1 using the .zip file (
> http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to
> start up pharo with arguments.
>
> The issue is that the pharo bash script (in the extracted home dir) quotes
> all arguments:
>
> # execute
> exec "$LINUX/pharo" \
> --plugins "$LINUX" \
> --encoding utf8 \
> -vm-display-X11 \
> "$image"
>
> where
>
> image = $*
>
> The impact is that if I want to run a startup script, eg.
>
> pharo my.image startup.st
>
> pharo complains with "Could not open the Pharo image file: 'my.image
> startup.st'
>
> So I must run the executable directly?
>
> If so, some questions about the options that the bash script passes in:
> --plugins "$LINUX"is this necessary? will the default not be enough?
> --encoding utf8  the usage output says for example --textenc
> default is "UTF-8". Is utf8 the same thing?
> -vm-display-X11I tried starting without this, and it worked. Do I
> need to explicitly start with this?
>
> Thanks
> Otto
>
>

Re: [Pharo-users] pharo bash script with startup

[Tim Mackinnon]

I’ve not noticed that problem on ubuntu or AWS lambda so there must be 
something different going on.

Sent from my iPhone

> On 27 Jun 2018, at 07:30, Otto Behrens  wrote:
> 
> Hi,
> 
> I just installed pharo 6.1 using the .zip file 
> (http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to start 
> up pharo with arguments.
> 
> The issue is that the pharo bash script (in the extracted home dir) quotes 
> all arguments:
> 
> # execute
> exec "$LINUX/pharo" \
> --plugins "$LINUX" \
> --encoding utf8 \
> -vm-display-X11 \
> "$image"
> 
> where
> 
> image = $*
> 
> The impact is that if I want to run a startup script, eg.
> 
> pharo my.image startup.st
> 
> pharo complains with "Could not open the Pharo image file: 'my.image 
> startup.st'
> 
> So I must run the executable directly?
> 
> If so, some questions about the options that the bash script passes in:
> --plugins "$LINUX"is this necessary? will the default not be enough?
> --encoding utf8  the usage output says for example --textenc default 
> is "UTF-8". Is utf8 the same thing?
> -vm-display-X11I tried starting without this, and it worked. Do I 
> need to explicitly start with this?
> 
> Thanks
> Otto