As it stands now, we have a pure java wrapper application that simply starts a
subprocess with our pure go binary. I guess what you are saying is that our Go
application needs to become a library, rather than a process. Which is
complicated as I am not sure it can, as our cleanup assumes the pro
This is more work than say writing a bit of C to instantiate a JVM in the
go process for example, and to get what we are after.
On 13 Oct 2017 06:41, "Jakob Borg" wrote:
> On 12 Oct 2017, at 23:43, audrius.butkevic...@gmail.com wrote:
> >
> > Your example has a MainActivity.java.
> > As I said,
Your example has a MainActivity.java.
As I said, this is a Go application, and as it stands it has no Java, so it
doesn't have (and doesn't intend to have) a main activity.
Also, your initialization (Hello.initContentProvider) happens from Java
(not from Go), so my question is still unanswered of
So I've been going back and forth with this
in https://github.com/golang/go/issues/105808.
Syncthing on Android consists of two parts, one is the actual android
UI/wrapper, and second is GOOS=linux GOARCH=arm Go binary that the android
UI starts and manipulates using a rest API.
>From the Go b
Hi,
So I have the following:
https://play.golang.org/p/dcuhh40DFZ
Yet I believe it exposes the following issues:
1. If sendWork is at line 54, it's possible that doWrites will hit line 79,
falsely reporting a timeout case due to timing issues. Correct?
2. In case of a real timeout (where the wri
