Conversation
Change where windows esp build looks for esp tools.
…PocoMakePixel* macros
Collaborator
|
Tnanks, looks good. I believe examples/drivers/HMC5883L/main.js needs to be updated in the call to the SMBus constructor. Additionally, it would be good to update the I2C constructor docs in pins.md. |
Smoke tested with: - examples/drivers/BMP180 - examples/drivers/HMC5883L - examples/drivers/lis3dh - examples/drivers/mcp23008 (existing and new feature branch) - examples/drivers/mcp23017 (on new feature branch)
I created these while testing the examples and thought it might benefit others to share them.
Contributor
Author
|
@phoddie updated! |
Collaborator
|
Looks great. We'll get these merged (Big thanks for the two manifests - I haven't had a chance to dig those components out recently to put those together) |
mkellner
pushed a commit
that referenced
this pull request
Dec 1, 2021
kriscendobot
added a commit
to kriscendobot/moddable
that referenced
this pull request
Jun 30, 2026
`fx_Array_prototype_flatAux` pushed each per-element mapper result (and each nested sub-array) onto the value stack and never popped it before the next iteration. Once an element is defined into the heap-allocated result array (`mxDefineIndex`, which writes into `mxResult` and pops only the result-array reference), or once a nested array has been fully flattened into the result, its value-stack slot is dead weight: it is already reachable from the result array, so it no longer needs a stack root. Leaving it resident makes peak value-stack use O(flattened output length) instead of O(depth). Add a single `mxPop()` at the end of each iteration to drop that dead slot, mirroring `fx_Array_prototype_forEach` (which already pops every iteration and is therefore O(1)). The result is still constructed entirely on the heap; we just stop spreading the inputs across the stack while building it. This is GC-safe: an element is popped only after `mxDefineIndex` has stored it into the result array (heap-rooted), and a nested array is popped only after the recursive `flatAux` has copied its leaves into the result; during the recursion the sub-array stays on the stack as the recursion source, so it is rooted throughout. Motivation: a real Agoric contract upgrade import overflowed the xsnap value stack (fixed stackCount=4096) at `@agoric/internal/src/hex.js`'s top-level `new Map(encodings.flatMap(...))` (256x4 pair-arrays left ~1232 slots resident). With this fix the same import completes at the stock 4096-slot stack. Investigation: kriscendobot/garden#9 and Moddable-OpenSource#17.
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
6 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.
Smoke tested with: