fix(binary_tree): accept any value as a tree entry - #976
Merged
Merged
Conversation
make_tree declared its entry parameter as DataType.OPAQUE, so the host rejected ordinary values: make_tree(4, None, None) failed with "Expected argument 0 to have type 'opaque', got 'int' or 'float'". - make_tree: entry and branches are now DataType.ANY. The branches were DataType.LIST, which rejects trees round-tripped through Python as DataType.ARRAY; make_tree_func already validates them with is_tree. - entry: returns DataType.ANY instead of OPAQUE. - entry/left_branch/right_branch: accept DataType.ANY, for the same ARRAY reason (assertNonEmptyTree does the real check). - Tests used opaque_make for every entry, which hid the bug; they now use plain numbers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Only the entry parameter of make_tree and the return type of entry were wrong. py-slang and js-slang both accept a DataType.ARRAY where LIST is declared, so the tree parameters did not need widening to ANY. This restores LIST for them. Co-Authored-By: Claude Opus 5.5 <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
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.
Problem
fails with:
make_treedeclared its entry parameter asDataType.OPAQUE. In Conductor, that type means a handle to a host-side object, not "any value", so the host's argument check rejects numbers, strings, etc.entrydeclared its return type asOPAQUEfor the same reason. Both evaluators also check return types, soentry(t)would have failed too. Both have been broken since the Conductor migration (#680).Fix
make_tree: entry parameterOPAQUE→ANYentry: return typeOPAQUE→ANYThe branch/tree parameters stay
LIST. py-slang and js-slang both let a Python/Source list (sent asDataType.ARRAY) through whereLISTis declared.Why tests didn't catch it
handler.opaque_make(...), which is exactly the one case that worked. They now use plainnumberValue(...).index.ts. binary_tree (and matrix, repeat, midi, repl, pix_n_flix, sound) set"experimentalDecorators": false, and vitest can't parse the resulting TC39 decorators. Soindex.tscan't be imported in tests, and no signature test like the one csg/rune have is possible. Fixing that is out of scope here and worth a follow-up.I checked all 215 signatures in the 12 Conductor bundles by reading the code, and found no other signature bugs of this kind.
Testing
yarn testin binary_tree: 19/19 passyarn tsc,yarn lint(one existing jsdoc warning),yarn build: clean🤖 Generated with Claude Code