natefinch/gorram

It's like go run for any go function

gorram's Issues

-c to produce a compiled version

Experiment with G-23 paxilon hydrochlorate on Miranda

Alliance scientists believe it will make people "more controllable."

run a full line of code

e.g. github.com/foo/bar/DialServer("1.2.3.4").Versions()"

Print out global variables

e.g. gorram time RFC822

Doesn't handle package name != dir

Assumes package name is always the same as the last part of the import path

Add -h To Show Help Text

generate help text from godoc, converted to make sense with the gorram CLI.

import paths with . in the name don't work

gorram foo/bar.V2.Baz is ambiguous. Is the import path foo/bar.V2 and the function Baz, or is the import path foo/bar with a global variable V2 with a method Baz?

benchmark support

It would be great to be able to get an instant micro-benchmark
of a function.

For example:

% gorram -bench math Sqrt 1000
2000000000 0.31 ns/op 0 B/op 0 allocs/op

Doesn't support calling variables that are functions

Gorram should realize when a variable is a function and enable you to call that function:

var Bar = func() { fmt.Println("Hi!") }

-t to specify specify output template

Use a go template to format the output val

-o to tell gorram where to put the output

e.g. gorram encoding/json.Indent -o foo.go

format time as RFC3339

I use gorram to print the current time, is it possible to format it as RFC3339?

doesn't handle variadics

should be able to handle variadics we otherwise handle

Print out values from global maps and slices

e.g. gorram package varname key

-g to just generate the file/binary

i.e. generate but not run

compilation failure when using os.Write

% gorram os Stdout.Write 'hello world'
os/Stdout.Write.go:48: undefined: val

race condition in parallel tests

Holy gtobal variables batman!

named types don't work

This is just a matter of remembering to use .Underlying() judiciously, but still represents work that needs to be done.

Add version info to generated code

We should stamp the generated code with a version number so that we know if it should be regenerated automatically.

need a test for package dir != name

Installation prints out compile errors

I get the following when trying to install:

$ go get npf.io/gorram
# npf.io/gorram/run
../go/src/npf.io/gorram/run/command.go:18: cannot use buf (type "golang.org/x/tools/go/types".Type) as type "go/types".Type in argument to "go/types".NewPointer:
        "golang.org/x/tools/go/types".Type does not implement "go/types".Type (wrong type for Underlying method)
                have Underlying() "golang.org/x/tools/go/types".Type
                want Underlying() "go/types".Type
../go/src/npf.io/gorram/run/command.go:21: cannot use prog.Package("io").Pkg.Scope().Lookup("Reader").Type() (type "golang.org/x/tools/go/types".Type) as type "go/types".Type in assignment:
        "golang.org/x/tools/go/types".Type does not implement "go/types".Type (wrong type for Underlying method)
                have Underlying() "golang.org/x/tools/go/types".Type
                want Underlying() "go/types".Type
../go/src/npf.io/gorram/run/command.go:22: cannot use prog.Package("io").Pkg.Scope().Lookup("Writer").Type() (type "golang.org/x/tools/go/types".Type) as type "go/types".Type in assignment:
        "golang.org/x/tools/go/types".Type does not implement "go/types".Type (wrong type for Underlying method)
                have Underlying() "golang.org/x/tools/go/types".Type
                want Underlying() "go/types".Type
../go/src/npf.io/gorram/run/command.go:121: cannot use pkg (type *"golang.org/x/tools/go/types".Package) as type *"go/types".Package in argument to getFunc

$ go version
go version go1.7 darwin/amd64

Doesn't currently compile

Doesn't currently compile

$ go install npf.io/gorram
# npf.io/gorram
./main.go:21: undefined: cli.Run

$ go version
go version go1.7.1 linux/amd64

zero argument functions fail due to `imported and not used: "os"`

Demonstrated with

package sillytest

var Example = func() int { println("sup"); return 5 }

regenall command

When upgrading to a new version, allow people to run a single command that'll upgrade all old scripts. Not strictly necessary, but might be nice if you want to avoid that first-run sluggishness.

Love your project image!

Seriously, it is awesome. Love stuff like this. +1

what to do about interface{} parameters?

It may be intractable for many cases... it's basically impossible to know if a user that types 25 as an argument means 25 the int or "25" a string.