Git Product home page Git Product logo

shenzhen-go's Introduction

"SHENZHEN GO" (working title)

Doc Status license

โš ๏ธ WARNING: This repository is currently unmaintained, and the project is not being worked on.

SHENZHEN GO (working title) is an experimental visual Go environment, inspired by programming puzzle games such as TIS-100 and SHENZHEN I/O.

SHENZHEN GO provides a UI for editing a "graph," where the nodes are goroutines and the arrows are channel reads and writes. (This is analogous to multiple "microcontrollers" communicating electrically in a circuit.) It can also convert a graph into pure Go source code, which can be compiled and run, or used as a library in a regular Go program.

SHENZHEN GO was unveiled at the linux.conf.au 2017 Open Source & Games Miniconf.

Read more at https://google.github.io/shenzhen-go.

Example Graph

Getting started

See the getting-started guides at https://google.github.io/shenzhen-go.

...for the impatient gopher

Choose one of:

git clone https://github.com/google/shenzhen-go && cd shenzhen-go && go install
git clone https://github.com/google/shenzhen-go && cd shenzhen-go && go install -tags webview
go get -u github.com/google/shenzhen-go
go get -u -tags webview github.com/google/shenzhen-go

Notes

This is not an official Google product.

This is an experimental project - expect plenty of rough edges and bugs, and no support.

For discussions, there is a Google Group and a Slack channel.

Acknowledgements

This project wouldn't be nearly as good as it is without the following:

shenzhen-go's People

Contributors

baptr avatar dmitshur avatar drjosh9000 avatar gingerhot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

shenzhen-go's Issues

Parts shouldn't be able to change type

Parts of different types aren't expected to be convertible to one another. Such conversion will usually be lossy. Remove the dropdown for changing part type.

Type changes should be restricted to either nothing, or to Code type (new part's Code = old part's Impl).

dev: UI overhaul

I'm looking into Polymer - seems to allow nice separation between view and API?
Though I'm not much of a frontend coder (yet).

Write & post a design doc

Lack of a doc actually laying out the vision is bad enough to be a bug.
I have one I've been writing, just needs polishing and releasing.

dev/model/parts: Add more parts

More ideas:

  • Broadcast
  • Function (out <- f(<-in))
  • Map (out <- m[<-in]) - statically defined map? Ability to load from a file?
  • Static input

More specific parts:

  • HTTP server
  • File input
  • File output
  • Database I/O

Choreography

This is a bit out of left field but you know how you link the mini executing programmes, well I reckon it's begging for a event bus with topics.

At design time you have to wire your pins together. That's orchestration pattern and is a dead end.
Better to use a choreography pattern and at design time just have a file to describe the things pins subscribe to, and those things are topics. This way no components know about each other and the design scales out at design time. You can then change the wiring at runtime also.

Happy to discuss these ideas. I use them for all other projects and it's well know enterprise pattern so you don't end up in a architectural design cul-de-sac.

Google orchestration versus choreography..

dev/model/parts: Add a part type that can launch a func in an existing file

It'd be nice to edit code in a preferred text editor, and take control of the full contents of a file. This part type should, given a Go source file in the target package and a function name, can infer the pin definitions from the function arguments, and update itself (inotify?) when the file changes.

Channels should be more like cattle, less like pets

๐Ÿšจ Self-directed rant. ๐Ÿšจ

I think the model of channels (and how they're used) has to change before progress can be made on what I think is a major feature - visually observing runtime behaviour.

The current model of creating every channel and giving it a name makes sense if you understand the code coming out the other end, but I can't think of another visual system that does it this way. Referring to the inspiration for this project, SHENZHEN I/O, it has circuit traces (channels) which are anonymous, and connect parts which identify communication via the pin it is communicating on.

I originally thought this low-level approach leads to confusion (pin x0 on one part goes to x3 on another ...) so pressed on with letting the user give each channel a name and having it magically detect channel usage (by parsing the user's Go, go/parser, go/types). It's clever, but not clever enough. SZ-GO would have to get into the business of statically analysing and rewriting other people's code much more precisely in order to progress.

To explain: This is important for what I'm calling "smart channels" - visualising what is passing through a channel at runtime. To do that the channel has to be swapped at build time for some kind of weightier structure that intercepts channel communication, e.g.:

type smartChannel struct {
	in, out chan interface{}   // Could generate these smart channel types with a template, to handle specific value types.
        // Other fields for tracking statistics.
}

// Run in a separate goroutine:
func (c *smartChannel) Track() {
	for x := range c.in {
		// Accumulate information to display here.
		c.out <- x
	}
	close(c.out)
}

but for this to work, analysis is required for knowing whether to swap each usage of a channel identifier with smartChannel.in or smartChannel.out. It's simple if it is all one of <-, close, or range - the current code works great for those cases. But it doesn't handle channels passed through function arguments or fields. There's also this potential case:

// Third-party package:
func SomeoneElsesCode(info chan interface{}) {
     x := <-info
     // do something
     info <- y
}

// An SZ-GO program:

var info = make(chan interface{}, 0)

// This channel gets exchanged at build-time for:
var info = &smartChannel{ ... }
// in order to visualise information flowing through "info".

go func () {
    // The user wrote in some goroutine:
    ...
    SomeoneElsesCode(info)
    ...
}()

It can't substitute SomeoneElsesCode(info) for both SomeoneElsesCode(info.in) and SomeoneElsesCode(info.out) simultaneously - that's impossible. It could handle it by reparsing and rewriting SomeoneElsesCode but that seems to be too unreasonable - to go that far probably needs compiler changes (or something on the order of compiler changes). And if the compiler is being changed, why not just change the standard channel implementation to implement smart channels? Either way feels like dangerous territory for a spare-time project :-)

It is comparatively much easier to simply lock down whatever channels are being used, and how they are used:

  1. Declaring the "real" channels hidden inside the main/Run function rather than as package variables.
  2. Every goroutine, which today is pasted into an anonymous goroutine function in main/Run, becomes a standalone function with read- or write-channel arguments, e.g.
func myExampleGoroutine(in <-chan int, out chan<- string) { ... }
  1. Goroutine invocation in main/Run passes in the channels and calls the function.

The upside to this is most of the existing channel extraction and renaming business just goes away. Various UI bits could be easier to implement too.

The downside with this proposal is that the user has to declare channel usage at both ends. If everything is a Code part, that's as many as 2 channel declarations (as arguments) per channel (value), i.e. twice the work for the user compared to the current scheme.

Ideas.....

The dev version works well. Its quite fun too to kind of visually code.

I have some ideas and i am kind of allowed to because i used to do a fair bit of Generative Design for Code and Architecture...
Also its great to see someone being brave enough to try this...

Brain dump .......

  • grasshopper is the merge of coding and 3D Design and has a runtime display of the channels. The output of the channel can be done with a mini excel spreadsheet type of widget. Also Victor has a similar demo ( cant remember his last name but he is a Design UX god in the world of Parametric software). Its a good first step to see the values running through the channels.

  • GRPC and gopherjs.
    I like that your using this. I have used it on a few projects too.

  • Run your IDE in a Desktop app and distribute on the Windows, Apple stores.
    https://github.com/zserge/webview
    Easy to use and fast. Not like Electron.

  • About Pins and Channels.
    I wonder if you want to consider abstracting it ? What i mean is that Protobufs and GRPC is a higher order abstraction than golang channels. This would make it much easier to plug anyones code into the "svgo pipeline" and it would be cross language. Also GRPC gives ou this abstraction too:
    a. calls acroos cross computer so you get scaling
    b. same computer but out of process . Basically IPC with grpc - saw a few github golang projects doing it that way
    c. same computer and same process. This is done using cmux.
    d. And browsers to computer . Of as as you seeing using GRPC and gopherjs you can also bring the browser into the pipeline too.
    So basically you also get Physical Topology independence.

Also GRPC and protobufs is common now and pretty accepted.

I would definitely keep the pure go channels approach you have now BTW !!! But i am just seeing how GRPC and protobuf will make this thing more reusable later thats all.

  • go wagon and WASM
    You can also look into compiling to WASM. But why ?
    go-interpreter/wagon#56
    Sure you get magic web browser speed. But the real interesting part is what you can run the WASM on a Mobile phone or something else that only accepts compiled code. And its not an awful hack like Otto etc. This is kind of huge. This is one of the reasons react native was popular - the mobile apps can download new code and run it without having to go through the app store.

i am pretty terrible at explaining my self so yell if i am not making sense and i will elaborate.

Anyway super cool stuff, and intrigued where this will go.

dev/client: Distinguish inputs and outputs with different shapes

The circle works well for goroutine outputs, but a downward triangle (evoking an "arrow") would be better for inputs.

It could be just as useful to put arrowheads on the writing side of a channel, but the middle node of a channel might have to automatically widen to declutter the arrows.

graphing package

For v1, if graphviz is not being used, how are the graphics generated?

get ride of all OS non agnostic code - use Mage instead

saw the ps1 fiel for the client.

You can use Mage to get ride of all this !
https://github.com/magefile/mage

Mage is sort of like Makefiles but for golang.
You can also use them non compiled, but then compiel the mage file to have it non interpreted (not the right term i know, but you get the idea ) and not need golang installed.

Lost of golang programs using it.

Some great examples here:
https://github.com/mcandre/mage-extras

There are many other examples around.

Will be pretty quick to convert the stuff too.

Any chance for a maintenance patch?

Never mind...
I though there was a problem with the app just acting a raw http file server... turns out the interface just looks like that.

Delete v0

If anyone wants it there's git history.
It's confusing to keep around.

WebAssembly

The bulk of the UI is still built with GopherJS.
The WebAssembly compiler might be ready.

dev/client: Make the canvas the right size

It's currently a fixed size. It should be at least as large as the area it needs to fit inside, and also at least as large as the contents plus some margin to add new items to it.

gui

This is quite similar
https://luna-lang.org/#Features

The difference is that the nodes have the ability to show a Widget representing the data.
Like a quasi spreadsheet. I expect what it is showing is the data flowing through each node.

Food for thought... I think with SVG that something similar can be done to a degree.
But i have really not thought about it too much and just figured its a good idea to post this here.

Cannot install as per documentation

README.md provides a command for installation. When I run it on Ubuntu 16.04 LTS, it does not work.

$ go get -u github.com/google/shenzhen-go/cmd/shenzhen-go
# github.com/google/shenzhen-go/graph
go/src/github.com/google/shenzhen-go/graph/graph.go:114: enc.SetIndent undefined (type *json.Encoder has no field or method SetIndent)
$ uname -a
Linux nala 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l

$ go version
go version go1.6.2 linux/amd64

Please let me know if there's anything else I can do to help diagnose the issue. This looks super fun!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.