Automatically command rotator when tuning database entries #122
Conversation
RequireJS normally allows two different types of dependencies: module names, and URLs to JavaScript files. When the nodeIdCompat option is set, it unconditionally removes a trailing ".js" from dependency names even if those names are URLs, which then causes it to try to load from the wrong URL. Mounting tests at test/ and loading them as modules works around this problem while still allowing nodeIdCompat to be true so node modules can be loaded.
Some modules, like geodesy, call require() with .js filenames. In
Node, require("./dms") and require("./dms.js") are the same path, but
in RequireJS's default configuration, the former is treated as a
module path and the latter is treated as a URL relative to the
document's base path (NOT the RequireJS baseUrl!
Enabling the Node support means that all modules need to be loaded
with module names and not relative URLs, so the plugin loader is
changed to give the module name of plugin javascript.
quentinmit
force-pushed
the
rotator-tune
branch
from
877f372
to
7abf153
Compare
|
General early comments:
|
I tried to cover this in the commit messages, but the short answer is, var Dms = require('./dms.js');and RequireJS misinterprets that as relative to the HTML file and not the javascript file that includes it. I think I could also make it work by using RequireJS's "shims" mechanism, which would save the transformation step but pollute the global namespace with
If we did anything like that we'd have to give up on geodesy being a submodule. If you want to do that I'd rather just fork it and ship the forked version with shinysdr.
I thought about that, but on balance I went ahead with a client-side solution because it's more than enough for use with database entries, and moving targets is an edge-case. |
|
You can look at https://github.com/w1xm/shinysdr/tree/rotator-tune-shim to see what this would look like using |
|
-Suggestion: web ui should make a distinct visual indication between a tracking plot and Antenna position. Focus on code to update the predicted position and plot that on the globe. Comment: importing antenna beamwidth/focal length of station properties. This effect allows directional reception rather than precise tracking. important when pairing directional dish aperture with tracking speed, and reporting this all to the web interface. Q; Show the current predicted position ? or Current predicted position along a path? Icon moves along the ArcPath? Resulting in a checksum that returns plotting lock on for position alignment for the page. |
|
Just to set expectations, I don't expect to get around to further action on this PR until January. This is partly because of the holidays, and partly because the module loading awkwardness is tempting me to implement the """correct""" solution here (server-side continuous tracking) instead and so I may give that a shot. |
This required some interesting surgery to work around RequireJS bugs when loading the geodesy library.
geodesy is built as a CommonJS library, which RequireJS provides support for but it is partially broken. More detail is in the commit messages.
I could have instead patched the geodesy source or used one of the existing module converters out there, but I didn't want to add any additional build steps and build-time dependencies.