The test was broken with the foo -> exp/foo move.
Change-Id: Ie2bdf54f6da0365d2e0332bcacdd2b7a000c950c
Reviewed-on: https://go-review.googlesource.com/11392
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL will be followed by another change to remove the
misc/ios/clangwrapper.sh dependency.
Updates golang/go#11043.
Fixesgolang/go#11339.
Change-Id: I82466f8d845945935ab82d3d0b75f5af9e1ef3ec
Reviewed-on: https://go-review.googlesource.com/11345
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The existing implementation generates uncompilable objc code for
functions returning two results.
Change-Id: I13f7329596d8fa6103c4b7827c26c5461e16a925
Reviewed-on: https://go-review.googlesource.com/11364
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This prevents filenames like go_test.go (when the package name is test)
or go_windows.go (wen the package name is windows).
Change-Id: Iae8f549d4d73baac8f8ba2ea33be7fec83f0023a
Reviewed-on: https://go-review.googlesource.com/11305
Reviewed-by: David Crawshaw <crawshaw@golang.org>
On my 2013 Nexus 7, a simple
start := time.Now()
draw.Draw(etc)
log.Printf("draw.Draw took %v", time.Since(start))
around the draw.Draw call dropped from 12ms to 30µs.
Change-Id: I12aea4a4ade07eedb8ee86f7c8d4a4ed49f39f36
Reviewed-on: https://go-review.googlesource.com/11299
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Markdown acts weirdly at puts more whitespace around the audio
package if there is no other content seperating the lists.
Change-Id: Ia60c0ea05ab2d86b9b0cbcbabccdeebda8c13cbf
Reviewed-on: https://go-review.googlesource.com/11314
Reviewed-by: Nigel Tao <nigeltao@golang.org>
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>
