Re: [go-nuts] calling go functions from c

[webuser1200]

Thanks for reading my question. I'm trying to map c  to Go "C."

C int -> go C.int
C unsigned char -> ?
C char -> ?
C unsigned short -> ?
C double -> ?
C __int64 -> ?
C *char -> C.string


On Friday, September 30, 2016 at 1:27:13 AM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Sep 29, 2016 at 8:59 PM,   
> wrote: 
> > I have a basic example working of calling back into go from C. If I have 
> a C 
> > function as: 
> > 
> > func Add(a, b C.Int) C.Int { 
> > return a + b 
> > } 
> > 
> > Where is the mapping of C type to C. when I want to pass 
> additional 
> > types to Go : 
> > 
> > 1. Unsigned int 
> > 2. char 
> > 3. double 
> > 4. string 
> > 5. short 
> > etc... 
>
> I'm sorry, I don't understand the question.  The C type int maps to 
> the Go type C.int. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] calling go functions from c

[Ian Lance Taylor]

On Thu, Sep 29, 2016 at 8:59 PM,   wrote:
> I have a basic example working of calling back into go from C. If I have a C
> function as:
>
> func Add(a, b C.Int) C.Int {
> return a + b
> }
>
> Where is the mapping of C type to C. when I want to pass additional
> types to Go :
>
> 1. Unsigned int
> 2. char
> 3. double
> 4. string
> 5. short
> etc...

I'm sorry, I don't understand the question.  The C type int maps to
the Go type C.int.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: SimpleHttpServer built into go toolchain?

[Harley Laue]

Go does build as a static binary. However, if all you're doing in
production is serving static files, nginx is a better solution. Python and
SimpleHTTPServer isn't for production anyway. Best of luck in your
deployment. Maybe you'll be able to find a use case for Go in your future
endeavors. If not, that's cool too. Use the best tool to accomplish your
goals. :)

On Thu, Sep 29, 2016, 9:16 PM Darren Hoo  wrote:

> Sure, for  my development environment, I can do all this..
>
> But on a server with only Go installed, in order to use go get,  I have to
> setup GOPATH,  I have to installed git. And I have to cross the great
> firewall of china.
>
> Oh my god, thank you guys. forget what I said. Go is not built for doing
> such a simple thing.
>
> To myself: Man!, just stick with Python
>
>
> On Friday, September 30, 2016 at 11:43:29 AM UTC+8, Diego Medina wrote:
>>
>> Hi,
>>
>> If you don't want to have to copy/paste that snippet of code on a new
>> laptop/OS install, I have been using:
>>
>> $ go get github.com/rif/spark
>> $ spark static_site/
>>
>> for the last couple of years, works great, it's simple.
>>
>> https://github.com/rif/spark
>>
>> Regards,
>>
>> Diego
>>
>> On Thursday, September 29, 2016 at 11:10:29 PM UTC-4, Dave Cheney wrote:
>>>
>>> > Since Go is battery included and http is part of its core  library,
>>>
>>> We said batteries, not the kitchen sink.
>>>
>>> But seriously, the standard library gives you the components to build
>>> these tools yourself. If the Go distro included a http server that just
>>> served static files, while this would be perfect for your use case, others
>>> who wanted a server that forwarded to FastCGI would be incensed that Go
>>> shipped with such a limited tool, and furthermore we refused to improve it.
>>> It's better to give you the tools to write exactly the program you want,
>>> then you can share it with the world via go get.
>>>
>>> On Friday, 30 September 2016 12:14:26 UTC+10, Darren Hoo wrote:

 One thing that I really like about python is this one command line to
 serve static files:

  python -m SimpleHTTPServer


 This is very convenient.


 Now I just want to use Go to do the same thing, I have to copy the
 snippet from

 https://github.com/golang/go/wiki/HttpStaticFiles and go run it.


 Since Go is battery included and http is part of its core  library, why
 not

 just build it into the Go toolchain, So every time I want to serve
 static files,

 I can fire up go like this:


  go tool http  /usr/share/doc


  go tool http  --addr=: /usr/share/doc





 --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: SimpleHttpServer built into go toolchain?

[Darren Hoo]

Sure, for  my development environment, I can do all this..

But on a server with only Go installed, in order to use go get,  I have to 
setup GOPATH,  I have to installed git. And I have to cross the great 
firewall of china.

Oh my god, thank you guys. forget what I said. Go is not built for doing 
such a simple thing.

To myself: Man!, just stick with Python


On Friday, September 30, 2016 at 11:43:29 AM UTC+8, Diego Medina wrote:
>
> Hi,
>
> If you don't want to have to copy/paste that snippet of code on a new 
> laptop/OS install, I have been using:
>
> $ go get github.com/rif/spark
> $ spark static_site/
>
> for the last couple of years, works great, it's simple.
>
> https://github.com/rif/spark
>
> Regards,
>
> Diego
>
> On Thursday, September 29, 2016 at 11:10:29 PM UTC-4, Dave Cheney wrote:
>>
>> > Since Go is battery included and http is part of its core  library,
>>
>> We said batteries, not the kitchen sink.
>>
>> But seriously, the standard library gives you the components to build 
>> these tools yourself. If the Go distro included a http server that just 
>> served static files, while this would be perfect for your use case, others 
>> who wanted a server that forwarded to FastCGI would be incensed that Go 
>> shipped with such a limited tool, and furthermore we refused to improve it. 
>> It's better to give you the tools to write exactly the program you want, 
>> then you can share it with the world via go get.
>>
>> On Friday, 30 September 2016 12:14:26 UTC+10, Darren Hoo wrote:
>>>
>>> One thing that I really like about python is this one command line to 
>>> serve static files:
>>>
>>>  python -m SimpleHTTPServer
>>>
>>>
>>> This is very convenient. 
>>>
>>>
>>> Now I just want to use Go to do the same thing, I have to copy the 
>>> snippet from 
>>>
>>> https://github.com/golang/go/wiki/HttpStaticFiles and go run it.
>>>
>>>
>>> Since Go is battery included and http is part of its core  library, why 
>>> not 
>>>
>>> just build it into the Go toolchain, So every time I want to serve 
>>> static files, 
>>>
>>> I can fire up go like this:
>>>
>>>
>>>  go tool http  /usr/share/doc
>>>
>>>
>>>  go tool http  --addr=: /usr/share/doc
>>>
>>>
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] calling go functions from c

[webuser1200]

I have a basic example working of calling back into go from C. If I have a 
C function as:

func Add(a, b C.Int) C.Int {
return a + b
}

Where is the mapping of C type to C. when I want to pass additional 
types to Go :

1. Unsigned int
2. char
3. double
4. string
5. short
etc...


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: SimpleHttpServer built into go toolchain?

[Diego Medina]

Hi,

If you don't want to have to copy/paste that snippet of code on a new 
laptop/OS install, I have been using:

$ go get github.com/rif/spark
$ spark static_site/

for the last couple of years, works great, it's simple.

https://github.com/rif/spark

Regards,

Diego

On Thursday, September 29, 2016 at 11:10:29 PM UTC-4, Dave Cheney wrote:
>
> > Since Go is battery included and http is part of its core  library,
>
> We said batteries, not the kitchen sink.
>
> But seriously, the standard library gives you the components to build 
> these tools yourself. If the Go distro included a http server that just 
> served static files, while this would be perfect for your use case, others 
> who wanted a server that forwarded to FastCGI would be incensed that Go 
> shipped with such a limited tool, and furthermore we refused to improve it. 
> It's better to give you the tools to write exactly the program you want, 
> then you can share it with the world via go get.
>
> On Friday, 30 September 2016 12:14:26 UTC+10, Darren Hoo wrote:
>>
>> One thing that I really like about python is this one command line to 
>> serve static files:
>>
>>  python -m SimpleHTTPServer
>>
>>
>> This is very convenient. 
>>
>>
>> Now I just want to use Go to do the same thing, I have to copy the 
>> snippet from 
>>
>> https://github.com/golang/go/wiki/HttpStaticFiles and go run it.
>>
>>
>> Since Go is battery included and http is part of its core  library, why 
>> not 
>>
>> just build it into the Go toolchain, So every time I want to serve static 
>> files, 
>>
>> I can fire up go like this:
>>
>>
>>  go tool http  /usr/share/doc
>>
>>
>>  go tool http  --addr=: /usr/share/doc
>>
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: go escape analysis

[刘桂祥]

package main

func main() {
var m map[int]int

{
m = make(map[int]int)
}

_ = m
}

if I do this m will not escape just want to know what's the scope rule for 
escape ?  puzzled 

 

在 2016年9月29日星期四 UTC+8上午1:39:09，Chris Manghane写道：
>
> In the first example, make does not escape the scope of the for statement. 
> In the second example, make is assigned to m, which is outside of the scope 
> of the for statement, which means the make operation escapes its scope and 
> subsequently, is heap allocated. If you want more information about why 
> something escapes, try compiling with -gcflags "-m -m" for an explanation 
> of the escape analysis information.
>
> On Wed, Sep 28, 2016 at 7:56 AM, 刘桂祥  
> wrote:
>
>> go 1.7
>>
>> 在 2016年9月28日星期三 UTC+8下午10:41:09，Dave Cheney写道：
>>
>>> Which version of Go?
>>>
>>> On Thursday, 29 September 2016 00:18:29 UTC+10, 刘桂祥 wrote:

 // example1.go
 package main


 func main() {

 for i := 0; i < 2; i++ {
 m := make(map[int]int) 

  

 m[1] = 100 
 }   


 }


 main make(map[int]int) does not escape


 // example2.go
 package main


 func main() {
 var m map[int]int
 for i := 0; i < 2; i++ {
 m = make(map[int]int) 

  

 m[1] = 100 
 }   


 }

  make(map[int]int) escapes to heapwhy ???


 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: SimpleHttpServer built into go toolchain?

[Dave Cheney]

> Since Go is battery included and http is part of its core  library,

We said batteries, not the kitchen sink.

But seriously, the standard library gives you the components to build these 
tools yourself. If the Go distro included a http server that just served 
static files, while this would be perfect for your use case, others who 
wanted a server that forwarded to FastCGI would be incensed that Go shipped 
with such a limited tool, and furthermore we refused to improve it. It's 
better to give you the tools to write exactly the program you want, then 
you can share it with the world via go get.

On Friday, 30 September 2016 12:14:26 UTC+10, Darren Hoo wrote:
>
> One thing that I really like about python is this one command line to 
> serve static files:
>
>  python -m SimpleHTTPServer
>
>
> This is very convenient. 
>
>
> Now I just want to use Go to do the same thing, I have to copy the snippet 
> from 
>
> https://github.com/golang/go/wiki/HttpStaticFiles and go run it.
>
>
> Since Go is battery included and http is part of its core  library, why 
> not 
>
> just build it into the Go toolchain, So every time I want to serve static 
> files, 
>
> I can fire up go like this:
>
>
>  go tool http  /usr/share/doc
>
>
>  go tool http  --addr=: /usr/share/doc
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] SimpleHttpServer built into go toolchain?

[Darren Hoo]

One thing that I really like about python is this one command line to serve 
static files:

 python -m SimpleHTTPServer


This is very convenient. 


Now I just want to use Go to do the same thing, I have to copy the snippet 
from 

https://github.com/golang/go/wiki/HttpStaticFiles and go run it.


Since Go is battery included and http is part of its core  library, why not 

just build it into the Go toolchain, So every time I want to serve static 
files, 

I can fire up go like this:


 go tool http  /usr/share/doc


 go tool http  --addr=: /usr/share/doc




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Getting a snapshot of point-in-time allocation

[Caleb Spare]

Of course now that I sent this email, I have just noticed this pprof flag:

  -baseShow delta from this profile

I haven't tried it yet, but this seems like it might solve these problems.

-Caleb

On Thu, Sep 29, 2016 at 2:12 PM, Caleb Spare  wrote:
> pprof gives two kinds of heap profiles: (please let me know if any of
> this is not correct)
>
> - inuse_space -- a profile of the currently live objects/bytes on the heap
> - alloc_space -- a profile of the allocated objects/bytes since program 
> startup
>
> When I need to figure out why my heap is so big, inuse_space is
> usually very helpful. However, I've found that alloc_space is
> sometimes less helpful for the other kind of memory analysis I
> typically need to perform.
>
> Here are two scenarios I've hit in which alloc_space doesn't quite cut it:
>
> - A server operates by allocating a bunch of large data structures on
> startup and then starts handling requests. I'd like to optimize the
> request handling and reduce some allocations but alloc_space is
> initially dominated by the initialization.
> - A server has been running normally for days and then suddenly starts
> allocating somewhat more than usual. I look at an alloc_space profile,
> but it's dominated by the allocations from normal operation.
>
> What I'd really like is some better way to profile recent allocations.
> It seems like two options could be (a) another heap profile mode that
> shows allocations since the last GC or (b) a way to ask the runtime to
> reset allocation counts.
>
> Am I making sense? Did I misunderstand how all this works or miss some
> profiling feature?
>
> Thanks!
> Caleb

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Getting a snapshot of point-in-time allocation

[Caleb Spare]

pprof gives two kinds of heap profiles: (please let me know if any of
this is not correct)

- inuse_space -- a profile of the currently live objects/bytes on the heap
- alloc_space -- a profile of the allocated objects/bytes since program startup

When I need to figure out why my heap is so big, inuse_space is
usually very helpful. However, I've found that alloc_space is
sometimes less helpful for the other kind of memory analysis I
typically need to perform.

Here are two scenarios I've hit in which alloc_space doesn't quite cut it:

- A server operates by allocating a bunch of large data structures on
startup and then starts handling requests. I'd like to optimize the
request handling and reduce some allocations but alloc_space is
initially dominated by the initialization.
- A server has been running normally for days and then suddenly starts
allocating somewhat more than usual. I look at an alloc_space profile,
but it's dominated by the allocations from normal operation.

What I'd really like is some better way to profile recent allocations.
It seems like two options could be (a) another heap profile mode that
shows allocations since the last GC or (b) a way to ask the runtime to
reset allocation counts.

Am I making sense? Did I misunderstand how all this works or miss some
profiling feature?

Thanks!
Caleb

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: I want a Gopher Squishable

[Roberto Zanotto]

They definitely were on the merchandise store, seems like they're sold out.
No idea when they will be available again.
Some big Go conferences give them away for free.

On Thursday, September 29, 2016 at 8:58:47 PM UTC+2, Esteban Rodríguez 
Betancourt wrote:
>
> Hello!
> I want to buy a gopher squishable, but in the Google Merchandise Store 
> that item is not found (neither the T-shirts). Somebody knows where I could 
> get one, or when it will be available again?
> I'm not sure if I should file a bug about that :p .
>
> Thanks,
> Esteban
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Wordbreak and word extraction in Go?

['Ingo Oeser' via golang-nuts]

thx Marcel,

filed an issue here: https://github.com/golang/go/issues/17256

if you could outline a possible designe there, that would be great.

On Thursday, September 22, 2016 at 5:51:48 PM UTC+2, Marcel van Lohuizen 
wrote:
>
> Hi Ingo,
>
> Thanks for your interest in x/text!  Text segmentation is high on the 
> priority list for x/text, but not yet implemented. Indeed, x/text/cases 
> implements a (close) approximation of Annex #29 optimized for title casing, 
> but it is not the full thing.
>
> For now, if your main interest is word segmentation, your best bet is to 
> use github.com/blevesearch/segment. This is a decent implementation of 
> Annex #29 for word breaking. I've been talking with Marty to see if this 
> can be integrated with x/text even.
>
> But it would help to file an issue with exactly what you need.
>
> Please let me know if you have any other questions.
>
> Best regards,
>
> Marcel
>
>
> On Wed, Sep 21, 2016 at 5:41 AM, Nigel Tao  > wrote:
>
>> On Wed, Sep 21, 2016 at 7:34 AM, 'Ingo Oeser' via golang-nuts
>>  wrote:
>> > I am pretty sure I am overlooking something in the repository 
>> https://godoc.org/golang.org/x/text but I cannot find something to split 
>> text into words according to the next Unicode word splitting algorithm.
>> >
>> > Has anyone examples or can point me to the right direction? Can anyone 
>> confirm that this is missing? If missing, I would like to file an issue 
>> against the text repository for this.
>>
>> I'd ask mpvl (CC'ed).
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

['Axel Wagner' via golang-nuts]

On Thu, Sep 29, 2016 at 9:09 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Thu, 29 Sep 2016 19:35:49 +0200
> Axel Wagner  wrote:
>
> [...]
> > > With type assertions, I really fail to see how returning the zero
> > > value for the target type in case the type assertion failed can be
> > > useful.
> > >
> >
> > For example: You are using context.Context, save a thing under a
> > given key and then provide functions to extract it and do stuff to it
> > (say, you have a logger saved in a context). You also make, as a good
> > go citizen, the zero value of the thing useful.
> > You can still write that, like this:
> >
> > func Log(ctx context.Context, fmt string, v ...interface{}) {
> > l, _ := ctx.Value(loggerKey).(*Logger)
> > l.Printf(fmt, v...)
> > }
>
> Henrik tried to highlight a caveat of this approach:
>
> 8<
> package main
>
> type Logger struct {
> }
>
> func (l *Logger) Printf(args ...interface{}) {
> // Do nothing, intentionally to be OK with nils
> }
>
> func main() {
> var n int = 42
>
> var wi interface{} = n
>
> l, _ := wi.(Logger)
> l.Printf("whatever")
> }
> 8<
>
> (Playground link: ).
>
> This program does not crash, it called a method on a Logger-typed value
> which was "automagically produced" from an integer by actively abusing

the two-argument form of type assertion.


> It's abusing because if you want to call functions on your logger while
> not being interested whether it was set or not, you just don't need to
> do anything besides type-asserting its container value to be *Logger.
> That works because interface{} contains two things: the type and the
> value of that type.  The latter can perfectly be nil for pointer types.
>
> To demonstrate:
>
> 8<
> package main
>
> import "fmt"
>
> type Logger struct {
> }
>
> func (l *Logger) Printf(args ...interface{}) {
> if l == nil {
> fmt.Println("I'm nil")
> } else {
> fmt.Println("I'm not nil")
> }
> }
>
> func main() {
> set := {}
> missing := (*Logger)(nil)
>
> var wi interface{}
>
> wi = set
> log(wi)
>
> wi = missing
> log(wi)
> }
>
> func log(wi interface{}) {
> l := wi.(*Logger)
> l.Printf()
> }
> 8<
>
> (Playground link: ).
>
> As you can see here, we "blindly" type-assert the value to be *Logger
> in the log() function using it, and on the first call that
> "decapsulates" a non-nil pointer value while on the second call it
> fetches a nil value.  The point is: in both cases these values have
> the type *Logger.
>
> Maybe you forgot about the distinction between a nil value of interface
> type and a nil value _contained_ in an interface value?
> I mean .
>

No, I didn't (why do people tend to assume that other people don't know the
language as well as they do?). Your code would violate (if it actually
where similar to mine) a different "rule" for idiomatic use of
context.Context, which is that you should not have to assume that a given
key exists, i.e. the values saved in a context should be optional. In your
case, there needs to be *something* passed to log, which means (if you
will) that now your log-function doesn't use the zero value as a useful
thing. Or, if you prefer, it implies that I wrap my stuff always and
unconditionally in your logging-middleware (which makes it not only
potentially annoying, it also adds another indirection in the common case
to support an edge-case, because even a nil-value saved in a context does
add another link in the linked list that is context.Context).

Your code works differently (and is strictly worse, even if not necessarily
by much), precisely *because* of that difference you so helpfully pointed
out; a typed nil in an interface is still not the zero value.


But, again, I also wasn't really trying to argue in favor of either type
assertions not panic'ing nor map accesses panic'ing. What I was arguing in
favor of is that there is an inconsistency here, for better or for worse. I
think I myself believe the way it's now is actively the better way, even
*though* it's inconsistent. But the way everyone kept saying "no it isn't",
instead of "yes, it is, but it's better this way" seemed kind of weird to
me.

I find Ian's reply very satisfactory. Thanks for looking up the historical
context :) I think these kinds of questions need more replies like that.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Ian Lance Taylor]

On Thu, Sep 29, 2016 at 12:08 AM, T L  wrote:
>
> On Thursday, September 29, 2016 at 1:31:41 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Wed, Sep 28, 2016 at 10:02 PM, T L  wrote:
>> >
>> > On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote:
>> >>
>> >> The reason is directly stated in the Go language spec:
>> >>
>> >> "If the type assertion holds, the value of the expression is the value
>> >> stored in x and its type is T. If the type assertion is false, a
>> >> run-time
>> >> panic occurs."
>> >>
>> >> Here "hold" means if it succeeds.
>> >>
>> >
>> > I know of the syntax in spec.
>> > I just want to understand what is the deep reason for the syntax
>> > inconsistency between map index and type assert.
>>
>> Why do you think there is an inconsistency?
>>
>> Let me put it another way.  A type assertion and a map index are two
>> different kinds of expressions.  They do different things.  What kind
>> of consistency do you expect between them?
>
>
> I just feel that It is weird that the behavior of type assertion depends on
> whether the second OK result variable is provided or not.

This conversation has reminded me that early in the development of the
language map lookups worked like type assertions: if you wrote m[k],
and k was not present in the map, then you got a run-time panic.  In
other words, exactly like when writing v.(T), if v is not of type T,
you get a run-time panic.  For both cases, the comma-ok statement let
you check whether the result succeeded without having the panic.  So,
back then, the two statements did not have the inconsistency that
concerns you.

The behavior for maps changed with
https://codereview.appspot.com/673042.  The discussion that led to the
change was 
https://groups.google.com/forum/#!msg/golang-nuts/2VQ7h0CMkjg/2qE3rFSfo_4J
.

So, OK, from a certain perspective, there is an inconsistency.  And
the reason there is an inconsistency is that it made Go programming
easier to not have maps panic.

But I think type assertion are a very different matter.  I don't think
anybody wants to write a Go program that has a type assertion that
silently fails.  The only possible argument for that being a good idea
would be to avoid something that looks like it might be an
inconsistency.  That is, in my opinion, a terrible argument.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Konstantin Khomoutov]

On Thu, 29 Sep 2016 19:35:49 +0200
Axel Wagner  wrote:

[...]
> > With type assertions, I really fail to see how returning the zero
> > value for the target type in case the type assertion failed can be
> > useful.
> >
> 
> For example: You are using context.Context, save a thing under a
> given key and then provide functions to extract it and do stuff to it
> (say, you have a logger saved in a context). You also make, as a good
> go citizen, the zero value of the thing useful.
> You can still write that, like this:
> 
> func Log(ctx context.Context, fmt string, v ...interface{}) {
> l, _ := ctx.Value(loggerKey).(*Logger)
> l.Printf(fmt, v...)
> }

Henrik tried to highlight a caveat of this approach:

8<
package main

type Logger struct {
}

func (l *Logger) Printf(args ...interface{}) {
// Do nothing, intentionally to be OK with nils
}

func main() {
var n int = 42

var wi interface{} = n

l, _ := wi.(Logger)
l.Printf("whatever")
}
8<

(Playground link: ).

This program does not crash, it called a method on a Logger-typed value
which was "automagically produced" from an integer by actively abusing
the two-argument form of type assertion.

It's abusing because if you want to call functions on your logger while
not being interested whether it was set or not, you just don't need to
do anything besides type-asserting its container value to be *Logger.
That works because interface{} contains two things: the type and the
value of that type.  The latter can perfectly be nil for pointer types.

To demonstrate:

8<
package main

import "fmt"

type Logger struct {
}

func (l *Logger) Printf(args ...interface{}) {
if l == nil {
fmt.Println("I'm nil")
} else {
fmt.Println("I'm not nil")
}
}

func main() {
set := {}
missing := (*Logger)(nil)

var wi interface{}

wi = set
log(wi)

wi = missing
log(wi)
}

func log(wi interface{}) {
l := wi.(*Logger)
l.Printf()
}
8<

(Playground link: ).

As you can see here, we "blindly" type-assert the value to be *Logger
in the log() function using it, and on the first call that
"decapsulates" a non-nil pointer value while on the second call it
fetches a nil value.  The point is: in both cases these values have
the type *Logger.

Maybe you forgot about the distinction between a nil value of interface
type and a nil value _contained_ in an interface value?
I mean .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] I want a Gopher Squishable

[estebarb]

Hello!
I want to buy a gopher squishable, but in the Google Merchandise Store that 
item is not found (neither the T-shirts). Somebody knows where I could get 
one, or when it will be available again?
I'm not sure if I should file a bug about that :p .

Thanks,
Esteban

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to fork or create a subprocess?

[Aram Hăvărneanu]

You can't use fork in multithreaded programs (except to call exec),
and all Go programs are multithreaded.

You can use os/exec to start new programs, however.

-- 
Aram Hăvărneanu

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

['Axel Wagner' via golang-nuts]

On Thu, Sep 29, 2016 at 7:09 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> I think you still can't "get" the chief distinction: it lies in typing
> not in similarities of syntax.
>
> For
>
>   m := make(map[string]interface{})
>
> there's a well-defined zero value for the type of values this map holds.
>
> While somewhat dubious, this is useful for maps which merely record the
> fact the particular set of keys is "known"; consider:
>
>   m := make(map[string]bool)
>   m["three"] = true
>
> And now:
>
> * m["one"] evaluates to false
> * m["two"] evaluates to false
> * m["three"] evaluates to true
> * m["four"] evaluates to false
> ...and so on.
>
> With type assertions, I really fail to see how returning the zero value
> for the target type in case the type assertion failed can be useful.
>

For example: You are using context.Context, save a thing under a given key
and then provide functions to extract it and do stuff to it (say, you have
a logger saved in a context). You also make, as a good go citizen, the zero
value of the thing useful.
You can still write that, like this:

func Log(ctx context.Context, fmt string, v ...interface{}) {
l, _ := ctx.Value(loggerKey).(*Logger)
l.Printf(fmt, v...)
}

(so, there clearly is no type-problem here, otherwise this wouldn't work or
make sense), if you assume that logging to a nil-*Logger would be a nop. If
the one-argument form were equivalent, you could do

func Log(ctx context.Context, fmt string, v ...interface{}) {
ctx.Value(loggerKey).(*Logger).Printf(fmt, v...)
}

Similarly (and closer to your example):

func WithDebug(ctx context.Context) context.Context {
return context.WithValue(ctx, debugKey, true)
}

func DebugLog(ctx context.Context, fmt.String, v ...interface{}) {
if ctx.Value(debugKey).(bool) {
Debug(ctx, fmt, v...)
}
}

Now, granted, the difference in those particular cases isn't huge, but
there are similar cases to be constructed; basically, every time a) the
zero value is a useful value (which it should be
) and b) you then want to use it in an
expression, you now need to put it into a separate variable.

I think the context-example is particularly illustrative, because you are
supposed to not depend on a value being present in it and you don't have
any other type-information. I'd argue, that it's a sign of idiomatic go
code to use v, _ := ctx.Value(key).(someType); making the zero value a
useful default and then use that default, if it isn't given otherwise.

Claiming that it would be useless to just use a zero value on a failing
type-assertion means contending the notion of zero values being useful
things (see also ). Which
is *exactly* the same notion that make the zero value a reasonable and good
default to return from a map-access.

(that is also the reason why I don't like the implication that a failed
type-assertion is something to panic' about. It's based on the assumption
that zero values are dangerous, broken or useless)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Licenses

['Eric Johnson' via golang-nuts]

On Thursday, September 29, 2016 at 1:12:41 AM UTC-7, dja...@gmail.com wrote:
>
> Hi,
> May be OT, but:
>
> Can i  translate some GPLv2 licensed C code to GO, and publish it under 
> BSD new license ?
> Code comments are from original C code.
>

The correct way to do this would be to perform a "clean-room" 
implementation. Have one person create a specification based on the 
original C library, and have a second person implement the specification. 
Ideally, the form of the specification is neither C nor Go. The second 
person should not, under any circumstances, look at the original C code.

Eric

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Konstantin Khomoutov]

On Thu, 29 Sep 2016 09:38:24 -0700 (PDT)
T L  wrote:

> > > I just expect type asserting on a non-nil interface value
> > > shouldn't 
> > panic. 
> >
> > of course it should panic if the interface holds an unexpected
> > value and you're not checking for correctness with the comma-ok
> > pattern. 
> >
> > Go is a statically typed language and by asserting the wrong type
> > on a variable you have an created an obviously incorrectly typed
> > program. If the compiler was able to deduce that the interface was
> > holding an incorrect value at compile time it would never have
> > allowed such a program to be compiled. 
> >
> > the following two examples both look ridiculous to a Go programmer: 
> >
> > var i int = 42 
> > var b = bool(i) 
> > // b is now false 
> >
> > vs 
> >
> >var i = interface{}(42) 
> > var b = i.(bool) 
> > // b is now false 
> >
> > One shouldn't be able to turn 42 into a "false" in Go. maybe in
> > other languages, but not Go. 
> 
> ok, maybe type assertion is really different from map element access,
> range over slice/map and read from channel.
> The later three can be viewed as special form of function callings,
> but type assertion can't.

I think you still can't "get" the chief distinction: it lies in typing
not in similarities of syntax.

For

  m := make(map[string]interface{})

there's a well-defined zero value for the type of values this map holds.

While somewhat dubious, this is useful for maps which merely record the
fact the particular set of keys is "known"; consider:

  m := make(map[string]bool)
  m["three"] = true

And now:

* m["one"] evaluates to false
* m["two"] evaluates to false
* m["three"] evaluates to true
* m["four"] evaluates to false
...and so on.

With type assertions, I really fail to see how returning the zero value
for the target type in case the type assertion failed can be useful.

That's because type assertions are really used for two cases:

* Conditional switching of the program flow -- such as in "when the
  actual type is T do this, otherwise do that".

* Actually _asserting_ the value is of particular type.
  To assert something means to verify a particular invariant about how
  the world behaves.

  To illustrate, you might assert that 4 / 2 == 2, and if this invariant
  fails, your runtime (or hardware or whatever) is broken and the only
  thing you can sensibly do is to crash your process.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: TimeZone Query: Time Difference between EST and UTC

[Adam Webb]

Hi,

EST is 5 hours difference from UTC. 
https://www.timeanddate.com/time/zones/est

However, most of those locations are currently using EDT which is 4 hours 
due to daylight savings. This is a common confusion of timezones so it 
depends on which one you mean. I live in a place that CST all year and 
doesn't do daylight savings time. 

Cheers,
Adam

On Thursday, 29 September 2016 09:18:03 UTC-6, laxman.v...@gmail.com wrote:
>
> Hi,
>
> Google shows difference between EST and UTC as 4 hours whereas go logic 
> gives 5 hours difference in time. 
>
> https://play.golang.org/p/zHc9hM15iH
>
> Is there any issue in my logic??
>
> Thanks
> LV
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go tcp assembly missing packets

[Behram Khan]

I am trying to use use the tcp assembly package to start reassembling TCP 
streams. I have looked at two examples


https://github.com/google/gopacket/tree/master/examples/httpassembly and 

https://github.com/google/gopacket/tree/master/examples/statsassembly


These example work fine if I am sending small data chunks. If I send bigger 
data, for example 5MB file from source to destination, the golang TCP 
assembly seems to lose data.


When I use tcpdump with tcpflow I can reconstruct the data I sent but the 
golang examples miss big chunks of data during reassembly and I cannot 
reproduce the data that I sent.


When I use tc command to slow down traffic, then the application works just 
fine. That's strange. Is there a limit to the speed at which go library can 
capture packets? Tcpdump seems to capture all the traffic just fine.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 11:48:34 PM UTC+8, andrey mirtchovski 
wrote:
>
> > I just expect type asserting on a non-nil interface value shouldn't 
> panic. 
>
> of course it should panic if the interface holds an unexpected value 
> and you're not checking for correctness with the comma-ok pattern. 
>
> Go is a statically typed language and by asserting the wrong type on a 
> variable you have an created an obviously incorrectly typed program. 
> If the compiler was able to deduce that the interface was holding an 
> incorrect value at compile time it would never have allowed such a 
> program to be compiled. 
>
> the following two examples both look ridiculous to a Go programmer: 
>
> var i int = 42 
> var b = bool(i) 
> // b is now false 
>
> vs 
>
>var i = interface{}(42) 
> var b = i.(bool) 
> // b is now false 
>
> One shouldn't be able to turn 42 into a "false" in Go. maybe in other 
> languages, but not Go. 
>


ok, maybe type assertion is really different from map element access, range 
over slice/map and read from channel.
The later three can be viewed as special form of function callings, but 
type assertion can't.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] TimeZone Query: Time Difference between EST and UTC

[Andy Balholm]

Right now there is a 4-hour difference between Eastern (Daylight) Time and UTC. 
But you asked for “EST”, and that is what you got: Eastern *Standard* Time. If 
you want a Location that automatically switches between EST and EDT, ask for 
“America/New_York”.

Andy

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[andrey mirtchovski]

> I just expect type asserting on a non-nil interface value shouldn't panic.

of course it should panic if the interface holds an unexpected value
and you're not checking for correctness with the comma-ok pattern.

Go is a statically typed language and by asserting the wrong type on a
variable you have an created an obviously incorrectly typed program.
If the compiler was able to deduce that the interface was holding an
incorrect value at compile time it would never have allowed such a
program to be compiled.

the following two examples both look ridiculous to a Go programmer:

var i int = 42
var b = bool(i)
// b is now false

vs

   var i = interface{}(42)
var b = i.(bool)
// b is now false

One shouldn't be able to turn 42 into a "false" in Go. maybe in other
languages, but not Go.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] TimeZone Query: Time Difference between EST and UTC

[laxman . vallandas]

Hi,

Google shows difference between EST and UTC as 4 hours whereas go logic 
gives 5 hours difference in time. 

https://play.golang.org/p/zHc9hM15iH

Is there any issue in my logic??

Thanks
LV

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 8:46:14 PM UTC+8, Konstantin Khomoutov 
wrote:
>
> On Thu, 29 Sep 2016 00:25:23 -0700 (PDT) 
> T L  wrote: 
>
> > > > I just want to understand what is the deep reason for the syntax 
> > > > inconsistency between map index and type assert. 
> > > 
> > > a map is fully typed at compile time. even if its key is of type 
> > > interface{} the language defines how to compare two interface{} 
> > > values using type assertion here: 
> > > https://golang.org/ref/spec#Comparison_operators 
> > > 
> > > "Interface values are comparable. Two interface values are equal if 
> > > they have identical dynamic types and equal dynamic values or if 
> > > both have value nil." 
> > > 
> > > Using interface{} in assignments on the other hand is only 
> > > type-safe at runtime when used with a type assertion. 
> > > 
> > 
> > Aha, it would be more understandable if you can explain it with code. 
> > :), my English is not very good. 
>
> "One argument lookup" of a map containing values of type interface{} 
> produces the zero value for type interface{}.  That's because as Andrey 
> said, such map _itself_ is statically typed: the type of its values is 
> interface{}. 
>
> Conversely, when you type-assert a value of type interface{}, you're 
> making a claim the _real dynamic run-time_ type of the value held in 
> that value of type interface{} is such and such. 
>
> Thus even though both operations superficially look the same, they're 
> doing drastically different things, as Andrey and Dave tried to explain. 
>
> Here's the code: 
>
>   package main 
>   
>   import ( 
>   "fmt" 
>   ) 
>   
>   func main() { 
>   var zvi interface{} // The zero value for type interface{} 
>   
>   m := make(map[string]interface{}) 
>   
>   v := m["abc"] // Returns the zero value for type interface{} 
>   fmt.Println(v == zvi) // Prints "true" 
>   
>   v = zvi.(int64) // panics beause zvi contains no dynamic type 
>   // information. 
>   } 
>

I'm still not convinced by your explanation.
I never expect the last line should not panic. Type asserting on a nil 
interface value is expected to panic (it is a surprise that nil map element 
access doesn't panic).
I just expect type asserting on a non-nil interface value shouldn't panic.

 

>
> Playground link: https://play.golang.org/p/oS7SWHXgJQ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go analysis memory mallocs

[刘桂祥]

if use go1.7
in runtime/malloc.go file add mallocgc debug info and go install and go run 
x.goI will get a error "signal: segmentation fault"
in go1.4.2 will not

func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {
println("mallocgc:size=", size, "kind=", typ.kind, "needzero=", 
needzero)

在 2016年9月29日星期四 UTC+8下午9:04:58，Dave Cheney写道：
>
> You should use Go 1.7.1 or later. 
>
> On Thursday, 29 September 2016 23:00:25 UTC+10, 刘桂祥 wrote:
>>
>> package main
>>
>> import "runtime"
>>
>> func main() {
>> m := new(runtime.MemStats)
>> runtime.ReadMemStats(m)
>> cap := 1024
>> println("debug0")
>> s := make([]byte, cap)
>> println("debug1")
>> _ = s
>> runtime.ReadMemStats(m)
>> println("memstats:", m.Alloc, m.Mallocs)
>> }
>>
>> I use go1.4.2 and In go source code add mallocgc debug info 
>> here is the result:
>> debug0
>> mallocgc: 1024
>> mallocgc: 272
>> mallocgc: 32
>> debug1
>>
>> I doubt there is other goroutine call the mallocgc  
>>  
>> but if I use go test -bench="." makeslice_test.go
>> func BenchmarkMakeSlice2(b *testing.B) {
>> b.ReportAllocs()
>> cap := 1024
>> for i := 0; i < b.N; i++ {
>> s := make([]byte, cap, cap)
>> _ = s
>> }
>> }
>> the output is:
>> 14120 ns/op1024 B/op   1 allocs/op
>> I infer the go test know all the mallocgc and also know which is  user's 
>> source code to call it  
>>
>> my guess
>>
>> 在 2016年9月29日星期四 UTC+8下午5:30:54，Dave Cheney写道：
>>
>>> Sorry, you'll have to work harder to generate a memory profile. My 
>>> github.com/pkg/profile package may help automate some of the work, but 
>>> may introduce a few allocations of its own which you will have to filter 
>>> out. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go analysis memory mallocs

[刘桂祥]

package main

import "runtime"

func main() {
m := new(runtime.MemStats)
runtime.ReadMemStats(m)
cap := 1024
println("debug0")
s := make([]byte, cap)
println("debug1")
_ = s
runtime.ReadMemStats(m)
println("memstats:", m.Alloc, m.Mallocs)
}

I use go1.4.2 and In go source code add mallocgc debug info 
here is the result:
debug0
mallocgc: 1024
mallocgc: 272
mallocgc: 32
debug1

I doubt there is other goroutine call the mallocgc  
 
but if I use go test -bench="." makeslice_test.go
func BenchmarkMakeSlice2(b *testing.B) {
b.ReportAllocs()
cap := 1024
for i := 0; i < b.N; i++ {
s := make([]byte, cap, cap)
_ = s
}
}
the output is:
14120 ns/op1024 B/op   1 allocs/op
I infer the go test know all the mallocgc and also know which is  user's 
source code to call it  

my guess

在 2016年9月29日星期四 UTC+8下午5:30:54，Dave Cheney写道：

> Sorry, you'll have to work harder to generate a memory profile. My 
> github.com/pkg/profile package may help automate some of the work, but 
> may introduce a few allocations of its own which you will have to filter 
> out. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Konstantin Khomoutov]

On Wed, 28 Sep 2016 23:07:06 -0600
andrey mirtchovski  wrote:

> > I just want to understand what is the deep reason for the syntax
> > inconsistency between map index and type assert.
> 
> a map is fully typed at compile time. even if its key is of type
> interface{} the language defines how to compare two interface{} values
> using type assertion here:
> https://golang.org/ref/spec#Comparison_operators
> 
> "Interface values are comparable. Two interface values are equal if
> they have identical dynamic types and equal dynamic values or if both
> have value nil."
> 
> Using interface{} in assignments on the other hand is only type-safe
> at runtime when used with a type assertion.

Kudos for IMO the best explanation of these matters posted to this
thread ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Konstantin Khomoutov]

On Thu, 29 Sep 2016 00:25:23 -0700 (PDT)
T L  wrote:

> > > I just want to understand what is the deep reason for the syntax 
> > > inconsistency between map index and type assert. 
> >
> > a map is fully typed at compile time. even if its key is of type 
> > interface{} the language defines how to compare two interface{}
> > values using type assertion here: 
> > https://golang.org/ref/spec#Comparison_operators 
> >
> > "Interface values are comparable. Two interface values are equal if 
> > they have identical dynamic types and equal dynamic values or if
> > both have value nil." 
> >
> > Using interface{} in assignments on the other hand is only
> > type-safe at runtime when used with a type assertion. 
> >
> 
> Aha, it would be more understandable if you can explain it with code.
> :), my English is not very good.

"One argument lookup" of a map containing values of type interface{}
produces the zero value for type interface{}.  That's because as Andrey
said, such map _itself_ is statically typed: the type of its values is
interface{}.

Conversely, when you type-assert a value of type interface{}, you're
making a claim the _real dynamic run-time_ type of the value held in
that value of type interface{} is such and such.

Thus even though both operations superficially look the same, they're
doing drastically different things, as Andrey and Dave tried to explain.

Here's the code:

  package main
  
  import (
"fmt"
  )
  
  func main() {
var zvi interface{} // The zero value for type interface{}
  
m := make(map[string]interface{})
  
v := m["abc"] // Returns the zero value for type interface{}
fmt.Println(v == zvi) // Prints "true"
  
v = zvi.(int64) // panics beause zvi contains no dynamic type
// information.
  }

Playground link: https://play.golang.org/p/oS7SWHXgJQ

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: glog log rotate not working correctly

[Dave Cheney]

Did you find the open deleted file in /proc/.../fds ?

On Thursday, 29 September 2016 22:37:47 UTC+10, ramkumar.g...@gmail.com 
wrote:
>
> So it looks like a bug in the glog library. Anyway to file a bug against 
> it?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] glog log rotate not working correctly

[ramkumar . gowrishankar]

So it looks like a bug in the glog library. Anyway to file a bug against it?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go-gcnl: Golang library for accessing the Google Cloud Natural Language API

[Daniel Whitenack]

Thanks Josh!

This is a nice complement to the auto generated libraries which as stated:

"Due to the auto-generated nature of this collection of libraries, complete 
APIs or specific versions can appear or go away without notice."

I added your library here:

https://github.com/gopherds/resources/blob/master/tooling/README.md#nlp

Daniel

On Friday, September 2, 2016 at 9:51:30 AM UTC-4, Josh Lubawy wrote:
>
> Hi All,
>
> I made a new library that I thought some people might find useful: 
> https://github.com/jlubawy/go-gcnl
>
> Feedback and feature requests are gladly welcomed!
>
> Thanks,
> Josh
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: gomobile: target=ios, getting incompatible pointer types assigning to 'GoUniverseerror *' from 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]

[Joe Blue]

Yeah i saw thats the way the team were doing it in the example.

I tried it, and sure it works. And it also adds the path.
But there was also lots of mis information about how to use it. gopaths
being hard coded in it etc etc etc.
I saw your comment recently about how to correctly use it.
But i decided to give it a miss because i wanted to have control. I need to
do some crazy stuff with webviews and gomobile you see.

Once i got used to Android Studio and the way it loads the aar packages
etc, i liked it because i had control.
A tiny bit slower at dev time, but at least i see all of Android Studios
crumpiness, and can learn how to tame it.

I think we can definitely CLOSE this. Thanks for the follow up and tips.
Your new Cl's did the trick :)

---
Today, I have hit a new regression for gomobile that is pretty nasty and i
expect will break allot of people.
I will raise it on the offical github issues.
Link to complete code is there !!
Easy to reproduce

https://github.com/golang/go/issues/17277





On Thu, Sep 29, 2016 at 1:26 PM Elias Naur  wrote:

> Is there a reason you're not using the gobind gradle plugin? If you need
> an example, the "bind" app from gomobile uses it to automatically generate
> the aar-file during builds.
>
>  - elias
>
>
> On Thursday, September 29, 2016 at 9:50:17 AM UTC+2, Joe Blue wrote:
>
>> upgrading caused a new problem on the android side.
>>
>> ```
>>
>> Information:Gradle tasks [:app:generateDebugSources,
>> :app:generateDebugAndroidTestSources, :app:mockableAndroidJar,
>> :app:prepareDebugUnitTestDependencies]
>> Error:Execution failed for task ':app:prepareMd01CliUnspecifiedLibrary'.
>> > Could not expand ZIP '/Users/apple/workspace/go/src/
>> github.com/asdine/brazier/_android/md01/cli/cli.aar'.
>> Information:BUILD FAILED
>> Information:Total time: 3.155 secs
>> Information:1 error
>> Information:0 warnings
>> Information:See complete output in console
>>
>> ```
>>
>> its nuts because when i rename the cli.aar to .zip, i can open it on my
>> osx laptop.
>> but android studio seems to not think its NOT a zip.
>>
>> So i changed the gradle to to this:
>>
>> configurations.maybeCreate("default")
>> artifacts.add("default", 
>> file('/Users/apple/workspace/go/src/github.com/asdine/brazier/cli/cli.aar'))
>>
>> that fixed it.
>>
>> It seems that when you use Android Studio > New > New Module > Import .Jar / 
>> -aar package it does not put the path in the gradle file above.
>>
>>
>> little things i know..
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 29, 2016 at 9:21 AM Joe Blue  wrote:
>>
> i upgraded:
>>> gomobile version +9640137 Tue Sep 27 16:37:51 2016 + (android,ios);
>>> androidSDK=/Users/apple/Library/Android/sdk/platforms/android-24
>>>
>>> It fixed all the errors:)
>>>
>>> thankyou
>>>
>>>
>>>
>>>
>>> On Thu, Sep 29, 2016 at 9:13 AM Joe Blue  wrote:
>>>
>> thank Elias. Nice

 I am on this version:

 x-MacBook-Pro:rpc apple$ gomobile version

 gomobile version +7573efa Wed Aug 24 22:21:38 2016 + (android,ios);
 androidSDK=/Users/apple/Library/Android/sdk/platforms/android-24

 I will upgrade now and see if i get the same errors. thanks



 On Wed, Sep 28, 2016 at 5:06 PM Elias Naur  wrote:

>>> Hi,
>
> Use the -work flag to gomobile to output working directory and to
> preserve the generated files.
>
> What revision are your gomobile tool compiled at? CL 29052 should have
> fixed that error.
>
>  - elias
>
>
> On Wednesday, September 28, 2016 at 2:14:30 PM UTC+2, Joe Blue wrote:
>>
>>
>> Hey all,
>>
>> i am compiling code across to IOS & Android.
>>
>> On Android things are working ok it seems.
>>
>> But i get this on ios with: gomobile bind --target=ios -v
>>
>>
>>
>> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>>
>> #
>> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:156:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>> note: instance method 'initWithError:' is assumed to return an instance 
>> of
>> its receiver type ('goSeqErrorWrapper *')
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:178:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> 

Re: [go-nuts] Licenses

[andrey mirtchovski]

> Also, Can I in my BSD licensed GO project, link to GPLv2 library ?

You may link to the library via cgo if the author has given you
permission to do so. Usually this is done via a separate COPYING.LIB
file which contains the GNU LGPLv2 text in the library's repository
(the COPYING file still contains GPLv2). One example that I can think
on top of my head, but it's literally everywhere:

http://procps.cvs.sourceforge.net/procps/procps/

In this case you need to provide sources for the library and full
object files to relink the project if someone wants to, or better yet
always link dynamically.

rabbit hole this way:
http://copyleft.org/guide/comprehensive-gpl-guidech11.html#x14-9600010

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: gomobile: target=ios, getting incompatible pointer types assigning to 'GoUniverseerror *' from 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]

[Elias Naur]

Is there a reason you're not using the gobind gradle plugin? If you need an 
example, the "bind" app from gomobile uses it to automatically generate the 
aar-file during builds.

 - elias

On Thursday, September 29, 2016 at 9:50:17 AM UTC+2, Joe Blue wrote:
>
> upgrading caused a new problem on the android side.
>
> ```
>
> Information:Gradle tasks [:app:generateDebugSources, 
> :app:generateDebugAndroidTestSources, :app:mockableAndroidJar, 
> :app:prepareDebugUnitTestDependencies]
> Error:Execution failed for task ':app:prepareMd01CliUnspecifiedLibrary'.
> > Could not expand ZIP '/Users/apple/workspace/go/src/
> github.com/asdine/brazier/_android/md01/cli/cli.aar'.
> Information:BUILD FAILED
> Information:Total time: 3.155 secs
> Information:1 error
> Information:0 warnings
> Information:See complete output in console
>
> ```
>
> its nuts because when i rename the cli.aar to .zip, i can open it on my 
> osx laptop.
> but android studio seems to not think its NOT a zip.
>
> So i changed the gradle to to this:
>
> configurations.maybeCreate("default")
> artifacts.add("default", 
> file('/Users/apple/workspace/go/src/github.com/asdine/brazier/cli/cli.aar'))
>
> that fixed it.
>
> It seems that when you use Android Studio > New > New Module > Import .Jar / 
> -aar package it does not put the path in the gradle file above.
>
>
> little things i know..
>
>
>
>
>
>
>
>
> On Thu, Sep 29, 2016 at 9:21 AM Joe Blue  
> wrote:
>
>> i upgraded:
>> gomobile version +9640137 Tue Sep 27 16:37:51 2016 + (android,ios); 
>> androidSDK=/Users/apple/Library/Android/sdk/platforms/android-24
>>
>> It fixed all the errors:)
>>
>> thankyou
>>
>>
>>
>>
>> On Thu, Sep 29, 2016 at 9:13 AM Joe Blue  
>> wrote:
>>
>>> thank Elias. Nice
>>>
>>> I am on this version:
>>>
>>> x-MacBook-Pro:rpc apple$ gomobile version
>>>
>>> gomobile version +7573efa Wed Aug 24 22:21:38 2016 + (android,ios); 
>>> androidSDK=/Users/apple/Library/Android/sdk/platforms/android-24
>>>
>>> I will upgrade now and see if i get the same errors. thanks
>>>
>>>
>>>
>>> On Wed, Sep 28, 2016 at 5:06 PM Elias Naur >> > wrote:
>>>
 Hi,

 Use the -work flag to gomobile to output working directory and to 
 preserve the generated files.

 What revision are your gomobile tool compiled at? CL 29052 should have 
 fixed that error.

  - elias


 On Wednesday, September 28, 2016 at 2:14:30 PM UTC+2, Joe Blue wrote:
>
>
> Hey all,
>
> i am compiling code across to IOS & Android.
>
> On Android things are working ok it seems.
>
> But i get this on ios with: gomobile bind --target=ios -v
>
>
>
> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>
> # 
> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:156:11:
>  
> warning: incompatible pointer types assigning to 'GoUniverseerror *' from 
> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>  
> note: instance method 'initWithError:' is assumed to return an instance 
> of 
> its receiver type ('goSeqErrorWrapper *')
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:178:11:
>  
> warning: incompatible pointer types assigning to 'GoUniverseerror *' from 
> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>  
> note: instance method 'initWithError:' is assumed to return an instance 
> of 
> its receiver type ('goSeqErrorWrapper *')
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:202:11:
>  
> warning: incompatible pointer types assigning to 'GoUniverseerror *' from 
> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>  
> note: instance method 'initWithError:' is assumed to return an instance 
> of 
> its receiver type ('goSeqErrorWrapper *')
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:228:11:
>  
> warning: incompatible pointer types assigning to 'GoUniverseerror *' from 
> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>
> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>  
> note: instance method 'initWithError:' is assumed to return an instance 

Re: [go-nuts] Re: Connect In Database

[Josh Kamau]

Let me try ;)

You can use package database/sql to connect to any sql database that has a
golang driver.
Here is a list of some database drivers
https://github.com/golang/go/wiki/SQLDrivers

Here is some documentation: http://go-database-sql.org/

And here is a video https://www.youtube.com/watch?v=m879N2rzn2g

Josh.

On Thu, Sep 29, 2016 at 11:06 AM,  wrote:

>
>
> On Thursday, September 29, 2016 at 1:04:34 AM UTC-7, hadies...@gmail.com
> wrote:
>>
>> Hi
>>
>
>> we can with this *package database/sql*  connect to any databases???
>>
>>
>> if you'r Answer is NO then help me.
>>
>>
>> THANKS
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

['Axel Wagner' via golang-nuts]

I don't understand where we are talking past each other.
I am aware, what the current behavior is. I am (and T L was asking) for
technical reasons why a) any justification for the behavior of the
type-assertion doesn't apply to map-access and b) any justification for the
behavior of the map-access doesn't apply to type-assertions? I don't
believe there is any.

On Thu, Sep 29, 2016 at 11:48 AM, Dave Cheney  wrote:

> That's what happens now with the two arg version, the one arg version
> panics rather than letting you think you got a valid value of the type you
> expected.
>
Why is that a show-stopper for
v := iface.(someType)
but not for
v := someMap[k]

The value will be of type someType either way, it will be just as valid a
value in both cases and the consequences of assuming it's non-zero are just
as dire in both cases.

You could argue that assuming that a key is present in a map is just as
broken an assumption as assuming that an interface value contains a value
of a given type. You could argue that just as
v, _ := someMap[k]
v := someMap[k]
are equivalent,
v, _ := iface.(someType)
v := iface.(someType)
should be equivalent. Or, you could also argue, if you prefer, that just as
v := iface.(someType)
should panic because you shan't just assume that iface contains a someType
and continue working with a possibly invalid value, so should
v := someMap[k]
panic, because you shan't just assume that a map contains a given key and
continue working with a possibly invalid value. You could argue, that
requiring v, _ := iface.(someType) for the non-panicy behavior is better,
because it makes explicit that you've thought about it and are aware that
iface could possibly be something else, but just as well could you argue
that v, _ := someMap[k] for the non-panicy behavior is better for exactly
the same reasons.

Again, I'm not really saying it's a *bad* thing that there is an
inconsistency here, but I also don't think that it can really be argued
that there is much of a technical reason for these two, on the surface very
similar constructs, to behave this differently. I believe the true answer
is "for historical reasons. No one realized this, when converging on the
,ok construct". Which I think would be a fine answer.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Dave Cheney]

That's what happens now with the two arg version, the one arg version
panics rather than letting you think you got a valid value of the type you
expected.

On Thu, 29 Sep 2016, 19:44 Axel Wagner 
wrote:

> The thing you are asserting to, obviously? The types are not a problem if
> you do
> v, ok := iface.(someType)
> v simply has type someType and will be the zero-value if iface doesn't
> contain a someType. Why should this be a problem for the non-comma-ok
> version?
> I.e., what would be the technical difficulty in making
> v := iface.(someType)
> semantically equivalent to
> v, _ := iface.(someType)
> 'cause I don't see any.
>
> On Thu, Sep 29, 2016 at 11:40 AM, Dave Cheney  wrote:
>
>> A type assertion is dangerous because if the thing you are asserting to
>> doesn't match the type of the value inside the interface, what type should
>> the result be? With the map example the type of the result is known.
>>
>> On Thu, 29 Sep 2016, 19:36 Axel Wagner 
>> wrote:
>>
>>> On Thu, Sep 29, 2016 at 9:31 AM, Dave Cheney  wrote:
>>>
 Sorry, I misspoke, this logic does not apply to map lookup
>>>
>>>
>>> But why? It seems to me, everything you said can just as easily be
>>> applied to map lookups. Why is a zero-value on a type-assertion potentially
>>> dangerous, while it's fine on a map-lookup?
>>> I don't see anything in your E-Mail that is specific to type-assertions
>>> (I mean. It's specific to type-assertions as implemented. Just not as
>>> theorized).
>>>
>>> Indeed, you could argue that, as we deal just fine with the behavior for
>>> maps, we would probably deal just fine with the behavior for type
>>> assertions. And that the same conveniences we get from *not* panic'ing on
>>> map-accesses also would apply to type-assertions.
>>>
>>> So… I have to agree, that there is an inconsistency here. I don't think
>>> it's a *bad* thing and I prefer my type-assertions panic'ing and my
>>> map-accesses not-panic'ing, but I would be hard pressed to give a technical
>>> argument why they should be different.
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

['Axel Wagner' via golang-nuts]

The thing you are asserting to, obviously? The types are not a problem if
you do
v, ok := iface.(someType)
v simply has type someType and will be the zero-value if iface doesn't
contain a someType. Why should this be a problem for the non-comma-ok
version?
I.e., what would be the technical difficulty in making
v := iface.(someType)
semantically equivalent to
v, _ := iface.(someType)
'cause I don't see any.

On Thu, Sep 29, 2016 at 11:40 AM, Dave Cheney  wrote:

> A type assertion is dangerous because if the thing you are asserting to
> doesn't match the type of the value inside the interface, what type should
> the result be? With the map example the type of the result is known.
>
> On Thu, 29 Sep 2016, 19:36 Axel Wagner 
> wrote:
>
>> On Thu, Sep 29, 2016 at 9:31 AM, Dave Cheney  wrote:
>>
>>> Sorry, I misspoke, this logic does not apply to map lookup
>>
>>
>> But why? It seems to me, everything you said can just as easily be
>> applied to map lookups. Why is a zero-value on a type-assertion potentially
>> dangerous, while it's fine on a map-lookup?
>> I don't see anything in your E-Mail that is specific to type-assertions
>> (I mean. It's specific to type-assertions as implemented. Just not as
>> theorized).
>>
>> Indeed, you could argue that, as we deal just fine with the behavior for
>> maps, we would probably deal just fine with the behavior for type
>> assertions. And that the same conveniences we get from *not* panic'ing on
>> map-accesses also would apply to type-assertions.
>>
>> So… I have to agree, that there is an inconsistency here. I don't think
>> it's a *bad* thing and I prefer my type-assertions panic'ing and my
>> map-accesses not-panic'ing, but I would be hard pressed to give a technical
>> argument why they should be different.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] image: algorithm to convert to grayscale

[Rodolfo Carvalho]

Thanks everyone for the answers and links.

I computed a pixel-to-pixel difference and indeed what I was getting was
-1/+1 differences in the gray values, due to rounding.

Next free time I'll try the other formulas.


Thank you again,

Rodolfo Carvalho

On Thu, Sep 29, 2016 at 6:12 AM, Micky  wrote:

>
>
> On Thu, Sep 29, 2016 at 3:19 AM, Rodolfo Carvalho 
> wrote:
>
>> gift [3]:
>> y := 0.299*px.R + 0.587*px.G + 0.114*px.B
>>
>> I did not understand why image/color adds an extra 0.5 (500/1000) to y.
>> Could anybody give me a clue?
>>
>
> To directly answer your question:
>
> *GIFT also adds 0.5 to round off. *
>
> Wanna know where? Try to make up a call stack:
>
> gift.Grayscale() > returns Filter > is colorFilter > has a callback fn >
> returns pixel > contains float32s
>
> pixel is a struct containing float32s
> Filter is an interface, made of Draw() and Bounds()
> colorFilter implements Filter
>
> So, it eventually boils down to: [1]
>
> *colorFilter.Draw() > parallelize() > newPixelSetter().SetPixel() >
> f32u16()
>
> color.Color uses uint32s while gift.pixel uses float32s. I guess gift uses
> floats for cosmetic reasons. But they both round off while applying the
> grayscale filter.
>
> [1] https://github.com/disintegration/gift/blob/
> 703be73d60d8baeaa84c47be0d31551b466ea84a/pixels.go#L304
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: go escape analysis

[Dave Cheney]

-gcflags=-m is your guide. There are no documents of the escape analysis done 
by the gc compiler, but you could read the source of 
cmd/compile/internal/gc/esc.go

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Dave Cheney]

A type assertion is dangerous because if the thing you are asserting to
doesn't match the type of the value inside the interface, what type should
the result be? With the map example the type of the result is known.

On Thu, 29 Sep 2016, 19:36 Axel Wagner 
wrote:

> On Thu, Sep 29, 2016 at 9:31 AM, Dave Cheney  wrote:
>
>> Sorry, I misspoke, this logic does not apply to map lookup
>
>
> But why? It seems to me, everything you said can just as easily be applied
> to map lookups. Why is a zero-value on a type-assertion potentially
> dangerous, while it's fine on a map-lookup?
> I don't see anything in your E-Mail that is specific to type-assertions (I
> mean. It's specific to type-assertions as implemented. Just not as
> theorized).
>
> Indeed, you could argue that, as we deal just fine with the behavior for
> maps, we would probably deal just fine with the behavior for type
> assertions. And that the same conveniences we get from *not* panic'ing on
> map-accesses also would apply to type-assertions.
>
> So… I have to agree, that there is an inconsistency here. I don't think
> it's a *bad* thing and I prefer my type-assertions panic'ing and my
> map-accesses not-panic'ing, but I would be hard pressed to give a technical
> argument why they should be different.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

['Axel Wagner' via golang-nuts]

On Thu, Sep 29, 2016 at 9:31 AM, Dave Cheney  wrote:

> Sorry, I misspoke, this logic does not apply to map lookup


But why? It seems to me, everything you said can just as easily be applied
to map lookups. Why is a zero-value on a type-assertion potentially
dangerous, while it's fine on a map-lookup?
I don't see anything in your E-Mail that is specific to type-assertions (I
mean. It's specific to type-assertions as implemented. Just not as
theorized).

Indeed, you could argue that, as we deal just fine with the behavior for
maps, we would probably deal just fine with the behavior for type
assertions. And that the same conveniences we get from *not* panic'ing on
map-accesses also would apply to type-assertions.

So… I have to agree, that there is an inconsistency here. I don't think
it's a *bad* thing and I prefer my type-assertions panic'ing and my
map-accesses not-panic'ing, but I would be hard pressed to give a technical
argument why they should be different.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: go escape analysis

[刘桂祥]

veyr thanks and want to know more about go's compile and escape rules 

在 2016年9月29日星期四 UTC+8上午1:39:09，Chris Manghane写道：
>
> In the first example, make does not escape the scope of the for statement. 
> In the second example, make is assigned to m, which is outside of the scope 
> of the for statement, which means the make operation escapes its scope and 
> subsequently, is heap allocated. If you want more information about why 
> something escapes, try compiling with -gcflags "-m -m" for an explanation 
> of the escape analysis information.
>
> On Wed, Sep 28, 2016 at 7:56 AM, 刘桂祥  
> wrote:
>
>> go 1.7
>>
>> 在 2016年9月28日星期三 UTC+8下午10:41:09，Dave Cheney写道：
>>
>>> Which version of Go?
>>>
>>> On Thursday, 29 September 2016 00:18:29 UTC+10, 刘桂祥 wrote:

 // example1.go
 package main


 func main() {

 for i := 0; i < 2; i++ {
 m := make(map[int]int) 

  

 m[1] = 100 
 }   


 }


 main make(map[int]int) does not escape


 // example2.go
 package main


 func main() {
 var m map[int]int
 for i := 0; i < 2; i++ {
 m = make(map[int]int) 

  

 m[1] = 100 
 }   


 }

  make(map[int]int) escapes to heapwhy ???


 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go analysis memory mallocs

[Dave Cheney]

Sorry, you'll have to work harder to generate a memory profile. My 
github.com/pkg/profile package may help automate some of the work, but may 
introduce a few allocations of its own which you will have to filter out. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go analysis memory mallocs

[刘桂祥]

package main

import "runtime"

func init() {
runtime.MemProfileRate = 1
}
func main() {
m := new(runtime.MemStats)
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
cap := 1024 * 1024 * 4
s := make([]byte, cap)
_ = s
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
}
go run example2.go
32744 65
4228984 76
sorry  add this to example2.go  and the results is a little different  but 
I also don't konw the reason to the results

在 2016年9月29日星期四 UTC+8下午5:07:23，Dave Cheney写道：
>
> One way to do this might be to enable memory profiling in your program 
> with the rate set to 1. Hopefully this will record the stack trace of every 
> allocation. The data may need some interpretation

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go analysis memory mallocs

[刘桂祥]

package main

import "runtime"

func init() {
runtime.MemProfileRate = 1
}
func main() {
m := new(runtime.MemStats)
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
cap := 1024 * 1024 * 4
s := make([]byte, cap)
_ = s
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
}

I add this to example2.go  but the results is the same . Did I use right ??

在 2016年9月29日星期四 UTC+8下午5:07:23，Dave Cheney写道：
>
> One way to do this might be to enable memory profiling in your program 
> with the rate set to 1. Hopefully this will record the stack trace of every 
> allocation. The data may need some interpretation

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go analysis memory mallocs

[Dave Cheney]

One way to do this might be to enable memory profiling in your program with the 
rate set to 1. Hopefully this will record the stack trace of every allocation. 
The data may need some interpretation

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Dave Cheney]

It's all in the release history, this change occured before Go 1.0.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Getting error back after executing a shell script via Golang

[DM]

Cross-posting this from stackoverflow 

:-

I have a simple shell script (named copy.sh) which looks like below:-

#! /bin/sh

cp $1 $2

I did chmod 777 copy.sh.

I have a golang code which executes the above shell code:-

package main
import (
"fmt"
"os/exec")

func main() {
_, err := exec.Command("/Users/debraj/copy.sh", "/Users/debraj/temp.txt", 
"/Users/debraj/gotest/").Output()
if err != nil {
fmt.Println("Failed to execute command " + err.Error())
return
}
fmt.Printf("\nCopy Successful - %v")}

The above code is showing be the below output:-

jabongs-MacBook-Pro-4:src debraj$ go run copyerr.go Failed to execute command 
exit status 1
jabongs-MacBook-Pro-4:src debraj$ 

But the error I receive from shell script looks like below:-

jabongs-MacBook-Pro-4:~ debraj$ ./copy.sh /Users/debraj/temp.txt 
/Users/debraj/gotest/
cp: /Users/debraj/gotest/temp.txt: Permission denied 

Can someone let me know how how can I get the same error message that is 
returned by the shell script?

If I don;t do chmod 777 copy.sh and the file has permission as below:-

jabongs-MacBook-Pro-4:~ debraj$ ls -la copy.sh -rw-r--r--  1 debraj  staff  21 
Sep 29 13:28 copy.sh

Then the golang code gives the output as given by the shell script. Can 
some also let me know why this is behaving like this?

I am on

   - Golang 1.7
   - Mac OS X 10.11.4

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Licenses

[T L]

On Thursday, September 29, 2016 at 4:24:51 PM UTC+8, T L wrote:
>
>
>
> On Thursday, September 29, 2016 at 4:12:41 PM UTC+8, dja...@gmail.com 
> wrote:
>>
>> Hi,
>> May be OT, but:
>>
>> Can i  translate some GPLv2 licensed C code to GO, and publish it under 
>> BSD new license ?
>> Code comments are from original C code.
>>
>
> no, 
> http://programmers.stackexchange.com/questions/151515/rewrote-gnu-gpl-v2-code-in-another-language-can-i-change-a-license
>  
> 
>

but IMO, sometimes, it is really hard to judge if the new code is 
translated from the old code or implemented from scratch.
 

>
>  
>
>>
>> Also, Can I in my BSD licensed GO project, link to GPLv2 library ?
>>
>
> no
>  
>
>>
>> Regards,
>> Djadala
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go analysis memory mallocs

[刘桂祥]

In my two examples, I use variable in makeslice that it will all escape to 
the heap ,  But I just want to use runtime.ReadMemStats to lookup it
and find strange 
ly
 
example2.go memstats.Mallocs is many times  don't know why ...

在 2016年9月29日星期四 UTC+8下午2:56:38，Dave Cheney写道：
>
> Be careful that the compiler isnt removing some or all of your program. 
> Check the asm to assert that your program is not being optimised away.
>
> Then check -gcflags=-m to see if the compiler is choosing a different 
> escape analysis depending on the size of your allocation. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Licenses

[T L]

On Thursday, September 29, 2016 at 4:12:41 PM UTC+8, dja...@gmail.com wrote:
>
> Hi,
> May be OT, but:
>
> Can i  translate some GPLv2 licensed C code to GO, and publish it under 
> BSD new license ?
> Code comments are from original C code.
>

no, 
http://programmers.stackexchange.com/questions/151515/rewrote-gnu-gpl-v2-code-in-another-language-can-i-change-a-license
 

>
> Also, Can I in my BSD licensed GO project, link to GPLv2 library ?
>

no
 

>
> Regards,
> Djadala
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Licenses

[djadala]

Hi,
May be OT, but:

Can i  translate some GPLv2 licensed C code to GO, and publish it under BSD 
new license ?
Code comments are from original C code.

Also, Can I in my BSD licensed GO project, link to GPLv2 library ?

Regards,
Djadala


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go compile for memory allocation

[刘桂祥]

https://github.com/golang/go/issues/17275

在 2016年9月29日星期四 UTC+8下午2:57:08，Dave Cheney写道：
>
> Don't forget to log that issue. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Connect In Database

[hadiesmaili85]

On Thursday, September 29, 2016 at 1:04:34 AM UTC-7, hadies...@gmail.com 
wrote:
>
> Hi 
>

> we can with this *package database/sql*  connect to any databases???
>
>
> if you'r Answer is NO then help me.
>
>
> THANKS
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Connect In Database

[hadiesmaili85]

On Thursday, September 29, 2016 at 1:04:34 AM UTC-7, hadies...@gmail.com 
wrote:
>
> Hi
>
> we can with this *package database/sql*  connect to any databases???
>
>
> if you'r Answer is NO then help me.
>
>
> THANKS
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Dave Cheney]

If you think that's inconsistent, you should see how we used to delete things 
from maps ;)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 3:31:46 PM UTC+8, Dave Cheney wrote:
>
> Sorry, I misspoke, this logic does not apply to map lookup, they are 
> unrelated other than having a one arg and two arg form. 


:) yes, that is what the weirdness and inconsistency is. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Dave Cheney]

Sorry, I misspoke, this logic does not apply to map lookup, they are unrelated 
other than having a one arg and two arg form. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 3:21:26 PM UTC+8, Volker Dobler wrote:
>
> Am Donnerstag, 29. September 2016 07:02:26 UTC+2 schrieb T L:
>>
>> I know of the syntax in spec. 
>> I just want to understand what is the deep reason for the syntax 
>> inconsistency between map index and type assert.
>>
>
> "deep reason"s are found in religion and math not in
> programming language design.
>
> A type assertion states "this has type x" which is a bold
> statement, an assertion and these tend to fail/abort/terminate/throw
> if violated in most languages. Also: What could be the possible
> return value if the assertion failed? The zero value only.
> Now think about how you would use x := foo.(bar)  after a failed
> type assertion. Basically impossible, a practically useless language
> construct. Which in turn would force to allow the the x, ok = foo.(bar)
> only. Now again you do have an "inconsistency" (whatever you mean
> with this term) with map access which allows both forms.
>
> Btw: What do you think about the inconsistency between import
> statements and for loops :-) ?
>
> V. 
>

If there are any inconsistencies between import statements and for loops, 
it is very natural for me. :)
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Dave Cheney]

That sounds like a very bad idea. You type assert to the wrong type and receive 
a valid blank value for that type. If you're lucky the program crahesh 
immedialy because the type's zero value is nil, if you're not the person 
program continues to execute using this types zero value for an unknown amount 
of time causing untold data corruption. 

This is why go requires you to work hard for this behaviour by making the 
single value form of the expression the panicing default and the two value form 
harder to use accidentally. 

The same logic I described also applies to map lookup. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 1:07:17 PM UTC+8, andrey mirtchovski 
wrote:
>
> > I just want to understand what is the deep reason for the syntax 
> > inconsistency between map index and type assert. 
>
> a map is fully typed at compile time. even if its key is of type 
> interface{} the language defines how to compare two interface{} values 
> using type assertion here: 
> https://golang.org/ref/spec#Comparison_operators 
>
> "Interface values are comparable. Two interface values are equal if 
> they have identical dynamic types and equal dynamic values or if both 
> have value nil." 
>
> Using interface{} in assignments on the other hand is only type-safe 
> at runtime when used with a type assertion. 
>

Aha, it would be more understandable if you can explain it with code.
:), my English is not very good.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 3:10:46 PM UTC+8, Dave Cheney wrote:
>
> Which of these would you prefer happened instead?
>
> * A failed type assertion always panic'd
> * A failed type assertion never panic'd and instead returned the zero 
> value, as the map lookup does
> * Something else
>
> Dave
>

returned the zero value 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 1:33:40 PM UTC+8, Micky wrote:
>
> TL, the simplest reason is this: 
>
> You can live without the "ok idiom" when retrieving a map value but you 
> cannot when type asserting. Think of the consequences for rest of your 
> program, if you forgot to check the status of assertion that is failed (but 
> you didn't know) because the compiler didn't panic! It would be a travesty.
>
> For compiler's perspective, see Andrey's response.
>

But I don't check the status of an assertion and the the status is false, I 
surely expect to get a zero value of the wrong type in the assertion.
 

>
> On Thu, Sep 29, 2016 at 10:06 AM, Henrik Johansson  > wrote:
>
>> I am not sure but perhaps as simple as it is a very natural and known 
>> behavior of maps and to make it work syntactically as the type assertion 
>> would make it weird. 
>>
>> On Thu, Sep 29, 2016, 07:02 T L  wrote:
>>
>>>
>>>
>>> On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote:

 The reason is directly stated in the Go language spec:

 "If the type assertion holds, the value of the expression is the value 
 stored in x and its type is T. If the type assertion is false, a run-time 
 panic  occurs."

 Here "hold" means if it succeeds.


>>> I know of the syntax in spec. 
>>> I just want to understand what is the deep reason for the syntax 
>>> inconsistency between map index and type assert.
>>>  
>>>

 On Thu, Sep 29, 2016 at 9:53 AM, T L  wrote:

>
>
> On Thursday, September 29, 2016 at 12:32:48 PM UTC+8, Henrik Johansson 
> wrote:
>>
>> This is just how type assertion works. 
>> If you don't use the dual return it panics if the actual type is 
>> different from the one you try to assert. 
>>
>
> but what is the underlining reason for the inconsistency between map 
> index and type assert?
>  
>
>>
>> On Thu, Sep 29, 2016, 05:26 T L  wrote:
>>
>>> package main
>>>
>>> func main() {
>>> var m = map[string]int{}
>>> _, _ = m["abc"] // ok
>>> _ = m["abc"] // ok
>>> 
>>> var i interface{} = 789
>>> _, _ = i.(bool) // ok
>>> _ = i.(bool) // panic: interface conversion: interface is int, 
>>> not bool
>>> }
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
> You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: gomobile: target=ios, getting incompatible pointer types assigning to 'GoUniverseerror *' from 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]

[Joe Blue]

i upgraded:
gomobile version +9640137 Tue Sep 27 16:37:51 2016 + (android,ios);
androidSDK=/Users/apple/Library/Android/sdk/platforms/android-24

It fixed all the errors:)

thankyou




On Thu, Sep 29, 2016 at 9:13 AM Joe Blue  wrote:

> thank Elias. Nice
>
> I am on this version:
>
> x-MacBook-Pro:rpc apple$ gomobile version
>
> gomobile version +7573efa Wed Aug 24 22:21:38 2016 + (android,ios);
> androidSDK=/Users/apple/Library/Android/sdk/platforms/android-24
>
> I will upgrade now and see if i get the same errors. thanks
>
>
>
> On Wed, Sep 28, 2016 at 5:06 PM Elias Naur  wrote:
>
>> Hi,
>>
>> Use the -work flag to gomobile to output working directory and to
>> preserve the generated files.
>>
>> What revision are your gomobile tool compiled at? CL 29052 should have
>> fixed that error.
>>
>>  - elias
>>
>>
>> On Wednesday, September 28, 2016 at 2:14:30 PM UTC+2, Joe Blue wrote:
>>>
>>>
>>> Hey all,
>>>
>>> i am compiling code across to IOS & Android.
>>>
>>> On Android things are working ok it seems.
>>>
>>> But i get this on ios with: gomobile bind --target=ios -v
>>>
>>>
>>>
>>> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>>>
>>> #
>>> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:156:11:
>>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>>> note: instance method 'initWithError:' is assumed to return an instance of
>>> its receiver type ('goSeqErrorWrapper *')
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:178:11:
>>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>>> note: instance method 'initWithError:' is assumed to return an instance of
>>> its receiver type ('goSeqErrorWrapper *')
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:202:11:
>>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>>> note: instance method 'initWithError:' is assumed to return an instance of
>>> its receiver type ('goSeqErrorWrapper *')
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:228:11:
>>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>>> note: instance method 'initWithError:' is assumed to return an instance of
>>> its receiver type ('goSeqErrorWrapper *')
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:253:11:
>>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>>> note: instance method 'initWithError:' is assumed to return an instance of
>>> its receiver type ('goSeqErrorWrapper *')
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:279:11:
>>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>>
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>>> note: instance method 'initWithError:' is assumed to return an instance of
>>> its receiver type ('goSeqErrorWrapper *')
>>>
>>> command-line-arguments
>>>
>>> write Cli.framework/Versions/A/Headers/GoCli.h
>>>
>>> write Cli.framework/Versions/A/Headers/GoUniverse.h
>>>
>>> write Cli.framework/Versions/A/Headers/Cli.h
>>>
>>> write Cli.framework/Versions/A/Modules/module.modulemap
>>>
>>>
>>>
>>> 1. Is there a way to tell the compiler to leave the files in the 
>>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/
>>> location so i can see them. At the moment it deletes them.
>>>
>>>
>>> Regards
>>>
>>>
>>> Joe
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> 

Re: [go-nuts] Re: gomobile: target=ios, getting incompatible pointer types assigning to 'GoUniverseerror *' from 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]

[Joe Blue]

thank Elias. Nice

I am on this version:

x-MacBook-Pro:rpc apple$ gomobile version

gomobile version +7573efa Wed Aug 24 22:21:38 2016 + (android,ios);
androidSDK=/Users/apple/Library/Android/sdk/platforms/android-24

I will upgrade now and see if i get the same errors. thanks



On Wed, Sep 28, 2016 at 5:06 PM Elias Naur  wrote:

> Hi,
>
> Use the -work flag to gomobile to output working directory and to preserve
> the generated files.
>
> What revision are your gomobile tool compiled at? CL 29052 should have
> fixed that error.
>
>  - elias
>
>
> On Wednesday, September 28, 2016 at 2:14:30 PM UTC+2, Joe Blue wrote:
>>
>>
>> Hey all,
>>
>> i am compiling code across to IOS & Android.
>>
>> On Android things are working ok it seems.
>>
>> But i get this on ios with: gomobile bind --target=ios -v
>>
>>
>>
>> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>>
>> #
>> _/var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:156:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>> note: instance method 'initWithError:' is assumed to return an instance of
>> its receiver type ('goSeqErrorWrapper *')
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:178:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>> note: instance method 'initWithError:' is assumed to return an instance of
>> its receiver type ('goSeqErrorWrapper *')
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:202:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>> note: instance method 'initWithError:' is assumed to return an instance of
>> its receiver type ('goSeqErrorWrapper *')
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:228:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>> note: instance method 'initWithError:' is assumed to return an instance of
>> its receiver type ('goSeqErrorWrapper *')
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:253:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>> note: instance method 'initWithError:' is assumed to return an instance of
>> its receiver type ('goSeqErrorWrapper *')
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/GoCli.m:279:11:
>> warning: incompatible pointer types assigning to 'GoUniverseerror *' from
>> 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]
>>
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/T/gomobile-work-821936368/src/gomobile_bind/seq.h:32:1:
>> note: instance method 'initWithError:' is assumed to return an instance of
>> its receiver type ('goSeqErrorWrapper *')
>>
>> command-line-arguments
>>
>> write Cli.framework/Versions/A/Headers/GoCli.h
>>
>> write Cli.framework/Versions/A/Headers/GoUniverse.h
>>
>> write Cli.framework/Versions/A/Headers/Cli.h
>>
>> write Cli.framework/Versions/A/Modules/module.modulemap
>>
>>
>>
>> 1. Is there a way to tell the compiler to leave the files in the 
>> /var/folders/wp/ff6sz9qs6g71jnm12nj2kbywgp/
>> location so i can see them. At the moment it deletes them.
>>
>>
>> Regards
>>
>>
>> Joe
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/vTdAjZk1W64/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [go-nuts] why this?

[Dave Cheney]

Which of these would you prefer happened instead?

* A failed type assertion always panic'd
* A failed type assertion never panic'd and instead returned the zero value, as 
the map lookup does
* Something else

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] glog log rotate not working correctly

[Dave Cheney]

This is usually caused by the process writing to a log file that has been 
deleted. This is a very common bug with programs that rotate their own logs and 
a major reason why 12 factor apps recommend that log rotation be down by an 
external program. 

Have a look in /proc/yourprocess/fd with ls -al. If there is an open file 
pointing to a log file with the suffix (deleted), that's the problem. 

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 1:31:41 PM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Sep 28, 2016 at 10:02 PM, T L  
> wrote: 
> > 
> > On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote: 
> >> 
> >> The reason is directly stated in the Go language spec: 
> >> 
> >> "If the type assertion holds, the value of the expression is the value 
> >> stored in x and its type is T. If the type assertion is false, a 
> run-time 
> >> panic occurs." 
> >> 
> >> Here "hold" means if it succeeds. 
> >> 
> > 
> > I know of the syntax in spec. 
> > I just want to understand what is the deep reason for the syntax 
> > inconsistency between map index and type assert. 
>
> Why do you think there is an inconsistency? 
>
> Let me put it another way.  A type assertion and a map index are two 
> different kinds of expressions.  They do different things.  What kind 
> of consistency do you expect between them? 
>
> Ian 
>

I just feel that It is weird that the behavior of type assertion depends on 
whether the second OK result variable is provided or not.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[T L]

On Thursday, September 29, 2016 at 1:07:42 PM UTC+8, Henrik Johansson wrote:
>
> I am not sure but perhaps as simple as it is a very natural and known 
> behavior of maps and to make it work syntactically as the type assertion 
> would make it weird. 
>
>
yes. 
It is really weird that the behavior of type assertion depends on whether 
the second OK result value is received or not.
 

> On Thu, Sep 29, 2016, 07:02 T L  wrote:
>
>>
>>
>> On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote:
>>>
>>> The reason is directly stated in the Go language spec:
>>>
>>> "If the type assertion holds, the value of the expression is the value 
>>> stored in x and its type is T. If the type assertion is false, a run-time 
>>> panic  occurs."
>>>
>>> Here "hold" means if it succeeds.
>>>
>>>
>> I know of the syntax in spec. 
>> I just want to understand what is the deep reason for the syntax 
>> inconsistency between map index and type assert.
>>  
>>
>>>
>>> On Thu, Sep 29, 2016 at 9:53 AM, T L  wrote:
>>>


 On Thursday, September 29, 2016 at 12:32:48 PM UTC+8, Henrik Johansson 
 wrote:
>
> This is just how type assertion works. 
> If you don't use the dual return it panics if the actual type is 
> different from the one you try to assert. 
>

 but what is the underlining reason for the inconsistency between map 
 index and type assert?
  

>
> On Thu, Sep 29, 2016, 05:26 T L  wrote:
>
>> package main
>>
>> func main() {
>> var m = map[string]int{}
>> _, _ = m["abc"] // ok
>> _ = m["abc"] // ok
>> 
>> var i interface{} = 789
>> _, _ = i.(bool) // ok
>> _ = i.(bool) // panic: interface conversion: interface is int, 
>> not bool
>> }
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to golang-nuts...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go compile for memory allocation

[Dave Cheney]

Don't forget to log that issue. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go analysis memory mallocs

[Dave Cheney]

Be careful that the compiler isnt removing some or all of your program. Check 
the asm to assert that your program is not being optimised away.

Then check -gcflags=-m to see if the compiler is choosing a different escape 
analysis depending on the size of your allocation. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go analysis memory mallocs

[刘桂祥]

// example1.go
package main


import "runtime"


func main() {
m := new(runtime.MemStats)
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
cap := 1024 * 1024 * 3
s := make([]byte, cap)
_ = s
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
}

go run example1.go
32744 65
3178472 66

// example2.go
package main


import "runtime"


func main() {
m := new(runtime.MemStats)
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
cap := 1024 * 1024 * 4
s := make([]byte, cap)
_ = s
runtime.ReadMemStats(m)
println(m.Alloc, m.Mallocs)
}

go run example2.go
32744 65
4228984 77

why it have 12 times mallocs ??

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.