Pharo command line, stdout and integrating with other tools?
Hi - I've been playing with using Pharo with Aws lambda and have got an image to launch in that environment. However now I need to better integrate Pharo with its calling environment - and I know there was a concerted effort to make Pharo play better which I should be able to leverage. So I am calling Pharo from a NodeJS wrapper (the suggested aws method for integrating alternative languages like Ruby, Go etc). I got this to work - however as an observation, it is rather awkward passing parameters to Pharo using the "eval" mechanism as other languages and environments frequently use the " character (particularly with Json) and this causes Pharo to fail if you don't \" this. I'm wondering if others have noted this and whether we can do this better somehow? For now a little nodeJS regex fu gets me past it. However my next question is about passing information back to the calling application. I can see that there is a stdout method on Fikestream that I can write to (great), however in my ./pharo eval call, which sends to a class method doing this - it also returns the result of that method or yourself? I guess this convention is great for the "eval 42 factorial" example but not so great of you just want to return some Json via stdout in a format of the calling environment? Is there something simple trick I can do to stop this extra result and just let me use stdout myself? Or do I have to return a Smalltalk string and then regex convert it to a new format in my calling language? I'm wondering if others have done this, or if anyone has some advice? It feels like a usecase that we might be able to do better somehow? Tim Sent from my iPhone
If I'm not mistaken, this is Pharo's eval command line handler you're talking about. If so, it is not correct to say 'it also return the result of that method or yourself'. To return the result (and print it to stdout) of that method is the goal of eval command line handler. How about making your method to return empty string, or better create your own command line handler. I believe the minimal you need to do is to subclass EvaluateCommandLineHandler, override class method #commandName and override method #evaluate:. Something like this, perhaps ProceesCommandLineHandler class >> commandName ^ 'process' ProcessCommandLineHandler >> evaluate: aStream Smalltalk evaluate: aStream. Save your image, then you can call ./pharo -headless myimage.image process StandardFileStream stdout print: 42 and it'll print 42 and nothing else. I'm not sure I understand the double quote (") character issue that \" solves. Example? On Thu, Jun 29, 2017 at 7:02 AM, Tim Mackinnon <tim@testit.works> wrote:
Hi - I've been playing with using Pharo with Aws lambda and have got an image to launch in that environment.
However now I need to better integrate Pharo with its calling environment - and I know there was a concerted effort to make Pharo play better which I should be able to leverage.
So I am calling Pharo from a NodeJS wrapper (the suggested aws method for integrating alternative languages like Ruby, Go etc).
I got this to work - however as an observation, it is rather awkward passing parameters to Pharo using the "eval" mechanism as other languages and environments frequently use the " character (particularly with Json) and this causes Pharo to fail if you don't \" this. I'm wondering if others have noted this and whether we can do this better somehow? For now a little nodeJS regex fu gets me past it.
However my next question is about passing information back to the calling application.
I can see that there is a stdout method on Fikestream that I can write to (great), however in my ./pharo eval call, which sends to a class method doing this - it also returns the result of that method or yourself? I guess this convention is great for the "eval 42 factorial" example but not so great of you just want to return some Json via stdout in a format of the calling environment?
Is there something simple trick I can do to stop this extra result and just let me use stdout myself? Or do I have to return a Smalltalk string and then regex convert it to a new format in my calling language?
I'm wondering if others have done this, or if anyone has some advice?
It feels like a usecase that we might be able to do better somehow?
Tim
Sent from my iPhone
Thanks Andreas, I was just coming to the conclusion you have pointed out. I haven't had a computer to try it - but I'll try your example. If it works, I think this should almost be in the std image so that Pharo plays better with others straight out of the box. The " issue is when calling from other other languages (e.g. Nodejs). Try passing some Json as a parameter using exec and you hit this issue with the eval handler - but maybe with my own handler I can do something better? I need to study this and will report back. Thanks, Tim Sent from my iPhone
On 1 Jul 2017, at 17:17, Andreas Sunardi <a.sunardi@gmail.com> wrote:
If I'm not mistaken, this is Pharo's eval command line handler you're talking about. If so, it is not correct to say 'it also return the result of that method or yourself'. To return the result (and print it to stdout) of that method is the goal of eval command line handler.
How about making your method to return empty string, or better create your own command line handler. I believe the minimal you need to do is to subclass EvaluateCommandLineHandler, override class method #commandName and override method #evaluate:. Something like this, perhaps
ProceesCommandLineHandler class >> commandName ^ 'process'
ProcessCommandLineHandler >> evaluate: aStream Smalltalk evaluate: aStream.
Save your image, then you can call ./pharo -headless myimage.image process StandardFileStream stdout print: 42
and it'll print 42 and nothing else.
I'm not sure I understand the double quote (") character issue that \" solves. Example?
On Thu, Jun 29, 2017 at 7:02 AM, Tim Mackinnon <tim@testit.works> wrote: Hi - I've been playing with using Pharo with Aws lambda and have got an image to launch in that environment.
However now I need to better integrate Pharo with its calling environment - and I know there was a concerted effort to make Pharo play better which I should be able to leverage.
So I am calling Pharo from a NodeJS wrapper (the suggested aws method for integrating alternative languages like Ruby, Go etc).
I got this to work - however as an observation, it is rather awkward passing parameters to Pharo using the "eval" mechanism as other languages and environments frequently use the " character (particularly with Json) and this causes Pharo to fail if you don't \" this. I'm wondering if others have noted this and whether we can do this better somehow? For now a little nodeJS regex fu gets me past it.
However my next question is about passing information back to the calling application.
I can see that there is a stdout method on Fikestream that I can write to (great), however in my ./pharo eval call, which sends to a class method doing this - it also returns the result of that method or yourself? I guess this convention is great for the "eval 42 factorial" example but not so great of you just want to return some Json via stdout in a format of the calling environment?
Is there something simple trick I can do to stop this extra result and just let me use stdout myself? Or do I have to return a Smalltalk string and then regex convert it to a new format in my calling language?
I'm wondering if others have done this, or if anyone has some advice?
It feels like a usecase that we might be able to do better somehow?
Tim
Sent from my iPhone
Just to confirm and give a specific example - if I use the eval handler, you get output like the following which means that other tools will barf (the json was written to stdout, the âokâ string was the result of the method called). So Andreas is correct - I need to write my own handler. I will report back. { "outputSpeach": { "text": "hello world", "type": "PlainText" }, "card": { "content": "Operation Complete", "title": "Genius", "type": "simple" } } âokâ <â this extra output, the result of a method will confuse tools calling Pharo Tim
On 1 Jul 2017, at 17:41, Tim Mackinnon <tim@testit.works> wrote:
Thanks Andreas, I was just coming to the conclusion you have pointed out. I haven't had a computer to try it - but I'll try your example.
If it works, I think this should almost be in the std image so that Pharo plays better with others straight out of the box.
The " issue is when calling from other other languages (e.g. Nodejs). Try passing some Json as a parameter using exec and you hit this issue with the eval handler - but maybe with my own handler I can do something better? I need to study this and will report back.
Thanks,
Tim
Sent from my iPhone
On 1 Jul 2017, at 17:17, Andreas Sunardi <a.sunardi@gmail.com <mailto:a.sunardi@gmail.com>> wrote:
If I'm not mistaken, this is Pharo's eval command line handler you're talking about. If so, it is not correct to say 'it also return the result of that method or yourself'. To return the result (and print it to stdout) of that method is the goal of eval command line handler.
How about making your method to return empty string, or better create your own command line handler. I believe the minimal you need to do is to subclass EvaluateCommandLineHandler, override class method #commandName and override method #evaluate:. Something like this, perhaps
ProceesCommandLineHandler class >> commandName ^ 'process'
ProcessCommandLineHandler >> evaluate: aStream Smalltalk evaluate: aStream.
Save your image, then you can call ./pharo -headless myimage.image process StandardFileStream stdout print: 42
and it'll print 42 and nothing else.
I'm not sure I understand the double quote (") character issue that \" solves. Example?
On Thu, Jun 29, 2017 at 7:02 AM, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> wrote: Hi - I've been playing with using Pharo with Aws lambda and have got an image to launch in that environment.
However now I need to better integrate Pharo with its calling environment - and I know there was a concerted effort to make Pharo play better which I should be able to leverage.
So I am calling Pharo from a NodeJS wrapper (the suggested aws method for integrating alternative languages like Ruby, Go etc).
I got this to work - however as an observation, it is rather awkward passing parameters to Pharo using the "eval" mechanism as other languages and environments frequently use the " character (particularly with Json) and this causes Pharo to fail if you don't \" this. I'm wondering if others have noted this and whether we can do this better somehow? For now a little nodeJS regex fu gets me past it.
However my next question is about passing information back to the calling application.
I can see that there is a stdout method on Fikestream that I can write to (great), however in my ./pharo eval call, which sends to a class method doing this - it also returns the result of that method or yourself? I guess this convention is great for the "eval 42 factorial" example but not so great of you just want to return some Json via stdout in a format of the calling environment?
Is there something simple trick I can do to stop this extra result and just let me use stdout myself? Or do I have to return a Smalltalk string and then regex convert it to a new format in my calling language?
I'm wondering if others have done this, or if anyone has some advice?
It feels like a usecase that we might be able to do better somehow?
Tim
Sent from my iPhone
I actually got the bottom of why I was having problems with â characters. Itâs a bash thing (see:http://wiki.bash-hackers.org/syntax/quoting <http://wiki.bash-hackers.org/syntax/quoting>) regarding strong and weak quotes. The syntax I needed to use (which is somewhat convoluted): ./pharo Pharo.image exec âMyClass processJSON: '\''{ "we" : "love", "using" : "Lambda" }'\''' Possibly this might help someone else in the future. Tim
On 1 Jul 2017, at 16:17, Andreas Sunardi <a.sunardi@gmail.com> wrote:
If I'm not mistaken, this is Pharo's eval command line handler you're talking about. If so, it is not correct to say 'it also return the result of that method or yourself'. To return the result (and print it to stdout) of that method is the goal of eval command line handler.
How about making your method to return empty string, or better create your own command line handler. I believe the minimal you need to do is to subclass EvaluateCommandLineHandler, override class method #commandName and override method #evaluate:. Something like this, perhaps
ProceesCommandLineHandler class >> commandName ^ 'process'
ProcessCommandLineHandler >> evaluate: aStream Smalltalk evaluate: aStream.
Save your image, then you can call ./pharo -headless myimage.image process StandardFileStream stdout print: 42
and it'll print 42 and nothing else.
I'm not sure I understand the double quote (") character issue that \" solves. Example?
On Thu, Jun 29, 2017 at 7:02 AM, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> wrote: Hi - I've been playing with using Pharo with Aws lambda and have got an image to launch in that environment.
However now I need to better integrate Pharo with its calling environment - and I know there was a concerted effort to make Pharo play better which I should be able to leverage.
So I am calling Pharo from a NodeJS wrapper (the suggested aws method for integrating alternative languages like Ruby, Go etc).
I got this to work - however as an observation, it is rather awkward passing parameters to Pharo using the "eval" mechanism as other languages and environments frequently use the " character (particularly with Json) and this causes Pharo to fail if you don't \" this. I'm wondering if others have noted this and whether we can do this better somehow? For now a little nodeJS regex fu gets me past it.
However my next question is about passing information back to the calling application.
I can see that there is a stdout method on Fikestream that I can write to (great), however in my ./pharo eval call, which sends to a class method doing this - it also returns the result of that method or yourself? I guess this convention is great for the "eval 42 factorial" example but not so great of you just want to return some Json via stdout in a format of the calling environment?
Is there something simple trick I can do to stop this extra result and just let me use stdout myself? Or do I have to return a Smalltalk string and then regex convert it to a new format in my calling language?
I'm wondering if others have done this, or if anyone has some advice?
It feels like a usecase that we might be able to do better somehow?
Tim
Sent from my iPhone
participants (2)
-
Andreas Sunardi -
Tim Mackinnon