Re: [go-nuts] why this?

[Micky]

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.

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+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.
>

-- 
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 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

-- 
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?

[Henrik Johansson]

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+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?

[andrey mirtchovski]

> 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.

-- 
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 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why this?

[Micky]

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.


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+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?

[andrey mirtchovski]

> If you don't use the dual return it panics if the actual type is different
> from the one you try to assert.

from the language specification:

" x.(T)

asserts that x is not nil and that the value stored in x is of type T.
The notation x.(T) is called a type assertion.
[...]
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."

https://golang.org/ref/spec#Type_assertions

the key to why _ = m["abc"] works lies in this text:

"For a of map type M:

x's type must be assignable to the key type of M
[...]
if the map is nil or does not contain such an entry, a[x] is the zero
value for the value type of M"

https://golang.org/ref/spec#Index_expressions

-- 
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]

Hi,

I am using the glog to log for my golang program and I have changed the
package to limit maximum file size to 250MB by changing this line (
https://github.com/golang/glog/blob/master/glog_file.go#L34).

The log rotate seems to be working as intended and the file size gets
limited to 250MB but somehow there seems to be a bug in file close/open and
the log directory keeps filling up until it runs out of space. df -h
command shows that the used space is close to 100% but if I look using du
-h or ls and add up the file sizes it is not close to 100%. My platform is
CentOS7.

Thanks,

Ramkumar

-- 
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?

[Henrik Johansson]

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.

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+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] image: algorithm to convert to grayscale

[Micky]

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] image: algorithm to convert to grayscale

[Michael Jones]

Yes, certainly this is round to nearest for the luminance computation, and that 
is a good thing.

 

As far as the equation itself, this is a color science topic with many types of 
answers—engineering answers that cite various specifications, scientific 
answers that study human perception, and others. The logic of it is that the 
typical human eye is much more sensitive to green light, then reds, and then 
blue least of all. Basically this is just 6x, 3x and 1x the sensitivity.

 

However, the color responses in the eye are spectral—across a range of 
frequencies—not centered at just the one particular red, green, and blue 
wavelength of a particular display device, which is why there are so many 
engineering answers—one overall best fit per color triad for the original NTSC 
phosphor colors, for CRT computer monitors, etc.

 

That said, NONE OF THEM ARE VERY GOOD for common purposes.

 

Here is a survey:

http://cseweb.ucsd.edu/~ckanan/publications/Kanan_Cottrell_PloS_ONE_2012.pdf

 

And interesting approaches…

http://www.cs.northwestern.edu/~ago820/color2gray/color2gray.pdf

https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-649.pdf

 

What I tend to use is the perceptually pleasing, unofficial, non-standard, 
clever solution by Darel Rex Finley…

y  :=  math.Sqrt(0 .299*r*r + 0.587*g*g + 0.114*b*b)

 

You can see how well it works by looking at the child and building images on 
his web page. See how long it takes you to see what’s happening in the bottom 
row…  

 

Michael

 

 

From:  on behalf of Patrick Smith 

Date: Wednesday, September 28, 2016 at 4:51 PM
To: Rodolfo Carvalho 
Cc: golang-nuts 
Subject: Re: [go-nuts] image: algorithm to convert to grayscale

 

Looks like it's just rounding to the nearest integer.

 

On Wed, Sep 28, 2016 at 3:19 PM, Rodolfo Carvalho  wrote:

Hello,

 

I'm not an image processing expert, but was trying to write a small program to 
convert images to grayscale, just for the fun of it [1].

 

First I managed to get something working with image/draw, then I discovered 
about github.com/disintegration/gift through an old post here.

 

I realized the output images had a different luminance, what led me to dig a 
bit deeper to see how the implementations differed.

 

 

image/color [2]:

 

y := (299*r + 587*g + 114*b + 500) / 1000

 

 

gift [3]:

 

y := 0.299*px.R + 0.587*px.G + 0.114*px.B

 

 

The initially funny numbers, weights, match those described in Wikipedia [4].

I went ahead and compared to what Matlab [5] and Octave [6] do and found a 
similar formula.

 

 

I did not understand why image/color adds an extra 0.5 (500/1000) to y.

Could anybody give me a clue?

 

 

 

 

[1] https://gist.github.com/rhcarvalho/5e97f310701528f5a0610415e317b992

[2] image/color: 
https://github.com/golang/go/blob/master/src/image/color/color.go#L249

[3] GIFT: https://github.com/disintegration/gift/blob/master/colors.go#L252

[4] https://en.wikipedia.org/wiki/Grayscale#Luma_coding_in_video_systems

[5] Matlab: 
https://www.mathworks.com/help/matlab/ref/rgb2gray.html#expand_body_buiz8mj-9

[6] Octave: 
https://sourceforge.net/p/octave/image/ci/default/tree/inst/rgb2gray.m#l43

 

 

Thanks,


Rodolfo Carvalho

-- 
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.

-- 
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] Mocking os.Open and related calls for more code coverage

['Eric Johnson' via golang-nuts]

Why not, instead of passing a file path as a parameter, pass a function that 
returns a ReadCloser (and error, of course). That way, you can preserve the 
existing semantics of your function, but move the decision of what to open, how 
to open, and how to handle the error for when it fails - all out of your 
function.

Or just use a temp file.

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] Re: do packages need to be recompiled when Go is upgraded?

[Micky]

Thanks for the correction :-)

On Thu, Sep 29, 2016 at 2:26 AM, Dave Cheney  wrote:

> s/go build/go install/g
>
> On Thursday, 29 September 2016 01:41:31 UTC+10, Micky wrote:
>>
>> go list ...
>> go build ...
>>
>> It will build only if it it needs to! Otherwise add -a to force.
>>
>> On Wed, Sep 28, 2016 at 8:30 PM, Tim K  wrote:
>>
>>> OK, so all that should happen is just re-install the binaries in
>>> $GOPATH/bin. Does anyone have any tips or helper scripts that help automate
>>> re-installing all these binaries? There's a pile of them which makes it a
>>> bit difficult to find out what exact package path they came from so they
>>> can be rebuilt.
>>>
>>> Thanks!
>>>
>>>
>>> On Wednesday, September 28, 2016 at 7:43:18 AM UTC-7, Chris Hines wrote:

 I'm pretty sure that the last few versions of Go (since 1.5 maybe) are
 smart enough to do it automatically. I believe the .o files in the pkg tree
 have the compiler version embedded in their meta data for this purpose.
>>>
>>> --
>>> 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.
>

-- 
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

[Patrick Smith]

Looks like it's just rounding to the nearest integer.

On Wed, Sep 28, 2016 at 3:19 PM, Rodolfo Carvalho 
wrote:

> Hello,
>
> I'm not an image processing expert, but was trying to write a small
> program to convert images to grayscale, just for the fun of it [1].
>
> First I managed to get something working with image/draw, then I
> discovered about github.com/disintegration/gift through an old post here.
>
> I realized the output images had a different luminance, what led me to dig
> a bit deeper to see how the implementations differed.
>
>
> image/color [2]:
>
> y := (299*r + 587*g + 114*b + 500) / 1000
>
>
> gift [3]:
>
> y := 0.299*px.R + 0.587*px.G + 0.114*px.B
>
>
> The initially funny numbers, weights, match those described in Wikipedia
> [4].
> I went ahead and compared to what Matlab [5] and Octave [6] do and found a
> similar formula.
>
>
> I did not understand why image/color adds an extra 0.5 (500/1000) to y.
> Could anybody give me a clue?
>
>
>
>
> [1] https://gist.github.com/rhcarvalho/5e97f310701528f5a0610415e317b992
> [2] image/color: https://github.com/golang/go/blob/master/src/image/color/
> color.go#L249
> [3] GIFT: https://github.com/disintegration/gift/blob/
> master/colors.go#L252
> [4] https://en.wikipedia.org/wiki/Grayscale#Luma_coding_in_video_systems
> [5] Matlab: https://www.mathworks.com/help/matlab/ref/rgb2gray.html#
> expand_body_buiz8mj-9
> [6] Octave: https://sourceforge.net/p/octave/image/ci/default/tree/
> inst/rgb2gray.m#l43
>
>
> Thanks,
>
> Rodolfo Carvalho
>
> --
> 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 result type is different on sql.Query()

[Harry]

Thanks, Konstantin.

It would be nice idea,
I'll try to check it!

2016年9月28日水曜日 23時00分14秒 UTC+9 Konstantin Khomoutov:
>
> On Wed, 28 Sep 2016 06:30:05 -0700 (PDT) 
> Harry  wrote: 
>
> > > In a nutshell, Scan() internally performs several nested type 
> > > switches based on the type of the Scan destination and what is 
> > > received from the database (in other words, the driver). 
> > > 
> > > As to why the two scans returned values of different types, more 
> > > information is needed. But since the queries were similar and the 
> > > dest were the same, you could start by looking at what is stored in 
> > > the database and what's the int64/[]byte returned. 
> > > 
> > These two SQL expect same result. 
> > 
> > Field1's type on MySQL is int. 
> > When returning value as string type, that value is same to int value 
> > after asserted to int. 
> > But it's troublesome to handle two different result by placeholder 
> > added/not added. 
>
> I would take tcpdump / Wireshark, capture the exchange with the server 
> in both cases and look at what Wireshark's dissectors decode from that 
> exchange in both cases.  If there's some information delivered by the 
> server along with its response (it should, I'd think), you'll be able 
> to see how it differs.  Alternatively, you should be able to tell any 
> difference between how the MySQL driver on the Go side handles the 
> query in both the cases.  This one is interesting.  Say, the driver 
> might actually prepare the query behind your back.  Or it may do 
> something weird when escaping the argument when constructing the full 
> query string if it's not using prepared statements. 
>
> To recap, there are at least two points of interest to look at. 
>

-- 
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 result type is different on sql.Query()

[Harry]

Thank you ksug,
Your indication makes sense.

I try to check more detail.
And I'll feedback.

2016年9月28日水曜日 22時58分24秒 UTC+9 ksug:
>
> I don't think placeholder vs no placeholder makes a difference. Here is 
> an example where Scan() into the same table could return values of 
> different types (using sqlite instead of mysql). 
>
> https://play.golang.org/p/rAA04pv_I_ 
>
> I'm not saying that this is what's definitely happening on your end, 
> just that it's possible. 
> Look at: 
> - implicit type conversions 
> - database, driver behavior 
> - driver bug 
> - etc 
>
> As I said, more information is needed. 
>

-- 
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: do packages need to be recompiled when Go is upgraded?

[Tim K]

On Wednesday, September 28, 2016 at 2:31:44 PM UTC-7, andrey mirtchovski 
wrote:
>
> > If I want to start from the executables in $GOPATH/bin and recompile 
> only 
> > those, is there a way to tell what package an executable comes from so I 
> can 
> > easily automate the process? E.g. goimports is the result of "go install 
> > golang.org/x/tools/cmd/goimports", etc. 
>
> you can do it by listing the target and import path or directory for 
> each package and filter out the executables you're interested in. 'go 
> help list' gives you a lot of options. example: 
>
> go list -f '{{.Dir}}: {{.Target}}' all | grep yourbinaryfile 
>
> or, to see the import path for every binary in your GOPATH/bin: 
>
> go list -f '{{.ImportPath}}: {{.Target}}' all | grep $GOPARH/bin 
>

Thanks for the pointer in the right direction. I can work with that to 
automate it. There are some things to take care of such as same package 
being vendored but that can be solved by picking the shortest Dir. Maybe 
this is a good tool to write in 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] image: algorithm to convert to grayscale

[Rodolfo Carvalho]

Hello,

I'm not an image processing expert, but was trying to write a small program
to convert images to grayscale, just for the fun of it [1].

First I managed to get something working with image/draw, then I
discovered about github.com/disintegration/gift through an old post here.

I realized the output images had a different luminance, what led me to dig
a bit deeper to see how the implementations differed.


image/color [2]:

y := (299*r + 587*g + 114*b + 500) / 1000


gift [3]:

y := 0.299*px.R + 0.587*px.G + 0.114*px.B


The initially funny numbers, weights, match those described in Wikipedia
[4].
I went ahead and compared to what Matlab [5] and Octave [6] do and found a
similar formula.


I did not understand why image/color adds an extra 0.5 (500/1000) to y.
Could anybody give me a clue?




[1] https://gist.github.com/rhcarvalho/5e97f310701528f5a0610415e317b992
[2] image/color:
https://github.com/golang/go/blob/master/src/image/color/color.go#L249
[3] GIFT: https://github.com/disintegration/gift/blob/master/colors.go#L252
[4] https://en.wikipedia.org/wiki/Grayscale#Luma_coding_in_video_systems
[5] Matlab:
https://www.mathworks.com/help/matlab/ref/rgb2gray.html#expand_body_buiz8mj-9
[6] Octave:
https://sourceforge.net/p/octave/image/ci/default/tree/inst/rgb2gray.m#l43


Thanks,

Rodolfo Carvalho

-- 
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: do packages need to be recompiled when Go is upgraded?

[andrey mirtchovski]

> go list -f '{{.ImportPath}}: {{.Target}}' all | grep $GOPATH/bin

mistyped GOPATH, sorry.

-- 
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: do packages need to be recompiled when Go is upgraded?

[andrey mirtchovski]

> If I want to start from the executables in $GOPATH/bin and recompile only
> those, is there a way to tell what package an executable comes from so I can
> easily automate the process? E.g. goimports is the result of "go install
> golang.org/x/tools/cmd/goimports", etc.

you can do it by listing the target and import path or directory for
each package and filter out the executables you're interested in. 'go
help list' gives you a lot of options. example:

go list -f '{{.Dir}}: {{.Target}}' all | grep yourbinaryfile

or, to see the import path for every binary in your GOPATH/bin:

go list -f '{{.ImportPath}}: {{.Target}}' all | grep $GOPARH/bin

-- 
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: do packages need to be recompiled when Go is upgraded?

[Dave Cheney]

s/go build/go install/g

On Thursday, 29 September 2016 01:41:31 UTC+10, Micky wrote:
>
> go list ...
> go build ...
>
> It will build only if it it needs to! Otherwise add -a to force.
>
> On Wed, Sep 28, 2016 at 8:30 PM, Tim K  
> wrote:
>
>> OK, so all that should happen is just re-install the binaries in 
>> $GOPATH/bin. Does anyone have any tips or helper scripts that help automate 
>> re-installing all these binaries? There's a pile of them which makes it a 
>> bit difficult to find out what exact package path they came from so they 
>> can be rebuilt.
>>
>> Thanks!
>>
>>
>> On Wednesday, September 28, 2016 at 7:43:18 AM UTC-7, Chris Hines wrote:
>>>
>>> I'm pretty sure that the last few versions of Go (since 1.5 maybe) are 
>>> smart enough to do it automatically. I believe the .o files in the pkg tree 
>>> have the compiler version embedded in their meta data for this purpose.
>>
>> -- 
>> 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: do packages need to be recompiled when Go is upgraded?

[Tim K]

If I want to start from the executables in $GOPATH/bin and recompile only 
those, is there a way to tell what package an executable comes from so I 
can easily automate the process? E.g. goimports is the result of "go 
install golang.org/x/tools/cmd/goimports", etc.

On Wednesday, September 28, 2016 at 8:41:18 AM UTC-7, andrey mirtchovski 
wrote:
>
> use 'go list' to see which packages you have installed and which may 
> need upgrading (they all will, in the end). 'go help packages' will 
> tell you the difference between 'go list std', 'go list all', and also 
> how to query individual folders inside GOPATH. 
>
> "go build -i" will ensure that prerequisite library dependencies are 
> also installed, which will populate the entire pkg/* directory. 
>
> On Wed, Sep 28, 2016 at 9:30 AM, Tim K  
> wrote: 
> > OK, so all that should happen is just re-install the binaries in 
> > $GOPATH/bin. Does anyone have any tips or helper scripts that help 
> automate 
> > re-installing all these binaries? There's a pile of them which makes it 
> a 
> > bit difficult to find out what exact package path they came from so they 
> can 
> > be rebuilt. 
> > 
> > Thanks! 
> > 
> > 
> > On Wednesday, September 28, 2016 at 7:43:18 AM UTC-7, Chris Hines wrote: 
> >> 
> >> I'm pretty sure that the last few versions of Go (since 1.5 maybe) are 
> >> smart enough to do it automatically. I believe the .o files in the pkg 
> tree 
> >> have the compiler version embedded in their meta data for this purpose. 
> > 
> > -- 
> > 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: [ANN] Cgogen - automatic Go bindings generator released

[Markus Zimmermann]

On Tuesday, September 20, 2016 at 1:05:39 PM UTC+2, Maxim Kupriianov wrote:
>
> Hi Markus, nice project! I must agree that the subject-specific bindings 
> will always be superior over the generic ones. Another good example of that 
> is https://github.com/therecipe/qt bindings with custom generator as well.
>

We tried to keep a lot of code generic so that we could make something like 
cgogen later on. You beat us to it :-) I would have loved to use something 
like cgogen but could not find anything related at that time.

Wow, github.com/therecipe/qt is huge.

As for LLVM, I'm trying to avoid using it for now, because that's a very 
> heavy dependency to have. Also that'd require rewriting more than half of 
> the current code. One day we may join our efforts working on a generic C 
> code transcriber, but that's another story.
>

The dependency is not that big, it is just libclang and some other 
libraries however it is not as portable as having a C parser written in Go. 
A rewrite at this point would not make sense for either projects. Honestly, 
if something like github.com/cznic/cc had existed when I started working 
with go-clang I would not have started the whole rewrite. Are you a 
maintainer of github.com/cznic/cc ? What is your opinion of the maturity of 
the project?

> Maybe we can find some inspiration from each others projects?
>
> I find the "ArrayNameFromLength" function curious, sadly things like that 
> are almost impossible in a generic context, even with YAML hints.
>

I think that something like "ArrayNameFromLength" should be seen as a 
"first automatic draft" for a binding. If the user sees that something is 
not generated as expected, the user should be able to overwrite the 
generators heuristics. That is what we did with go-clang/gen. However, I 
agree with your concern. Such heuristics suck, but I think they are better 
than having none.

Take a look onto my helper pipeline (gen_bindings.go), I used that approach 
> instead of using templates that are pure evil for generating code.
>

We used go/ast to generate most Go code which is complicated to use. 
However, I am pretty happy with the result and after some refactoring the 
whole generation would look rather easy. I did that for an internal project 
(I hope that I can open source parts of it) and this generic approach makes 
it easy to maintain generators for more than one language.

I definitely will study your code deeply because it's interesting indeed to 
> compare our approaches to the same problems.
> Feel free to reach me out :)
>

Looking forward to your changes :-) Contact me if you need any 
ideas/opinions.

I mentioned some concerns about cgogen here 
https://github.com/go-clang/design/issues/9 if you are interested. I can 
also over my help in setting up TravisCI and Coveralls, and making the 
whole repository more "go-ish". 

On Tue, Sep 20, 2016 at 1:23 PM, Markus Zimmermann  > wrote:
>
>> This looks pretty neat. We did something similar for 
>> https://github.com/go-clang/ The generator is here 
>> https://github.com/go-clang/gen and a resulting binding is here 
>> https://github.com/go-clang/v3.7 Maybe we can find some inspiration from 
>> each others projects? It would be also interesting to figure out how we 
>> could merge each efforts?
>>
>> Cheers,
>> Markus
>>
>> On Tuesday, September 20, 2016 at 10:19:14 AM UTC+2, Maxim Kupriianov 
>> wrote:
>>>
>>> Hello everyone, 
>>>
>>> today I'm glad to announce that after 3 months of full-time development 
>>> back in 2015 and after 1 year of part-time field testing and improvements 
>>> in 2016,
>>> an automatic CGo bindings generator for Golang is finally released to 
>>> the public. Visit https://cgogen.com
>>>
>>> Sources: http://github.com/xlab/cgogen
>>> Documentation: https://github.com/xlab/cgogen/wiki
>>>
>>> That is the same generator that brought us Go bindings for Android NDK, 
>>> Vulkan Graphics API, CMU PocketSphinx, ALAC and Ogg/Vorbis decoders, Pure 
>>> Data embeddable library, PortAudio and PortMIDI adapters. And bindings for 
>>> the libpvpx from WebM are on their way.
>>>
>>> I hope the project will be useful for the community and awaiting for the 
>>> feedback and issues.
>>> Good luck y all!
>>>
>>> --
>>> Max
>>>
>> -- 
>> 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/3I7TzmEirbo/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: go escape analysis

[Ian Lance Taylor]

On Wed, Sep 28, 2016 at 11:15 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> We could discuss what has "gone wrong" in the Go compiler; and how to make
> it work at least in theory.
>
> Unfortunately, me not being paid by Google is a line I am both unable and
> unwilling to cross.
>
> I feel sorry for not being able to discuss the subject of escape analysis
> which by itself is quite fascinating.

For the record, in case anybody is confused by this, there are people
who work actively on the Go compiler who are not paid by Google.  You
should of course make your own choices.

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.

[go-nuts] Functional tests for project based on fasthttp

[Dmitriy Suhinin]

In my project I'm using valyala/fasthttp to serve HTTP requests. I'm almost 
finish project and now want to write functional tests to test all project 
endpoints and be sure that everything works fine and without problems. 
Could someone know how to do that in case of valyala/fasthttp? I know that 
for regular net/http package exists "net/http/httptest" package but what 
about valyala/fasthttp? Now I really don't understand how to do 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.

[go-nuts] Re: go escape analysis

[⚛]

We could discuss what has "gone wrong" in the Go compiler; and how to make 
it work at least in theory.

Unfortunately, me not being paid by Google is a line I am both unable and 
unwilling to cross.

I feel sorry for not being able to discuss the subject of escape analysis 
which by itself is quite fascinating.

Sincerely
atomsymbol

On Wednesday, September 28, 2016 at 4:18:29 PM UTC+2, 刘桂祥 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] golang can't compile a static go compiler

[Ian Lance Taylor]

On Wed, Sep 28, 2016 at 10:29 AM, Dave Goehrig  wrote:
>
> On x86_64-linux, golang 1.7.1 in cmd/cgo/out.go  lines 248-277 explicitly
> creates a dynamically linked elf file when compiling via go (but not gccgo,
> cf line 3359 of cmd/go/build.go.
> It appears that there is no way to build a static /bin/go as a result of
> this code.  Is this correct?
>
> I ask because the environment I'm trying to build go for doesn't support
> shared libraries or dynamic loading (no ld-linux), and would love to know if
> there is a way to do it.

The code you mention in the cgo tool is used when doing a dynamic
link, but not when doing a static link.

If you don't need cgo, set CGO_ENABLED=0 when you build the go tools,
and you will get statically linked binaries.

If you do need cgo, you will to pass -extldflags=-static to tell the
external linker to do a static link.

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.

[go-nuts] slice expansion in templates

[Steven Hartland]

Is there anyway to pass a slice to a varadic golang function in a template?

In straight go it would simply be myfunc(myslice...) but in templates 
this possible?


Regards
Steve

--
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: Set ldflags for vendor dependency

[mhhcbon]

I have no idea how ldflags works under the hood but this is awesome news.

I ll check the other Q later.
Hoped someone could answer without having to roll out a test, from his mind.


thanks for interest and answer!


On Wednesday, September 28, 2016 at 3:05:07 PM UTC+2, parais...@gmail.com 
wrote:
>
> I just tested with :
>
> package main
>
> // SomeVar is a var
>
> var SomeVar = "default" + "variable"
>
> func main() {
>   print(SomeVar)
> }
>
> and 
>
> go build --ldflags "-X main.SomeVar=changed"
>
>
> and it works, it prints changed
>
> Le mardi 27 septembre 2016 23:28:49 UTC+2, mhh...@gmail.com a écrit :
>>
>> What if for some reason i have to write the value like this within the 
>> code (...),
>>
>> var SomeVariable = "some"+"what"
>>
>> ldflags will be able to operate ?
>>
>

-- 
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: not available from my location when I run git mail to submit a patch.

[Peng Gao]

Use a proxy fix it.

On Wednesday, September 28, 2016 at 11:25:31 PM UTC+8, Peng Gao wrote:
>
> I just make a path and want to push it, I got this error
>
> git mail
> fatal: remote error: Access Denied (not available from your location)
> (running: git push -q origin HEAD:refs/for/master)
> git-codereview: exit status 128
>
> what's the reason? 
>

-- 
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: do packages need to be recompiled when Go is upgraded?

[andrey mirtchovski]

use 'go list' to see which packages you have installed and which may
need upgrading (they all will, in the end). 'go help packages' will
tell you the difference between 'go list std', 'go list all', and also
how to query individual folders inside GOPATH.

"go build -i" will ensure that prerequisite library dependencies are
also installed, which will populate the entire pkg/* directory.

On Wed, Sep 28, 2016 at 9:30 AM, Tim K  wrote:
> OK, so all that should happen is just re-install the binaries in
> $GOPATH/bin. Does anyone have any tips or helper scripts that help automate
> re-installing all these binaries? There's a pile of them which makes it a
> bit difficult to find out what exact package path they came from so they can
> be rebuilt.
>
> Thanks!
>
>
> On Wednesday, September 28, 2016 at 7:43:18 AM UTC-7, Chris Hines wrote:
>>
>> I'm pretty sure that the last few versions of Go (since 1.5 maybe) are
>> smart enough to do it automatically. I believe the .o files in the pkg tree
>> have the compiler version embedded in their meta data for this purpose.
>
> --
> 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] Re: do packages need to be recompiled when Go is upgraded?

[Micky]

go list ...
go build ...

It will build only if it it needs to! Otherwise add -a to force.

On Wed, Sep 28, 2016 at 8:30 PM, Tim K  wrote:

> OK, so all that should happen is just re-install the binaries in
> $GOPATH/bin. Does anyone have any tips or helper scripts that help automate
> re-installing all these binaries? There's a pile of them which makes it a
> bit difficult to find out what exact package path they came from so they
> can be rebuilt.
>
> Thanks!
>
>
> On Wednesday, September 28, 2016 at 7:43:18 AM UTC-7, Chris Hines wrote:
>>
>> I'm pretty sure that the last few versions of Go (since 1.5 maybe) are
>> smart enough to do it automatically. I believe the .o files in the pkg tree
>> have the compiler version embedded in their meta data for this purpose.
>
> --
> 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] go/types - creating a Type from whole cloth?

[roger peppe]

You shouldn't need to do any more parsing - when you type checked the original
program, the bytes package would have been loaded.
(if it wasn't then you know for sure that the type isn't *bytes.Buffer).

You could do something like this: https://play.golang.org/p/7pn6G9PCPp
(I used types.WriteExpr for the example as it was the first thing
I came across that had a public signature involving *bytes.Buffer).

  cheers,
rog.

On 28 September 2016 at 15:04, Nate Finch  wrote:
> Oh yes, that's smart, just use go/types to parse the bytes package. Great,
> thanks!
>
> On Wednesday, September 28, 2016 at 9:27:20 AM UTC-4, Sebastien Binet wrote:
>>
>>
>>
>> On Wed, Sep 28, 2016 at 2:57 PM,  wrote:
>>>
>>> You need to actually get the type of a *bytes.Buffer with reflect.TypeOf
>>> and compare types.
>>>
>>> https://play.golang.org/p/iqv16ibt9w
>>
>>
>> OP is using go/types, not reflect.
>>
>> using something like so might work:
>>
>> https://play.golang.org/p/sJ8u6cZjZ1
>>
>> (for some reason, it won't work in the playground...)
>>
>> hth,
>> -s
>
> --
> 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: do packages need to be recompiled when Go is upgraded?

[Tim K]

OK, so all that should happen is just re-install the binaries in 
$GOPATH/bin. Does anyone have any tips or helper scripts that help automate 
re-installing all these binaries? There's a pile of them which makes it a 
bit difficult to find out what exact package path they came from so they 
can be rebuilt.

Thanks!

On Wednesday, September 28, 2016 at 7:43:18 AM UTC-7, Chris Hines wrote:
>
> I'm pretty sure that the last few versions of Go (since 1.5 maybe) are 
> smart enough to do it automatically. I believe the .o files in the pkg tree 
> have the compiler version embedded in their meta data for this purpose.

-- 
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] not available from my location when I run git mail to submit a patch.

[Peng Gao]

I just make a path and want to push it, I got this error

git mail
fatal: remote error: Access Denied (not available from your location)
(running: git push -q origin HEAD:refs/for/master)
git-codereview: exit status 128

what's the reason? 

-- 
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: gomobile: target=ios, getting incompatible pointer types assigning to 'GoUniverseerror *' from 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]

[Elias Naur]

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 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 escape analysis

[刘桂祥]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] do packages need to be recompiled when Go is upgraded?

[Chris Hines]

I'm pretty sure that the last few versions of Go (since 1.5 maybe) are smart 
enough to do it automatically. I believe the .o files in the pkg tree have the 
compiler version embedded in their meta data for this purpose.

-- 
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 escape analysis

[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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Limit golang exceed

[Shawn Milochik]

Look for code calling itself in a loop. Maybe a function A calling function
B, which calls A again. Or just a buggy recursive function.

-- 
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 escape analysis

[刘桂祥]

// 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Limit golang exceed

[Anonymous]

Hello everyone this is my problem golang apparently said that I exceed the 
limits.
Would there any way to overcome these limitations?

C:\Users\Dylan\Desktop>go run 1.go
2016/09/28 16:02:28 Listening
runtime: goroutine stack exceeds 10-byte limit
fatal error: stack overflow

runtime stack:
runtime.throw(0x67eeb6, 0xe)
C:/Go/src/runtime/panic.go:566 +0x9c
runtime.newstack()
C:/Go/src/runtime/stack.go:1061 +0x424
runtime.morestack()
C:/Go/src/runtime/asm_amd64.s:366 +0x87

goroutine 6 [running]:
main.PageRequest(0x68004e0, 0xc04203a270, 0xc0420b21e0)
C:/Users/Dylan/Desktop/1.go:118 fp=0xc082233b78 sp=0xc082233b70
net/http.HandlerFunc.ServeHTTP(0x671fd60, 0x68004e0, 0xc04203a270, 
0xc0420b21e0)
C:/Go/src/net/http/server.go:1726 +0x4b fp=0xc082233ba0 sp=0xc082233b78
net/http.(*ServeMux).ServeHTTP(0x681b940, 0x68004e0, 0xc04203a270, 
0xc0420b21e0)
C:/Go/src/net/http/server.go:2022 +0x86 fp=0xc082233be0 sp=0xc082233ba0
net/http.serverHandler.ServeHTTP(0xc042068500, 0x68004e0, 0xc04203a270, 
0xc0420b21e0)
C:/Go/src/net/http/server.go:2202 +0x84 fp=0xc082233c28 sp=0xc082233be0
net/http.(*conn).serve(0xc042068580, 0x68008a0, 0xc042422600)
C:/Go/src/net/http/server.go:1579 +0x4be fp=0xc082233e88 sp=0xc082233c28
runtime.goexit()
C:/Go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc082233e90 sp=0xc082233e88
created by net/http.(*Server).Serve
C:/Go/src/net/http/server.go:2293 +0x454

goroutine 1 [IO wait]:
net.runtime_pollWait(0x6aaab40, 0x72, 0xc042420ac0)
C:/Go/src/runtime/netpoll.go:160 +0x60
net.(*pollDesc).wait(0xc0423b8170, 0x72, 0xc042420ac0, 0xc042077a98)
C:/Go/src/net/fd_poll_runtime.go:73 +0x3f
net.(*ioSrv).ExecIO(0xc042024000, 0xc0423b8060, 0x67d17c, 0x8, 
0xc0420af2a0, 0xc0423b8300, 0x0, 0x0)
C:/Go/src/net/fd_windows.go:171 +0x186
net.(*netFD).acceptOne(0xc0423b8000, 0xc04206e0e0, 0x2, 0x2, 0xc0423b8060, 
0xc04201a000, 0x0, 0x0)
C:/Go/src/net/fd_windows.go:529 +0x1f8
net.(*netFD).accept(0xc0423b8000, 0x0, 0x0, 0x0)
C:/Go/src/net/fd_windows.go:559 +0x131
net.(*TCPListener).accept(0xc042024028, 0x29e8d60800, 0x0, 0x0)
C:/Go/src/net/tcpsock_posix.go:132 +0x35
net.(*TCPListener).AcceptTCP(0xc042024028, 0xc042077d88, 0xc042077d90, 
0xc042077d80)
C:/Go/src/net/tcpsock.go:209 +0x50
net/http.tcpKeepAliveListener.Accept(0xc042024028, 0x671ff08, 0xc042068580, 
0x6800960, 0xc042427b60)
C:/Go/src/net/http/server.go:2608 +0x36
net/http.(*Server).Serve(0xc042068500, 0x6800520, 0xc042024028, 0x0, 0x0)
C:/Go/src/net/http/server.go:2273 +0x1d5
net/http.(*Server).ListenAndServe(0xc042068500, 0xc042068500, 0x0)
C:/Go/src/net/http/server.go:2219 +0xbb
net/http.ListenAndServe(0x67c3e1, 0x3, 0x0, 0x0, 0xc04200b1c0, 0x0)
C:/Go/src/net/http/server.go:2351 +0xa7
main.main()
C:/Users/Dylan/Desktop/1.go:198 +0x11b
exit status 2

-- 
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] go/types - creating a Type from whole cloth?

[Nate Finch]

Oh yes, that's smart, just use go/types to parse the bytes package. Great, 
thanks!

On Wednesday, September 28, 2016 at 9:27:20 AM UTC-4, Sebastien Binet wrote:
>
>
>
> On Wed, Sep 28, 2016 at 2:57 PM,  
> wrote:
>
>> You need to actually get the type of a *bytes.Buffer with reflect.TypeOf 
>> and compare types.
>>
>> https://play.golang.org/p/iqv16ibt9w
>>
>
> OP is using go/types, not reflect.
>
> using something like so might work:
>
> https://play.golang.org/p/sJ8u6cZjZ1
>
> (for some reason, it won't work in the playground...)
>
> hth,
> -s
>

-- 
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] do packages need to be recompiled when Go is upgraded?

[Tim K]

If the Go toolchain is upgraded to a newer version, do the existing 
packages in $GOPATH need to be recompiled? If so, how? Just delete 
$GOPATH/pkg and go install everything? What about the binaries in 
$GOPATH/bin?
What's the easiest way to make sure that everything in $GOPATH is compiled 
with the latest Go?

Thank you.

Tim

-- 
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 result type is different on sql.Query()

[Konstantin Khomoutov]

On Wed, 28 Sep 2016 06:30:05 -0700 (PDT)
Harry  wrote:

> > In a nutshell, Scan() internally performs several nested type
> > switches based on the type of the Scan destination and what is
> > received from the database (in other words, the driver). 
> >
> > As to why the two scans returned values of different types, more 
> > information is needed. But since the queries were similar and the
> > dest were the same, you could start by looking at what is stored in
> > the database and what's the int64/[]byte returned. 
> >
> These two SQL expect same result.
> 
> Field1's type on MySQL is int.
> When returning value as string type, that value is same to int value
> after asserted to int.
> But it's troublesome to handle two different result by placeholder 
> added/not added.

I would take tcpdump / Wireshark, capture the exchange with the server
in both cases and look at what Wireshark's dissectors decode from that
exchange in both cases.  If there's some information delivered by the
server along with its response (it should, I'd think), you'll be able
to see how it differs.  Alternatively, you should be able to tell any
difference between how the MySQL driver on the Go side handles the
query in both the cases.  This one is interesting.  Say, the driver
might actually prepare the query behind your back.  Or it may do
something weird when escaping the argument when constructing the full
query string if it's not using prepared statements.

To recap, there are at least two points of interest to look at.

-- 
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 result type is different on sql.Query()

[Kiki Sugiaman]

I don't think placeholder vs no placeholder makes a difference. Here is 
an example where Scan() into the same table could return values of 
different types (using sqlite instead of mysql).


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

I'm not saying that this is what's definitely happening on your end, 
just that it's possible.

Look at:
- implicit type conversions
- database, driver behavior
- driver bug
- etc

As I said, more information is needed.

--
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 result type is different on sql.Query()

[Harry]

Thanks ksug.

These two SQL expect same result.

Field1's type on MySQL is int.
When returning value as string type, that value is same to int value after 
asserted to int.
But it's troublesome to handle two different result by placeholder 
added/not added.


2016年9月28日水曜日 21時23分52秒 UTC+9 ksug:
>
> In a nutshell, Scan() internally performs several nested type switches 
> based on the type of the Scan destination and what is received from the 
> database (in other words, the driver). 
>
> As to why the two scans returned values of different types, more 
> information is needed. But since the queries were similar and the dest 
> were the same, you could start by looking at what is stored in the 
> database and what's the int64/[]byte returned. 
>

-- 
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] go/types - creating a Type from whole cloth?

[Seb Binet]

On Wed, Sep 28, 2016 at 2:57 PM,  wrote:

> You need to actually get the type of a *bytes.Buffer with reflect.TypeOf
> and compare types.
>
> https://play.golang.org/p/iqv16ibt9w
>

OP is using go/types, not reflect.

using something like so might work:

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

(for some reason, it won't work in the playground...)

hth,
-s

-- 
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: Mocking os.Open and related calls for more code coverage

[Nate Finch]

freeformz had a good suggestion to try to make your function take an 
io.Reader, which is good not just for testing, but for future 
flexibility... but of course, you still need some place that opens the 
file... that's inescapable.  The way I test those sorts of things is to use 
a variable to hold the function variable, and swap that out during testing:

 https://npf.io/2014/04/mocking-functions-in-go/

The article I wrote suggests a global variable, but that restricts you from 
doing parallel tests (and global variables are generally bad)... you could 
also make it a variable on the struct that has the method you're testing, 
then it's isolated from other tests and values... i.e.

type myObjStruct struct {
...
OpenFile func(string) (*os.File, error)
}

then when you construct the type, in production you do myObj.OpenFile = 
os.Open  and in testing you do myObj.OpenFile = testOpen (or whatever)

-- 
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 compile for memory allocation

[刘桂祥]

//  example1.go
packge main

func main() {
 s := make([]byte, 1024, 1024)
 _ = s
}

s will be allocated in stack and lookup assembl 
e
 
code  not call runtime.makeslice

// example2.go
packge main

func main() {
 cap := 1024
 s := make([]byte, 1024, cap)
 _ = s
}

s will be allocated in heap and lookup assemble code there is 
runtime.makeslice   why this ???

// example3.go
package main

func main() {
   a := 100
   if a>1 {
 a = 1000
   }
   b := interface{}(a)
   _ = b
}

0x 0 (example1.go:3) TEXT "".main(SB), $64-0
0x 0 (example1.go:3) MOVQ (TLS), CX
0x0009 9 (example1.go:3) CMPQ SP, 16(CX)
0x000d 00013 (example1.go:3) JLS 93
0x000f 00015 (example1.go:3) SUBQ $64, SP
0x0013 00019 (example1.go:3) MOVQ BP, 56(SP)
0x0018 00024 (example1.go:3) LEAQ 56(SP), BP
0x001d 00029 (example1.go:3) FUNCDATA $0, gclocals·33cdeebe80329
f1fdbee7f5874cb(SB)
0x001d 00029 (example1.go:3) FUNCDATA $1, gclocals·33cdeebe80329
f1fdbee7f5874cb(SB)
0x001d 00029 (example1.go:8) MOVQ $1000, "".autotmp_0+48(SP)
0x0026 00038 (example1.go:8) MOVQ $0, "".autotmp_1+40(SP)
0x002f 00047 (example1.go:8) LEAQ type.int(SB), AX
0x0036 00054 (example1.go:8) MOVQ AX, (SP)
0x003a 00058 (example1.go:8) LEAQ "".autotmp_0+48(SP), AX
0x003f 00063 (example1.go:8) MOVQ AX, 8(SP)
0x0044 00068 (example1.go:8) LEAQ "".autotmp_1+40(SP), AX
0x0049 00073 (example1.go:8) MOVQ AX, 16(SP)
0x004e 00078 (example1.go:8) PCDATA $0, $0
0x004e 00078 (example1.go:8) CALL runtime.convT2E(SB)
0x0053 00083 (example1.go:10) MOVQ 56(SP), BP
0x0058 00088 (example1.go:10) ADDQ $64, SP
0x005c 00092 (example1.go:10) RET
0x005d 00093 (example1.go:10) NOP
0x005d 00093 (example1.go:3) CALL runtime.morestack_noctxt(SB)
0x0062 00098 (example1.go:3) JMP 0


lookup the assemble code and see the compiler is very clever to opt that 
but in example2.go why don't do this 

-- 
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: Which web framework is recommended to use with GO?

['Jyotiswarup Raiturkar' via golang-nuts]

i've used https://github.com/gin-gonic/gin/ for a minimalistic framework, 
gets you started in no time. ( needs an MR for go v 1.6+, not sure if it 
was merged yet)
At the other end of the spectrum in revel : https://revel.github.io/ which 
is very much like RoR



On Wednesday, 28 September 2016 11:16:59 UTC+5:30, Devashish Ghosh wrote:
>
> https://github.com/jabong/florest-core A lightweight workflow based REST 
> API framework with features customized workflow, logging, monitoring, a/b 
> test, dynamic config, profiling, swagger, database adapters, cache adapter.
>
> On Saturday, January 17, 2015 at 4:30:07 PM UTC+5:30, Subhajit Datta wrote:
>>
>> Hi,
>> As of now, there seems to be many web frameworks in GO found on GITHUB 
>> projects.
>> eg:
>> webgo, gorrila, martini, Goji, Negorini, Revel, Beego
>> It will be really helpful if the community can suggest the good 
>> frameworks from these.
>> I am a newbie to GO.
>> Also please provide the pros and cons for the framework/s that you have 
>> used.
>>
>> Thanks and Regards,
>> Subhajit Datta
>>
>

-- 
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: how to read an http request's body?

[khoa]

Thanks man. 
I got same issue in your post. I call fmt.Fprintln before call 
json.NewDecoder.
I can run normally in develop server but when I deploy in App Engine, it 
stress me with " invalid Read on closed request Body"

-- 
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 result type is different on sql.Query()

[Kiki Sugiaman]

In a nutshell, Scan() internally performs several nested type switches 
based on the type of the Scan destination and what is received from the 
database (in other words, the driver).


As to why the two scans returned values of different types, more 
information is needed. But since the queries were similar and the dest 
were the same, you could start by looking at what is stored in the 
database and what's the int64/[]byte returned.


--
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] gomobile: target=ios, getting incompatible pointer types assigning to 'GoUniverseerror *' from 'goSeqErrorWrapper *' [-Wincompatible-pointer-types]

[Joe Blue]

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 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] go/types - creating a Type from whole cloth?

[Nate Finch]

Sorry, I wasn't clear. I'm using the go/types package to read go code and 
generate wrapper code for it.  And I need to generate different code based on 
the types of parameters a function takes. 

So like if a function takes a *bytes.Buffer to write to and I am generating a 
wrapper that wants the output written to an io.Writer, I need to generate 
wrapper code that creates the buffer, passes it to the function and then writes 
it to the writer output.

So, when reading a function via go/types, it has a Parameter() Tuple, and I can 
get the types.Type of each one, but I don't know how to say "Is this types.Type 
a *bytes.Buffer?"

-- 
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 result type is different on sql.Query()

[Harry]

I made a mistake.

Second query don't include placeholder.

sql := "SELECT field1, field2 FROM t_xxx"
rows1, err := ms.DB.Query(sql)

There is no error.
I'm asking why result type was changed/


2016年9月28日水曜日 19時30分23秒 UTC+9 ksug:
>
> Did you check your error after each call to Query()? 
> Without an arg, what do you expect the "?" in "flg=?" to be formatted 
> into? 
>

-- 
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 result type is different on sql.Query()

[Kiki Sugiaman]

Did you check your error after each call to Query()?
Without an arg, what do you expect the "?" in "flg=?" to be formatted into?

--
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: Web Framework

[Justin Israel]

On Wed, 28 Sep 2016, 6:50 PM Devashish Ghosh 
wrote:

> https://github.com/jabong/florest-core A lightweight workflow based REST
> API framework with features like customized workflow, logging, monitoring,
> a/b test, dynamic config, profiling, swagger, database adapters, cache
> adapter.
>

You have reposted this information about your web framework at least 3
times on this list. This particular thread is over 4 years old. A single
announcement would suffice as opposed to searching for all historical
threads that ask about web framework recommendations.


>
> On Sunday, June 24, 2012 at 4:35:41 PM UTC+5:30, Max wrote:
>>
>> What web framework do you use your self?
>>
>> Do you create webapps in Go?
>>
>> Is it good idea to create web apps with Go now?
>>
>> Web Framework do you use? I would love to have option to update some page
>> dynamically without server restart.
>> Looks like I have to proxy this pages to some other server or use FCGI.
>>
> --
> 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.