Re: [go-nuts] Congrats to the Go team

[Steven Hartland]

t;> DivFixed-8  0.000 ±  0% 0.000 ±  0%~ (p=1.000 n=6) ¹   
>>> 0.000 ±  0%~ (p=1.000 n=6) ¹
>>> DivDecimal-8568.0 ±  0% 384.0 ±  0%  -32.39% (p=0.002 n=6) 
>>> 384.0 ±  0%  -32.39% (p=0.002 n=6)
>>> DivBigInt-8 8.000 ±  0% 8.000 ±  0%~ (p=1.000 n=6) ¹   
>>> 8.000 ±  0%~ (p=1.000 n=6) ¹
>>> DivBigFloat-8   24.00 ±  0% 24.00 ±  0%~ (p=1.000 n=6) ¹   
>>> 24.00 ±  0%~ (p=1.000 n=6) ¹
>>> CmpFixed-8  0.000 ±  0% 0.000 ±  0%~ (p=1.000 n=6) ¹   
>>> 0.000 ±  0%~ (p=1.000 n=6) ¹
>>> CmpDecimal-80.000 ±  0% 0.000 ±  0%~ (p=1.000 n=6) ¹   
>>> 0.000 ±  0%~ (p=1.000 n=6) ¹
>>> CmpBigInt-8 0.000 ±  0% 0.000 ±  0%~ (p=1.000 n=6) ¹   
>>> 0.000 ±  0%~ (p=1.000 n=6) ¹
>>> CmpBigFloat-8   0.000 ±  0% 0.000 ±  0%~ (p=1.000 n=6) ¹   
>>> 0.000 ±  0%~ (p=1.000 n=6) ¹
>>> StringFixed-8   32.00 ±  0% 24.00 ±  0%  -25.00% (p=0.002 n=6) 
>>> 24.00 ±  0%  -25.00% (p=0.002 n=6)
>>> StringNFixed-8  32.00 ±  0% 24.00 ±  0%  -25.00% (p=0.002 n=6) 
>>> 24.00 ±  0%  -25.00% (p=0.002 n=6)
>>> StringDecimal-8 64.00 ±  0% 56.00 ±  0%  -12.50% (p=0.002 n=6) 
>>> 56.00 ±  0%  -12.50% (p=0.002 n=6)
>>> StringBigInt-8  24.00 ±  0% 16.00 ±  0%  -33.33% (p=0.002 n=6) 
>>> 16.00 ±  0%  -33.33% (p=0.002 n=6)
>>> StringBigFloat-8192.0 ±  0% 176.0 ±  0%   -8.33% (p=0.002 n=6) 
>>> 176.0 ±  0%   -8.33% (p=0.002 n=6)
>>> WriteTo-8   21.00 ± 14% 23.00 ± 13%   +9.52% (p=0.002 n=6) 
>>> 23.00 ± 13%   +9.52% (p=0.002 n=6)
>>> geomean ² -9.89%   ²
>>>  -9.89%   ²
>>> ¹ all samples are equal
>>> ² summaries must be >0 to compute geomean
>>> 
>>> 
>>> 
>>>   │ go1.12.17.txt │
>>> go1.21.5.txt │go1.22.2.txt │
>>>  │   allocs/op   │ allocs/op   vs base │ 
>>> allocs/op   vs base │
>>> AddFixed-8  0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> AddDecimal-88.000 ± 0% 2.000 ± 0%  -75.00% (p=0.002 n=6) 
>>> 2.000 ± 0%  -75.00% (p=0.002 n=6)
>>> AddBigInt-8 0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> AddBigFloat-8   1.000 ± 0% 1.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 1.000 ± 0%~ (p=1.000 n=6) ¹
>>> MulFixed-8  0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> MulDecimal-82.000 ± 0% 2.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 2.000 ± 0%~ (p=1.000 n=6) ¹
>>> MulBigInt-8 0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> MulBigFloat-8   0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> DivFixed-8  0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> DivDecimal-821.00 ± 0% 12.00 ± 0%  -42.86% (p=0.002 n=6) 
>>> 12.00 ± 0%  -42.86% (p=0.002 n=6)
>>> DivBigInt-8 1.000 ± 0% 1.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 1.000 ± 0%~ (p=1.000 n=6) ¹
>>> DivBigFloat-8   2.000 ± 0% 2.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 2.000 ± 0%~ (p=1.000 n=6) ¹
>>> CmpFixed-8  0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> CmpDecimal-80.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> CmpBigInt-8 0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> CmpBigFloat-8   0.000 ± 0% 0.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 0.000 ± 0%~ (p=1.000 n=6) ¹
>>> StringFixed-8   1.000 ± 0% 1.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 1.000 ± 0%~ (p=1.000 n=6) ¹
>>> StringNFixed-8  1.000 ± 0% 1.000 ± 0%~ (p=1.000 n=6) ¹   
>>> 1.000 ± 0%~ (p=1.000 n=6) ¹
>>> StringDecimal-8 5.000 ± 0% 4.000 ± 0% 

Re: [go-nuts] Congrats to the Go team

[Steven Hartland]

   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpBigFloat-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringFixed-8   24.00 ± ∞ ¹   24.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringNFixed-8  24.00 ± ∞ ¹   24.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringDecimal-8 56.00 ± ∞ ¹   56.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringBigInt-8  16.00 ± ∞ ¹   16.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringBigFloat-8176.0 ± ∞ ¹   176.0 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> WriteTo-8   29.00 ± ∞ ¹   28.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ³
> geomean   ⁴-0.16% 
>   ⁴
> ¹ need >= 6 samples for confidence interval at level 0.95
> ² all samples are equal
> ³ need >= 4 samples to detect a difference at alpha level 0.05
> ⁴ summaries must be >0 to compute geomean
>   
>   
>   
>   │ 
> /Users/robertengels/go1.21.5.txt │  /Users/robertengels/go1.22.2.txt   │
>  │allocs/op │  allocs/op   vs base
> │
> AddFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddDecimal-82.000 ± ∞ ¹   2.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddBigInt-8 0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddBigFloat-8   1.000 ± ∞ ¹   1.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulDecimal-82.000 ± ∞ ¹   2.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulBigInt-8 0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulBigFloat-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivDecimal-812.00 ± ∞ ¹   12.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivBigInt-8 1.000 ± ∞ ¹   1.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivBigFloat-8   2.000 ± ∞ ¹   2.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpDecimal-80.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpBigInt-8 0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpBigFloat-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringFixed-8   1.000 ± ∞ ¹   1.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringNFixed-8  1.000 ± ∞ ¹   1.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringDecimal-8     4.000 ± ∞ ¹   4.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringBigInt-8  1.000 ± ∞ ¹   1.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringBigFloat-87.000 ± ∞ ¹   7.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> WriteTo-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> geomean   ³+0.00% 
>   ³
>
>
> On Apr 24, 2024, at 6:20 PM, Steven Hartland 
> wrote:
>
> What’s it look like when your run it through
> https://pkg.go.dev/golang.org/x/perf/cmd/benchstat which will provide a
> nice side by side comparison?
>
> On Wed, 24 Apr 2024 at 19:26, 'Robert Engels' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I have a fairly stable project github.com/robaho/fixed which is almost
>> 100% cpu bound. It doesn’t change so it makes a great way to compare the
>> performance of different Go versions using the same hardware. I took the
>> time to re-run the tests today.
>>
>> Using 1.21.17:
>>
>> BenchmarkAddFixed-8 20   0.59 ns/op  
>>   0 B/op  0 allocs/op
>> BenchmarkAddDecimal-8500   243 ns/op 
>> 176 B/op  8 allocs/op
>> BenchmarkAddBigInt-81   14.3 ns/op   
>>   0 B/op  0 allocs/op
>> BenchmarkAddBigFloat-8   

Re: [go-nuts] Congrats to the Go team

[Steven Hartland]

What’s it look like when your run it through
https://pkg.go.dev/golang.org/x/perf/cmd/benchstat which will provide a
nice side by side comparison?

On Wed, 24 Apr 2024 at 19:26, 'Robert Engels' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I have a fairly stable project github.com/robaho/fixed which is almost
> 100% cpu bound. It doesn’t change so it makes a great way to compare the
> performance of different Go versions using the same hardware. I took the
> time to re-run the tests today.
>
> Using 1.21.17:
>
> BenchmarkAddFixed-8 20   0.59 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkAddDecimal-8500   243 ns/op 
> 176 B/op  8 allocs/op
> BenchmarkAddBigInt-81   14.3 ns/op
>  0 B/op  0 allocs/op
> BenchmarkAddBigFloat-8  200078.8 ns/op
> 48 B/op  1 allocs/op
> BenchmarkMulFixed-8 34.88 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkMulDecimal-8   200072.0 ns/op
> 80 B/op  2 allocs/op
> BenchmarkMulBigInt-81   17.1 ns/op
>  0 B/op  0 allocs/op
> BenchmarkMulBigFloat-8  300035.5 ns/op
>  0 B/op  0 allocs/op
> BenchmarkDivFixed-8 34.71 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkDivDecimal-8200   779 ns/op 
> 568 B/op 21 allocs/op
> BenchmarkDivBigInt-8300046.1 ns/op
>  8 B/op  1 allocs/op
> BenchmarkDivBigFloat-8  2000   108 ns/op  
> 24 B/op  2 allocs/op
> BenchmarkCmpFixed-8 20   0.38 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkCmpDecimal-8   28.05 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkCmpBigInt-835.87 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkCmpBigFloat-8  35.46 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkStringFixed-8  200057.4 ns/op
> 32 B/op  1 allocs/op
> BenchmarkStringNFixed-8 200055.6 ns/op
> 32 B/op  1 allocs/op
> BenchmarkStringDecimal-81000   218 ns/op  
> 64 B/op  5 allocs/op
> BenchmarkStringBigInt-8 1000   122 ns/op  
> 24 B/op  2 allocs/op
> BenchmarkStringBigFloat-8300   416 ns/op 
> 192 B/op  8 allocs/op
> BenchmarkWriteTo-8  300045.8 ns/op
> 18 B/op  0 allocs/op
>
>
> and version 1.21.5:
>
> BenchmarkAddFixed-8 10   0.9735 ns/op 
>  0 B/op  0 allocs/op
> BenchmarkAddDecimal-8   1431199569.99 ns/op   
> 80 B/op  2 allocs/op
> BenchmarkAddBigInt-81   13.42 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkAddBigFloat-8  1750670263.84 ns/op   
> 48 B/op  1 allocs/op
> BenchmarkMulFixed-8 3139831043.732 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkMulDecimal-8   1804652066.59 ns/op   
> 80 B/op  2 allocs/op
> BenchmarkMulBigInt-81   10.79 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkMulBigFloat-8  4918602424.30 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkDivFixed-8 3068880693.721 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkDivDecimal-82510688   462.4 ns/op   
> 384 B/op 12 allocs/op
> BenchmarkDivBigInt-83399382237.02 ns/op   
>  8 B/op  1 allocs/op
> BenchmarkDivBigFloat-8   9415330   111.5 ns/op
> 24 B/op  2 allocs/op
> BenchmarkCmpFixed-8 10   0.2548 ns/op 
>  0 B/op  0 allocs/op
> BenchmarkCmpDecimal-8   1687145497.086 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkCmpBigInt-82348956344.952 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkCmpBigFloat-8  2608144644.503 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkStringFixed-8  2372547050.57 ns/op   
> 24 B/op  1 allocs/op
> BenchmarkStringNFixed-8 232850.67 ns/op  

Re: [go-nuts] Re: <-ctx.Done() panic - link injecting bot?

[Steven Hartland]

Ah in the web UI, just did the same, hopeful more reports will cause it to
be actioned.

On Sat, 30 Mar 2024 at 10:44, 'Brian Candler' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I clicked the "Report message" button for each of them, selecting type of
> abuse "Spam". Whether anyone reads these is doubtful though.
>
> The first spam was on 3 Jan 2024 and I reported it straight away; it
> hasn't stopped the new ones coming through.
>
> On Saturday 30 March 2024 at 10:21:18 UTC Steven Hartland wrote:
>
>> Johans account looks like a bot designed to inject links, possibly
>> malicious, is there an admin who can investigate and take the appropriate
>> action?
>>
>>
>> On Fri, 29 Mar 2024 at 12:11, Johan Liebert  wrote:
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/750cf63f-625a-4655-9905-fb544850674en%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/750cf63f-625a-4655-9905-fb544850674en%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAA38pebT%2BJdbzxLK_c7NWXNFwD5MQgQHpMqcf01VckGMh8MPPg%40mail.gmail.com.

Re: [go-nuts] Re: <-ctx.Done() panic - link injecting bot?

[Steven Hartland]

Johans account looks like a bot designed to inject links, possibly
malicious, is there an admin who can investigate and take the appropriate
action?


On Fri, 29 Mar 2024 at 12:11, Johan Liebert 
wrote:

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

Re: [go-nuts] Data structure code review

[Steven Hartland]

Some feedback:
Instead of errors.New(emptyDataStructureMessage("stack")) use an
emptyDataError type, where it implements the error interface by adding an
Error() string method, for example:

type emptyDataError string

func (e emptyDataError) Error() string {
return fmt.Sprintf("not empty %s expected", name)
}

Don't ignore errors like you have here as that can lead to
unexpected behavior, in your case a panic if you use those methods..
pushCommand, _ := 


On Sun, 3 Mar 2024 at 21:25, Miss Adorable 
wrote:

> Hi! I wrote
> 
> my first data structure in Go. I wonder how idiomatic my code is to enhance
> it. Previously, I had C# and Java experience.
>
>
> --
> 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/34b9d900-7571-45d1-ae75-21a021d4c75fn%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/CAA38peYisEwEsTdm-8pB8UmuxaDA6rbxn2DPpSSMdvUXP1%2B7Gg%40mail.gmail.com.

Re: [go-nuts] help

[Steven Hartland]

What’s your DATABASE_URL? If your on Windows make sure you use localhost
not 127.0.0.1 as they aren’t necessarily the same thing

On Sun, 18 Feb 2024 at 04:54, Sunday Ajayi  wrote:

> Hi guys,
> Please I am having a little issue with my go project using docker.
>
> I set up my Postgres db in docker with my go app but it is unable to
> connect. Please what could be the issue?
>
> I will share the docker-compose file and the main.go here
>
> main.go
>
> package main
>
> import (
> "database/sql"
> "encoding/json"
> "log"
> "net/http"
> "os"
>
> "github.com/gorilla/mux"
> _ "github.com/lib/pq"
> )
>
> type User struct {
> ID int `json:"id"`
> Name string `json:"name"`
> Email string `json:"email"`
> }
>
> var db *sql.DB
> var err error
>
> func main() {
> //connect to database
> db, err = sql.Open("postgres", os.Getenv("DATABASE_URL"))
> log.Println("DATABASE_URL:", os.Getenv("DATABASE_URL"))
>
> if err != nil {
> log.Fatal("Error connecting to database: ", err)
> }
> if db != nil {
> log.Println("Database connected")
> }
> if err := db.Ping(); err != nil {
> log.Fatal("Error pinging database: ", err)
> }
>
> defer db.Close()
>
> //create the table if it doesn't exist
> _, err = db.Exec("CREATE TABLE IF NOT EXISTS users (id SERIAL PRIMARY
> KEY, name TEXT, email TEXT)")
>
> if err != nil {
> log.Fatal("Error creating table: ", err)
> }
>
> //create router
> router := mux.NewRouter()
> router.HandleFunc("/users", getUsers(db)).Methods("GET")
> router.HandleFunc("/users/{id}", getUser(db)).Methods("GET")
> router.HandleFunc("/users", createUser(db)).Methods("POST")
> router.HandleFunc("/users/{id}", updateUser(db)).Methods("PUT")
> router.HandleFunc("/users/{id}", deleteUser(db)).Methods("DELETE")
>
> //start server
> log.Fatal(http.ListenAndServe(":8088", jsonContentTypeMiddleware(router)))
> }
>
> func jsonContentTypeMiddleware(next http.Handler) http.Handler {
> return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
> w.Header().Set("Content-Type", "application/json")
> next.ServeHTTP(w, r)
> })
> }
>
> // get all users
> func getUsers(db *sql.DB) http.HandlerFunc {
> return func(w http.ResponseWriter, r *http.Request) {
> rows, err := db.Query("SELECT * FROM users")
> if err != nil {
> log.Fatal(err)
> }
> defer rows.Close()
>
> users := []User{}
> for rows.Next() {
> var u User
> if err := rows.Scan(, , ); err != nil {
> log.Fatal(err)
> }
> users = append(users, u)
> }
> if err := rows.Err(); err != nil {
> log.Fatal(err)
> }
>
> json.NewEncoder(w).Encode(users)
> }
> }
>
> // get user by id
> func getUser(db *sql.DB) http.HandlerFunc {
> return func(w http.ResponseWriter, r *http.Request) {
> vars := mux.Vars(r)
> id := vars["id"]
>
> var u User
> err := db.QueryRow("SELECT * FROM users WHERE id = $1", id).Scan(, 
> ,
> )
> if err != nil {
> w.WriteHeader(http.StatusNotFound)
> return
> }
>
> json.NewEncoder(w).Encode(u)
> }
> }
>
> // create user
> func createUser(db *sql.DB) http.HandlerFunc {
> return func(w http.ResponseWriter, r *http.Request) {
> var u User
> json.NewDecoder(r.Body).Decode()
>
> err := db.QueryRow("INSERT INTO users (name, email) VALUES ($1, $2)
> RETURNING id", u.Name, u.Email).Scan()
> if err != nil {
> log.Fatal(err)
> }
>
> json.NewEncoder(w).Encode(u)
> }
> }
>
> // update user
> func updateUser(db *sql.DB) http.HandlerFunc {
> return func(w http.ResponseWriter, r *http.Request) {
> var u User
> json.NewDecoder(r.Body).Decode()
>
> vars := mux.Vars(r)
> id := vars["id"]
>
> _, err := db.Exec("UPDATE users SET name = $1, email = $2 WHERE id = $3",
> u.Name, u.Email, id)
> if err != nil {
> log.Fatal(err)
> }
>
> json.NewEncoder(w).Encode(u)
> }
> }
>
> // delete user
> func deleteUser(db *sql.DB) http.HandlerFunc {
> return func(w http.ResponseWriter, r *http.Request) {
> vars := mux.Vars(r)
> id := vars["id"]
>
> var u User
> err := db.QueryRow("SELECT * FROM users WHERE id = $1", id).Scan(, 
> ,
> )
> if err != nil {
> w.WriteHeader(http.StatusNotFound)
> return
> } else {
> _, err := db.Exec("DELETE FROM users WHERE id = $1", id)
> if err != nil {
> //todo : fix error handling
> w.WriteHeader(http.StatusNotFound)
> return
> }
>
> json.NewEncoder(w).Encode("User deleted")
> }
> }
> }
>
>
> Docker compose file:
>
> version: '3.9'
>
> services:
> go-app:
> container_name: go-app
> image: sunnex/go-app:1.0.0
> build: .
> environment:
> - DATABASE_URL="host=go_db port=5432 user=postgres password=postgres
> dbname=go_db sslmode=disable"
> ports:
> - "8088:8088"
> networks:
> - backend
> depends_on:
> - go_db
> go_db:
> container_name: go_db
> image: postgres:13
> environment:
> POSTGRES_USER: postgres
> POSTGRES_PASSWORD: postgres
> POSTGRES_DB: go_db
> ports:
> - "5432:5432"
> networks:
> - backend
> volumes:
> - pgdata:/var/lib/postgresql/data
>
> volumes:
> pgdata: {}
>
> networks:
> backend:
> driver: bridge
>
> Keep getting this error:
> Error pinging database: *dial tcp 127.0.0.1:5432 :
> connect: connection refused*
>
>
> Please where 

Re: [go-nuts] Re: help with thread limit

[Steven Hartland]

Ignore that as it just triggers a panic if the limit is exceeded, however
based on that I'm guessing it's not going to be possible.

On Thu, 1 Feb 2024 at 19:01, Steven Hartland 
wrote:

> Sounds sensible to me.
>
> I haven't read the entire thread, pun intended ;-), so just checking if
> you tried debug.SetMaxThreads
> <https://pkg.go.dev/runtime/debug#SetMaxThreads>?
>
>
> On Thu, 1 Feb 2024 at 16:42, Steve Roth  wrote:
>
>> Fair question.  In their view, 25 threads per user is a sensible limit.
>> Their mindset is based around single-threaded PHP.  And for that reason
>> among others, yes, switching providers is definitely something I will
>> pursue.  But that will be a long-term effort.  Right now I'm looking for a
>> short-term solution to get my site back up.
>>
>> Thanks,
>> Steve
>>
>> On Thu, Feb 1, 2024 at 8:34 AM Steven Hartland 
>> wrote:
>>
>>> To be honest I would question if its a usable solution if they are
>>> limiting that low on threads, so is the fix to switch or have the provider
>>> increase the limit to a sensible number?
>>>
>>> On Thu, 1 Feb 2024 at 16:08, Steve Roth  wrote:
>>>
>>>> Thanks to the people who suggested how to limit the number of apparent
>>>> cores.  Unfortunately, doing that didn't solve the problem.  I have the
>>>> number of cores now limited to two — confirmed by checking runtime.NumCPU()
>>>> — but the program is still trying to allocate more than 25 threads, and
>>>> crashing when cgroups won't let it.
>>>>
>>>> Surely there must be some way to get a Go program to run successfully
>>>> in an environment with process limits?  Any further suggestions would be
>>>> greatly appreciated.
>>>>
>>>> Regards,
>>>> Steve
>>>>
>>>>
>>>> On Wed, Jan 31, 2024 at 6:43 PM Steve Roth 
>>>> wrote:
>>>>
>>>>> I am running Go code on a shared web hosting server from a major
>>>>> hosting company.  Using cgroups, they limit the number of threads any user
>>>>> can create to 25.  Up until a week ago, they had me running on a server
>>>>> with 24 cores, and everything worked fine.  Now they've moved me to a new
>>>>> server with 128 cores.  The Go runtime thinks it should be able to create
>>>>> that many threads, and it can't, and all of my Go programs crash with,
>>>>> "runtime: failed to create new OS thread".
>>>>>
>>>>> Setting GOMAXPROCS doesn't help this, since it only controls the
>>>>> number of active threads, not the total number of threads.  The Go runtime
>>>>> still thinks it can create as many threads as there are cores, and crashes
>>>>> the program when it's blocked from doing so.
>>>>>
>>>>> Is there any way around this?  Or is Go just completely unusable in an
>>>>> environment where the per-user process limit is less than the number of
>>>>> cores?
>>>>>
>>>>> Many thanks,
>>>>> Steve
>>>>>
>>>>>
>>>>> --
>>>> 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/CAAnpqKEzZcFxDkG2Qtzf25hPwkZq2EstbDbYtBz4CtTaBQxqWA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/CAAnpqKEzZcFxDkG2Qtzf25hPwkZq2EstbDbYtBz4CtTaBQxqWA%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

-- 
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/CAA38pea4tD4vhtO4j-YhCM1T0x0y2nm3439%3DagnLP%3D5SF1VHLg%40mail.gmail.com.

Re: [go-nuts] Re: help with thread limit

[Steven Hartland]

Sounds sensible to me.

I haven't read the entire thread, pun intended ;-), so just checking if you
tried debug.SetMaxThreads <https://pkg.go.dev/runtime/debug#SetMaxThreads>?


On Thu, 1 Feb 2024 at 16:42, Steve Roth  wrote:

> Fair question.  In their view, 25 threads per user is a sensible limit.
> Their mindset is based around single-threaded PHP.  And for that reason
> among others, yes, switching providers is definitely something I will
> pursue.  But that will be a long-term effort.  Right now I'm looking for a
> short-term solution to get my site back up.
>
> Thanks,
> Steve
>
> On Thu, Feb 1, 2024 at 8:34 AM Steven Hartland 
> wrote:
>
>> To be honest I would question if its a usable solution if they are
>> limiting that low on threads, so is the fix to switch or have the provider
>> increase the limit to a sensible number?
>>
>> On Thu, 1 Feb 2024 at 16:08, Steve Roth  wrote:
>>
>>> Thanks to the people who suggested how to limit the number of apparent
>>> cores.  Unfortunately, doing that didn't solve the problem.  I have the
>>> number of cores now limited to two — confirmed by checking runtime.NumCPU()
>>> — but the program is still trying to allocate more than 25 threads, and
>>> crashing when cgroups won't let it.
>>>
>>> Surely there must be some way to get a Go program to run successfully in
>>> an environment with process limits?  Any further suggestions would be
>>> greatly appreciated.
>>>
>>> Regards,
>>> Steve
>>>
>>>
>>> On Wed, Jan 31, 2024 at 6:43 PM Steve Roth 
>>> wrote:
>>>
>>>> I am running Go code on a shared web hosting server from a major
>>>> hosting company.  Using cgroups, they limit the number of threads any user
>>>> can create to 25.  Up until a week ago, they had me running on a server
>>>> with 24 cores, and everything worked fine.  Now they've moved me to a new
>>>> server with 128 cores.  The Go runtime thinks it should be able to create
>>>> that many threads, and it can't, and all of my Go programs crash with,
>>>> "runtime: failed to create new OS thread".
>>>>
>>>> Setting GOMAXPROCS doesn't help this, since it only controls the number
>>>> of active threads, not the total number of threads.  The Go runtime still
>>>> thinks it can create as many threads as there are cores, and crashes the
>>>> program when it's blocked from doing so.
>>>>
>>>> Is there any way around this?  Or is Go just completely unusable in an
>>>> environment where the per-user process limit is less than the number of
>>>> cores?
>>>>
>>>> Many thanks,
>>>> Steve
>>>>
>>>>
>>>> --
>>> 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/CAAnpqKEzZcFxDkG2Qtzf25hPwkZq2EstbDbYtBz4CtTaBQxqWA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/golang-nuts/CAAnpqKEzZcFxDkG2Qtzf25hPwkZq2EstbDbYtBz4CtTaBQxqWA%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/CAA38peYmwZ6U7_Y5aV9zMDHc_5TKGmOLn6dwy%3DwKPNrNwy%3Dfag%40mail.gmail.com.

Re: [go-nuts] Re: help with thread limit

[Steven Hartland]

To be honest I would question if its a usable solution if they are limiting
that low on threads, so is the fix to switch or have the provider increase
the limit to a sensible number?

On Thu, 1 Feb 2024 at 16:08, Steve Roth  wrote:

> Thanks to the people who suggested how to limit the number of apparent
> cores.  Unfortunately, doing that didn't solve the problem.  I have the
> number of cores now limited to two — confirmed by checking runtime.NumCPU()
> — but the program is still trying to allocate more than 25 threads, and
> crashing when cgroups won't let it.
>
> Surely there must be some way to get a Go program to run successfully in
> an environment with process limits?  Any further suggestions would be
> greatly appreciated.
>
> Regards,
> Steve
>
>
> On Wed, Jan 31, 2024 at 6:43 PM Steve Roth  wrote:
>
>> I am running Go code on a shared web hosting server from a major hosting
>> company.  Using cgroups, they limit the number of threads any user can
>> create to 25.  Up until a week ago, they had me running on a server with 24
>> cores, and everything worked fine.  Now they've moved me to a new server
>> with 128 cores.  The Go runtime thinks it should be able to create that
>> many threads, and it can't, and all of my Go programs crash with, "runtime:
>> failed to create new OS thread".
>>
>> Setting GOMAXPROCS doesn't help this, since it only controls the number
>> of active threads, not the total number of threads.  The Go runtime still
>> thinks it can create as many threads as there are cores, and crashes the
>> program when it's blocked from doing so.
>>
>> Is there any way around this?  Or is Go just completely unusable in an
>> environment where the per-user process limit is less than the number of
>> cores?
>>
>> Many thanks,
>> Steve
>>
>>
>> --
> 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/CAAnpqKEzZcFxDkG2Qtzf25hPwkZq2EstbDbYtBz4CtTaBQxqWA%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/CAA38peZRd9uKHa49Lz22u40jJqULJz9FKNEqYztiSg%2Bmh57moQ%40mail.gmail.com.

Re: [go-nuts] Disable false positive go vet check in tests per line?

[Steven Hartland]

Thanks Kurtis, that's a good workaround :)

On Sun, 28 Jan 2024 at 21:24, Kurtis Rader  wrote:

> What happens if you just alias the var?
>
> argsCopy := args
> fmt.Printf("%v\n", argsCopy)
>
>
> On Sun, Jan 28, 2024 at 12:13 PM Steven Hartland <
> stevenmhartl...@gmail.com> wrote:
>
>> When running a test I'm getting:
>> missing ... in args forwarded to print-like function
>>
>> Usually this would be helpful as the pass in variadic should generally be
>> expanded with ... but in this case I specifically want the result of args 
>> passed
>> as a slice.
>>
>> Is there a way to disable go vet checks for tests on a line by line basis
>> like what would do with golangci-lint //nocheck: ?
>>
>>   Regards
>>   Steve
>>
>> --
>> 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/CAA38peaR%3DhFQPv3cCcDndfsEkqkM-X5s8rC1H%2BeOzAJ3ijhqPQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAA38peaR%3DhFQPv3cCcDndfsEkqkM-X5s8rC1H%2BeOzAJ3ijhqPQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/CAA38peaPxDtF_%2BB9sMhXGM-fsXujcz0WHoyUOfJG9%3DooAQypVA%40mail.gmail.com.

[go-nuts] Disable false positive go vet check in tests per line?

[Steven Hartland]

When running a test I'm getting:
missing ... in args forwarded to print-like function

Usually this would be helpful as the pass in variadic should generally be
expanded with ... but in this case I specifically want the result of
args passed
as a slice.

Is there a way to disable go vet checks for tests on a line by line basis
like what would do with golangci-lint //nocheck: ?

  Regards
  Steve

-- 
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/CAA38peaR%3DhFQPv3cCcDndfsEkqkM-X5s8rC1H%2BeOzAJ3ijhqPQ%40mail.gmail.com.

Re: [go-nuts] Re: Good examples of Go back ends?

[Steven Hartland]

It's high level, but there's some good stuff mentioned in
https://github.com/avelino/awesome-go

On Mon, 22 Jan 2024 at 15:23, george looshch 
wrote:

> hi Jason,
>
> thanks a million for pointing out the vagueness of my question! English
> isn’t my mother tongue so now i see where you’re coming from
>
> what i meant was examples of real-world web server with routing,
> authentication, DB, etc.
>
> curated lists have libraries and frameworks, what i’m looking for is
> examples of usages these libraries and frameworks in production. Search on
> github didn’t yield any good results, unfortunately
>
> On Monday, January 22, 2024 at 2:13:17 PM UTC Jason E. Aten wrote:
>
>> This question is too vague.
>>
>> You are likely to get more helpful answers if you specify what kind of
>> "backend" you are looking for.  As it is, we can only guess.
>>
>> Do you want backends that are web servers? (see the standard library
>> net/http or the caddy web server)  Is it a backend for iOS iPhone Apps? For
>> Android Apps? That respond to a specific kind of RPC such as gRPC? That
>> simply access a database?...  A relational database? A non-relational
>> database (graph?, vector?, full-text search?)
>>
>> Pocketbase is a backend mentioned recently on hackernews, that is written
>> in Go and seems to do alot.  Perhaps it is similar to firebase, just going
>> by the name. I have not used it myself.  I cannot say whether it is a "good
>> example" or not, because I've not used it, and similarly this is too vague
>> a criteria (good at what?)
>>
>> https://github.com/pocketbase/pocketbase
>>
>> Generally, go over to github and search for the kind of backend you want,
>> and select those projects that are written in Go on the left side filter
>> click-boxes.  You could also look at the curated lists of Go libraries such
>> as https://awesome-go.com/
>>
>> On Sunday, January 21, 2024 at 4:57:42 PM UTC+1 george looshch wrote:
>>
>> hi!
>> can i please ask if someone knows good examples of back ends written in
>> Go? If not good, just production code would be great as well!
>> thanks in advance and have a great rest of the weekend!
>>
>> --
> 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/bcb429bb-4cfb-4421-be4e-b1ffbcd5e228n%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/CAA38peZRPyhoJ0pL8bdQQdv2Sz2sofWgNJUWJan6gVQuhhd8wg%40mail.gmail.com.

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

[Steven Hartland]

poll and select for this behavior was broken in FreeBSD up until 195423
 was committed as detailed by
this bug report .

Given the MacOS and FreeBSD have related history I wouldn't be surprised if
this is a bug in the OS implementation with poll on MacOS.

On Thu, 21 Dec 2023 at 20:21, 'TheDiveO' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> The issue is also reproducible using Python3 on macOS, whereas it works as
> expected once again on Linux; just for reference here's the corresponding SO
> question
> .
> To a large extend, this now excludes potential Go and/or
> Ginkgo/Gomega-related effects, yet is consistent with my original
> observation and question here.
>
> On Sunday, December 17, 2023 at 6:02:17 AM UTC+1 Kurtis Rader wrote:
>
> On Sat, Dec 16, 2023 at 7:54 AM 'TheDiveO' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> [...]
>
> I only glanced at your unit test but the sleeps and goroutines without any
> explicit synchronization (e.g., using a sync.WaitGroup) look to me like a
> source of non-deterministic behavior.
>
> [...]
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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/a7fe0e6e-d6b0-4881-a02c-61516684caf9n%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/CAA38peYhwUEi6n6T624iwbzdrEkVKqZRr31bUMosWj_-RRJz7w%40mail.gmail.com.

Re: [go-nuts] CPU usage increasing day by day because of Cron

[Steven Hartland]

Your use of sync.WaitGroup looks strange. Typically you would expect to
call wg.Add(1) before a goroutine is started, wg.Done() before it returns
and wg.Wait() to ensure all goroutines have completed.
This doesn't seem to be what you're doing.

Consider restructuring to make best use of the goroutines (start them
first) with the WaitGroup being used to detect when they complete
processing all work items.

Other things, your switch on cronType is invariant so could result in
entries added to jobs never being processed hence wg.Wait blocking forever,
might be your leak.

Finally no need for bare return at the end of functions

Hope that helps.

On Mon, 3 Jul 2023 at 04:25, Rohit Rohit  wrote:

> I am running a cron  whose
> code is written in Golang ,and
> i am using mongoDb(version -4.4) as database, the cron runs after every 5
> minutes of interval, i have been noticing that when i start the cron within
> a week the cpu usage hikes from 0 to 60% or even more and i have to restart
> the cron service so that it shouldn’t effect the services of cron later on,
> which means that there’s an memory leak, resources are not being released
> properly, i’m not able to figure out what might be the reason, i have been
> using the single db connection for the whole cron let’s say a single cron
> is being for 2000 merchants. I’m running my cron with Worker pool using
> Buffered Channels. Below is the code which i am using for running my cron
> using worker pool
> func RunCronForDbNames(cronType, subsType string) {
> cronStatus := GetCronStatusConditions(cronType)
> if cronStatus {
> dbNames, _ := controller.GetDbNamesForCron(subsType, cronType)
> if len(dbNames) == 0 {
> return
> }
> client, ctx := ConnectDb("ip")
> defer client.Disconnect(ctx)
> cronDataChannel := make(chan view.CronChannelData, len(dbNames))
> var wg sync.WaitGroup
> startTime := time.Now().Unix()
> var cronChData view.CronChannelData
> cronChData.Database.Client = client
> cronChData.Database.Ctx = ctx
> cronChData.StartTime = startTime
> for _, dbName := range dbNames {
> isContinue := db.CheckGlobalCronStatus(cronType, dbNames)
> if !isContinue {
> continue
> }
> wg.Add(1)
> contextKeys := make(map[string]interface{})
> contextKeys["db_name"] = dbName
> contextKeys["role"] = ""
> var c gin.Context
> c.Keys = make(map[string]any)
> c.Keys = contextKeys
> cronChData.C = c
> cronChData.Database.MainDatabase = dbName
> cronDataChannel <- cronChData
> }
> close(cronDataChannel)
> for w := 1; w <= 10; w++ {
> go Worker(w, cronDataChannel, , cronType)
> }
> wg.Wait()
> }
> return
> }
>
> My worker is running with 10 workers at a time
> func Worker(id int, jobs <-chan view.CronChannelData, wg *sync.WaitGroup,
> cronType string) {
> switch cronType {
> case config.CompleteBookingCron:
> for job := range jobs {
> controller.CompleteBookingsCron(job, wg)
> }
> }
> return
> }
>
> In CompleteBookingsCron, I’m subtracting the WaitGroup using wg.Done() and
> marking the bookings as completed and send mails and Sms to our customers
> based on their settings. For sending Emails and Sms, go-routines are being
> used.
>
> Can someone help me find out what could be the reason for the increasing
> of cpu usage, what things should i follow in order to getting the resources
> freed up properly which should not increase the Cpu usage?
>
> --
> 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/2e700735-7c77-4d4b-95fb-f74599517b3fn%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/CAA38peZwRfdNUYAgho8sjWJXMV1AAAJtT5KW1e5eM7Syhbz0zg%40mail.gmail.com.

Re: [go-nuts] slog - potentially broken test

[Steven Hartland]

Looks like a bug, I suspect because you have a space in the path the path
was quoted breaking the regexp as it's not expecting the final quote.
Try editing the regexp to:
^time=\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}(Z|[+-]\d{2}:\d{2})
level=INFO source=.*logger_test.go:\d{3}"? msg=msg2$

On Mon, 3 Jul 2023 at 02:23, Merrick Clay  wrote:

> When attempting to build from source on Windows, a test in slog fails for
> me every time. Am I doing something wrong or should I file an issue and
> submit a PR to improve this test? The issue seems to be the "source" being
> surrounded by quotes. See details below.
>
> *Test output *(from running all.bat)
> Building Go cmd/dist using C:\Program Files\Go. (go1.20.5 windows/amd64)
> Building Go toolchain1 using C:\Program Files\Go.
> Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
> Building Go toolchain2 using go_bootstrap and Go toolchain1.
> Building Go toolchain3 using go_bootstrap and Go toolchain2.
> Building packages and commands for windows/amd64.
>
> # Test execution environment.
> # GOARCH: amd64
> # CPU: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
> # GOOS: windows
> # OS Version: 10.0.22621
>
> # Testing packages.
> *(other tests)*
>
>
>
> *--- FAIL: TestConnections (0.00s)logger_test.go:109:got
>  time=2023-07-02T18:04:14.412-06:00 level=INFO source="C:/Users/Merrick
> Clay/goprojects/src/goroot/src/log/slog/logger_test.go:108" msg=msg2
> want ^time=\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}(Z|[+-]\d{2}:\d{2})
> level=INFO source=.*logger_test.go:\d{3} msg=msg2$*
> FAIL
> FAILlog/slog1.187s
>
> *go env*
> set GO111MODULE=
> set GOARCH=amd64
> set GOBIN=
> set GOCACHE=C:\Users\Merrick Clay\AppData\Local\go-build
> set GOENV=C:\Users\Merrick Clay\AppData\Roaming\go\env
> set GOEXE=.exe
> set GOEXPERIMENT=
> set GOFLAGS=
> set GOHOSTARCH=amd64
> set GOHOSTOS=windows
> set GOINSECURE=
> set GOMODCACHE=C:\Users\Merrick Clay\goprojects\pkg\mod
> set GONOPROXY=
> set GONOSUMDB=
> set GOOS=windows
> set GOPATH=C:\Users\Merrick Clay\goprojects
> set GOPRIVATE=
> set GOPROXY=https://proxy.golang.org,direct
> set GOROOT=C:\Program Files\Go
> set GOSUMDB=sum.golang.org
> set GOTMPDIR=
> set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
> set GOVCS=
> set GOVERSION=go1.20.5
> set GCCGO=gccgo
> set GOAMD64=v1
> set AR=ar
> set CC=gcc
> set CXX=g++
> set CGO_ENABLED=1
> set GOMOD=C:\Users\Merrick Clay\goprojects\src\goroot\src\go.mod
> set GOWORK=
> set CGO_CFLAGS=-O2 -g
> set CGO_CPPFLAGS=
> set CGO_CXXFLAGS=-O2 -g
> set CGO_FFLAGS=-O2 -g
> set CGO_LDFLAGS=-O2 -g
> set PKG_CONFIG=pkg-config
> set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0
> -fdebug-prefix-map=C:\Users\MERRIC~1\AppData\Local\Temp\go-build60902014=/tmp/go-build
> -gno-record-gcc-switches
>
> --
> 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/0c19486e-2b30-400e-a0da-f9c51e929a6en%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/CAA38peb9_biB9KV8268UPiAX6Jcp_O6q6dbYFewNwx-f5d3pwA%40mail.gmail.com.

[go-nuts] pkg.go.dev down?

[Steven Hartland]

Is there an issue with pkg.go.dev atm as packages are failing to load after
a long time with a 500 error for example time 

-- 
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/CAA38peZuW4xKFqg4iK4_3R3r45XOSgzu9hAjV3ofOB1R9uRTUw%40mail.gmail.com.

Re: [go-nuts] Best way to mark unused parameters/error values reported by linter

[Steven Hartland]

I would use the following if I truly wanted to ignore an error, but I would
question if ignoring the error from os.Open was ever a good idea. If you
want to handle a file not found error then do so, don't just ignore the
error.
file, _ := os.Open(name) //nolint: errcheck

On Mon, 6 Mar 2023 at 20:14, Sergei Dyshel  wrote:

> Hello all,
> I'm incorporating golangci-lint  
> linter
> aggregator in my codebase and facing a dilemma  on how to mark false
> positives for these 2  linters:
>
>- errcheck - reports unchecked errors.
>- unparam - reports unused function parameters.
>
> The "official" way is to use special comment directives that make linter
> ignore the line:
>
> func foo(
> name string,
> //nolint:unparam
> age int,
> ) {
> //nolint:errcheck
> file, _ := os.Open(name)
> 
>
> Another, may be more portable way, would be using special functions which
> do nothing:
>
> // defined in some library utilities package
> func IgnoreErr(err error) {}
> func Unused(a any) {}
>
> func foo(
> name string,
> age int,
> ) {
> Unused(age)
> file, err := os.Open(name)
> IgnoreErr(err)
> ...
>
> What do you think the proper/idiomatic/better way among these two?
>
> --
> 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/6fc8a933-b68c-4e07-a4ee-98c4fe01ba8dn%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/CAA38pebGViygCaqwwMsw3gOnSodQ%3DeDavaaq1V9q%2BASyd2Mbew%40mail.gmail.com.

Re: [go-nuts] go install of forked repo

[Steven Hartland]

Check out go work I achieve it’s exactly what you are looking for, allowing
for projects to use temporary local versions of packages

On Sat, 3 Dec 2022 at 11:55, Duncan Harris  wrote:

> This seems a noddy question but can't easily find an answer with Google
> apparently. I may have lost the plot :-)
>
> There is a repo which contains source for a go executable that I want to
> use.
> Normally I install this with: go install original.domain/path@latest
> I want to fork that repo and make some experimental changes.
> So then I want to: go install my.forked.domain/path@commit
> But if I don't also change the go.mod file in my fork I get something like:
>
> go: downloading my.forked.domain/path v0.0.0-20221203102529-commit
> go: my.forked.domain/path@commit
> : my.forked.domain/path@v0.0.0-20221203102529-commit: parsing go.mod:
> module declares its path as: original.domain/path
> but was required as: my.forked.domain/path
>
> Obviously I could change the go.mod in my fork, but that seems wrong if I
> later want to submit a PR on the original repo.
>
> --
> 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/9a9542bd-1718-4ea7-a0ed-42b343bb9699n%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/CAHEMsqa7HahGdG0-Fz5_WZaVSa90TvFCX0dZ4O4516TP6drB3A%40mail.gmail.com.

Re: [go-nuts] imported and not used "errors"

[Steven Hartland]

Something is already running on localhost port 8080. use a different port.

On Tue, 27 Sept 2022 at 16:15, Conor O'Neill  wrote:

> I am following a tutorial to great an API in Go with a framework called
> Gin.
>
> I have imported errors and created a function like so;
>
> func createBook(c *gin.Context) {
>
>var newBook book
>
>
>
>if err := c.BindJSON(); err != nil {
>
>return
>
>}
>
>
>
>books = append(books, newBook)
>
>c.IndentedJSON(http.StatusCreated, newBook)
>
> }
>
> func main is as follows;
>
> func main() {
>
>//1.router responsible for handling different routes and diff
> endpoints of API
>
>router := gin.Default()
>
>//2.the route we are handling is /books, ie when u go to
> localhost:8080/books it will call getBooks()function
>
>router.GET("/books", getBooks)
>
>router.POST("/books", createBook)
>
>router.Run("localhost:8080")
>
> }
>
> If i simply ignore the import error I get this;
>
> [GIN-debug] Listening and serving HTTP on localhost:8080
>
> [GIN-debug] [ERROR] listen tcp 127.0.0.1:8080: bind: address already in
> use
>
> I've gone over the tutorial several times and I'm not sure how he isn't
> getting the erros.
>
> On another note are there any good recommendations for documentation to
> create an API without a framework?
>
> --
> 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/CAPp9YQWGyicjMrFrMD2yg4Sb%2BLMGFFzGq_aKbRf25iLv2YW1Nw%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/CAHEMsqYXCSdWZTPDGKvgw8he%2Bw0LDOdtPhhDBN%2BRtaCuTwRX4w%40mail.gmail.com.

Re: [go-nuts] How to check Cmd.ProcessState without triggering the race checker?

[Steven Hartland]

Looks like session already has what you need as you can check
if session.Exited has been closed something like:

select {
case <- session.Exited:
  // Handle session has ended
default:
  // Handle session hasn't ended
}

On Sat, 23 Jul 2022 at 21:39, TheDiveO  wrote:

> In my open source file descriptor leak checker (Linux only) for Gomega,
> Go's race detector flags a race condition in my code where I need to
> check whether a Cmd.Process already has terminated
> 
> as its ProcessState has been set.
>
> if session.Command.ProcessState != nil {
> return nil, errors.New("session has already ended")
> }
>
> Now, this check might be called be called from a different Goroutine than
> another Goroutine waiting for the command to exit. In particular, this is
> the (what I consider to be the relevant) output of the race detector:
>
> WARNING: DATA RACE
> Write at 0x00c0002e8208 by goroutine 16:
>   os/exec.(*Cmd).Wait()
>   /home/.../sdk/go1.19rc2/src/os/exec/exec.go:598 +0x1eb
>   github.com/onsi/gomega/gexec.(*Session).monitorForExit()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/gexec/session.go:197 +0x44
>   github.com/onsi/gomega/gexec.Start.func1()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/gexec/session.go:96 +0x47
>
> Previous read at 0x00c0002e8208 by goroutine 12:
>   github.com/thediveo/fdooze/session.FiledescriptorsFor()
>   /home/.../github/fdooze/session/session_fds.go:21 +0x1b7
>   github.com/thediveo/fdooze/session.glob..func1.1.1()
>   /home/.../github/fdooze/session/session_fds_test.go:45 +0x30
>   runtime.call16()
>   /home/.../sdk/go1.19rc2/src/runtime/asm_amd64.s:724 +0x48
>   reflect.Value.Call()
>   /home/.../sdk/go1.19rc2/src/reflect/value.go:368 +0xc7
>   github.com/onsi/gomega/internal.NewAsyncAssertion.func1()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:48 +0x16e
>   github.com/onsi/gomega/internal.(*AsyncAssertion).pollActual()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:132 +0x82
>   github.com/onsi/gomega/internal.(*AsyncAssertion).match()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:162 +0xe4
>   github.com/onsi/gomega/internal.(*AsyncAssertion).ShouldNot()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:112 +0xa9
>   github.com/thediveo/fdooze/session.glob..func1.1()
>   /home/.../github/fdooze/session/session_fds_test.go:65 +0xf41
>   github.com/onsi/ginkgo/v2/internal.(*Suite).runNode.func2()
>   /home/.../go/pkg/mod/
> github.com/onsi/ginkgo/v2@v2.1.4/internal/suite.go:596 +0xea
>
> Is there actually any way to check use Cmd.ProcessState at all from a
> thread different from the one doing a Cmd.Wait? Might this be a design
> "weakness" of the Cmd type in that it doesn't cover such use cases?
>
> Any idea for a work around to find if the command might already have
> (prematurely) finished by the time I try to check for its open file
> descriptors?
>
> --
> 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/8ed84076-b29d-4840-8c15-09621e2fca61n%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/CAHEMsqYuX3SdE%2B9ds_ANkHYa24J7d7PEDLN6Fz9eUjxt5%2BnQxg%40mail.gmail.com.

Re: [go-nuts] Data race in sql package

[Steven Hartland]

I'm guessing that Michal is flagging is there no way to write safe code if
your using stmt.QueryContext(ctx) and rows.Scan into a sql.RawBytes
as QueryContext kicks off a go routine that monitors the ctx, closing rows
if cancelled and that ctx can be cancelled at any time.

The only thing that springs to mind is to only allow the cancellation
processing to happen while in sql functions which would mean that
sql.RawBytes can't be updated while the consumer, user code, is processing
it.

It's interesting that there is a related comment in row.Scan
,
which prevents the use of sql.RawBytes because it always closes the
underlying rows before returning.

On Thu, 21 Jul 2022 at 20:02, Ian Lance Taylor  wrote:

> On Thu, Jul 21, 2022 at 11:02 AM Michal Hruby 
> wrote:
> >
> > Hello, I have a code snippet equivalent to this one:
> >
> > rows, err := stmt.QueryContext(ctx)
> > if err != nil {
> > return info, nil, err
> > }
> > defer rows.Close()
> >
> > var data sql.RawBytes
> > for rows.Next() {
> > err = rows.Scan()
> > if err != nil {
> > return nil, err
> > }
> > // if ctx is canceled around this point, rows.Close() will be called
> and the data can e overwritten, causing a data race
> > _ = data[0] // <--- possible concurrent read here and write inside
> driver.Rows.Close()
> > }
> >
> > And as the comments say, if the context is cancelled, there's a
> possibility of a data race where this goroutine is trying to read data[0],
> and another goroutine can be writing to it, cause the sql package calls
> driver.Rows.Close() (from
> https://github.com/golang/go/blob/176b63e7113b82c140a4ecb2620024526c2c42e3/src/database/sql/sql.go#L2974
> )
> >
> > I've opened an issue about this on github (
> https://github.com/golang/go/issues/53970 ), but was told that's not the
> proper forum to talk about data races.
> >
> > Any help would be appreciated, thanks.
>
> I don't quite understand what you are asking.  I think you're correct
> that there is a data race there.  It seems to me that the answer is to
> not cancel the context.
>
> What kind of answer are you looking for?
>
> 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/CAOyqgcUwGN5b-DEwCqLRu6kWwpAnCvO7o6u5TjzS3bmbUgksdw%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/CAHEMsqYKu5wNtZybfNzz4xbBmfZOCDew6zo-v5R8QDsDH%3D43Ug%40mail.gmail.com.

Re: [go-nuts] how to minimize the size of struct?

[Steven Hartland]

https://pkg.go.dev/reflect#Type.Size or https://pkg.go.dev/unsafe#Sizeof

On Wed, 13 Jul 2022 at 08:00, xie cui  wrote:

>
> https://github.com/orijtech/structslop/blob/13637e228c1a50d8444da1b71a83aff3b6536851/structslop.go#L246-L267
> why sort by  can minimize the sizeof
> struct?
> is there some formal prove?
>
> --
> 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/11d1b26a-b090-4462-a6c0-c04054ca1789n%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/CAHEMsqain0U%3D2DZ%2B2bXnpZexp%2BO%3DUa3Y%2BwjW13Qk7eX5O_PUsg%40mail.gmail.com.

Re: [go-nuts] Re: No downloadable go1.18.1 version for darwin

[Steven Hartland]

Looks like this is fixed now.

On Wed, 13 Apr 2022 at 15:48, Brian Candler  wrote:

> It's mentioned in the original announcement
> :
>
> "macOS binary artifacts for Go 1.18.1 are not available at this time due
> to an issue .
> We are working on providing them as soon as possible. Sorry for the
> inconvenience."
>
> On Wednesday, 13 April 2022 at 15:33:44 UTC+1 Yulrizka wrote:
>
>> I see from release history that go.1.18.1 was released yesterday.
>>
>> But it seems that the download page does not contain package for darwin
>> like previous version
>>
>> This command also failed
>>
>> go1.18.1 download
>> go1.18.1: download failed: no binary release of go1.18.1 for darwin/amd64
>> at https://dl.google.com/go/go1.18.1.darwin-amd64.tar.gz
>>
> --
> 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/8240a867-23d1-48be-9096-340e357edb9en%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/CAHEMsqa6VuPE3e9c%3Dx-j%2BoxBxOGMMFuby99NBmQKVTo2%2B6BL-A%40mail.gmail.com.

Re: [go-nuts] encoding/json mistakenly transfer int64 format to string

[Steven Hartland]

First off, the package you're using for redis isn't maintained; you should
switch to github.com/gomodule/redigo/redis instead, which will allow you to
remove the c == nil check as that doesn't happen.

In your example you're ignoring error from json.Marshal which could be
hiding a problem, so I would recommend you handle that.

encoding/json should represent float as a json number so I would never
expect what you're seeing but its not clear to me if that is down to how
you are viewing it.

On Tue, 12 Apr 2022 at 04:02, Zhaoxun Yan  wrote:

> The scenario is upon receiving an incoming financial quotation, save it as
> a string of json into a Redis service. Sorry but I cannot provide the whole
> code of quotation receiving here, which is very complex with cgo. But the
> code below will help you get a glimpse on what should be going on:
>
> import (
> "encoding/json"
> //"errors"
> "fmt"
> "time"
>
> "github.com/garyburd/redigo/redis"
> )
>
> var pool *redis.Pool
>
> type Fvprices struct {
> P float64 `json:"price"`
> F float64 `json:"floor"`
> C float64 `json:"ceiling"`
> S float64 `json:"settle"`
> T int64   `json:"time"`
> }
>
> func init() {
> pool = newPool()
> }
>
> var redisport = "6379"
> var redisip = "127.0.0.1"
> var password = ""
>
> func newPool() *redis.Pool {
>
> fmt.Println("redis @", redisport, redisip, password)
> return {
> MaxIdle: 4,
> MaxActive:   50, // max number of connections
> IdleTimeout: 30 * time.Second,
>
> Dial: func() (redis.Conn, error) {
> c, err := redis.DialURL("redis://" + redisip + ":" +
> redisport)
> if err != nil {
> ErrMsg = fmt.Sprintf("redis connection error: %s", err.
> Error())
> fmt.Println(time.Now().Format("2006-01-02 15:04:05"),
> ErrMsg)
> return nil, err
> }
> if _, autherr := c.Do("AUTH", password); autherr != nil {
> ErrMsg = fmt.Sprintf("redis password error: %s", err.Error
> ())
> fmt.Println(time.Now().Format("2006-01-02 15:04:05"),
> ErrMsg)
> return nil, autherr
> }
> return c, nil
> },
> }
> }
>
> func Upfutureprice(future_id string,
> future_price, lowerLimitPrice, upperLimitPrice, preSettlementPrice
> float64,
> updatetime time.Time) {
>
> c := pool.Get()
> if c == nil {
> return
> }
> defer c.Close()
>
> content := Fvprices{
> P: future_price,
> F: lowerLimitPrice,
> C: upperLimitPrice,
> S: preSettlementPrice,
> T: updatetime.UnixNano() / 1e6,
> }
>
> js, _ := json.Marshal(content)
>
> if _, err := c.Do("SET", future_id, js); err != nil {
> fmt.Println("cannot save to redis：", err)
> }
> }
>
> So obviously until the function "Upfutureprice" everything is correct,
> for all  four prices it receives are in float64 format. After running this
> program for one day, I just browse the redis using
> AnotherRedisDesktopManager via ssh port forwarding, and something strange
> happens as I clicking on various future_id key strings:
>
> {
> price:807
> floor:720.6
> ceiling:881
> settle:"800.80001"
> time:1649726499000
> }
>
> {
> price:"3691.5"
> floor:3237
> ceiling:4204
> settle:3721
> time:1649726910500
> }
>
> {
> price:"15405.0004"
> floor:13625
> ceiling:17340
> settle:15485
> time:1649728303500
> }
>
> {
> price:"800.40001"
> floor:720.6
> ceiling:881
> settle:"800.80001"
> time:1649728048000
> }
>
> Note quotations above. I wonder how encoding/json can made transformation
> from a float64 inside struct Fvprices  to a string instead? It seems that
> only long decimals would trigger such an error while short decimals won't:
>
> {
> price:2910
> floor:2443.5
> ceiling:3305.5
> settle:2874.5
> time:1649728261026
> }
>
> How could that happen? I am really puzzled.
>
> Regards,
> Zhaoxun
>
> --
> 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/f42b29b3-de17-48c6-9f71-1176f1288396n%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/CAHEMsqb24d5B4NxzeaCNdR%2B_%3DQgxbyGJSsSgjS8jyQa%3DQFHmgg%40mail.gmail.com.

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

[Steven Hartland]

No problem, there's a nice little write up on it stackoverflow
<https://stackoverflow.com/questions/47645808/how-does-select-work-when-multiple-channels-are-involved>
.

On Mon, 28 Mar 2022 at 17:41, Gowtham Raj  wrote:

> Hello Steven,
>
> Wow, this solved the problem. Never saw this pattern before. Thanks for
> your help !!
> If you have any reference material for further reading for patterns like
> this can you please share them.
>
> Regards,
> Gowtham
>
> On Mon, 28 Mar 2022 at 12:21, Steven Hartland 
> wrote:
>
>> There is no guarantee that the select chooses the done case, so you need
>> to check in work case as well e.g.
>> https://go.dev/play/p/zAj_qfO4uMA
>>
>> On Mon, 28 Mar 2022 at 16:54, Gowtham Raj  wrote:
>>
>>> In this example, we have a *worker*. The idea here is simulate clean
>>> shutdown of all go routines based on a condition.
>>>
>>> In this case, go routines get spun - based on workers count. Each go
>>> routine reads the channel, does some work and sends output to the
>>> outputChannel.
>>>
>>> The main go routine reads this output and prints it. To simulate a stop
>>> condition, the doneChannel is closed. Expected outcome is that select inside
>>> each go routine will pick this up and execute return which in turn will
>>> call the defer println. The actual output is that it never gets called
>>> and main exits.
>>>
>>> Not sure what's the reason behind this.
>>>
>>> Code at *https://go.dev/play/p/-R7Llw9X_6U
>>> <https://go.dev/play/p/-R7Llw9X_6U> *
>>>
>>> Can you please help to figure out the bug in this code.
>>>
>>> --
>>> 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/3762b074-63c5-407e-9515-6833465dc94en%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/3762b074-63c5-407e-9515-6833465dc94en%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/CAHEMsqYrJv%3D-Gc8E0Z9hqodsqgso_2wgbVt9jmOhsORgQvGcaQ%40mail.gmail.com.

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

[Steven Hartland]

There is no guarantee that the select chooses the done case, so you need to
check in work case as well e.g.
https://go.dev/play/p/zAj_qfO4uMA

On Mon, 28 Mar 2022 at 16:54, Gowtham Raj  wrote:

> In this example, we have a *worker*. The idea here is simulate clean
> shutdown of all go routines based on a condition.
>
> In this case, go routines get spun - based on workers count. Each go
> routine reads the channel, does some work and sends output to the
> outputChannel.
>
> The main go routine reads this output and prints it. To simulate a stop
> condition, the doneChannel is closed. Expected outcome is that select inside
> each go routine will pick this up and execute return which in turn will
> call the defer println. The actual output is that it never gets called
> and main exits.
>
> Not sure what's the reason behind this.
>
> Code at *https://go.dev/play/p/-R7Llw9X_6U
>  *
>
> Can you please help to figure out the bug in this code.
>
> --
> 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/3762b074-63c5-407e-9515-6833465dc94en%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/CAHEMsqbQdAHfJ1hCyd7y_KFNeWKUMQpKLywruqs06vD64NaY6w%40mail.gmail.com.

Re: [go-nuts] Re: Advise about using go mod retract to fix pre go mod v2.0.0 tag

[Steven Hartland]

Thanks Zik, looks this worked as go list -m -versions
github.com/gomodule/redigo now returns the expected versions:
github.com/gomodule/redigo v1.7.0 v1.7.1 v1.7.2 v1.8.0 v1.8.1 v1.8.2 v1.8.3
v1.8.4 v1.8.5 v1.8.6 v1.8.7

On Mon, 3 Jan 2022 at 02:41, Zik Aeroh  wrote:

> I don't think you need to do anything with the "real" v2. The way I
> visualize this is to think of "v0+v1", "v2", "v3", and so on as completely
> different modules; they have entirely different names by SIV.
>
> The version "v2.0.1+incompatible" would be imported as "
> github.com/gomodule/redigo", same as a v0 or v1; they have the same name.
> The "real" v2 would be "github.com/gomodule/redigo/v2", which you can
> only get from a "real" v2 tag, not any pre-modules tag (which require that
> there is no "/v2" suffix, for compatibility with old code).
>
> Therefore, the Go toolchain will go look at whatever is latest for "
> github.com/gomodule/redigo", then use the retractions there. It won't
> look for "github.com/gomodule/redigo/v2".
> On Friday, December 31, 2021 at 1:37:34 PM UTC-8 Steven Hartland wrote:
>
>> Thanks Zik, not clear if I still need to publish v2.0.1 to retract
>> v2.0.0+incompatible given the comments in
>> https://play-with-go.dev/retract-module-versions_go116_en/
>>
>> To retract v1.0.0 you will need to publish v1.0.1. But that means you
>>> will *also* need to retract version v1.0.1.
>>
>>
>> I wonder if Jay or someone else could clarify the v2.0.0+incompatible
>> case?
>>
>> On Mon, 6 Dec 2021 at 06:21, Zik Aeroh  wrote:
>>
>>> Unless I'm mistaken, you should be retracting "v2.0.0+incompatible", as
>>> that's the actual version known to the Go tool. Retracting "v2.0.0" would
>>> be valid if you were retracting in the "github.com/gomodule/redigo/v2"
>>> module, which it sounds like you aren't.
>>>
>>> You wouldn't want to publish v2.0.1 to fix this; the latest version of
>>> the "github.com/gomodule/redigo" module will be checked for
>>> retractions, and that would be in the v1 series (no v# in the URL, so must
>>> be v0 or v1).
>>>
>>> On Friday, December 3, 2021 at 6:53:04 AM UTC-8 Steven Hartland wrote:
>>>
>>>> One of the golang packages I maintain redigo had a v2.0.0 tag created
>>>> before the introduction of go mod and this still causes challenges today.
>>>>
>>>> A kind soul pointed <https://github.com/gomodule/redigo/issues/585>
>>>> out go mod retract <https://go.dev/ref/mod#go-mod-file-retract> the
>>>> other day in the hope that this could help solve the problem. From what
>>>> I've read it does seem like this is the case and that creating a v2.0.1 tag
>>>> which includes
>>>>
>>>> retract (
>>>> v2.0.0 // Published accidentally.
>>>> v2.0.1 // Contains retractions only.
>>>> )
>>>>
>>>> To be clear the go mod compatible structure of v2.0.0 was never
>>>> created hence v2.0.0 is listed as incompatible e.g.
>>>>
>>>> go list -m -versions
>>>> github.com/gomodule/redigo v0.0.0-do-not-use v1.7.0 v1.7.1 v1.7.2
>>>> v1.8.0 v1.8.1 v1.8.2 v1.8.3 v1.8.4 v1.8.5 v1.8.6 v2.0.0+incompatible
>>>>
>>>> This could help but my concern is if this doesn't work it could make
>>>> matters worse, so wanted to see if anyone could advise on this process?
>>>>
>>>>Regards
>>>>Steve
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/d7715c26-8b96-4b35-a069-5d638ba2d6a4n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/d7715c26-8b96-4b35-a069-5d638ba2d6a4n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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/98df8e56-d897-41fd-b884-44d65ad4760fn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/98df8e56-d897-41fd-b884-44d65ad4760fn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAHEMsqYb66_zmf545rHkKLz%3Dz5CR7zZBydjGTb4CTv23U4%3Dn3g%40mail.gmail.com.

Re: [go-nuts] Re: Advise about using go mod retract to fix pre go mod v2.0.0 tag

[Steven Hartland]

Thanks Zik, not clear if I still need to publish v2.0.1 to retract
v2.0.0+incompatible given the comments in
https://play-with-go.dev/retract-module-versions_go116_en/

To retract v1.0.0 you will need to publish v1.0.1. But that means you will
> *also* need to retract version v1.0.1.


I wonder if Jay or someone else could clarify the v2.0.0+incompatible case?

On Mon, 6 Dec 2021 at 06:21, Zik Aeroh  wrote:

> Unless I'm mistaken, you should be retracting "v2.0.0+incompatible", as
> that's the actual version known to the Go tool. Retracting "v2.0.0" would
> be valid if you were retracting in the "github.com/gomodule/redigo/v2"
> module, which it sounds like you aren't.
>
> You wouldn't want to publish v2.0.1 to fix this; the latest version of the
> "github.com/gomodule/redigo" module will be checked for retractions, and
> that would be in the v1 series (no v# in the URL, so must be v0 or v1).
>
> On Friday, December 3, 2021 at 6:53:04 AM UTC-8 Steven Hartland wrote:
>
>> One of the golang packages I maintain redigo had a v2.0.0 tag created
>> before the introduction of go mod and this still causes challenges today.
>>
>> A kind soul pointed <https://github.com/gomodule/redigo/issues/585> out go
>> mod retract <https://go.dev/ref/mod#go-mod-file-retract> the other day
>> in the hope that this could help solve the problem. From what I've read it
>> does seem like this is the case and that creating a v2.0.1 tag which
>> includes
>>
>> retract (
>> v2.0.0 // Published accidentally.
>> v2.0.1 // Contains retractions only.
>> )
>>
>> To be clear the go mod compatible structure of v2.0.0 was never created
>> hence v2.0.0 is listed as incompatible e.g.
>>
>> go list -m -versions
>> github.com/gomodule/redigo v0.0.0-do-not-use v1.7.0 v1.7.1 v1.7.2 v1.8.0
>> v1.8.1 v1.8.2 v1.8.3 v1.8.4 v1.8.5 v1.8.6 v2.0.0+incompatible
>>
>> This could help but my concern is if this doesn't work it could make
>> matters worse, so wanted to see if anyone could advise on this process?
>>
>>Regards
>>Steve
>>
> --
> 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/d7715c26-8b96-4b35-a069-5d638ba2d6a4n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/d7715c26-8b96-4b35-a069-5d638ba2d6a4n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAHEMsqaPiA%3DZ8MqJ5yNe-MTXu96B2ovuEC%3DWJH8oENkNHKtTuA%40mail.gmail.com.

[go-nuts] Advise about using go mod retract to fix pre go mod v2.0.0 tag

[Steven Hartland]

One of the golang packages I maintain redigo had a v2.0.0 tag created
before the introduction of go mod and this still causes challenges today.

A kind soul pointed  out go
mod retract  the other day in
the hope that this could help solve the problem. From what I've read it
does seem like this is the case and that creating a v2.0.1 tag which
includes

retract (
v2.0.0 // Published accidentally.
v2.0.1 // Contains retractions only.
)

To be clear the go mod compatible structure of v2.0.0 was never created
hence v2.0.0 is listed as incompatible e.g.

go list -m -versions
github.com/gomodule/redigo v0.0.0-do-not-use v1.7.0 v1.7.1 v1.7.2 v1.8.0
v1.8.1 v1.8.2 v1.8.3 v1.8.4 v1.8.5 v1.8.6 v2.0.0+incompatible

This could help but my concern is if this doesn't work it could make
matters worse, so wanted to see if anyone could advise on this process?

   Regards
   Steve

-- 
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/CAHEMsqaXKVNCYXja7GbKhOp7UvH2J3TBpyZe4r%3DB92wbFhVyCw%40mail.gmail.com.

Re: [go-nuts] Re: pkg.go.dev jump to broken?

[Steven Hartland]

Didn't touch anything on my side and it's working again today, error has
gone from the console as well, so can only assume someone fixed something.

Thanks for feedback Brian :)

   Regards
   Steve

On Tue, 16 Nov 2021 at 20:44, Brian Candler  wrote:

> Works for me: Chrome 96.0.4664.45, macOS 10.14.6
>
> --
> 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/6b1f490d-3625-4ca6-9a0e-0d0459f2c631n%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/CAHEMsqbGUubgH5KFT7e0GTxfkuEkbrBhBsqC8Raqd-pVeLKkWg%40mail.gmail.com.

[go-nuts] pkg.go.dev jump to broken?

[Steven Hartland]

Clicking the jump to or pressing F on pkg.go.dev seems to be broken here.

In Chrome console I'm seeing security warning about eval, which could be
the cause:
Content Security Policy of your site blocks the use of 'eval' in JavaScript`
The Content Security Policy (CSP) prevents the evaluation of arbitrary
strings as JavaScript to make it more difficult for an attacker to inject
unathorized code on your site.
To solve this issue, avoid using eval(), new Function(),
setTimeout([string], ...) and setInterval([string], ...) for evaluating
strings.
If you absolutely must: you can enable string evaluation by adding
unsafe-eval as an allowed source in a script-src directive.
⚠️ Allowing string evaluation comes at the risk of inline script injection.
1 directive
Source Location Directive Status
gtm.js?id=GTM-W8MVQXG:3 script-src blocked
Learn more: Content Security Policy - Eval

-- 
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/CAHEMsqYytzG7DbQ4AJGYTTd24Miu%3D%3D%3Dk%2BEgwOOZ4WZwZYqVmiA%40mail.gmail.com.

[go-nuts] Re: Help getting database/sql pooling merged

[Steven Hartland]

Just a quick bump to see if we can get this over the line in time for the
1.18 release freeze in just a couple of days time?

On Sat, 23 Oct 2021 at 00:29, Steven Hartland 
wrote:

> There's been a long standing bug
> <https://github.com/golang/go/issues/39471> in database/sql pooling which
> means SetConnMaxIdleTime doesn't work.
>
> I found and fixed the bug
> <https://go-review.googlesource.com/c/go/+/237337> back in June of 2020,
> but have so far been unable to get this relatively simple fix across the
> line.
>
> With 1.18 freeze fast approaching, I'd love to get this merged before then
> so we can have working DB pooling without having to run a patched core
> library.
>
> Others have looked at it in the past and said the fix looks good, and
> we've been running it for well over a year now, so I would say confidence
> is high ;-)
>
> So any help to get it merged would be most appreciated!
>
>Regards
>Steve
>

-- 
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/CAHEMsqY3DLqKdT0%3DEMmJUwz-BNxydvRVKH19yfk7UR41zE6Oyg%40mail.gmail.com.

[go-nuts] Help getting database/sql pooling merged

[Steven Hartland]

There's been a long standing bug 
in database/sql pooling which means SetConnMaxIdleTime doesn't work.

I found and fixed the bug 
back in June of 2020, but have so far been unable to get this relatively
simple fix across the line.

With 1.18 freeze fast approaching, I'd love to get this merged before then
so we can have working DB pooling without having to run a patched core
library.

Others have looked at it in the past and said the fix looks good, and we've
been running it for well over a year now, so I would say confidence is high
;-)

So any help to get it merged would be most appreciated!

   Regards
   Steve

-- 
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/CAHEMsqamkJagp0gk2d61At6kHxWQwJJXQw-dqDgP9v-ic0NNjw%40mail.gmail.com.

Re: [go-nuts] ast.NewPackage errors for built in types

[Steven Hartland]

Thanks for that. I spent some time over the weekend refactoring from raw ast
<https://pkg.go.dev/go/ast> parser with a simpleImporter and universe to
using types <https://pkg.go.dev/go/types>.

So far this has provided everything I need, and also massively simplified
the code as no need to manually parse the ast.File apart from a basic
ast.Visitor <https://pkg.go.dev/go/ast#Visitor> to create a lookup map for
type comments and position information.

I did find the types docs <https://pkg.go.dev/go/types> less consumable
than the ast docs <https://pkg.go.dev/go/ast> as the relationship between
the various types and the data in types.Info
<https://pkg.go.dev/go/types#Info> wasn't particularly clear to me even
after reading the tutorial <https://golang.org/s/types-tutorial>. This
resulted in it taking quite a bit of trial and error, which I didn't need
with raw ast. However once I combined an ast.Visitor
<https://pkg.go.dev/go/ast#Visitor> and a pass over info.Defs to create a
type name map I had most of all the elements.

Getting the type name from types.Info <https://pkg.go.dev/go/types#Info>
map had me scratching my head for some time as I couldn't believe that the
Types field wouldn't have an easy way to get to the name of the type.

Using types Config.Check <https://pkg.go.dev/go/types#Config.Check> didn't
have any performance penalties that I saw with packages.Load
<https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages#Load> so I'm
hopeful that this is the correct route.

I'd love to hear if there is a neat way to get from info.Types to the name
of each type without having to process info.Defs first, but that's more to
know if missed something obvious or not 

Thanks again to everyone who has provided pointers in this thread, as it
demonstrates what great community this is!

On Sun, 17 Oct 2021 at 22:16, K. Alex Mills  wrote:

> I'm guessing here, but you probably do need the full type-checker for
> that, depending on what you mean by "a native type".
>
> In go we can alias types in two ways.
>
> type A uint8
> type B = uint8
>
> There are subtle differences between the two which I don't claim to
> understand... In any case, AFAIK both are essentially built-in types at
> runtime.
>
> Suppose these types are declared in a third-party package on GitHub and
> another package uses A and B (since they're exported) to declare a struct
> like this.
>
> import "github.com/foo/bar"
>
> type MyStruct struct {
>   Byte1 bar.A
>   Byte2 bar.B
> }
>
> AFAIK, the compiler cannot tell whether Byte1 and Byte2 are builtin types
> or a struct without seeing their definition hosted on GitHub. Which means
> downloading, parsing, and type-checking the code from GitHub.
>
> But it gets a little worse. Type-checking the remote code entails
> downloading any of its dependencies recursively and doing the same thing...
> I'm sure you can see how this can take some time -- especially for large
> projects.
>
> Anyway, it sounds to me like what you're asking to do requires the use of
> the type-checker and because of the dependency management involved I
> believe the most convenient route to type-checking (at this time) lives in
> the packages package.
>
> Happy to learn if anyone else knows otherwise.
>
> On Sun, Oct 17, 2021, 5:00 AM Steven Hartland 
> wrote:
>
>> I need to be able to tell the types of fields, in particular are fields
>> of a struct a native type or a struct themselves.
>>
>> The ast parse even with a simple importer don’t provide that info.
>>
>> On Sat, 16 Oct 2021 at 21:06, 'Richard Oudkerk' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> I am not sure what "import external packages" means.
>>>
>>> Apart dot imports (which I have never seen used for real) why would you
>>> need to load the imported packages?
>>>
>>> On Saturday, 16 October 2021 at 20:34:17 UTC+1 Steven Hartland wrote:
>>>
>>>> Thanks Richard, that allowed me to replace a hand rolled
>>>> universe scope 
>>>>
>>>> My importer varies from yours in that for correct lookups for versioned
>>>> packages or those with '-' in I had to copy ImportPathToAssumedName
>>>> from x/tools/internal/imports/fix.go.
>>>>
>>>> func simpleImporter(imports map[string]*ast.Object, path string)
>>>> (*ast.Object, error) {
>>>> pkg := imports[path]
>>>> if pkg == nil {
>>>> pkg = ast.NewObj(ast.Pkg, ImportPathToAssumedName(path))
>>>> pkg.Data = ast.NewScope(nil) // required by
>>>> ast.NewP

Re: [go-nuts] ast.NewPackage errors for built in types

[Steven Hartland]

I need to be able to tell the types of fields, in particular are fields of
a struct a native type or a struct themselves.

The ast parse even with a simple importer don’t provide that info.

On Sat, 16 Oct 2021 at 21:06, 'Richard Oudkerk' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I am not sure what "import external packages" means.
>
> Apart dot imports (which I have never seen used for real) why would you
> need to load the imported packages?
>
> On Saturday, 16 October 2021 at 20:34:17 UTC+1 Steven Hartland wrote:
>
>> Thanks Richard, that allowed me to replace a hand rolled universe scope 
>>
>> My importer varies from yours in that for correct lookups for versioned
>> packages or those with '-' in I had to copy ImportPathToAssumedName from
>> x/tools/internal/imports/fix.go.
>>
>> func simpleImporter(imports map[string]*ast.Object, path string)
>> (*ast.Object, error) {
>> pkg := imports[path]
>> if pkg == nil {
>> pkg = ast.NewObj(ast.Pkg, ImportPathToAssumedName(path))
>> pkg.Data = ast.NewScope(nil) // required by
>> ast.NewPackage for dot-import
>> imports[path] = pkg
>> }
>> return pkg, nil
>> }
>>
>> This now works for all cases which don't import external packages. So now
>> I just need to do the on demand load of packages, which I suspect will lead
>> me right back to packages.Load.
>>
>> On Sat, 16 Oct 2021 at 15:59, 'Richard Oudkerk' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> You could try building the universe scope for ast.NewPackage from
>>> types.Universe.  For example
>>>
>>> https://play.golang.org/p/1E5Iu4vW3g9
>>>
>>> func NewPackage(fset *token.FileSet, files map[string]*ast.File)
>>> (*ast.Package, error) {
>>> univ, err := universe()
>>> if err != nil {
>>> return nil, err
>>> }
>>> return ast.NewPackage(fset, files, dummyImporter, univ)
>>> }
>>>
>>> func dummyImporter(imports map[string]*ast.Object, importPath string)
>>> (*ast.Object, error) {
>>> pkg := imports[importPath]
>>> if pkg == nil {
>>> pkg = ast.NewObj(ast.Pkg, path.Base(importPath))
>>> pkg.Data = ast.NewScope(nil)
>>> imports[importPath] = pkg
>>> }
>>> return pkg, nil
>>> }
>>>
>>> func universe() (*ast.Scope, error) {
>>> u := ast.NewScope(nil)
>>> for _, name := range types.Universe.Names() {
>>> o := types.Universe.Lookup(name)
>>> if o == nil {
>>> return nil, fmt.Errorf("failed to lookup %s in universe scope", name)
>>> }
>>> var objKind ast.ObjKind
>>> switch o.(type) {
>>> case *types.Const, *types.Nil:
>>> objKind = ast.Con
>>> case *types.TypeName:
>>> objKind = ast.Typ
>>> case *types.Builtin:
>>> objKind = ast.Fun
>>> default:
>>> return nil, fmt.Errorf("unexpected builtin %s of type %T", o.Name(), o)
>>> }
>>> obj := ast.NewObj(objKind, name)
>>> if u.Insert(obj) != nil {
>>> return nil, fmt.Errorf("types internal error: double declaration")
>>> }
>>> obj.Decl = u
>>> }
>>> return u, nil
>>> }
>>>
>>> On Saturday, 16 October 2021 at 14:38:43 UTC+1 eli...@gmail.com wrote:
>>>
>>>> On Fri, Oct 15, 2021 at 2:13 PM Steven Hartland 
>>>> wrote:
>>>>
>>>>> I converted my code to x/tools/go/packages
>>>>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> and while
>>>>> it did solve the problem it's VERY slow in comparison.
>>>>>
>>>>> I have a set of 21 tests operating on a single package which has at
>>>>> most two very basic types, no imports and using go/parser
>>>>> <https://pkg.go.dev/go/parser> they take 0.011s but with go/packages
>>>>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> that
>>>>> increases to 3.548s a 300x slow down.
>>>>>
>>>>> I'm setting a basic mode: packages.NeedName | packages.NeedSyntax
>>>>>
>>>>> The package.Load call takes ~220ms whereas ast.NewPackage only
>>>>> takes 2.7µs.
>>>>>
>>>>
>>>> Could you post a reproducer of your target package and analysis
>>>> somewhere? 220ms for packages.Load sounds like a lot. It's true that
>&

Re: [go-nuts] ast.NewPackage errors for built in types

[Steven Hartland]

Thanks Richard, that allowed me to replace a hand rolled universe scope 

My importer varies from yours in that for correct lookups for versioned
packages or those with '-' in I had to copy ImportPathToAssumedName from
x/tools/internal/imports/fix.go.

func simpleImporter(imports map[string]*ast.Object, path string)
(*ast.Object, error) {
pkg := imports[path]
if pkg == nil {
pkg = ast.NewObj(ast.Pkg, ImportPathToAssumedName(path))
pkg.Data = ast.NewScope(nil) // required by ast.NewPackage
for dot-import
imports[path] = pkg
}
return pkg, nil
}

This now works for all cases which don't import external packages. So now I
just need to do the on demand load of packages, which I suspect will lead
me right back to packages.Load.

On Sat, 16 Oct 2021 at 15:59, 'Richard Oudkerk' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> You could try building the universe scope for ast.NewPackage from
> types.Universe.  For example
>
> https://play.golang.org/p/1E5Iu4vW3g9
>
> func NewPackage(fset *token.FileSet, files map[string]*ast.File)
> (*ast.Package, error) {
> univ, err := universe()
> if err != nil {
> return nil, err
> }
> return ast.NewPackage(fset, files, dummyImporter, univ)
> }
>
> func dummyImporter(imports map[string]*ast.Object, importPath string)
> (*ast.Object, error) {
> pkg := imports[importPath]
> if pkg == nil {
> pkg = ast.NewObj(ast.Pkg, path.Base(importPath))
> pkg.Data = ast.NewScope(nil)
> imports[importPath] = pkg
> }
> return pkg, nil
> }
>
> func universe() (*ast.Scope, error) {
> u := ast.NewScope(nil)
> for _, name := range types.Universe.Names() {
> o := types.Universe.Lookup(name)
> if o == nil {
> return nil, fmt.Errorf("failed to lookup %s in universe scope", name)
> }
> var objKind ast.ObjKind
> switch o.(type) {
> case *types.Const, *types.Nil:
> objKind = ast.Con
> case *types.TypeName:
> objKind = ast.Typ
> case *types.Builtin:
> objKind = ast.Fun
> default:
> return nil, fmt.Errorf("unexpected builtin %s of type %T", o.Name(), o)
> }
> obj := ast.NewObj(objKind, name)
> if u.Insert(obj) != nil {
> return nil, fmt.Errorf("types internal error: double declaration")
> }
> obj.Decl = u
> }
> return u, nil
> }
>
> On Saturday, 16 October 2021 at 14:38:43 UTC+1 eli...@gmail.com wrote:
>
>> On Fri, Oct 15, 2021 at 2:13 PM Steven Hartland 
>> wrote:
>>
>>> I converted my code to x/tools/go/packages
>>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> and while it
>>> did solve the problem it's VERY slow in comparison.
>>>
>>> I have a set of 21 tests operating on a single package which has at most
>>> two very basic types, no imports and using go/parser
>>> <https://pkg.go.dev/go/parser> they take 0.011s but with go/packages
>>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> that
>>> increases to 3.548s a 300x slow down.
>>>
>>> I'm setting a basic mode: packages.NeedName | packages.NeedSyntax
>>>
>>> The package.Load call takes ~220ms whereas ast.NewPackage only
>>> takes 2.7µs.
>>>
>>
>> Could you post a reproducer of your target package and analysis
>> somewhere? 220ms for packages.Load sounds like a lot. It's true that
>> packages does a lot more work than just the parser (*), but it's not
>> supposed to be that slow. In my tests a simple Load with more functionality
>> takes 60-70ms
>>
>> (*) The type checking takes a bit of time over just parsing to AST, but
>> the biggest difference is loading multiple files from imports. For type
>> checking you need to know, when you see:
>>
>> import foo
>>
>> x := foo.Foo()
>>
>> What the type of `x` is, so go/packages has to analyze the `foo` package
>> as well.
>>
>>
>>
>>>
>>> As the resulting ast.File's are pretty much the same, I'm wondering if
>>> for my use case packages.Load is doing way more than I need?
>>>
>>> Another downside is for tests run in a temporary directory outside of
>>> the package space package.Load fails with:
>>> directory /tmp/tests76985775 outside available modules
>>>
>>> I fixed it by calling ioutil.TempDir with "." but that's not ideal.
>>>
>>> Thoughts?
>>>
>>> On Tue, 12 Oct 2021 at 13:42, Steven Hartland 
>>> wrote:
>>>
>>>> Thanks David, much appreciated, I will have a look at both.
>>>>
>>>> When migrating from go/ast to go/types did you hit a

Re: [go-nuts] ast.NewPackage errors for built in types

[Steven Hartland]

This is an example of code resulting in ~200ms.

This was measured on a laptop with i7-7700HQ under WSL2, so that could be a
contributing factor.

package mypkg

type MyType struct {
String string
}

On Sat, 16 Oct 2021 at 14:38, Eli Bendersky  wrote:

>
>
> On Fri, Oct 15, 2021 at 2:13 PM Steven Hartland 
> wrote:
>
>> I converted my code to x/tools/go/packages
>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> and while it
>> did solve the problem it's VERY slow in comparison.
>>
>> I have a set of 21 tests operating on a single package which has at most
>> two very basic types, no imports and using go/parser
>> <https://pkg.go.dev/go/parser> they take 0.011s but with go/packages
>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> that
>> increases to 3.548s a 300x slow down.
>>
>> I'm setting a basic mode: packages.NeedName | packages.NeedSyntax
>>
>> The package.Load call takes ~220ms whereas ast.NewPackage only
>> takes 2.7µs.
>>
>
> Could you post a reproducer of your target package and analysis somewhere?
> 220ms for packages.Load sounds like a lot. It's true that packages does a
> lot more work than just the parser (*), but it's not supposed to be that
> slow. In my tests a simple Load with more functionality takes 60-70ms
>
> (*) The type checking takes a bit of time over just parsing to AST, but
> the biggest difference is loading multiple files from imports. For type
> checking you need to know, when you see:
>
> import foo
>
> x := foo.Foo()
>
> What the type of `x` is, so go/packages has to analyze the `foo` package
> as well.
>
>
>
>>
>> As the resulting ast.File's are pretty much the same, I'm wondering if
>> for my use case packages.Load is doing way more than I need?
>>
>> Another downside is for tests run in a temporary directory outside of the
>> package space package.Load fails with:
>> directory /tmp/tests76985775 outside available modules
>>
>> I fixed it by calling ioutil.TempDir with "." but that's not ideal.
>>
>> Thoughts?
>>
>> On Tue, 12 Oct 2021 at 13:42, Steven Hartland 
>> wrote:
>>
>>> Thanks David, much appreciated, I will have a look at both.
>>>
>>> When migrating from go/ast to go/types did you hit anything of note I
>>> should look out for?
>>>
>>> On Mon, 11 Oct 2021 at 17:06, David Finkel 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 11, 2021 at 5:48 AM Steven Hartland 
>>>> wrote:
>>>>
>>>>> If the ast.Files passed to ast.NewPackage includes built in types such
>>>>> as int it returns an error e.g.
>>>>> file1.go:5:6: undeclared name: int
>>>>>
>>>>> Is there a way to prevent that?
>>>>>
>>>>
>>>> Generally, I always add the `builtin` package to the list of packages
>>>> I'm parsing.
>>>> I wrote a little library for exactly this kind of package loading a few
>>>> years ago:
>>>> https://gitlab.com/dfinkel/goastpkg/-/blob/master/go_ast_parser.go
>>>> (https://pkg.go.dev/golang.spin-2.net/astpkg)
>>>>
>>>>>
>>>>> Playground example: https://play.golang.org/p/Yg30TTzoLHP
>>>>>
>>>>> My goal is to take multiple files, resolve inter file dependencies
>>>>> e.g. a type referencing another type in a different file and process the
>>>>> resulting ast.Files. So if there is a better way to achieve this I'm all
>>>>> ears.
>>>>>
>>>>
>>>> In general, I've stopped using the `go/ast` internal references as much
>>>> and have started using resolved `go/types` references as they're more
>>>> reliable and better-specified.
>>>> (golang.org/x/tools/go/packages
>>>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> has a
>>>> LoadMode flag for generating `go/types.Info` (NeedTypesInfo
>>>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages#NeedTypesInfo>
>>>> ))
>>>>
>>>>>
>>>>>Regards
>>>>>Steve
>>>>>
>>>>> --
>>>>> 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.
>>

Re: [go-nuts] ast.NewPackage errors for built in types

[Steven Hartland]

I converted my code to x/tools/go/packages
<https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> and while it did
solve the problem it's VERY slow in comparison.

I have a set of 21 tests operating on a single package which has at most
two very basic types, no imports and using go/parser
<https://pkg.go.dev/go/parser> they take 0.011s but with go/packages
<https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> that increases
to 3.548s a 300x slow down.

I'm setting a basic mode: packages.NeedName | packages.NeedSyntax

The package.Load call takes ~220ms whereas ast.NewPackage only takes 2.7µs.

As the resulting ast.File's are pretty much the same, I'm wondering if for
my use case packages.Load is doing way more than I need?

Another downside is for tests run in a temporary directory outside of the
package space package.Load fails with:
directory /tmp/tests76985775 outside available modules

I fixed it by calling ioutil.TempDir with "." but that's not ideal.

Thoughts?

On Tue, 12 Oct 2021 at 13:42, Steven Hartland 
wrote:

> Thanks David, much appreciated, I will have a look at both.
>
> When migrating from go/ast to go/types did you hit anything of note I
> should look out for?
>
> On Mon, 11 Oct 2021 at 17:06, David Finkel  wrote:
>
>>
>>
>> On Mon, Oct 11, 2021 at 5:48 AM Steven Hartland 
>> wrote:
>>
>>> If the ast.Files passed to ast.NewPackage includes built in types such
>>> as int it returns an error e.g.
>>> file1.go:5:6: undeclared name: int
>>>
>>> Is there a way to prevent that?
>>>
>>
>> Generally, I always add the `builtin` package to the list of packages I'm
>> parsing.
>> I wrote a little library for exactly this kind of package loading a few
>> years ago:
>> https://gitlab.com/dfinkel/goastpkg/-/blob/master/go_ast_parser.go
>> (https://pkg.go.dev/golang.spin-2.net/astpkg)
>>
>>>
>>> Playground example: https://play.golang.org/p/Yg30TTzoLHP
>>>
>>> My goal is to take multiple files, resolve inter file dependencies e.g.
>>> a type referencing another type in a different file and process the
>>> resulting ast.Files. So if there is a better way to achieve this I'm all
>>> ears.
>>>
>>
>> In general, I've stopped using the `go/ast` internal references as much
>> and have started using resolved `go/types` references as they're more
>> reliable and better-specified.
>> (golang.org/x/tools/go/packages
>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> has a
>> LoadMode flag for generating `go/types.Info` (NeedTypesInfo
>> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages#NeedTypesInfo>
>> ))
>>
>>>
>>>Regards
>>>Steve
>>>
>>> --
>>> 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/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/golang-nuts/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/CAHEMsqYMSBUfuOUvptv6UrvBFTwFxjOhJZ5sMN-omOx5ESL5hw%40mail.gmail.com.

Re: [go-nuts] ast.NewPackage errors for built in types

[Steven Hartland]

Thanks David, much appreciated, I will have a look at both.

When migrating from go/ast to go/types did you hit anything of note I
should look out for?

On Mon, 11 Oct 2021 at 17:06, David Finkel  wrote:

>
>
> On Mon, Oct 11, 2021 at 5:48 AM Steven Hartland 
> wrote:
>
>> If the ast.Files passed to ast.NewPackage includes built in types such as
>> int it returns an error e.g.
>> file1.go:5:6: undeclared name: int
>>
>> Is there a way to prevent that?
>>
>
> Generally, I always add the `builtin` package to the list of packages I'm
> parsing.
> I wrote a little library for exactly this kind of package loading a few
> years ago:
> https://gitlab.com/dfinkel/goastpkg/-/blob/master/go_ast_parser.go
> (https://pkg.go.dev/golang.spin-2.net/astpkg)
>
>>
>> Playground example: https://play.golang.org/p/Yg30TTzoLHP
>>
>> My goal is to take multiple files, resolve inter file dependencies e.g. a
>> type referencing another type in a different file and process the resulting
>> ast.Files. So if there is a better way to achieve this I'm all ears.
>>
>
> In general, I've stopped using the `go/ast` internal references as much
> and have started using resolved `go/types` references as they're more
> reliable and better-specified.
> (golang.org/x/tools/go/packages
> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages> has a LoadMode
> flag for generating `go/types.Info` (NeedTypesInfo
> <https://pkg.go.dev/golang.org/x/tools@v0.1.7/go/packages#NeedTypesInfo>))
>
>>
>>Regards
>>Steve
>>
>> --
>> 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/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAHEMsqavYgUqPOBo6zB5SsizVB39JO9vNUePnecDN-664e0NUQ%40mail.gmail.com.

[go-nuts] ast.NewPackage errors for built in types

[Steven Hartland]

If the ast.Files passed to ast.NewPackage includes built in types such as
int it returns an error e.g.
file1.go:5:6: undeclared name: int

Is there a way to prevent that?

Playground example: https://play.golang.org/p/Yg30TTzoLHP

My goal is to take multiple files, resolve inter file dependencies e.g. a
type referencing another type in a different file and process the resulting
ast.Files. So if there is a better way to achieve this I'm all ears.

   Regards
   Steve

-- 
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/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%40mail.gmail.com.

Re: [go-nuts] What is the point of gzip Reader.Close?

[Steven Hartland]

Internally close calls z.decompressor.Close() where decompressor is
typically obtained via flat.NewReader(r) which states

NewReader returns a new ReadCloser that can be used to read the
uncompressed version of r. If r does not also implement io.ByteReader, the
decompressor may read more data than necessary from r. It is the caller's
responsibility to call Close on the ReadCloser when finished reading.

The ReadCloser returned by NewReader also implements Resetter.

It's been some time now but I'm pretty sure I've seen gzip Reader fail
silently when the Close error wasn't correctly checked, so there is a good
reason why you should not only call Close but also confirm it returns nil.

On Mon, 21 Jun 2021 at 23:44, Steven Penny  wrote:

> >> - https://golang.org/pkg/compress/flate
> >>
> >> - https://golang.org/pkg/compress/lzw
> >> - https://golang.org/pkg/compress/zlib
> >
> > All of these do.
>
> whoops, yeah thats true. However my original point still stands. Three
> people
> have replied now:
>
> - Axel Wagner
> - Bruno Albuquerque
> - Dan Kortschak
>
> and none has been able to provide a simple program that demonstrate a
> problem
> that could arise from not closing gzip reader. So I am confident for now at
> least that its not needed.
>
> --
> 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/CAP8dQmsmqFqOu-iS9-e%3D3FZimG4nybdwM-d53JccaCuGoXJjRg%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/CAHEMsqZ97VQQqnJo5d-VjY9-YWuJoSxMtMnvg%2Be4dGq%2BjCrPtg%40mail.gmail.com.

Re: [go-nuts] no generic ?

[Steven Hartland]

The proposal to add generics to go has been accepted and it is due to be
added in v1.18

On Sun, 21 Feb 2021 at 21:02, alex-coder  wrote:

> Hi all !
> I'm just a beginner in Golang and I see a discussion in regards to
> introduce generics into Go.
> But is it possible to provide an example where it is impossible to use
> interface instead of generic ?
> Thank you in advance.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e0139450-f753-4921-ba6f-fd0b252c525cn%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/CAHEMsqbsvbvLxSx9YWd5GZXX%2BLD8KJxE3h_Zx8zAg%3DXK3XQ4dA%40mail.gmail.com.

Re: [go-nuts] When set time.Location, will be detected Data Race

[Steven Hartland]

Always serialise t.UTC()?

On 24/07/2020 04:26, Mike Cohen wrote:
To be clear, the time.MarshalJSON() function produces valid RFC 3339 
timestamps which allow arbitrary timezones. This means that local time 
offset is used in the string representation. Although all 
representations are technically equivalent their string form is not so 
we need to do special parsing to compare them (and users get really 
confused as well).


Here is an example -
https://play.golang.org/p/hELVEI1tGJd

when I run it I get {"A":6,"B":"2009-11-11T10:00:00+11:00"}  for 
Australia time, but

 {"A":6,"B":"2009-11-10T18:00:00-05:00"} for America/New_York.

I am aware I can use the .In() method to cast the time.Time object 
into different timezone but this is the whole issue - I need to search 
through all the struct fields, expand slices, recurse through maps etc 
just to find any time.Time objects and change them **before** I call 
json.Marshal().


I usually get the times from a struct in another library so I have no 
control over how these times are made for example consider this

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

where I call an out of tree library to build a struct then just want 
to dump it - I have no control over the encoding.


I think this is a actually a limitation in the json strategy of 
encoding based only on types and not on context. The TZ issue is just 
a manifestation of that - even if there was a safe way to set TZ in a 
running program, in a multithreaded program all json encoders would be 
forced to use the same local TZ because encoding goes with type and 
not with context.


Thanks.
Mike


On Thu, 2020-07-23 at 20:02 -0700, Ian Lance Taylor wrote:

On Thu, Jul 23, 2020 at 5:13 PM Michael Cohen <
scude...@gmail.com

> wrote:

Thanks Ian, this does not work as I mentioned because there is no way to 
guarantee that my init function will run before any of my libraries creating a 
time object (which many do as they start various background tasks).
Doing what you say is fragile because even if it appears to work, one day I 
might link a library and it will mysteriously break randomly (this happened to 
us previously).
Is this a bug in the time package? Or simply a bug or design shortfall in the 
json package? One way I thought to fix this issue is to simply fork the json 
encoder and handle time.Time structs specifically, but this obviously does not 
scale to eg yaml encoders etc.

I don't think it's a shortfall in the encoding/json package as such,
as that package knows nothing about times.  It's the time package that
implements an UnmarshalJSON.  Looking at that method, I'm a little
surprised at what you describe, since it just uses the timezone in the
JSON string.  It doesn't use the local timezone as far as I can see.
Can you show a small program that demonstrates the problem?
Ian

--

*Mike Cohen*
/Digital Paleontologist/

Velocidex Enterprises
https://www.velocidex.com

+61.470238491


--
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/55b1098d4ff2518143b249b4587b36b527797896.camel%40velocidex.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/d1075c07-991e-2506-29a1-7847df4cda66%40multiplay.co.uk.

Re: [go-nuts] Re: Variadic Arguments and Interfaces

[Steven Hartland]

Did you use the correct calling convension e.g.
db.Query(query, cond...)

The ... makes the slice variadic, passing echData.Active, exchData.Role 
instead of just a interface slice


On 17/05/2020 23:27, Saied Seghatoleslami wrote:
I hate to dig up something from 2012, but I have come across a similar 
issue where I can use an explanation.  The signature of the Query 
function in the sql package is:


|
func (db *DB  )Query(query string  
,args ...interface{})(*Rows  
,error  )
|

so, one would assume that passing something like this  for args would 
work (Active is bool and Role is a string:


|
varcond =[]interface{}{exchData.Active,exchData.Role}
|

but it does not, it results in this error:

|

sql:converting argument $1 type:unsupported type []interface{},a slice 
of interface


|

I suspect there is a good explanation for this that I do not get.



On Friday, September 7, 2012 at 4:45:07 PM UTC-4, Paddy Foran wrote:

Consider the following:

In package fmt: func Println(a …interface{})

One would think the following code would work:

func main() {
testslice := []string { "this", "is", "a", "test" }
fmt.Println(testslice…)
}

One would subsequently be met with "cannot use testslice (type
[]string) as type []interface {} in function argument"
(http://play.golang.org/p/H3349TDJnS
)

On the other hand, if one were to try:

func print(words …string) {
for _, word := range words {
fmt.Printf("%s", word)
}
}

func main() {
testslice := []string { "this", "is", "a", "test" }
print(testslice…)
}

Everything works as expected (http://play.golang.org/p/1ZnIwge19V
). Can anyone explain why the
empty interface in variadic parameters prevents me from using
argument expansion?

God, I hope I used the right names for all these things.

--
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/1cc28db0-98c6-49cd-bd3e-7752ef2b5328%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/04082c78-b064-24a7-08e2-16bec1ac690d%40multiplay.co.uk.

Re: [go-nuts] Too many open files / broken pipe issue.

[Steven Hartland]

Few things which may help:
1. Use pprof to look at goroutines, see if you have a leak there.
2. What does linux utility lsof say?

Don't forget that each network connection uses a "file" so it may not be 
a real file hand instead a network socket, which given your screen shot 
could be due to network disconnects.


    Regards
    Steve

On 08/05/2020 22:51, Juhee LR wrote:

Hello ,

I am currently working for a company and one of our site is having 
little trouble. It is built in golang . I am facing this particular 
issue for over 3 months now. No matter what solution i've tried so far 
, it ends up failing. So the site is working fine , but somewhere due 
to the code there is some kind of leak which is causing open files not 
being closed and due to that server crashes and the site goes down 
until IT restarts. So i've so far tried to deal with "defer" and 
removed all the defer in code without return type. There is nothing we 
have not closed. Also increased server ulimit for soft and hard files 
. Still randomly site breaks down with "too many open file" error or 
"broken pipe" .

Here is the go env :
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/juhi/Library/Caches/go-build"
GOENV="/Users/juhi/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/juhi/go/"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct;
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics 
-Qunused-arguments -fmessage-length=0 
-fdebug-prefix-map=/var/folders/z9/hr670btx0_gdq81bgc3q42w4gn/T/go-build387581625=/tmp/go-build 
-gno-record-gcc-switches -fno-common"


P.S have also attached screenshot of the logs and the go version is 
: go version go1.13.4 darwin/amd64
and I have also tried putting "time-stamps" but that generated more 
error so we removed 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 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/adf07d15-e8bd-4184-b717-2b73d04cf6b0%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/0abfe94c-cd6b-e07e-71f9-3c0368072174%40multiplay.co.uk.

Re: [go-nuts] go commands hang indefinitely

[Steven Hartland]

What happens if you kill -ABRT the process?

On Fri, 10 Apr 2020 at 01:16, Juan Monroy-Nieto 
wrote:

> Hello everyone, I am compelled to stop just lurking.
>
> Go Version 1.14.1 on MacOS Mohave.
>
> Similarly to a recent post
> ,
> commands go build/vet/test/run hang indefinitely for any program including
> a hello world inside the GOPATH (copy pasted the code from the starting
> point in the playground). All the code I can test in the playground and in
> another mac runs fine. Unlike the cited post, this does not relate to
> internet connectivity. I have already posted this *issue
> *
> in StackOverflow to no avail. So I would like to ask for your help with
> this issue. I appreciate your help.
>
>  I have tried troubleshooting by:
>
>- Resetting GOPATH
>- Starting a shell without my bashRC
>- Restarting my computer
>- Reinstalling Go
>- Running go build -x yields normal calls and even an executable that
>runs fine (Last output is rm -r $WORK/b001/). It just does not exit,
>and ignores interrupt signals.
>- When it is running, a stack trace using *dtruss* shows ongoing
>syscalls that I am unable to interpret.
>
> My go env output:
>
>
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN="/bin"
> GOCACHE="/Users/user_name/Library/Caches/go-build"
> GOENV="/Users/user_name/Library/Application Support/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOINSECURE=""
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="darwin"
> GOPATH="/Users/user_name/go:/Users/user_name/goCode"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct;
> GOROOT="/usr/local/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> GCCGO="gccgo"
> AR="ar"
> CC="clang"
> CXX="clang++"
> CGO_ENABLED="1"
> GOMOD=""
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments
> -fmessage-length=0
> -fdebug-prefix-map=/var/folders/6c/h189_j9s6tdbj_kw24g2kvchsk0515/T/go-build628238008=/tmp/go-build
> -gno-record-gcc-switches -fno-common"
>
> --
> 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/81548479-6676-4594-a0ba-6890003bafda%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/CAHEMsqaB-1HZvoDSNY-R9J8spmJ_X0%2BGFHqGy79s6sn2-sUH7w%40mail.gmail.com.

[go-nuts] godoc.org - Internal server error

[Steven Hartland]

Looks like somethings wrong with godoc.org atm, not sure who maintains 
this as every page just errors for me ATM, hence reaching out here in 
the hope someone who does reads this list.


An example is accessing: https://godoc.org/github.com/spf13/pflag
Internal server error.

--
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/b1447b27-9b0c-989e-5ddc-4b1234e5e18a%40multiplay.co.uk.

Re: [go-nuts] go 1.13.1 (linux x64): time.After not working as expected

[Steven Hartland]

Your not checking done in your for loop.

On 14/10/2019 13:39, Jeff Kayser wrote:
I'm working through the most excellent book "Concurrency in Go", doing 
the example on page 162-166.  My code is here:


https://play.golang.org/p/7kokkAIdhov

The program is not triggering the timeout section of the code (lines 
103-103 in the playground code).


All of the other examples have worked as expected, including the one 
just before this, which is almost identical, except for a couple of 
tweaks.  This is the first one that hasn't worked.


What am I doing wrong?

~Jeff Kayser

--
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/6316c901-9425-4d4f-9bb3-2f7d4aed94a5%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/487e1ad8-e0e6-a3d7-d69b-b9a20dec9295%40multiplay.co.uk.

Re: [go-nuts] Is there a preferred REDIS driver or go psckage?

[Steven Hartland]

https://github.com/gomodule/redigo/ written by Gary Burd is still
maintained. We actively use it in production heavily.

On Mon, 9 Sep 2019 at 19:19, joe mcguckin 
wrote:

>
>
> Thanks,
>
> Joe
>
> --
> 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/a82996c6-6163-4025-a3f2-f0d6f37b0473%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/CAHEMsqbde8iA0Jnfon8AWm0ZYmYjSCth4eNv8nwCf1v726D0Cw%40mail.gmail.com.

Re: [go-nuts] Re: Option to disable version validation in 1.13?

[Steven Hartland]

Yer replace is mentioned in the link I provided too and I’d seen that
thread, but as you can see from the amount of effort required I would
suggest that it’s currently not practical to have everyone go through that
process; particularly for tools when they just want to install and use not
develop against it.

In our company we’ve tried several times now to migrate to go mods and each
time we’ve given up as third party libs are simply not ready, this is just
another example of that.

I totally agree with the why but the practicalities should not be ignored
and hence there should be way to easily disable this check while libs and
tools address the issues; similarly to how checksums can be disabled.

In our case were now using a patched 1.13 with this check removed as that
was by far the path of least resistance, which is something we really don’t
want to do.

   Regards
   Steve



On Wed, 4 Sep 2019 at 04:33, t hepudds  wrote:

> Hello Steve,
>
> > https://golang.org/doc/go1.13#version-validation lists a number of
> > options if you're maintaining a module but nothing seems relevant for
> > CI/CD pipelines which are just trying to use tools for which they aren't
> > the maintainer.
>
> Regarding how to fix "invalid pseudo-version" errors, I think the release
> notes are also trying to give options for someone trying to use tools for
> which they aren't the maintainer (as well as options for maintainers).
>
> The paragraph on the `replace` directive in that section of the release
> notes I think is something you can use, even if you are not the maintainer
> of a module with an invalid version. In general, the `replace` directive
> basically gives your module complete control over its own build in terms of
> what versions to use.
>
> More specifically, using Go 1.13, this fails with an "invalid
> pseudo-version" error (as expected):
>
>export GOPATH=$(mktemp -d)   # using fresh module cache
>cd $(mktemp -d)
>go mod init example.com/tempmod
>go get github.com/golangci/golangci-lint/cmd/golangci-lint@v1.17.1
>
> which reports error:
>
>   go: extracting github.com/golangci/golangci-lint v1.17.1
>   go get: github.com/golangci/golangci-lint@v1.17.1 requires
> github.com/go-critic/go-critic@v0.0.0-20181204210945-1df300866540:
> invalid pseudo-version: does not match version-control timestamp
> (2019-05-26T07:48:19Z)
>
> It looks like there has been some discussion of solving this within
> golangci, including here and some related issues there:
>
>https://github.com/golangci/golangci-lint/pull/605
>
> It looks like some of the core Go team has commented there with advice,
> but looks like it is still pending changes there.
>
> However, we don't need to wait for that to be resolved within golangci.
>
> If we follow the advice from the section of the Go 1.13 release notes on
> resolving version validation issues ( valhttps://
> golang.org/doc/go1.13#version-validation), we can make that same 'go get'
> work:
>
># re-do setup from scratch
>export GOPATH=$(mktemp -d)   # using fresh module cache
>cd $(mktemp -d)
>go mod init example.com/tempmod
>
># create 'replace' statements using *just* the commit hashes for each
> problematic module on the right-hand side
>echo 'replace github.com/go-critic/go-critic
> v0.0.0-20181204210945-1df300866540 => github.com/go-critic/go-critic
> 1df300866540' >> go.mod
>echo 'replace github.com/golangci/errcheck
> v0.0.0-20181003203344-ef45e06d44b6 => github.com/golangci/errcheck
> ef45e06d44b6' >> go.mod
>echo 'replace github.com/golangci/go-tools
> v0.0.0-20180109140146-af6baa5dc196 => github.com/golangci/go-tools
> af6baa5dc196' >> go.mod
>echo 'replace github.com/golangci/gofmt
> v0.0.0-20181105071733-0b8337e80d98 => github.com/golangci/gofmt
> 0b8337e80d98' >> go.mod
>echo 'replace github.com/golangci/gosec
> v0.0.0-20180901114220-66fb7fc33547 => github.com/golangci/gosec
> 66fb7fc33547' >> go.mod
>echo 'replace github.com/golangci/ineffassign
> v0.0.0-20180808204949-42439a7714cc => github.com/golangci/ineffassign
> 42439a7714cc' >> go.mod
>echo 'replace github.com/golangci/lint-1
> v0.0.0-20180610141402-ee948d087217 => github.com/golangci/lint-1
> ee948d087217' >> go.mod
>echo 'replace mvdan.cc/unparam v0.0.0-20190124213536-fbb59629db34 =>
> mvdan.cc/unparam fbb59629db34' >> go.mod
>
># this now works
>go get github.com/golangci/golangci-lint/cmd/golangci-lint@v1.17.1
>
> Regards,
> thepudds
>
> On Tuesday, September 3, 2019 at 8:17:47 PM UTC-4, Steven Hartland wrote:
>>
>> Trying to update to 1.13 but

[go-nuts] Option to disable version validation in 1.13?

[Steven Hartland]

Trying to update to 1.13 but the new version validation breaks 
golangci-lint installs with:

invalid pseudo-version: does not match version-control timestamp

https://golang.org/doc/go1.13#version-validation lists a number of 
options if you're maintaining a module but nothing seems relevant for 
CI/CD pipelines which are just trying to use tools for which they aren't 
the maintainer.


On my local box I ended up downgrading to go 1.12.9 running the install, 
which downloaded the dependencies into the cash then upgrading again and 
reinstalling to get go 1.13 compiled versions of golangci-lint.


GO111MODULE=on go get 
github.com/golangci/golangci-lint/cmd/golangci-lint@v1.17.1


The standard way to install golangci-lint from binaries fails due to 
what seems like conflicts with the changes in go 1.13, erroring out in 
various linters.


So the question is:
* Is there option to disable this behaviour so we don't have to get 
every single tools dependencies fixed to pass this new validation just 
to use them?


    Regards
    Steve

--
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/dae5cebf-4262-ee0d-f6d8-f5087759d662%40multiplay.co.uk.

Re: [go-nuts] By passing go type check when performing bitwise operator

[Steven Hartland]

This has been changed in the upcoming 1.13 release, so you might want to 
try the latest release candidate.


On 01/09/2019 19:03, Albert Tedja wrote:
 I am trying to perform some bitwise operators, but Go is not letting 
me because the mask is an uint and the values are int. Setting the 
mask to int will break the code since I am shifting bits right and 
left and prefer the prefix 0 when shifting right, and if I am not 
mistaken, Go does not have >>>.




--
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/a211253c-eec1-4efb-8f4c-5e94f04e6681%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/0cd00fab-a296-823d-61bc-1d6b873db761%40multiplay.co.uk.

Re: [go-nuts] Goroutine scheduled 10 seconds too late

[Steven Hartland]

Out of interest what OS?
Is the machine virtualised?

You might want to try doing an OS syscall trace to see if it’s stuck in an
OS call for some reason.

  Regards
  Steve

On Sat, 24 Aug 2019 at 03:37, Michael Andersen 
wrote:

> This is built with go 1.12.5, incidentally, but I have seen this on
> several go versions spanning several months.
>
> On Fri, Aug 23, 2019 at 7:36 PM Michael Andersen 
> wrote:
>
>> Ok, so I have more information, and it's not what I would expect.
>>
>> I added scheddetail=1,schedtrace=2000 so that I had a list of which M's
>> and G's were on the P's during the 5 seconds that scheduling stalled. I
>> added a sentinel goroutine that sleeps 1 second in a loop and panics if the
>> sleep takes more than 4 seconds. As soon as the sentinel wakes up after the
>> stall, it dumps all the stacks for all the goroutines under  the assumption
>> that at least some of them might be in the same place as they were during
>> the stall. Thus, I know for sure which goroutines caused the problem and
>> maybe which piece of the code they were in.
>>
>> During the stall, all of the P's had the same M's and the same G's, so
>> nothing was changing except the idlethreads and runqueues (as I would
>> expect because my sentinel goroutine didn't get run). Here is a compilation
>> of the information captured during the stall.
>>
>> SCHED 3425490ms: gomaxprocs=8 idleprocs=0 threads=52 spinningthreads=0
>> idlethreads=35 runqueue=8 gcwaiting=0 nmidlelocked=1 stopwait=0 sysmonwait=0
>>  < same M's on the same P's with the same curg's as below >
>> SCHED 3427497ms: gomaxprocs=8 idleprocs=0 threads=52 spinningthreads=0
>> idlethreads=36 runqueue=9 gcwaiting=0 nmidlelocked=1 stopwait=0 sysmonwait=0
>>   P0: status=1 schedtick=22978494 syscalltick=6811602 m=44 runqsize=0
>> gfreecnt=2
>>   M44: p=0 curg=12934173 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934173: status=2(chan receive) m=44 lockedm=-1
>>
>>   P1: status=1 schedtick=22848756 syscalltick=6851102 m=34 runqsize=0
>> gfreecnt=32
>>   M34: p=1 curg=12934084 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934084: status=2(chan receive) m=34 lockedm=-1
>>
>>   P2: status=1 schedtick=22743131 syscalltick=6730185 m=17 runqsize=0
>> gfreecnt=37
>>   M17: p=2 curg=12934032 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934032: status=2(chan receive) m=17 lockedm=-1
>>
>>   P3: status=1 schedtick=22674653 syscalltick=6516472 m=11 runqsize=0
>> gfreecnt=20
>>   M11: p=3 curg=12934147 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934147: status=2(chan receive) m=11 lockedm=-1
>>
>>   P4: status=1 schedtick=22693327 syscalltick=6322345 m=33 runqsize=0
>> gfreecnt=12
>>   M33: p=4 curg=12934059 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934059: status=2(chan receive) m=33 lockedm=-1
>>
>>   P5: status=1 schedtick=22370152 syscalltick=6219903 m=0 runqsize=0
>> gfreecnt=39
>>   M0: p=5 curg=12934131 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934131: status=2(chan receive) m=0 lockedm=-1
>>
>>   P6: status=1 schedtick=21910259 syscalltick=6171748 m=51 runqsize=0
>> gfreecnt=39
>>   M51: p=6 curg=12934126 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934126: status=2(chan receive) m=51 lockedm=-1
>>
>>   P7: status=1 schedtick=22019793 syscalltick=6091894 m=32 runqsize=1
>> gfreecnt=30
>>   M32: p=7 curg=12934191 mallocing=0 throwing=0 preemptoff= locks=0
>> dying=0 spinning=false blocked=false lockedg=-1
>>   G12934191: status=2(chan receive) m=32 lockedm=-1
>>
>> After the sentinel goroutine was scheduled (~1 second after this
>> schedtrace output) I captured the stacks and crossreferenced the G's. All
>> of them are in time.Now()
>>
>>   goroutine 12934173 [runnable]:
>>   time.Now(0x7f453a441dc0, 0xc0169fe000, 0x5a0)
>>   /usr/local/go/src/time/time.go:1087 +0xb2
>>   -- line in request handler in my app--
>>
>>   goroutine 12934084 [runnable]:
>>   time.Now(0x7f4614a65400, 0xc0155a2000, 0x1680)
>>   /usr/local/go/src/time/time.go:1087 +0xb2
>>   -- line in request handler in my app--
>>
>>   goroutine 12934032 [runnable]:
>>   time.Now(0x7f457d74ae20, 0xc023179400, 0x3c0)
>>   /usr/local/go/src/time/time.go:1087 +0xb2
>>   -- line in request handler in my app--
>>
>>   goroutine 12934147 [runnable]:
>>   time.Now(0x7f461fcca4c0, 0xc00cf38400, 0x3c0)
>>   /usr/local/go/src/time/time.go:1087 +0xb2
>>   -- line in request handler in my app--
>>
>>   goroutine 12934059 [runnable]:
>>   time.Now(0x7f45ff9dcd00, 0xc0245b1000, 0xf00)
>>   /usr/local/go/src/time/time.go:1087 +0xb2
>>   -- line in request handler in my app--
>>
>>   goroutine 12934131 [runnable]:
>>   

Re: [go-nuts] Re: Tips for reproducing flaky Go tests

[Steven Hartland]

We’ve found stress invaluable in helping to reproduce flaky tests
https://godoc.org/golang.org/x/tools/cmd/stress


On Sat, 17 Aug 2019 at 01:50, Maxim Fateev  wrote:

> I wish Go had a deterministic execution mode with predefined randomization
> seed. The to reproduce such test you would only need a single seed number.
> We built such system for testing our distributed application and it was
> very useful to track rare race conditions.
>
> On Thursday, August 15, 2019 at 11:16:24 AM UTC-7, Mark Rushakoff wrote:
>>
>> I put together a blog post on reproducing flaky Go tests:
>> https://www.influxdata.com/blog/reproducing-a-flaky-test-in-go/
>>
>> This was the result of what I've learned spending many, many hours
>> hunting down many unreliable tests.
>>
>> I hope these tips can help you out next time you have a test that fails
>> in CI but passes locally.
>>
> --
> 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/a56c15a3-6a96-47ab-8b09-147d29c05f23%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/CAHEMsqY%2B%3DgndA7B7myzwdVppMTTE73F7GTU7Eq2wBzevANBJFQ%40mail.gmail.com.

Re: [go-nuts] Re: Build issues on FreeBSD ZoF "unexpected stale targets"

[Steven Hartland]

You might want to see if dtrace can shed some light on this?

On Sat, 20 Jul 2019 at 01:25,  wrote:

>
>
> On Friday, July 19, 2019 at 2:24:30 PM UTC-7, Steven Hartland wrote:
>>
>> Mat is actually running a non-standard kernel, with the ZFS filesystem
>> from the core OS replaced with a ZFS version derived from Linux ZFS port.
>>
>> I've not looked at the details of the port, but one suggestion would be
>> do you see the same behaviour if you build on UFS volume while still
>> running the kernel with the ZFS port.
>>
>> This may indicate if a strange filesystem level issue is causing
>> corruption or if the port has changed / broken a kernel feature go is
>> relying on.
>>
>
> Haven't tried UFS but he problem doesn't occur when using tmpfs for /tmp
> when using ZoF or when using the ZFS in base for /tmp. Trussing the build
> slows it down to the point where it succeeds. I attribute this to some sort
> of race in ZoF but not in "legacy" ZFS. vfsops and vnops are essentially
> the same as upstream so I'm really not sure what to look for.
>
> -M
>
>
>>
>> Regards
>> Steve
>> On 19/07/2019 22:01, B Carr wrote:
>>
>>
>> What does this part mean? "...with the ZFS rebased to ZFS on Linux..."
>>
>>
>> On Friday, July 19, 2019 at 1:37:02 PM UTC-6, mat...@gmail.com wrote:
>>>
>>> I'm not sure where to ask this since this isn't actually a Go bug. Go
>>> 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However, with the
>>> ZFS rebased to ZFS on Linux I'm seeing issues that I can only reproduce
>>> building Go.
>>>
>> --
>> 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/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>
>> --
> 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/e5b4f8cf-6203-4a93-88fe-b4d61d83b12d%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/e5b4f8cf-6203-4a93-88fe-b4d61d83b12d%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAHEMsqbcX-8O4c%2BSwezHoH0MDQ51u4bVR%2B0YDVatHwcTO7M7ew%40mail.gmail.com.

Re: [go-nuts] Re: Build issues on FreeBSD ZoF "unexpected stale targets"

[Steven Hartland]

Mat is actually running a non-standard kernel, with the ZFS filesystem 
from the core OS replaced with a ZFS version derived from Linux ZFS port.


I've not looked at the details of the port, but one suggestion would be 
do you see the same behaviour if you build on UFS volume while still 
running the kernel with the ZFS port.


This may indicate if a strange filesystem level issue is causing 
corruption or if the port has changed / broken a kernel feature go is 
relying on.


    Regards
    Steve
On 19/07/2019 22:01, B Carr wrote:


What does this part mean? "...with the ZFS rebased to ZFS on Linux..."


On Friday, July 19, 2019 at 1:37:02 PM UTC-6, mat...@gmail.com wrote:

I'm not sure where to ask this since this isn't actually a Go bug.
Go 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However,
with the ZFS rebased to ZFS on Linux I'm seeing issues that I can
only reproduce building Go.

--
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/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%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/2dc3cd67-9bd1-8ca7-df85-2f4436ecc103%40multiplay.co.uk.

Re: [go-nuts] ioutil.ReadDir error

[Steven Hartland]

If you want this behavior you'll need to use the lower level methods in 
the os package .


    Regards
    Steve

On 19/07/2019 11:54, rob wrote:

I have this in my code

  files, err := ioutil.ReadDir(CleanDirName)

  if err != nil {

    log.Println(err)

  }

Occasionally I have a symlink to another computer that goes stale, 
with this error:


  lstat [symlinkname] stale NFS file handle

When this happens, ReadDir does not return any other files in the 
slice.  I would like it to.  Is there any way for me to get it to do 
that?


--rob solomon



--
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/de4ad0cc-f0d2-80bc-af11-fe2e51b41e74%40multiplay.co.uk.

Re: [go-nuts] Does this code safe?

[Steven Hartland]

Use the same method for both Load and Set, also your example will never 
complete as your for loops will run forever.


On 05/07/2019 15:53, Cholerae Hu wrote:

|
package main

import (
"sync/atomic"
"sync"
)

func main() {
var n int32
var m sync.Mutex
var wg sync.WaitGroup
wg.Add(2)
go func() {
for {
atomic.LoadInt32()
}
wg.Done()
}()
go func() {
for {
m.Lock()
n = 1
m.Unlock()
}
wg.Done()
}()
wg.Wait()
}

|
Does it safe to use atomic read an int and write an int non-atomically 
but in lock concurrently? Race detector will report it data race.

--
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/825f9031-74b9-41b6-87af-dccfa7d98d04%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3fdeff39-758e-9a00-ba51-f79c4d20bde8%40multiplay.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Steven Hartland]

Couple of things that you might want to investigate:
1. Is SetReadDeadline the same as SO_RCVTIMEO (vm vs socket)?
2. Is c.Close()  the same as shutdown (flushes vs doesn't)?
3. Is print is the same as fmt.Fprintf / c.Write (buffered vs unbuffered)?

With the go I'd be tempted to put everything from the successful accept 
to the socket close in a goroutine.


    Regards
    Steve

On 08/06/2019 14:56, Tong Sun wrote:

Agree that it was not an apples to apples comparison. So please check
out my 2nd blog:

https://dev.to/suntong/simple-web-server-in-perl-and-go-revisit-5d82


thanks to Axel Wagner, who replaced the net/http.Server layer with direct 
translation of Perl code, the code is now reading and writing directly to a 
socket, just as what the Perl code is doing.

@Budi, links to my Go code are available in both of my posts.


On Fri, Jun 7, 2019 at 8:08 PM Ivan Bertona wrote:

Looking a the two code samples I wouldn't say this is an apples to apples 
comparison... The Perl script seems to be a simple single-threaded loop that 
understands a tiny subset of HTTP vs. a fully-fledged (and secure) web server 
from the Go standard library. I would definitely not run that Perl script in 
production, even if it was for a simple project. My bet is that if you actually 
port the Perl script to a Go program that does more or less the same thing 
you'll see more or less the same performance (because the example is 
fundamentally I/O-bound).

Best,
Ivan

On Friday, June 7, 2019 at 9:36:49 AM UTC-4, Tong Sun wrote:

I had always believed that the web projects build with Go should be much faster 
than Perl, since Go is a compiled language.

However that belief was crushed brutally last night, when I did a comparison -- 
the Go implementation is 8 times worse than the Perl! -- the mean response time 
jumped from 6ms to 48ms.

I know this is the simplest possible web server, but still, when it comes to 
simple web servers like this, I have to say that Perl performs much better than 
Go.

I don't think there is much I can twist on the Go side, since it can't be more 
simpler than that. However, I also believe it won't hurt to ask and confirm. So,

Have I missed anything? Is it possible for me to make my Go implementation 
anywhere near the Perl's performance?

Thanks



--
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/iH2Ck_hpCpI/unsubscribe.
To unsubscribe from this group and all its topics, 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/12e7666a-385f-47ef-b061-9738802e7a88%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/933ab3e8-5a79-0542-2f9d-bd82a54d8514%40multiplay.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Creating HTTP API with extra '/' (without quotes) at the end of the route, takes only 'GET' request.

[Steven Hartland]

I believe this is documented here: https://golang.org/pkg/net/http/#ServeMux

On 07/06/2019 07:46, Mayank Gupta wrote:
Hi All, I wanted to make sure before filing an issue on Github. Here's 
the code using net/http package to create a restful web API.
If I hit any route using Postman app, no matter the type of request 
(POST, PUT, DELETE, etc.) it always hits the API as a GET request.

|
packagemain import("context""fmt""io""log""net/http")func 
registerHandler(responseWriter http.ResponseWriter,request 
*http.Request){ifrequest.Method=="GET"{        
io.WriteString(responseWriter,"This is a get 
request")}elseifrequest.Method=="POST"{        
io.WriteString(responseWriter,"This is a post request")}else{        
io.WriteString(responseWriter,"This is not a valid request 
request")}}func statsHandler(responseWriter 
http.ResponseWriter,request *http.Request){ifrequest.Method=="GET"{    
    io.WriteString(responseWriter,"This is a get 
request")}elseifrequest.Method=="POST"{        
io.WriteString(responseWriter,"This is a post request")}else{        
io.WriteString(responseWriter,"This is not a valid request 
request")}}func main(){    mux :=http.NewServeMux()    
mux.HandleFunc("/register/",registerHandler)    
mux.HandleFunc("/stats/",statsHandler)    
log.Fatal(http.ListenAndServe(":5000",mux))}

|
If I hit 'http://localhost:5000/stats' using POST, it'll always hit 
the API as a GET request.


Changing main() function to:
|
func main(){

    mux :=http.NewServeMux()
    mux.HandleFunc("/register",registerHandler)
    mux.HandleFunc("/stats",statsHandler)

    log.Fatal(http.ListenAndServe(":5000",mux))

}
|
Works like a charm, the only change is I removed '/' from the routes 
at end.


I believe it's a bug. Please let me know if what I believe is wrong.

Thanks,
Mayank Gupta

--
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/52a497c0-0c94-4005-94c1-f0ac3ee170d6%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ab7c3e3c-5cac-372a-3fa2-394261a70429%40multiplay.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 1.8 port to FreeBSD/PowerPC64

[Steven Hartland]

Newer versions of go require an older version of go (1.4) to bootstrap, 
that may be related to your issue?


On 04/06/2019 04:21, Curtis Hamilton wrote:

Currently. the FreeBSD port only supports "i386 amd64 armv6 armv7" and does not 
support powerpc64 (ppc64).  I'm starting with an older version because newer versions 
seem to only support power8, while I'm using power5.



--
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/598c3204-a7d7-2652-5cfe-7329586c6116%40multiplay.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: using channels to gather bundles from inputs for batch processing

[Steven Hartland]

You can see it doesn't wait by adding a counter as seen here:
https://play.golang.org/p/-eqKggUEjhQ

On 02/05/2019 21:09, Louki Sumirniy wrote:
I have been spending my time today getting my knowledge of this 
subject adequate enough to use channels for a UDP transport with FEC 
creating sharded pieces of the packets, and I just found this and 
played with some of the code on it and I just wanted to mention these 
things:


https://dave.cheney.net/2013/04/30/curious-channels

In the code, specifically first section of this article, I found that 
the sync.WaitGroup stuff can be completely left out. The quit channel 
immediately unblocks the select when it is closed and 100 of the 
goroutines immediately stop. Obviously in a real situation you would 
put cleanup code in the finish clauses of the goroutines, but yeah, 
point is the waitgroup is literally redundant in this code:


package main

import (
"fmt"
"time"
)

func main() {
const n = 100
finish := make(chan bool)
for i := 0; i < n; i++ {
go func() {
select {
case <-time.After(1 * time.Hour):
case <-finish:
}
}()
}
t0 := time.Now()
close(finish) // closing finish makes it ready to receive
fmt.Printf("Waited %v for %d goroutines to stop\n", time.Since(t0), n)
}

The original version uses waitgroups but you can remove them as above 
and it functions exactly the same. Presumably it has lower overhead 
from the mutex not being made and propagating to each thread when it 
finishes a cycle.


It really seems to me like for this specific case, the use of the 
property of a closed channel to yield zero completely renders a 
waitgroup irrelevant.


What I'm curious about is, what reasons would I have for not wanting 
to use this feature of closed channels as a stop signal versus using a 
waitgroup?


On Thursday, 2 May 2019 16:20:26 UTC+2, Louki Sumirniy wrote:

It's not precisely the general functionality that I will implement
for my transport, but here is a simple example of a classifier
type processing queue:

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


This processes a series of sequential integers and pops them into
an array to find the highest factor of a given range of numbers.
The code I will write soon is slightly different, as, obviously,
that above there is not technically a queue. This code shows how
to make a non-deadlocking processing queue, however.

Adding an actual queue like for my intended purpose of bundling
packets with a common uuid is not much further, instead of just
dropping the integers into their position in the slice, it
iterates them as each item is received to find a match, if it
doesn't find enough, then it puts the item back at the end of the
search on the queue and waits for the next new item to arrive.
I'll be writing that shortly.

For that, I think the simple example would use an RNG to generate
numbers within the specified range, and then for the example, it
will continue to accumulate numbers in the buffer until a
recurrance occurs, then the numbers are appended to  the array and
this index is ignored when another one comes in later. That most
closely models what I am building.

On Thursday, 2 May 2019 13:26:47 UTC+2, Louki Sumirniy wrote:

Yeah, I was able to think a bit more about it as I was falling
asleep later and I realised how I meant it to run. I had to
verify that indeed channels are FIFO queues, as that was the
basis of this way of using them.

The receiver channel is unbuffered, and lives in one
goroutine. When it receives something it bounces it into the
queue and for/range loops through the content of a fairly
big-buffered working channel where items can collect while
they are fresh, and upon arrival of a new item the new item is
checked for a match against the contents of the queue, as well
as kicking out stale data (and recording the uuid of the stale
set so it can be immediately dumped if any further packets got
hung up and come after way too long.

This differs a lot from the loopy design I made in the OP. In
this design there is only to threads instead of three. I think
the geometry of a channel pattern is important - specifically,
everything needs to be done in pairs with channels, although
maybe sometimes you want it too receive but not need it to
send it anywhere, just store/drop, as the algorithm requires.

I still need to think through the design a bit more. Like,
perhaps the queue channel *should* be a pair of one-direction
channels so one is the main fifo and the other side each item
is taken off the queue, processed, and then put back into the
stream. Ordering is not important, except that it is very
handy that it is a FIFO because this means if I have a buffer

Re: [go-nuts] Re: using channels to gather bundles from inputs for batch processing

[Steven Hartland]

Without the wait group it doesn't wait, so you're not guaranteed for all 
/ any of the goroutines to complete.


On 02/05/2019 21:09, Louki Sumirniy wrote:
I have been spending my time today getting my knowledge of this 
subject adequate enough to use channels for a UDP transport with FEC 
creating sharded pieces of the packets, and I just found this and 
played with some of the code on it and I just wanted to mention these 
things:


https://dave.cheney.net/2013/04/30/curious-channels

In the code, specifically first section of this article, I found that 
the sync.WaitGroup stuff can be completely left out. The quit channel 
immediately unblocks the select when it is closed and 100 of the 
goroutines immediately stop. Obviously in a real situation you would 
put cleanup code in the finish clauses of the goroutines, but yeah, 
point is the waitgroup is literally redundant in this code:


package main

import (
"fmt"
"time"
)

func main() {
const n = 100
finish := make(chan bool)
for i := 0; i < n; i++ {
go func() {
select {
case <-time.After(1 * time.Hour):
case <-finish:
}
}()
}
t0 := time.Now()
close(finish) // closing finish makes it ready to receive
fmt.Printf("Waited %v for %d goroutines to stop\n", time.Since(t0), n)
}

The original version uses waitgroups but you can remove them as above 
and it functions exactly the same. Presumably it has lower overhead 
from the mutex not being made and propagating to each thread when it 
finishes a cycle.


It really seems to me like for this specific case, the use of the 
property of a closed channel to yield zero completely renders a 
waitgroup irrelevant.


What I'm curious about is, what reasons would I have for not wanting 
to use this feature of closed channels as a stop signal versus using a 
waitgroup?


On Thursday, 2 May 2019 16:20:26 UTC+2, Louki Sumirniy wrote:

It's not precisely the general functionality that I will implement
for my transport, but here is a simple example of a classifier
type processing queue:

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


This processes a series of sequential integers and pops them into
an array to find the highest factor of a given range of numbers.
The code I will write soon is slightly different, as, obviously,
that above there is not technically a queue. This code shows how
to make a non-deadlocking processing queue, however.

Adding an actual queue like for my intended purpose of bundling
packets with a common uuid is not much further, instead of just
dropping the integers into their position in the slice, it
iterates them as each item is received to find a match, if it
doesn't find enough, then it puts the item back at the end of the
search on the queue and waits for the next new item to arrive.
I'll be writing that shortly.

For that, I think the simple example would use an RNG to generate
numbers within the specified range, and then for the example, it
will continue to accumulate numbers in the buffer until a
recurrance occurs, then the numbers are appended to  the array and
this index is ignored when another one comes in later. That most
closely models what I am building.

On Thursday, 2 May 2019 13:26:47 UTC+2, Louki Sumirniy wrote:

Yeah, I was able to think a bit more about it as I was falling
asleep later and I realised how I meant it to run. I had to
verify that indeed channels are FIFO queues, as that was the
basis of this way of using them.

The receiver channel is unbuffered, and lives in one
goroutine. When it receives something it bounces it into the
queue and for/range loops through the content of a fairly
big-buffered working channel where items can collect while
they are fresh, and upon arrival of a new item the new item is
checked for a match against the contents of the queue, as well
as kicking out stale data (and recording the uuid of the stale
set so it can be immediately dumped if any further packets got
hung up and come after way too long.

This differs a lot from the loopy design I made in the OP. In
this design there is only to threads instead of three. I think
the geometry of a channel pattern is important - specifically,
everything needs to be done in pairs with channels, although
maybe sometimes you want it too receive but not need it to
send it anywhere, just store/drop, as the algorithm requires.

I still need to think through the design a bit more. Like,
perhaps the queue channel *should* be a pair of one-direction
channels so one is the main fifo and the other side each item
is taken off the queue, processed, and then put back into the
stream. Ordering is not important, except that it is very
handy that it is a FIFO because this means if I have a buffer
 

Re: [go-nuts] Struct's fields order affects required memory

[Steven Hartland]

With regards the size of the struct, elements are aligned by the go 
compiler automatically as demonstrated by the following tool:

http://golang-sizeof.tips/

Are you asking why the compiler doesn't automatically change the order 
of fields in the struct to make the struct a minimal size?


    Regards
    Steve

On 06/03/2019 12:56, Viktor Packhuchyi wrote:

Hi,

As I know Go compiler provide self-managed alignment for fields 
inside a structure.


I don't understand why the fields order must impact additional 
allocations.
It's not clear for me, why the compiler doesn't manage this 
automatically.


Is this a future which I can't understand or a design gap?
--
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] golang websocket read method doesn't get error if the android client changes its network

[Steven Hartland]

If the server doesn't do an writes or is stuck in a read you can see 
this behavior.


Enabling keepalive on the connection should fix this.

On 29/01/2019 10:57, mailme...@gmail.com wrote:
I wrote a both server and client side with golang, the server side 
runs on centos7, and I built client side as aar package runs at 
android, but I noticed If I close android network, the server side 
websocket.read not get a EOF error and it still keep hang.


What is the reason? how can I solve it, thanks in advance!
--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


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

Re: [go-nuts] gotcha: don't take the address of a for-range loop variable

[Steven Hartland]

Worth mentioning you don't need the second _ variable in range 
statements e.g. use:

    for i := range items {
   .
    }

vs:
    for i, _ := range items {
   .
    }
On 07/01/2019 02:24, bucha...@gmail.com wrote:

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

I was taking the address of the for-loop variable ("" in the example 
above) and was surprised to find that all my items pointed the same 
address. I thought I had found most of the Golang gotchas by now, but 
this is a new one to me.


-A
--
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] [RFC] Dynamically instrumentation Go binaries

[Steven Hartland]

dtrace support?

On 15/11/2018 16:51, ju...@sqreen.io wrote:

Hi,

I am working on dynamic instrumentation of Go programs at run time, 
possibly without static source-code instrumentation. As I would like a 
solution as close to Go and standard as possible, I was first thinking 
of using `go generate` to generate a file adding things `reflect` 
doesn't provide such as the list of packages, functions, global 
variables... That way, I should be able to use `reflect` to modify any 
dynamic calls by modifying the method tables of their underlying type 
representations.


But regarding statically linked calls, the less intrusive technique I 
found are uprobes, which is linux-specific. And at the opposite, there 
are user-space binary code instrumentation libraries such as dyninst 
that modify the code at run time...


So I am wondering if anyone here has any thoughts on this subject, 
that doesn't seem to be solved for Go programs.


Thanks!

Julio
--
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] defining custom struct, confused

[Steven Hartland]

If you look closely they have a strange structure:
 "users": [*[*{...},{...}*]*]

You've created:
"users":[{...},{...}]

On 26/09/2018 14:43, 'Mudasir Mirza' via golang-nuts wrote:

Hey guys,

I am fairly new to GoLang, still learning.

I am trying to working on a small utility, which fetches details from 
a third party.

As per their documentation, I will get response something like

|
{
"users":[
[
{
"firstName":"string ",
"lastName":"string",
"username":"string",
"email":"string",
"createdAt":"string",
"passwordLastUpdated":"string",
"verified":true,
"_selfUrl":"string"
},
{
"firstName":"string ",
"lastName":"string",
"username":"string",
"email":"string",
"createdAt":"string",
"passwordLastUpdated":"string",
"verified":true,
"_selfUrl":"string"
}
]
]
}
|

For this, I created struct type

|
type V1User struct{
FirstNamestring`json:"firstName,omitempty"`
LastNamestring`json:"lastName,omitempty"`
UserNamestring`json:"username,omitempty"`
Emailstring`json:"email,omitempty"`
CreatedAtstring`json:"createdAt,omitempty"`
PasswordLastUpdatedstring`json:"passwordLastUpdated,omitempty"`
Verifiedbool`json:"verified,omitempty"`
SelfUrlstring`json:"_selfUrl,omitempty"`
}


type allUsers struct{
 users []V1User `json:"users,omitempty"`
}
|

I am pretty sure I am missing out on something. I am running below 
code to fetch and decode the data


|
func (c *Client)getUsers()(users []allUsers,err error){
 resp,err :=c.request(http.MethodGet,"user",nil)
iferr !=nil{
return
}
 defer resp.Body.Close()
varresult =struct{
Users[]allUsers
}{}
 err =json.NewDecoder(resp.Body).Decode()
returnresult.Users,err
}
|

and I get error

|
fmt.Println(result.Users)->Users:[{[]}]
fmt.Println(err)->Error: json:cannot unmarshal array intoGostructfield 
.Usersof type main.allUsers

|

I am still trying to figure out what's wrong here, any help will be 
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.


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

Re: [go-nuts] a potential problem with go1.11 HTTP library

[Steven Hartland]

For reference this is the issue tracking the regression I believe your 
experiencing:

https://github.com/golang/go/issues/27525

On 25/09/2018 08:36, Xiangrong Fang wrote:

I have a HTTP API and its client written in Go. The client side code is:

func upload(link, dir, name string, r io.Reader) {
var buf bytes.Buffer
mw := multipart.NewWriter()
mw.WriteField("dir", dir)
mw.WriteField("name", name)
ff, _ := mw.CreateFormFile("file", name)
io.Copy(ff, r)
mw.Close()
hc := http.Client{Timeout: time.Minute}
req, _ := http.NewRequest("POST", link, )
req.Header.Set("X-Key", "api-key")
req.Header.Set("Content-Type", mw.FormDataContentType())
start := time.Now()
resp, _ := hc.Do(req)
diff := time.Since(start)
defer resp.Body.Close()
if resp.StatusCode == http.StatusOK {
fmt.Printf("Upload OK, elapsed=%v\n", diff)
} else {
data, _ := ioutil.ReadAll(resp.Body)
fmt.Printf("Upload failed, elapsed=%v, http_code=%d, data=%s", diff, 
resp.StatusCode, data)

}
}

if compiled using Go 1.10.1, the client program uploads a test file 
about 4K in 250 milliseconds, while compiled using Go1.11, it costs 10 
seconds to upload! and the server is in local network.   Originally 
the client code uses io.Pipe to avoid memory consumption, in order to 
eliminate any improper use of pipe, I re-write it into the above 
version, no difference observed.   Also, after we spotted the problem, 
the server side code is also re-compiled using Go1.10, but still no 
difference. It seems only related to the client side.


Another important symptom is that the same compiled code, if running 
on another server (in the same LAN), the problem disappeared, yet 
another server will cost about 2 seconds.  That is to say, the problem 
has something to do with conditions of the server, probably some 
network issues we don't know yet. But the problem only occur with Go 1.11.


Is there anything changed in the http client library of 1.11 which may 
cause this problem?



Thank you!

Xiangrong
--
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] a potential problem with go1.11 HTTP library

[Steven Hartland]

Sounds like a broken DNS server on the machine, this was something I saw 
raised before. See the thread "Performance regression of HTTP requests 
since Go 1.11" for more information.


    Regards
    Steve

On 25/09/2018 08:36, Xiangrong Fang wrote:

I have a HTTP API and its client written in Go. The client side code is:

func upload(link, dir, name string, r io.Reader) {
var buf bytes.Buffer
mw := multipart.NewWriter()
mw.WriteField("dir", dir)
mw.WriteField("name", name)
ff, _ := mw.CreateFormFile("file", name)
io.Copy(ff, r)
mw.Close()
hc := http.Client{Timeout: time.Minute}
req, _ := http.NewRequest("POST", link, )
req.Header.Set("X-Key", "api-key")
req.Header.Set("Content-Type", mw.FormDataContentType())
start := time.Now()
resp, _ := hc.Do(req)
diff := time.Since(start)
defer resp.Body.Close()
if resp.StatusCode == http.StatusOK {
fmt.Printf("Upload OK, elapsed=%v\n", diff)
} else {
data, _ := ioutil.ReadAll(resp.Body)
fmt.Printf("Upload failed, elapsed=%v, http_code=%d, data=%s", diff, 
resp.StatusCode, data)

}
}

if compiled using Go 1.10.1, the client program uploads a test file 
about 4K in 250 milliseconds, while compiled using Go1.11, it costs 10 
seconds to upload! and the server is in local network.   Originally 
the client code uses io.Pipe to avoid memory consumption, in order to 
eliminate any improper use of pipe, I re-write it into the above 
version, no difference observed.   Also, after we spotted the problem, 
the server side code is also re-compiled using Go1.10, but still no 
difference. It seems only related to the client side.


Another important symptom is that the same compiled code, if running 
on another server (in the same LAN), the problem disappeared, yet 
another server will cost about 2 seconds.  That is to say, the problem 
has something to do with conditions of the server, probably some 
network issues we don't know yet. But the problem only occur with Go 1.11.


Is there anything changed in the http client library of 1.11 which may 
cause this problem?



Thank you!

Xiangrong
--
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] Test caching unexpectedly disabled by -exec

[Steven Hartland]

On 24/08/2018 18:00, Ian Lance Taylor wrote:

On Fri, Aug 24, 2018 at 8:31 AM, Steven Hartland  wrote:

Hi all I've just been banging my head why test our linux test env isn't
caching tests and found that its down to -exec.

The docs (https://golang.org/cmd/go/#hdr-Build_and_test_caching) refer to
cacheable "test" flags but doesn't mention standard non-test flags.

In addition to this GODEBUG=gocachetest=1 reports all cases where it
disables caching except when there is a execCmd which simply skips setting
-test.testlogfile:
https://github.com/golang/go/blob/master/src/cmd/go/internal/test/test.go#L1107

This was the most frustrating part as it meant hacking the runtime to figure
out why caching was not working.

So two question:

Is disabling test caching with -exec really intended and why?
Would it be acceptable to have to option to cache with -exec?

In terms of background, we use -exec so we change the binary permissions so
the tests run correctly, it changes CAP's, without which the test wont run.

I'm sorry you had to hack the runtime, but I do want to mention that
this is documented at https://golang.org/cmd/go/#hdr-Test_packages:

 The rule for a match in the cache is that the run involves the
same test binary and the flags on the command line come entirely from
a restricted set of 'cacheable' test flags, defined as -cpu, -list,
-parallel, -run, -short, and -v. If a run of go test has any test or
non-test flags outside this set, the result is not cached.

To me it seems reasonable that we should be able to cache test results
if -exec is specified, though of course it means that the cache would
need to include the -exec argument in the cache key.  I suggest that
you open a feature request for that at https://golang.org/issue.
Thanks.

Ian

Thanks for the feedback Ian.

Issue https://golang.org/issue/27207 raised, as you've see, and PR to 
fix also pushed https://go-review.googlesource.com/c/go/+/131415


Fix was simple in the end as ExecCmd is already included in the 
cache.ActionID for tests, so only required removing the extra condition 
from builderRunTest and docs update, reviews appreciated.


    Regards
    Steve

--
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] Test caching unexpectedly disabled by -exec

[Steven Hartland]

Hi all I've just been banging my head why test our linux test env isn't 
caching tests and found that its down to -exec.


The docs (https://golang.org/cmd/go/#hdr-Build_and_test_caching) refer 
to cacheable "test" flags but doesn't mention standard non-test flags.


In addition to this GODEBUG=gocachetest=1 reports all cases where it 
disables caching except when there is a execCmd which simply skips 
setting -test.testlogfile:

https://github.com/golang/go/blob/master/src/cmd/go/internal/test/test.go#L1107

This was the most frustrating part as it meant hacking the runtime to 
figure out why caching was not working.


So two question:

1. Is disabling test caching with -exec really intended and why?
2. Would it be acceptable to have to option to cache with -exec?

In terms of background, we use -exec so we change the binary permissions 
so the tests run correctly, it changes CAP's, without which the test 
wont run.


    Regards
    Steve

--
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: AWS S3 Image Upload with Golang

[Steven Hartland]

If your file out code is above your original code snippet so you have 
something like:

https://play.golang.org/p/5MVxJamHy4c

Then one of the problems is the file pointer of "out" points to the end 
of your file not the beginning.


If you don't need the file on disk then something like the following 
should suffice:

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

    Regards
    Steve

On 16/08/2018 01:18, maks...@gmail.com wrote:

err = out.Close()
if err != nil {
fmt.Println(err)
}

When I add this code after the io.Copy line, it gives me this error 
(attached screenshot to the email). It says upload multipart failed, 
failed to compute body hashes, and file already closed. I moved both 
the file.Close() and out.Close() lines to be after the io.Copy but I 
still got the same error.


On Wednesday, August 15, 2018 at 10:00:23 AM UTC-7, Ingo Oeser wrote:

You seem to ignore the error from out.Close()

What is out.Close reporting after the io.Copy?

--
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] Golang package docs site sluggish recently

[Steven Hartland]

This seems to happening again :(

On 08/06/2018 12:26, Steven Hartland wrote:

Thanks Chris appreciated, does indeed to be quick again :)

    Regards
    Steve

On 08/06/2018 05:57, Chris Broadfoot wrote:
Should be fast again now. I'm not sure what happened, but it appears 
the site search index was missing for a previous deploy.


If godoc starts without a prebuilt search index, it scans $GOPATH to 
build a new index. That's pretty slow on Google App Engine, and by 
the time it would finish indexing the instance might have been 
killed. While it's indexing, it's presumably using a lot of I/O and 
CPU, slowing down user requests.


I've redeployed it, and it seems fast again (with search index 
present). We're going to look into why the deploy was bad when 
performed from my colleagues' machines. (We're also re-working the 
deploy scripts and moving them into the open-source repos.)


On Thu, Jun 7, 2018 at 4:26 PM, Shawn Milochik <mailto:shawn.m...@gmail.com>> wrote:


I've been experiencing this myself lately.

This is a great opportunity to remind everyone that you can run
godoc locally. For example:
    godoc --http=:8000

This will run it at http://localhost:8000/ for your convenience.
It's even better than the public one because it's guaranteed to
be your version, and it will show all your local packages as
well. ^_^


-- 
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout
<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 
<mailto: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] Error getting FormValue in MultipartForm http request in Go 1.10

[Steven Hartland]

Actually looks like its already fixed:
https://github.com/golang/go/issues/24041
https://github.com/golang/go/commit/f69ad10377b1817e3db57851226a23973caa584e

On 18/05/2018 13:06, mosalo...@gmail.com wrote:

Hi!
In version 1.9, I had no problem getting the FormValue in http request.
After upgrading to version Go 1.10 of FormValue is empty. Did I find 
the error? in module:

mine/multipart/formdata.go
/before/:
_, hasContentTypeHeader := p.Header["Content-Type"]
if *!*hasContentTypeHeader && filename == ""
/after/
_, hasContentTypeHeader := p.Header["Content-Type"]
if hasContentTypeHeader && filename == ""
began to work as I need
--
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] Error getting FormValue in MultipartForm http request in Go 1.10

[Steven Hartland]

Do you have a little reproduction case you can put on playground?

On 18/05/2018 13:06, mosalo...@gmail.com wrote:

Hi!
In version 1.9, I had no problem getting the FormValue in http request.
After upgrading to version Go 1.10 of FormValue is empty. Did I find 
the error? in module:

mine/multipart/formdata.go
/before/:
_, hasContentTypeHeader := p.Header["Content-Type"]
if *!*hasContentTypeHeader && filename == ""
/after/
_, hasContentTypeHeader := p.Header["Content-Type"]
if hasContentTypeHeader && filename == ""
began to work as I need
--
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] Possible issue with math.Floor on Linux

[Steven Hartland]

You could be seeing a side effect on fact that windows only ticks every
15ms.

On Fri, 4 May 2018 at 21:56, Andrei Avram 
wrote:

> This code is extracted from something real. Someone on the team noticed
> the unit tests (which I wrote on a Linux machine) were failing on their
> Windows machine.
> I'll continue studying this and come back if I find something new.
>
> Thank you both for your time, I appreciate it!
>
>
> On Friday, May 4, 2018 at 11:42:00 PM UTC+3, speter wrote:
>
>> To file a bug (and have it treated seriously) you would need to
>> demonstrate that it is causing problems in a program that actually does
>> something useful, not just a pathological code sample. My expectation would
>> be that once you start doing some real processing, the difference between
>> time.Now() invocations becomes non-zero, that is this "issue" doesn't
>> reproduce with "real" practical programs.
>>
>>
>> On Fri, May 4, 2018 at 10:26 PM, Andrei Avram 
>> wrote:
>>
>>> But I don't think it is because Windows is so much faster than Linux

>>>
>>> Yeah... :) I was exploring all cases.
>>>
>>>
>>>  and/or the way the time package implemented is different between
 Windows and Linux
>>>
>>>
>>> Could this be considered a possible Go bug and would it worth opening an
>>> issue on Github?
>>>
>>>
>>> On Friday, May 4, 2018 at 10:57:46 PM UTC+3, speter wrote:

 So on Linux it's working as expected. In the playground time is
 "virtual"; the start time is fixed and it doesn't progress unless you
 explicitly Sleep -- because you don't Sleep in your program, time.Now()
 returns the same time on both invocation.

 So the only slightly surprising part is that on Windows, time as
 measured by time.Now() doesn't progress between the two statements. But I
 don't think it is because Windows is so much faster than Linux. :) I'd
 guess this is because the way Windows manages time is different from how
 Linux manages it, and/or the way the time package implemented is different
 between Windows and Linux. The result of the cross-platform differences
 seems to be less precision on Windows -- at least in this specific 
 scenario.

 Peter


 On Fri, May 4, 2018 at 9:33 PM, Andrei Avram 
 wrote:

> Peter and Ian, you are both wright regarding the printing. Still, on
> Linux I have different values than on Go Playground.
>
> Regarding the speed, Peter, do you think that on Windows the two calls
> just run faster every time?
>
> On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:
>>
>> b is slightly less than 3 because there is a bit of time between the
>> two calls to time.Now().
>>
>> If you substitute this:
>> fmt.Printf("input: %20.18f\n", b)
>>
>> you get something like
>> input: 2.99965553350911
>>
>> HTH
>> Peter
>>
>> On Fri, May 4, 2018 at 7:26 PM, Andrei Avram 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Today I ran into a situation that is strange to me. I ran the
>>> following code on two Linux machines (go run floor.go), on two Windows
>>> ones, and on Go Playground.
>>>
>>> package main
>>>
>>> import (
>>> "time"
>>> "math"
>>> )
>>>
>>> func main() {
>>> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
>>> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
>>> a := 29030400
>>> b := float64(seconds) / float64(a)
>>>
>>> println("input:", b)
>>> println("floor:", math.Floor(b))
>>> }
>>>
>>> On Linux the output is:
>>>
>>> input: +3.00e+000
>>> floor: *+2.00e+000*
>>>
>>> On Windows and Playground:
>>>
>>> input: +3.00e+000
>>> floor: *+3.00e+000*
>>>
>>> As you can see, on Linux the floor value of float value 3 is rounded
>>> down to 2, while on Windows/Playground it's 3.
>>>
>>> The code was ran with Go 1.10 and 1.10.2.
>>>
>>> The system details of one of the Linux machines, as reported by "go
>>> bug":
>>>
>>> go version go1.10.2 linux/amd64
>>> GOARCH="amd64"
>>> GOBIN=""
>>> GOCACHE="/home/msd/.cache/go-build"
>>> GOEXE=""
>>> GOHOSTARCH="amd64"
>>> GOHOSTOS="linux"
>>> GOOS="linux"
>>> GOPATH="/home/msd/go/"
>>> GORACE=""
>>> GOROOT="/usr/local/go"
>>> GOTMPDIR=""
>>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>>> GCCGO="gccgo"
>>> CC="gcc"
>>> CXX="g++"
>>> CGO_ENABLED="1"
>>> CGO_CFLAGS="-g -O2"
>>> CGO_CPPFLAGS=""
>>> CGO_CXXFLAGS="-g -O2"
>>> CGO_FFLAGS="-g -O2"
>>> CGO_LDFLAGS="-g -O2"
>>> PKG_CONFIG="pkg-config"
>>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
>>> -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build

Re: [go-nuts] Re: About a channel detail, bug, defect, or intended?

[Steven Hartland]

You should use a wait group to guarantee the behaviour of this.

On Sat, 7 Apr 2018 at 12:54, T L  wrote:

>
>
> On Monday, March 26, 2018 at 4:09:24 PM UTC-4, Marvin Renich wrote:
>>
>> It seems that you understand why you are seeing the behavior you
>> reported, but you are questioning whether the spec either does or should
>> guarantee that reading from a channel with a goroutine waiting to send
>> on that channel will fill the buffer as an atomic part of the read.
>>
>> As others have said, the spec does not guarantee this.  I would like to
>> add that I believe it shouldn't.  Suppose goroutine A is currently
>> blocked waiting to send on a channel.  Now goroutine B reads from that
>> channel.  If the refill of the channel must happen atomically with the
>> read from that channel, now goroutine B must be put in a blocked state
>> waiting for goroutine A to finish its send.  This contradicts the spec
>> at [1] which states
>>
>>   ...communication succeeds without blocking if the buffer is not full
>>   (sends) or not empty (receives).
>>
>> If you think about how this is likely to be implemented (including
>> considerations for GOMAXPROC and multicore vs single core systems), you
>> should realize that, while it would be possible to implement
>> atomic-refill, it would give no (or very little) benefit and might have
>> undesirable performance effects.
>>
>> As an aside, I think the reason Jake is seeing 100 lines of output and
>> you only see 1 is likely to be the difference between GOMAXPROC=1 and
>> greater than 1.  If GOMAXPROC=1, the scheduler may force a running
>> goroutine to yield after receiving, but before returning from the
>> receive operation.  In other words, the receive happens without
>> blocking, but the scheduler thinks that is a convenient point for giving
>> another goroutine an opportunity to run.
>>
>
>
> No, I tried both GOMAXPROC=1 and GOMAXPROC=4. Same results.
>
> It is strange that I just tried it again, now there will be always 100
> lines outputted,
> for both GOMAXPROC=1 and GOMAXPROC=4, for both v1.10 and v1.10.1.
> Quite strange.
>
>
>>
>> ...Marvin
>>
>> [1] https://golang.org/ref/spec#Channel_types
>
>
>
>
> --
> 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: Scheduler discrepancy between Linux and OS X with Gosched()

[Steven Hartland]

What I found interesting is with this code run with raw on FreeBSD takes 
~1s, however running via truss to see what happening with the syscalls 
it takes only ~83ms e.g.


> ./tst
2018/04/03 21:53:28 Finished in 998.77123ms.
> truss -o t.txt ./tst
2018/04/03 21:53:31 Finished in 83.14988ms.

This only seems to effect really small duration's, time.Millisecond 
isn't effected, which is perplexing.


On 03/04/2018 21:24, jake6...@gmail.com wrote:
For what it is worth, when I run your new code (without channels) on 
windows it takes consistently 1 second. On Linux it takes variably 
between 400ms and 1.5 seconds. Both running go 1.10. But, on my 
systems, this seems to be actually measuring |time.Sleep()|. Removing 
the call to |spin()| and the second |runtime.Gosched() |results in the 
same times:


|
package main

import (
    "log"
    "runtime"
    "time"
)

func main() {
    runtime.GOMAXPROCS(1)

    t0 := time.Now()
    for i := 0; i < 1000; i++ {
        time.Sleep(1 * time.Microsecond)
    }

    log.Printf("Finished in %v.", time.Since(t0))
}
|

I can not speak for your original example, but in this one I would be 
looking to |time.Sleep()|.


- Jake


On Tuesday, April 3, 2018 at 2:12:40 PM UTC-4, brianbl...@gmail.com 
wrote:


Hi Dave, thanks for the reply!

It makes sense that the send c <- 0 is not guaranteed to transfer
control to the receiving goroutine. But is it not guaranteed that
runtime.Gosched() will at least check if another goroutine is
runnable? I thought that was roughly the point of runtime.Gosched().

I see what you're saying in that when the second goroutine calls
Gosched, the sleep period may not be finished. But this will only
waste another 100 microseconds by design (not 100 milliseconds),
so it seems like control flow should return to the main goroutine
approximately when the sleep call finishes.

I created a simpler example, that doesn't use channels and avoids
the work length ambiguity, posted below. Now the secondary
goroutine just does an infinite loop of runtime.Gosched(). It
should be instantaneous to run (and is on my Mac), but it takes
almost exactly 5 seconds on Ubuntu, suggesting that there is some
fixed 5 millisecond delay on Gosched(). And adding a print above
spin's Gosched makes it instantaneous.

Thanks for your patience! I'm working on an application where the
~5ms Gosched delay is meaningful and I am very curious to figure
out what's going on here.
|
package main

import (
    "log"
    "runtime"
    "time"
)

func spin() {
    for {
        runtime.Gosched()
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go spin()

    t0 := time.Now()
    for i := 0; i < 1000; i++ {
        time.Sleep(10 * time.Microsecond)

        runtime.Gosched()
    }

    log.Printf("Finished in %v.", time.Since(t0))
}
|


On Tuesday, April 3, 2018 at 12:56:49 AM UTC-4,
brianbl...@gmail.com wrote:

I've run into some mysterious behavior, where Gosched() works
as expected in Mac OS X, but only works as expected in Ubuntu
if I put a logging statement before it.

I originally posted this on Stack Overflow but was directed
here. Post:

https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x



Any help would be greatly appreciated! Very curious what's
going on here, as this behavior came up while I was trying to
write a websocket broadcast server. Here's a minimal setup
that reproduces the behavior:

The main goroutine sleeps for 1000 periods of 1ms, and after
each sleep pushes a dummy message onto another goroutine via a
channel. The second goroutine listens for new messages, and
every time it gets one it does 10ms of work. So without any
|runtime.Gosched()| calls, the program will take 10 seconds to
run.

When I add periodic |runtime.Gosched()| calls in the second
goroutine, as expected the program runtime shrinks down to 1
second on my Mac. However, when I try running the same program
on Ubuntu, it still takes 10 seconds. I made sure to set
|runtime.GOMAXPROCS(1)| in both cases.

Here's where it gets really strange: if I just add a logging
statement before the the |runtime.Gosched()| calls, then
suddenly the program runs in the expected 1 second on Ubuntu
as well.


|packagemain import("time""log""runtime")func doWork(c chan
int){for{<-c // This outer loop will take ~10ms.forj :=0;j
<100;j++{// The following block of CPU work takes ~100
microsecondsfori :=0;i <30;i++{_ =i *17}// Somehow this
print statement saves the day in

Re: [go-nuts] API fixes for sync.Mutex and friends?

[Steven Hartland]

The various meta linters pick this up.

I would highly recommend using: 
https://github.com/alecthomas/gometalinter to improve the quality of 
code, for this and other issues not picked up by the standard tool chain.


    Regards
    Steve

On 03/04/2018 00:37, Andrew Pennebaker wrote:
Some Go types like sync.Mutex have a subtle API issue, where the 
objects really shouldn't be copied or passed around into different 
function calls, e.g. to a goroutine worker. However, this is not 
enforced by the current API, but merely mentioned in the 
documentation, which is easily ignored.


Is there a way to better protect these types, so that users can't 
accidentally copy and corrupt them? Maybe a linter or the Go compiler 
could check for these types being passed in non-pointer form to 
function calls. I wonder if this problem still appears in Rust, or if 
the borrow checker could model this API distinction more safely and 
automatically?

--
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] Appreciating Go

[Steven Hartland]

On 22/02/2018 09:46, andrewchambe...@gmail.com wrote:

Just a list of things I like about Go, thanks everyone for the hard work:

snip...

Minor things that could be improved in order of importance:

- Ways to express immutability ... as a concurrent language it can 
still be easy to make mistakes and share a buffer or slice by accident.
- More advanced static analysis tools that can prove properties of 
your code (perhaps linked with the above).

Have you seen: https://github.com/alecthomas/gometalinter

- Generics.
- Some sort of slightly more sophisticated pattern matching .
Not sure what you mean here but have you seen: 
https://golang.org/pkg/regexp/


--
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] syscall.SetNonblock stopped working in Go 1.9.3

[Steven Hartland]

I checked this on FreeBSD and it still works, so seems like it could be 
a macOS specific issue.


You should raise a bug here:
https://github.com/golang/go/issues

It would be good to try and identify the go version which it first broke 
in too, as that will be helpful in identifying the change which cause 
the regression.


    Regards
    Steve

On 25/01/2018 04:06, Dave Keck wrote:
Hey all, this program exits (as expected) when run with macOS 10.12.6 
+ Go 1.8.6, but it deadlocks when run with Go 1.9.3:


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

The same behavior is observed when using unix.SetNonblock instead of 
syscall.SetNonblock.


It appears that the SetNonblock() functions don't have an effect in Go 
1.9.3. Is this a known issue?


Thanks!
David
--
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] [ANN] gometalinter v2.0.0 released - much faster linting

[Steven Hartland]

On 05/12/2017 05:16, Alec Thomas wrote:

Hello,

Through the efforts of many contributors, and in particular those of 
Daniel Nephin, v2.0.0 has been released. You can grab it here:


  https://github.com/alecthomas/gometalinter/releases/tag/v2.0.0

The biggest change since v1.x is that linting is now MUCH more 
efficient, thanks to the changes by Daniel. Instead of invoking each 
linter for every directory, linters are invoked the minimum number of 
times necessary by passing as many directories, packages or files as 
they will accept in a single invocation.


The configuration format has also changed, but should be mostly 
backwards compatible.


Another major change is that from now on we will be releasing binary 
packages. This also means that: gometalinter's management of linter 
installation will soon be deprecated, and eventually removed, and that 
gopkg.in will no longer be used.


Going forward we have several interesting things planned for gometalinter:

1. Support for in-process invocation of linters via an interface + 
adapters. See https://github.com/alecthomas/gometalinter/issues/380. 
This should make linting even more efficient, as packages will only 
need to be parsed/compiled once, and the FileSet (etc.) can be reused.
2. Configuration handling will be rewritten/rethought. This will 
encompass automatic .gometalinterrc loading, among other things.
This is great news Alex, thanks for everyone's hard work #2 
(.gometalinterrc loading) is the killer feature for us.


Currently we have to invoke gometalinter for each package on the command 
line separately, which prevents any benefits of v2. speedup.



3. Lots of internal refactoring to clean up the codebase.

As always, if you encounter any problems please create a new issue.



    Regards
    Steve

--
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] graceful restart of app with more than one tcp Listener

[Steven Hartland]

There are a number of libraries which attempt to address this, ones I've 
seen:


 * https://github.com/fvbock/endless
 * https://github.com/rcrowley/goagain
 * https://github.com/facebookgo/grace


On 07/11/2017 13:33, Vasiliy Tolstov wrote:

Hi! I have application that listens 2-4 tcp ports and i need to
upgrade it while running. How can upgrade server and not dropping
exiting connected apps (tcp nbd-client like apps)?
I don't want to use haproxy or nginx before my app.
As i understand i need master process that only listens sockets and
fork child app and pass to it accepted connections.
So i can upgrade by passing listening fd to new master process and
forward new tcp connections to new child? But what can i do with
already connected clients to previous child process?
Does it possible to do what i need and not dropping exiting tcp connections?



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

Re: [go-nuts] A way to detect closed channel

[Steven Hartland]

If you're using it as a signal to trigger only on close and not sending 
any data, you should use chan struct{}, the reason for this is is that 
the empty struct consumes zero storage 
.


Also there is a multi-valued assignment form of the receive operator 
, which reports whether a 
received value was sent before the channel was closed.


Dave Cheney's article curious channels 
 is also relate so 
worth a read.


    Regards
    Steve

On 07/11/2017 00:59, Albert Tedja wrote:
So, I just found out that closed channels always yield the zero value. 
That means, a closed channel inside a select statement seems to always 
be guaranteed to be executed.


Since closing an already closed channel creates a panic, does this 
mean then I can do this to make sure that the channel is closed only once?



|
select{
case<-closedchan:
default:
        close(closedchan)
}
|



Golang playground: https://play.golang.org/p/LSrTh0HC2K

It seems to work. Just want to confirm here before start doing this 
everywhere in my code.

--
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: Binary Download

[Steven Hartland]

We also had Auth issues:
=> Attempting to fetch http://golang.org/dl/go1.9.2.src.tar.gz
SSL certificate subject doesn't match host r16---sn-aigllnds.gvt1.com
fetch: http://golang.org/dl/go1.9.2.src.tar.gz: Authentication error

On 26/10/2017 10:54, paul.totter...@gmail.com wrote:


Tried to update to 1.9.2 and 1.8.5 with godeb. Oops "no downloads
found"  Downloads only through a redirector.
https://redirector.gvt1.com/edgedl/go/go1.9.2.linux-386.tar.gz

whois GVT1.COM  returns Registrar URL:
http://www.markmonitor.com. Can sombody point me to the discussion
about this change?


whois gvt1.com returns quite a bit for me, including:

 Registrant Name: DNS Admin
Registrant Organization: Google Inc.
Registrant Street: 1600 Amphitheatre Parkway
Registrant City: Mountain View
Registrant State/Province: CA
Registrant Postal Code: 94043
Registrant Country: US
Registrant Phone: +1.6506234000
Registrant Phone Ext:
Registrant Fax: +1.6506188571
Registrant Fax Ext:
Registrant Email: dns-ad...@google.com

Cheers,
Paul
--
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] Weird stack overflow error for struct with interface in it (a golang bug? )

[Steven Hartland]

Which then calls the function your in, which then creates another 
variable BOOM!


On 29/09/2017 00:15, Yaroslav Molochko wrote:

But I'm using other variable not the one I'm unmarshaling to:

var ts Result
err := json.Unmarshal(b, )



On Friday, September 29, 2017 at 2:10:25 AM UTC+3, Steven Hartland wrote:

You created an infinite recursion by calling Unmarshal on the same
type your unmarshalling, hence the stack overflow error.

On 28/09/2017 23:59, Yaroslav Molochko wrote:

Here is the code which runs:

https://play.golang.org/p/ds3KZspFvE
<https://play.golang.org/p/ds3KZspFvE>

If you press play, it will work fine and gives an expected output,

 as soon as you uncomment  this part:
/*
func (u *Result) UnmarshalJSON(b []byte) error {
var ts Result
err := json.Unmarshal(b, )
if err != nil {
fmt.Println(err)
}
return nil
}
*/

which basically does nothing, you will get:
https://play.golang.org/p/Y9NTzpwyQy
<https://play.golang.org/p/Y9NTzpwyQy>


runtime: goroutine stack exceeds 25000-byte limit fatal
error: stack overflow runtime stack: runtime.throw(0x122c5a, 0xe)
/usr/local/go/src/runtime/panic.go:605 +0x100
runtime.newstack(0x0, 0x0)
/usr/local/go/src/runtime/stack.go:1050 +0x960
runtime.morestack() /usr/local/go/src/runtime/asm_amd64p32.s:378
+0xa0

Anyone knows how to solve it?
-- 
You received this message because you are subscribed to the

Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to golang-nuts...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout
<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 
<mailto: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] Weird stack overflow error for struct with interface in it (a golang bug? )

[Steven Hartland]

You created an infinite recursion by calling Unmarshal on the same type 
your unmarshalling, hence the stack overflow error.


On 28/09/2017 23:59, Yaroslav Molochko wrote:

Here is the code which runs:

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

If you press play, it will work fine and gives an expected output,

 as soon as you uncomment  this part:
/*
func (u *Result) UnmarshalJSON(b []byte) error {
var ts Result
err := json.Unmarshal(b, )
if err != nil {
fmt.Println(err)
}
return nil
}
*/

which basically does nothing, you will get:
https://play.golang.org/p/Y9NTzpwyQy


runtime: goroutine stack exceeds 25000-byte limit fatal error: 
stack overflow runtime stack: runtime.throw(0x122c5a, 0xe) 
/usr/local/go/src/runtime/panic.go:605 +0x100 runtime.newstack(0x0, 
0x0) /usr/local/go/src/runtime/stack.go:1050 +0x960 
runtime.morestack() /usr/local/go/src/runtime/asm_amd64p32.s:378 +0xa0


Anyone knows how to solve it?
--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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] Best practices for internal repository management

[Steven Hartland]

We had issues with ensuring that cross dependencies worked correctly when
working with lots of independent repos, so we currently use a single repo.

The main issue we see now is all go dependency managers we’ve tried have
problems. We currently use glide which seems to be the best of the bunch.

So we’d also be interested to here what others use.

On Fri, 22 Sep 2017 at 18:25, Shawn Milochik  wrote:

> I'm also interested in hearing opinions on this. We do the latter (many
> repos), and have over 250 of them. This causes some difficulties,
> especially because Github's search *sucks*[1].
>
> Onboarding: People need to *find out about *the repos they need, have
> permission to access them, etc.
> Reading code: If you're looking at a part of the code you haven't looked
> at before, you may have stop to clone a repo.
> Searching: Interested in which services import your package? Github's
> search is *useless[1]*. grep/ack-grep/suchen are great, but you have to
> have everything cloned.
> Keeping up-to-date: Try having 250+ repos checked out locally and have the
> latest version checked out. Requires an automated process all on its own.
>
> I like the idea of a monorepo. Keeping internal and vendored packages in
> one place with a single command to test/build everything to prove you
> haven't broken others' work. Other than the sheer size and the extra
> coordination that has to go into preventing/resolving merge conflicts, are
> there any big downsides?
>
>
> [1] https://help.github.com/articles/searching-code/ They delete/ignore
> special characters, making it almost impossible to find anything across
> repos (or even within them). Forget a regex search... WTF
>
> --
> 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] golang and linking

[Steven Hartland]

Does quoting the flags work?

On 21/09/2017 23:25, willow.pine.2...@gmail.com wrote:
Hi, I have a project which requires multiple --ldflags or -ldflags. I 
noticed that go build only uses the last --ldflags of the commandline. 
Is there a way to pass multiple --ldflags and have them all be in effect?


Thanks.

Will


--
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] Forcing multiple HTTP/2 connections to a single server?

[Steven Hartland]

We're looking to upgrade one of our services to enable TLS however as 
soon as we do that the services also going to switch to HTTP/2 which is 
good apart from for this service which requires multiple TCP connections 
to eliminate BDP issues when performing bulk downloads; think parallel 
downloads reassembled on the fly to a single stream.


Now with HTTP/2 I believe its going to try and multiplex all requests 
over the same TCP connection and hence the throughput for the download 
requests is going to plummet compared to HTTP/1 due to BDP.


We could disable HTTP/2 by setting Server.TLSNextProto to nil, but we 
would like to use HTTP/2 for all the other requests.


Prior to the following commit it looked like this was possible by 
setting MaxConcurrentStreams to 1 for the download requests, however 
after it the RoundTrip will just block until a scream is available, 
preventing any concurrency.

https://github.com/golang/net/commit/1c05540f6879653db88113bc4a2b70aec4bd491f

The issue which triggered this changes was originally raised by Brad here:
https://github.com/golang/go/issues/13774

I suspect this use case was never identified prior to making this change?

So the question is how do we force multiple HTTP/2 connections to a 
single server for a specific endpoint?


    Regards
    Steve

--
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: Retrieve Unknown Rows & Columns From a MySQL Table (Golang)

[Steven Hartland]

QueryRow(..) returns a *Row but you then chained a .Scan(..) which 
returns an error as compile error suggests.


I'm guessing you want rows, if so have a look at:
https://golang.org/pkg/database/sql/#DB.Query

On 15/09/2017 03:10, Alexandre K wrote:

Thank you so much for your response!

The code you added probably works, but I'm getting held up by 
something else.


I'm running into a set of errors when I execute this on the command 
line...It seems the "rows" value I'm creating doesn't have the 
functionality that the guide says it would


|
# command-line-arguments
./2multi.go:22: rows.Columns undefined (type error has no field or 
method Columns)
./2multi.go:30: rows.Next undefined (type error has no field or method 
Next)
./2multi.go:34: rows.Scan undefined (type error has no field or method 
Scan)

|
Here's an updated version of my code

package main
import (
"database/sql"
"fmt"
"log"
        _ "github.com/go-sql-driver/mysql"
)
func main() {
//Connect to database and check for errors
db, err := sql.Open("mysql",
"script:script1!@tcp(10.14.0.173:3306)/dbaTesting")
if err != nil {
               log.Println(err)
       }
var str string
rows := db.QueryRow("SELECT * FROM animals").Scan()
cols, err := rows.Columns() // Remember to check err afterwards
if err != nil {
               log.Fatal(err)
       }
vals := make([]interface{}, len(cols))
for rows.Next() {
for i := range cols {
           vals[i] = [i]
               }
       err = rows.Scan(vals...)
// Now you can check each element of vals for nil-ness,
if err != nil {
               log.Fatal(err)
       }
for i := range cols {
                   fmt.Println(vals[i])
                }
       }
}


Shouldn't the value I create in "rows" be able to pass arguments to 
the "db" class I'm referencing when I'm creating "rows?"

--
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: Splitting CamelCaseWords in Go

[Steven Hartland]

You other option is:
splittable == v != ' ' && v == unicode.ToLower(v), depends what you want 
to happen with non-word characters?


On 06/09/2017 16:15, Michael Jones wrote:

Precisely, though probably a renaming is in order:
https://play.golang.org/p/AZ7Ptg4HYP

On Wed, Sep 6, 2017 at 6:58 AM, Steven Hartland 
<ste...@multiplay.co.uk <mailto:ste...@multiplay.co.uk>> wrote:


Numbers don't match IsLower so how about:
https://play.golang.org/p/Z6q9dJZ7QK
<https://play.golang.org/p/Z6q9dJZ7QK>



--
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: Splitting CamelCaseWords in Go

[Steven Hartland]

Numbers don't match IsLower so how about:
https://play.golang.org/p/Z6q9dJZ7QK

On 06/09/2017 14:12, Tong Sun wrote:

Almost, https://play.golang.org/p/6Zl_EKqFqT
But thanks a lot! It's significantly shorter/better than my initial 
version.


On Tue, Sep 5, 2017 at 6:18 PM, Michael Jones > wrote:


Like this?

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


On Tue, Sep 5, 2017 at 12:33 PM, Tong Sun > wrote:


I'll be religiously avoiding "*unicode.IsUpper*()" as
something mystery happened in the past:
https://groups.google.com/d/msg/golang-nuts/714WQs85H3w/KEqKgmAqAAAJ


BTW, /for my case/, I do need the string,

"FooBarBaz GNU PYTHON Standard"

to be split exactly to be

"Foo Bar Baz GNU PYTHON Standard"

I.e., 6 words altogether, no more spacing than this.

thanks again for helping and showing me you benchmark code.


On Tue, Sep 5, 2017 at 1:35 PM, Florian Florensen
> wrote:

I've just joined the group and had to get activated,
that's why my answer took so long. Should have waited
until then.

Thank you for the notice! I fixed it in the playground:
https://play.golang.org/p/kuk6FxesDq
.
Although I wrote a benchmark
(https://play.golang.org/p/YpnI257SHD
), I didn't write
tests. Sorry for that!

I still would use Seths version, since it correctly splits
uppercase-words like CAMELCase to ["C" "A" "M" "E" "L"
"Case"].

Am Dienstag, 5. September 2017 03:43:22 UTC+2 schrieb Tong
Sun:

Oh thanks a lot Florian!

I wished I had received it earlier (my email header
said, Created at: Sun, Sep 3, 2017 at 6:03 PM
(Delivered after 89531 seconds)), because my own
version is embarrassingly complicated:


https://github.com/go-dedup/text/blob/3d0d998bef3db3937496933778c55e4f01cab5e4/text.go#L37-L60



I'll go with the simple camelRegexp, because to be
fair, the camelAppend is not handing the cases
that camelRegexp is handling, e.g., "FooBarBaz GNU
PYTHON Standard", and I'll make it not inserting space
if there is already one there...

PS. did you have to write extra code (not published
here) to use `go test -bench=.`?

thx



On Sun, Sep 3, 2017 at 6:03 PM, Florian Florensen
 wrote:

Hi, two approaches would be:

|
func camelAppend(str string)string{
  w :=[]rune(str)
fori :=len(w)-1;i >1;i--{
ifunicode.IsUpper(w[i]){
      w =append(w[:i],append([]rune{' '},w[i:]...)...)
}
}
returnstring(w)
}
|

|
func camelRegexp(str string)string{
  re :=regexp.MustCompile(`([A-Z]+)`)
  str =re.ReplaceAllString(str,` $1`)
  str =strings.Trim(str," ")
returnstr
}
|

|
$ go test -bench=.
goos:darwin
goarch:amd64
BenchmarkCamelAppend-4300444ns/op
BenchmarkCamelRegexp-42011224ns/op
PASS
|


Am Sonntag, 3. September 2017 23:23:59 UTC+2
schrieb Tong Sun:

Hi,

I need to split "CamelCaseWords" into
individual words like "Camel Case Words".
The following is the Perl code that I get for
doing just that:

|
@words=$words[0]=~/[A-Z][^A-Z]*/g
if@words==1&&$words[0]=~/^[A-Z]/;
|

However, I've been staring at it long enough
to confirm myself that I really don't quite
understand how it was done.

Anyway, I'm wondering what's the neat way to
   

Re: [go-nuts] Upload File Size Limit in Go 1.9

[Steven Hartland]

Sorry I was unclear, you are right, my intention was to identify where 
standard form size limiting is done for multipart/form-data POST requests.


There is also a limit placed on "application/x-www-form-urlencoded" for 
POST requests unless the request body is already limited by 
MaxBytesReader, as detailed here:

https://golang.org/pkg/net/http/#Request.ParseForm
https://golang.org/pkg/net/http/#MaxBytesReader

MaxBytesReader can be used in all cases to limit the total size of the 
form processed, so that may be an option.


If the OP does indeed want per file configurable upload limits then I 
don't think that's trivial and would likely require a custom 
mime/multipart reader.


On 30/08/2017 11:24, Lutz Horn wrote:
Limiting is done by the form parse: 
https://golang.org/pkg/net/http/#Request.ParseMultipartForm


No, this is not limiting:


The whole request body is parsed and up to a total of maxMemory bytes
of its file parts are stored in memory, with the remainder stored on
disk in temporary files. ParseMultipartForm calls ParseForm if
necessary.


This is just offloading to disk. The whole request including all 
complete body parts is still parsed and available.


Unless the OP tells us what kind of limiting he has in mind, it is 
hard to give advice.


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] Upload File Size Limit in Go 1.9

[Steven Hartland]

Limiting is done by the form parse:
https://golang.org/pkg/net/http/#Request.ParseMultipartForm

On 29/08/2017 20:40, Andrew wrote:
Go 1.9 has "The new |FileHeader.Size| 
 field 
describes the size of a file in a multipart message."


Suppose I upload multiple files using *multiple*>


Can I use FileHeader.Size to limit *each* uploaded file size? Or 
there's other ways?


Thanks,
Andrew

--
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: [golang-dev] Go 1.9 is released

[Steven Hartland]

On 25/08/2017 17:39, Ian Lance Taylor wrote:

On Fri, Aug 25, 2017 at 1:53 AM, Steven Hartland <ste...@multiplay.co.uk> wrote:

One thing I've noticed, having read through the blog post and release notes,
is a mention of the issue with the netpoller is surprisingly absent.

This issue has bitten us quite a bit, only tracked it down this week, so
would have expected to see this one to mentioned given it can and does cause
TCP connections from the runtime to fail randomly; something worth adding?

In general we don't mention every bug fix in the release notes, and
this one is fairly uncommon, and I think mainly occurs when trying to
connect to a TCP port on which nothing is listening.  That said, if
you want to send in a patch for the release notes, that would be fine.
Thanks.

Ian
Thanks for the response Ian, if this was rare here I would agree, but 
prior to deploying a 1.9 build, we were experiencing this many times a 
day on a reconciliation daemon we have which talks to GCE API so we 
believe its more common than people may think.


My guess would be there aren't more reports because its hard to track 
and people just retry assuming its a network glitch.


I'll look to create a patch.

    Regards
    Steve

--
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: [golang-dev] Go 1.9 is released

[Steven Hartland]

Thanks for everyone's hard work on this!

One thing I've noticed, having read through the blog post and release 
notes, is a mention of the issue with the netpoller 
 
is surprisingly absent.


This issue has bitten us quite a bit, only tracked it down 
 this week, 
so would have expected to see this one to mentioned given it can and 
does cause TCP connections from the runtime to fail randomly; something 
worth adding?


    Regards
    Steve

On 24/08/2017 23:43, Chris Broadfoot wrote:

Hello gophers,

We just released Go 1.9.

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

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

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


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

Thanks to everyone who contributed to the release.

Chris
--
You received this message because you are subscribed to the Google 
Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-dev+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] Golang 1.9 release ETA update?

[Steven Hartland]

On 23/08/2017 23:16, Ian Lance Taylor wrote:

On Wed, Aug 23, 2017 at 1:23 AM, Steven Hartland <ste...@multiplay.co.uk> wrote:

Hi guys I see there's three issues still pending in the 1.9 milestone. The
one being at test case failure on darwin which now has a skip in and the
other two are doc fixes, so I was wondering if we have a likely release date
yet?

The reason I ask is our production system is being hit regularly by net:
handle spurious netpoll wakeups in connect while using the
google-api-go-client so we're considering if we need to do a custom build of
1.8 with the aforementioned fix or if we should wait for 1.9 if its very
imminent.

1.9 is very imminent.

Ian
Thanks Ian, we where looking at Dave's suggestion of using 1.9rc2 but 
we'll hold of if that's case.


    Regards
    Steve

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