JavaScript Programming: Add Code Sync Status and Gvar Display (Features 2 & 3) #2540
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Augment decompiler to track which Logic Conditions map to which lines in generated JavaScript code. This enables real-time highlighting of active conditions in the JavaScript Programming tab. Key features: - 3-pass mapping algorithm handles simple, compound, and nested conditions - Compound conditions (a && b) correctly map all sub-LCs to same line - Activator chains propagate line numbers to child LCs - Hoisted variables and sticky/timer patterns tracked - Returns lcToLineMapping in decompile() result Part of Feature 1: Active LC Highlighting (Phase 1/5)
Implement real-time status polling and gutter decoration updates in the JavaScript Programming tab to show which Logic Conditions are currently active/true. Key features: - Status polling every 100ms using MSPChainer - updateActiveHighlighting() filters true LCs and applies gutter markers - clearActiveHighlighting() when code is dirty (unsaved changes) - Proper cleanup on tab switch/disconnect - isDirty check prevents highlighting stale code Part of Feature 1: Active LC Highlighting (Phase 2/5)
Implement CSS and Monaco editor configuration for green checkmark gutter markers that indicate active/true Logic Conditions. Key changes: - Add .lc-active-true CSS class with SVG green checkmark icon - Add Monaco gutter margin background styling - Enable glyphMargin: true in Monaco editor options - Set up proper cursor and sizing for gutter decorations Part of Feature 1: Active LC Highlighting (Phase 3/5)
Fix 'Cannot read properties of null' error in updateActiveHighlighting() by adding proper null checks for FC.LOGIC_CONDITIONS_STATUS and FC.LOGIC_CONDITIONS before accessing .get(). This prevents errors during tab initialization when FC data is still loading.
The onChange handler was firing after setValue() during load, causing isDirty to be set to true even after we cleared it. This prevented the highlighting from ever appearing because updateActiveHighlighting() returns early when isDirty is true. Fixed by using setTimeout() to clear isDirty after the setValue() change event has been processed.
Previous approach tried to find LCs by parsing the generated code for /* LC X */ comments, but normal if-statements don't have these comments. New approach: - Track LC index and line content during code generation - After adding boilerplate, search for the tracked lines in final code - Map LC index to actual line numbers in final output This ensures all if-statements and their associated LCs get mapped correctly for the active highlighting feature.
Track what's being searched for and what's being found to diagnose why the LC-to-line mapping is empty.
This will help us diagnose why the green checkmarks aren't appearing by logging: - When the function is called - If isDirty is blocking it - What the LC-to-line mapping is - If FC data is available - Which LCs are TRUE - What lines should be highlighted - If decorations are created
FC.LOGIC_CONDITIONS_STATUS.get() requires a condition index parameter and returns a single value. We need getAll() to get the entire status array. This was causing 'FC data is null' errors and preventing any highlighting from appearing.
This completes the active LC highlighting feature with two major improvements: 1. FALSE condition indicators: Gray hollow circles (○) display when conditions evaluate to FALSE, complementing the existing green checkmarks for TRUE conditions. Mixed states (TRUE and FALSE on same line) show green checkmark. 2. Transpiler-side line tracking: LC-to-line mappings are now generated during transpilation, providing immediate visual feedback after "Transpile" or "Save to FC" without requiring "Load from FC" roundtrip. Correctly adjusts for auto-added import statement offset. Technical changes: - Add lineOffset tracking in codegen to account for prepended import lines - Store currentSourceLine context during statement generation - Return lcToLineMapping in transpiler result - Update tab to use transpiler mapping immediately after transpile/save - Change polling interval from 100ms to 500ms to reduce MSP load (2Hz vs 10Hz) - Reorder checks: verify FC data availability before isDirty state - Clean up excessive debug logging for production readiness Testing: - Verified circles appear on correct lines after transpile - Tested TRUE/FALSE/MIXED states display properly - Confirmed decompiler mapping replaces transpiler mapping on load - Reviewed with inav-code-review agent - all critical issues resolved
Fixes all 6 medium-priority issues identified by qodo-merge bot: 1. Clear stale decorations when loading code from FC 2. Clear mapping/decorations when loading default code 3. Add in-flight guard to prevent overlapping MSP polling requests 4. Remove duplicate intervals before adding new one 5. Improve type safety with Array.isArray() checks for MSP data Code organization improvements: - Extract highlighting logic to new module js/transpiler/lc_highlighting.js - Reduce tab file from 928 to 893 lines (-35 lines) - Create 5 testable, pure functions: categorizeLCsByStatus(), mapLCsToLines(), createMonacoDecorations(), applyDecorations(), clearDecorations() - Better separation of concerns (tab orchestrates, module implements) - Improved code maintainability and testability
Implement visual indicator showing when JavaScript editor content matches flight controller storage vs when changes exist locally. Key features: - Save button disabled when isDirty=false (code matches FC) - Save button enabled when isDirty=true (unsaved changes) - updateSaveButtonState() called at all isDirty change points - Uses existing .disabled CSS styling for visual feedback Part of Feature 2: Code Sync Status
…ing tab Feature 2 - Code Sync Status: - Disable Save button when editor matches FC (isDirty = false) - Enable Save button when code is modified (isDirty = true) - Uses existing .disabled CSS class with pointer-events: none Feature 3 - Gvar Display: - Display live non-zero global variable values as inline hints - Format: // gvar[index] = value - Position at end of line where gvar is referenced - Deduplicate - show each gvar only once at first occurrence - Auto-update at 500ms intervals via MSP polling - Implemented using Monaco Content Widgets API Implementation details: - Created js/transpiler/gvar_display.js module for gvar functionality - Added updateSaveButtonState() to manage Save button state - Added updateGvarDisplay() for real-time gvar value display - Integrated with existing MSPChainer for efficient polling - CSS styling: opacity 0.65, italic, subtle gray color
After code review, added critical error handling to prevent silent failures: - Monaco widget operations now wrapped in try-catch blocks - MSP chainer exit point updates protected with error handling - Fixed cleanup bug (gvarDecorations -> gvarWidgets) - Added console logging for debugging widget failures These changes ensure the gvar display feature degrades gracefully instead of breaking the polling loop if Monaco operations fail.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Implements Features 2 & 3 for JavaScript Programming debugging tools:
inav.gvar[N]referencesDependencies
This branch is based on
feature/js-programming-debug-toolsand adds Features 2 & 3 on top of Feature 1.Changes
Feature 2 - Code Sync Status
updateSaveButtonState()function that manages Save button enabled/disabled state.disabledCSS class withpointer-events: noneisDirty = false(code matches FC)Feature 3 - Gvar Display
js/transpiler/gvar_display.jsusing Monaco Content Widgets APIGvarHintWidgetclass for inline text display// gvar[index] = valueat end of line where gvar is referencedCode Quality Improvements
Testing
Tested on Hardware
pointer-events: none// gvar[0] = 32767Code Review
Reviewed with pr-review-toolkit using multiple agents:
code-reviewer- General code qualitycomment-analyzer- Comment accuracysilent-failure-hunter- Error handlingcode-simplifier- Complexity analysisAll critical issues addressed:
Files Changed
js/transpiler/gvar_display.js(new) - Gvar display moduletabs/javascript_programming.js- Integration and Save button statetabs/javascript_programming.html- CSS for gvar hintsScreenshots
Gvar hints displaying inline with subtle styling, Save button correctly disabled when code matches FC.
Related Issues
Part of JavaScript Programming debugging tools suite.