Re: [go-nuts] Help with Go channels and select talk

[robert engels]

I’m sorry but your design is not comprehendible by me, and I’ve done lots of 
TCP based services. 

i think you only need to emulate classic TCP processing - a reader thread (Go 
routine) on each side of the connection using range to read until closed. The 
connection is represented by 2 channels - one for each direction.

I think you might be encountering a deadlock because the producer on one end is 
not also reading the incoming - so either restructure, or use 2 more threads 
for the producers.



> On Dec 6, 2019, at 10:38 PM, Egon Kocjan  wrote:
> 
> Agreed, I see goroutines in general as a big win. But what I intend to talk 
> about in the presentation:
> - we have two unidirectional flows of data resembling something like a TCP 
> socket, easy to do with two goroutines with a for loop
> - let's add caching, so some requests do not go to the server
> - it would be tempting to just combine two goroutines into one and handle 
> caching in a single loop without using locks (I see developers avoid atomics 
> and locks if they don't have a lot of previous experience with traditional MT 
> primitives)
> - this is surprisingly difficult to do properly with Go channels, see my 
> attempts: https://github.com/egonk/chandemo/blob/master/2_3.go 
>  and 
> https://github.com/egonk/chandemo/blob/master/2_4.go 
> 
> - it is easy to do in actor systems, just move the code for both actors into 
> a single actor!
> 
> The lesson here is that select is not a nice and safe compose statement even 
> if it appears so at the first glance, do not be afraid to use locks.
> 
> Of course, if somebody comes up with a better implementation than 2_3.go and 
> 2_4.go, I would be very happy to include it in the talk.
> 
> On Saturday, December 7, 2019 at 4:17:04 AM UTC+1, robert engels wrote:
> To clarify, with Go’s very lightweight threads it is “doing the multiplexing 
> for you” - often only a single CPU is consumed if the producer and consumer 
> work cannot be parallelized, otherwise you get this concurrency “for free”.
> 
> You are trying to manually perform the multiplexing - you need async 
> structures to do this well - Go doesn’t really support async by design - and 
> it’s a much simpler programming model as a result.
> 
>> On Dec 6, 2019, at 12:02 PM, Robert Engels > wrote:
>> 
>> A channel is much closer to a pipe. There are producers and consumers and 
>> these are typically different threads of execution unless you have an event 
>> based (async) system - that is not Go. 
>> 
>>> On Dec 6, 2019, at 9:30 AM, Egon Kocjan > wrote:
>>> 
>>> 
>>> There are goroutines in the examples of course, just a single goroutine per 
>>> bidi channel seems hard. By contrast, I've worked with actor systems before 
>>> and they are perfectly fine with a single fiber.
>>> 
>>> On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>>> Channels are designed to be used with multiple go routines - if you’re not 
>>> you are doing something wrong. 
>>> 
 On Dec 6, 2019, at 8:32 AM, Egon Kocjan > wrote:
 
 
 Hello
 
 I'm preparing a short talk about Go channels and select. More 
 specifically, I want to show what not to do. I chose a bidirectional 
 communication channel implementation, because it seems to be a common base 
 for a lot of problems but hard to implement correctly without using any 
 extra goroutines. All the code is here: https://github.com/egonk/chandemo 
 
 
 1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
 2_1.go: nice but completely wrong
 2_2.go: better but still deadlocks
 2_3.go: correct but ugly and slow (takes more than 2s for million ints)
 2_4.go: correct and a bit faster but still ugly (1.8s for million ints)
 
 So my question: is there a better way of doing it with just nested for and 
 select and no goroutines? Basically, what would 2_5.go look like?
 
 Thank you
 Egon
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to golan...@googlegroups.com <>.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/82830a5d-2bd8-4324-890e-9ae7f5f0fbaf%40googlegroups.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 golan...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> 

Re: [go-nuts] manifest file of releases

[Wagner Riffel]

On Thu Dec 5, 2019 at 8:27 AM  wrote:
> I would hope there would be a JSON file from which I could use to monitor 
> releases and obtain download URLs. Something similar to what CoreOS does:
> https://coreos.com/releases/releases.json

GET https://golang.org/dl/?mode=json, then your download link would be
https://storage.googleapis.com/golang/ + "filename" field in the json.

- wgr

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BYYYF11U1DN7.3AKDHU881DXM9%40pampas.

Re: [go-nuts] Help with Go channels and select talk

[Jason E. Aten]

@Egon, 

I'm sure many here would jump in and assist, but you need to help us to 
help you by spelling out, specifically and exactly, the problem(s) you want 
solved. A few sentences on each challenge should suffice.

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a540a6bd-1f41-4f86-8e1f-4b5ac8288814%40googlegroups.com.

Re: [go-nuts] Help with Go channels and select talk

[Egon Kocjan]

Agreed, I see goroutines in general as a big win. But what I intend to talk 
about in the presentation:
- we have two unidirectional flows of data resembling something like a TCP 
socket, easy to do with two goroutines with a for loop
- let's add caching, so some requests do not go to the server
- it would be tempting to just combine two goroutines into one and handle 
caching in a single loop without using locks (I see developers avoid 
atomics and locks if they don't have a lot of previous experience with 
traditional MT primitives)
- this is surprisingly difficult to do properly with Go channels, see my 
attempts: https://github.com/egonk/chandemo/blob/master/2_3.go and 
https://github.com/egonk/chandemo/blob/master/2_4.go 

- it is easy to do in actor systems, just move the code for both actors 
into a single actor!

The lesson here is that select is not a nice and safe compose statement 
even if it appears so at the first glance, do not be afraid to use locks.

Of course, if somebody comes up with a better implementation than 2_3.go 
and 2_4.go, I would be very happy to include it in the talk.

On Saturday, December 7, 2019 at 4:17:04 AM UTC+1, robert engels wrote:
>
> To clarify, with Go’s very lightweight threads it is “doing the 
> multiplexing for you” - often only a single CPU is consumed if the producer 
> and consumer work cannot be parallelized, otherwise you get this 
> concurrency “for free”.
>
> You are trying to manually perform the multiplexing - you need async 
> structures to do this well - Go doesn’t really support async by design - 
> and it’s a much simpler programming model as a result.
>
> On Dec 6, 2019, at 12:02 PM, Robert Engels  > wrote:
>
> A channel is much closer to a pipe. There are producers and consumers and 
> these are typically different threads of execution unless you have an event 
> based (async) system - that is not Go. 
>
> On Dec 6, 2019, at 9:30 AM, Egon Kocjan > 
> wrote:
>
> 
> There are goroutines in the examples of course, just a single goroutine 
> per bidi channel seems hard. By contrast, I've worked with actor systems 
> before and they are perfectly fine with a single fiber.
>
> On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>>
>> Channels are designed to be used with multiple go routines - if you’re 
>> not you are doing something wrong. 
>>
>> On Dec 6, 2019, at 8:32 AM, Egon Kocjan  wrote:
>>
>> 
>> Hello
>>
>> I'm preparing a short talk about Go channels and select. More 
>> specifically, I want to show what not to do. I chose a bidirectional 
>> communication channel implementation, because it seems to be a common base 
>> for a lot of problems but hard to implement correctly without using any 
>> extra goroutines. All the code is here: https://github.com/egonk/chandemo
>>
>> 1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
>> 2_1.go: nice but completely wrong
>> 2_2.go: better but still deadlocks
>> 2_3.go: correct but ugly and slow (takes more than 2s for million ints)
>> 2_4.go: correct and a bit faster but still ugly (1.8s for million ints)
>>
>> So my question: is there a better way of doing it with just nested for 
>> and select and no goroutines? Basically, what would 2_5.go look like?
>>
>> Thank you
>> Egon
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/82830a5d-2bd8-4324-890e-9ae7f5f0fbaf%40googlegroups.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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/bdc57eb0-b26f-4364-87fb-241b0807e8ae%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/75d69b4e-4fb7-4f62-8011-f21e2a4c294a%40googlegroups.com.

[go-nuts] benchgraph: no data to show

[Tong Sun]

Oh, yeah, that's perfect. 

However, anyone get it working? 

I think I'm following the instruction correctly, however, whatever I tried, 
I always get no data to show error. I use benchgraph from latest git. 

Anyone able to get benchgraph from latest git working? 

Thx.


On Friday, December 6, 2019 at 3:14:57 PM UTC-5, Sean Liao wrote:
>
> not sure if this fits https://github.com/codingberg/benchgraph
>
>
> On Friday, December 6, 2019 at 2:21:47 AM UTC+1, Tong Sun wrote:
>>
>> Hi, 
>>
>> Any existing tools out there that can turn Go's benchmark result from 
>> text into chart? 
>>
>> I'm looking for a simple/light-weighted solution, like using gnuplot, or 
>> web --
>> Found one using Python to plot Go's benchmark result, but don't like the 
>> overhead. 
>>
>> thx
>>
>>

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/085ed5e6-e12a-4000-87dc-97c14fdbe3fe%40googlegroups.com.

Re: [go-nuts] Help with Go channels and select talk

[robert engels]

To clarify, with Go’s very lightweight threads it is “doing the multiplexing 
for you” - often only a single CPU is consumed if the producer and consumer 
work cannot be parallelized, otherwise you get this concurrency “for free”.

You are trying to manually perform the multiplexing - you need async structures 
to do this well - Go doesn’t really support async by design - and it’s a much 
simpler programming model as a result.

> On Dec 6, 2019, at 12:02 PM, Robert Engels  wrote:
> 
> A channel is much closer to a pipe. There are producers and consumers and 
> these are typically different threads of execution unless you have an event 
> based (async) system - that is not Go. 
> 
>> On Dec 6, 2019, at 9:30 AM, Egon Kocjan  wrote:
>> 
>> 
>> There are goroutines in the examples of course, just a single goroutine per 
>> bidi channel seems hard. By contrast, I've worked with actor systems before 
>> and they are perfectly fine with a single fiber.
>> 
>> On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>> Channels are designed to be used with multiple go routines - if you’re not 
>> you are doing something wrong. 
>> 
>>> On Dec 6, 2019, at 8:32 AM, Egon Kocjan > wrote:
>>> 
>>> 
>>> Hello
>>> 
>>> I'm preparing a short talk about Go channels and select. More specifically, 
>>> I want to show what not to do. I chose a bidirectional communication 
>>> channel implementation, because it seems to be a common base for a lot of 
>>> problems but hard to implement correctly without using any extra 
>>> goroutines. All the code is here: https://github.com/egonk/chandemo 
>>> 
>>> 
>>> 1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
>>> 2_1.go: nice but completely wrong
>>> 2_2.go: better but still deadlocks
>>> 2_3.go: correct but ugly and slow (takes more than 2s for million ints)
>>> 2_4.go: correct and a bit faster but still ugly (1.8s for million ints)
>>> 
>>> So my question: is there a better way of doing it with just nested for and 
>>> select and no goroutines? Basically, what would 2_5.go look like?
>>> 
>>> Thank you
>>> Egon
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golan...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/82830a5d-2bd8-4324-890e-9ae7f5f0fbaf%40googlegroups.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 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/bdc57eb0-b26f-4364-87fb-241b0807e8ae%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F798CDF8-8108-437F-A435-7C8B882BFA96%40ix.netcom.com.

[go-nuts] getting a function docs when you have a *packages.Package

[Dan Kortschak]

I want to be able to extract function documentation in addition to a
variety of other information. I have a *packages.Package from
packages.Load. Is there an easy way to get the function documentation
from this. At the moment I am obtaining a *doc.Package using the
following code, but it seems more complicated than necessary and it
returns errors (I think) because I do not have an ast.Importer and I
don't see a place to get one.

files := make(map[string]*ast.File)
for _, f := range pkg.Syntax {
files[f.Name.Name] = f
}
astPkg, err := ast.NewPackage(pkg.Fset, files, nil, ast.NewScope(nil))
if err != nil {
log.Printf("error preparing docs: %v", err)
}
docs := doc.New(astPkg, pkg.PkgPath, doc.PreserveAST)

Is there a more sensible way to do this?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/00d778703983e75b997144416641e9c365bb82e4.camel%40kortschak.io.

Re: [go-nuts] Plot Go's benchmark result

[Sebastien Binet]

there's this from Austin Clements:

https://godoc.org/github.com/aclements/go-misc/benchplot

On Fri, Dec 6, 2019 at 2:22 AM Tong Sun  wrote:

> Hi,
>
> Any existing tools out there that can turn Go's benchmark result from text
> into chart?
>
> I'm looking for a simple/light-weighted solution, like using gnuplot, or
> web --
> Found one using Python to plot Go's benchmark result, but don't like the
> overhead.
>
> thx
>
> --
> You received this message because you are subscribed 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c737f2d5-cc55-4ddc-a905-9c443d3916c8%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAV3P_BYfF-h4mMowyKZDS-Sk9eUnxbQso0As2U89SQDyE6uHg%40mail.gmail.com.

Re: [go-nuts] Multiple processes in parallel for cgo service

[Brian Candler]

Can you just run multiple instances of your program, each independently 
fetching messages from SQS?

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/36c64d89-c8bf-4595-8fc3-fdc11a8b315b%40googlegroups.com.

[go-nuts] Re: Plot Go's benchmark result

[Sean Liao]

not sure if this fits https://github.com/codingberg/benchgraph


On Friday, December 6, 2019 at 2:21:47 AM UTC+1, Tong Sun wrote:
>
> Hi, 
>
> Any existing tools out there that can turn Go's benchmark result from text 
> into chart? 
>
> I'm looking for a simple/light-weighted solution, like using gnuplot, or 
> web --
> Found one using Python to plot Go's benchmark result, but don't like the 
> overhead. 
>
> thx
>
>

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/907fe2a0-f791-4012-9caf-398426541981%40googlegroups.com.

Re: [go-nuts] run queue length

[Ian Lance Taylor]

On Fri, Dec 6, 2019 at 11:29 AM Hochhaus, Andy  wrote:
>
> I would like to export the runtime run queue length (as can be seen using "go 
> tool trace") to our monitoring infrastructure but I am unable to find a way 
> to access it using the runtime package without traces enabled. Is the run 
> queue length accessible from application code?

Not as far as I know.  There is some related discussion at
https://golang.org/issue/15490.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUR3GW68zTO3%3DG4O73VjC-NwONwr6fVv-9GUcM_SexyuQ%40mail.gmail.com.

[go-nuts] Re: Inconsistent rounding with float printf ?

[cratermoon]

https://play.golang.org/p/j5HKxitS-Z6

See  https://0.30004.com/

On Friday, December 6, 2019 at 1:25:01 AM UTC-8, Christophe Meessen wrote:
>
> I have noticed that printf performs an apparently inconsistent rounding of 
> floating point values.
>
> I divide a big number by 1000 and printf the resulting value with "%.1f".
> Here is the code: https://play.golang.org/p/e7dD3c6IHq2
>
> I would expect the rounding rule to be "round away from zero" as defined 
> here: https://math.stackexchange.com/a/2252888/33796
> In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05 
> to -0.1). 
>
> Here is what I see with golang 1.13.4:
>
> 999000/1000 = 999.0
> 999050/1000 = 999.0 // expected 999.1
> 999100/1000 = 999.1
> 999150/1000 = 999.1 // expected 999.2
> 999200/1000 = 999.2
> 999250/1000 = 999.2 // expected 999.3
> 999300/1000 = 999.3
> 999350/1000 = 999.4 
> 999400/1000 = 999.4
> 999450/1000 = 999.5 
> 999500/1000 = 999.5
> 999550/1000 = 999.5 // expected 999.6
> 999600/1000 = 999.6
> 999650/1000 = 999.6 // expected 999.7
> 999700/1000 = 999.7
> 999750/1000 = 999.8 
> 999800/1000 = 999.8
> 999850/1000 = 999.9 
> 00/1000 = 999.9
> 50/1000 = 1000.0 
> -50/1000 = -1000.0 
> -00/1000 = -999.9
> -999850/1000 = -999.9  
> -999800/1000 = -999.8
> -999750/1000 = -999.8
> -999700/1000 = -999.7
> -999650/1000 = -999.6 // expected -999.7
> -999600/1000 = -999.6
> -999550/1000 = -999.5 // expected -999.6
> -999500/1000 = -999.5
> -999450/1000 = -999.5
> -999400/1000 = -999.4
> -999350/1000 = -999.4
> -999300/1000 = -999.3
> -999250/1000 = -999.2 // expected -999.3
> -999200/1000 = -999.2
> -999150/1000 = -999.1 // expected -999.2
> -999100/1000 = -999.1
> -999050/1000 = -999.0 // expected -999.1
>
>
> Is this actual rounding the result of a rule or is it pseudo random ? 
>

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/138f55d2-e7a6-4f12-85fd-d14bc42699f7%40googlegroups.com.

[go-nuts] run queue length

[Hochhaus, Andy]

Hello,

I would like to export the runtime run queue length (as can be seen using
"go tool trace") to our monitoring infrastructure but I am unable to find a
way to access it using the runtime package without traces enabled. Is the
run queue length accessible from application code?

-Andy

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAhqAFqYxFd%3D6o9HLmR2t9%3DqvDfWCUVLBLn9syt53quoYc8M_Q%40mail.gmail.com.

Re: [go-nuts] Help with Go channels and select talk

[Robert Engels]

A channel is much closer to a pipe. There are producers and consumers and these 
are typically different threads of execution unless you have an event based 
(async) system - that is not Go. 

> On Dec 6, 2019, at 9:30 AM, Egon Kocjan  wrote:
> 
> 
> There are goroutines in the examples of course, just a single goroutine per 
> bidi channel seems hard. By contrast, I've worked with actor systems before 
> and they are perfectly fine with a single fiber.
> 
>> On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>> Channels are designed to be used with multiple go routines - if you’re not 
>> you are doing something wrong. 
>> 
 On Dec 6, 2019, at 8:32 AM, Egon Kocjan  wrote:
 
>>> 
>>> Hello
>>> 
>>> I'm preparing a short talk about Go channels and select. More specifically, 
>>> I want to show what not to do. I chose a bidirectional communication 
>>> channel implementation, because it seems to be a common base for a lot of 
>>> problems but hard to implement correctly without using any extra 
>>> goroutines. All the code is here: https://github.com/egonk/chandemo
>>> 
>>> 1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
>>> 2_1.go: nice but completely wrong
>>> 2_2.go: better but still deadlocks
>>> 2_3.go: correct but ugly and slow (takes more than 2s for million ints)
>>> 2_4.go: correct and a bit faster but still ugly (1.8s for million ints)
>>> 
>>> So my question: is there a better way of doing it with just nested for and 
>>> select and no goroutines? Basically, what would 2_5.go look like?
>>> 
>>> Thank you
>>> Egon
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/82830a5d-2bd8-4324-890e-9ae7f5f0fbaf%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/bdc57eb0-b26f-4364-87fb-241b0807e8ae%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9F3C3A18-9A8D-44A6-881F-729FB364FBED%40ix.netcom.com.

Re: [go-nuts] Re: Inconsistent rounding with float printf ?

[Jan Mercl]

On Fri, Dec 6, 2019 at 6:04 PM Christophe Meessen
 wrote:

> I can't change expectations. It is to convert a byte count into a human 
> readable byte count ( with kB, MB, ... units).

So it was an XY problem?

No floating point operations are necessary to do that. Also, check
several existing libraries, for example this one:
https://github.com/dustin/go-humanize

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VnzYWABrP8ET7KkqeRrjNzH6kxoE8Sjwog8mcqbgTxqA%40mail.gmail.com.

[go-nuts] Re: Inconsistent rounding with float printf ?

[Christophe Meessen]

I can't change expectations. It is to convert a byte count into a human 
readable byte count ( with kB, MB, ... units). 

I found out that I can produce the expected result by using math.Round. See 
here https://play.golang.org/p/UorDwbKlLj5

For my use case, I ended up converting "manually" the integer into a .1f 
float by using an array. The resulting code is 12 time faster than the one 
using the printf and float64 operations. It also need only one allocation 
to convert the byte array into a string. 

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/425dd75e-7d58-44cd-9e99-b197b81c078e%40googlegroups.com.

Re: [go-nuts] Inconsistent rounding with float printf ?

[Robert Engels]

You can use github.com/robaho/fixed

> On Dec 6, 2019, at 10:19 AM, Michael Jones  wrote:
> 
> 
> Agree with Ian. 
> 
> Solutions are: change expectations, use decimal floating point, or use a 
> base-independent decimal representation. The latter implies scaled integers.
> 
> Quick, ugly, and typed on one hand from bed, but here it is: 
> https://play.golang.org/p/fBztRY6qHP0
> 
> 999000/1000 = 999.0
> 999050/1000 = 999.1
> 999100/1000 = 999.1
> 999150/1000 = 999.2
> 999200/1000 = 999.2
> 999250/1000 = 999.3
> 999300/1000 = 999.3
> 999350/1000 = 999.4
> 999400/1000 = 999.4
> 999450/1000 = 999.5
> 999500/1000 = 999.5
> 999550/1000 = 999.6
> 999600/1000 = 999.6
> 999650/1000 = 999.7
> 999700/1000 = 999.7
> 999750/1000 = 999.8
> 999800/1000 = 999.8
> 999850/1000 = 999.9
> 00/1000 = 999.9
> 50/1000 = 1000.0
> -50/1000 = -1000.0
> -00/1000 = -999.9
> -999850/1000 = -999.9
> -999800/1000 = -999.8
> -999750/1000 = -999.8
> -999700/1000 = -999.7
> -999650/1000 = -999.7
> -999600/1000 = -999.6
> -999550/1000 = -999.6
> -999500/1000 = -999.5
> -999450/1000 = -999.5
> -999400/1000 = -999.4
> -999350/1000 = -999.4
> -999300/1000 = -999.3
> -999250/1000 = -999.3
> -999200/1000 = -999.2
> -999150/1000 = -999.2
> -999100/1000 = -999.1
> -999050/1000 = -999.1
> 
>> On Fri, Dec 6, 2019 at 2:31 AM Ian Davis  wrote:
>>> On Fri, 6 Dec 2019, at 9:25 AM, Christophe Meessen wrote:
>>> I have noticed that printf performs an apparently inconsistent rounding of 
>>> floating point values.
>>> 
>>> I divide a big number by 1000 and printf the resulting value with "%.1f".
>>> Here is the code: https://play.golang.org/p/e7dD3c6IHq2
>> 
>> I think you are just seeing the usual problems of floating point 
>> representation. 
>> 
>> You may wonder why 999450/1000=999.45, 999500/1000=999.50 and 
>> 999550/1000=999.55 all format as 999.5. The answer is that the internal 
>> representation of the three results cannot correspond to the mathematical 
>> result you expect.
>> 
>> This link shows the internal representation of each answer: 
>> https://play.golang.org/p/bBTNCdsAttR
>> 
>> You can see that 999550/1000 = 
>> 999.5499954525264911353588104248046875 which is printed as 999.5
>> 
>> 
>>> I would expect the rounding rule to be "round away from zero" as defined 
>>> here: https://math.stackexchange.com/a/2252888/33796
>>> In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05 
>>> to -0.1). 
>> 
>> The strconv and fmt packages use round to even as a rule. Use math.Round to 
>> round away from zero.
>> 
>> -- 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/ee94624c-5485-4daf-98ad-8e59055056dd%40www.fastmail.com.
> 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQy%3DMCWgb69GgsZwAv2GT4ar%3DWrdvn212sFK1PfGES1ijw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D9F522AC-A89C-4915-9DEE-41D70E8A7C65%40ix.netcom.com.

Re: [go-nuts] Inconsistent rounding with float printf ?

[Michael Jones]

Agree with Ian.

Solutions are: change expectations, use decimal floating point, or use a
base-independent decimal representation. The latter implies scaled integers.

Quick, ugly, and typed on one hand from bed, but here it is:
https://play.golang.org/p/fBztRY6qHP0

999000/1000 = 999.0
999050/1000 = 999.1
999100/1000 = 999.1
999150/1000 = 999.2
999200/1000 = 999.2
999250/1000 = 999.3
999300/1000 = 999.3
999350/1000 = 999.4
999400/1000 = 999.4
999450/1000 = 999.5
999500/1000 = 999.5
999550/1000 = 999.6
999600/1000 = 999.6
999650/1000 = 999.7
999700/1000 = 999.7
999750/1000 = 999.8
999800/1000 = 999.8
999850/1000 = 999.9
00/1000 = 999.9
50/1000 = 1000.0
-50/1000 = -1000.0
-00/1000 = -999.9
-999850/1000 = -999.9
-999800/1000 = -999.8
-999750/1000 = -999.8
-999700/1000 = -999.7
-999650/1000 = -999.7
-999600/1000 = -999.6
-999550/1000 = -999.6
-999500/1000 = -999.5
-999450/1000 = -999.5
-999400/1000 = -999.4
-999350/1000 = -999.4
-999300/1000 = -999.3
-999250/1000 = -999.3
-999200/1000 = -999.2
-999150/1000 = -999.2
-999100/1000 = -999.1
-999050/1000 = -999.1


On Fri, Dec 6, 2019 at 2:31 AM Ian Davis  wrote:

> On Fri, 6 Dec 2019, at 9:25 AM, Christophe Meessen wrote:
>
> I have noticed that printf performs an apparently inconsistent rounding of
> floating point values.
>
> I divide a big number by 1000 and printf the resulting value with "%.1f".
> Here is the code: https://play.golang.org/p/e7dD3c6IHq2
>
>
> I think you are just seeing the usual problems of floating point
> representation.
>
> You may wonder why 999450/1000=999.45, 999500/1000=999.50 and
> 999550/1000=999.55 all format as 999.5. The answer is that the internal
> representation of the three results cannot correspond to the mathematical
> result you expect.
>
> This link shows the internal representation of each answer:
> https://play.golang.org/p/bBTNCdsAttR
>
> You can see that 999550/1000 = 999.5499954525264911353588104248046875
> which is printed as 999.5
>
>
> I would expect the rounding rule to be "round away from zero" as defined
> here: https://math.stackexchange.com/a/2252888/33796
> In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05
> to -0.1).
>
>
> The strconv and fmt packages use round to even as a rule. Use math.Round
> to round away from zero.
>
> -- 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ee94624c-5485-4daf-98ad-8e59055056dd%40www.fastmail.com
> 
> .
>


-- 

*Michael T. jonesmichael.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQy%3DMCWgb69GgsZwAv2GT4ar%3DWrdvn212sFK1PfGES1ijw%40mail.gmail.com.

Re: [go-nuts] Help with Go channels and select talk

[Egon Kocjan]

There are goroutines in the examples of course, just a single goroutine per 
bidi channel seems hard. By contrast, I've worked with actor systems before 
and they are perfectly fine with a single fiber.

On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>
> Channels are designed to be used with multiple go routines - if you’re not 
> you are doing something wrong. 
>
> On Dec 6, 2019, at 8:32 AM, Egon Kocjan > 
> wrote:
>
> 
> Hello
>
> I'm preparing a short talk about Go channels and select. More 
> specifically, I want to show what not to do. I chose a bidirectional 
> communication channel implementation, because it seems to be a common base 
> for a lot of problems but hard to implement correctly without using any 
> extra goroutines. All the code is here: https://github.com/egonk/chandemo
>
> 1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
> 2_1.go: nice but completely wrong
> 2_2.go: better but still deadlocks
> 2_3.go: correct but ugly and slow (takes more than 2s for million ints)
> 2_4.go: correct and a bit faster but still ugly (1.8s for million ints)
>
> So my question: is there a better way of doing it with just nested for and 
> select and no goroutines? Basically, what would 2_5.go look like?
>
> Thank you
> Egon
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/82830a5d-2bd8-4324-890e-9ae7f5f0fbaf%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bdc57eb0-b26f-4364-87fb-241b0807e8ae%40googlegroups.com.

Re: [go-nuts] Help with Go channels and select talk

[Robert Engels]

Channels are designed to be used with multiple go routines - if you’re not you 
are doing something wrong. 

> On Dec 6, 2019, at 8:32 AM, Egon Kocjan  wrote:
> 
> 
> Hello
> 
> I'm preparing a short talk about Go channels and select. More specifically, I 
> want to show what not to do. I chose a bidirectional communication channel 
> implementation, because it seems to be a common base for a lot of problems 
> but hard to implement correctly without using any extra goroutines. All the 
> code is here: https://github.com/egonk/chandemo
> 
> 1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
> 2_1.go: nice but completely wrong
> 2_2.go: better but still deadlocks
> 2_3.go: correct but ugly and slow (takes more than 2s for million ints)
> 2_4.go: correct and a bit faster but still ugly (1.8s for million ints)
> 
> So my question: is there a better way of doing it with just nested for and 
> select and no goroutines? Basically, what would 2_5.go look like?
> 
> Thank you
> Egon
> -- 
> You received this message because you are subscribed 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/82830a5d-2bd8-4324-890e-9ae7f5f0fbaf%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BD2088DD-59DA-4AA4-AE34-C8E81A79982A%40ix.netcom.com.

[go-nuts] Help with Go channels and select talk

[Egon Kocjan]

Hello

I'm preparing a short talk about Go channels and select. More specifically, 
I want to show what not to do. I chose a bidirectional communication 
channel implementation, because it seems to be a common base for a lot of 
problems but hard to implement correctly without using any extra 
goroutines. All the code is here: https://github.com/egonk/chandemo

1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
2_1.go: nice but completely wrong
2_2.go: better but still deadlocks
2_3.go: correct but ugly and slow (takes more than 2s for million ints)
2_4.go: correct and a bit faster but still ugly (1.8s for million ints)

So my question: is there a better way of doing it with just nested for and 
select and no goroutines? Basically, what would 2_5.go look like?

Thank you
Egon

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/82830a5d-2bd8-4324-890e-9ae7f5f0fbaf%40googlegroups.com.

Re: [go-nuts] Inconsistent rounding with float printf ?

[Ian Davis]

On Fri, 6 Dec 2019, at 9:25 AM, Christophe Meessen wrote:
> I have noticed that printf performs an apparently inconsistent rounding of 
> floating point values.
> 
> I divide a big number by 1000 and printf the resulting value with "%.1f".
> Here is the code: https://play.golang.org/p/e7dD3c6IHq2

I think you are just seeing the usual problems of floating point 
representation. 

You may wonder why 999450/1000=999.45, 999500/1000=999.50 and 
999550/1000=999.55 all format as 999.5. The answer is that the internal 
representation of the three results cannot correspond to the mathematical 
result you expect.

This link shows the internal representation of each answer: 
https://play.golang.org/p/bBTNCdsAttR

You can see that 999550/1000 = 999.5499954525264911353588104248046875 
which is printed as 999.5


> I would expect the rounding rule to be "round away from zero" as defined 
> here: https://math.stackexchange.com/a/2252888/33796
> In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05 to 
> -0.1). 

The strconv and fmt packages use round to even as a rule. Use math.Round to 
round away from zero.

-- 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ee94624c-5485-4daf-98ad-8e59055056dd%40www.fastmail.com.

[go-nuts] Inconsistent rounding with float printf ?

[Christophe Meessen]

I have noticed that printf performs an apparently inconsistent rounding of 
floating point values.

I divide a big number by 1000 and printf the resulting value with "%.1f".
Here is the code: https://play.golang.org/p/e7dD3c6IHq2

I would expect the rounding rule to be "round away from zero" as defined 
here: https://math.stackexchange.com/a/2252888/33796
In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05 
to -0.1). 

Here is what I see with golang 1.13.4:

999000/1000 = 999.0
999050/1000 = 999.0 // expected 999.1
999100/1000 = 999.1
999150/1000 = 999.1 // expected 999.2
999200/1000 = 999.2
999250/1000 = 999.2 // expected 999.3
999300/1000 = 999.3
999350/1000 = 999.4 
999400/1000 = 999.4
999450/1000 = 999.5 
999500/1000 = 999.5
999550/1000 = 999.5 // expected 999.6
999600/1000 = 999.6
999650/1000 = 999.6 // expected 999.7
999700/1000 = 999.7
999750/1000 = 999.8 
999800/1000 = 999.8
999850/1000 = 999.9 
00/1000 = 999.9
50/1000 = 1000.0 
-50/1000 = -1000.0 
-00/1000 = -999.9
-999850/1000 = -999.9  
-999800/1000 = -999.8
-999750/1000 = -999.8
-999700/1000 = -999.7
-999650/1000 = -999.6 // expected -999.7
-999600/1000 = -999.6
-999550/1000 = -999.5 // expected -999.6
-999500/1000 = -999.5
-999450/1000 = -999.5
-999400/1000 = -999.4
-999350/1000 = -999.4
-999300/1000 = -999.3
-999250/1000 = -999.2 // expected -999.3
-999200/1000 = -999.2
-999150/1000 = -999.1 // expected -999.2
-999100/1000 = -999.1
-999050/1000 = -999.0 // expected -999.1


Is this actual rounding the result of a rule or is it pseudo random ? 

-- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7ace93da-e330-4069-9b0c-6d1aa15fc179%40googlegroups.com.

Re: [go-nuts] Multiple processes in parallel for cgo service

[Nitish Saboo]

Hi Ian,

The Go code fetches a message from SQS and calls the C code to parse the
log messages.So this is what the cgo service does.
I would like to run the same service on different processes independently.
I am not sure how to achieve this in Go. Can you please guide me here.

Thanks,
Nitish

On Fri, Dec 6, 2019 at 11:11 AM Ian Lance Taylor  wrote:

> On Thu, Dec 5, 2019 at 2:41 AM Nitish Saboo 
> wrote:
> >
> > I am having a cgo(go + c) service.Is it possible to run multiple
> processes of the same service in parallel ?
>
> Well, it depends on what the service does.  But there is nothing in
> the Go tools or standard library that prevents you from doing this.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALjMrq4iazJYAraoAdiG%3D%3D1-4uWd03jLGbs00FmDhuOt%3Dix0ig%40mail.gmail.com.