SY-3495: Refactor Arc to Support a Module-Based STL#1954
SY-3495: Refactor Arc to Support a Module-Based STL#1954
Conversation
…s-in-arc' of https://github.com/synnaxlabs/synnax into sy-3572-add-mechanisms-for-setting-control-authority-in-arc
Fix issues with the metrics groups appearing twice. This happened because if you moved the metrics channels to another group, and then restarted the Core, the original Metrics -> metric_channel ontology relationship would reappear.
…synnax into sy-3572-add-mechanisms-for-setting-control-authority-in-arc
…2-add-mechanisms-for-setting-control-authority-in-arc
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## rc #1954 +/- ##
==========================================
- Coverage 53.51% 53.48% -0.04%
==========================================
Files 2406 2424 +18
Lines 138508 139529 +1021
Branches 7106 7111 +5
==========================================
+ Hits 74121 74624 +503
- Misses 62582 63059 +477
- Partials 1805 1846 +41
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…2-add-mechanisms-for-setting-control-authority-in-arc
…-arc' of https://github.com/synnaxlabs/synnax into sy-3495-arc-modules
34bbadf to
aa26abd
Compare
…opposed to using sub-classes
pjdotson
left a comment
There was a problem hiding this comment.
Generally good, I like the syntax. Needs to be better tested + some concerns about the exponent function.
| @@ -0,0 +1,464 @@ | |||
| # Arc Module System Specification | |||
There was a problem hiding this comment.
what should and shouldn't get committed for working docs like this in terms of Markdown
files? Don't think we should be committing 4 markdown files for every significant PR but
also support having better documentation at this level (IE the existing RFCs).
| @@ -39,7 +38,7 @@ type Context[ASTNode antlr.ParserRuleContext] struct { | |||
| func Child[P, ASTNode antlr.ParserRuleContext](ctx Context[P], node ASTNode) Context[ASTNode] { | |||
| @@ -63,25 +62,30 @@ func (c Context[AstNode]) WithScope(scope *symbol.Scope) Context[AstNode] { | |||
|
|
|||
| func (c Context[ASTNode]) WithNewWriter() Context[ASTNode] { | |||
| return c | ||
| } | ||
|
|
||
| func CreateRoot( |
| // Resolve looks up a symbol by qualified name. If the name has the prefix | ||
| // "Name.", it strips the prefix and delegates to Members. Otherwise it returns | ||
| // query.ErrNotFound. | ||
| func (m *ModuleResolver) Resolve(ctx context.Context, name string) (Symbol, error) { |
| public: | ||
| explicit Module(runtime::errors::Handler handler): handler(std::move(handler)) {} | ||
|
|
||
| void bind_to(wasmtime::Linker &linker, wasmtime::Store::Context cx) override { |
| #include "arc/cpp/stl/series/state.h" | ||
| #include "arc/cpp/stl/str/state.h" | ||
|
|
||
| namespace arc::stl::stateful { |
| #include "arc/cpp/stl/stl.h" | ||
| #include "arc/cpp/stl/str/state.h" | ||
|
|
||
| namespace arc::stl::stateful { |
| std::unordered_map<uint32_t, x::telem::Series> handles; | ||
| uint32_t counter = 1; | ||
|
|
||
| public: |
| void Module::bind_to(wasmtime::Linker &linker, wasmtime::Store::Context cx) { | ||
| auto ss = this->series_state; | ||
|
|
||
| #define BIND_SERIES_OPS(suffix, cpptype, data_type_const) \ |
Issue Pull Request
Linear Issue
SY-####
Description
Basic Readiness
Greptile Overview
Greptile Summary
This PR refactors ARC (Go + C++ runtimes, compiler, and service integration) to use the new module-based API, updating WASM bindings, runtime state layout, STL module registration, and symbol resolution wiring.
Main correctness issue found is in the framer calculation path:
Calculator.Nextwas updated to use the newstate.Channel.Flush, but it no longer clears the transient series/string handle stores each cycle (previously done bystate.Flush()). The ARC task runtime path does clear these stores, so the calculator path should match to avoid handle accumulation and leaks when WASM code uses series/strings.Confidence Score: 4/5
Calculator.Next, which can leak/accumulate handles for WASM programs using those facilities. Other reviewed integration points (task runtime, module open, state split) align with the new API patterns.Important Files Changed
Nextnow usesstate.Channel.Flushbut misses clearingstate.Series/state.Stringstransient stores each cycle (bug).state.Series.Clear()andstate.Strings.Clear()and flushes authority changes.STLModules) and state; non-test callers pass state; no definite issues found.Sequence Diagram
sequenceDiagram participant Calc as Calculator participant Ch as state.Channel participant Sch as scheduler.Scheduler participant Mod as wasm.Module participant Ser as state.Series participant Str as state.Strings Calc->>Ch: Ingest(input) loop while output changed Calc->>Sch: Next(ctx, since(start), ReasonChannelInput) Sch->>Mod: Execute node graph (WASM) Mod-->>Ser: Allocate/update series handles Mod-->>Str: Allocate/update string handles Calc->>Ch: Flush(outFrame) Ch-->>Calc: (outFrame, changed?) end Calc->>Ch: ClearReads() Note over Calc,Ser: BUG: Series.Clear() not called Note over Calc,Str: BUG: Strings.Clear() not called rect rgba(200,255,200,0.25) Note over Calc,Ser: Expected each cycle Calc->>Ser: Clear() Calc->>Str: Clear() end