Conversation
The hand-rolled Unix linker flags (-Wl,-rpath,... -L... -l...) broke the Windows CI build, since the MSVC cl.exe compiler does not understand that syntax. NCrystal_process.comp and Many_meshes.instr already use @NCRYSTALFLAGS@ for exactly this reason; switching to it here makes the flags platform-independent as suggested by P. Willendrup. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…tically
write_browse() no longer shells out to `npm run dev` (Vite dev server) to
view a trace - dist/ is a self-contained, hashed Vite production build, so
the stdlib ThreadingHTTPServer serves it directly with no Node/npm/vite
runtime dependency and no per-launch startup cost.
This removes the whole per-user ~/.mcstas/<ver>/webgl deployment: no more
node_modules symlink/junction, no start-vite.js, no first-launch
npminstall requiring internet access. mcdisplay.py now always reads dist/
from wherever it's installed (conda env or dev checkout) and only builds
it once, in place, if it's ever missing.
npminstall(.bat).in simplified to match: build directly next to the
source files instead of copying everything into a per-user folder first.
CMakeLists.txt: drop the empty node_modules install and start-vite.js
(unused now); add model/, vite.config.mts, tsconfig*.json so the fallback
`npm run build` matches a real dev build; drop nodejs/npm/rsync as a
package runtime dependency, since dist/ ships pre-built.
vite.config.mts: remove the vite-plugin-static-copy step - it pointed at
placeholder paths ("path/to/particles.json") that never existed as real
files, and was always dead since vite.config.mts was never previously
shipped to end users. instrument.json/particles.json are per-run outputs
write_browse() already writes directly into the served directory.
package.json: move build-only packages (vite, @vitejs/plugin-react,
@types/*) into devDependencies; drop the now-unused
vite-plugin-static-copy dependency.
Verified end-to-end on macOS: cold `npm install && npm run build` from
exactly what CMakeLists.txt now ships, served via the new stdlib server,
and a real instrument trace through mcdisplay-webgl.
mcdisplay-webgl: drop Vite/npm from the runtime path
…lator Add Union_abs_logger_nD_scintillator component and test instrument
Create SOLEIL_SIRIUS.instr
(use platform-specific @XRLFLAGS@ to inject an xraylib/ folder if required, see cmake/Modules/PlatformDefaults.cmake if needed)
…_fix Fix Conics display and particle trace parsing
…orkaround nvc >= 26.5 Monitor_nd workaround
…gravity PROP_NO_G_ functions
PR to include Soleil samba
PR to include Soleil sirius
I'll look at mcdoc's doc-string parsing in your McCode checkout and make a minimal fix. The parsing lives in `mccodelib/utils.py`; let me look at `parse_header`. Now a quick check against a synthetic header with a wrapped parameter description. Copy-over failed, so I'll exercise the patched loop verbatim in the workspace. mcdoc now joins parameter descriptions that wrap over several lines into one description, so they show up in full in the HTML, Markdown and LaTeX output. Before this, everything after the first line was silently dropped. The fix is a 9-line addition to `parse_header()` in `tools/Python/mccodelib/utils.py`, which is where mcdoc reads the file headers. `mcdoc.py` itself is unchanged. - **How it works:** after a `name: [unit] text` line, any following non-blank line is added to that parameter's description. Joining stops at a blank line, a `%` tag, a `/` line, or the next parameter. - **What stays the same:** headers with only single-line descriptions parse exactly as before. - **Testing:** I ran the new loop on a sample header with a three-line description, and it came out as one joined description. I couldn't copy `utils.py` into my workspace, so I tested a copy of the loop rather than the file itself, and haven't run `mcdoc` on your machine. A wrapped line that starts like a new parameter (for example `Note: see below`) is still read as a new parameter entry. That's how the parser already worked, and I left it alone to keep the change small.
…-docstrings Tiny mcdoc change for mcdoc to parse multiline parm-docstrings.
Ai driven doc header updates and CI-improvements
* mcxtrace: SOLEIL: add PUMA BL * X: PUMA: add target test value * AI-drafted input descriptions/doc-strings * Only use single-line parameter doc strings --------- Co-authored-by: Peter Willendrup <pkwi@fysik.dtu.dk>
DOC and Manual refresh branch: Finalize here and merge before release
Update RELEASE_NOTES.md
Update RELEASE_NOTES.md
…-autobuild Safeguards to ensure a more stable cross-compile path for 'Windows bundles'
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
11 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.
Free-form text area
Please describe what your PR is adding in terms of features or bugfixes:
Declaration of use of AI-tools
Development OS / boundary conditions
Please describe what OS you developed and tested your additions on, and if any special dependencies are required:
PR Checklist for contributing to McStas/McXtrace
For a coherent and useful contribution to McStas/McXtrace, please fill in relevant parts of the checklist:
My contribution contains something else