-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intermediate Representation #20
Comments
How it started: rendering Jinja Ok, jokes aside, now. |
Thanks @sdesrozis I now have a clear picture of it. So, we are going to provide building blocks within a graphical tool, right ? |
I think that is quite original. IMO, we need a common representation (IR) for both templates and graphical tool. You are working on the code generator. Really interested to hear you about that when you would have thought about it. |
@sdesrozis I sent an invite for our next team meeting |
I'm full on Wenesday 24th... |
We are currently thinking about a visual representation of building blocks composing an application : PyTorch objects, handlers, metrics, engines, etc. The idea is to provide a graphical helper to organise events and dataflow. In my knowledge, it is an original approach that could be complementary to our code generator (from templates).
To do this, the visual representation (from a graphical tool, in the spirit of PyFlow https://github.com/wonderworks-software/PyFlow) should be described in a specific representation used by a code generator. This representation could be similar to the intermediate representation (IR) used in compilation (e.g llvm, gcc). It helps optimisation, and code generation.
I wonder about merging our effort to have a unique representation. I mean
What do you think about that ?
Some insights
The text was updated successfully, but these errors were encountered: