Run the executable if no error #1302
Conversation
| if (backend == Backend::wasm) { | ||
| err = system(("js " + outfile +".js").c_str()); | ||
| } else { |
There was a problem hiding this comment.
@Shaikh-Ubaid, the Wasm Backend executable can be executed using js filename.out.js, right?
There was a problem hiding this comment.
It can be executed using node a.out.js (where a.out and a.out.js are the output files generated).
I am unsure if we need auto-execution for wasm backend (or other backends excluding llvm). It seems that when a user specifies a particular backend (apart from llvm, for example, let's say --backend=wasm), the (primary) intention of the user is to generate target backend code from the source code. Thus, if a user executes lpython examples/expr2.py --backend wasm, he's trying to generate wasm code from the source code. He could later choose to use the generated wasm code for his own purposes or choose to execute it.
I think it would be better if we leave the choice of what should be done with the output code (wasm code in our example) onto the user. One added advantage of leaving the choice with the user is that the user would get to know what all files are generated using a particular backend (wasm backend generates two files a.out and a.out.js). The user also gets the opportunity to explore how the generated target (wasm) code could be executed.
I am just sharing my thoughts here. Anything is-fine/works for me.
There was a problem hiding this comment.
@czgdp1807 @certik Can you please share your thoughts as well?
I made these changes because I felt like the behaviour should be consistent on all the backends.
There was a problem hiding this comment.
It seems that when a user specifies a particular backend (apart from llvm, for example, let's say --backend=wasm), the (primary) intention of the user is to generate target backend code from the source code.
Not sure. I guess --show-wasm should generate the code?
Overall I guess at least the executable shouldn't be deleted after automatic execution. For now for LLVM backend it gets deleted.
There was a problem hiding this comment.
After this PR changes got merged. LPython doesn't generate a.out anymore. Instead, it generates filename.out. These changes were made because of some problems in testing the runtime outputs, see here for more details. Also, to stop the automatic execution one can use the -o option to specify the executable to be written into.
I apologize for not sharing this updated information.
There was a problem hiding this comment.
I don't have a strong opinion either way on this. I feel calling "node" from LPython seems fragile.
I think for now, why don't we do the following:
lpython a.pycompilesa.pywith the default backend (currently LLVM, perhaps in the future it will be WASM + x86/arm) and runs it- If any other option is passed to
lpython, then it will not run it by default.
Although I can see how this is not super consistent. But it gets us started. I think the most common use case is python a.py, so we now already have lpython a.py. Everything else seems lower priority.
We could also consider lpython run a.py or lpython --run a.py, and then you can supply other options as needed.
There was a problem hiding this comment.
Do you mean lpython --run a.py --backend x86 to run by default?
There was a problem hiding this comment.
I think lpython a.py --backend x86 && ./a.out is much familiar than using --run. So, Let's only support lpython a.py to run by default.
Also, I have a doubt: Currently, we write the executable to filename.out. Is this fine for other backend as well?
There was a problem hiding this comment.
Do you mean
lpython --run a.py --backend x86to run by default?
Makes sense to me.
Thirumalai-Shaktivel
force-pushed
the
auto_run
branch
from
6b9c616 to
ac19aec
Compare
| if (err != 0) { | ||
| if (0 < err && err < 256) { | ||
| return err; | ||
| } else { | ||
| return 1; | ||
| } | ||
| } |
There was a problem hiding this comment.
This is a separate topic:
I recently came across something like this:
def test():
quit(10)
test()$ lpython a.py
err = 2560
STOP
$ echo $?
1So, I thought to replace this with the following change:
| if (err != 0) { | |
| if (0 < err && err < 256) { | |
| return err; | |
| } else { | |
| return 1; | |
| } | |
| } | |
| if (err != 0) { | |
| if (0 < err && err < 256) { | |
| return err; | |
| } if else (err % 256 == 0) { | |
| return err / 256; | |
| } else { | |
| return 1; | |
| } | |
| } |
Provide this support for all other backends. The user can pass `-o` option to stop the binary execution.
Thirumalai-Shaktivel
force-pushed
the
auto_run
branch
from
ac19aec to
ef95afc
Compare
|
Thanks for the approvals. Let's merge this. |
No description provided.