[go-nuts] Re: max connections limit lib/pq

[Franco Marchesini]

Postgres default max connection is set to 100.

https://www.postgresql.org/docs/9.5/static/runtime-config-connection.html

max_connections (integer)

Determines the maximum number of concurrent connections to the database 
server. The default is typically 100 connections, but might be less if your 
kernel settings will not support it (as determined during initdb). This 
parameter can only be set at server start.

When running a standby server, you must set this parameter to the same or 
higher value than on the master server. Otherwise, queries will not be 
allowed in the standby server.



Il giorno venerdì 30 giugno 2017 20:40:36 UTC+2, Gerald Stan ha scritto:
>
> what you want is to set SetMaxOpenConns, SetMaxIdleConns:
>
> db, err := sql.Open(config.DriverName, GetDataSourceFromConfig(config))
> if err != nil {
> log.Fatal(err)
> }
>
> db.SetMaxOpenConns(config.MaxOpenConns)
> db.SetMaxIdleConns(config.MaxIdleConns)
>
>
> On Friday, June 30, 2017 at 10:22:11 AM UTC-4, Franco Marchesini wrote:
>>
>> If you really have over 100 simultaneous connection you need to configure 
>> postgresql engine
>> Regards
>> Franco
>>
>> Il giorno mercoledì 21 giugno 2017 14:56:14 UTC+2, Tieson Molly ha 
>> scritto:
>>>
>>> I am running into an issue I have seen mentioned on here years ago.  I 
>>> am seeking the current best solution.
>>>
>>> I have a web server connecting to a postgresql database using the 
>>> standard database/sql and the lib/pq driver.  I keep running out of 
>>> connections over time as it seems the pool grows up to 100.
>>>
>>> Is there a way to prevent or fix this?
>>>
>>> Best regards,
>>>
>>> Ty
>>>
>>>

-- 
You received this message because you are subscribed 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: gofmt question

[Michael Jones]

Find a way to use comments for your ""big space"

On Fri, Jun 30, 2017 at 8:12 PM  wrote:

> I have a few such bug bears, so, my trick is to 'fix' fmt's helpful
> services when I check a file out, and only run fmt automatically when the
> file is committed to the repository.
>
> This keeps my fugly habits out of the tidy fmt'ed space and at the same
> time, keeps fmt's attempts to tickle my OCD safely away from me :-)
>
> Think about this way:  because fmt enforces uniformity, you now have the
> chance to have your code shaped *exactly* they way you like it, without
> having to write too much formatting code to cover everyone's peculiarities.
>
>
> Siduri
>
>
>
> On Saturday, July 1, 2017 at 2:27:10 AM UTC+1, Glenn Hancock wrote:
>>
>> I am learning the go language and really liking it.  However, there are a
>> few things that drive me crazy and I wanted to list one in particular to
>> see if there is some way to change it.
>>
>> When I write a package that has 20 different functions in it I like to
>> add 4 or 5 blank lines between each function to make it easier to scroll
>> down through the code and easily see where one starts and ends.  Currently
>> gofmt removes all my extra lines and replaces them with a single space
>> which makes it difficult to easily see what I'm looking at.
>>
>> Is there some way to get it to not remove my extra lines?
>>
>> Thanks,
>>
>> Glenn
>>
> --
> You received this message because you are subscribed 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.
>
-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
You received this message because you are subscribed 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: runtime/malloc: out of memory when only 512GB / 4TB in use

[Dave Cheney]

https://github.com/golang/go/blob/master/src/runtime/malloc.go#L137

On Saturday, 1 July 2017 13:12:32 UTC+10, Jeremy Jay wrote:
>
> We've got a very high-memory (4TB) system available that I'm trying to 
> make full use of. Anyone have any
> pointers on how to track down this issue? Is it a system configuration 
> thing, a go malloc bug, or something else?
>
> Thanks!
>
> Snippet of the crash follows:
>
> fatal error: out of memory
> fatal error: out of memory
> runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
> use)
> fatal error: out of memory
> runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
> use)
> fatal error: out of memory
> runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
> use)
> fatal error: out of memory
> runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
> use)
> fatal error: out of memory
>
> runtime stack:
> runtime.throw(0x533f6c, 0xd)
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/panic.go:596 +0x95
> runtime.largeAlloc(0x24700, 0x44ac01, 0x1441fe22000)
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/malloc.go:797 +0x10f
> runtime.mallocgc.func1()
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/malloc.go:690 +0x3e
> runtime.systemstack(0xc42053bbe0)
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/asm_amd64.s:327 +0x79
> runtime.mstart()
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/proc.go:1132
>
> goroutine 849 [running]:
> runtime.systemstack_switch()
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/asm_amd64.s:281 
> fp=0xd278fd1a40 sp=0xd278fd1a38
> runtime.mallocgc(0x24700, 0x505720, 0xd278fd1b01, 0x40eff8)
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/malloc.go:691 +0x930 
> fp=0xd278fd1ae0 sp=0xd278fd1a40
> runtime.makeslice(0x505720, 0x48e0, 0x48e0, 0xda52757500, 0x0, 0x947)
> /projects/bisd/sw/packages/go/1.8.1/src/runtime/slice.go:54 +0x7b 
> fp=0xd278fd1b30 sp=0xd278fd1ae0
>

-- 
You received this message because you are subscribed 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] Explain the meaning of iota

[Shawn Milochik]

https://github.com/golang/go/wiki/Iota

-- 
You received this message because you are subscribed 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] Explain the meaning of iota

[Manohar Reddy]

`iota` is golnag's enum. I've seen this code in Wikipedia. But I did not 
understand it. Can someone please explain this code?

type ByteSize float64
const (
_   = iota // ignore first value by assigning to blank identifier
KB ByteSize = 1 << (10 * iota)
MB
GB)

-- 
You received this message because you are subscribed 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] No luck running 'go install' from within go program

[siduri . irudis]

Hi,

I made a bash script that sets up a small go project with the name(s)
of my choice that already has a useful basic shape to start with --
an internal package, tests and benchmarking. (I borrowed code from the
official set up video and from Daves's Fibonacci example)

I'm happy with the way the bash script works (and you might find it
useful too!) but, when I try to translate it into golang, so it's
portable and neater, it's not working very well.

I get to the stage where I write the first go code file to disk, and
then try to use os.cmd to run 'go install'

I tried a number of things --- and the GOPATH I set up on the fly
looks correct, so does the PATH I modify, but go install is on
permanent strike.

If I manually cd into the created directory, go install works just
fine.

Could someone please take a look at give me a hint as to where I'm
going wrong here?

My repository is here:

https://bitbucket.org/siduri-irudis/go-lazy-tools

The bash script is called small_go_project_builder.sh 


and the golang version is go_project.go 


I added a comment to the place where I'm stuck into the go version.

many thanks,

Siduri

-- 
You received this message because you are subscribed 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 test` does not honor -ldflags

[chioyi . tang]

Do you know where is this issue documented? I'm facing the same problem now 
and tried to find more information. Thanks!

On Tuesday, October 4, 2016 at 6:47:30 AM UTC-7, Art Mellor wrote:
>
> Perhaps documenting the behavior is the best quick fix. Not knowing how 
> 'main' gets altered - is it something that is predictable? If so, I don't 
> think it is too terrible to document that so you can alter your command 
> line appropriately. 
>
> I personally use the feature to pass in build numbers and version, etc. 
> but I (without knowing of this problem) had done it in a separate version 
> package. I imagine it would be common to use it the same way with the main 
> 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.

[go-nuts] Re: gofmt question

[siduri . irudis]

I have a few such bug bears, so, my trick is to 'fix' fmt's helpful 
services when I check a file out, and only run fmt automatically when the 
file is committed to the repository.

This keeps my fugly habits out of the tidy fmt'ed space and at the same 
time, keeps fmt's attempts to tickle my OCD safely away from me :-)

Think about this way:  because fmt enforces uniformity, you now have the 
chance to have your code shaped *exactly* they way you like it, without 
having to write too much formatting code to cover everyone's peculiarities.

Siduri


On Saturday, July 1, 2017 at 2:27:10 AM UTC+1, Glenn Hancock wrote:
>
> I am learning the go language and really liking it.  However, there are a 
> few things that drive me crazy and I wanted to list one in particular to 
> see if there is some way to change it.
>
> When I write a package that has 20 different functions in it I like to add 
> 4 or 5 blank lines between each function to make it easier to scroll down 
> through the code and easily see where one starts and ends.  Currently gofmt 
> removes all my extra lines and replaces them with a single space which 
> makes it difficult to easily see what I'm looking at.
>
> Is there some way to get it to not remove my extra lines?
>
> Thanks,
>
> Glenn
>

-- 
You received this message because you are subscribed 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] runtime/malloc: out of memory when only 512GB / 4TB in use

[Jeremy Jay]

We've got a very high-memory (4TB) system available that I'm trying to make 
full use of. Anyone have any
pointers on how to track down this issue? Is it a system configuration 
thing, a go malloc bug, or something else?

Thanks!

Snippet of the crash follows:

fatal error: out of memory
fatal error: out of memory
runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
use)
fatal error: out of memory
runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
use)
fatal error: out of memory
runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
use)
fatal error: out of memory
runtime: out of memory: cannot allocate 196608-byte block (549755682816 in 
use)
fatal error: out of memory

runtime stack:
runtime.throw(0x533f6c, 0xd)
/projects/bisd/sw/packages/go/1.8.1/src/runtime/panic.go:596 +0x95
runtime.largeAlloc(0x24700, 0x44ac01, 0x1441fe22000)
/projects/bisd/sw/packages/go/1.8.1/src/runtime/malloc.go:797 +0x10f
runtime.mallocgc.func1()
/projects/bisd/sw/packages/go/1.8.1/src/runtime/malloc.go:690 +0x3e
runtime.systemstack(0xc42053bbe0)
/projects/bisd/sw/packages/go/1.8.1/src/runtime/asm_amd64.s:327 +0x79
runtime.mstart()
/projects/bisd/sw/packages/go/1.8.1/src/runtime/proc.go:1132

goroutine 849 [running]:
runtime.systemstack_switch()
/projects/bisd/sw/packages/go/1.8.1/src/runtime/asm_amd64.s:281 
fp=0xd278fd1a40 sp=0xd278fd1a38
runtime.mallocgc(0x24700, 0x505720, 0xd278fd1b01, 0x40eff8)
/projects/bisd/sw/packages/go/1.8.1/src/runtime/malloc.go:691 +0x930 
fp=0xd278fd1ae0 sp=0xd278fd1a40
runtime.makeslice(0x505720, 0x48e0, 0x48e0, 0xda52757500, 0x0, 0x947)
/projects/bisd/sw/packages/go/1.8.1/src/runtime/slice.go:54 +0x7b 
fp=0xd278fd1b30 sp=0xd278fd1ae0

-- 
You received this message because you are subscribed 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] gofmt question

[Shawn Milochik]

https://go-proverbs.github.io

gofmt is our life now. 😎

It is not meant (or possible) to be everyone's favorite. 👍

-- 
You received this message because you are subscribed 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] gofmt question

[Glenn Hancock]

I am learning the go language and really liking it.  However, there are a 
few things that drive me crazy and I wanted to list one in particular to 
see if there is some way to change it.

When I write a package that has 20 different functions in it I like to add 
4 or 5 blank lines between each function to make it easier to scroll down 
through the code and easily see where one starts and ends.  Currently gofmt 
removes all my extra lines and replaces them with a single space which 
makes it difficult to easily see what I'm looking at.

Is there some way to get it to not remove my extra lines?

Thanks,

Glenn

-- 
You received this message because you are subscribed 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: max connections limit lib/pq

[gerald . stanje]

what you want is to set SetMaxOpenConns, SetMaxIdleConns:

db, err := sql.Open(config.DriverName, GetDataSourceFromConfig(config))
if err != nil {
log.Fatal(err)
}

db.SetMaxOpenConns(config.MaxOpenConns)
db.SetMaxIdleConns(config.MaxIdleConns)


On Friday, June 30, 2017 at 10:22:11 AM UTC-4, Franco Marchesini wrote:
>
> If you really have over 100 simultaneous connection you need to configure 
> postgresql engine
> Regards
> Franco
>
> Il giorno mercoledì 21 giugno 2017 14:56:14 UTC+2, Tieson Molly ha scritto:
>>
>> I am running into an issue I have seen mentioned on here years ago.  I am 
>> seeking the current best solution.
>>
>> I have a web server connecting to a postgresql database using the 
>> standard database/sql and the lib/pq driver.  I keep running out of 
>> connections over time as it seems the pool grows up to 100.
>>
>> Is there a way to prevent or fix this?
>>
>> Best regards,
>>
>> Ty
>>
>>

-- 
You received this message because you are subscribed 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] Perl die("") equivalent for Go?

[Steven Hartland]

log.Fatal() is what u want

On Fri, 30 Jun 2017 at 18:32, Andrew Pennebaker 
wrote:

> For command line applications, it's often useful to terminate with a
> one-line string message, without presenting a stack trace. Could Go get a
> die-like standard function for this?
>
> panic() and log.Panic() are similar to die, except that panic always shows
> a trace, even when a very newbie-facing application or other security
> concern would preclude full error traces.
>
> --
> You received this message because you are subscribed 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] Perl die("") equivalent for Go?

[Andrew Pennebaker]

For command line applications, it's often useful to terminate with a 
one-line string message, without presenting a stack trace. Could Go get a 
die-like standard function for this?

panic() and log.Panic() are similar to die, except that panic always shows 
a trace, even when a very newbie-facing application or other security 
concern would preclude full error traces.

-- 
You received this message because you are subscribed 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] gomacro v2.0 - Go interpreter with REPL, Eval and code-generating macros

[Max]

website: https://github.com/cosmos72/gomacro
install: go get github.com/cosmos72/gomacro

Fairly complete and interactive Go interpreter, implemented in pure Go, 
supporting:

   - all Go basic types, expressions, operators and builtins
   - all Go statements except goto
   - all Go declarations: import, type, const, var, func, including Go 1.9 
   type aliases
   - code generation with Lisp-like macros, quote and quasiquote
   
Main missing feature: cannot yet declare or implement interfaces.

Version 2.0 is a full reimplementation with greatly improved performance.

Not yet tested on Go 1.9 Beta 1.

Feedback welcome :)

Max

-- 
You received this message because you are subscribed 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: max connections limit lib/pq

[Franco Marchesini]

If you really have over 100 simultaneous connection you need to configure 
postgresql engine
Regards
Franco

Il giorno mercoledì 21 giugno 2017 14:56:14 UTC+2, Tieson Molly ha scritto:
>
> I am running into an issue I have seen mentioned on here years ago.  I am 
> seeking the current best solution.
>
> I have a web server connecting to a postgresql database using the standard 
> database/sql and the lib/pq driver.  I keep running out of connections over 
> time as it seems the pool grows up to 100.
>
> Is there a way to prevent or fix this?
>
> Best regards,
>
> Ty
>
>

-- 
You received this message because you are subscribed 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 rot13Reader example run twice?

[Franco Marchesini]

Now that I looked at the source, I learned.

// Reader is the interface that wraps the basic Read method.  //  // Read reads 
up to len(p) bytes into p. It returns the number of bytes  // read (0 <= n <= 
len(p)) and any error encountered. Even if Read  // returns n < len(p), it may 
use all of p as scratch space during the call.  // If some data is available 
but not len(p) bytes, Read conventionally  // returns what is available instead 
of waiting for more.  //  // When Read encounters an error or end-of-file 
condition after  // successfully reading n > 0 bytes, it returns the number of  
// bytes read. It may return the (non-nil) error from the same call  // or 
return the error (and n == 0) from a subsequent call.  // An instance of this 
general case is that a Reader returning  // a non-zero number of bytes at the 
end of the input stream may  // return either err == EOF or err == nil. The 
next Read should  // return 0, EOF.  //  // Callers should always process the n 
> 0 bytes returned before  // considering the error err. Doing so correctly 
handles I/O errors  // that happen after reading some bytes and also both of 
the  // allowed EOF behaviors.  //  // Implementations of Read are discouraged 
from returning a  // zero byte count with a nil error, except when len(p) == 0. 
 // Callers should treat a return of 0 and nil as indicating that  // nothing 
happened; in particular it does not indicate EOF.

Sorry for bother.
Thank you all.

Il giorno venerdì 30 giugno 2017 15:01:55 UTC+2, Jan Mercl ha scritto:
>
>
> On Fri, Jun 30, 2017 at 2:42 PM Franco Marchesini  > wrote:
>
> > Aside from the correction, however, I did not understand why the method 
> is called 2 times.
>
> HTH: https://play.golang.org/p/Na7GtgZ-_B
>
>
> -- 
>
> -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 rot13Reader example run twice?

[Jan Mercl]

On Fri, Jun 30, 2017 at 2:42 PM Franco Marchesini <
franco.marches...@gmail.com> wrote:

> Aside from the correction, however, I did not understand why the method
is called 2 times.

HTH: https://play.golang.org/p/Na7GtgZ-_B


-- 

-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 rot13Reader example run twice?

[Franco Marchesini]

Aside from the correction, however, I did not understand why the method is 
called 2 times.

Il giorno venerdì 30 giugno 2017 12:51:20 UTC+2, Franco Marchesini ha 
scritto:
>
> Yes, after Dave's answer I realized the mistake.
> This is a solution.
>
> Il giorno venerdì 30 giugno 2017 11:42:45 UTC+2, Sebastien Binet ha 
> scritto:
>>
>>
>>
>> On Fri, Jun 30, 2017 at 11:38 AM, Franco Marchesini <
>> franco.m...@gmail.com> wrote:
>>
>>> 1.
>>>
>>> Because with 2 there is a problem. The method is called twice and is 
>>> inefficient.
>>>
>>
>> what about checking your errors, then ? :)
>>  https://play.golang.org/p/K8j8D0AZe9
>>
>> -s
>>
>>
>>> Il giorno venerdì 30 giugno 2017 11:31:31 UTC+2, Jan Mercl ha scritto:

 On Fri, Jun 30, 2017 at 9:48 AM Franco Marchesini <
 franco.m...@gmail.com> wrote:

 > Why after the execution the k value is 2?

 What value of k do you expect instead and why? (
 https://play.golang.org/p/wdWo3fahAS)

 -- 

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

[go-nuts] Re: Go 1.9 Beta 2 is released

[Parker Evans]

It is certainly a micro-benchmark.  I just wanted to ask in case it was 
expected since I use golang on ARM based embedded systems a lot and they 
tend to be sensitive to binary size.  In the tests, my binary is stripped 
(-ldflags="-w -s"), so I wouldn't think the size difference is related to 
the changes that were made to add additional DWARF info, etc.  When I 
checked the cross compiled Linux ARM 7 sizes for the hello world program, 
they are also up in go1.9 beta.

go version go1.8.3 darwin/amd64


$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"

dozer2:test Parker$ ls -l

total 1824

-rw-r--r--  1 Parker  staff  79 Jun 16 18:47 main.go

-rwxr-xr-x  1 Parker  staff  928608 Jun 30 06:37 test

go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64

$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"

$ ls -l

total 2176

-rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go

-rwxr-xr-x  1 Parker  staff  1107256 Jun 30 06:36 test

Checking the hello world HTTP server program:

package main

import (

"net/http"

)

func main() {

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {

   w.Write([]byte("Hello world!"))

   })

   panic(http.ListenAndServe(":8080", nil))

}

The size is also up a bit from go1.8 -> go1.9 on both darwin amd64 and 
linux_arm (7), though a smaller percentage than the basic hello world.

go version go1.8.3 darwin/amd64

$ go build -ldflags="-w -s"

$ ls -l

total 8344

-rw-r--r--  1 Parker  staff  204 Jun 30 06:44 main.go

-rwxr-xr-x  1 Parker  staff  4264852 Jun 30 06:47 test

$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"

$ ls -l

total 6344

-rw-r--r--  1 Parker  staff  204 Jun 30 06:44 main.go

-rwxr-xr-x  1 Parker  staff  3242224 Jun 30 06:48 test

go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64

$ go build -ldflags="-w -s"

$ ls -l

total 8880

-rw-r--r--  1 Parker  staff  204 Jun 30 06:44 main.go

-rwxr-xr-x  1 Parker  staff  4538852 Jun 30 06:45 test

$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"

$ ls -l

total 6664

-rw-r--r--  1 Parker  staff  204 Jun 30 06:44 main.go

-rwxr-xr-x  1 Parker  staff  3405040 Jun 30 06:46 test

I can check it out for bigger/more realistic programs as well.

~Parker

On Thursday, June 29, 2017 at 8:21:18 AM UTC-4, Alberto Donizetti wrote:
>
> But if you have other numbers please share them, it'll certainly interesing
> to see them.
>
> Il giorno giovedì 29 giugno 2017 13:38:18 UTC+2, Parker Evans ha scritto:
>>
>> Congratulations on the Beta 2 release, pretty excited to test it out. 
>>  Lots of interesting updates!
>>
>> I did notice one thing when I was playing around with Beta 1 and now Beta 
>> 2 that I wanted to ask about.  Is it expected that binary size would 
>> increase in this release?  A toy example that has been somewhat of a 
>> benchmark in previous releases is the simple hello world program:
>>
>> package main
>>
>> import (
>>
>>   "fmt"
>>
>> )
>>
>>
>> func main() {
>>
>>fmt.Println("Hello world!")
>>
>> }
>>
>> It seems like this program, when compiled with options to strip debugging 
>> information has grown about 20% in size when compiled natively for macOS:
>>
>> go version go1.8.3 darwin/amd64
>>
>> $ go build -ldflags="-w -s"
>>
>> $ ls -l
>>
>> total 2320
>>
>> -rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go
>>
>> -rwxr-xr-x  1 Parker  staff  1181728 Jun 29 07:24 test
>>
>> go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64
>>
>> $ go build -ldflags="-w -s"
>>
>> $ ls -l
>>
>> total 2792
>>
>> -rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go
>>
>> -rwxr-xr-x  1 Parker  staff  1424992 Jun 29 07:11 test
>>
>> Anyone have any insight on whether this is expected and if a similar 
>> increase should be expected across the board in this release?
>>
>> Thanks,
>> Parker
>>
>> On Monday, June 26, 2017 at 6:11:46 PM UTC-4, Chris Broadfoot wrote:
>>>
>>> Hello gophers,
>>>
>>> We have just released go1.9beta2, a beta version of Go 1.9.
>>> It is cut from the master branch at the revision tagged go1.9beta2.
>>>
>>> There are no known problems or regressions.
>>> Please try running production load tests and your unit tests with the 
>>> new version.
>>> Your help testing these pre-release versions is invaluable.
>>>
>>> Report any problems using the issue tracker:
>>> https://golang.org/issue/new
>>>
>>> If you have Go installed already, the easiest way to try go1.9beta2
>>> is by using this tool:
>>> https://godoc.org/golang.org/x/build/version/go1.9beta2
>>>
>>> You can download binary and source distributions from the usual place:
>>> https://golang.org/dl/#go1.9beta2
>>>
>>> To find out what has changed in Go 1.9, read the draft release notes:
>>> https://tip.golang.org/doc/go1.9
>>>
>>> Documentation for Go 1.9 is available at:
>>> https://tip.golang.org/
>>>
>>> Cheers,
>>> Chris
>>>
>>

-- 
You received this message beca

Re: [go-nuts] why rot13Reader example run twice?

[Franco Marchesini]

Yes, after Dave's answer I realized the mistake.
This is a solution.

Il giorno venerdì 30 giugno 2017 11:42:45 UTC+2, Sebastien Binet ha scritto:
>
>
>
> On Fri, Jun 30, 2017 at 11:38 AM, Franco Marchesini  > wrote:
>
>> 1.
>>
>> Because with 2 there is a problem. The method is called twice and is 
>> inefficient.
>>
>
> what about checking your errors, then ? :)
>  https://play.golang.org/p/K8j8D0AZe9
>
> -s
>
>
>> Il giorno venerdì 30 giugno 2017 11:31:31 UTC+2, Jan Mercl ha scritto:
>>>
>>> On Fri, Jun 30, 2017 at 9:48 AM Franco Marchesini  
>>> wrote:
>>>
>>> > Why after the execution the k value is 2?
>>>
>>> What value of k do you expect instead and why? (
>>> https://play.golang.org/p/wdWo3fahAS)
>>>
>>> -- 
>>>
>>> -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] A question about race conditions

[Peter Waller]

Can you provide example code which demonstrates the problem? What you are
describing is not expected.

Reading and writing to channels simultaneously with the `<-` operator from
multiple goroutines should not generate memory race conditions by
themselves, but concurrency is complicated and it is still possible to
misuse memory if you're not careful.

My best guess from what you described was that you might be assigning to a
channel variable rather than writing a value into it? This is not a
concurrency-safe operation.

-- 
You received this message because you are subscribed 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] A question about race conditions

[fusi . enrico . maria]

Hello All

I have a question about the use of race condition detector. (compiling with 
-race options, to be precise).

I have a program which has a channel (size 1024): one goroutine is reading 
and one is writing. 

When I compile using -race , the detector says there is a race condition on 
the channel, because it is being written previously.

I am a bit surprised because my understanding was channels were 
"decoupling" the write and the read operation: so you can keep writing
and another goroutine reading asynchronously. 

This output gave me the impression a goroutine should not write while 
another is reading, or something similar.

Is it correct? At which extent?

thank you in advance

FEM.


-- 
You received this message because you are subscribed 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 rot13Reader example run twice?

[Sebastien Binet]

On Fri, Jun 30, 2017 at 11:38 AM, Franco Marchesini <
franco.marches...@gmail.com> wrote:

> 1.
>
> Because with 2 there is a problem. The method is called twice and is
> inefficient.
>

what about checking your errors, then ? :)
 https://play.golang.org/p/K8j8D0AZe9

-s


> Il giorno venerdì 30 giugno 2017 11:31:31 UTC+2, Jan Mercl ha scritto:
>>
>> On Fri, Jun 30, 2017 at 9:48 AM Franco Marchesini 
>> wrote:
>>
>> > Why after the execution the k value is 2?
>>
>> What value of k do you expect instead and why? (
>> https://play.golang.org/p/wdWo3fahAS)
>>
>> --
>>
>> -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] why rot13Reader example run twice?

[Franco Marchesini]

1.

Because with 2 there is a problem. The method is called twice and is 
inefficient.

Il giorno venerdì 30 giugno 2017 11:31:31 UTC+2, Jan Mercl ha scritto:
>
> On Fri, Jun 30, 2017 at 9:48 AM Franco Marchesini  > wrote:
>
> > Why after the execution the k value is 2?
>
> What value of k do you expect instead and why? (
> https://play.golang.org/p/wdWo3fahAS)
>
> -- 
>
> -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: why rot13Reader example run twice?

[Franco Marchesini]

Anyway thank you for the answer.
I know whats the problem.
This is an example of "cargo cult programming"
This is where I read the solutions.

https://gist.github.com/zyxar/2317744

-- 
You received this message because you are subscribed 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 rot13Reader example run twice?

[Jan Mercl]

On Fri, Jun 30, 2017 at 9:48 AM Franco Marchesini <
franco.marches...@gmail.com> wrote:

> Why after the execution the k value is 2?

What value of k do you expect instead and why? (
https://play.golang.org/p/wdWo3fahAS)

-- 

-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: why rot13Reader example run twice?

[Franco Marchesini]

Sorry but the method work twice.
try this:
}

func (rot *rot13Reader) Read(p []byte) (n int, err error) {
k++
n, err = rot.r.Read(p)
for i := 0; i < len(p); i++ {
if (p[i] >= 'A' && p[i] < 'N') || (p[i] >= 'a' && p[i] < 'n') {
p[i] += 13
} else if (p[i] > 'M' && p[i] <= 'Z') || (p[i] > 'm' && p[i] <= 
'z') {
p[i] -= 13
}
}
fmt.Println("\n", k, string(p))
return
}



Il giorno venerdì 30 giugno 2017 10:24:22 UTC+2, Dave Cheney ha scritto:
>
> Oh, sorry, I know. It'll be because the first time through your reader 
> returns , nil, and on the second time returns 0, io.EOF. So Read is called 
> twice, but on the second time does no work.

-- 
You received this message because you are subscribed 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] why rot13Reader example run twice?

[Dave Cheney]

Oh, sorry, I know. It'll be because the first time through your reader returns 
, nil, and on the second time returns 0, io.EOF. So Read is called twice, but 
on the second time does no work.

-- 
You received this message because you are subscribed 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] why rot13Reader example run twice?

[Dave Cheney]

Print out the size of p each time Read is called

-- 
You received this message because you are subscribed 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] why rot13Reader example run twice?

[Franco Marchesini]

Hello,
why the method Read of rot13Reader run twice?
This is the code:

package main

import (
"fmt"
"io"
"os"
"strings"
)

type rot13Reader struct {
r io.Reader
}

var k int

func (rot *rot13Reader) Read(p []byte) (n int, err error) {
k++
n, err = rot.r.Read(p)
for i := 0; i < len(p); i++ {
if (p[i] >= 'A' && p[i] < 'N') || (p[i] >= 'a' && p[i] < 'n') {
p[i] += 13
} else if (p[i] > 'M' && p[i] <= 'Z') || (p[i] > 'm' && p[i] <= 
'z') {
p[i] -= 13
}
}
return
}

func main() {
s := strings.NewReader("Lbh penpxrq gur pbqr!")
r := rot13Reader{s}
io.Copy(os.Stdout, &r)
fmt.Println("\n", k)
}


Why after the execution the k value is 2?

T.i.a
Franco

-- 
You received this message because you are subscribed 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: database/sql: Latency when calling DB.QueryContext()

[Kai Zhang]

In my private sql driver implementation, I need to do some clean up during 
conn.Close().
That clean up may block the DB.Query() for a second. That lead to the 
latency.
Now I fix this problem by making conn.Close() do clean up asynchronously, 
so the conn.Close() can return fast.

Doing clean up synchronously during DB.Query() call, makes an assumption 
that the conn.Close() is fast.
And  Go sql driver developers need to be awared of this requirement.

-- 
You received this message because you are subscribed 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: database/sql: Latency when calling DB.QueryContext()

[Kai Zhang]

Benchmark is not fair to this problem, it is the mean latency value.

This time  I wrote a simple test, and just log the time elapsed. 

Here is the code:
package main

import (
"database/sql"
"fmt"
"os"
"time"

_ "github.com/go-sql-driver/mysql"
)

var db *sql.DB

func RunNoMaxLifetime() {
db.SetConnMaxLifetime(0)

var v string
for i := 0; i < 10; i++ {
tBegin := time.Now()
db.QueryRow("select 1").Scan(&v)
fmt.Printf("max_lifetime=0, elapsed=%v\n", time.Since(tBegin))
time.Sleep(time.Second)
}
}

func RunMaxLifetime1S() {
db.SetConnMaxLifetime(time.Duration(1 * time.Second))

var v string
for i := 0; i < 10; i++ {
tBegin := time.Now()
db.QueryRow("select 1").Scan(&v)
fmt.Printf("max_lifetime=1s, elapsed=%v\n", time.Since(tBegin))
time.Sleep(time.Second)
}
}

func main() {
var err error
if db, err = sql.Open("mysql", "test:test@tcp(127.0.0.1:3306)/test"); err 
!= nil {
fmt.Fprintf(os.Stderr, "sql.Open(): %v", err)
os.Exit(1)
}

RunNoMaxLifetime()
RunMaxLifetime1S()
}


here is the output:
max_lifetime=0, elapsed=328.687µs
max_lifetime=0, elapsed=336.997µs
max_lifetime=0, elapsed=224.982µs
max_lifetime=0, elapsed=343.504µs
max_lifetime=0, elapsed=447.579µs
max_lifetime=0, elapsed=330.273µs
max_lifetime=0, elapsed=332.782µs
max_lifetime=0, elapsed=277.991µs
max_lifetime=0, elapsed=391.225µs
max_lifetime=0, elapsed=373.826µs
max_lifetime=1s, elapsed=1.438923ms
max_lifetime=1s, elapsed=1.553653ms
max_lifetime=1s, elapsed=1.497325ms
max_lifetime=1s, elapsed=1.572134ms
max_lifetime=1s, elapsed=1.582973ms
max_lifetime=1s, elapsed=1.393672ms
max_lifetime=1s, elapsed=1.321443ms
max_lifetime=1s, elapsed=1.090508ms
max_lifetime=1s, elapsed=875.897µs
max_lifetime=1s, elapsed=1.685481ms



-- 
You received this message because you are subscribed 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.