[pull] master from GaijinEntertainment:master#975
Merged
Conversation
The MCP tools list_module_api, describe_type, and eval_expression took a module-name parameter but failed when given a single-token name like "ast" because there is no top-level `ast` module — it lives at `daslib/ast`. Even the tools' own descriptions used "ast" as an example. On compile failure when the supplied name has no `/`, retry once with `daslib/<name>` prepended. Successful retries prepend a `[resolved 'X' as 'daslib/X']` line so the rewrite stays visible to the caller (and typos like `mat` still surface as plain errors, since `daslib/mat` doesn't exist either). Also fix all pre-existing lint warnings in the touched files (LINT003 var→let, PERF007 string(das_string)==, PERF017 length>0, STYLE016 mergeable guards) per upcoming PR-gate policy. Tests added: rewrite + already-qualified no-rewrite cases for each of the three tools. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…wrap_up skill Bugfix ------ findModuleCallMacro deref'd the result of Module::findCall without null-checking. For unregistered call_macro names this crashed with EXCEPTION_ACCESS_VIOLATION. Add the null check; find_call_macro is now a safe soft-probe that returns null on miss. Macro regression coverage (tests/macro_call/) --------------------------------------------- - test_find_call_macro_null - covers the bugfix above - test_dyn_register_call_macro - function_macro that registers a per-decl call_macro instance from inside its apply() - test_call_macro_emit_gate - call_macro that gates add_variable on a find_variable miss (auto-emit module global, idempotent) These tests pin three patterns the dasImgui [widget] macro relies on; breaking any of them would silently regress dasImgui's call dispatch. Task wrap-up skill + MOUSE FIRST hard rule ------------------------------------------ - New skills/task_wrap_up.md - blind-mouse curation pass for any major task wrap, not just PRs. Three steps: review log, surface the un-asked, cost calculus. - skills/make_pr.md section 5.5 collapsed to a pointer at task_wrap_up.md. - CLAUDE.md gains a row in the skill table and a "MOUSE FIRST (hard rule)" section at the bottom: mouse__ask is the first tool on any pattern/why/how question, before Explore/Grep/Read. Plus 9 mouse-data/docs/ entries seeded during dasImgui Phase 0a: reload firing-order, C++-resource preservation across reload, ImGui backend-data-survives-ctx-roundtrip, plus six macro / daspkg patterns surfaced during the same session. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…fallback mcp: auto-retry unqualified module names under daslib/
…bugfix-and-coverage fix: find_call_macro null-deref + macro_call regression tests + task_wrap_up skill
…in linux_arm CI build.yml no longer uploads `daslang-<platform>-<arch>.zip` (release.yml is the sole release publisher) — also kills the empty-name `daslang--.zip` that sanitizer rows produced via clobbering uploads. linux_arm Release in build.yml now enables `dasHV` and `dasSQLITE` to mirror release.yml's module set, so the LLVM AArch64 SelectionDAG hang seen in the v0.6.2-RC2 release run reproduces in regular CI. The linux_arm test step drops `--failures-only` on JIT so PASS lines name each test as it finishes — the file running just before the hung one will be the last PASS printed. Also threads the five post-RC2 PRs (#2611, #2612, #2614, #2616, #2617) into CHANGELIST.md and the site/index.html change list, with a May 9 News entry. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…llowup ci: stop publishing non-bundled release zips; mirror release modules in linux_arm CI
…0.6.2-RC3 The `linux_arm × arm64` exclude at release.yml:125-126 was dead matrix overlap — the active linux ARM64 release build is the `linux_arm × 64` cell (which maps to `release_arch: arm64`). Remove the redundant exclude. Add a May 9 News entry pointing at v0.6.2-RC3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…omment Removing the exclude in dcb0b11 was a mistake — the cell has no valid build path. The linux_arm target's runner is already ARM64 hardware (ubuntu-24.04-arm-fat) and the linux_arm × 64 cell produces release_arch: arm64 via the include block. The ×arm64 cell would fall through to the *) case which applies -DCMAKE_OSX_ARCHITECTURES with no architecture_string — invalid on Linux. Restore the exclude with a comment so this doesn't get "cleaned up" again. v0.6.2-RC3 still shipped daslang-bundle-linux-arm64.zip (from the linux_arm × 64 cell, which passed); fail-fast: false kept the parallel cells alive when the bogus one failed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…oot cause Earlier comment guessed at CMAKE_OSX_ARCHITECTURES being the breakage — that's harmless on Linux. The real reason from RC3's failed cell log: the install-deps step at L147 gates apt-get on `linux64|linux_arm64`, which doesn't match `linux_armarm64` (target+architecture concat for the ×arm64 cell). The cell skipped apt-get entirely → no OpenGL libs → dasGlfw find_package(OpenGL) failed at configure. Updated comment so the next person reading this knows what would actually need to change to enable the cell. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…clude rationale Install-deps gate widens from `linux64|linux_arm64` to `linux64|linux_arm*`. Defensive future-proofing: the linux_arm × arm64 cell stays excluded, but if anyone lifts that exclude they don't trip on missing OpenGL deps the way RC3 did. No behavior change in the current matrix — `linux_arm × 64` already matched the prior pattern. Also rewrites the exclude comment with the actual reason to keep it excluded: the include overlay at L53-57 sets release_arch: arm64 for all linux_arm cells regardless of architecture, so a ×arm64 cell would clobber the same bundle name (daslang-bundle-linux-arm64.zip) on the same ARM64 hardware via gh release upload --clobber. Wasted CI for no extra artifact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ang diagnostic skills/task_wrap_up.md: replace Windows-specific `bin/Release/daslang.exe` with the cross-platform `bin/daslang` form, with a parenthetical for the Windows MSVC layout. Match the convention other skills use. mouse-data/docs: add an answer for "How do I identify which test is hanging when dastest -jit times out in CI?" — captures the diagnostic technique discovered while triaging the v0.6.2-RC2 release-only linux ARM64 timeout (drop --failures-only, the most recent PASS line names the predecessor). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a full C API surface for constructing, populating and passing
array<T> / table<K;V> values across the C boundary, plus tutorial 14
exercising the borrowed-buffer and context-owned ownership patterns.
* das_array / das_table layout in daScriptC.h synced to mirror
das::Array / das::Table exactly (was missing the runtime's `magic`
field, leaving `lock` / `flags` reads at the wrong offsets from C).
Compile-time static_assert(sizeof) + offsetof checks in
daScriptC.cpp now guard against future drift.
* das_context_allocate / _reallocate / _free — main-heap C wrappers
around Context::allocate/_reallocate/free.
* das_array_init / _init_borrowed / _reserve / _resize / _clear /
_at / _lock / _unlock — full array lifecycle from C.
* das_table_init / _reserve / _clear / _find / _insert / _erase /
_lock / _unlock with DAS_TYPE_* key-type dispatch routing to the
existing TableHash<K> instantiations.
* das_argument_array / _table and das_result_array / _table
(aligned + unaligned) for piping pointers through vec4f.
* Tutorial 14 (tutorials/integration/c/14_passing_arrays.{c,das} +
RST) demonstrates: (a) C-owned data via das_array_init_borrowed
with daslang's array<int># temporary type, (b) context-heap-owned
array grown by daslang and read back through das_array_at, (c)
table fill via daslang and lookup via das_table_find.
* tests-cpp/small/test_c_array_table_api.cpp covers the layout
canary, heap, both ownership flavors, lock/unlock, and table
insert/find/erase across multiple key types.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…-tutorial feat: c-api arrays/tables + tutorial 14 (passing arrays from C)
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )