Fixes to workflow and precompilation#77
Merged
Merged
Conversation
…s Spice3 in_c) Algorithmic Modelica function bodies kept a record used as a whole value as a bare symbol, so a record copy / call argument / return / field-index referenced an undeclared symbol (e.g. `in_c` in the Spice3 MOSFET functions), failing the in-backend structural_simplify build. Scalarise every record use onto the flattened `<base>_<field>` symbols (the naming flattenRecordInput already emits): - whole-record copy lhs := rhs -> per-field assignments - record call argument -> splat into its flat field symbols - record-valued call assignment -> scatter the flat-tuple return - record cref indexed by a constant -> the kth flat field symbol All four Spice3 examples (Inverter, Nor, Nand, FourInverters) now build via the in-backend structural_simplify path (previously they fell back). Detection is fully structural (cref/type pattern-matching, no string parsing); helpers carry strict argument types and signature docstrings. LRT green (289 pass / 0 fail / 6 broken) with this change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three test-only fixes for type mismatches against production:
- mock stringToSimVarHT used Tuple{Integer, SimVar}; SIM_CODE requires
Tuple{Int, SimVar} (backendTestMocks.jl, simCodeTraverseTests.jl)
- mkWhenEq passed nothing for the attr field added to WHEN_EQUATION;
use EQ_ATTR_DEFAULT_UNKNOWN (runtests.jl)
Suite: 228/228 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #77 +/- ##
==========================================
- Coverage 24.78% 21.40% -3.38%
==========================================
Files 28 44 +16
Lines 3430 21213 +17783
==========================================
+ Hits 850 4541 +3691
- Misses 2580 16672 +14092 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
On Windows the umbrella precompile/load failed with could not load library "...\artifacts\...\libgio-2.0-0.dll" The specified procedure could not be found. (and a blocking Windows error popup). Root cause: OMRuntimeExternalC loads its own bundled mingw libintl-8.dll / libiconv-2.dll into the process. If that happens before Glib is loaded, Glib's libgio-2.0-0.dll binds against the older gettext runtime and fails to resolve an entry point. It is order-dependent (so it appeared intermittent) and Windows-only (Linux resolves each library against its own RPATH). Fix: import Plots at the top of the OMBackend module, before the includes that pull in OMRuntimeExternalC, so Glib's gettext wins the libintl-8.dll name first; OMRuntimeExternalC tolerates the newer runtime. Verified: full OM.jl umbrella now precompiles (exit 0) and `using OM` loads on Windows + Julia 1.12.6. Co-authored-by: JKRT <jtinnerholm@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…anging The Windows CI test job hung silently for the full 90-minute timeout: the build precompiled fine, but `Run tests` emitted "Running tests..." and then nothing. That signature is a blocking modal dialog (Windows Error Reporting) from a failed DLL load or a segfault in an external Modelica C function (the ModelicaCallbacks shim is unavailable on Windows) — the headless runner can't dismiss it, so the job stalls until it is cancelled. Call SetErrorMode(0x8003) at the very top of runtests.jl on Windows so such a failure surfaces as a visible crash/error in the log instead of an invisible hang. This is also diagnostic: the next run will show the actual failing test rather than timing out in silence. Co-authored-by: JKRT <jtinnerholm@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The Windows build precompiles fine, but `using OMBackend` in the test process still failed to load Glib's libgio-2.0-0.dll. The in-module `import Plots` fixes the order at precompile time, but the package __init__ order when LOADING the precompiled OMBackend is not guaranteed, so on the CI runner OMRuntimeExternalC's bundled libintl-8.dll loaded first and broke Glib. Preload Plots at the very top of runtests.jl (the test entry script runs in order), before `using OMBackend`, so Glib's gettext is resident before OMRuntimeExternalC loads. Could not reproduce locally (the __init__ order happens to work here), so this is verified on CI. Co-authored-by: JKRT <jtinnerholm@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
SVAGEN26
added a commit
to SVAGEN26/OMBackend.jl
that referenced
this pull request
Jul 2, 2026
Rebuilt on current master (the previous branch was based on a pre-dev-fix OMBackend, so master's src — including the new src/precompile.jl from OpenModelica#77 — was never brought to standard, and the license check failed on the merge). - .github/workflows/check-license.yml: runs check_julia_license.py on src per PR. - .CI/scripts/check_julia_license.py: the checker (Julia #= =# headers, OSMC-PL 1.8 + current year), plus julia-license-exceptions.txt. - .gitignore: negate /.CI/ (the `/.*` rule was silently excluding it). - Bring all 51 src/*.jl to the OSMC-PL 1.8 header (was a mix of missing and 1.2). src/CodeGeneration/mtkExternals.jl is excluded — vendored MIT ModelingToolkit code — and left untouched. Verified: check_julia_license.py --summary src -> PASSED (51 checked, 1 skipped). All modified .jl files still parse under Julia 1.12. Co-authored-by: JKRT <jtinnerholm@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Attempting to fix the slow precompilation issue on windows