[go-nuts] Notable Go 1.8 XML decoder bug fix

[James Pettyjohn]

I switched to go 1.8 today and found that some of my XML parsing was 
failing where it was passing in 1.6/1.7.

After a bit of searching I found that there was a bug that was *fixed* in 
1.8 and my faulty data was previously being ignored. Specifically empty 
attributes which mapped to non-nilable int types.

This was not mentioned in the release notes so I had trouble finding it, 
but did eventually find it was well documented in the issues preceding it 
the release:

https://github.com/golang/go/issues/16158 
https://go-review.googlesource.com/#/c/27455/


-- 
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: Organizing a lot of implementations for single interface

[Henry]

Alternatively, you can leave them where they are and focus on the future so 
that future implementation of the interface doesn't add to more garbage. It may 
be possible to use fewer data types with configurable behavior.

-- 
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] Panic when highly concurrent MySQL queries

[Dave Cheney]

Can you share that code, it looks like you haven't checked the error from the 
previous call.

-- 
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 parse script expression with go and run the script

[Jason E. Aten]

Hello Hui,

I would invite you try my scripting language, zygomys. It is 100% Go. It 
offers both (lisp) and {infix} syntax.

https://github.com/glycerine/zygomys

- Jason

On Wednesday, February 15, 2017 at 12:48:32 AM UTC-6, hui zhang wrote:
>
>  I am developing a game engine 
> I wish some event could be trigger by script. and this script expression 
> is self-defined.
> Like below 
> trigger.ini 
> 
> trigger = "power >= 1000"
> trigger = "statetype == A || statetype == B "
> trigger = "foo() > 1"
> -
> *power* and *statetype* are a struct variable (it also can be defined as 
> global) in go.
> *foo* are a struct method (it also can be defined as global) 
>
>
> how can I parse the expression like "power >= 1000"
> and execute it in go.
>
> I notice there is a  go/parse package ,  but I am not sure how to use it .
>
>

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

[go-nuts] Go 1.8 is released

[Chris Broadfoot]

Hello gophers,

We just released Go 1.8.

You can read the announcement blog post here:
  https://blog.golang.org/go1.8

You can download binary and source distributions from our download page:
  https://golang.org/dl/

To compile from source using a Git checkout, update to the release with 
"git checkout go1.8" and build as usual.

To find out what has changed, read the release notes:
  https://golang.org/doc/go1.8

Thanks to everyone who contributed to the release.

Chris

-- 
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: weak hash for (MongoDb like) data server

[Ian Lance Taylor]

On Wed, Feb 15, 2017 at 9:42 PM, Basile Starynkevitch
 wrote:
>
> On Wednesday, February 15, 2017 at 9:01:58 PM UTC+1, Tamás Gulácsi wrote:
>
>>
>> Why do you need this?
>> You want the GC do the housekeeping for you, but I'm sure you won't be
>> happy with the result, as the GC's policy differs from what you await...
>
>
> What make you believe I won't be happy with the GC's policy. I'm quite open
> on that. My understanding is that the GC's policy is what I want.
>>
>>
>> What kind of eviction policy would you want?
>> Storing the data in an append-only file (or LevelDB), the deleted items in
>> SQLite, evicting regularly and on close?
>
>
> Persistence to disk will only happen explicitly at shutdown (process exit)
> time. So the file aspect don't matter much for my Q1.
>
> So my Q1 is basically: how can I make a weak hash table (in the sense I have
> described, of having an association from strong keys -pairs of uint64- to
> weak pointers to items).

Hi Basile.

Go does not support any sort of weak pointer.  You've already
identified one approach using finalizers.  That approach will work
today as Go's garbage collector never moves items.  There are no
current plans to ever move items, but it is possible that some Go
implementation will do so, in which case hiding the pointer as a
uintptr will break.  (By the way, Go's garbage collector is precise,
so there is no need to invert the bits in the uintptr or anything like
that--simply storing a pointer value in a uintptr is enough to hide it
from the garbage collector.)

Other than that, I think you will have to implement garbage collection
yourself.  That doesn't sound too hard with your data structure, which
doesn't seem to have cycles.  Basically traverse the data structure
copying data from the current map to a new one, then replace the
official map with the new one.  With judicious locking this could even
be done concurrently.

Sorry I don't have anything else to suggest.

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 get an element from []interface{} `arr[0] == nil` is not true?

[Dragos Harabor]

I understand that, I was just curious to see if there was another way to do 
it besides reflection.

On Thursday, February 16, 2017 at 12:03:43 PM UTC-8, Axel Wagner wrote:
>
> The question is: Why would you want to know? nil-pointers are perfectly 
> fine implementations of an interface. By caring whether the value 
> implementing your interface is a nil-pointer, you are breaking the 
> abstraction of your interface.
>
> On Thu, Feb 16, 2017 at 8:37 PM, Dragos Harabor  > wrote:
>
>> Actually it doesn't do what I asked, sorry if I was not clear, I was 
>> expecting your example to print "true true", got excited too quickly.
>>
>> https://play.golang.org/p/WnDyT9OOpr
>>
>>
>> On Thursday, February 16, 2017 at 11:32:59 AM UTC-8, Dragos Harabor wrote:
>>>
>>> Nice, thank you!
>>>
>>> On Thursday, February 16, 2017 at 11:25:31 AM UTC-8, Jan Mercl wrote:

 On Thu, Feb 16, 2017 at 8:20 PM Dragos Harabor  
 wrote:

 > Is there any way to check whether the value stored in a non-nil 
 interface is nil when you don't know the type, short of using 
 reflect.Value.IsNil()?

 For example: https://play.golang.org/p/Sdqx7Frjxj

 -- 

 -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...@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 get an element from []interface{} `arr[0] == nil` is not true?

['Axel Wagner' via golang-nuts]

The question is: Why would you want to know? nil-pointers are perfectly
fine implementations of an interface. By caring whether the value
implementing your interface is a nil-pointer, you are breaking the
abstraction of your interface.

On Thu, Feb 16, 2017 at 8:37 PM, Dragos Harabor  wrote:

> Actually it doesn't do what I asked, sorry if I was not clear, I was
> expecting your example to print "true true", got excited too quickly.
>
> https://play.golang.org/p/WnDyT9OOpr
>
>
> On Thursday, February 16, 2017 at 11:32:59 AM UTC-8, Dragos Harabor wrote:
>>
>> Nice, thank you!
>>
>> On Thursday, February 16, 2017 at 11:25:31 AM UTC-8, Jan Mercl wrote:
>>>
>>> On Thu, Feb 16, 2017 at 8:20 PM Dragos Harabor 
>>> wrote:
>>>
>>> > Is there any way to check whether the value stored in a non-nil
>>> interface is nil when you don't know the type, short of using
>>> reflect.Value.IsNil()?
>>>
>>> For example: https://play.golang.org/p/Sdqx7Frjxj
>>>
>>> --
>>>
>>> -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.
>

-- 
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] "defer f.Close()" - error return ignored?

[Jakob Borg]

Deferred close on the input file is fine, no need for closure shenanigans. On 
the output file, you'll get cleaner code here by not using defer at all.

outputFile, err := os.Create(outputFileName)
if err != nil {
return err
}
_, err = io.Copy(outputFile, inputFile)
if err != nil {
outputFile.Close() // don't care about the error
return err
}
return outputFile.Close()

> On 16 Feb 2017, at 19:57, Константин Изюмов  wrote:
> 
> In my point of view - let`s try that:
> 
> ---
> // Copy - copy files
> func Copy(inputFileName, outputFileName string) (err error) {
> 
>   if len(inputFileName) == 0 {
>   return fmt.Errorf("inputFileName is zero: %s", inputFileName)
>   }
> 
>   if len(outputFileName) == 0 {
>   return fmt.Errorf("inputFileName is zero: %s", outputFileName)
>   }
> 
>   inputFile, err := os.Open(inputFileName)
>   if err != nil {
>   return err
>   }
>   defer func() {
>   errFile := inputFile.Close()
>   if errFile != nil {
>   if err != nil {
>   err = fmt.Errorf("%v ; %v", err, errFile)
>   } else {
>   err = errFile
>   }
>   }
>   }()
> 
>   outputFile, err := os.Create(outputFileName)
>   if err != nil {
>   return err
>   }
>   defer func() {
>   errFile := outputFile.Close()
>   if errFile != nil {
>   if err != nil {
>   err = fmt.Errorf("%v ; %v", err, errFile)
>   } else {
>   err = errFile
>   }
>   }
>   }()
> 
>   _, err = io.Copy(outputFile, inputFile)
>   if err != nil {
>   return err
>   }
> 
>   return nil
> }
> ---
> 
> 
> 
>> On Thursday, 17 November 2011 01:41:09 UTC+3, Ian Lance Taylor wrote:
>> Dave Cheney  writes:
>> > On 17/11/2011, at 6:49, Igor Nazarenko  wrote:
>> >
>> >> In many places in the documentation I see the "defer f.Close()" idiom
>> >> used to close files. However, looking at the godoc for os.Close, it
>> >> actually returns an error. What happens to the error return when the
>> >> Close() call is deferred?
>> 
>> > It is discarded.
>> 
>> So it is probably not a good idea to use this idiom for a file open for
>> writing.  But it is fine in practice to do this with a file open only
>> for reading.  There is nothing interesting to be done for an error when
>> closing a file open for reading.
>> 
>> 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.

-- 
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 get an element from []interface{} `arr[0] == nil` is not true?

[Dragos Harabor]

Actually it doesn't do what I asked, sorry if I was not clear, I was 
expecting your example to print "true true", got excited too quickly.

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


On Thursday, February 16, 2017 at 11:32:59 AM UTC-8, Dragos Harabor wrote:
>
> Nice, thank you!
>
> On Thursday, February 16, 2017 at 11:25:31 AM UTC-8, Jan Mercl wrote:
>>
>> On Thu, Feb 16, 2017 at 8:20 PM Dragos Harabor  wrote:
>>
>> > Is there any way to check whether the value stored in a non-nil 
>> interface is nil when you don't know the type, short of using 
>> reflect.Value.IsNil()?
>>
>> For example: https://play.golang.org/p/Sdqx7Frjxj
>>
>> -- 
>>
>> -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] Why get an element from []interface{} `arr[0] == nil` is not true?

[Dragos Harabor]

Nice, thank you!

On Thursday, February 16, 2017 at 11:25:31 AM UTC-8, Jan Mercl wrote:
>
> On Thu, Feb 16, 2017 at 8:20 PM Dragos Harabor  > wrote:
>
> > Is there any way to check whether the value stored in a non-nil 
> interface is nil when you don't know the type, short of using 
> reflect.Value.IsNil()?
>
> For example: https://play.golang.org/p/Sdqx7Frjxj
>
> -- 
>
> -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] Why get an element from []interface{} `arr[0] == nil` is not true?

[Jan Mercl]

On Thu, Feb 16, 2017 at 8:20 PM Dragos Harabor  wrote:

> Is there any way to check whether the value stored in a non-nil interface
is nil when you don't know the type, short of using reflect.Value.IsNil()?

For example: https://play.golang.org/p/Sdqx7Frjxj

-- 

-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] Why get an element from []interface{} `arr[0] == nil` is not true?

[Dragos Harabor]

Is there any way to check whether the value stored in a non-nil interface 
is nil when you don't know the type, short of using reflect.Value.IsNil()?

Thanks.

On Wednesday, February 15, 2017 at 10:11:55 AM UTC-8, rog wrote:
>
> In addition to what others have said, note that the 
> comparison works as you expected if you use a typed nil: 
>
> https://play.golang.org/p/jA57mTKbxa 
>
>
> On 15 February 2017 at 08:40, Felix Sun  
> wrote: 
> > https://play.golang.org/p/qYA8Ddnnye 
> > 
> > ``` 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > ) 
> > 
> > type Obj struct { 
> > One *Obj 
> > } 
> > 
> > func main() { 
> > var o = {} 
> > 
> > var arr = []interface{}{o.One} 
> > 
> > fmt.Println(arr[0]) 
> > fmt.Println("why this is not true?", arr[0] == nil) 
> > } 
> > 
> > 
> > ``` 
> > 
> > 
> > Why `arr[0] == nil` is not true? 
> > 
> > -- 
> > 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] Puzzle for golang guru.

[DV]

Very subtle fix:
https://play.golang.org/p/xTEGpgIyP6

-- 
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] Puzzle for golang guru.

[DV]

Very subtle fix:
https://play.golang.org/p/xTEGpgIyP6

-- 
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] "defer f.Close()" - error return ignored?

[Константин Изюмов]

In my point of view - let`s try that:

---
// Copy - copy files
func Copy(inputFileName, outputFileName string) (err error) {

if len(inputFileName) == 0 {
return fmt.Errorf("inputFileName is zero: %s", inputFileName)
}

if len(outputFileName) == 0 {
return fmt.Errorf("inputFileName is zero: %s", outputFileName)
}

inputFile, err := os.Open(inputFileName)
if err != nil {
return err
}
* defer func() {*
* errFile := inputFile.Close()*
* if errFile != nil {*
* if err != nil {*
* err = fmt.Errorf("%v ; %v", err, errFile)*
* } else {*
* err = errFile*
* }*
* }*
* }()*

outputFile, err := os.Create(outputFileName)
if err != nil {
return err
}
* defer func() {*
* errFile := outputFile.Close()*
* if errFile != nil {*
* if err != nil {*
* err = fmt.Errorf("%v ; %v", err, errFile)*
* } else {*
* err = errFile*
* }*
* }*
* }()*

_, err = io.Copy(outputFile, inputFile)
if err != nil {
return err
}

return nil
}
---



On Thursday, 17 November 2011 01:41:09 UTC+3, Ian Lance Taylor wrote:
>
> Dave Cheney  writes:
>
> > On 17/11/2011, at 6:49, Igor Nazarenko  > wrote:
> >
> >> In many places in the documentation I see the "defer f.Close()" idiom
> >> used to close files. However, looking at the godoc for os.Close, it
> >> actually returns an error. What happens to the error return when the
> >> Close() call is deferred?
>
> > It is discarded. 
>
> So it is probably not a good idea to use this idiom for a file open for
> writing.  But it is fine in practice to do this with a file open only
> for reading.  There is nothing interesting to be done for an error when
> closing a file open for reading.
>
> 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] [ANN] Gobot 1.2 has been released

[Ron Evans]

Hi, everyone

We just released Gobot (https://gobot.io) version 1.2 today, to coincide 
with the release party for Golang 1,8.

Blog post here: https://gobot.io/blog/2017/02/16/gobot-1.2-released/

Thank you to everyone who contributed to this release!

-- 
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] Panic when highly concurrent MySQL queries

[lee]

Ah thanks I had not seen this and replacing it with a non prepared version 
and some manual sql statement generation fixed the problem.

Thank you!

On Thursday, February 16, 2017 at 6:22:27 PM UTC, Justin Israel wrote:
>
>
>
> On Fri, Feb 17, 2017, 6:48 AM  wrote:
>
>> I have a channel that receives a lot of data that needs to be stored into 
>> MySQL.
>>
>> After a short period of time I get the following...
>>
>> Error 1461: Can't create more than max_prepared_stmt_count statements 
>> (current value: 16382)
>> panic: runtime error: invalid memory address or nil pointer dereference
>> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13f7168]
>>
>> goroutine 61348 [running]:
>> database/sql.(*Stmt).Close(0x0, 0x0, 0x0)
>> /usr/local/go/src/database/sql/sql.go:2022 +0x38
>>
>> I notice a few really old bugs that have been closed off but not sure why 
>> this is happening.
>>
>> I am running Go1.8rc3
>>
>
> What does your usage pattern look like in code? 
>
> http://go-database-sql.org/prepared.html
>
> "Because statements will be re-prepared as needed when their original 
> connection is busy, it’s possible for high-concurrency usage of the 
> database, which may keep a lot of connections busy, to create a large 
> number of prepared statements. This can result in apparent leaks of 
> statements, statements being prepared and re-prepared more often than you 
> think, and even running into server-side limits on the number of 
> statements."
>
> Justin 
>
>
> -- 
>> 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] Panic when highly concurrent MySQL queries

[Justin Israel]

On Fri, Feb 17, 2017, 6:48 AM  wrote:

> I have a channel that receives a lot of data that needs to be stored into
> MySQL.
>
> After a short period of time I get the following...
>
> Error 1461: Can't create more than max_prepared_stmt_count statements
> (current value: 16382)
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13f7168]
>
> goroutine 61348 [running]:
> database/sql.(*Stmt).Close(0x0, 0x0, 0x0)
> /usr/local/go/src/database/sql/sql.go:2022 +0x38
>
> I notice a few really old bugs that have been closed off but not sure why
> this is happening.
>
> I am running Go1.8rc3
>

What does your usage pattern look like in code?

http://go-database-sql.org/prepared.html

"Because statements will be re-prepared as needed when their original
connection is busy, it’s possible for high-concurrency usage of the
database, which may keep a lot of connections busy, to create a large
number of prepared statements. This can result in apparent leaks of
statements, statements being prepared and re-prepared more often than you
think, and even running into server-side limits on the number of
statements."

Justin


-- 
> 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: Go 1.7.5 and Go 1.8rc3 are released

[Jason E. Aten]

On Thursday, February 16, 2017 at 9:50:22 AM UTC-6, Jason E. Aten wrote:
>
> Hi Chris, will go1.8 be released today?
>

I see the answer is yes. Woot!

 
https://github.com/golang/go/releases/tag/go1.8?utm_source=golangweekly_medium=email

-- 
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] Panic when highly concurrent MySQL queries

[lee]

I have a channel that receives a lot of data that needs to be stored into 
MySQL.

After a short period of time I get the following...

Error 1461: Can't create more than max_prepared_stmt_count statements 
(current value: 16382)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13f7168]

goroutine 61348 [running]:
database/sql.(*Stmt).Close(0x0, 0x0, 0x0)
/usr/local/go/src/database/sql/sql.go:2022 +0x38

I notice a few really old bugs that have been closed off but not sure why 
this is happening.

I am running Go1.8rc3

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

Re: [go-nuts] how can i build a golang system library of debug version

[Ian Lance Taylor]

On Wed, Feb 15, 2017 at 11:29 PM, Wen Hailong <7234...@gmail.com> wrote:
> i want to debug golang system library. can step code one by one

Go programs are built with debugging info by default.  You need to
take special action to avoid the debugging info.

But note https://golang.org/doc/gdb .  You may also want to try
https://github.com/derekparker/delve .

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] Place of the Pointer type inside unsafe.package

[Ian Lance Taylor]

On Thu, Feb 16, 2017 at 8:50 AM,   wrote:
> Le jeudi 16 février 2017 17:46:15 UTC+1, Axel Wagner a écrit :
>>
>> The unsafe package is pretty much virtual. The compiler is aware of it and
>> implements the operations defined by the spec to be in it.
>
> Is it the same for C.call() in the case of the C package ?

No.  The C package is implemented by the cgo tool
(https://golang.org/cmd/cgo), which rewrites the Go source code to use
generated names rather than explicit references to the C package.

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] Place of the Pointer type inside unsafe.package

[lael . cellier]

Le jeudi 16 février 2017 17:46:15 UTC+1, Axel Wagner a écrit :
>
> The unsafe package is pretty much virtual. The compiler is aware of it and 
> implements the operations defined by the spec 
>  to be in it.
>
Is it the same for C.call() in the case of the C package ?

-- 
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] Place of the Pointer type inside unsafe.package

['Axel Wagner' via golang-nuts]

The unsafe package is pretty much virtual. The compiler is aware of it and
implements the operations defined by the spec
 to be in it.

On Thu, Feb 16, 2017 at 6:54 AM,  wrote:

> Hello,
>
> I'm trying to redeclare the Pointer type
> I found unsafe/unsafe.go inside compiler source where the Pointer type is
> declared like this :
> type ArbitraryType int
> type Pointer *ArbitraryType.
> but obviously, this isn’t the declaration which used with Pointer() inside
> normal programs :
> package main
>
> type ArbitraryType int
> type Pointer *ArbitraryType
>
> func main() {
> f := *(*func() int)(Pointer(uintptr(0)))
> f()
> }
>
> main.go:7: cannot convert Pointer(uintptr(0)) (type Pointer) to type *func() 
> int
>
>
> So where is the Pointer type declared ?
>
> --
> 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: Organizing a lot of implementations for single interface

[Luca Looz]

It's a scraper and i'm already planning to drastically reduce 
implementations by grouping them into common ones that can be configured 
but i will not be able to do it for all of them

Il giorno giovedì 16 febbraio 2017 17:14:34 UTC+1, Henry ha scritto:
>
> It's difficult to recommend any specific refactoring strategy without 
> seeing the actual codes. However, judging from your description where you 
> have hundreds of implementation for a single interface, it just feels wrong 
> and I am certain there is a way to simplify your codes. Instead of looking 
> to organize your codes, you should try to simplify them. 

-- 
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: Organizing a lot of implementations for single interface

[Henry]

It's difficult to recommend any specific refactoring strategy without seeing 
the actual codes. However, judging from your description where you have 
hundreds of implementation for a single interface, it just feels wrong and I am 
certain there is a way to simplify your codes. Instead of looking to organize 
your codes, you should try to simplify them. 

-- 
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: Puzzle for golang guru.

[Volker Dobler]

https://golang.org/doc/faq#nil_error

Am Donnerstag, 16. Februar 2017 16:58:18 UTC+1 schrieb dreyk:
>
> What do you expect as output of following code?
>
> package main
>
> import "fmt"
>
> type MyInterface interface {
>GetName() string
> }
> type MyInterfaceImpl struct {
>Name string
> }
> func (i *MyInterfaceImpl) GetName() string {
>return i.Name
> }
> func getNilMyInterface() MyInterface {
>return nil
> }
> func getNilMyInterfaceImpl() *MyInterfaceImpl {
>return nil
> }
> func main() {
>v := getNilMyInterface()
>if v == nil {
>   if v = getNilMyInterfaceImpl(); v == nil {
>  fmt.Println("Ok. This code is correct!")
>   } else {
>  fmt.Println("Opsss... It's not nil")
>  fmt.Println(v.GetName())
>   }
>}
> }
>
>
> Check yourself  https://play.golang.org/p/PDbyjP7QcS
>
>

-- 
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] Puzzle for golang guru.

[Rob Pike]

https://golang.org/doc/faq#nil_error

On Thu, Feb 16, 2017 at 12:38 AM, dreyk  wrote:

> What do you expect as output of following code?
>
> package main
>
> import "fmt"
>
> type MyInterface interface {
>GetName() string
> }
> type MyInterfaceImpl struct {
>Name string
> }
> func (i *MyInterfaceImpl) GetName() string {
>return i.Name
> }
> func getNilMyInterface() MyInterface {
>return nil
> }
> func getNilMyInterfaceImpl() *MyInterfaceImpl {
>return nil
> }
> func main() {
>v := getNilMyInterface()
>if v == nil {
>   if v = getNilMyInterfaceImpl(); v == nil {
>  fmt.Println("Ok. This code is correct!")
>   } else {
>  fmt.Println("Opsss... It's not nil")
>  fmt.Println(v.GetName())
>   }
>}
> }
>
>
> Check yourself  https://play.golang.org/p/PDbyjP7QcS
>
> --
> 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: Orm Golang

[dwicahya . sulistyawan]

On Thursday, February 16, 2017 at 12:02:30 PM UTC+7, I Ketut Gunawan wrote:
>
> Hi is there any suggestion of using orm in golang with lock feature update 
> record ? 
>
>
> Thanks for help 
>

   Yang bisa dipergunakan :
https://github.com/jinzhu/gorm
 

-- 
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] Field substitution in nested templates

[brydavis . mpa]

Still works as of Go 1.7

On Thursday, May 28, 2015 at 11:57:18 AM UTC-7, rog...@lommers.org wrote:
>
> Thanks; this fixed my problem!
>
> On Sunday, 29 April 2012 03:30:18 UTC+2, David Symonds wrote:
>>
>> You need to declare the data to use for the template invocation. You 
>> probably want 
>>   {{template "header" .}} 
>>
>>
>> Dave. 
>>
>

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

[go-nuts] Puzzle for golang guru.

[dreyk]

What do you expect as output of following code?

package main

import "fmt"

type MyInterface interface {
   GetName() string
}
type MyInterfaceImpl struct {
   Name string
}
func (i *MyInterfaceImpl) GetName() string {
   return i.Name
}
func getNilMyInterface() MyInterface {
   return nil
}
func getNilMyInterfaceImpl() *MyInterfaceImpl {
   return nil
}
func main() {
   v := getNilMyInterface()
   if v == nil {
  if v = getNilMyInterfaceImpl(); v == nil {
 fmt.Println("Ok. This code is correct!")
  } else {
 fmt.Println("Opsss... It's not nil")
 fmt.Println(v.GetName())
  }
   }
}


Check yourself  https://play.golang.org/p/PDbyjP7QcS

-- 
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 1.7.5 and Go 1.8rc3 are released

[Jason E. Aten]

Hi Chris, will go1.8 be released today?

-- 
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: Organizing a lot of implementations for single interface

[Luca Looz]

Can you be more specific?

Il giorno giovedì 16 febbraio 2017 14:36:19 UTC+1, Henry ha scritto:
>
> It seems like you could use some serious refactoring there, rather than 
> merely organizing your files.

-- 
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] Organizing a lot of implementations for single interface

[Henry]

It seems like you could use some serious refactoring there, rather than merely 
organizing your files.

-- 
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: [ANN] Java Object Signing and Encryption (JOSE) for golang

[dvsekhvalnov]

Hi all,

Want to make announcement on fixing possible security vulnerability in 
jose2go library. Invalid Curve Attack on NIST curves.

So if you by chance using the library and dealing with ECDH key management, 
strongly advised to upgrade to latest (v1.3).

-- 
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: Windows Message Loop is getting blocked and resumed intermittently

[martseniuk]

Oh! Sorry about the wrong link. 
However dont ignore 2 errors from ole.GetMessage & ole.DispatchMessage

On Thursday, February 16, 2017 at 1:45:18 PM UTC+3, fe f wrote:
>
>
> https://github.com/go-ole/go-ole/blob/master/com.go#L308
>
> I used this function. 
>
> 2017년 2월 16일 목요일 오후 1시 30분 11초 UTC+9, marts...@gmail.com 님의 말:
>>
>> check ole.GeMessage error.
>>
>> btw. https://github.com/go-ole/go-ole/blob/master/com_func.go#L163
>>
>

-- 
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: empty nested template definitions not working as expected

[Manlio Perillo]

Il giorno mercoledì 15 febbraio 2017 19:36:40 UTC+1, mhh...@gmail.com ha 
scritto:
>
> Hi,
>
> see this play,
> https://play.golang.org/p/s-GdewdWz_
>
> In my understanding, 
> as the template is empty, 
> it is not added to the templates tree, 
> i suspect it has something to do with that,
> https://golang.org/src/text/template/parse/parse.go?#L243
>
>
Thanks. So this seems to be a feature.  What is the rationale?  As far as I 
know this is not documented.
 

> Maybe a non breakable space like  will do the trick ?
>
>
Currently I'm using an empty span.

> [...]


Manlio

-- 
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: Windows Message Loop is getting blocked and resumed intermittently

[fe f]

https://github.com/go-ole/go-ole/blob/master/com.go#L308

I used this function. 

2017년 2월 16일 목요일 오후 1시 30분 11초 UTC+9, marts...@gmail.com 님의 말:
>
> check ole.GeMessage error.
>
> btw. https://github.com/go-ole/go-ole/blob/master/com_func.go#L163
>

-- 
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] will GC close unused connection ?

[caspian46]

Thanks! I'm going to read it carefully.

在 2017年2月16日星期四 UTC+8下午4:40:54，Konstantin Khomoutov写道：
>
> On Thu, 16 Feb 2017 00:29:04 -0800 (PST) 
> casp...@gmail.com  wrote: 
>
> > > > Will GC close unused connection ? 
> > > 
> > > No. At least not directly. A finalizer can possibly do that and 
> > > finalizers are possibly invoked by the GC. 
> [...] 
> > Means yes, GC will close unused connection, just indirectly? 
> > Cause I found this: 
> > #/opt/go/src/net/fd_unix.go 
> > func (fd *netFD) setAddr(laddr, raddr Addr) { 
> > fd.laddr = laddr 
> > fd.raddr = raddr 
> > runtime.SetFinalizer(fd, (*netFD).Close) 
> > } 
> > 
> > And this function is called by netFD.dial in sock_posix.go:148 
>
> It means "the runtime _may_ eventually close the connection after the 
> Go's value wrapping it was garbage-collected, but this is not 
> guaranteed to happend, and quite likely it will not happen". 
>
> Please read this recent thread [1] dealing with finalizers. 
>
> 1. https://groups.google.com/d/topic/golang-nuts/d8aF4rAob7U/discussion 
>

-- 
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] will GC close unused connection ?

[caspian46]

Many thanks!
Yes, I know that it is wrong to keep connection without call Close func. 
just when I working on a bug, I found the connection was closed 
automatically somehow.


在 2017年2月16日星期四 UTC+8下午4:33:54，Axel Wagner写道：
>
> Yes, in general, the GC will usually close connections when the 
> corresponding files are collected. But a) you can't really rely on that and 
> b) the number of file descriptors that a program can open is very limited 
> and for many programs, the rate at which they are opened is high enough, 
> that they will pass that threshold, because the GC doesn't collect them 
> quickly enough.
>
> Given how limited file descriptors are, you thus should still take care to 
> actually close all files you open yourself.
>
> On Thu, Feb 16, 2017 at 9:29 AM,  wrote:
>
>> Thanks for you reply!
>> Means yes, GC will close unused connection, just indirectly?  Cause I 
>> found this:
>> #/opt/go/src/net/fd_unix.go
>> func (fd *netFD) setAddr(laddr, raddr Addr) {
>> fd.laddr = laddr
>> fd.raddr = raddr
>> runtime.SetFinalizer(fd, (*netFD).Close)
>> }
>>
>> And this function is called by netFD.dial in sock_posix.go:148
>>
>>
>> 在 2017年2月16日星期四 UTC+8下午3:31:07，Jan Mercl写道：
>>>
>>> On Thu, Feb 16, 2017 at 8:20 AM  wrote:
>>>
>>> > Will GC close unused connection ?
>>>
>>> No. At least not directly. A finalizer can possibly do that and 
>>> finalizers are possibly invoked by the GC.
>>>
>>> -- 
>>>
>>> -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...@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 executable cross-compiled for arm5 works on amd64 (and arm5)

[Dan Kortschak]

Thank you. Yes, I had forgotten I'd installed that (needed for kernel
building for the very same arm5 device).

Dan

On Thu, 2017-02-16 at 21:31 +1300, Michael Hudson-Doyle wrote:
> Do you have qemu-user-static or a similarly named package installed?
> Then
> the magic of binfmt_misc may be invoking it. For me:
> 
> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> enabled
> interpreter /usr/bin/qemu-arm-static
> flags: OC
> offset 0
> magic 7f454c460101010002002800
> mask ff00feff
> 
> Cheers,
> mwh

-- 
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] will GC close unused connection ?

[Konstantin Khomoutov]

On Thu, 16 Feb 2017 00:29:04 -0800 (PST)
caspia...@gmail.com wrote:

> > > Will GC close unused connection ?
> >
> > No. At least not directly. A finalizer can possibly do that and
> > finalizers are possibly invoked by the GC.
[...]
> Means yes, GC will close unused connection, just indirectly?
> Cause I found this:
> #/opt/go/src/net/fd_unix.go
> func (fd *netFD) setAddr(laddr, raddr Addr) {
> fd.laddr = laddr
> fd.raddr = raddr
> runtime.SetFinalizer(fd, (*netFD).Close)
> }
> 
> And this function is called by netFD.dial in sock_posix.go:148

It means "the runtime _may_ eventually close the connection after the
Go's value wrapping it was garbage-collected, but this is not
guaranteed to happend, and quite likely it will not happen".

Please read this recent thread [1] dealing with finalizers.

1. https://groups.google.com/d/topic/golang-nuts/d8aF4rAob7U/discussion

-- 
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] will GC close unused connection ?

['Axel Wagner' via golang-nuts]

Yes, in general, the GC will usually close connections when the
corresponding files are collected. But a) you can't really rely on that and
b) the number of file descriptors that a program can open is very limited
and for many programs, the rate at which they are opened is high enough,
that they will pass that threshold, because the GC doesn't collect them
quickly enough.

Given how limited file descriptors are, you thus should still take care to
actually close all files you open yourself.

On Thu, Feb 16, 2017 at 9:29 AM,  wrote:

> Thanks for you reply!
> Means yes, GC will close unused connection, just indirectly?  Cause I
> found this:
> #/opt/go/src/net/fd_unix.go
> func (fd *netFD) setAddr(laddr, raddr Addr) {
> fd.laddr = laddr
> fd.raddr = raddr
> runtime.SetFinalizer(fd, (*netFD).Close)
> }
>
> And this function is called by netFD.dial in sock_posix.go:148
>
>
> 在 2017年2月16日星期四 UTC+8下午3:31:07，Jan Mercl写道：
>>
>> On Thu, Feb 16, 2017 at 8:20 AM  wrote:
>>
>> > Will GC close unused connection ?
>>
>> No. At least not directly. A finalizer can possibly do that and
>> finalizers are possibly invoked by the GC.
>>
>> --
>>
>> -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.
>

-- 
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 executable cross-compiled for arm5 works on amd64 (and arm5)

[Michael Hudson-Doyle]

Do you have qemu-user-static or a similarly named package installed? Then
the magic of binfmt_misc may be invoking it. For me:

$ cat /proc/sys/fs/binfmt_misc/qemu-arm
enabled
interpreter /usr/bin/qemu-arm-static
flags: OC
offset 0
magic 7f454c460101010002002800
mask ff00feff

Cheers,
mwh

On 16 February 2017 at 20:37, Dan Kortschak 
wrote:

> Can someone explain to me why this works? I am cross-compiling for
> arm5, but the executable works on amd64.
>
> $ cat hello.go
> package main
>
> import "fmt"
>
> func main() {
> fmt.Println("hello")
> }
> $ GOARCH=arm GOARM=5 go build hello.go
> $ ./hello
> hello
> $ go env
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/daniel"
> GORACE=""
> GOROOT="/home/daniel/go"
> GOTOOLDIR="/home/daniel/go/pkg/tool/linux_amd64"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-
> map=/tmp/go-build014006335=/tmp/go-build -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
> $ go version
> go version go1.7.4 linux/amd64
>
>
> The executable also works on the arm5 device. I'm not worried, but I
> don't understand how this works.
>
> --
> 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] will GC close unused connection ?

[caspian46]

Thanks for you reply!
Means yes, GC will close unused connection, just indirectly?  Cause I found 
this:
#/opt/go/src/net/fd_unix.go
func (fd *netFD) setAddr(laddr, raddr Addr) {
fd.laddr = laddr
fd.raddr = raddr
runtime.SetFinalizer(fd, (*netFD).Close)
}

And this function is called by netFD.dial in sock_posix.go:148


在 2017年2月16日星期四 UTC+8下午3:31:07，Jan Mercl写道：
>
> On Thu, Feb 16, 2017 at 8:20 AM  wrote:
>
> > Will GC close unused connection ?
>
> No. At least not directly. A finalizer can possibly do that and finalizers 
> are possibly invoked by the GC.
>
> -- 
>
> -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.

[go-nuts] Re: Compressing 2.5 GB data trims files

[Mukund 8kmiles]

Hey all,

Thanks, the io.copy resolved the issue.

Thanks & Regards
Mukund



On Thu, Feb 16, 2017 at 2:51 AM, Dave Cheney  wrote:

> Or use https://godoc.org/io/ioutil#ReadFile
>
> By really you don't need to buffer all the data in memory, io.Copy will do
> that for you
>
> in, err := os.Open(input)
> check(err)
> defer in.Close()
> out, err := os.Create(output)
> gz := gzip.New.Writer(out)
> _, err = io.Copy(gz, in)
> check(err)
> err = gz.Close()
> check(err)
> err = out.Close()
> check(err)
>
>
> On Thursday, 16 February 2017 06:05:51 UTC+11, howar...@gmail.com wrote:
>>
>> While it is not clear from the Buffer documentation, the Reader
>> *interface* documentation (which Buffer.Read implements implicitly) does
>> state "up to len(p) bytes." You are ignoring how many bytes it read and
>> assuming that the one read is reading the whole file. I am not sure that
>> this is guaranteed with Buffer.Read.
>>
>> I would suggest you try to adhere to the Reader interface's documented
>> behavior, and continue to call Read until you get EOF, and process the n
>> returned bytes each time. Doing this would also make it easier to then move
>> a step further and drop your buffer size to something sensible, instead of
>> attempting to read the entire 2.5G file into memory before compressing.
>>
>> Howard
>>
>

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