- can anybody tell which and/or how much of erlang distribution functionality is implemented in atomvm for esp32? i would like to use gen_server:call({Name, Node}, Request) where Node =/= localhost on both raspberry (linux) and esp32 (atomvm)
- i can see 3 branches [main, release-0.6, feature/bigint] where main is the most up to date one and release-0.6 seems to be outdated soon. can anybody tell me how main and feature/bigint are related? i feel that either main or feature/bigint will lead to the future version. which one is the most complete version? which one should i go for?
1 Like
Thank you for your interest in our project! Indeed you can call a gen_server on a remote node. You can also do rpc calls from an OTP node, it doesn’t have to be another AtomVM node. This is quite handy for testing or debugging an AtomVM device from an erl cli.
The bigjnt branch is a work in progress to support bigger integers, it is unstable and should not be used except for testing bigint functionality. It will be merged to main once it is ready.
The main branch is where work for the future 0.7 release cycle. The release-0.6 branch is where bug fixes for 0.6.x are merged for the next update (I.e. the upcoming 0.6.7 release).
Main does have a lot more nice features, but is not considered stable for production use. There are (or may be) breaking changes from the 0.6 release cycle.
I hope this clears thing up, and don’t hesitate to post any further updates, suggestions or feedback.
— Winford
3 Likes
many thanks winford,
your answer has cleared up some ambiguities.
i decided to go for the main branch because i am interested in distributed applications (besides integrating sensors and actors).
unfortunately i was not able to run the test program (https://github.com/atomvm/AtomVM/blob/main/examples/erlang/esp32/epmd_disterl.erl#L51) on an esp32-s3 (sender on linux) successfully.
both on self-built main and on self-built feature/bigint it terminated with
CRASH
======
pid: <0.13.0>
Stacktrace:
[{socket_dist_controller,process_recv_buffer,3,[{file,"/home/xxxx/avm/$branch/AtomVM/libs/estdlib/src/socket_dist_controller.erl"},{line,192}]},{socket_dist_controller,recv_data_loop,1,[{file,"/home/xxxx/avm/feature-bigint/AtomVM/libs/estdlib/src/socket_dist_controller.erl"},{line,175}]},{socket_dist_controller,handle_cast,2,[{file,"/home/xxxx/avm/$branch/AtomVM/libs/estdlib/src/socket_dist_controller.erl"},{line,151}]},{gen_server,loop,3,[{file,"/home/xxxx/avm/$branch/AtomVM/libs/estdlib/src/gen_server.erl"},{line,539}]}]
cp: #CP<module: 19, label: 55, offset: 40>
x[0]: error
x[1]: badarg
x[2]: {4,4,150,2,[{6,3226},{19,929},{19,1514},{19,1659}],error}
Stack
-----
{<<112,131,104,4,97,6,88,119,13,116,64,115,112,120,46,115,112,54,101,46,100,101,0,0,0,95,0,0,0,0,104,129,253,168,119,0,119,7,100,105,115,116,101,114,108,131,119,4,113,117,105,116>>,<<"">>}
0
<<"">>
#CP<module: 19, label: 55, offset: 40>
[]
{state,{<<"">>,#Ref<0.0.28>},<<"">>,undefined,<<"">>,0,0}
#CP<module: 19, label: 39, offset: 69>
#CP<module: 6, label: 112, offset: 24>
[]
[]
[]
{state,{<<"">>,#Ref<0.0.28>},undefined,undefined,<<"">>,0,0}
[]
{state,undefined,socket_dist_controller,{state,{<<"">>,#Ref<0.0.28>},undefined,undefined,<<"">>,0,0}}
<0.12.0>
#CP<module: 6, label: 140, offset: 0>
Mailbox
-------
Monitors
--------
link to <0.14.0>
monitored by resource 0x3fcc65dc ref=44
**End Of Crash Report**
after i set a message and epmd is not included in release-0.6.
of course I had
Creds = [
{ssid, "****"},
{psk, "********"}
],
adjusted according to my network.
what could I be doing wrong?
addendum1: i use Erlang/OTP 27 [erts-15.2.2]
addendum2: i found https://github.com/atomvm/AtomVM/issues/1671 which describes my issue and suggests that the bug was fixed. did i clone a wrong branch? (i cloned using git clone -b main https://github.com/atomvm/AtomVM.git)
Sorry for the delay getting back to you. My day job has been keeping me extra busy lately.
Just to make sure I understand correctly, the error you posted happened after a message was sent from an OTP node?
Can you post the message you sent? There does seem to be a bug here, if the message contained a badarg you should get that back on the sender node, but knowing what message was sent might help to track down the bug.
The timing is a little unfortunate, @pguyot (contributor disterl support in AtomVM) is starting a well earned 2 week vacation, and will be unable to push any fixes. In the meantime we will see if we can get to the bottom of this.
I would suggest opening an issue on GitHub, if you can include the crash log, along with the exact steps you used to start and connect from the OTP node, along with the message that was sent it should help get to the bottom of this a little quicker.
Since you are using distribution, you should definitely stick to the main branch for now. There is no support in the 0.6-release branch (or any 0.6.x release), and the bigint branch is still a work in progress.
We use feature branches when authors are contributing a large set of changes with many commits. You can think of them a large multipart pull requests. This allows for easier review, and lets the authors submit PRs for smaller sets of changes as they are ready. Once all of the necessary changes are merged to the feature branch, and we do some testing of the final work they get merged into the appropriate branch (almost always main).
For esp32 make sure you built first in AtomVM/build, and then in platforms/esp32 and flash, especially when you change branches.
Tip: You can use chrome and flash latest from main (or release-0.6) here AtomVM Flasher just as a bug/sanity check..
(the binaries are scraped from CI eg. at the bottom here Merge pull request #1772 from pguyot/w29/optimize-term-compare · atomvm/AtomVM@8effe63 · GitHub)
sorry, i did not want to push you.
yes, you are right, the error happened after i had sent the message from another otp-27 node. i exactly followed the instruction from the doc and the output of the program i had started on the esp and entered {disterl, 'atomvm@10.28.57.99'} ! quit. at the erlang prompt after i had started the node (erl -name xxx@domain.tld) and had set the cookie using erlang:set_cookie('atomvm@10.28.57.99', 'AtomVM').
to be sure, i just repeated this procedure and saw the same result as before.
as i’m not in a hurry, i think, it might be best to wait until @pguyot will have finished his vacation.
thanks for your assistance, g4v
@outlog: i had built in AtomVM/build, and then in platforms/esp32 and had flashed AtomVm/libs/esp32boot/esp32boot.avm using build/flash.sh -l -p /dev/ttyACM2 ../../../build/libs/esp32boot/esp32boot.avm in the diectory platforms/esp and executed idf.py flash -p /dev/ttyACM2 in the same directory.
i even did this after i had erased flash (using esptool.py --chip esp32s3 --baud 921600 -p /dev/ttyACM2 erase_flash).
1 Like