[go-nuts] Odd "socket: An invalid argument was supplied." problem, does not happen from go run ...

[Andrew Price]

I have a program that accesses a MS SQL Server via 
github.com/denisenkom/go-mssqldb. 
This from my windows 7 dev box.

It works beautifully when I start it by "go run prog.go", but when started 
as just "prog.exe" it gives the dreaded "dial tcp 10.1.11.23:1433 socket: 
An invalid argument was supplied." error.

Connection strings are identical in both cases.

I haven't tried on linux yet.

Any ideas anyone?

Thx

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.

[go-nuts] reflectutils: Easier way to use reflect to set values in Go

[Felix Sun]

https://github.com/sunfmin/reflectutils

-- 
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] Reasons why `go get` is entirely quiet by default

[Aaron Taylor]

It's also probably worth noting that 'go get' isn't really a package manager in 
the way that yarn and npm are. Each of those tools, and their go equivalents 
[1] have somewhat more sophisticated functionality related actually managing 
the packages, controlling their versions, resolving conflicts, etc. while 'go 
get' basically retrieves a package and it's dependencies if they aren't already 
present. If you're working on anything that needs to be relied upon, it's 
probably worth checking out Go's package manager ecosystem. For what it's 
worth, we use glide where I work and it has lots of output :)

[1] https://github.com/golang/go/wiki/PackageManagementTools

-- 
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] Wrong order for float64 conversion

['Chris Manghane' via golang-nuts]

In the Go Language specification under operators (
https://golang.org/ref/spec#Operators), there are a couple examples that
demonstrate this exact situation:

var u2 = 1< wrote:

> https://play.golang.org/p/iZTogUaWWl
>
> In the program above, foo and bar compile but baz does not.  It fails with
> the message: "invalid operation: 1 << b (shift of type float64)".  This
> seems to be wrong on the surface, since the order of operations should
> imply the shift takes precedence.  In the bar function, using a temporary
> variable without specifying the type shows that the compiler does know what
> to do.   What am I missing?
>
> --
> 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] Wrong order for float64 conversion

[Carl Mastrangelo]

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

In the program above, foo and bar compile but baz does not.  It fails with 
the message: "invalid operation: 1 << b (shift of type float64)".  This 
seems to be wrong on the surface, since the order of operations should 
imply the shift takes precedence.  In the bar function, using a temporary 
variable without specifying the type shows that the compiler does know what 
to do.   What am I missing?

-- 
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: Increasing memory usage from Gob, references never lost

[hiatt . dustin]

Not sure if it's intended behavior, but you are using defer conn.Close() 
inside of an infinite for loop which means the conn never closes.

On Thursday, October 13, 2016 at 4:28:57 PM UTC-5, Morgan Hein wrote:
>
> Hey Rob, I really appreciate you looking and responding to this.
>
> After your response it gave me a hunch,and after doing some more research 
> realized that you cannot deep copy the device struct like I thought I 
> could, and in fact the references are still being held to the original 
> decoded object, which is why it stays in memory. I think.
>
> I will update this post when I learn more/figure it out, but until then if 
> anyone has more thoughts i'm all ears.
>
>
> On Thursday, October 13, 2016 at 1:27:39 PM UTC-7, Roberto Zanotto wrote:
>>
>> Forgot to add... from the profile, gob is calling decodeStruct, which 
>> calls decodeMap, which allocates. So we are looking for structs that 
>> contain a map that are decoded and never garbage collected (maybe the 
>> WatheverDevices contain a map and some other goroutine reads the Devices 
>> form "input" channel and retains them?).
>>
>> On Thursday, October 13, 2016 at 10:15:36 PM UTC+2, Roberto Zanotto wrote:
>>>
>>> I took a quick look at the code. There's the Receive loop, you allocate 
>>> and decode ReceivedGobs there. As part of the ReceivedGob, a WatheverDevice 
>>> is also allocated and decoded. Assuming there are no errors in decoding, 
>>> you do SendResult(Device), which sends the Device to the "input" channel. I 
>>> seem to understand that you expect the ReceivedGobs to be garbage collected 
>>> and it seems to me that it should indeed happen. Maybe are the Devices that 
>>> are filling your memory? Where do the Devices go, after they are sent to 
>>> "input"?
>>>
>>> On Thursday, October 13, 2016 at 7:22:49 PM UTC+2, Morgan Hein wrote:

 Howdy,

 I'm struggling here, and hopefully someone can point me in the right 
 direction.


 Here's a playground with the code 
  in question. Here's the pprof 
 with memory usage 
  
 
  
 
 .


 I cannot understand why the memory usage is going up so much. As far as 
 I can tell, not only am I copying the data structure that is received in 
 the Gob, but i'm setting the original value of the ReceivedGob to nil. 
 Why, 
 then, does the reflect.mapassign and gob.Decoder continue to increase in 
 memory?

 I am either missing something about scope, pointers, or Gob. Any 
 insights or help would be greatly appreciated.

 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] Reasons why `go get` is entirely quiet by default

[Ian Davis]

On Thu, Oct 13, 2016, at 10:48 PM, Nyah Check wrote:
> Hi everyone,
>
> I don't know if someone may have talked of this here. But I just wish
> to find out why `go get` is entirely quiet by default? Unlike other
> package managers like npm or yarn. Someone asked this on the IRC
> channel today and no one seemed to know why? I tweeted[1] about this
> today; still no response yet.

Perhaps the Rule of Silence from The Art of Unix Programming

http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2878450

and

http://www.catb.org/esr/writings/taoup/html/ch11s09.html


Ian

Links:

  1. https://twitter.com/nyah_check/status/786547656155725824

-- 
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: Increasing memory usage from Gob, references never lost

[Roberto Zanotto]

Yes, when you copy the device it's not a deep (recursive) copy, so some 
fields of the device could still point to things allocated by gob.
Why do you care? I mean: supposing you want to keep the devices in memory, 
why doing a copy and not keeping the original ones?

On Thursday, October 13, 2016 at 11:28:57 PM UTC+2, Morgan Hein wrote:
>
> Hey Rob, I really appreciate you looking and responding to this.
>
> After your response it gave me a hunch,and after doing some more research 
> realized that you cannot deep copy the device struct like I thought I 
> could, and in fact the references are still being held to the original 
> decoded object, which is why it stays in memory. I think.
>
> I will update this post when I learn more/figure it out, but until then if 
> anyone has more thoughts i'm all ears.
>
>
> On Thursday, October 13, 2016 at 1:27:39 PM UTC-7, Roberto Zanotto wrote:
>>
>> Forgot to add... from the profile, gob is calling decodeStruct, which 
>> calls decodeMap, which allocates. So we are looking for structs that 
>> contain a map that are decoded and never garbage collected (maybe the 
>> WatheverDevices contain a map and some other goroutine reads the Devices 
>> form "input" channel and retains them?).
>>
>> On Thursday, October 13, 2016 at 10:15:36 PM UTC+2, Roberto Zanotto wrote:
>>>
>>> I took a quick look at the code. There's the Receive loop, you allocate 
>>> and decode ReceivedGobs there. As part of the ReceivedGob, a WatheverDevice 
>>> is also allocated and decoded. Assuming there are no errors in decoding, 
>>> you do SendResult(Device), which sends the Device to the "input" channel. I 
>>> seem to understand that you expect the ReceivedGobs to be garbage collected 
>>> and it seems to me that it should indeed happen. Maybe are the Devices that 
>>> are filling your memory? Where do the Devices go, after they are sent to 
>>> "input"?
>>>
>>> On Thursday, October 13, 2016 at 7:22:49 PM UTC+2, Morgan Hein wrote:

 Howdy,

 I'm struggling here, and hopefully someone can point me in the right 
 direction.


 Here's a playground with the code 
  in question. Here's the pprof 
 with memory usage 
  
 
  
 
  
 
 .


 I cannot understand why the memory usage is going up so much. As far as 
 I can tell, not only am I copying the data structure that is received in 
 the Gob, but i'm setting the original value of the ReceivedGob to nil. 
 Why, 
 then, does the reflect.mapassign and gob.Decoder continue to increase in 
 memory?

 I am either missing something about scope, pointers, or Gob. Any 
 insights or help would be greatly appreciated.

 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] Reasons why `go get` is entirely quiet by default

['Axel Wagner' via golang-nuts]

Because that's good practice for a cli-tool. No output means success. Only
print information that is actually needed. For a successful go-get, that's
none.

On Thu, Oct 13, 2016 at 11:48 PM, Nyah Check  wrote:

> Hi everyone,
>
> I don't know if someone may have talked of this here. But I just wish to
> find out why `go get` is entirely quiet by default? Unlike other package
> managers like npm or yarn. Someone asked this on the IRC channel today and
> no one seemed to know why? I tweeted
>  about this
> today; still no response yet.
>
> Thanks,
> Nyah
>
> "The heaviest penalty for declining to rule is to be ruled by someone
> inferior to yourself." --*Plato*
>
> --
> 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] Reasons why `go get` is entirely quiet by default

[Nyah Check]

Hi everyone,

I don't know if someone may have talked of this here. But I just wish to
find out why `go get` is entirely quiet by default? Unlike other package
managers like npm or yarn. Someone asked this on the IRC channel today and
no one seemed to know why? I tweeted
 about this
today; still no response yet.

Thanks,
Nyah

"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
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: Increasing memory usage from Gob, references never lost

[Morgan Hein]

Hey Rob, I really appreciate you looking and responding to this.

After your response it gave me a hunch,and after doing some more research 
realized that you cannot deep copy the device struct like I thought I 
could, and in fact the references are still being held to the original 
decoded object, which is why it stays in memory. I think.

I will update this post when I learn more/figure it out, but until then if 
anyone has more thoughts i'm all ears.


On Thursday, October 13, 2016 at 1:27:39 PM UTC-7, Roberto Zanotto wrote:
>
> Forgot to add... from the profile, gob is calling decodeStruct, which 
> calls decodeMap, which allocates. So we are looking for structs that 
> contain a map that are decoded and never garbage collected (maybe the 
> WatheverDevices contain a map and some other goroutine reads the Devices 
> form "input" channel and retains them?).
>
> On Thursday, October 13, 2016 at 10:15:36 PM UTC+2, Roberto Zanotto wrote:
>>
>> I took a quick look at the code. There's the Receive loop, you allocate 
>> and decode ReceivedGobs there. As part of the ReceivedGob, a WatheverDevice 
>> is also allocated and decoded. Assuming there are no errors in decoding, 
>> you do SendResult(Device), which sends the Device to the "input" channel. I 
>> seem to understand that you expect the ReceivedGobs to be garbage collected 
>> and it seems to me that it should indeed happen. Maybe are the Devices that 
>> are filling your memory? Where do the Devices go, after they are sent to 
>> "input"?
>>
>> On Thursday, October 13, 2016 at 7:22:49 PM UTC+2, Morgan Hein wrote:
>>>
>>> Howdy,
>>>
>>> I'm struggling here, and hopefully someone can point me in the right 
>>> direction.
>>>
>>>
>>> Here's a playground with the code  
>>> in question. Here's the pprof with memory usage 
>>>  
>>> 
>>>  
>>> 
>>> .
>>>
>>>
>>> I cannot understand why the memory usage is going up so much. As far as 
>>> I can tell, not only am I copying the data structure that is received in 
>>> the Gob, but i'm setting the original value of the ReceivedGob to nil. Why, 
>>> then, does the reflect.mapassign and gob.Decoder continue to increase in 
>>> memory?
>>>
>>> I am either missing something about scope, pointers, or Gob. Any 
>>> insights or help would be greatly appreciated.
>>>
>>> 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] Re: package versioning

['Eric Johnson' via golang-nuts]

On 10/12/16 2:32 AM, Peter Vypov wrote:



On Wednesday, October 12, 2016 at 2:04:19 AM UTC+2, Eric Johnson wrote:

My view is that the general case requires putting such metadata in
a separate file for a package.

Yes, I agree with you that having multiple Go files with such comments 
creates repetition (having to update multiple files) and forgetting to 
update one of those makes it ambiguous which particular version is 
going to be installed.


[...] after the current package management efforts nail down that
metadata file.

Having been working with dependency management tools such `godep` and 
`glide` would much prefer not to deal with any metadata files at all, 
with their location, format, and naming conventions.
I suspect the annoyance of this will disappear when the team trying to 
standardize this actually succeeds, and then it is always the same 
metadata files. Then, you'll eventually be glad they're there.


How about an implied metadata file when you specify package versions 
on the `go get` command line but nowhere in source code or metadata 
files. Would such a tradeoff work?


|
go get-u github.com/spf13/cobra:v1.10.0\
  github.com/spf13/viper:v0.10.0\
  github.com/pelletier/go-toml:v0.3.4

|

This has a drawback that dependent packages are going to be installed 
as their latest versions, so the ordering is important.


If I can't source control it, I don't think it will work.



The reason for asking this question is that in recent months tools 
like `glide` (https://github.com/Masterminds/glide) gained popularity 
and some third-party packages require you to do `glide up` to populate 
it properly in addition / instead of the regular `go  get`. This means 
that for a package that uses such a glided package, you'd need to 
create a Makefile (or shell script) with a `glide up` and other 
non-`go` commands in it (which is ugly).


Again, hopefully the dependency management team will make some headway. 
Then we might see an evolution of the standard tools.


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.

[go-nuts] Re: Increasing memory usage from Gob, references never lost

[Roberto Zanotto]

Forgot to add... from the profile, gob is calling decodeStruct, which calls 
decodeMap, which allocates. So we are looking for structs that contain a 
map that are decoded and never garbage collected (maybe the WatheverDevices 
contain a map and some other goroutine reads the Devices form "input" 
channel and retains them?).

On Thursday, October 13, 2016 at 10:15:36 PM UTC+2, Roberto Zanotto wrote:
>
> I took a quick look at the code. There's the Receive loop, you allocate 
> and decode ReceivedGobs there. As part of the ReceivedGob, a WatheverDevice 
> is also allocated and decoded. Assuming there are no errors in decoding, 
> you do SendResult(Device), which sends the Device to the "input" channel. I 
> seem to understand that you expect the ReceivedGobs to be garbage collected 
> and it seems to me that it should indeed happen. Maybe are the Devices that 
> are filling your memory? Where do the Devices go, after they are sent to 
> "input"?
>
> On Thursday, October 13, 2016 at 7:22:49 PM UTC+2, Morgan Hein wrote:
>>
>> Howdy,
>>
>> I'm struggling here, and hopefully someone can point me in the right 
>> direction.
>>
>>
>> Here's a playground with the code  
>> in question. Here's the pprof with memory usage 
>>  
>> 
>>  
>> 
>> .
>>
>>
>> I cannot understand why the memory usage is going up so much. As far as I 
>> can tell, not only am I copying the data structure that is received in the 
>> Gob, but i'm setting the original value of the ReceivedGob to nil. Why, 
>> then, does the reflect.mapassign and gob.Decoder continue to increase in 
>> memory?
>>
>> I am either missing something about scope, pointers, or Gob. Any insights 
>> or help would be greatly appreciated.
>>
>> 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] stdout to zlib and then to io.reader service

[Pietro Gagliardi]

What's the other end (the "other service") look like?

> On Oct 13, 2016, at 1:43 PM, Walter Garcia  wrote:
> 
> Hello all
> Im trying to test using zlib.
> 
> In my test I need compress the Stdout from exec.Command to zlib and then send 
> to io.reader to use in other service
> 
> cmd := exec.Command("mysqldump", args...)
> ..
> cmd.StdoutPipe()
> 
> z := zlib.NewWriter( ... )
> .
> z -> to -> io.reader
> 
> Could you help me?
> 
> Thanks in advance
> 
> -- 
> 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] stdout to zlib and then to io.reader service

[Walter Garcia]

Hello all
Im trying to test using zlib.

In my test I need compress the Stdout from exec.Command to zlib and then 
send to io.reader to use in other service

cmd := exec.Command("mysqldump", args...)
..
cmd.StdoutPipe()

z := zlib.NewWriter( ... )
.
z -> to -> io.reader

Could you help me?

Thanks in advance

-- 
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] don't understand the comment in spec Type assertions section

[digg]

On Friday, October 14, 2016 at 1:33:52 AM UTC+8, di...@veryhaha.com wrote:
>
>
>
> On Friday, October 14, 2016 at 1:28:01 AM UTC+8, di...@veryhaha.com wrote:
>>
>>
>>
>> On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote:
>>>
>>> In that example y is a nil interface value of type l. The last line 
>>> implies that for a type assertion to another interface type, the operation 
>>> will only be possible if the underlying value implements both interfaces. 
>>> That is, the value must have an m() method as well as all of io.reader 
>>> methods or the type assertion will like the above assertion to a string 
>>> type.
>>>
>>
>> But it looks it is not essential for the underlying value implements 
>> io.Reader. 
>> The code always compiles, whether or not the underlying value implements 
>> io.Reader. 
>> The difference is:
>> * if the underlying value implements io.Reader, then r is a non-nil 
>> io.Reader value
>> * if the underlying value doesn't implement io.Reader, then r is a nil 
>> io.Reader value
>>
>
> sorry, my mistake, if the underlying value doesn't implement io.Reader, 
> the last line will panic.
>

but it compiles even if the underlying value doesn't implement io.Reader, 
not like the " s := y.(string) ", which doesn't compile.
 

>  
>
>>  
>>
>>>
>>> On Oct 13, 2016 7:48 AM,  wrote:
>>>
>>>
>>>
>>> On Thursday, October 13, 2016 at 8:52:14 PM UTC+8, Jan Mercl wrote:
>>>
 On Thu, Oct 13, 2016 at 2:42 PM  wrote:

 > I don't understand the comment of the last line. Can someone explain 
 it for me?

 "r has type io.Reader" means that the type if expr.(T) is T.

 "and y must implement both I and io.Reader"

 y is either nil or it implements I, because that's how it was declared 
 and nothing not implementing I can be assigned to it. The dynamic type of 
 y 
 can implement any number of interfaces, so it can implement both I and 
 io.Reader. The later is checked at run time when the type assertion 
 expression y.(io.Reader) is actually evaluated.

 -- 

 -j

>>>
>>> So "y must implement both I and io.Reader" means short form of "the 
>>> dynamic type of y must implement both I and io.Reader"?
>>> My brain really can't accept this short form.
>>>
>>> And in that example, it gives people the impression y is nil. I really 
>>> think it is a bad example.
>>>
>>>
>>>
>>>
>>>
>>>
>>> I feel that comment (and that example) is very not professional for 
>>> these reason:
>>> 1. y is a value of type I, 
>>>
>>>
>>> -- 
>>> 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] don't understand the comment in spec Type assertions section

[digg]

On Friday, October 14, 2016 at 1:28:01 AM UTC+8, di...@veryhaha.com wrote:
>
>
>
> On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote:
>>
>> In that example y is a nil interface value of type l. The last line 
>> implies that for a type assertion to another interface type, the operation 
>> will only be possible if the underlying value implements both interfaces. 
>> That is, the value must have an m() method as well as all of io.reader 
>> methods or the type assertion will like the above assertion to a string 
>> type.
>>
>
> But it looks it is not essential for the underlying value implements 
> io.Reader. 
> The code always compiles, whether or not the underlying value implements 
> io.Reader. 
> The difference is:
> * if the underlying value implements io.Reader, then r is a non-nil 
> io.Reader value
> * if the underlying value doesn't implement io.Reader, then r is a nil 
> io.Reader value
>

sorry, my mistake, if the underlying value doesn't implement io.Reader, the 
last line will panic.
 

>  
>
>>
>> On Oct 13, 2016 7:48 AM,  wrote:
>>
>>
>>
>> On Thursday, October 13, 2016 at 8:52:14 PM UTC+8, Jan Mercl wrote:
>>
>>> On Thu, Oct 13, 2016 at 2:42 PM  wrote:
>>>
>>> > I don't understand the comment of the last line. Can someone explain 
>>> it for me?
>>>
>>> "r has type io.Reader" means that the type if expr.(T) is T.
>>>
>>> "and y must implement both I and io.Reader"
>>>
>>> y is either nil or it implements I, because that's how it was declared 
>>> and nothing not implementing I can be assigned to it. The dynamic type of y 
>>> can implement any number of interfaces, so it can implement both I and 
>>> io.Reader. The later is checked at run time when the type assertion 
>>> expression y.(io.Reader) is actually evaluated.
>>>
>>> -- 
>>>
>>> -j
>>>
>>
>> So "y must implement both I and io.Reader" means short form of "the 
>> dynamic type of y must implement both I and io.Reader"?
>> My brain really can't accept this short form.
>>
>> And in that example, it gives people the impression y is nil. I really 
>> think it is a bad example.
>>
>>
>>
>>
>>
>>
>> I feel that comment (and that example) is very not professional for these 
>> reason:
>> 1. y is a value of type I, 
>>
>>
>> -- 
>> 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] Increasing memory usage from Gob, references never lost

[Morgan Hein]

Howdy,

I'm struggling here, and hopefully someone can point me in the right 
direction.


Here's a playground with the code  in 
question. Here's the pprof with memory usage 
.


I cannot understand why the memory usage is going up so much. As far as I 
can tell, not only am I copying the data structure that is received in the 
Gob, but i'm setting the original value of the ReceivedGob to nil. Why, 
then, does the reflect.mapassign and gob.Decoder continue to increase in 
memory?

I am either missing something about scope, pointers, or Gob. Any insights 
or help would be greatly appreciated.

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] don't understand the comment in spec Type assertions section

[digg]

On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote:
>
> In that example y is a nil interface value of type l. The last line 
> implies that for a type assertion to another interface type, the operation 
> will only be possible if the underlying value implements both interfaces. 
> That is, the value must have an m() method as well as all of io.reader 
> methods or the type assertion will like the above assertion to a string 
> type.
>

But it looks it is not essential for the underlying value implements 
io.Reader. 
The code always compiles, whether or not the underlying value implements 
io.Reader. 
The difference is:
* if the underlying value implements io.Reader, then r is a non-nil 
io.Reader value
* if the underlying value doesn't implement io.Reader, then r is a nil 
io.Reader value
 

>
> On Oct 13, 2016 7:48 AM,  wrote:
>
>
>
> On Thursday, October 13, 2016 at 8:52:14 PM UTC+8, Jan Mercl wrote:
>
>> On Thu, Oct 13, 2016 at 2:42 PM  wrote:
>>
>> > I don't understand the comment of the last line. Can someone explain it 
>> for me?
>>
>> "r has type io.Reader" means that the type if expr.(T) is T.
>>
>> "and y must implement both I and io.Reader"
>>
>> y is either nil or it implements I, because that's how it was declared 
>> and nothing not implementing I can be assigned to it. The dynamic type of y 
>> can implement any number of interfaces, so it can implement both I and 
>> io.Reader. The later is checked at run time when the type assertion 
>> expression y.(io.Reader) is actually evaluated.
>>
>> -- 
>>
>> -j
>>
>
> So "y must implement both I and io.Reader" means short form of "the 
> dynamic type of y must implement both I and io.Reader"?
> My brain really can't accept this short form.
>
> And in that example, it gives people the impression y is nil. I really 
> think it is a bad example.
>
>
>
>
>
>
> I feel that comment (and that example) is very not professional for these 
> reason:
> 1. y is a value of type I, 
>
>
> -- 
> 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 "_ := x" is illegal but "var _ = x" is legal?

[digg]

On Friday, October 14, 2016 at 12:49:43 AM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Oct 13, 2016 at 9:40 AM,   
> wrote: 
> > 
> > On Friday, October 14, 2016 at 12:14:34 AM UTC+8, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Thu, Oct 13, 2016 at 8:36 AM,   wrote: 
> >> > 
> >> > On Thursday, October 13, 2016 at 11:24:50 PM UTC+8, Jesper Louis 
> >> > Andersen 
> >> > wrote: 
> >> >> 
> >> >> The rule is that a short variable declaration requires that at least 
> >> >> one 
> >> >> non-blank variable is new (the specification even says so) Consider 
> >> >> 
> >> >> _, y := 4,5 
> >> >> 
> >> >> where one variable, y, is new. In 
> >> >> 
> >> >> _ := 6 
> >> >> 
> >> >> or 
> >> >> 
> >> >> _, _ := 5, 7 
> >> >> 
> >> >> this rule is violated, since there are no non-blank variables (and 
> thus 
> >> >> vacuously nothing new). 
> >> >> 
> >> >> I think the reason this is a rule is because it may detect some 
> >> >> spurious 
> >> >> errors by forcing the programmer to write code in a certain style, 
> but 
> >> >> I may 
> >> >> be wrong. 
> >> > 
> >> > 
> >> > 
> >> > What spurious errors? 
> >> 
> >> The error of thinking that because you are using := you are getting a 
> >> new variable. 
> >> 
> >> The handling of := is a bit tricky, perhaps too tricky.  It used to 
> >> always declare new variables, and give an error if there was already a 
> >> variable of the same name in the same scope.  But that was too painful 
> >> to use with the err variable, because of the common use of 
> >> n, err := F() 
> >> So := was changed to permit reusing a variable if it already existed 
> >> in the same scope with the same name and (inferred) type. 
> > 
> > 
> > But the long variable declaration form only allows all variables are new 
> > ones generally, except for the blank _ identifier. 
> > Why not also make an exception for the blank _ identifier in the short 
> form? 
>
> Every language change has a cost and a benefit.  The cost of this 
> change is that right now we have a simple rule: a := statement must 
> define at least one new variable.  You are suggesting that we replace 
> that with a more complicated rule: a := statement must define at least 
> one new variable, except in the case where all the variables are the 
> blank identifier, in which case it is OK.  Also, the language is 
> stable, so any change at all carries a cost.  The benefit of this 
> particular change seems to me to be very very small: when you have an 
> existing `a, _ := b, c` statement, you can change it to `_, _ := b, c` 
> instead of changing it to `_, _ = b, c`.  I don't see why the very 
> small benefit outweighs the cost. 
>
> I'm just speaking for myself, of course.  If this is important to you, 
> you could write this up as a language change proposal, describing the 
> change and presenting an argument for why the benefit outweighs the 
> cost.  See https://github.com/golang/proposal .  But I suspect that 
> such a proposal would be rejected unless the argument in favor was 
> quite convincing. 
>
> Ian 
>

yes, I have filed one: https://github.com/golang/go/issues/17429
and yes, it was rejected. 

I admit this is really not a big problem.

-- 
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 "_ := x" is illegal but "var _ = x" is legal?

[digg]

On Friday, October 14, 2016 at 12:14:34 AM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Oct 13, 2016 at 8:36 AM,   
> wrote: 
> > 
> > On Thursday, October 13, 2016 at 11:24:50 PM UTC+8, Jesper Louis 
> Andersen 
> > wrote: 
> >> 
> >> The rule is that a short variable declaration requires that at least 
> one 
> >> non-blank variable is new (the specification even says so) Consider 
> >> 
> >> _, y := 4,5 
> >> 
> >> where one variable, y, is new. In 
> >> 
> >> _ := 6 
> >> 
> >> or 
> >> 
> >> _, _ := 5, 7 
> >> 
> >> this rule is violated, since there are no non-blank variables (and thus 
> >> vacuously nothing new). 
> >> 
> >> I think the reason this is a rule is because it may detect some 
> spurious 
> >> errors by forcing the programmer to write code in a certain style, but 
> I may 
> >> be wrong. 
> > 
> > 
> > 
> > What spurious errors? 
>
> The error of thinking that because you are using := you are getting a 
> new variable. 
>
> The handling of := is a bit tricky, perhaps too tricky.  It used to 
> always declare new variables, and give an error if there was already a 
> variable of the same name in the same scope.  But that was too painful 
> to use with the err variable, because of the common use of 
> n, err := F() 
> So := was changed to permit reusing a variable if it already existed 
> in the same scope with the same name and (inferred) type. 
>
> Ian 
>

But the long variable declaration form only allows all variables are new 
ones generally, except for the blank _ identifier.
Why not also make an exception for the blank _ identifier in the short 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 "_ := x" is illegal but "var _ = x" is legal?

[Ian Lance Taylor]

On Thu, Oct 13, 2016 at 8:36 AM,   wrote:
>
> On Thursday, October 13, 2016 at 11:24:50 PM UTC+8, Jesper Louis Andersen
> wrote:
>>
>> The rule is that a short variable declaration requires that at least one
>> non-blank variable is new (the specification even says so) Consider
>>
>> _, y := 4,5
>>
>> where one variable, y, is new. In
>>
>> _ := 6
>>
>> or
>>
>> _, _ := 5, 7
>>
>> this rule is violated, since there are no non-blank variables (and thus
>> vacuously nothing new).
>>
>> I think the reason this is a rule is because it may detect some spurious
>> errors by forcing the programmer to write code in a certain style, but I may
>> be wrong.
>
>
>
> What spurious errors?

The error of thinking that because you are using := you are getting a
new variable.

The handling of := is a bit tricky, perhaps too tricky.  It used to
always declare new variables, and give an error if there was already a
variable of the same name in the same scope.  But that was too painful
to use with the err variable, because of the common use of
n, err := F()
So := was changed to permit reusing a variable if it already existed
in the same scope with the same name and (inferred) type.

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: Are all bytes, alloced for any zero value of any type, zeros?

[Konstantin Khomoutov]

On Thu, 13 Oct 2016 08:27:57 -0700 (PDT)
adonovan via golang-nuts  wrote:

> Yes, the memory representation of the zero value of any type consists
> only of zero bytes.

A nitpick, but recalling the famous comp.lang.C FAQ, I'd say the
assumption that a NULL (than is, "officially invalid") pointer consists
of zero bytes is wrong: on certain H/W arches the memory address 0 is
valid and such an "officially invalid" pointer's value may well be
different from 0.

Since the zero value of a pointer, I beleive, is defined to point to no
valid object, this rule applies to pointers.

I think that ATM Go does not support any such "weird" architecture but
still I'd be easier with stating "any type" :-)

> However, this is an implementation detail and not a consequence of
> the spec.

This is surely true, I concur.

-- 
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: Are all bytes, alloced for any zero value of any type, zeros?

[digg]

On Thursday, October 13, 2016 at 11:28:11 PM UTC+8, adon...@google.com 
wrote:
>
> Yes, the memory representation of the zero value of any type consists only 
> of zero bytes.
> However, this is an implementation detail and not a consequence of the 
> spec.
>

Thanks for the explanation. 

-- 
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] don't understand the comment in spec Type assertions section

[digg]

On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote:
>
> In that example y is a nil interface value of type l. The last line 
> implies that for a type assertion to another interface type, the operation 
> will only be possible if the underlying value implements both interfaces. 
> That is, the value must have an m() method as well as all of io.reader 
> methods or the type assertion will like the above assertion to a string 
> type.
>

It would be great if the spec can explain things as clear as you.
 

>
> On Oct 13, 2016 7:48 AM,  wrote:
>
>
>
> On Thursday, October 13, 2016 at 8:52:14 PM UTC+8, Jan Mercl wrote:
>
>> On Thu, Oct 13, 2016 at 2:42 PM  wrote:
>>
>> > I don't understand the comment of the last line. Can someone explain it 
>> for me?
>>
>> "r has type io.Reader" means that the type if expr.(T) is T.
>>
>> "and y must implement both I and io.Reader"
>>
>> y is either nil or it implements I, because that's how it was declared 
>> and nothing not implementing I can be assigned to it. The dynamic type of y 
>> can implement any number of interfaces, so it can implement both I and 
>> io.Reader. The later is checked at run time when the type assertion 
>> expression y.(io.Reader) is actually evaluated.
>>
>> -- 
>>
>> -j
>>
>
> So "y must implement both I and io.Reader" means short form of "the 
> dynamic type of y must implement both I and io.Reader"?
> My brain really can't accept this short form.
>
> And in that example, it gives people the impression y is nil. I really 
> think it is a bad example.
>
>
>
>
>
>
> I feel that comment (and that example) is very not professional for these 
> reason:
> 1. y is a value of type I, 
>
>
> -- 
> 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] About panic/recover in Golang

[Jesper Louis Andersen]

On Thu, Oct 13, 2016 at 3:54 PM Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

>
> That's because there's the difference between the so-called normative
> texts and so-called informative texts.  Normative texts intently use dry
> language with as minimal wording as possible to not accidently state
> more than should have stated.  You can found this pattern everywhere --
> from civil laws to patents to RFCs and ITU-T recommendations etc.
>
>
>
An even better approach is to write the text in a formal semantics such as
structural operational semantics. This removes another layer of
interpretative error in the text. It has been done for real-world
languages: Standard ML is an example, where its 1997 specification is about
70 pages of operational semantics. Javascripts normative description is
very close to the ideal as well.

One powerful aspect is that you can then write every rule from the
semantics into, say, a Prolog system and then you can ask the system what
the correct behavior is for a given program. This allows multiple
implementations to solve discrepancies by asking the spec who is right.

One caveat though is that in the last couple of years much have happened in
the area. You would not write a modern spec as is done in the 1997 SML
spec, as we have learnt that there are some constructions which look
formal, but aren't. That is, even if your goal is formality, there are
informal assumptions you have made which in turn gives a window for
interpretation. A long term goal is to eliminate those.

-- 
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 "_ := x" is illegal but "var _ = x" is legal?

[Jesper Louis Andersen]

The rule is that a short variable declaration requires that at least one
non-blank variable is new (the specification even says so) Consider

_, y := 4,5

where one variable, y, is new. In

_ := 6

or

_, _ := 5, 7

this rule is violated, since there are no non-blank variables (and thus
vacuously nothing new).

I think the reason this is a rule is because it may detect some spurious
errors by forcing the programmer to write code in a certain style, but I
may be wrong.

On Thu, Oct 13, 2016 at 4:50 PM  wrote:

> .
>
> --
> 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] don't understand the comment in spec Type assertions section

['Chris Manghane' via golang-nuts]

In that example y is a nil interface value of type l. The last line implies
that for a type assertion to another interface type, the operation will
only be possible if the underlying value implements both interfaces. That
is, the value must have an m() method as well as all of io.reader methods
or the type assertion will like the above assertion to a string type.

On Oct 13, 2016 7:48 AM,  wrote:



On Thursday, October 13, 2016 at 8:52:14 PM UTC+8, Jan Mercl wrote:

> On Thu, Oct 13, 2016 at 2:42 PM  wrote:
>
> > I don't understand the comment of the last line. Can someone explain it
> for me?
>
> "r has type io.Reader" means that the type if expr.(T) is T.
>
> "and y must implement both I and io.Reader"
>
> y is either nil or it implements I, because that's how it was declared and
> nothing not implementing I can be assigned to it. The dynamic type of y can
> implement any number of interfaces, so it can implement both I and
> io.Reader. The later is checked at run time when the type assertion
> expression y.(io.Reader) is actually evaluated.
>
> --
>
> -j
>

So "y must implement both I and io.Reader" means short form of "the dynamic
type of y must implement both I and io.Reader"?
My brain really can't accept this short form.

And in that example, it gives people the impression y is nil. I really
think it is a bad example.






I feel that comment (and that example) is very not professional for these
reason:
1. y is a value of type I,


-- 
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] Are all bytes, alloced for any zero value of any type, zeros?

[digg]

.

-- 
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] Function pointer vs interface for callback?

[Chris Hines]

If you want to dig into this topic more. I gave a presentation on this 
topic at my local Go meetup earlier this year.

The slides from my talk are 
here: 
http://go-talks.appspot.com/github.com/ChrisHines/talks/non-orthogonal-choices-in-go/non-orthogonal-choices-in-go.slide#1

Some of the code examples will not run on the public go-talks app. The 
source material is 
at https://github.com/ChrisHines/talks/tree/master/non-orthogonal-choices-in-go.

If you just want my conclusion:

*Informed choices for dynamic behavior:*

Use interface values when:

   - Well known interfaces already exist, e.g. io.Reader
   - More than one behavior required
   - Typically stateful
   - Implementations non-trivial

Use function values when:

   - Only one behavior
   - Typically stateless
   - In-line implementations typical

Based on these guidelines and the outline of your code you've provided, I 
agree with Ian that a function value is the best fit for your case.

Chris

On Wednesday, October 12, 2016 at 2:33:47 PM UTC-4, Shaun Crampton wrote:
>
> Thanks for the tips.
>
> On Wed, Oct 12, 2016 at 2:11 PM Jesse McNelis  > wrote:
>
>> On Wed, Oct 12, 2016 at 11:05 PM,   wrote:
>> >  Seems like a function
>> > pointer is more universal (I don't even need an object to be a 
>> receiver) but
>> > maybe an interface is more idiomatic?
>>
>> An interesting pattern from the http pkg is that a function type can
>> also implement an interface.
>> https://golang.org/pkg/net/http/#HandlerFunc
>>
>

-- 
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] About panic/recover in Golang

[digg]

On Thursday, October 13, 2016 at 9:55:01 PM UTC+8, Konstantin Khomoutov 
wrote:
>
> On Thu, 13 Oct 2016 05:47:33 -0700 (PDT) 
> di...@veryhaha.com  wrote: 
>
> [...] 
> > Thanks, Ian. 
> > The recover1.go has many great examples to understand the mechanism 
> > of panic/recover. 
> > I think I have get it. 
> > And I still think the spec doc is shallow. 
>
> That's because there's the difference between the so-called normative 
> texts and so-called informative texts.  Normative texts intently use dry 
> language with as minimal wording as possible to not accidently state 
> more than should have stated.  You can found this pattern everywhere -- 
> from civil laws to patents to RFCs and ITU-T recommendations etc. 
>
> What's supposedly missing is some piece of documentation accompanying 
> the spec which would provide informative bits.  This could possibly be 
> a community-provided thing. 
>

Good point.
 

-- 
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] don't understand the comment in spec Type assertions section

[digg]

On Thursday, October 13, 2016 at 8:52:14 PM UTC+8, Jan Mercl wrote:
>
> On Thu, Oct 13, 2016 at 2:42 PM  wrote:
>
> > I don't understand the comment of the last line. Can someone explain it 
> for me?
>
> "r has type io.Reader" means that the type if expr.(T) is T.
>
> "and y must implement both I and io.Reader"
>
> y is either nil or it implements I, because that's how it was declared and 
> nothing not implementing I can be assigned to it. The dynamic type of y can 
> implement any number of interfaces, so it can implement both I and 
> io.Reader. The later is checked at run time when the type assertion 
> expression y.(io.Reader) is actually evaluated.
>
> -- 
>
> -j
>

So "y must implement both I and io.Reader" means short form of "the dynamic 
type of y must implement both I and io.Reader"?
My brain really can't accept this short form.

And in that example, it gives people the impression y is nil. I really 
think it is a bad example.






I feel that comment (and that example) is very not professional for these 
reason:
1. y is a value of type I, 


-- 
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] About panic/recover in Golang

[Konstantin Khomoutov]

On Thu, 13 Oct 2016 05:47:33 -0700 (PDT)
d...@veryhaha.com wrote:

[...]
> Thanks, Ian. 
> The recover1.go has many great examples to understand the mechanism
> of panic/recover.
> I think I have get it.
> And I still think the spec doc is shallow.

That's because there's the difference between the so-called normative
texts and so-called informative texts.  Normative texts intently use dry
language with as minimal wording as possible to not accidently state
more than should have stated.  You can found this pattern everywhere --
from civil laws to patents to RFCs and ITU-T recommendations etc.

What's supposedly missing is some piece of documentation accompanying
the spec which would provide informative bits.  This could possibly be
a community-provided thing.

-- 
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] NullTime in SQL drivers: how to leak them to the user?

[Lucio De Re]

It will take me a while to reproduce the error, but it involved on one
hand refusing to accept the "mysql" import and on the other claiming
that the "mysql" in "mysql.NullTime" wasn't defined (from memory).

I have borrowed code I found elsewhere, but it's not as comprehensive
as I may wish and seems a ridiculous work-around.

Lucio.

On 10/13/16, Pietro Gagliardi  wrote:
> What error do you get? Can you paste it here?
>
> In the meantime, does pq's license allow you to just copy its NullTime into
> your project?
>
>> On Oct 13, 2016, at 8:34 AM, Lucio  wrote:
>>
>> I used
>>
>>   import "github.com/lib/pq"
>>
>>...
>>
>>   var t pq.NullTime
>>
>>   ...
>>
>> successfully in the past, but using
>>
>>   import "github.com/go-sql-driver/mysql"
>>
>> in the same context seems to fail with an error I don't quite understand.
>>
>> How is one to access the NullTime in mysql, if the import cannot be
>> visible? Is there a trick I have overlooked?
>>
>> I have checked a previous thread along these lines, but it does not
>> disclose how it's done, even though the tools for it seem to be in place
>> (mysql.NullTime does exist).
>>
>> Help, anyone?
>>
>> Lucio.
>>
>>
>> --
>> 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
>> .
>
>


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824
FAX: +27 58 653 1435

-- 
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] NullTime in SQL drivers: how to leak them to the user?

[Pietro Gagliardi]

What error do you get? Can you paste it here?

In the meantime, does pq's license allow you to just copy its NullTime into 
your project?

> On Oct 13, 2016, at 8:34 AM, Lucio  wrote:
> 
> I used
> 
>   import "github.com/lib/pq"
> 
>...
> 
>   var t pq.NullTime
> 
>   ...
> 
> successfully in the past, but using
> 
>   import "github.com/go-sql-driver/mysql"
> 
> in the same context seems to fail with an error I don't quite understand.
> 
> How is one to access the NullTime in mysql, if the import cannot be visible? 
> Is there a trick I have overlooked?
> 
> I have checked a previous thread along these lines, but it does not disclose 
> how it's done, even though the tools for it seem to be in place 
> (mysql.NullTime does exist).
> 
> Help, anyone?
> 
> Lucio.
> 
> 
> -- 
> 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] don't understand the comment in spec Type assertions section

[Jan Mercl]

On Thu, Oct 13, 2016 at 2:42 PM  wrote:

> I don't understand the comment of the last line. Can someone explain it
for me?

"r has type io.Reader" means that the type if expr.(T) is T.

"and y must implement both I and io.Reader"

y is either nil or it implements I, because that's how it was declared and
nothing not implementing I can be assigned to it. The dynamic type of y can
implement any number of interfaces, so it can implement both I and
io.Reader. The later is checked at run time when the type assertion
expression y.(io.Reader) is actually evaluated.

-- 

-j

-- 
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] About panic/recover in Golang

[digg]

On Thursday, October 13, 2016 at 1:30:48 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Oct 12, 2016 at 9:21 AM,   
> wrote: 
> > I don't like the spec docs for panic/recover in Golang, for the spec 
> docs is 
> > vague and not clear on when recover will take effect. 
> > 
> > So I wrote some examples to get the mechanism of panic/recover in 
> Golang. 
> > 
> > // example A 
> > func main() { 
> > defer func() { 
> > fmt.Println(recover()) 
> > }() 
> > panic(1) // recovered 
> > } 
> > 
> > = result: 
> > 1 
> > 
> > 
> > 
> > // example B 
> > func main() { 
> > defer func() { 
> > defer func() { 
> > fmt.Println(recover()) 
> > }() 
> > 
> > panic(2) // recovered 
> > }() 
> > panic(1) // not recover 
> > } 
> > 
> > = result: 
> > 2 
> > panic: 1 
> > 
> > 
> > 
> > // example c 
> > func main() { 
> > defer func() { 
> > defer func() { 
> > recover() 
> > panic(3) 
> > }() 
> > panic(2) 
> > }() 
> > panic(1) 
> > } 
> > 
> > = result: 
> > 2 
> > panic: 1 
> > panic: 2 [recovered] 
> > panic: 3 
> > 
> > 
> > 
> > 
> > // example D 
> > func main() { 
> > defer func() { 
> > recover() 
> > }() 
> > defer func() { 
> > panic(2) // recovered, (overwrite 1) 
> > }() 
> > defer func() { 
> > panic(1) // recovered, (overwritten by 2) 
> > }() 
> > } 
> > 
> > = result: 
> > 2 
> > 
> > 
> > 
> > // example E 
> > func main() { 
> > defer func() { 
> > defer func() { 
> > fmt.Println(recover()) 
> > }() 
> > }() 
> > panic(1) // not recover 
> > } 
> > 
> > = result: 
> >  
> > panic: 1 
> > 
> > 
> > 
> > // example F 
> > func main() { 
> > defer func() { 
> > func() { 
> > fmt.Println(recover()) 
> > }() 
> > }() 
> > panic(1) // not recover 
> > } 
> > 
> > = result (same as last one): 
> >  
> > panic: 1 
> > 
> > 
> > 
> > 
> > // example G 
> > func main() { 
> > defer fmt.Println(recover()) 
> > panic(1) // not recover 
> > } 
> > 
> > = result: 
> >  
> > panic: 1 
> > 
> > 
> > // example H 
> > func main() { 
> > defer func() { 
> > fmt.Println(recover()) 
> > }() 
> > 
> > func() { 
> > func() { 
> > panic(1) // recovered 
> > }() 
> > }() 
> > } 
> > 
> > = result: 
> > 1 
> > 
> > 
> > So, it looks the calling of recover only takes effect only when both of 
> the 
> > following two conditions are met: 
> > 1. the caller of calling recover must be a deferred function calling . 
> > 2. the panic must happened in (may not originate from) the caller 
> function 
> > of caller of calling recover. 
> > 
> > Where or not the calling of recover is deferred or not is not important. 
> > 
> > Is the conclusion right? 
>
> The rules are in the language spec: 
>
> The return value of recover is nil if any of the following conditions 
> holds: 
>
> * panic's argument was nil; 
> * the goroutine is not panicking; 
> * recover was not called directly by a deferred function. 
>
> If I understand your rule 1 correctly, it is the same as the third 
> rule in the spec, though they are reversed because you are describing 
> the case where recover returns non-nil and the spec is describing the 
> case where recover returns nil. 
>
> I don't understand your rule 2.  We agree that recover must be called 
> from a deferred function, so what is the caller of the caller of 
> calling recover? 
>
> You may want to review the files test/recover*.go in the Go sources. 
>
> Ian 
>

Thanks, Ian. 
The recover1.go has many great examples to understand the mechanism of 
panic/recover.
I think I have get it.
And I still think the spec doc is shallow.

-- 
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] don't understand the comment in spec Type assertions section

[digg]

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

var x interface{} = 7  // x has dynamic type int and value 7
i := x.(int)   // i has type int and value 7

type I interface { m() }
var y I
s := y.(string)// illegal: string does not implement I (missing 
method m)
r := y.(io.Reader) // r has type io.Reader and y must implement 
both I and io.Reader

I don't understand the comment of the last line. Can someone explain it 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] Re: go get: You are not currently on a branch

[Konstantin Khomoutov]

On Thu, 13 Oct 2016 04:36:27 -0700 (PDT)
Thomas Modeneis  wrote:

> > Does "NPM installs the target module" mean it's pulling and/or
> > updating 
> its sources to a VCS?
> 
> NPM decided that releases are part of a module. This module should be 
> release explicitly by the team/developer in charge for the module,
> and the module version is consequently bumped after.
> So developers that just want to use a module, do not have to worry
> where that project VCS is, if stills online or not, if exists or not.
> All this factors are mitigated and handled by NPM, due to its
> release/usage mechanism.

That's a strange point you're making here: NPM might not be online just
like the project's repo might be [1].

If we recall the recent left-pad debacle, it becames apparent that if
you really think about the future of your software and wants to make
its lifecycle not depend on the availablilty of external resources, you
have to vendor your dependencies.

So we again arrived at square one [2].

[...]
> In the other hand, Go decided (or the absence of a early stage design 
> decision caused this) that releases are linked to explicit commits,
> so VCS was added to equation to mitigate the problem

I think you're wrong on this: you put extra meaning into what `go get`
does.  `go get` is merely able to fetch code from several VCS systems
(and knows about the specific of several popular hosting solutions).
It explicitly knows nothing / does not care about which "version" of
the software it manages to download.

You're not at all oblidged to use `go get` (for instance, I, for one,
almost never touch it): instead, you're free to explicitly pick
whatever versions of the 3rd-party libraries you want, and do this in a
way you want it.  For instance, I personally use Git subtree merging to
vendor my dependencies, and hence I explicitly decide which versions I
merge (and hence depend on).

> + enabling people to use external projects into their Go modules...
> So several projects have been created to address the issue, like
> godeps, gm, glide. But (correct me if I'm wrong) there is no central
> repository for releases in Go ->
> http://stackoverflow.com/questions/38595887/does-golang-have-a-central-repository-for-the-downloaded-third-party-packages

Yes, there's no central package repository.
Personally, I have no opinion on this.
On the one hand, it might be convenient to have.  But that's only if
you're "infected" with an NMP-ish approach to working with packages.
The problem is that proponents of this approach implicitly assume
it's the best thing to have, but this is arguable (i.e. that would be
"one size fits all", and folks at Google explicitly abstrained from
instilling it on the community because they would not use this approach
anyway).

1. https://www.reddit.com/r/rust/comments/35kf6h/now_that_cratesio_is_down/
2. https://golang.org/doc/faq#get_version

-- 
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 get: You are not currently on a branch

[Konstantin Khomoutov]

On Thu, 13 Oct 2016 07:15:56 -0400
Tong Sun  wrote:

> > > You can blame git, but I think "go get" can do better to avoid the
> > problem in the first place.
> >
> > 'go get' just executes `git clone` or `git pull`. What would you
> > suggest 'go get' can do to "do better"?
> >
> 
> The problem occurs between two consequent 'go get' that may have a
> long time span. If
> 
>git checkout master
> 
> is suppose to fix the problem, then 'go get' should at least try to do
> that, I suppose.

No.

The branch named "master" is not somehow special for `git clone`.
After fetching all the data from the origin repository, it asks that
repository about where its HEAD ref points at.  If it points to a
branch, a local branch with its name is created -- pointing to the
commit of that branch.

Sure, in 90% (or more) of bare (that is, "central") Git repos found in
the wild, HEAD points at refs/heads/master, and that's why `git clone`
creates a local branch "master" for you pointing to the same commit
"origin/master" point at, but still the name "master" is not at all
special when cloning.  When someone told you to do `git checkout master`
it was actually a conscious oversimplification to avoid explaining the
stuff I have just explaining.

Changing the subject of this discussion a bit, I think that embedding
more magic into `go get` is wrong: there are legitimate cases where you
might have a repository fetched via `go get` in a special state (say,
you have implemented a local fix not yet upstreamed), and you're
supposed to track these things yourself -- tools can't really guess
what you _meant_ when you were working in that repository doing things
which put it into the state it's currently in.

-- 
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 get: You are not currently on a branch

[Jan Mercl]

On Thu, Oct 13, 2016 at 1:15 PM Tong Sun  wrote:

> The problem occurs between two consequent 'go get' that may have a long
time span. If
>
> git checkout master
>
> is suppose to fix the problem, then 'go get' should at least try to do
that, I suppose.

It fixes the problem provided no changes were made to the tree. But even if
there are no changes made to the tree in the detached head state, or it
being on a different branch than master, it would be strange if go get just
silently changed the current head state/current branch of a repository
someone intentionally put in such state. It's reasonable to suppose that
someone needs/wants to be on that branch/in that detached head state so
human intervention/supervision is justified, IMO.

-- 

-j

-- 
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 get: You are not currently on a branch

[Tong Sun]

On Thu, Oct 13, 2016 at 1:31 AM, Jan Mercl  wrote:

> On Thu, Oct 13, 2016 at 3:59 AM Tong Sun wrote:
>
> > You can blame git, but I think "go get" can do better to avoid the
> problem in the first place.
>
> 'go get' just executes `git clone` or `git pull`. What would you suggest
> 'go get' can do to "do better"?
>

The problem occurs between two consequent 'go get' that may have a long
time span. If

   git checkout master

is suppose to fix the problem, then 'go get' should at least try to do
that, I suppose.

-- 
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 get: You are not currently on a branch

[Jan Mercl]

On Thu, Oct 13, 2016 at 8:18 AM Thomas Modeneis 
wrote:

> I hate comparing Go with Node, but (I'm sorry)... How about doing the
same that NPM does ? NPM installs the target module + target version. End.

I'm not familiar with Node. Does "NPM installs the target module" mean it's
pulling and/or updating its sources to a VCS?

-- 

-j

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