-
-
Notifications
You must be signed in to change notification settings - Fork 319
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
Data flow similarities and gui assistance #116
Comments
This sounds interesting! Can you fill in a bit more detail about how this might work, or what it might look like? |
Hey. Thanks for showing interest in this concept. Also thanks for Sprite - i love to see this more evolved way of thinking about things instead of just accepting the status quo way of looking at things. This area is a big area. Its also a bit abstract to developers, but i will try to describe my take on this area. It's only my opinions of course, and there are many different approaches to data flow. DataFlow / Pipelines have been used for graphics for a long time to allow non developers to build things. https://nodes.io/story/ is a high level summary. There are a zillion links i could give you. FBP is also one of them, and the No-FLow implementation. Script is very very simple and i think thats why its so powerful. Just files and readers and writers with a streaming buffer. There is no CLI or GUI. I would favour a golang WASM GUI, rather than a CLI because if you were building a Web app, the Script GUI could be in the left pane and the Web app in the right pane. You get immediate feedback with no context switching. You can operate on files in the browser OR , remotely. https://github.com/hack-pad/hackpadfs does this, allowing a FS in the browser, on a disk or in S3. It's a slightly different API but not too bad. Then you can built systems where part of the computation is in the browser and part is remote, which opens up the idea of collaborative computing with a microservices pattern. I am very happy to talk about this and other stuff around this if you want. |
Yes, this sounds really cool! Why don't you go ahead and prototype something for us to look at? I for one would be very interested. |
I think CueLang would be a good way to do this. Script is the pipes between the different CueLang modules. |
I'm all about the CUE! Looking forward to seeing what you come up with. |
Bret Victor - Drawing Dynamic Visualisations https://www.youtube.com/watch?v=ef2jpjTEB5U Cue can be used as a type and value system at runtime for the stream that describes the gui. Because its runtime changeable you dont have to compile. Essentially data driven gui and compute ... Sort of like a CMS but deeper in that it described every vector pixel. |
Sorry, @gedw99, but it's still not clear to me exactly what you're proposing. Can you elaborate? |
Pipelines remind me of data flow systems and the node based editors often provides with them.
Bubbletea would provide the ability to create and edit the scripts by simple parsing the text of the pipeline and then allow you to adjust it and then save and run it.
while the tui is running you can “debug” it by stopping it on a node . You can also hover a node to see the data flowing through it to see the data changing .
Wondering what others thing of this
i have written similar things in golang as both gui and tui and Script seems like a great base from which to extend to an visual editor and debugger .
being pure golang the editor can be part of the same script program too so it’s still just a single binary .
The text was updated successfully, but these errors were encountered: