[ANN] Rango , a REPL program for Go in Go

[Ernest Micklei]

Rango uses a generate-compile-run loop. Successively, for each new command line entry, a new program is generated in Go, compiled in Go and run on your machine. Any compiler error of the generated source is captured and printed by rango. The output (stdout and stderr) of the generated program is captured and printed by rango. Rango can pick up where you left because it keeps the changes in a file.

Docs:  http://godoc.org/github.com/emicklei/rango

Project: https://github.com/emicklei/rango

Note: this idea is not new and has been implemented before for (so I found) https://github.com/vito/go-repl

Have fun,

Ernest

[rocky]

What are the differences, pros and cons, between rango, go-repl, and igo? If go-repl was known previously, what was it that motivated writing rango?

I'll start out with the little things I see, but I'd really appreciate the views of others. 

I know igo uses liner for line editing support and I guess rango and go-repl do not. In my view this is not a big deal since that is easily added. Also, it looked like editing of the collected source in rango seemed a bit minimal. There is "undo" but nothing to modify or delete previous lines. 

I get the impression that igo works fundamentally different from rango and go-repl. Is this correct? 

[Rocky Bernstein]

Should have added http://play.golang.org to the list below. 

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/VGZiQmyijgc/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Damian Gryski]

There's also the local unsandboxed 'goplay' in $GOROOT/go/misc/goplay   ( https://code.google.com/p/go/source/browse#hg%2Fmisc%2Fgoplay )

Damian

[rocky]

goplay is cool too. I wonder why it doesn't have many of the features that http://play.go.org has.  In particular reformatting text, the line highlighting of errors when there is a compile error, among other things.

[Ernest Micklei]

I started rango from the generate-compile-run loop idea and wanted to see if that would work at all. Later I realized that such program are classified as REPL and started looking for such implementations in Go. I found the project go-repl and looked at its source. Because it uses a container/vector package which is no longer available in the standard libs and some other unclear complexity, I resumed my own work. 

The https://github.com/sbinet/go-eval project implements an interpreter which better fits my needs but cannot (and will never?) be able to deal with dynamic imports. 

One feature of rango I like to explore more is that it keeps changes of a rango shell session in a file. This also provides a means to bootstrap a session with packages "pre-loaded", e.g:

import m "bitbucket.org/emicklei/musigo"

m.ParseNote("C#") // nop to use the package 

Op zaterdag 16 maart 2013 19:40:54 UTC+1 schreef rocky het volgende:

[Damian Gryski]

Le dimanche 17 mars 2013 01:21:36 UTC+1, rocky a écrit :

goplay is cool too. I wonder why it doesn't have many of the features that http://play.go.org has.  In particular reformatting text, the line highlighting of errors when there is a compile error, among other things.

   Just for simplicity, I'd imagine.  The full repo is available at https://code.google.com/p/go-playground/ , but I'm not sure how easy (if at all) it would be to install and run locally. However, I wonder if a 'tricked-out' local playground would even be something people would want?  I don't think it would fit into my workflow, personally.  If I'm coding at a terminal, I don't want to be jumping back and forth to a web-app to test out ideas.

   Damian

[Sebastien Binet]

hi,

On Sun, Mar 17, 2013 at 11:50 AM, Ernest Micklei
<ernest....@gmail.com> wrote:
> I started rango from the generate-compile-run loop idea and wanted to see if
> that would work at all. Later I realized that such program are classified as
> REPL and started looking for such implementations in Go. I found the project
> go-repl and looked at its source. Because it uses a container/vector package
> which is no longer available in the standard libs and some other unclear
> complexity, I resumed my own work.
>
> The https://github.com/sbinet/go-eval project implements an interpreter
> which better fits my needs but cannot (and will never?) be able to deal with
> dynamic imports.

go-eval had that feature at one time (but was relying on a few CLs for
go's stdlib which weren't included b/c not really fit to general
consumption)
I do plan to work on this when go-1.1 and go.exp/go/types are out.
(as well as trying to implement more of the go constructs)

-s

[Andrew Gerrand]

On 17 March 2013 11:21, rocky <rocky.b...@gmail.com> wrote:

goplay is cool too. I wonder why it doesn't have many of the features that http://play.go.org has.  In particular reformatting text, the line highlighting of errors when there is a compile error, among other things.

The play.golang.org code was written to the remote playground API, not to compile locally.

At this point, goplay is more or less unmaintained and rarely used. I'd like to see it moved outside the Go core and given some love by people that actually use it.

Andrew

[Rocky Bernstein]

On Sun, Mar 17, 2013 at 9:48 PM, Andrew Gerrand <a...@golang.org> wrote:

On 17 March 2013 11:21, rocky <rocky.b...@gmail.com> wrote:

goplay is cool too. I wonder why it doesn't have many of the features that http://play.go.org has.  In particular reformatting text, the line highlighting of errors when there is a compile error, among other things.

The play.golang.org code was written to the remote playground API, not to compile locally.

Is the remote playground API that much different than compiling locally? Can they easily be made to look more the same?

At this point, goplay is more or less unmaintained and rarely used. I'd like to see it moved outside the Go core and given some love by people that actually use it.

I've been looking for something in-between (or including) http://play.go.org and igo/rango. I'm not totally sure what that would be though.


I'd love for someone else to take the ball and run with it. But if no one else does, I might.

What do you suggest for those that do want pick this up? Fork the code and put it in a separate repository somewhere?


 

Andrew

[Nate Finch]

I'm trying this out this morning.... my suggestion would be to automatically undo lines that don't compile. For example, I made the mistake of using = instead of := to define a variable... but that line got "stuck" in the file, even though it wasn't valid. Most repls won't "penalize" you for entering in something invalid... they'll just let you know it's invalid, and if you  then type in something valid, that'll "stick".

Very cool that you're doing thing. Please continue to work on it. I think this is a very handy tool to have, especially for people coming from interpreted languages that have these things built in.

On Saturday, March 16, 2013 10:24:52 AM UTC-4, Ernest Micklei wrote:

[Ernest Micklei]

@Nate , thank you for the suggestion ; will work on that too.

[Andrew Gerrand]

On 18 March 2013 13:47, Rocky Bernstein <rocky.b...@gmail.com> wrote:

On Sun, Mar 17, 2013 at 9:48 PM, Andrew Gerrand <a...@golang.org> wrote:

On 17 March 2013 11:21, rocky <rocky.b...@gmail.com> wrote:

goplay is cool too. I wonder why it doesn't have many of the features that http://play.go.org has.  In particular reformatting text, the line highlighting of errors when there is a compile error, among other things.

The play.golang.org code was written to the remote playground API, not to compile locally.

Is the remote playground API that much different than compiling locally? Can they easily be made to look more the same?

One uses websockets and streams responses in real time, the other uses HTTP requests and replays responses to make it look like they're happening in realtime. So they're fundamentally different. The latter approach requires a specially modified runtime environment to capture the timings of the output.

 

At this point, goplay is more or less unmaintained and rarely used. I'd like to see it moved outside the Go core and given some love by people that actually use it.

I've been looking for something in-between (or including) http://play.go.org and igo/rango. I'm not totally sure what that would be though.


I'd love for someone else to take the ball and run with it. But if no one else does, I might.

What do you suggest for those that do want pick this up? Fork the code and put it in a separate repository somewhere?

Fork it and put it somewhere else. I'm happy to assure you the Playground API on the HTTP side is stable, but the rest is subject to change at my convenience (as the maintainer of play.golang.org, tour.golang.org, and talks.golang.org).

Andrew

[Rocky Bernstein]

Funny, just today I went back to this thread to make note of the locations of the two sources to make it easy for me to find the important information when I want it. I've also added what you wrote below as well. 

I'll probably poke around this as a toy project for fun. And probably at a pace that will make your reply seem lightning fast. 

Again - thanks, everyone, for the pointers and suggestions. 

[rocky]

I've just made a quick pass at merging the http://play.golang.org code with $GOROOT/go/misc/goplay

It is at https://code.google.com/p/go-play/. 

From http://play.golang.or  we pick up  css and javascript. So the styling, showing line numbers and highlighting errors works the same way. 

Like goplay from the go source, compilation and running are done on the computer running the HTTP server, so no internet connection is needed, the time is set correctly,  and you can import any packages you have installed locally.

What's currently missing are the "share" and "format" buttons from http://play.go.com;  "load go file" and "save" buttons could easily be added.

Although this is functional as is, there is still probably a bit of low-hanging fruit. So feel free to extend and contribute.