targets/zephyr: REPL: Print expression result, or exception value.

[pfalcon]

With this change, REPL works almost the same as a standard JS REPL does
(browser console, Node.js, etc.). A result of each expression is
printed, e.g. "2+2" will print "4". Result is printed even if its
value is "undefined", e.g. "print(1)" will print "1", and on the next
line "undefined" (which is again how "normal" JS console work, except
a normal JS way to print to console is console.log()).

If an exception occured, a message "Error executing statement:", followed
by external representation of exception object, is printed. Note that
distinctive exception objects are supported only in "cp" (compact profile),
not in "cp_minimal". In the latter case, there's only exception hierarchy
top-level prototype, so any error message will look like:

Error executing statement: [object Function]

(That's the reason why there's error message prefix - so it weren't too
confusing even if used in cp_minimal config. Unfortunately, compile-time
JerryScript configuration isn't available to Zephyr's main.c, so there's
no easy way to implement cp vs cp_minimal distinction).

JerryScript-DCO-1.0-Signed-off-by: Paul Sokolovsky paul.sokolovsky@linaro.org

[pfalcon]

This finishes work started in #1190, now REPL works pretty much like a browser JS console/Node.js do.

@sergioamr , @poussa : FYI

[zherczeg]

LGTM

[LaszloLango]

Although a jerry_release_value call on an undefined value is a no-op at the moment, this can be changed later. I suggest you to put the value of 'this' into a local variable and call jerry_release_value after the function call. The code will be more stable.

jerry_value_t this_val =  jerry_create_undefined ();
jerry_value_t ret_val_print = jerry_call_function (print_function, this_val, &ret_val, 1);
jerry_release_value (this_val);

[pfalcon]

@LaszloLango, The code above is taken as-is from main-unix.c. I'd be reluctant to stray too much from it, to avoid confusion for someone who may later deal with Zephyr code (including myself at some later time). I'd be happy to apply such change later, when main-unix.c will be updated. (Or can submit a next change to update both if you think it makes sense.)

[LaszloLango]

LGTM, my comments are only suggestions. We can land it as is, if you don't want to update the PR.

[poussa]

I like the feature, did not look at the code.

[pfalcon]

The patch updated per a suggestion above, added error handling for "print" function lookup. Also, rebased onto the latest master.

[sergioamr]

I like it. LGTM

@pfalcon I am currently working on getting the USB ACM Uart from Zephyr working on the Arduino 101 to upload code directly and save it into a permanent state.

Zephyr seems to have a few bugs on the uart so you loose data on transactions and i've been fixing those.

It would be nice if you could have a look.

It is very Arduino 101 oriented right now, since it creates the javascript Shell in the Uart0 and you can upload code in Ihex format into the Uart1 on the usb acm. I am not sure how other boards are supporting the serial transactions and how difficult it would be to add support for those.

I am also building a web editor to edit and upload code to the device using serial if you would like to play with it too.

https://github.com/jslaunchbox/ihex_uploader/tree/wip/sergio/debugging_uart

[LaszloLango]

@pfalcon, LGTM

P.S. It would be great to change the printf calls to jerry_port_console and jerry_port_log in a followup work.

[LaszloLango]

@pfalcon, please rebase to the current master, so we can land the PR properly.

[pfalcon]

@LaszloLango : Rebased, thanks!

[pfalcon]

@sergioamr : Thanks for heads-up, sounds interesting, will have a more detailed look. I spotted in the README of the link above you mention "10 spaces" limit of Zephyr shell parser. I hit that too, submitted https://jira.zephyrproject.org/browse/ZEP-532 on that, not sure though what's the best way (for Zephyr) to resolve it.

[sergioamr]

@pfalcon The 10 spaces limit is quite annoying. I was looking at the RFC for the new shell and there is not a treatment for special cases where you need to get the raw data directly, the shell code is quite small and i am reusing part of it... also the uart console has a few issues with disconnecting if the package is too big.

I don't plan on creating a pull request for the development i am doing since i think it is quite outside the purpose of the integration but basically this is the idea:

Arduino 101 has two UARTs, one on the USB and one on some pins that you have to use the TTL levels adapter.

On the USB i have a service with a simple shell.
You can set states, like the file name you want to use to write the program, the type of transfer...
It is getting complicated really fast, here is an example of what my raw plan is:

set filename
set transfer raw / ihex / snapshot
get filedata

begin transaction
<Transfer / writing / happens>
end transaction

bluetooth connect / disconnect / list

parse
run
debug server -> Launches a debug server to step into the jerryscript code

On the UART i have a shell with lots of commands to test how is everything going inside the zephyr with transactions and stuff.

Where is the best place to have this kind of talks ? I could do with feedback and how to get other devices to work on this, since i am also working in a webeditor which could benefit from all of this.

A pull request doesn't seem to be the best place hahaha 💃
I am also looking about how is it going to work using bluetooth so you can upload code to the device wirelessly.

It is going to be fun to write all of that 👯

[pfalcon]

The 10 spaces limit is quite annoying. I was looking at the RFC for the new shell and there is not a treatment for special cases where you need to get the raw data directly, the shell code is quite small and i am reusing part of it...

I now (yesterday) read the new shell RFC too, and yep, it seems that it would be better not to use shell service for JerryScript input, as it has different purpose than just allowing user to input a line. But using console API directly looks also cumbersome, I gathered my thought on that in a zephyr mailing list post (you should be in cc: if I got it right): https://lists.zephyrproject.org/archives/list/devel@lists.zephyrproject.org/thread/JXBRTPP56R5BJJALWXRVCESHZYSQUN72/ .

I don't plan on creating a pull request for the development i am doing since i think it is quite outside the purpose of the integration but basically this is the idea:

Reading thru it, I agree that it goes beyond basic Zephyr support in JerryScript, and kind of a separate project built on top of it.

It is getting complicated really fast, here is an example of what my raw plan is:

Well, I can only ack that, it all sounds familiar. For another project I'm working on, MicroPython, we have a tool called WebREPL - essentially, a telnet over websockets. But then people of cause want to also transfer files with it, but to do that comfortably, you need to be able to create dirs and list files in them, etc., etc. With WebREPL, we aren't yed beyond mere transferring files, so good luck with you thing ;-).

Where is the best place to have this kind of talks ? I could do with feedback and how to get other devices to work on this, since i am also working in a webeditor which could benefit from all of this.

Yep, random related tickets aren't the best place for that ;-). I guess that at least an occasional post to Zephyr users mailing lists would be helpful to let other folks know what kind of solutions are being built on Zephyr. And making it portable won't be easy, for example you assume 2 wired serial-like connections, but having 2 is more like exception I guess (or requires UART/USB adapter indeed, not very user-friendly), then people will want wireless, and that can be WiFi or BLE, etc.

Btw, I tried to build your code (for qemu, as I don't have Arduino101), but there was an error, apparently because of ongoing JrS API refactor...