Re: [Pharo-users] Running a teapot instance remotely

[Vince Refiti]

Hi Joachim

I see. I have submitted a pull request to change the wording to reflect the 
real situation.

By the way I work professionally on a 20 year old VA Smalltalk app that we just 
upgraded from 6 to 9. That thing is solid as a rock and only walksback with bad 
code. Nothing ever else goes wrong.

Vince

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
jtuc...@objektfabrik.de
Sent: Friday, 11 October 2019 4:09 PM
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Running a teapot instance remotely

EXTERNAL: Do not click links or open attachments if you do not recognize the 
sender.

Vince,

I guess this has its roots in long-ongoing discussions about the anticipated 
disadvantages of image-based development in general. It tries to explain that 
Smalltalk has mechanisms for recovering code after an image crashes. It is not 
indicating that images do actually crash more often than other development 
environments. It is more a remark about the fact that of course even Smalltalk 
can crash and that there is a mechanism (namely the changes file and changes 
browsers) for restoring your code after a crash, even if you didn't file-out 
your code or didn't push it to an external repository. Nothing more, nothing 
less.

So please don't read this as: "Since Pharo/Smalltalk isn't stable, we had to 
xyz" - this is not the case. I've been using Smalltalk (mostly not Pharo) for 
more than 25 years and I can only remember having a need to recover source code 
maybe a hand full of times. In my favorite Smalltalk (VA Smalltalk), I am 
almost 100% sure I never had this issue because Envy is exactly the measure 
that is mentioned in the sentence you cited.

Joachim

Am 11.10.19 um 07:39 schrieb Vince Refiti:
> Hi
>
> This brings up some questions I have been meaning to ask for some time. The 
> sentence "When the Pharo image crashes (which will happen), there must be a 
> way to automatically recover from this crash." appears in the Enterprise 
> Pharo Book.
>
> Does this claim still apply? Is Pharo that unstable still?
>
> If it is, what are the major causes in your own applications that crash it? I 
> have run a few small, local, experimental Teapot, Seaside and other Pharo 
> server apps and nothing crashed, but reading something like that makes me 
> nervous about public-facing server apps in Pharo.
>
> Vince
>
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On 
> Behalf Of Pierce Ng
> Sent: Friday, 11 October 2019 12:39 PM
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] Running a teapot instance remotely
>
> EXTERNAL: Do not click links or open attachments if you do not recognize the 
> sender.
>
> On Thu, Oct 10, 2019 at 04:18:14PM -0400, sergio ruiz wrote:
>> How are people keeping it running these days?
> I used to use daemontools. These days I use Docker.
>
> Pierce
>

--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 
https://urldefense.com/v3/__http://www.objektfabrik.de__;!09EJrJkydGw!T9iwyNs37EekSPqfOmRtg4DpnjEcw9FV-Jzjbc59Tl-koQTH29rq-sj7txDgv-AzwGmoSvo25w$
 
D-71640 Ludwigsburg  
https://urldefense.com/v3/__http://joachimtuchel.wordpress.com__;!09EJrJkydGw!T9iwyNs37EekSPqfOmRtg4DpnjEcw9FV-Jzjbc59Tl-koQTH29rq-sj7txDgv-AzwGkxDIrO4Q$
 
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Running a teapot instance remotely

[Joachim Tuchel]

Sean,

good point about dev vs. prod. Thanks for adding.

I was indeed talking about development images. There is no loss of code in a 
runtime image, because you usually don't ship the "original" devleopment 
image... Of course, chances are a production image crashes when you ship bugs, 
but it' won't loose code.

Joacim

> "Sean P. DeNigris" mailto:s...@clipperadams.com > hat 
> am 11. Oktober 2019 um 20:07 geschrieben:
> 
> 
> jtuchel wrote
> 
> > > I guess this has its roots in long-ongoing discussions about the
> > anticipated disadvantages of image-based development in general.
> > 
> > > I would also add that IMHO a lot of (or maybe almost all) the 
> > angst of
> possible image crashes comes during development (with increasing risks as
> experiments get more exotic or delve deeper into the kernel), not
> deployment. Crashing may be less of an issue now for professional use 
> since
> there is a development/deployment distinction, unlike historically and in 
> a
> pure Dynabook vision where all users are developers.
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] Running a teapot instance remotely

[Sean P. DeNigris]

jtuchel wrote
> I guess this has its roots in long-ongoing discussions about the 
> anticipated disadvantages of image-based development in general.

I would also add that IMHO a lot of (or maybe almost all) the angst of
possible image crashes comes during development (with increasing risks as
experiments get more exotic or delve deeper into the kernel), not
deployment. Crashing may be less of an issue now for professional use since
there is a development/deployment distinction, unlike historically and in a
pure Dynabook vision where all users are developers.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Running a teapot instance remotely

[Tim Mackinnon]

If your question is aimed more at deploying on a server - it’s standard 
practice for applications (java, python, ruby etc) to have a watcher that will 
restart your app if it terminates/crashes - Pharo is no different. This 
mechanism serves well If a C primitive fails, or your server terminates it for 
some reason - and the watcher (or even a bash loop), will just restart it.

These days however, others have pointed out that we’re moving into a Docker 
world where that bit is taken care of with that infrastructure (I think you 
need an endpoint to monitor your app with, and which reminds me to revisit this 
with Pharo as the costs have come down I think). Still, monit or equivalent on 
an Ocean server is $5/m which is darn good value. (You can probably run several 
small apps with that too).

Tim

Sent from my iPhone



Sent from my iPhone
> On 11 Oct 2019, at 07:08, "jtuc...@objektfabrik.de"  
> wrote:
> 
> Vince,
> 
> I guess this has its roots in long-ongoing discussions about the anticipated 
> disadvantages of image-based development in general. It tries to explain that 
> Smalltalk has mechanisms for recovering code after an image crashes. It is 
> not indicating that images do actually crash more often than other 
> development environments. It is more a remark about the fact that of course 
> even Smalltalk can crash and that there is a mechanism (namely the changes 
> file and changes browsers) for restoring your code after a crash, even if you 
> didn't file-out your code or didn't push it to an external repository. 
> Nothing more, nothing less.
> 
> So please don't read this as: "Since Pharo/Smalltalk isn't stable, we had to 
> xyz" - this is not the case. I've been using Smalltalk (mostly not Pharo) for 
> more than 25 years and I can only remember having a need to recover source 
> code maybe a hand full of times. In my favorite Smalltalk (VA Smalltalk), I 
> am almost 100% sure I never had this issue because Envy is exactly the 
> measure that is mentioned in the sentence you cited.
> 
> Joachim
> 
>> Am 11.10.19 um 07:39 schrieb Vince Refiti:
>> Hi
>> 
>> This brings up some questions I have been meaning to ask for some time. The 
>> sentence "When the Pharo image crashes (which will happen), there must be a 
>> way to automatically recover from this crash." appears in the Enterprise 
>> Pharo Book.
>> 
>> Does this claim still apply? Is Pharo that unstable still?
>> 
>> If it is, what are the major causes in your own applications that crash it? 
>> I have run a few small, local, experimental Teapot, Seaside and other Pharo 
>> server apps and nothing crashed, but reading something like that makes me 
>> nervous about public-facing server apps in Pharo.
>> 
>> Vince
>> 
>> -Original Message-
>> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
>> Pierce Ng
>> Sent: Friday, 11 October 2019 12:39 PM
>> To: Any question about pharo is welcome 
>> Subject: Re: [Pharo-users] Running a teapot instance remotely
>> 
>> EXTERNAL: Do not click links or open attachments if you do not recognize the 
>> sender.
>> 
>>> On Thu, Oct 10, 2019 at 04:18:14PM -0400, sergio ruiz wrote:
>>> How are people keeping it running these days?
>> I used to use daemontools. These days I use Docker.
>> 
>> Pierce
> 
> -- 
> ---
> 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] Running a teapot instance remotely

[jtuc...@objektfabrik.de]

Vince,

I guess this has its roots in long-ongoing discussions about the 
anticipated disadvantages of image-based development in general. It 
tries to explain that Smalltalk has mechanisms for recovering code after 
an image crashes. It is not indicating that images do actually crash 
more often than other development environments. It is more a remark 
about the fact that of course even Smalltalk can crash and that there is 
a mechanism (namely the changes file and changes browsers) for restoring 
your code after a crash, even if you didn't file-out your code or didn't 
push it to an external repository. Nothing more, nothing less.


So please don't read this as: "Since Pharo/Smalltalk isn't stable, we 
had to xyz" - this is not the case. I've been using Smalltalk (mostly 
not Pharo) for more than 25 years and I can only remember having a need 
to recover source code maybe a hand full of times. In my favorite 
Smalltalk (VA Smalltalk), I am almost 100% sure I never had this issue 
because Envy is exactly the measure that is mentioned in the sentence 
you cited.


Joachim

Am 11.10.19 um 07:39 schrieb Vince Refiti:

Hi

This brings up some questions I have been meaning to ask for some time. The sentence 
"When the Pharo image crashes (which will happen), there must be a way to 
automatically recover from this crash." appears in the Enterprise Pharo Book.

Does this claim still apply? Is Pharo that unstable still?

If it is, what are the major causes in your own applications that crash it? I 
have run a few small, local, experimental Teapot, Seaside and other Pharo 
server apps and nothing crashed, but reading something like that makes me 
nervous about public-facing server apps in Pharo.

Vince

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Pierce Ng
Sent: Friday, 11 October 2019 12:39 PM
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Running a teapot instance remotely

EXTERNAL: Do not click links or open attachments if you do not recognize the 
sender.

On Thu, Oct 10, 2019 at 04:18:14PM -0400, sergio ruiz wrote:

How are people keeping it running these days?

I used to use daemontools. These days I use Docker.

Pierce



--
---
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] Running a teapot instance remotely

[Vince Refiti]

Hi

This brings up some questions I have been meaning to ask for some time. The 
sentence "When the Pharo image crashes (which will happen), there must be a way 
to automatically recover from this crash." appears in the Enterprise Pharo 
Book. 

Does this claim still apply? Is Pharo that unstable still?

If it is, what are the major causes in your own applications that crash it? I 
have run a few small, local, experimental Teapot, Seaside and other Pharo 
server apps and nothing crashed, but reading something like that makes me 
nervous about public-facing server apps in Pharo.

Vince

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Pierce Ng
Sent: Friday, 11 October 2019 12:39 PM
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Running a teapot instance remotely

EXTERNAL: Do not click links or open attachments if you do not recognize the 
sender.

On Thu, Oct 10, 2019 at 04:18:14PM -0400, sergio ruiz wrote:
> How are people keeping it running these days?

I used to use daemontools. These days I use Docker.

Pierce

Re: [Pharo-users] Running a teapot instance remotely

[Pierce Ng]

On Thu, Oct 10, 2019 at 04:18:14PM -0400, sergio ruiz wrote:
> How are people keeping it running these days?

I used to use daemontools. These days I use Docker.

Pierce

Re: [Pharo-users] Running a teapot instance remotely

[Paul DeBruicker]

I use daemontools. Some people use Monit.

Sven made these for Pharo4 on Ubuntu 14.04 when Pharo was only 32 bit:

https://github.com/svenvc/pharo-server-tools

I'm sure you could edit those scripts to work for 64bit Pharo 7/8 on 64 bit
linux



And there is this chapter about deploying apps to production

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/DeploymentWeb/DeployForProduction.html



sergio_101 wrote
> This worked perfectly!
> 
> To keep this running, I am running it in tux, so it will keep running when
> I log out.
> 
> How are people keeping it running these days?
> 
> Thanks!
> 
> 
>> On Oct 10, 2019, at 3:46 PM, Tim Mackinnon <

> tim@

> > wrote:
>> 
>> Sergio - looking at the last time I did this, my run script did:
>> 
>> 
>> 
>> 
> 
> 
> peace,
> sergio
> photographer, journalist, visionary
> 
> Public Key: http://bit.ly/29z9fG0
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> @

> sergio_101@

> https://sergio101.com
> http://www.codeandmusic.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
> 
> 
> 
> signature.asc (849 bytes)
> ;





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Running a teapot instance remotely

[sergio ruiz]

This worked perfectly!

To keep this running, I am running it in tux, so it will keep running when I 
log out.

How are people keeping it running these days?

Thanks!


> On Oct 10, 2019, at 3:46 PM, Tim Mackinnon  wrote:
> 
> Sergio - looking at the last time I did this, my run script did:
> 
> 
> 
> 


peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
@sergio_101@mastodon.social
https://sergio101.com
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101



signature.asc
Description: Message signed with OpenPGP

Re: [Pharo-users] Running a teapot instance remotely

[Tim Mackinnon]

Sergio - looking at the last time I did this, my run script did:




pharo /home/app/PagerDuty/PagerDuty.image --no-default-preferences run.st


This was using sysctrl (from memory - but this line was what was run.)

The run.st was

1
2
3
4
5
6
7
"Simple application run script"
Transcript cr; cr; nextPutAll: 'Resetting server...'.
WPPagerDutyApp startForProduction: 8080.
Transcript cr; nextPutAll: 'Complete.'.


If you want to see my build script and deploy pipeline it’s in this simple 
project:

https://gitlab.com/macta/WillowPagerDuty/blob/master/scripts/run.st


Tim

Sent from my iPhone

> On 10 Oct 2019, at 19:46, sergio ruiz  wrote:
> 
> Hi, all.
> 
> I am running my teapot instance remotely, but I’m not sure how to start it up.
> 
> Just for testing, I am trying this:
> 
> ./pharo LunchPicker.image eval "server := PickerServer serveOn: 3200. server 
> start” &
> 
> But no luck.
> 
> ideas?
> 
> Thanks!
> 
> 
> 
> peace,
> sergio
> photographer, journalist, visionary
> 
> Public Key: http://bit.ly/29z9fG0
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> @sergio_101@mastodon.social
> https://sergio101.com
> http://www.codeandmusic.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
> 

[Pharo-users] Running a teapot instance remotely

[sergio ruiz]

Hi, all.

I am running my teapot instance remotely, but I’m not sure how to start it up.

Just for testing, I am trying this:

./pharo LunchPicker.image eval "server := PickerServer serveOn: 3200. server 
start” &

But no luck.

ideas?

Thanks!



peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
@sergio_101@mastodon.social
https://sergio101.com
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101



signature.asc
Description: Message signed with OpenPGP