Introduction & Interest in Julia Reference Implementation (GSoC 2026)

[avinxshKD]

Hi @mvk2, @rahuljagwani1012, and @pradeeban,

I’m Avinash, a developer with experience building end-to-end systems. I’ve been following the project closely and caught the recent discussion in #172 regarding the Julia implementation. It’s great to see the communication layer and file-watching logic already taking shape.

I’m very interested in contributing to the 350-hour Julia reference implementation for GSoC 2026. Given my background in building end-to-end systems, I want to help expand the core logic beyond just the communication layer.

I’ve been looking through the Python source, specifically how the GraphML workflows are handled in concore-lite. I’m interested in exploring how to port these to native Julia structures using multiple dispatch to ensure we get the performance benefits Julia is known for.

Are there specific modules or existing Python examples you’d prioritize for the Julia implementation? I'd love to start prototyping a "Julia-fied" version of the control logic or the parser to share with the community soon.

Looking forward to hearing your thoughts

Best regards,

Avinash

[pradeeban]

@avinxshKD There is no prioritization. If you like to implement something during the application period, you are free to start from whatever that is easy for you. For the GSoC coding period itself, crucial features should be implemented. You could check with the C++ and Verilog implementations as a start.

[avinxshKD]

Thanks for the guidance, @pradeeban. That makes sense, hve started digging into the C++ and Verilog source.

I'll share a link to my progress once I have a working demo ready for feedback....Thanks

[pradeeban]

Sounds good!

[avinxshKD]

Hi @pradeeban,

Following up, I've pushed my initial prototype here:
https://github.com/avinxshKD/concore-jl

Current implementation includes:

GraphML workflow parsing — load_graph() extracts node definitions with PID parameters
PID controller execution — Type-stable execute_step() with state management
File-based communication — read_input(), write_output(), unchanged() mirroring concore's IPC pattern
FileWatching integration — watch_and_execute() for reactive triggers

I've started reviewing the C++ and Verilog implementations as you suggested. Should I prioritize aligning with the C++ protocol handling, or focus on expanding the GraphML workflow engine first?

Happy to get feedback on the approach, thanks

Screenshots demonstrating the prototype in action. So far, hve invested approximately 20–25 hours into this initial prototype. And I’m excited to continue contributing further.

[pradeeban]

awesome!

[avinxshKD]

@pradeeban hve started reviewing the C++ and Verilog implementations as you suggested. Should I prioritize aligning with the C++ protocol handling or focus on expanding the GraphML workflow engine first?

Happy to get feedback, thanks

[pradeeban]

@avinxshKD I think, following the current implementations in C++ and Verilog is a good start. Just to get the core working first. Just to note: This is a comment about the actual coding period. You are not expected to code during the application period.

[avinxshKD]

Hey @pradeeban, @Rahuljagwani, and @mayureshkothare, recently shipped copy/paste feature for nodes in editor as discussed (ControlCore-Project/concore-editor#349), wanted to drop a note on where I'm at with the Julia implementation too.

I've been digging through the concore codebase, touched and made impact in C++ headers, Python core, Docker tooling, CI pipeline, the React editor, etc and I'm currently prototyping the Julia implementation. Core API is working, read, write, initval, unchanged, tryparam, default_maxtime..... matching the canonical signatures, with cross-language interop tests passing against Python's wire format.

A few things I ran into and the decisions I made. Would appreciate your thoughts on whether these align with where you want the project to go:

1. No eval anywhere, Julia doesn't have literal_eval the obvious alternative (eval(Meta.parse())) is arbitrary code execution on data from other processes. I wrote a safe regex-based parser instead. Non-negotiable imo, but wanted to flag it.
2. concore_read/concore_write naming to avoid clashing with Base.read/Base.write. Alternative is forcing Concore.read() everywhere. Any preference?
3. Kept mutable module globals for simtime, delay, etc. same layout as Python/C++. Fighting that pattern just adds abstraction nobody needs. Protocol is built around shared state, implementation should reflect that.
4. Wire format precision- Julia's float formatting doesn't match Python's str() by default. Handled it explicitly so cross-language studies don't silently break.
5. Protocol logic separated from app logic Concore.jl is stdlib-only, zero deps. GraphML/PID stuff lives in a separate utils module.

For GSoC, the roadmap I have in mind: ZMQ transport (behind the same read/write interface), shared memory via Mmap.jl for co-located nodes, proper benchmarks (Julia vs Python, file vs ZMQ, measured not estimated), a full concore study with a Julia node swapped in, and Docker support.

On the usability side, the single biggest friction point I hit setting up concore on Windows was the inpath/outpath directory structure. A first-run validation script would save people real time. For the editor, live visibility into which nodes have written vs which are still blocking would make debugging multi-process studies much less painful.

One more thing I wanted to ask, as I worked on a project with Julia in 2025. Worth including that in the proposal as prior Julia context ?

Does this direction make sense? Happy to adjust based on your priorities.