Re: [go-nuts] Go vs C speed - What am I doing wrong?

2019-02-11 Thread 'Isaac Gouy' via golang-nuts
On Saturday, February 9, 2019 at 9:30:25 AM UTC-8, Isaac Gouy wrote:

> On Tuesday, February 5, 2019 at 3:03:42 AM UTC-8, ohir wrote:
>
>>
>> > Contributors can recreate the same benchmarking routines in C, golang, 
>> JS 
>>
>> This is how "benchmark game" **entertaining** sites are architectured. 
>> Their 
>> "comparisons" are moot for the industry. Look at the history of java 
>> samples 
>> and benchmark earlier vs current at same task. 
>>
>
> *"Look at the history of java samples and benchmark earlier vs current at 
> same task"* and conclude what?
>

> Robert Engels wrote:The point is that when you leverage a runtime, you 
often get performance improvements as the runtime improves with no work on 
your end. Java has seen 1000x performance improvements in many areas as 
compared to version 1 - mostly due to the JIT.  

Ummm yeah, until language implementations are abandoned, people will try to 
make improvements — 
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/yarv-mri.html

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Parsing date with Timezone doesn't return UTC

2019-02-11 Thread stejcz
Hi all, please could you help me with a simple problem?

I have some parsing code like this: https://play.golang.org/p/6bVyWg4FCVN

It writes

20190211T103847+

2019-02-11 10:38:47 + *UTC*


on the server.

When I put the code into test, 

package tcx_test

import (
"fmt"
"testing"
"time"
)

func TestTemp(t *testing.T) {
date := "20190211T103847-"
parsed, err := time.Parse("20060102T150405-0700", date)
fmt.Println(date)
fmt.Println(err)
fmt.Println(parsed)
}

it outputs

>go test
20190211T103847-

2019-02-11 10:38:47 + *+*
PASS
ok  tc/tcx 0.048s

Why there is UTC in the first output, but + in the second one?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Mismatched types work sometimes?

2019-02-11 Thread Jamie Caldwell
Thanks for the help and quick response Tyler.

On Mon, 11 Feb 2019 at 17:56, Tyler Compton  wrote:

> Constant expressions like 'A' or 3 or named constants like "const x = 7"
> are what Go calls "untyped constants". The type of these constants are
> determined by the context in which they're used. For example:
>
> const myConst = 3
> myFloat := 2.5
> fmt.Println(myFloat + myConst)
> fmt.Println(myFloat + 3)
>
> Both of the above cases work because myConst and the literal 3 are untyped
> constants that take on the type float64 automatically.
>
> You can also declare typed constants, which no longer have these type
> inference properties.
>
> const myConst int = 3
> myFloat := 2.5
> fmt.Println(myFloat + myConst)  // No longer works
>
> If you're curious about the details, I would check out the section of the
> language spec on this: https://golang.org/ref/spec#Constants
>
> On Mon, Feb 11, 2019 at 9:37 AM Jamie Caldwell <
> mr.jamie.caldw...@gmail.com> wrote:
>
>> Hello,
>>
>> Can you help?
>>
>> https://play.golang.org/p/XfJZ3h06p60
>>
>> Why does 'A' work, when first assigning it to a variable doesn't?
>>
>> Thank you,
>> Jamie.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and 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 vs C speed - What am I doing wrong?

2019-02-11 Thread 'Isaac Gouy' via golang-nuts


On Saturday, February 9, 2019 at 9:20:41 AM UTC-8, Isaac Gouy wrote:
>
>
> On Sunday, February 3, 2019 at 10:44:11 AM UTC-8, Milind Thombre wrote:
>>
>> … a quantitative performance study/Benchmarking study … If a verifiable 
>> (unbiased) study is already done and published, I'd greatly appreciate it 
>> if someone can post the link. 
>>
>
> What do you not find acceptable about what Google finds?
>


> Nothing, so far. But I feel Independent studies are necessary to confirm 
or refute claims.


"If you're interested in something not shown on the benchmarks game website 
then please take the program source code and the measurement scripts 

 
and publish your own measurements."

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Handling connection retries on a highly-available service

2019-02-11 Thread Tamás Gulácsi
If this process is mission-critical, I'd turn it around, have it log to stdout, 
push that stdout to files with svlogd (from runit) and move that to the log 
server.

The reason is that if this process has to implement the log retrying logic, 
that is a priority inversion. It's better to buffer the log and let another 
process ship it - decouple it from the main program.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Parsing date with Timezone doesn't return UTC

2019-02-11 Thread Ian Lance Taylor
On Mon, Feb 11, 2019 at 10:53 AM  wrote:
>
> Hi all, please could you help me with a simple problem?
>
> I have some parsing code like this: https://play.golang.org/p/6bVyWg4FCVN
>
> It writes
>
> 20190211T103847+
> 
> 2019-02-11 10:38:47 + UTC
>
>
> on the server.
>
> When I put the code into test,
>
> package tcx_test
>
> import (
> "fmt"
> "testing"
> "time"
> )
>
> func TestTemp(t *testing.T) {
> date := "20190211T103847-"
> parsed, err := time.Parse("20060102T150405-0700", date)
> fmt.Println(date)
> fmt.Println(err)
> fmt.Println(parsed)
> }
>
> it outputs
>
> >go test
> 20190211T103847-
> 
> 2019-02-11 10:38:47 + +
> PASS
> ok  tc/tcx 0.048s
>
> Why there is UTC in the first output, but + in the second one?

It depends on the timezone information available on the system and on
the system's local time zone.  If the system's local time zone is UTC,
that will be used.  Otherwise, the time will use an unnamed timezone
at offset +.  That winds up with the difference that you see.  See
the docs for time.Parse:

When parsing a time with a zone offset like -0700, if the offset
corresponds to a time zone used by the current location (Local), then
Parse uses that location and zone in the returned time. Otherwise it
records the time as being in a fabricated location with time fixed at
the given zone offset.

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] Mismatched types work sometimes?

2019-02-11 Thread Jamie Caldwell
Hello,

Can you help?

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

Why does 'A' work, when first assigning it to a variable doesn't?

Thank you,
Jamie.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Mismatched types work sometimes?

2019-02-11 Thread Tyler Compton
Constant expressions like 'A' or 3 or named constants like "const x = 7"
are what Go calls "untyped constants". The type of these constants are
determined by the context in which they're used. For example:

const myConst = 3
myFloat := 2.5
fmt.Println(myFloat + myConst)
fmt.Println(myFloat + 3)

Both of the above cases work because myConst and the literal 3 are untyped
constants that take on the type float64 automatically.

You can also declare typed constants, which no longer have these type
inference properties.

const myConst int = 3
myFloat := 2.5
fmt.Println(myFloat + myConst)  // No longer works

If you're curious about the details, I would check out the section of the
language spec on this: https://golang.org/ref/spec#Constants

On Mon, Feb 11, 2019 at 9:37 AM Jamie Caldwell 
wrote:

> Hello,
>
> Can you help?
>
> https://play.golang.org/p/XfJZ3h06p60
>
> Why does 'A' work, when first assigning it to a variable doesn't?
>
> Thank you,
> Jamie.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] Job Posting from a multinational company in Silicon Valley

2019-02-11 Thread lynnzhou999
We are seeking Staff engineer to lead Cloud Native Application initiative. 
We are taking our strength and leadership in compute and virtualization and 
extending it from a VM-centric focus to managing app-centric, containerized 
workloads using Kubernetes, Docker, and other emerging container 
technologies. 

 

Job requirements:

· Extensive experience of building a large scale distributed system

· Have experience in agile software development techniques, test 
driven development and innovative SDLC methodologies

· Familiarity with storage management domain

· Experience contributing to open source projects

· Hands on experience with container technologies (Docker and 
Kubernetes)

· Deep understanding of system architecture, including processors, 
storage, and networking

· Proficiency and experience with virtualization and application 
virtualization technologies in a data center environment

· Experience in delivering SaaS solutions and Cloud based services

· Experience with Continuous Integration and Continuous Development 
processes

· Solid Linux background

· Proficient in Golang, familiar with C++ and Python programming 
languages

· Excellent communication skills and team player

· Strong interpersonal and problem-solving skills

· PhD or Master degree in Computer Science from a reputable 
university

 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] ZXBasic string slicing

2019-02-11 Thread Dan Kortschak
https://play.golang.org/p/6GqrX15gXZ7

On Mon, 2019-02-11 at 13:04 -0800, Everton Marques wrote:
> Funny feature from ZXBasic:
> 
> There is a notation called slicing for describing substrings, and
> this can 
> be applied to arbitrary string expressions.
> 
> `"abcdef"(2 TO 5)="bcde"`
> 
> http://www.worldofspectrum.org/ZXBasicManual/zxmanchap8.html
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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.12 Release Candidate 1 is released

2019-02-11 Thread Andrew Bonventre
Hello gophers,

We have just released go1.12rc1, a release candidate version of Go 1.12.
It is cut from release-branch.go1.12 at the revision tagged go1.12rc1.

Please try your production load tests and 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.12rc1
is by using the go command:
$ go get golang.org/dl/go1.12rc1
$ go1.12rc1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.12rc1

To find out what has changed in Go 1.12, read the draft release notes:
https://tip.golang.org/doc/go1.12

Cheers,
The Go Team

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Mismatched types work sometimes?

2019-02-11 Thread Rob Pike
You might find blog.golang.org/constants helpful.

-rob


On Tue, Feb 12, 2019 at 5:04 AM Jamie Caldwell 
wrote:

> Thanks for the help and quick response Tyler.
>
> On Mon, 11 Feb 2019 at 17:56, Tyler Compton  wrote:
>
>> Constant expressions like 'A' or 3 or named constants like "const x = 7"
>> are what Go calls "untyped constants". The type of these constants are
>> determined by the context in which they're used. For example:
>>
>> const myConst = 3
>> myFloat := 2.5
>> fmt.Println(myFloat + myConst)
>> fmt.Println(myFloat + 3)
>>
>> Both of the above cases work because myConst and the literal 3 are
>> untyped constants that take on the type float64 automatically.
>>
>> You can also declare typed constants, which no longer have these type
>> inference properties.
>>
>> const myConst int = 3
>> myFloat := 2.5
>> fmt.Println(myFloat + myConst)  // No longer works
>>
>> If you're curious about the details, I would check out the section of the
>> language spec on this: https://golang.org/ref/spec#Constants
>>
>> On Mon, Feb 11, 2019 at 9:37 AM Jamie Caldwell <
>> mr.jamie.caldw...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Can you help?
>>>
>>> https://play.golang.org/p/XfJZ3h06p60
>>>
>>> Why does 'A' work, when first assigning it to a variable doesn't?
>>>
>>> Thank you,
>>> Jamie.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


[go-nuts] ZXBasic string slicing

2019-02-11 Thread Everton Marques
Funny feature from ZXBasic:

There is a notation called slicing for describing substrings, and this can 
be applied to arbitrary string expressions.

`"abcdef"(2 TO 5)="bcde"`

http://www.worldofspectrum.org/ZXBasicManual/zxmanchap8.html


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Mismatched types work sometimes?

2019-02-11 Thread Jamie Caldwell
Cheers Rob, I'll certainly read that.

On Mon, 11 Feb 2019 at 20:53, Rob Pike  wrote:

> You might find blog.golang.org/constants helpful.
>
> -rob
>
>
> On Tue, Feb 12, 2019 at 5:04 AM Jamie Caldwell <
> mr.jamie.caldw...@gmail.com> wrote:
>
>> Thanks for the help and quick response Tyler.
>>
>> On Mon, 11 Feb 2019 at 17:56, Tyler Compton  wrote:
>>
>>> Constant expressions like 'A' or 3 or named constants like "const x = 7"
>>> are what Go calls "untyped constants". The type of these constants are
>>> determined by the context in which they're used. For example:
>>>
>>> const myConst = 3
>>> myFloat := 2.5
>>> fmt.Println(myFloat + myConst)
>>> fmt.Println(myFloat + 3)
>>>
>>> Both of the above cases work because myConst and the literal 3 are
>>> untyped constants that take on the type float64 automatically.
>>>
>>> You can also declare typed constants, which no longer have these type
>>> inference properties.
>>>
>>> const myConst int = 3
>>> myFloat := 2.5
>>> fmt.Println(myFloat + myConst)  // No longer works
>>>
>>> If you're curious about the details, I would check out the section of
>>> the language spec on this: https://golang.org/ref/spec#Constants
>>>
>>> On Mon, Feb 11, 2019 at 9:37 AM Jamie Caldwell <
>>> mr.jamie.caldw...@gmail.com> wrote:
>>>
 Hello,

 Can you help?

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

 Why does 'A' work, when first assigning it to a variable doesn't?

 Thank you,
 Jamie.

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

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

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


Re: [go-nuts] Re: Go vs C speed - What am I doing wrong?

2019-02-11 Thread 'Isaac Gouy' via golang-nuts


> On Monday, February 11, 2019, 10:59:20 AM PST, Robert Engels  wrote: 
>
> Please don’t base any decisions on the benchmark games. They are seriously 
> flawed. 
>


Someone could write "They are seriously flawed." without ever having looked 
to see :-) 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] TLS Trusted Certificate Authority (TCA) Extension Support

2019-02-11 Thread dan
Bare with me on this, as I explain where I'm coming from and where I'm 
trying to go.

We've integrated Go into our code base as a separate service that 
communicates with some server code through TLS. For the most part, this 
worked flawlessly through Go 1.10. We were affected by some of the Go 1.11 
changes that deprecated  the 
use of the common name as a non-host name.

x509: Common Name is not a valid hostname: ...
>

As a result, we've been restricted to 1.10 although we've made some steps 
to try to get up to the most recent level.

Recently, we decided to migrate our Go service's certificate to a new, 
standardized certificate that will be accepted by Go 1.11's TLS certificate 
validation that removes the deprecated use of the CN. This certificate is 
generated by our server code.

We've hit a snag in terms of creating a migration path for our customers on 
existing server instances. As some context, the migration path is not quite 
simple as we are likely to have our legacy self-signed certificate deployed 
to hundreds if not thousand of non-Go clients. So although we have a new 
certificate, it's a difficult play to ask our customers to migrate to a new 
self-signed certificate without pulling teeth.

One idea on the table is to utilize an extension from the TLS RFC 6066 
standard detailed here  and 
basically allow the server to manage multiple certificates. That would 
allow our old clients to continue using legacy certificates and also 
provide a migration path for new Go clients. Is that implemented in Go or 
are there any plans to? Are there any alternatives you can think of given 
the scenario above?

We're trying to _avoid_ writing any custom validation logic on the Go 
client as encouraged here 
. We 
could also possibly use SNI although it seems like we'd be overloading the 
use of this field.

Thanks!

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


[go-nuts] Golang closures, counter-intuitive behaviour

2019-02-11 Thread Slawomir Pryczek
Hi Guys,

When looking at this code below, you can see that the function will get 
LAST value of i which is incremented inside the loop, but t is somehow 
copied and taken inside a function so closure is created and it is bound to 
current value of t, so we'll have its current value in function. This is 
strange as t and i is defined on the same code block level (t will be 
discarded at the same time as i, after the loop).

I always thought that t would need to be passed explicitly to goroutine to 
retain current value (which i did). But why assigning value in a loop is 
treated differently in this regard than a straight assignment? Any URL 
where such "special cases" are documented? Isn't it kind of design flaw, 
because this seem very confusing that loop is creating single value and 
simple assignment is creating multiple copies? Maybe you consider changing 
this in go2?

https://play.golang.org/p/6vx_qDOk51g

10 1
10 0
10 9
10 8
10 7
10 6
10 5
10 4
10 3
10 2


Thanks,
Slawomir.


-
package main
import (
"fmt"
"time"
)

func main() {
for i := 0; i < 10; i++ {
t := i
go func() {
time.Sleep(time.Millisecond * 100)
fmt.Println(i, t)
}()
}
time.Sleep(time.Millisecond * 1000)
}



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


Re: [go-nuts] Golang closures, counter-intuitive behaviour

2019-02-11 Thread Ian Lance Taylor
On Mon, Feb 11, 2019 at 4:48 PM Slawomir Pryczek  wrote:
>
> When looking at this code below, you can see that the function will get LAST 
> value of i which is incremented inside the loop, but t is somehow copied and 
> taken inside a function so closure is created and it is bound to current 
> value of t, so we'll have its current value in function. This is strange as t 
> and i is defined on the same code block level (t will be discarded at the 
> same time as i, after the loop).
>
> I always thought that t would need to be passed explicitly to goroutine to 
> retain current value (which i did). But why assigning value in a loop is 
> treated differently in this regard than a straight assignment? Any URL where 
> such "special cases" are documented? Isn't it kind of design flaw, because 
> this seem very confusing that loop is creating single value and simple 
> assignment is creating multiple copies? Maybe you consider changing this in 
> go2?

A nested function that refers to a variable outside the closure is
always using a reference to that variable, never a copy.  So the only
question here is about the handling of variables in a loop.  The rule
is simply that a new variable is created at each variable declaration.
In the loop, there is one variable declaration of i when the loop
starts: i := 0.  The other references to i, including all the uses of
i within the loop, all refer to that single variable.  But the
declaration "t := i" is declared each time through the loop, so each
separate iteration of the loop has a different variable t.

So there is no special case here, and this is working as intended.
Hope this helps.

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] GAE import of cloud and appengine data stores fails when in same file

2019-02-11 Thread Dan Kortschak
One of our developers has found that when they import both
"google.golang.org/appengine/datastore" and
"cloud.google.com/go/datastore", renaming the second import
to remoteds, the build on AE fails, though it does not fail locally
with dev_appserver.py.

This only happens when the imports are in the same file; if they are in
separate files of the same package, everything is OK.

Does anyone else have experience of this or understand why two packages
imported under separate names would be rejected by GAE?

thanks
Dan

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 vs C speed - What am I doing wrong?

2019-02-11 Thread Henry
Micro optimization is only a small part of the picture. While you can shave 
off a few ms with micro optimization, you can save much more with macro 
optimization. Macro optimization deals with algorithm, program design, 
caching, etc. This is why some people consider language vs language 
micro-benchmark to be *irrelevant*, because it plays only a very minor 
part. My colleague is a Haskell guru. Despite Haskell being cast as slow 
and inefficient in various micro benchmarks, his real-world Haskell 
programs are very fast that you wouldn't believe they are written in 
Haskell. He often come up with ingenious solutions to problems. I think 
Haskell tend to attract bright individuals and programming theoreticians.

I find it funny that people now use C as the golden standard to measure 
performance. Back then people used to think that C was slow compared to 
ASM. In fact, C is still slow compared to well-written ASM code. Often, C++ 
compilers are able to produce much more efficient code compared to C, 
thanks to some C++ constructs that allow the compilers to make better 
optimization decision. So C isn't really the *fastest* programming language 
out there.

While micro benchmark may give valuable feedback, do not use it as the sole 
measure to judge a programming language's merits. At the end of the day, it 
is the carpenter who makes the furniture and not his fancy hammer.

On Monday, February 4, 2019 at 1:22:54 AM UTC+7, Miki Tebeka wrote:

> Hi,
>
> I'm comparing two loops in Go and C. The Go code on my machine is about 3 
> times slower than C. I know C can be faster but didn't think it'll be that 
> faster. Any ideas what's making the Go code slower?
>
> You can see the code at https://github.com/tebeka/go-c-loop
>
> Go Code:
> package main
>
>
> import (
>  "fmt"
>  "os"
>  "strconv"
>  "time"
> )
>
>
> func main() {
>  n, _ := strconv.Atoi(os.Args[1])
>  m, _ := strconv.Atoi(os.Args[2])
>
>
>  sum := int(0)
>  start := time.Now()
>  for i := 0; i < 1000; i++ {
>  if i%n != m {
>  sum += n
>  }
>  }
>
>
>  fmt.Println(time.Now().Sub(start).Seconds(), sum)
> }
>
>
>
> C Code
> #include 
> #include 
> #include 
>
>
>
>
> int main(int argc,char** argv) {
> unsigned long long ull0,ull1;
> unsigned int sum=0,n,m;
>
>
> sscanf(argv[1],"%d",);
> sscanf(argv[2],"%d",);
>
>
> ull0 = __rdtsc();
> for(int i=0; i<1000; i++) {
> if(i%n != m) {
> sum += n;
> }
>
>
> }
>
>
> ull1 = __rdtsc();
> printf("%f %d\n",(ull1-ull0)/2.1e9,sum);
> }
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Handling connection retries on a highly-available service

2019-02-11 Thread Space A.
It has absolutely nothing to do with mutexes/contexts/atomics or even Go 
(even if you program in Go).
This is engineering or architecture task not the language thing, so you 
need to think like an architect.

A lot of solutions possible if you add some sort of integration layer 
between P and Logger, for instance, in-memory DB. 

Another thing which you should probably think of, is heart-beats, f.e. 
Logger may notify P that he is available.



понедельник, 11 февраля 2019 г., 19:34:46 UTC+3 пользователь Michel Levieux 
написал:
>
> Hi guys. I need a little help here.
>
> I work in a digital marketing company, where we have a program that 
> receives a lot of requests every second (counted in thousands) and logs its 
> behaviour via a logger that runs on another server. We are currently trying 
> to implement a connection-retry system between this program and its logging 
> API. What we want is :
>
> - We have a main program - let's call it P
> - P sends logs to the logger in multiple goroutines.
> - Sometimes we might need to shut down the logger (for maintenance or 
> anything)
> - We want P to keep running when the logger's down
> - Once the logger's up again, P must Dial it back automatically and repair 
> the *bufio.Writer associated with it
>
> Would you guys know a way not to check each single Read/Write if the 
> logger's up?
>
> Up to here we have thought of using atomic, mutexes and context for 
> synchronization, but the issues we face are the following:
>
> - mutexes create "pending" requests, since there's no way to check if a 
> mutex is locked or not
> - we're not really sure about the right way to use context for this 
> specific case
> - we'd like to avoid using atomics as much as possible, notably about this 
> quote from the docs : "*Except for special, low-level applications, 
> synchronization is better done with channels or the facilities of the sync 
> package*"
>
> In the end, what we're looking for is to reach a minimal checking 
> frequency (is connection up? do something, else do nothing), the ideal 
> being not to have to check anything.
>
> Have you guys already faced such problematics in the past? What solutions 
> have you come up with?
>
> Many thx in advance for your help!
>

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


Re: [go-nuts] How to run some unittest repeatedly without build cache?

2019-02-11 Thread Ian Lance Taylor
On Mon, Feb 11, 2019 at 10:32 PM Cholerae Hu  wrote:
>
> Some bugs caused by data race cannot be detected by running unittest only 
> once. Before Go 1.12, I can use GOCACHE=off go test -race . to force it to 
> run without cache, but GOCACHE=on is required as of Go 1.12. So how can I 
> workaround this?

go test -count=1

(This is documented at https://golang.org/cmd/go).

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] How to run some unittest repeatedly without build cache?

2019-02-11 Thread Cholerae Hu
Some bugs caused by data race cannot be detected by running unittest only 
once. Before Go 1.12, I can use GOCACHE=off go test -race . to force it to 
run without cache, but GOCACHE=on is required as of Go 1.12. So how can I 
workaround this?

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


Re: [go-nuts] Go vs C speed - What am I doing wrong?

2019-02-11 Thread Wojciech S. Czarnecki
On Sat, 9 Feb 2019 09:30:24 -0800 (PST)
"'Isaac Gouy' via golang-nuts"  wrote:

> > *"Look at the history of java samples and benchmark earlier vs current at 
> > same task"* 
> and conclude what?

That some languages demands very deep intrinsic knowledge to get code
running faster than in its most naïve — aka comprehensible — form.  
And that there are languages that tends to have no or almost no tricks under
the hood that allows for shortcuts to faster code.

> > Even then the chosen domain inevitably would bring a bias
> So, like [platforms07-tse-2010.pdf]

Yes, indeed :)

Kind regards,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Enumerate query result fields using "github.com/go-ole/go-ole/oleutil"

2019-02-11 Thread Lutz Horn

Any ideas on how I can get a list of fields (not values) after executing
something like this?


Try these:

* https://golang.org/pkg/database/sql/#Rows.Columns
* https://golang.org/pkg/database/sql/#Rows.ColumnTypes

These methods give you information about the columns of a sql.Row.

Lutz


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Help- Empty request header and body

2019-02-11 Thread Lutz Horn

Am new in golang and am trying to write an API but my request header and
body is always empty.


Well, that's a *lot* of code. Please trim it so it forms a SSCCE 
(http://www.sscce.org/).


Lutz


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 modules do not respect vendor folder of dependencies (is this by design?)

2019-02-11 Thread 'Bryan Mills' via golang-nuts
The fact that a module-mode build ignores dependencies vendored into *other* 
modules 
is intentional.
#27227 may change several details of vendoring in module mode, but this is 
not one of them.

If module B vendors its dependencies but does not specify their versions in 
a go.mod file, then you should specify the versions of those dependencies 
that you want in *your* module's go.mod file. (You can set them to 
something consistent using go get -m.)


On Sunday, February 10, 2019 at 12:26:10 PM UTC-5, Ian Davis wrote:
>
>
> On Sun, 10 Feb 2019, at 12:03 AM, se...@pion.ly  wrote:
>
> * I have a project 'A' that is importing 'B'
> * 'B' uses a vendor folder, if you delete the vendor folder the project 
> does not compile.
> * With `GO111MODULE=on` I am unable to project 'A'. It tries to pull the 
> latest of 'B', and everything 'B' depends on (instead of using 'B's vendor 
> folder)
>
> Does anyone have suggestions on what I should do here? I don't control 
> project 'B' only 'A'
>
>
>
> This sounds like issue https://github.com/golang/go/issues/27227 which is 
> still under discussion
>
> Ian
>
>

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


Re: [go-nuts] Re: Documention of a blog entry out of date

2019-02-11 Thread Victor Giordano
Hi Peter! Thank for updating the reference, so instead of looking decode i
DO see panics and reconver in encode.go!!
I guess there is slight inconsistency in the go blog.

I will help you guys (and help me, and others) by pointing this out in the
proper place.
Greetings
V




El lun., 11 feb. 2019 a las 11:06, peterGo ()
escribió:

> Victor,
>
> If you look at the source code, you may find that the blog inadvertently
> switched decode and encode. See encode.go.
>
> Reporting issues: If you spot bugs, mistakes, or inconsistencies in the Go
> project's code or documentation, please let us know by filing a ticket on
> our issue tracker. https://github.com/golang/go/issues
>
> Peter
>
> On Monday, February 11, 2019 at 8:19:58 AM UTC-5, Victor Giordano wrote:
>>
>> Dear all i was reading The defer, panic and recover entry
>> at the go blog until i
>> found this statement:
>>
>> For a real-world example of panic and recover, see the json package from
>>> the Go standard library. It decodes JSON-encoded data with a set of
>>> recursive functions. When malformed JSON is encountered, the parser calls
>>> panic to unwind the stack to the top-level function call, *which
>>> recovers from the panic and returns an appropriate error value* (see
>>> the 'error' and 'unmarshal' methods of the decodeState type in decode.go).
>>
>>
>> In the source code of decode.go
>>  and try to find "
>> *recover*" or "*panic*". Panic is present but no recover! I gues that as
>> time pass, changes to the code occurs and the documention was leave behind
>> outdated. Totally normal, but i guess it would the time to edit the blog.
>> If my premises aren't wrong, my concrete question is: Where i can file a
>> ticket for that?
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/XaSSyLrT81w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: [go-nuts] Basic Data structures and Algorithms with Go

2019-02-11 Thread Lutz Horn
The first chapter of my book from packt  is available on 
golangweekly. Book Title: "Basic  Data structures and Algorithms with

Go".


Some quick observations:

The code indention of many code snippets is broken. Example:
https://i.postimg.cc/6QFyMVjr/twic-Value.png

The terminal windows are *huge* and contain almost nothing. Example:
https://i.postimg.cc/dQ5KvQFX/term.png

A paragraph like this on page 2 does not help at all.


In the next code snippet, the Range keyword is explained in detail.
The Range keyword can be used to access index and value for each
element


Nothing is "explained" about `range` in the following code snippet.

Does Packt Publishing have an editor who makes sure quality standards 
are adhered to? Or can anybody just publish anything?


The recommended book about Go is still http://www.gopl.io/

Lutz

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Documention of a blog entry out of date

2019-02-11 Thread peterGo
Victor,

If you look at the source code, you may find that the blog inadvertently 
switched decode and encode. See encode.go.

Reporting issues: If you spot bugs, mistakes, or inconsistencies in the Go 
project's code or documentation, please let us know by filing a ticket on 
our issue tracker. https://github.com/golang/go/issues

Peter

On Monday, February 11, 2019 at 8:19:58 AM UTC-5, Victor Giordano wrote:
>
> Dear all i was reading The defer, panic and recover entry 
> at the go blog until i 
> found this statement:
>
> For a real-world example of panic and recover, see the json package from 
>> the Go standard library. It decodes JSON-encoded data with a set of 
>> recursive functions. When malformed JSON is encountered, the parser calls 
>> panic to unwind the stack to the top-level function call, *which 
>> recovers from the panic and returns an appropriate error value* (see the 
>> 'error' and 'unmarshal' methods of the decodeState type in decode.go).
>
>
> In the source code of decode.go 
>  and try to find "
> *recover*" or "*panic*". Panic is present but no recover! I gues that as 
> time pass, changes to the code occurs and the documention was leave behind 
> outdated. Totally normal, but i guess it would the time to edit the blog.
> If my premises aren't wrong, my concrete question is: Where i can file a 
> ticket for that?
>
>

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


[go-nuts] facing error "pq: unexpected Parse response 'C'" for multiple queries

2019-02-11 Thread aniruddha . dwivedi
Hi, I am working on project where I connect through PostgreSQL for CRUD 
operations and in back end I use golang. 
For transaction handling , I was using simple transaction objects for 
handling db operations as -

*tx, err := db.Begin()*
* handleError(ctx,err)*

*data, err := tx.Query(sqlStmt, 
val[ie])*


*   handleError(ctx,tx.Commit())*

As I have to execute multiple sql statements in same function for multiple 
db operations like --

sqlStmt1 := `INSERT INTO 
rules3(name,threshold,rule_condition,base_sql,cron,email_subject,chartio_url,rule_owner,expiration_date)
 
select 
name,threshold,rule_condition,base_sql,cron,email_subject,chartio_url,rule_owner,expiration_date
 
from rules3 where id in ($1) returning id`
data1, err := tx.Query(sqlStmt1 ,val[ie])

var cloneid int64
for cldata.Next(){
cldata.Scan()
log.Infof(ctx,"id returning from clone query is:%d ",cloneid)
}
sqlStmt2 := fmt.Sprint("update rules3 set name = (CASE WHEN length(name) > 
58 THEN replace(name,right(name,5),'_copy') ELSE concat(name,'_copy') END), 
is_active = false where id in (",cloneid,");")
data2, err := tx.Query(sqlStmt2 )


sqlStmt3 := `INSERT INTO rulesuserassoc3(rule_id, user_id) SELECT (SELECT 
A.id FROM rules3 A WHERE A.id in ($1)), B.user_id FROM rulesuserassoc3 B 
WHERE B.rule_id in ($2)`
data3, err := tx.Query(sqlStmt3 ,cloneid,val[ie])

Problem is when I hit url of that function in postman, I get weird error ---* 
"pq: 
unexpected Parse response 'C'"*

I don't know what I am doing wrong in my code for which I get above error 
and how to resolve this.
your help is much appreciated.




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Documention of a blog entry out of date

2019-02-11 Thread Victor Giordano
Dear all i was reading The defer, panic and recover entry 
at the go blog until i 
found this statement:

For a real-world example of panic and recover, see the json package from 
> the Go standard library. It decodes JSON-encoded data with a set of 
> recursive functions. When malformed JSON is encountered, the parser calls 
> panic to unwind the stack to the top-level function call, *which recovers 
> from the panic and returns an appropriate error value* (see the 'error' 
> and 'unmarshal' methods of the decodeState type in decode.go).


In the source code of decode.go 
 and try to find "*recover*" 
or "*panic*". Panic is present but no recover! I gues that as time pass, 
changes to the code occurs and the documention was leave behind outdated. 
Totally normal, but i guess it would the time to edit the blog.
If my premises aren't wrong, my concrete question is: Where i can file a 
ticket for that?

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


Re: [go-nuts] Help- Empty request header and body

2019-02-11 Thread afriyie . abraham
Hi,

Please attacted is app files (unnecessary codes deleted). I don’t if I 
could made mode simpler 
but this is how am able let you identify the problem am encountering when I 
run this code. 
I tried to print the request header and body and this is what am getting

 ]
&{{ObjectIdHex("") 0  0  [] [] []}}
2019/02/11 14:38:16 panic: ObjectIDs must be exactly 12 bytes long (got 0)
2019/02/11 14:38:16 [PUT] 
"/nnrf-nfm/v1/nf-instances/3fa85f64-5717-4562-b3fc-2c963f66afa6" 775.484µs

Thanks in advance



On Monday, February 11, 2019 at 11:29:05 AM UTC+2, Lutz Horn wrote:
>
> > Am new in golang and am trying to write an API but my request header and 
> > body is always empty. 
>
> Well, that's a *lot* of code. Please trim it so it forms a SSCCE 
> (http://www.sscce.org/). 
>
> Lutz 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Basic Data structures and Algorithms with Go

2019-02-11 Thread Bhagvan Kommadi
The first chapter of my book from packt  is available on golangweekly. Book 
Title: "Basic  Data structures and Algorithms with Go". Check out the 
golangweekly :



https://golangweekly.com/link/59052/5d605019f3



The code for the book is available at:


https://lnkd.in/f-Dy_Z4


#machinelearning #go #algorithms #datastructures 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Handling connection retries on a highly-available service

2019-02-11 Thread Michel Levieux
Hi guys. I need a little help here.

I work in a digital marketing company, where we have a program that
receives a lot of requests every second (counted in thousands) and logs its
behaviour via a logger that runs on another server. We are currently trying
to implement a connection-retry system between this program and its logging
API. What we want is :

- We have a main program - let's call it P
- P sends logs to the logger in multiple goroutines.
- Sometimes we might need to shut down the logger (for maintenance or
anything)
- We want P to keep running when the logger's down
- Once the logger's up again, P must Dial it back automatically and repair
the *bufio.Writer associated with it

Would you guys know a way not to check each single Read/Write if the
logger's up?

Up to here we have thought of using atomic, mutexes and context for
synchronization, but the issues we face are the following:

- mutexes create "pending" requests, since there's no way to check if a
mutex is locked or not
- we're not really sure about the right way to use context for this
specific case
- we'd like to avoid using atomics as much as possible, notably about this
quote from the docs : "*Except for special, low-level applications,
synchronization is better done with channels or the facilities of the sync
package*"

In the end, what we're looking for is to reach a minimal checking frequency
(is connection up? do something, else do nothing), the ideal being not to
have to check anything.

Have you guys already faced such problematics in the past? What solutions
have you come up with?

Many thx in advance for your help!

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