libpebble2.exceptions.TimeoutError when running emu-app-config for faces with enableMultiJS

[tilden]

It seems that some change in the Pebble tool broke the emu-app-config function for faces with enableMultiJS set to true. Faces and apps using the older style of Javascript do not appear to be affected.

Steps to reproduce:

1. Clone a face from Github that uses enableMultiJS. For example, Chris Lewis's Thin face will work: git clone https://github.com/C-D-Lewis/thin.git
2. Build and install the face: pebble build pebble install --emulator=basalt
3. Try to configure the face: pebble emu-app-config

At least in my tests, it times out, giving the error:

Traceback (most recent call last):
  File "/usr/local/Cellar/pebble-sdk/4.3/libexec/bin/pebble", line 9, in <module>
    load_entry_point('pebble-tool==4.3', 'console_scripts', 'pebble')()
  File "/usr/local/Cellar/pebble-sdk/4.3/libexec/lib/python2.7/site-packages/pebble_tool/__init__.py", line 43, in run_tool
    args.func(args)
  File "/usr/local/Cellar/pebble-sdk/4.3/libexec/lib/python2.7/site-packages/pebble_tool/commands/base.py", line 47, in <lambda>
    parser.set_defaults(func=lambda x: cls()(x))
  File "/usr/local/Cellar/pebble-sdk/4.3/libexec/lib/python2.7/site-packages/pebble_tool/commands/emucontrol.py", line 109, in __call__
    response = self.pebble.read_transport_message(MessageTargetPhone, WebSocketPhonesimConfigResponse)
  File "/usr/local/Cellar/pebble-sdk/4.3/libexec/vendor/lib/python2.7/site-packages/libpebble2/communication/__init__.py", line 253, in read_transport_message
    return self.event_handler.wait_for_event((_EventType.Transport, origin, message_type), timeout=timeout)
  File "/usr/local/Cellar/pebble-sdk/4.3/libexec/vendor/lib/python2.7/site-packages/libpebble2/events/threaded.py", line 37, in wait_for_event
    return _BlockingEventWait(self, event).wait(timeout=timeout)
  File "/usr/local/Cellar/pebble-sdk/4.3/libexec/vendor/lib/python2.7/site-packages/libpebble2/events/threaded.py", line 61, in wait
    raise TimeoutError()
libpebble2.exceptions.TimeoutError

However, if a pre-multi-js commit is checked out, this error doesn't occur: git checkout 35c1f53b487ee54690ce42dc222f47a9ff5cea56

Build, install, and emu-app-config. It will correctly load the Dropbox-hosted config page.

[thirtythreeforty]

Can confirm here. Not entirely sure how to work around this.

[cjwilliams]

In the case of Chris Lewis's "thin" watchface, there is no bug with the emu-app-config command. If you install a compiled version of that app and run logs, you'll notice there's an error about Clay being included:

INFO:pypkjs.javascript.pebble:JS starting
[07:05:49] pkjs> JavaScript Error:
Error: Cannot find module 'clay'
    at Object.loader.require (loader.js:67:11)
    at _require.require (loader.js:55:48)
    at Object.loader (src/js/app.js:3:12)
    at _require (loader.js:58:10)
    at Object.loader.require (loader.js:70:10)
    at build/js/message_keys.json:12:14
    at build/js/message_keys.json:13:5
    at build/js/message_keys.json:14:3

If you fix the error by replacing clay and config.json with relative paths, ./clay and ./config.json, the project installs and runs correctly, and emu-app-config works as expected.

I can try to reproduce the issue if this is not the resolution to your problem, but a minimal app that reproduces the issue would be needed to do that. @thirtythreeforty @tilden

[thirtythreeforty]

Oh I see, so the problem is that the JS crashes due to the non-relative load path, and the Python that is expecting the JS to load finally times out? Funny that it would work on the phone but not on the emulator.

I will try that when I get home, thanks.

[tilden]

@cjwilliams Thanks for the response!

I hadn't thought to look at the logs for "Thin" because the logs came up blank when I encountered the same issue on my own watchface.

It turns out that if a face uses the classic appinfo.json format, JS package errors aren't shown in the logs for whatever reason. After converting my watchface to the new package.json format, I started getting errors that looked identical to the ones you found in Chris Lewis's face. Changing the paths to relative did indeed fix the issue! Thanks!