Skip to content

Interface "missing methods" #808

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.

Sign up for GitHub

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

Jump to bottom
Closed
Programmerino opened this issue Apr 27, 2018 · 4 comments
Closed

Interface "missing methods" #808

Programmerino opened this issue Apr 27, 2018 · 4 comments
Labels
external

Comments

@Programmerino
Copy link

For some reason, when compiling the Gorgonia library, GopherJS fails with:

../../../gorgonia.org/tensor/defaultengine_mapreduce.go:29:13: invalid operation: v (variable of type View) has no field or method Clone
../../../gorgonia.org/tensor/tensor.go:145:19: cannot use t.Slice(slices...) (value of type View) as Tensor value in assignment: missing method Clone

However, this error does not occur in standard Go, and I can only get it to work with GopherJS when I adjust the View interface from:

// View is any Tensor that can provide a view on memory
type View interface {
	Tensor
	IsView() bool
	IsMaterializable() bool
	Materialize() Tensor
}

to replace the Tensor line with the entire definition of the Tensor interface:

// View is any Tensor that can provide a view on memory
type View interface {
	// info about the ndarray
	Shape() Shape
	Strides() []int
	Dtype() Dtype
	Dims() int
	Size() int
	DataSize() int

	// Data access related
	RequiresIterator() bool
	Iterator() Iterator

	// ops
	Slicer
	At(...int) (interface{}, error)
	SetAt(v interface{}, coord ...int) error
	Reshape(...int) error
	T(axes ...int) error
	UT()
	Transpose() error // Transpose actually moves the data
	Apply(fn interface{}, opts ...FuncOpt) (Tensor, error)

	// data related interface
	Zeroer
	MemSetter
	Dataer
	Eq
	Cloner

	// type overloading methods
	IsScalar() bool
	ScalarValue() interface{}

	// engine/memory related stuff
	// all Tensors should be able to be expressed of as a slab of memory
	// Note: the size of each element can be acquired by T.Dtype().Size()
	Engine() Engine             // Engine can be nil
	MemSize() uintptr           // the size in memory
	Uintptr() uintptr           // the pointer to the first element, as a uintptr
	Pointer() unsafe.Pointer    // the pointer to the first elemment as a unsafe.Ponter
	IsNativelyAccessible() bool // Can Go access the memory
	IsManuallyManaged() bool    // Must Go manage the memory

	// formatters
	fmt.Formatter
	fmt.Stringer

	// all Tensors are serializable to these formats
	WriteNpy(io.Writer) error
	ReadNpy(io.Reader) error
	gob.GobEncoder
	gob.GobDecoder

	standardEngine() standardEngine
	headerer
	arrayer
	IsView() bool
	IsMaterializable() bool
	Materialize() Tensor
}
@myitcv myitcv mentioned this issue Apr 27, 2018
Closed
@myitcv
Copy link
Member

myitcv commented Apr 27, 2018

This is actually an instance of golang/go#25008 (GopherJS uses go/types under the covers). I've asked the question in that issue whether the fix could be back-ported to the 1.10 series.

Thanks for raising in any case; I suggest we leave this open, depending on the response in the linked issue.

@Programmerino
Copy link
Author

Thank you!

myitcv added a commit to myitcv/gopherjs that referenced this issue May 1, 2018
@myitcv
vendor: vendor go/types to workaround bug in method set calc.
c2b7fde 
Per golang/go#25008 (comment) the
fix for method set calculation will not be back ported to Go 1.10.
Instead gri suggests we vendor the latest version of go/types. This PR
does just that. It is effectively a temporary sticking plaster until Go
1.11 lands, or more specifically until we release GopherJS for Go 1.11.

In order to successfully vendor go/types, however, we need to move
compiler/vendor to the repo root (because build also uses go/types). And
because golang.org/x/tools/go/gcexportdata and
golang.org/x/tools/go/types/typeutil also reference go/types we need to
vendor them as well.

vendor/vendor.json is updated using govendor, with the one exception
being a manual addition for go/types (govendor doesn't appear to
understand how to vendor a standard library package).

Fixes gopherjs#808.
@myitcv myitcv mentioned this issue May 1, 2018
Closed
@myitcv
Copy link
Member

myitcv commented May 1, 2018

@131072 per the linked issue, as things stand we are not going to get a fix for this until Go 1.11, and even then until we release a GopherJS corresponding to that version.

So for now I've pushed up #811 in order to work around this as Robert suggested.

You can try this out locally:

cd $(go list -f '{{.Dir}}' github.com/gopherjs/gopherjs) && \
  git fetch origin pull/811/head && \
  git checkout FETCH_HEAD && \
  go install

With this version of gopherjs, gorgonia.org/gorgonia appears to compile just fine.

@Programmerino
Copy link
Author

Alright, sounds good!

myitcv added a commit to myitcv/gopherjs that referenced this issue Jul 2, 2018
@myitcv
vendor: vendor go/types to workaround bug in method set calc.
e5a64e8 
Per golang/go#25008 (comment) the
fix for method set calculation will not be back ported to Go 1.10.
Instead gri suggests we vendor the latest version of go/types. This PR
does just that. It is effectively a temporary sticking plaster until Go
1.11 lands, or more specifically until we release GopherJS for Go 1.11.

In order to successfully vendor go/types, however, we need to move
compiler/vendor to the repo root (because build also uses go/types). And
because golang.org/x/tools/go/gcexportdata and
golang.org/x/tools/go/types/typeutil also reference go/types we need to
vendor them as well.

vendor/vendor.json is updated using govendor, with the one exception
being a manual addition for go/types (govendor doesn't appear to
understand how to vendor a standard library package).

Fixes gopherjs#808.
myitcv added a commit to myitcv/gopherjs that referenced this issue Jul 2, 2018
@myitcv
vendor: vendor go/types to workaround bug in method set calc.
0256ac9 
Per golang/go#25008 (comment) the
fix for method set calculation will not be back ported to Go 1.10.
Instead gri suggests we vendor the latest version of go/types. This PR
does just that. It is effectively a temporary sticking plaster until Go
1.11 lands, or more specifically until we release GopherJS for Go 1.11.

In order to successfully vendor go/types, however, we need to move
compiler/vendor to the repo root (because build also uses go/types). And
because golang.org/x/tools/go/gcexportdata and
golang.org/x/tools/go/types/typeutil also reference go/types we need to
vendor them as well.

vendor/vendor.json is updated using govendor, with the one exception
being a manual addition for go/types (govendor doesn't appear to
understand how to vendor a standard library package).

Fixes gopherjs#808.
myitcv added a commit to myitcv/gopherjs that referenced this issue Jul 2, 2018
@myitcv
vendor: vendor go/types to workaround bug in method set calc.
96d0295 
Per golang/go#25008 (comment) the
fix for method set calculation will not be back ported to Go 1.10.
Instead gri suggests we vendor the latest version of go/types. This PR
does just that. It is effectively a temporary sticking plaster until Go
1.11 lands, or more specifically until we release GopherJS for Go 1.11.

In order to successfully vendor go/types, however, we need to move
compiler/vendor to the repo root (because build also uses go/types). And
because golang.org/x/tools/go/gcexportdata and
golang.org/x/tools/go/types/typeutil also reference go/types we need to
vendor them as well.

vendor/vendor.json is updated using govendor, with the one exception
being a manual addition for go/types (govendor doesn't appear to
understand how to vendor a standard library package).

Fixes gopherjs#808.
myitcv added a commit to myitcv/gopherjs that referenced this issue Jul 2, 2018
@myitcv
vendor: vendor go/types to workaround bug in method set calc. (#7)
e13dc1a 
Per golang/go#25008 (comment) the
fix for method set calculation will not be back ported to Go 1.10.
Instead gri suggests we vendor the latest version of go/types. This PR
does just that. It is effectively a temporary sticking plaster until Go
1.11 lands, or more specifically until we release GopherJS for Go 1.11.

In order to successfully vendor go/types, however, we need to move
compiler/vendor to the repo root (because build also uses go/types). And
because golang.org/x/tools/go/gcexportdata and
golang.org/x/tools/go/types/typeutil also reference go/types we need to
vendor them as well.

vendor/vendor.json is updated using govendor, with the one exception
being a manual addition for go/types (govendor doesn't appear to
understand how to vendor a standard library package).

Fixes gopherjs#808.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
external
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

vendor: vendor go/types to workaround bug in method set calc. myitcv/gopherjs
3 participants
@dmitshur @myitcv @Programmerino