Added recently, but I forgot to update the test.
Fixesgolang/go#12983
Change-Id: I668b20d74c6b91d9588e6f252939d36ae780bd77
Reviewed-on: https://go-review.googlesource.com/16052
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
for example,
package testpkg
var AnInt int64
will be mapped to
@interface GoTestpkg: NSObject
+ (int64_t) AnInt;
+ (void) setAnInt:(int64_t)v;
@end
Followup of cl/15340
Update golang/go#12475
Change-Id: Ie26c92af977fc3dd62dcad2b10c6a5c1c1b8941b
Reviewed-on: https://go-review.googlesource.com/15770
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Fixesgolang/go#12911
Note: the x11 support seems outdated in general compared to
android, darwin versions.
Change-Id: I2a80215c62b8c3cf87c5eb054184fea10819abc9
Reviewed-on: https://go-review.googlesource.com/15790
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Naked returns must be used for self-documentary reasons. In this
unexported package, it is not useful to name return values.
The change has been contributed on a previous CL but I don't know
what happened, it should have been lost on a bad merge.
Change-Id: I6cb9c3a58ad397aeb646f3e57e482628fe31ca31
Reviewed-on: https://go-review.googlesource.com/15658
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
readEvents never return an error, readSignal should not have an
error field.
Change-Id: I9566a6905ee678599fdad18f85ae55d1fdc16cc1
Reviewed-on: https://go-review.googlesource.com/15550
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Several notices, notes and questions have become obsolete when
CL/15438 is merged. Removing the TODOs pointing to the bug explained
in CL/15438's description.
Change-Id: I8a94507a6d0aa507a58be451336eba36dd383d64
Reviewed-on: https://go-review.googlesource.com/15551
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
A paint.Event now has an External field. Whenever a paint event is
sent by the x/mobile/app package, it is marked as external so users
with an active paint loop can ignore them.
Implemented on OS X and Android, with examples updated.
Change-Id: Ibee8d65625c8818ff954936be48257ad30daa147
Reviewed-on: https://go-review.googlesource.com/15480
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The CGL display link is a timer keyed on screen refresh rate. It made
sense to use it when the app package controlled the screen paint
cycle. Now that the paint cycle control has moved to the user, and
given that we have always made the equivalent of Publish block until
vsync, it is just complicating matters. The user can come up with
their own timer, and safely dedicate a goroutine to event handling
that paints as fast as it likes without running over the vsync time.
A version of this for iOS will follow (giving up on the timer provided
by GLKViewController) when I get my iOS setup working again.
(Note there is also a bug in the way drawgl works presently. This CL
doesn't fix the bug, but is a first step in untangling the draw loop
so I can fix it.)
Change-Id: I464d5b15f018527d98b792026fb3899681f24e4b
Reviewed-on: https://go-review.googlesource.com/15470
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The init signal's job could be done at the top of the proxying
goroutine.
Change-Id: Icb907946a679d3eca6bec5e12adeb2bedc0908f0
Reviewed-on: https://go-review.googlesource.com/15490
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Only the loopers allocated with ALooper_acquire are releasable. We are
depending on the looper associated to the thread which will be
automatically released when the thread is being terminated.
Trying to re-release a looper makes the app crash with segfault.
Change-Id: Ib80549de01f5f44143752c13a82b6b4a2ab5610e
Reviewed-on: https://go-review.googlesource.com/15491
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The sensor package had a deadlock case if it started to poll the
events but all sensors have been disabled on the underlying ALooper.
Consider the following program:
app.Main(func(a app.App) {
sensor.Enable(a, sensor.Gyroscope, time.Millisecond)
go func() {
time.Sleep(5 * time.Second)
sensor.Disable(sensor.Gyroscope)
time.Sleep(2 * time.Second)
sensor.Enable(a, sensor.Gyroscope, time.Millisecond)
}()
for e := range a.Events() {
case sensor.Event:
//...
}
The initial Enable will enable the gyroscope and start polling events
from the ALooper. After 5 seconds, the gyroscope will be disabled.
ALooper_pollAll(-1, NULL, &events, NULL)
will block indefinately because there are no events will be
available until another sensor is enabled.
After 2 seconds, we will attempt to enable the gyroscope again. But,
the underlying thread will be blocked at pollAll and won't be able
to make the sensor enabling call on the same thread.
In order to overcome this deadlock case, this thread introduces a
hard timeout limit during polling. If timeout occurs, the looper
thread will be unblocked and select{} statement will be able to
handle {enable,disable,close}Signal cases.
Fixesgolang/go#12501.
Change-Id: I35efa2e29057ca37f8ac0f38be8dc59c9b8262b3
Reviewed-on: https://go-review.googlesource.com/15438
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Also move the initialization of glctx to an init function, removing
the data race mentioned in golang/go#12718. (Unfortunately the data
race is not the cause of the bug.)
Change-Id: If5f1fd7755d5645cf25ccc780ee8d138011c8f10
Reviewed-on: https://go-review.googlesource.com/15460
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
It is not often clear that the issues must be prefixed with x/mobile.
Provide a template to give a hint to the user that all mobile bugs
must be prefix relative to golang.org base.
Change-Id: Ia5b35db529798a230850d935ff3e0e800d1948f9
Reviewed-on: https://go-review.googlesource.com/15401
Reviewed-by: Andrew Gerrand <adg@golang.org>
The current example 2**(2+3) yields the same result as not using
parenthesis. The "grouped differently" example should use (2**2)+3
so that it yields a different result.
Change-Id: If5f63ec03adba4402c51822d6c13646a26384730
Reviewed-on: https://go-review.googlesource.com/14960
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
Traditionally, framework bundles have title case names such as
CoreFoundation.framework and UIKIt.framework.
gomobile bind should generate framework bundles named similarly,
following this convention.
Change-Id: Ia6082ed351ddc6fc97e0435e24e5f79c5afbaea4
Reviewed-on: https://go-review.googlesource.com/15330
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The stderr includes a helpful note from Xcode about how to fix it.
Fixesgolang/go#12515
Change-Id: I4eb944f29a7a3e39e2f4150c27a53e04d02e5d09
Reviewed-on: https://go-review.googlesource.com/15300
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
It is an error to use a gl.Context concurrently. (Each Context
contains a state machine, so there is no way this can work.)
Up until now only the GL driver could report such a misuse, and
it generally does a poor job of it. Our command buffer adds some
small oppertunity for the race detector to help, but it makes it
harder to debug other kinds of driver crashes, so it is worth
disabling in debug mode.
To make it easy, compiling with -tags gldebug now inserts an
explicit check that there are no other active GL calls outstanding.
Adding something like:
go func() {
for {
glctx.GetInteger(gl.ALPHA_BITS)
}
}()
to x/mobile/example/basic now reliably crashes when compiled
with -tags gldebug, providing a stack trace that includes both
misbehaving goroutines.
Change-Id: I3d85d94220bca2a15eaf2742f13b44db1f3428bf
Reviewed-on: https://go-review.googlesource.com/15180
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This means that if the OpenGL driver crashes, the stack trace will
contain a goroutine blocked in the function that caused the panic.
Fixesgolang/go#12786
Change-Id: I039c74f9e24de777b925475a50e8c96129692f70
Reviewed-on: https://go-review.googlesource.com/15160
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Modulemaps allow users to use the import directives without
providing the specific header file but by using a module name
in Objective-C and Swift.
gomobile bind -target=ios golang.org/x/mobile/example/bind/hello
Add the generated framework to an Xcode project. You will be able
to import the library header and use the library by importing hello
in Swift.
import hello
// ...
hello.GoHelloGreetings("burcu");
In Objective-C, you will be able to import with the module name
similarly by using the import directive below.
#import hello
This CL also enables Go bindings to be used from Swift without an
Objective-C bridging header.
Fixesgolang/go#12422
Change-Id: I7c60349caad100861d0b642ddfa873d7ada47598
Reviewed-on: https://go-review.googlesource.com/15044
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The package-level OpenGL calls in golang.org/x/mobile/gl were removed.
This change fixes testapp to use their replacement.
This change also moves the location of the test taps to be further away
from the top of the screen. On my phone (running L), a tap at 50,60 is
opens the draggy menu thing that Android has and the running app doesn't
see it (which causes the test to not complete).
Change-Id: I679c9b61919a332f9b4a53e0950ff96f6aefbbbb
Reviewed-on: https://go-review.googlesource.com/15050
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The package-level OpenGL calls in golang.org/x/mobile/gl were removed.
This change fixes the example sprite app to use their replacement.
Change-Id: I1884e9292133375194c963e71540acaef0908d66
Reviewed-on: https://go-review.googlesource.com/15051
Reviewed-by: David Crawshaw <crawshaw@golang.org>
All OpenGL functions are now methods on a Context interface. The
gl.Context matches the one loaded into thread-local storage in C.
For mobile apps, the context is owned by an app.App. For now, it is
provided through the events channel on a lifecycle event. Long-term,
it should probably be available by a method on app.App, but this is
inherently racey with our current use of a channel to deliver events.
Shiny-based programs will have a gl.Context associated with a each
shiny.Window. The expectation is each Window will have different
contexts, allowing them to draw separately.
Change-Id: Ie09986fb74e493129f2ea542a151c95c6fa29812
Reviewed-on: https://go-review.googlesource.com/13431
Reviewed-by: Nigel Tao <nigeltao@golang.org>
gomobile builds apps with hidden files from the assets directory.
The final applications should skip files like .DS_Store, .gitignore,
etc. Therefore, walker needs to skip the hidden files.
Change-Id: Ibbf7010d525cc831a009f3680f84063f40ac570f
Reviewed-on: https://go-review.googlesource.com/14825
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It is now the user's job to track the lifetime of a glutil.Image
relative to a (currently implicit, soon to be explicit) GL context.
This is an attempt to move glutil.Image closer to the model for
buffers and textures in shiny. Long-term, I would like to adopt that
model, and this is a step in that direction. It also makes the
introduction of *gl.Context possible, so this is a pre-req for
cl/13431.
Change-Id: I8e6855211b3e67c97d5831c5c4e443e857c83d50
Reviewed-on: https://go-review.googlesource.com/14795
Reviewed-by: Nigel Tao <nigeltao@golang.org>
We now have one such goroutine for the life of the process, not one per
onInputQueueCreated call (e.g. whenever the app re-gains visibility).
Also use ALooper_wake instead of rolling our own os.Pipe.
Change-Id: I4fa045972289144e083033f2e243cac65f35ee46
Reviewed-on: https://go-review.googlesource.com/14670
Reviewed-by: David Crawshaw <crawshaw@golang.org>
More than a name change, the painting model changes so that the app, not
the library, is responsible for driving painting. If the app is
animating and wants paint events at 60 Hz, it has to ask for that. If
the app is not animating and doesn't need to update its screen, it
shouldn't get any paint events.
Plenty of TODOs, and this CL doesn't get us to a perfect place, but it
is a checkpoint along the way.
The darwin_*.go code changes were minimal. I don't even have a Mac or
iOS device to test that this even builds. Even so, the TODOs about not
sending paint.Events unconditionally are important TODOs. That's the
whole point of switching to this model. I'll leave the actual
implementation to you (crawshaw).
Out of all the example apps, the change to example/network/main.go is
probably the most interesting.
It seems like there ought to be some way to reduce the copy/paste
between all of the example app code, but I'll leave that for future CLs.
Change-Id: I17e11c06174110c68e17f7183b2d8af19b6a170e
Reviewed-on: https://go-review.googlesource.com/14300
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Previously, we did:
for {
processEvents() // Process any pending Android input events.
select { // Select Go events (channel send/receives).
etc
}
}
The problem was that if you were blocked on the select because there
were no incoming Go events, then you weren't reading new input events,
and the UI could block indefinitely.
After this CL, input events are processed in a dedicated goroutine,
where it's fine for
for C.AInputQueue_getEvent(q, &e) >= 0 { etc }
to block, and the main loop deals only with Go channels:
for {
select {
etc
}
}
Change-Id: I8ec27a40e220b1d95a6b6fc14347a59833ccfdc8
Reviewed-on: https://go-review.googlesource.com/14500
Reviewed-by: David Crawshaw <crawshaw@golang.org>
A framework generated with gomobile bind -target=ios has two global
constructors: one initializing a data structure and another using it.
These constructors are defined in different translation units, which
(I believe, reasoning from C++ global constructors) means their order
of initialization is undefined.
A capturing block is stack allocated. Its memory is invalid after the
function returns. Make a copy of the interface initializer blocks so
they can be saved to the heap.
Block implementation background:
http://www.cocoawithlove.com/2009/10/how-blocks-are-implemented-and.html
Updates golang/go#12590
Change-Id: Ia7ae9f4bbd8df6e6e79949de54b3e6c48148c700
Reviewed-on: https://go-review.googlesource.com/14549
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Gobind -lang=objc generates code that assume use of ARC.
Set -fobjc-arc to explicitly enable ARC.
Change-Id: Ib0ec7b19773c112c01ed23cb00f1ec9d64946e6b
Reviewed-on: https://go-review.googlesource.com/14544
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Replace the direct access to JavaVM* and the global android Context
instance with a function responsible for running attached correctly
to the JVM. This saves having to replicate the logic for attaching an
OS thread to the JVM. While here, check for any unhandled Java
exceptions.
This supersedes cl/11812.
Change-Id: Ic9291fe64083d2bd983c4f8e309941b9c47d60c2
Reviewed-on: https://go-review.googlesource.com/14162
Reviewed-by: Nigel Tao <nigeltao@golang.org>