Yes, it is. Socket is implemented for all the simulators on macOS, Windows, and Linux. That allows just about all the network modules to work. For example, you can run the httpget example:
cd $MODDABLE/examples/network/http/httpget
mcconfig -d -mYou can run the WebSocket examples the same way. Unfortunately.... the websocketclient example currently throws an exception because the echo server it uses was recently shut down. But, the example is still correct... if you can find another echo server. ;)
cd $MODDABLE/examples/network/websocket/websocketclient
mcconfig -d -mlet device = compartment.importNow(info.path).default;
Great. So, in this JS file that is loaded by the mcsim (let's call it device.js), which contains code describing the interface and behavior of the simulator (making use of DeviceBehavior and DeviceWorker imported from DevicePane), I just can't import any module. In the beginning of the file, if I for example write
import { Client } from "websocket"xsbug will raise an error in the mcsim/main.js file when trying to load this device.js file in the reloadDevices function saying that module websocket can't be found.
Right, you can't do that. ;)
What you are overlooking is that within mcsim there are two completely separate JavaScript virtual machines. There is one for mcsim itself, which includes Piu and a handful of other modules from the Moddable SDK. The other virtual machine is for the hosted Moddable SDK project running in the simulator. That project includes whatever modules from the Moddable SDK that your project manifest uses, such as WebSockets. There might be a way to modify mcsim to include some other modules. But, we've never tried because we didn't intend for it to be used that way.
The simulator already has a communication path for you to use. Here's an easy way to see that.
Add these lines at the end of $MODDABLE/examples/helloworld/main.js:
screen.onMessage = function(msg) {
msg = JSON.parse(msg);
screen.postMessage(JSON.stringify({led: msg.button}));
}Then on the command line, do this:
cd $MODDABLE/examples/helloworld
mcconfig -d -m -p simulator/moddable_twoNow you can blink the light in the simulator, as shown below.
mcsim simulator is still considered experimental and so we haven't documented it yet. That said, it works well and we use it on nearly every client project we do, so maybe it is finally time to retire the venerable screen test (our original and still default simulator) and make the switch.
mcsim is pretty obscure. How did you happen across that and decide to start working with it? It is great that you did.
mcsim for simulation, but is kind of outdated. So I'm working on another project that uses Screen Test and this aforementioned WebSocket/HTML workaround to control the screen. So basically I'm working on the latter in order to fully migrate the simulation to mcsim, having all user interactions embedded on it and establishing its communication to the main application, which works fine now.
Hi @phoddie - been a while (just under a year!) but I'm finally back on my Moddable project. I had a simple question about destructors in XS in C. I see that the (xsMachine) isn't passed to the destructor (the object is the first parameter; perhaps it's in another parameter?) I currently store it in my object in the constructor, and then access it in the destructor like this:
void xs_example_destructor(void *data)
{
xsMachine *the = ((test *)data)->the;
xsTrace("In destructor\n");
}It seems to be working in my very simple tests, but I was concerned I may be accessing a pointer (to the) that could be freed / invalid at this time. Is this the correct way to access the or is there a better way (or, not allowed at all)?
the is not passed to the destructor. The destructor is invoked from deep within the garbage collector, which is a time when it is not safe to call XS. It might work sometimes. But, it isn't safe. None of the destructors in the Moddable SDK call XS in C APIs for that reason.
I have the CPP file in the manifest/build, but of course I get errors on including Arduino.h. I added the CPLUS_INCLUDE_PATH to reference the Arduino includes, but then run into issues with missing defines / configuration. For example, currently it fails with:
# cc LoRa.cpp.o
cc1plus.exe: warning: command line option '-Wno-implicit-function-declaration' is valid for C/ObjC but not for C++
cc1plus.exe: warning: command line option '-std=gnu99' is valid for C/ObjC but not for C++
In file included from c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/avr/pgmspace.h:90,
from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:28,
from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14,
from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4:
c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/avr/io.h:711:6: warning: #warning "device type not defined" [-Wcpp]
# warning "device type not defined"
^~~~~~~
In file included from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/USBAPI.h:25,
from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:234,
from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14,
from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4:
c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/avr/eeprom.h:41:3: warning: #warning "Device does not have EEPROM available." [-Wcpp]
# warning "Device does not have EEPROM available."
^~~~~~~
In file included from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/USBAPI.h:27,
from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:234,
from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14,
from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4:
c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/util/delay.h:92:3: warning: #warning "F_CPU not defined for <util/delay.h>" [-Wcpp]
# warning "F_CPU not defined for <util/delay.h>"
^~~~~~~
In file included from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14,
from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4:
c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:258:10: fatal error: pins_arduino.h: No such file or directory
#include "pins_arduino.h"
^~~~~~~~~~~~~~~~
compilation terminated.I know the pins_arduino.h is just an include path, but the missing defines are more likely indicative of a more serious setup issue and likely I'm driving off the edge of a cliff....!
mcconfig to set additional build flags for certain files. It is an obscure feature, but it is also why our ESP8266 build works at all. The recipes named in the manifest are contained in $MODDABLE/tools/mcconfig, for example this is the strings-in-flash used on Mac and Linux builds.