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
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 <sergio.rrd@gmail.com> 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
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@testit.works> 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
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/lastSuccessfu... 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
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-bounces@lists.pharo.org] On Behalf Of Pierce Ng Sent: Friday, 11 October 2019 12:39 PM To: Any question about pharo is welcome <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. 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, 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-bounces@lists.pharo.org] On Behalf Of Pierce Ng Sent: Friday, 11 October 2019 12:39 PM To: Any question about pharo is welcome <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.
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:jtuchel@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
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, "jtuchel@objektfabrik.de" <jtuchel@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-bounces@lists.pharo.org] On Behalf Of Pierce Ng Sent: Friday, 11 October 2019 12:39 PM To: Any question about pharo is welcome <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.
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:jtuchel@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
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
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" <sean@clipperadams.com mailto:sean@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
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-bounces@lists.pharo.org] On Behalf Of jtuchel@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-bounces@lists.pharo.org] On Behalf Of Pierce Ng Sent: Friday, 11 October 2019 12:39 PM To: Any question about pharo is welcome <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.
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:jtuchel@objektfabrik.de Fliederweg 1 https://urldefense.com/v3/__http://www.objektfabrik.de__;!09EJrJkydGw!T9iwyN... D-71640 Ludwigsburg https://urldefense.com/v3/__http://joachimtuchel.wordpress.com__;!09EJrJkydG... Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
participants (8)
-
Joachim Tuchel -
jtuchel＠objektfabrik.de
-
Paul DeBruicker -
Pierce Ng -
Sean P. DeNigris -
sergio ruiz -
Tim Mackinnon -
Vince Refiti