Smalltalk › Pharo › Pharo Smalltalk Users

Running a teapot instance remotely

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

sergio_101

Running a teapot instance remotely

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

@[hidden email]

https://sergio101.com
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc (849 bytes) Download Attachment

Tim Mackinnon

Re: Running a teapot instance remotely

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

"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 <[hidden email]> 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
@[hidden email]
https://sergio101.com
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

sergio_101

Re: Running a teapot instance remotely

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 <[hidden email]> 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

@[hidden email]

https://sergio101.com
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc (849 bytes) Download Attachment

Paul DeBruicker

Re: Running a teapot instance remotely

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)
> <http://forum.world.st/attachment/5105321/0/signature.asc>

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

Pierce Ng-3

Re: Running a teapot instance remotely

In reply to this post by sergio_101

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

vince

Re: Running a teapot instance remotely

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:[hidden email]] On Behalf Of Pierce Ng
Sent: Friday, 11 October 2019 12:39 PM
To: Any question about pharo is welcome <[hidden email]>
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

jtuchel

Re: Running a teapot instance remotely

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:[hidden email]] On Behalf Of Pierce Ng
> Sent: Friday, 11 October 2019 12:39 PM
> To: Any question about pharo is welcome <[hidden email]>
> 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:[hidden email]
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

Tim Mackinnon

Re: Running a teapot instance remotely

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, "[hidden email]" <[hidden email]> 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:[hidden email]] On Behalf Of Pierce Ng
>> Sent: Friday, 11 October 2019 12:39 PM
>> To: Any question about pharo is welcome <[hidden email]>
>> 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:[hidden email]
> 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
>
>
>

Sean P. DeNigris

Re: Running a teapot instance remotely

Administrator

In reply to this post by jtuchel

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

Cheers,
Sean

jtuchel

Re: Running a teapot instance remotely

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" <[hidden email]> 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

vince

Re: Running a teapot instance remotely

In reply to this post by jtuchel

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:[hidden email]] On Behalf Of [hidden email]
Sent: Friday, 11 October 2019 4:09 PM
To: [hidden email]
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:[hidden email]] On
> Behalf Of Pierce Ng
> Sent: Friday, 11 October 2019 12:39 PM
> To: Any question about pharo is welcome <[hidden email]>
> 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:[hidden email]
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