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]

[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.

[pradeeban]

1. We do not need a 1:1 mapping between Python:Julia. You can utilize what Julia offers best.
2. Whatever works. Implementation is up to the contributor and you can state your preference in your proposal.
3. Great.
4. Great.
5. ok.

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 ?

Absolutely. And if it is an open-source project, include a link.

[avinxshKD]

Hey @pradeeban @Rahuljagwani @mayureshkothare, just following up, I would really appreciate your views on the direction outlined above. As I'm working on the proposal and bugs/contributions in parallel, so any early feedback would help me prioritize and align things better.
And one more thing, @pradeeban I really appreciate your time and guidance from the start, Thank you 🌸

[pradeeban]

@avinxshKD once you have your proposal draft, pls email it to all 3 of us in a single email.

[avinxshKD]

@pradeeban @Rahuljagwani @mayureshkothare sent the proposal to all three of you.
Would greatly appreciate any feedback or guidance on it :p

Also while writing proposal for project [15], a couple of things came up:

1. On the script generation side, when a generated .bat or shell script fails (bad path, missing compiler), the error gives you nothing useful. Is fixing that with pre-run path/tool validation the priority, or is the goal to move away from shell scripts to a Python subprocess runner entirely? Feels like they solve different problems.

2. On Docker Compose, file-based edges need shared volumes, ZMQ edges need networking. The existing ZMQ examples already mix both. Does concore compose handle that as two separate modes, or one compose file that covers both? Curious how that's meant to scale when a study adds more edge types.

[pradeeban]

@avinxshKD

1. Our layered approach appears neat to me: script -> API (FRI) -> GUI (concore-editor). Feel free to propose approaches to "move away" from the shell scripts. But we did not think about that.
2. I don't think we thought about Docker that far into the distance either. Docker one was implemented when we did not have the 0MQ and shared-memory implementations finalized.

[avinxshKD]

@pradeeban makes sense, thanks for the clarity
I will update accordingly

[hxrshxz]

Following this closely @pradeeban @avinxshKD, happy to help with testing and improvement
We can work together

[avinxshKD]

Hey @hxrshxz appreciate you jumping in. I’ll keep updates concrete and focused on changes we can validate quickly.

[hxrshxz]

Thankyou so much. For long-term direction, I think treat scripts as a thin compatibility layer and move new execution logic into a Python runner. Once feature parity is stable, scripts can be gradually phased down. Happy to know more

[avinxshKD]

Always welcome 😊 and Good take, @hxrshxz tbh that’s exactly the direction I’m planning, keep scripts as a compatibility shell, move real execution into Python, and validate with parity tests before deprecating anything.

[avinxshKD]

Hey @pradeeban I’ve updated the proposal based on your feedback, kept compatibility with the current script => API => GUI flow, and treat mixed transport in Compose as a staged follow-up with clear fallbacks. I’ll keep updates PR-first with reproducible steps and validation notes.

I’ve also kept backend-touching changes in stretch goals (if time permits). Will share the draft soon :P