| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 204225504
|
|
|
|
|
|
| |
Fixes #16464
PiperOrigin-RevId: 183946928
|
|
|
|
| |
PiperOrigin-RevId: 179263865
|
|
|
|
| |
PiperOrigin-RevId: 179260538
|
|
|
|
| |
PiperOrigin-RevId: 179258973
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By respecting cgo rules on pointers.
Without the change to graph.go, the newly added test would fail with:
panic: runtime error: cgo argument has Go pointer to Go pointer
in the call to the C function TF_SetAttrShapeList.
Fixes #14891
PiperOrigin-RevId: 177336663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Helps with #9931
- graph.go: Return a nil Operation if the operation creation failed.
This ensures that accidental usage of the nil operation results in
a panic/stacktrace purely in Go (nil pointer dereference) instead
of a SIGSEGV in the underlying C API.
- operation.go: Attempt to help in the developer find the root cause
of the nil pointer dereference with a chattier panic message.
PiperOrigin-RevId: 156220056
|
|
|
|
| |
Change: 152200430
|
|
|
|
| |
Change: 149800363
|
|
|
|
|
| |
Fixes #6833
Change: 144752893
|
|
|
|
| |
Change: 139377074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, TF_*Run, TF_SetAttrTensor and TF_SetAttrTensorList
took ownership of the TF_Tensor*s of the feeds. This can make performance
client languages bothersome when the same Tensor is repeatedly fed into
multiple session executions as the memory for the feed tensor would need
to be re-allocated and filled in every time.
With this change, these functions no longer take ownership of the
TF_Tensor*.
The changes to the Go API implementation reflect the claimed benefits.
(Another step towards #10)
Change: 139169388
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The types size_t and int were being used inconsistently
across different functions. This change documents the
convention and fixes a few functions up to ensure that
all functions adhere to it.
Not quite sure if this convention (in particular using
'int' for array indices, as opposed to say 'size_t')
is the best choice, but at least the choice has been
made consistently.
Change: 139100887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Export an API to add operations to the graph.
I also intend to use this API in a code generator that will generate
Go sources files containing functions for each OpDef (and all
this generated code will be in a separate package).
While at it, also changed some tests to use the "sub-tests"
feature in Go 1.7 (https://blog.golang.org/subtests)
Another step in the journey of #10
Change: 135493412
|
|
|
|
|
|
|
|
|
| |
With this change, it should be possible to execute
a pre-defined Graph created by any means (like a
training session in a Python program) in Go.
One more step towards #10
Change: 134096795
|
|
Remaining work to do:
- Generated ops.
- Generated protocol buffers.
- A few calls requiring protocol buffers aren't in this change.
Change: 131066649
|