Handle booleans used as temp variables in p5.strands#8548
Merged
davepagurek merged 6 commits intodev-2.0from Feb 23, 2026
Merged
Handle booleans used as temp variables in p5.strands#8548davepagurek merged 6 commits intodev-2.0from
davepagurek merged 6 commits intodev-2.0from
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
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.
Changes:
Usage of temp variables with booleans
Previously, if you made a temporary variable with a boolean value, it would break, e.g.:
I looked into a simple fix first, making all booleans into floats, so that we could make everything go through the same flow. However, the errors we were seeing were actually because we already assumed the variables to be floats. To make the initial error go away, every boolean operator would need to be wrapped in
float(...)to be assignable to a float variable, but NOT when used in an if statement, as we would then get errors due to a boolean value being expected there.Instead, I ended up updating our temp variable creation code to properly handle boolean types.
Usage of helper functions in JS
Another pattern that would break was this:
I thought this was related at first, but it's slightly different: the problem was in the early returns. We handle early returns special inp5.strands, turning them into a
__p5.earlyReturn(val)statement so that we can output an early return node and continue through execution to generate nodes for the other paths too. But because we don't turn js helper functions into GLSL helper functions, early returns in a helper end up returning early in the whole hook.So to address that, I added a step to the transpiler to make sure helpers always evaluate to a single strands node with one return. So the above helper now gets turned into this:
This introduced one new problem I needed to solve:
let returnValuewith no initializer. I made anASSIGN_ON_USEdata type for those nodes, which don't have a real type of their own. Type inference will take the value from whatever else they're operated on.Minor: fix formatting in the transpiler
I noticed that half of the file is indented one too many times randomly. I de-indented that.
This file has become really big as our transpiler has had to do more, at some point it may make sense to refactor that. I think at least our unit tests are pretty decent for strands so that can help us feel confident that we haven't broken something when/if we embark upon that journey.
PR Checklist
npm run lintpasses