gomobile init builds and install the toolchain for iOS builds now.
The error message shouldn't exclude the darwin/arm and darwin/arm64
related initialization.
Change-Id: Iebd5d7fb1466d9be694d8848c0fd8fa782850c79
Reviewed-on: https://go-review.googlesource.com/11239
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The params order matters in diff function's output.
Related to the confusing error report seen in golang/go#11297
Change-Id: Ibde615dbe43a4393232b72230fb21d7b577c0812
Reviewed-on: https://go-review.googlesource.com/11258
Reviewed-by: Burcu Dogan <jbd@google.com>
The golden output for build test was generated assuming GOPATH == HOME.
Change-Id: I7dbf292b66e2ba999cbdc1e288ddb60767b0835b
Reviewed-on: https://go-review.googlesource.com/11257
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also add a very simple test for gomobile build, some
documentation cleanup, and the -o flag for bind.
Change-Id: I719b92010ba2a5813049827c99502828788611ef
Reviewed-on: https://go-review.googlesource.com/11253
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Currently, we don't allow user to override xcodebuild args, we may
introdude a new go build flag such as `xcodebuildargs` to pass
additional flags.
Updates #11043.
Change-Id: I776b332c2af3d9640a7c5f23ab7bc7b19a5e408a
Reviewed-on: https://go-review.googlesource.com/10990
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL adds the generation of a boilerplate Xcode project
to make it possible to shell out to xcodebuild to make a
release build.
In order to support multiple architectures, we are using lipo tool to
create fat binaries that target both darwin/arm and darwin/arm64.
This build strategy will require a darwin host with Xcode CLI tools
installed.
Updates #11043.
Change-Id: I741b05f5e34bf2a90103b1efdfa2db97a743e2a6
Reviewed-on: https://go-review.googlesource.com/10813
Reviewed-by: David Crawshaw <crawshaw@golang.org>
x11/gl is not thread-safe, so all x11/gl related API should be called
from one thread. There's already a dedicated thread for GL calls, so
move all x11 API calls to GL thread using gl.Do(...)
Fixesgolang/go#11066
Change-Id: If84a8d56e978ce30d7fbbc310740fcc794ce61d7
Reviewed-on: https://go-review.googlesource.com/10744
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Translate error type to NSError.
Interface type is not supported yet.
Change-Id: I54abba2360cff41ef8ca08063b0120e7edd65a47
Reviewed-on: https://go-review.googlesource.com/10793
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Change AppDelegate, AppController to GoAppAppDelegate,
GoAppAppController - which are ugly enough so gobind users
is unlikely to use in their objective-c code.
Change-Id: I69305994a83405a1d8499df661bd5f63757a7fd6
Reviewed-on: https://go-review.googlesource.com/10852
Reviewed-by: David Crawshaw <crawshaw@golang.org>
With https://go-review.googlesource.com/10638, the reference counting
of Go objects can be simplified. Everytime a Go object is passed into
Objective-C side, a new proxy object with GoSeqRef is created.
Deallocation of a GoSeqRef decrements the reference counter of the
corresponding Go object.
Test the Go object is collected.
Note: It's possible to reduce the number of GoSeqRef
allocations by maintaining a map of weak references to the existing
GoSeqRef, but for now, we allocate a new GoSeqRef instance.
Change-Id: I57a5a4b249c5800d9eba95d128a2cdf74bbef566
Reviewed-on: https://go-review.googlesource.com/10639
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The gobind framework is supposed to use reference counting to
keep track of objects (e.g. pointer to a Go struct, interface
values) crossing the language boundary. This change fixes two bugs:
1) no reference counting on Java object: Previously, the lifetime
of a Java object was manages in the following way.
a. The Java object is pinned in an internal map (javaObjs) when it's
constructed.
b. When Go receives the reference to the Java object, it creates a
proxy object and sets a finalizer on it. The finalizer signals Java
to unpin the Java object (remove from the javaObjs map).
c. The javaObjs map is also used to identify the Java object when
Go asks to invoke a method on it later.
When the same Java object is sent to Java more than once, and the
finalizer (b) runs after the first use, the second use of the Java
object can cause the crash described in golang/go#10933.
This change fixes the bug by reference counting the Java object.
Java side pins the Java object and increments the refcount whenever it
sees the object sent to Go (in Seq.writeRef). When the Go proxy
object's finalizer runs, the refcount is decremented. When the refcount
becomes 0, the object gets unpined.
2) race in Go object lifetime management: Pinning on a Go object
has been done when the Go object is sent to Java but the Go object
is not in the pinned object map yet. (bind/seq.WriteGoRef).
Unpinning the object occurs when Java finds there are no proxy objects
on its side. For this, Java maintains a reference count map (goObjs).
When the refcount becomes zero, Java notifies Go so the object is
unpinned. Here is a race case:
a. Java has a proxy object for a Go object.
b. Go is preparing for sending the same Go object. seq.WriteGoRef
notices the corresponding entry in the pinned object map already,
and returns. The remaining work for sending the object continues.
c. The proxy object in Java finalizes and triggers deletion of the
object from the pinned object map.
d. The remaining work for (b) completes and Java creates a new proxy
object. When a method is called for the Go object, the Go object is
already removed from the object map on Go side and maybe already GC'd.
This change fixes it by converting the pinned object map to reference
counter map maintained in Go. The counter increments for each
seq.WriteGoRef call. The finalizer of the proxy object in Java causes
a decrement of the counter.
Fixesgolang/go#10933.
Renables the skipped testJavaRefGC.
Change-Id: I0992e002b1050b6183689e5ab821e058adbb420f
Reviewed-on: https://go-review.googlesource.com/10638
Reviewed-by: David Crawshaw <crawshaw@golang.org>
- Fix hangs on linux/x11. x11-related code remains outdated since
068a51c19, which seperates GL calls to dedicated thread. Update x11
code to work with GL thread.
- Fix bug on coordinate system. x11 has same coordinate system with
android, (0,0) on top-left.
Change-Id: I0b3ab97fd4842b1c9f730e1c90a5840f540fcb7a
Reviewed-on: https://go-review.googlesource.com/10623
Reviewed-by: David Crawshaw <crawshaw@golang.org>
All GL function calls fill out a C.struct_fnargs and drop it on the
work queue. The Start function drains the work queue and hands
over a batch of calls to C.process which runs them. This allows
multiple GL calls to be executed in a single cgo call.
A GL call is marked as blocking if it returns a value, or if it
takes a Go pointer. In this case the call will not return until
C.process sends a value on the retvalue channel.
Change-Id: I4c76b2a8ad55f57b0c98d200d0fb708d4634e042
Reviewed-on: https://go-review.googlesource.com/10452
Reviewed-by: Nigel Tao <nigeltao@golang.org>
After CL 10296 the workaround from CL 9783 is no longer necessary.
Revert the workaround but keep the global reference, just in case.
Change-Id: I3fdd580e4122c36508beb9d328739b910dbbe2e2
Reviewed-on: https://go-review.googlesource.com/10483
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This ensures that the java bindings are ready before any calls are
made by user code. As a bonus, the JNIEnv* is from the Seq class so I
believe no tricks are required to find the right class loader.
Fixesgolang/go#10903.
Change-Id: I33b3b39cef6cc2da36e271de882ba8d26610ea34
Reviewed-on: https://go-review.googlesource.com/10296
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Conflicts with cl/10396. I'll submit this first and update the it.
Change-Id: Ibc873b3fe896ecd2415a42676614807788a8d1c6
Reviewed-on: https://go-review.googlesource.com/10399
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This trusts bionic's reading of the system clock.
Future work should address the fact we cannot read the Android
zoneinfo file.
Fixesgolang/go#10857.
Change-Id: I5a684fecc920dce5ab8f624658e91d9e2d71738d
Reviewed-on: https://go-review.googlesource.com/10299
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The user may have set GOBIN, in which case the existing go command is
overwritten. I cannot think of any relevant environment variables the
user would set, so the easiest thing is not to use them at all.
While here, fix the unit test I broke in cl/10319.
Change-Id: I8cef353b5a0e4aabae97169ff553b53f7973ff8b
Reviewed-on: https://go-review.googlesource.com/10397
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change-Id: I574f9ea8ab8138c769be19df8b1e86a7fbe544a8
Reviewed-on: https://go-review.googlesource.com/9879
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
