Thanks for the clarification!
On Wed, 14 Sep 2016 at 17:07 David Crawshaw wrote:
> Typically yes, a program compiled with the NDK keeps working on newer
> versions of Android. I'm sure there are exceptions but none come to
> mind.
>
> On Wed, Sep 14, 2016 at 10:02 AM, Ged Wed wrote:
> >
> > Gre
I'm sorry to hear that you're having issues. The Go tool should detect that
a cached package in $GOPATH/pkg is out of date and overwrite it. If this is
not happening reliably this may be a bug.
Can you give some details about what you tried, what you expected to happen
and what happened instead
I'll use a concrete example. Substitute with your own.
GOPACKAGE=github.com/mkideal/cli
{ echo "digraph G {"; go list -f '{{ range .Imports }}{{printf "\t%q ->
%q;\n" $.ImportPath .}}{{end}}' $(go list -f '{{join .Deps " "}}'
$GOPACKAGE) $GOPACKAGE | grep '/.*" -> ".*/'; echo "}"; } | dot -Tsvg
On Wed, Sep 14, 2016 at 11:51 AM, 'simon place' via golang-nuts
wrote:
> what about when you're writing a lib, can't the importing code make use of
> constants?
No warning about an unused variable or constant would ever apply to an
exported name. That would not make sense.
Ian
> On Monday, 12
what about when you're writing a lib, can't the importing code make use of
constants?
On Monday, 12 September 2016 13:57:15 UTC+1, Markus Zimmermann wrote:
>
> Hi gophers!
>
> I am wondering why we have a "declared and not used" compile error for
> variables [https://play.golang.org/p/KLzHVO5L7
We've recently migrated from Go 1.6 to 1.7 within our engineering team, and
have been experiencing some binary compatibility issues (as is to be
expected) that have usually been corrected by emptying $GOPATH/pkg and
rebuilding - this was recommended but as is the case with manual steps,
people
A difference:
- it isn't possible to derive the address of a named variable from the
address of another named variable
- it is possible to derive the value of a named const from another named
const
const (
a = 0 // b-1, c-2
b = 1 // a+1, c-1
c = 2 // a+2, b+1
)
Re
Am Mittwoch, 14. September 2016 15:43:14 UTC+2 schrieb Markus Zimmermann:
>
> On Wednesday, September 14, 2016 at 3:37:10 PM UTC+2, Alan Donovan wrote:
>>
>> On 14 September 2016 at 09:32, Markus Zimmermann
>> wrote:
>>>
>>> Do you think this might be worth bringing up in golang-dev?
>>>
>>
>> N
On Wed, Sep 14, 2016 at 6:43 AM, Markus Zimmermann wrote:
> On Wednesday, September 14, 2016 at 3:37:10 PM UTC+2, Alan Donovan wrote:
>>
>> On 14 September 2016 at 09:32, Markus Zimmermann wrote:
>>>
>>> Do you think this might be worth bringing up in golang-dev?
>>
>>
>> No. We can't make this
Not very elegant but: https://play.golang.org/p/m6WFioPURM
On Wednesday, September 14, 2016 at 9:06:41 AM UTC-6, Luke wrote:
>
> Hi,
>
> i have something like: https://play.golang.org/p/j5WhDMUTI-
>
> type A struct {
>Name string `json:"n"`
>Typ byte `json:"t"`
> }
>
> JSON string:
Hi,
i have something like: https://play.golang.org/p/j5WhDMUTI-
type A struct {
Name string `json:"n"`
Typ byte `json:"t"`
}
JSON string:
j := `{"n":"test", "t":"x"}`
When I try to do
a := A{}
json.Unmarshal([]byte(j), &a)
I get error like: *json: cannot unmarshal string into
Typically yes, a program compiled with the NDK keeps working on newer
versions of Android. I'm sure there are exceptions but none come to
mind.
On Wed, Sep 14, 2016 at 10:02 AM, Ged Wed wrote:
>
> Great thanks David.
>
> So if i pick version 21 (i think that was kit kat), then any android version
:!go test works great... thank you
On Wednesday, September 14, 2016 at 8:41:15 AM UTC-4, Jan Mercl wrote:
>
> On Fri, Sep 9, 2016 at 5:43 PM Luke >
> wrote:
>
> > I am trying to figure out how to see the whole output of command `go
> test` (:GoTest) in VIM... I use vim-go. Right now, it just say
Great thanks David.
So if i pick version 21 (i think that was kit kat), then any android
version above that will work ?
I am thinking of aiming low initially and see how well that works for the
developers calling it from their Java and Swift GUI layers.
G
On Wed, 14 Sep 2016 at 15:34 David Cra
On Wednesday, September 14, 2016 at 3:37:10 PM UTC+2, Alan Donovan wrote:
>
> On 14 September 2016 at 09:32, Markus Zimmermann > wrote:
>>
>> Do you think this might be worth bringing up in golang-dev?
>>
>
> No. We can't make this change to the language without breaking existing
> programs.
>
On Wednesday, September 14, 2016 at 3:47:29 PM UTC+2, Chris Hines wrote:
>
> On Monday, September 12, 2016 at 8:57:15 AM UTC-4, Markus Zimmermann wrote:
>>
>> Hi gophers!
>>
>> I am wondering why we have a "declared and not used" compile error for
>> variables [https://play.golang.org/p/KLzHVO5L7q
On Monday, September 12, 2016 at 8:57:15 AM UTC-4, Markus Zimmermann wrote:
>
> Hi gophers!
>
> I am wondering why we have a "declared and not used" compile error for
> variables [https://play.golang.org/p/KLzHVO5L7q] but not for constants [
> https://play.golang.org/p/JG9dSa_VKg]? I am sure there
On 14 September 2016 at 09:32, Markus Zimmermann wrote:
>
> Do you think this might be worth bringing up in golang-dev?
>
No. We can't make this change to the language without breaking existing
programs.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts
-golang-dev (which is for discussing the development of Go), +golang-nuts
I'm not sure I follow your question. The Android NDK has platform
version targets which correspond to particular versions of Android. If
you build against a target, you can run on that version of Android or
newer. The gomobi
On Tuesday, September 13, 2016 at 3:50:12 PM UTC+2, Alan Donovan wrote:
>
> On 13 September 2016 at 08:22, Markus Zimmermann > wrote:
>
>> On Monday, September 12, 2016 at 3:41:35 PM UTC+2, adon...@google.com
>> wrote:
>>>
>>> unused constants and types cost nothing at run time. It's not that
>
On Wednesday, September 14, 2016 at 3:17:19 PM UTC+3, viljo...@gmail.com
wrote:
>
> Hi,
>
> To start off I'm fairly new to Go, I would just like to know the following:
>
> If I make changes similar to yours in common.go, how would I be able to
> make use of them in my main package.
>
> For exampl
On Fri, Sep 9, 2016 at 5:43 PM Luke wrote:
> I am trying to figure out how to see the whole output of command `go
test` (:GoTest) in VIM... I use vim-go. Right now, it just says if it was a
failure or success, however I also print out some logs using t.Logf and
this output is not being shown anyw
Hi Luke,
Right now there is no way to see the output. However if you use
NeoVim, it connects the stdout to an internal vim terminal and you can
see the output directly. In Vim we only parse the error failures and
put the inside a quickfix window, so you can go over them and fix
them.
Regards
On
Hi,
To start off I'm fairly new to Go, I would just like to know the following:
If I make changes similar to yours in common.go, how would I be able to
make use of them in my main package.
For example in my common.go file I added the following
common.go
func returnCiphers() []string {
>
> One WIP http://www.doc.ic.ac.uk/~cn06/pub/2016/dingo/
>
Man, this is cool! Thanks for the link. They say their deadlock detector
only works for unbounded buffers. Nevertheless, this closes a very
important gap. If I only think of the years I spent reproducing deadlocks
and race conditions
I'd like to be able to copy the http.DefaultTransport then tweak it for
my app.
http.DefaultTransport has a lot of good defaults in, so copying it then
tweaking it makes it forward compatible with changes (a good example of
a recent change would be the ExpectContinueTimeout).
You might think you
On Wed, Sep 14, 2016 at 10:40 AM josvazg wrote:
> When analyzing the code the model could distinguish "executors", which
cold be goroutines (main - the entry one, g1, g2, etc) or pieces of code
under a certain lock variable.
If a variable is ONLY accessed by a single "executor" (including locks)
I don't agree with your latest lines, maybe is cause I miss something but...
When analyzing the code the model could distinguish "executors", which cold
be goroutines (main - the entry one, g1, g2, etc) or pieces of code under a
certain lock variable.
If a variable is ONLY accessed by a single "
28 matches
Mail list logo
