Repository navigation
Standardize Workflow by Supporting GraphML Extracted Directly from Images (PNG/JPG) #537
Description
Currently, concore explicitly requires a standalone .graphml file to process the architecture.
If a user wants to build a study from an embedded image (which naturally acts as self-documenting code), they have to manually extract the GraphML or manually save multiple versions of their architecture.
Benefits are:
- Better Developer Experience: Users can drop an embedded PNG/JPG and then run makestudy.
- Eliminates the necessity to keep identical visual copies (PNG) and parser instructions (GraphML) artificially separated, preventing desyncing.
- Easier sharing
@pradeeban @Rahuljagwani @mayureshkothare , I have already implemented import/export feature of embedded images (.graphml.png or .graphml.jpeg) in concore-editor few days ago, This can be considered a step further to make concore studies out of those embedded images
Activity
pradeeban commentedon Apr 5, 2026
Ok, makes sense. Previously we didn't have the concept of an embedded image in concore.
GREENRAT-K405 commentedon Apr 6, 2026
@pradeeban @Rahuljagwani @mayureshkothare , the concore right now is mostly based on monolithic structure, like concore.py or concore.cpp (there is concore_base) but still concore scripts mostly act as standalone engine.
I wanted to try giving our entire repo an proper library structure (I have proposed this in my proposals also)
for example this could be one of the structures:
concore/
└── lib/
├── python/
│ └── concore/
│ ├── pyproject.toml # Language-specific config/build metadata
│ └── src/ # All decoupled functional logic
│ ├── concore.py # Primary user-facing client API
│ ├── concore_base.py # Base simulation logic and inheritance engine
│ ├── concoredocker.py # Container integration & execution runner
│ ├── io.py # Input/Output data parsing and validation
│ ├── params.py # Configuration parameters and environment loading
│ ├── ports.py # Input and Output port handling (iport, oport)
│ ├── shm.py # Shared memory interactions and buffer management
│ ├── state.py # Concore state lifecycle, transitions, and tracking
│ └── zmq.py # ZeroMQ messaging layers and network throughput logic
│
├── cpp/
│ └── concore/
│ ├── CMakeLists.txt
│ └── src/ # (Contains equivalent submodules: io.cpp, zmq.cpp...)
│
├── java/ # Java ecosystem equivalents
├── matlab/ # MATLAB ecosystem equivalents
├── julia/ # Julia ecosystem equivalents
└── ...
If you think this is a great idea please let me know, I can start working on it and do time to time discussion with you regarding it.
These are my points:
GREENRAT-K405 commentedon Apr 10, 2026
@pradeeban, should I raise a PR for a sample structure? I can try this for python.
GREENRAT-K405 commentedon Apr 10, 2026
My aim is not to replace the existing structure right away. We can start creating this more organized and standard libarary structure for all the languages one by one and then decide the further steps during actual coding period?
pradeeban commentedon Apr 10, 2026
That sounds more appropriate for GSoC coding period for the usability enhancements project.
GREENRAT-K405 commentedon Apr 10, 2026
That makes sense @pradeeban sir, structuring this during the GSoC coding period would allow us to approach it more systematically instead of introducing a large structural change prematurely.
In the meantime, I’ll continue exploring the current architecture and documenting areas where modularization could help. This way we can have a clearer roadmap of components that could be separated cleanly when we start working on usability improvements.
I also have a few related ideas around improving the internal structure and developer usability, so I’ll bring them up gradually for discussion with you and the other mentors.
Thanks for your guidance! :D