Re: [go-nuts] help

['Brian Candler' via golang-nuts]

Your code includes this line:
log.Println("DATABASE_URL:", os.Getenv("DATABASE_URL"))
What does the log message actually show? This will confirm whether the 
environment variable is being passed correctly or not.

I note you are using a different YAML structure for "environment" under 
go_app than under go_db. The first uses a list, the second uses a map. 
However, the compose v3 spec says that both are 
fine: https://docs.docker.com/compose/compose-file/compose-file-v3/#environment

To be sure, you could try

environment:
DATABASE_URL: "host=go_db port=5432 user=postgres password=postgres 
dbname=go_db sslmode=disable"

On Sunday 18 February 2024 at 09:57:20 UTC Steven Hartland wrote:

> 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(&u.ID, &u.Name, &u.Email); 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(&u.ID, 
>> &u.Name, 
>> &u.Email)
>> 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(&u)
>>
>> err := db.QueryRow("INSERT INTO users (name, email) VALUES ($1, $2) 
>> RETURNING id", u.Name, u.Email).Scan(&u.ID)
>> 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(&u)
>>
>> 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(&u.ID, 
>> &u.Name, 
>> &u.Email)
>> if err != nil {
>> w.WriteHeader(http.StatusNotFound)
>> return
>> } else {
>> _, err := db.Exec("DELETE FROM users WHERE id =

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(&u.ID, &u.Name, &u.Email); 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(&u.ID, 
> &u.Name,
> &u.Email)
> 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(&u)
>
> err := db.QueryRow("INSERT INTO users (name, email) VALUES ($1, $2)
> RETURNING id", u.Name, u.Email).Scan(&u.ID)
> 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(&u)
>
> 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(&u.ID, 
> &u.Name,
> &u.Email)
> 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 

Re: [go-nuts] help

[Luca Pascali]

Hi.

Error says that the connection string that is executed is pointing to TCP
127.0.0.1:5432
from your docker compose file there is no such string, you are correctly
using go_db host name to work inside the docker network.

So my guess is that you are not executing what you think you are executing

3 hypotesis:
+ in the docker image that is created for app you are launching a bash file
that overrides the environment variable (easy to find: look at the content
and look for 127.0.0.1 or DATABASE_URL)
+ you introduced the environment variable and just forgot to rebuild the
container (can happen, it happens, no shame)
+ the real code tries to connect (probably somewhere else) to 127.0.0.1 in
a block of code that you forgot to cancel/delete/modify to use environment
variables

If launched manually, it honors the environment variable. At least the
block of code you posted.
So my thoughts are that there's something around it or in the real code

Hope that this can help

Suggestion: put a dependency clause, to be sure to start db before the app,
and consider some retries.
DB does not start immediately. It can run some more task at power on that
can delay the effective startup by some seconds.

Usually you say that go_db must be started before starting go_app and
inside go_app you try multiple times (or retry if db shuts down and
restarts during the app execution), but this depends on the type of
application you are writing.
24/7 application should (I would say "must") consider some db downtime
without crashing. Personal home application can be less refined.

PSK

On Sun, Feb 18, 2024 at 5:55 AM 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(&u.ID, &u.Name, &u.Email); 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(&u.ID, 
> &u.Name,
> &u.Email)
> 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(&u)
>
> err := db.QueryRow("INSERT INTO users (name, email) VALUES ($1, $2)
> RETURNING id", u.Name, u.Email).Scan(&u.ID)
> 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(&u)
>
> vars := mux.Vars(r)
> id := vars["id"]
>
> _, err := db

Re: [go-nuts] help

[Sunday Ajayi]

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(&u.ID, &u.Name, &u.Email); 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(&u.ID, &u.Name,
&u.Email)
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(&u)

err := db.QueryRow("INSERT INTO users (name, email) VALUES ($1, $2)
RETURNING id", u.Name, u.Email).Scan(&u.ID)
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(&u)

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(&u.ID, &u.Name,
&u.Email)
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 am I getting it wrong?

Regards


*AJAYI Sunday *
(+234) 806 771 5394
*sunnexaj...@gmail.com *



On Sat, Feb 17, 2024 at 11:38 PM Pilar Garcia 
wrote:

> hi everyone. my name is pilar. im trying to learn coding for the first
> time in my life..im so lost can anyone let me know how to even
> begin on this mission. please any advise will be greatly
> appreciated. you folks have a great day cant waint to hear from ya
>
> --
> You received this message because you are subscribed to the Google Groups
> "gol

Re: [go-nuts] help with thread limit

[Robert Engels]

You can use cpuctrl or similar to limit the number of visible cores when you start the process. On Jan 31, 2024, at 8: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/CAAnpqKHvfni_U%2BkCHp0hhUryDytPzQ%2BSqHZTcAFH9HNXgRCy_A%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/51EA8D38-5882-4F9B-A660-6E47627C5846%40ix.netcom.com.

Re: [go-nuts] Help understanding slices, variable arguments, and passing slices to functions

[Jan Mercl]

On Mon, Sep 25, 2023 at 1:57 PM Andrew Pillar  wrote:

A nice discussion of slices can be found for example here:
https://research.swtch.com/godata

tl;dr: Yes, slices are passed by value (everything in Go is passed by
value), but a slice does not contain the backing array, only a pointer
to it.

-j

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

Re: [go-nuts] Help me study resources or guides

[Marcello H]

You could take a look at:
https://mehdihadeli.github.io/awesome-go-education/


Op dinsdag 23 mei 2023 om 14:33:18 UTC+2 schreef Zhang Jie (Kn):

> 1. https://go101.org, from beginner to true gopher
> 2. go perf book, search it from github, this will teach you some 
> optimization techniques
> 3. here's a reading list about golang internals: 
> https://hitzhangjie.notion.site/149643669e0846e6b8e3294d04a6df0d?v=e1cea88688ec4102ae5d9af8cf9ac4c7
> ,
> actually, there's some Chinese golang books that describe the 
> internals, like go语言设计实现，go语言原本. Even though they're good, but there's 
> already many good articles, I keep updating this reading list.
> 4. 100-go-mistakes, this book will show you common mistakes among gophers, 
> and it will make you understand golang better.
>
> On Wednesday, May 3, 2023 at 9:14:40 PM UTC+8 Kamil Ziemian wrote:
>
>> Hello,
>>
>> I now try to read "Go Language Specification", which you must read to 
>> became true Gopher. If you want to read this document, I offer all my help, 
>> but not overestimate me. Recently I even doubt if I'm programmer at all, 
>> maybe just advanced hobbyist.
>>
>> Because Go Spec my by too much for the begining I strongly advice you go 
>> trough all the "A Tour of Go".
>> https://go.dev/tour/welcome/1
>> "A Tour of Go" is easy, outside few excercise that need a background 
>> knowledge in things like networking. In any case, if you will have any 
>> question about "A Tour of Go" feel free to ask.
>>
>> One thing I think is worth of pointing out in the context of "A Tour of 
>> Go". When we talk about language itself, not its toolchain, there was only 
>> Big addition with big "B" to it since the version 1.0 was introduced in the 
>> 2012. By it I mean generics (or like Rob Pike call them more correctly: 
>> parametric polymorphism) introduced with Go 1.18 around February 2022. The 
>> part of "A Tour of Go" is that introduce generics is the only part that I 
>> don't like. It is too short and too sketchy for my taste.
>>
>> I learn quite a lot about generics reading proposal of them, at the time 
>> where was no implementation of them in the language, but I cannot these 
>> proposals as a learning materials. Ian Lance Taylor, which is one of the 
>> highest Go authorities in the world, once stated here that even the last 
>> proposal of generics isn't what is in the language, due to some changes 
>> make during the phase of implementation (at least this is what I understood 
>> from his words). Taylor said that if you know how generics works in Go, you 
>> should read Go Spec, which I currently doing. As a result, I cannot give 
>> you any point where to learn generics, since I still don't know if 
>> particular part of is appropriate for the beginners and I don't know an 
>> good ones at this moment. Maybe someone else can point to such good 
>> resource.
>>
>> At the bright side of things, I think generics are the last thing that 
>> you should learn in Go. They are important, but since are the last Addition 
>> with big "A" to the language, you should leave them to the end. At least in 
>> the my opinion.
>>
>> Best regards,
>> Kamil Ziemian
>> wtorek, 2 maja 2023 o 18:52:56 UTC+2 Rajesh Pandian napisał(a):
>>
>>> HI Nyilynn,
>>>
>>> I have watched Matt's Golang videos about concurrency and few others and 
>>> I have to say it is Brilliant!  I highly recommend it. (And Thank you Matt 
>>> for the brilliant content!!  )
>>>
>>> If you are interested in books then "Learning Go" from O'reilly was also 
>>> helpful to me. If you want start from absolute basic then "Head First Go" 
>>> is a good book too. I have all these two and the "The Go programming 
>>> language book which I frequently refer to as it's written by Brian W. 
>>> Kernighan and Alan A. A. Donovan which is a must have book if you reading 
>>> Go.
>>>
>>> And finally, practice and practise! As a Mandalorian would say "This is 
>>> the way" 
>>>
>>> Regards,
>>> Rajesh
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Friday, April 28, 2023 at 8:52:34 PM UTC+5:30 Matt KØDVB wrote:
>>>
 You can find my video class at 
 https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
 people seem to like it

 Matt

 On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:

 I am starting to learn GO programming language with this course 
 . Can you all 
 guide me how to learn and how to be geek at Go? 
 Thank you for reading

 -- 
 You received this message because you are subscribed 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/e12e-c9c9-4481-b0eb-c33a6632b768n%40googlegroups.com
  
 

Re: [go-nuts] Help me study resources or guides

[Zhang Jie (Kn)]

1. https://go101.org, from beginner to true gopher
2. go perf book, search it from github, this will teach you some 
optimization techniques
3. here's a reading list about golang 
internals: 
https://hitzhangjie.notion.site/149643669e0846e6b8e3294d04a6df0d?v=e1cea88688ec4102ae5d9af8cf9ac4c7,
actually, there's some Chinese golang books that describe the 
internals, like go语言设计实现，go语言原本. Even though they're good, but there's 
already many good articles, I keep updating this reading list.
4. 100-go-mistakes, this book will show you common mistakes among gophers, 
and it will make you understand golang better.

On Wednesday, May 3, 2023 at 9:14:40 PM UTC+8 Kamil Ziemian wrote:

> Hello,
>
> I now try to read "Go Language Specification", which you must read to 
> became true Gopher. If you want to read this document, I offer all my help, 
> but not overestimate me. Recently I even doubt if I'm programmer at all, 
> maybe just advanced hobbyist.
>
> Because Go Spec my by too much for the begining I strongly advice you go 
> trough all the "A Tour of Go".
> https://go.dev/tour/welcome/1
> "A Tour of Go" is easy, outside few excercise that need a background 
> knowledge in things like networking. In any case, if you will have any 
> question about "A Tour of Go" feel free to ask.
>
> One thing I think is worth of pointing out in the context of "A Tour of 
> Go". When we talk about language itself, not its toolchain, there was only 
> Big addition with big "B" to it since the version 1.0 was introduced in the 
> 2012. By it I mean generics (or like Rob Pike call them more correctly: 
> parametric polymorphism) introduced with Go 1.18 around February 2022. The 
> part of "A Tour of Go" is that introduce generics is the only part that I 
> don't like. It is too short and too sketchy for my taste.
>
> I learn quite a lot about generics reading proposal of them, at the time 
> where was no implementation of them in the language, but I cannot these 
> proposals as a learning materials. Ian Lance Taylor, which is one of the 
> highest Go authorities in the world, once stated here that even the last 
> proposal of generics isn't what is in the language, due to some changes 
> make during the phase of implementation (at least this is what I understood 
> from his words). Taylor said that if you know how generics works in Go, you 
> should read Go Spec, which I currently doing. As a result, I cannot give 
> you any point where to learn generics, since I still don't know if 
> particular part of is appropriate for the beginners and I don't know an 
> good ones at this moment. Maybe someone else can point to such good 
> resource.
>
> At the bright side of things, I think generics are the last thing that you 
> should learn in Go. They are important, but since are the last Addition 
> with big "A" to the language, you should leave them to the end. At least in 
> the my opinion.
>
> Best regards,
> Kamil Ziemian
> wtorek, 2 maja 2023 o 18:52:56 UTC+2 Rajesh Pandian napisał(a):
>
>> HI Nyilynn,
>>
>> I have watched Matt's Golang videos about concurrency and few others and 
>> I have to say it is Brilliant!  I highly recommend it. (And Thank you Matt 
>> for the brilliant content!!  )
>>
>> If you are interested in books then "Learning Go" from O'reilly was also 
>> helpful to me. If you want start from absolute basic then "Head First Go" 
>> is a good book too. I have all these two and the "The Go programming 
>> language book which I frequently refer to as it's written by Brian W. 
>> Kernighan and Alan A. A. Donovan which is a must have book if you reading 
>> Go.
>>
>> And finally, practice and practise! As a Mandalorian would say "This is 
>> the way" 
>>
>> Regards,
>> Rajesh
>>
>>
>>
>>
>>
>>
>>
>>
>> On Friday, April 28, 2023 at 8:52:34 PM UTC+5:30 Matt KØDVB wrote:
>>
>>> You can find my video class at 
>>> https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
>>> people seem to like it
>>>
>>> Matt
>>>
>>> On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:
>>>
>>> I am starting to learn GO programming language with this course 
>>> . Can you all 
>>> guide me how to learn and how to be geek at Go? 
>>> Thank you for reading
>>>
>>> -- 
>>> You received this message because you are subscribed 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/e12e-c9c9-4481-b0eb-c33a6632b768n%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, s

Re: [go-nuts] Help me study resources or guides

[Zhang Jie (Kn)]

Here're some good materials:
1. https://go101.org, after learning this, you will be a true gopher.
2. go语言设计实现，maybe there's no English version. When I learns golang, I want 
to know its internals, and I kept lots of good articles, 
here: 
https://www.notion.so/hitzhangjie/149643669e0846e6b8e3294d04a6df0d?v=e1cea88688ec4102ae5d9af8cf9ac4c7&pvs=4
3. go perf book, https://github.com/dgryski/go-perfbook, if you want to 
know more about the optimization about golang, you can check this.
4. go is easy to start, but that doesn't mean it is simple to master, the 
book '100-go-mistakes' is very good. It will teach you by some practical 
lessons.
On Wednesday, May 3, 2023 at 9:14:40 PM UTC+8 Kamil Ziemian wrote:

> Hello,
>
> I now try to read "Go Language Specification", which you must read to 
> became true Gopher. If you want to read this document, I offer all my help, 
> but not overestimate me. Recently I even doubt if I'm programmer at all, 
> maybe just advanced hobbyist.
>
> Because Go Spec my by too much for the begining I strongly advice you go 
> trough all the "A Tour of Go".
> https://go.dev/tour/welcome/1
> "A Tour of Go" is easy, outside few excercise that need a background 
> knowledge in things like networking. In any case, if you will have any 
> question about "A Tour of Go" feel free to ask.
>
> One thing I think is worth of pointing out in the context of "A Tour of 
> Go". When we talk about language itself, not its toolchain, there was only 
> Big addition with big "B" to it since the version 1.0 was introduced in the 
> 2012. By it I mean generics (or like Rob Pike call them more correctly: 
> parametric polymorphism) introduced with Go 1.18 around February 2022. The 
> part of "A Tour of Go" is that introduce generics is the only part that I 
> don't like. It is too short and too sketchy for my taste.
>
> I learn quite a lot about generics reading proposal of them, at the time 
> where was no implementation of them in the language, but I cannot these 
> proposals as a learning materials. Ian Lance Taylor, which is one of the 
> highest Go authorities in the world, once stated here that even the last 
> proposal of generics isn't what is in the language, due to some changes 
> make during the phase of implementation (at least this is what I understood 
> from his words). Taylor said that if you know how generics works in Go, you 
> should read Go Spec, which I currently doing. As a result, I cannot give 
> you any point where to learn generics, since I still don't know if 
> particular part of is appropriate for the beginners and I don't know an 
> good ones at this moment. Maybe someone else can point to such good 
> resource.
>
> At the bright side of things, I think generics are the last thing that you 
> should learn in Go. They are important, but since are the last Addition 
> with big "A" to the language, you should leave them to the end. At least in 
> the my opinion.
>
> Best regards,
> Kamil Ziemian
> wtorek, 2 maja 2023 o 18:52:56 UTC+2 Rajesh Pandian napisał(a):
>
>> HI Nyilynn,
>>
>> I have watched Matt's Golang videos about concurrency and few others and 
>> I have to say it is Brilliant!  I highly recommend it. (And Thank you Matt 
>> for the brilliant content!!  )
>>
>> If you are interested in books then "Learning Go" from O'reilly was also 
>> helpful to me. If you want start from absolute basic then "Head First Go" 
>> is a good book too. I have all these two and the "The Go programming 
>> language book which I frequently refer to as it's written by Brian W. 
>> Kernighan and Alan A. A. Donovan which is a must have book if you reading 
>> Go.
>>
>> And finally, practice and practise! As a Mandalorian would say "This is 
>> the way" 
>>
>> Regards,
>> Rajesh
>>
>>
>>
>>
>>
>>
>>
>>
>> On Friday, April 28, 2023 at 8:52:34 PM UTC+5:30 Matt KØDVB wrote:
>>
>>> You can find my video class at 
>>> https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
>>> people seem to like it
>>>
>>> Matt
>>>
>>> On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:
>>>
>>> I am starting to learn GO programming language with this course 
>>> . Can you all 
>>> guide me how to learn and how to be geek at Go? 
>>> Thank you for reading
>>>
>>> -- 
>>> You received this message because you are subscribed 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/e12e-c9c9-4481-b0eb-c33a6632b768n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop 

Re: [go-nuts] Help me study resources or guides

[Kamil Ziemian]

Hello,

I now try to read "Go Language Specification", which you must read to 
became true Gopher. If you want to read this document, I offer all my help, 
but not overestimate me. Recently I even doubt if I'm programmer at all, 
maybe just advanced hobbyist.

Because Go Spec my by too much for the begining I strongly advice you go 
trough all the "A Tour of Go".
https://go.dev/tour/welcome/1
"A Tour of Go" is easy, outside few excercise that need a background 
knowledge in things like networking. In any case, if you will have any 
question about "A Tour of Go" feel free to ask.

One thing I think is worth of pointing out in the context of "A Tour of 
Go". When we talk about language itself, not its toolchain, there was only 
Big addition with big "B" to it since the version 1.0 was introduced in the 
2012. By it I mean generics (or like Rob Pike call them more correctly: 
parametric polymorphism) introduced with Go 1.18 around February 2022. The 
part of "A Tour of Go" is that introduce generics is the only part that I 
don't like. It is too short and too sketchy for my taste.

I learn quite a lot about generics reading proposal of them, at the time 
where was no implementation of them in the language, but I cannot these 
proposals as a learning materials. Ian Lance Taylor, which is one of the 
highest Go authorities in the world, once stated here that even the last 
proposal of generics isn't what is in the language, due to some changes 
make during the phase of implementation (at least this is what I understood 
from his words). Taylor said that if you know how generics works in Go, you 
should read Go Spec, which I currently doing. As a result, I cannot give 
you any point where to learn generics, since I still don't know if 
particular part of is appropriate for the beginners and I don't know an 
good ones at this moment. Maybe someone else can point to such good 
resource.

At the bright side of things, I think generics are the last thing that you 
should learn in Go. They are important, but since are the last Addition 
with big "A" to the language, you should leave them to the end. At least in 
the my opinion.

Best regards,
Kamil Ziemian
wtorek, 2 maja 2023 o 18:52:56 UTC+2 Rajesh Pandian napisał(a):

> HI Nyilynn,
>
> I have watched Matt's Golang videos about concurrency and few others and I 
> have to say it is Brilliant!  I highly recommend it. (And Thank you Matt 
> for the brilliant content!!  )
>
> If you are interested in books then "Learning Go" from O'reilly was also 
> helpful to me. If you want start from absolute basic then "Head First Go" 
> is a good book too. I have all these two and the "The Go programming 
> language book which I frequently refer to as it's written by Brian W. 
> Kernighan and Alan A. A. Donovan which is a must have book if you reading 
> Go.
>
> And finally, practice and practise! As a Mandalorian would say "This is 
> the way" 
>
> Regards,
> Rajesh
>
>
>
>
>
>
>
>
> On Friday, April 28, 2023 at 8:52:34 PM UTC+5:30 Matt KØDVB wrote:
>
>> You can find my video class at 
>> https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
>> people seem to like it
>>
>> Matt
>>
>> On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:
>>
>> I am starting to learn GO programming language with this course 
>> . Can you all 
>> guide me how to learn and how to be geek at Go? 
>> Thank you for reading
>>
>> -- 
>> You received this message because you are subscribed 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/e12e-c9c9-4481-b0eb-c33a6632b768n%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/bc042fc0-05c6-45a8-89b2-48aa7eeaa60cn%40googlegroups.com.

Re: [go-nuts] Help me study resources or guides

[Rajesh Pandian]

HI Nyilynn,

I have watched Matt's Golang videos about concurrency and few others and I 
have to say it is Brilliant!  I highly recommend it. (And Thank you Matt 
for the brilliant content!!  )

If you are interested in books then "Learning Go" from O'reilly was also 
helpful to me. If you want start from absolute basic then "Head First Go" 
is a good book too. I have all these two and the "The Go programming 
language book which I frequently refer to as it's written by Brian W. 
Kernighan and Alan A. A. Donovan which is a must have book if you reading 
Go.

And finally, practice and practise! As a Mandalorian would say "This is the 
way" 

Regards,
Rajesh








On Friday, April 28, 2023 at 8:52:34 PM UTC+5:30 Matt KØDVB wrote:

> You can find my video class at 
> https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
> people seem to like it
>
> Matt
>
> On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:
>
> I am starting to learn GO programming language with this course 
> . Can you all 
> guide me how to learn and how to be geek at Go? 
> Thank you for reading
>
> -- 
> You received this message because you are subscribed 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/e12e-c9c9-4481-b0eb-c33a6632b768n%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/1cf3f4f8-ff6d-4812-92d9-d94d671815b2n%40googlegroups.com.

Re: [go-nuts] Help me study resources or guides

[Matt KØDVB]

You can find my video class at 
https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
people seem to like it

Matt

> On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:
> 
> I am starting to learn GO programming language with this course 
> . Can you all guide 
> me how to learn and how to be geek at Go? 
> Thank you for reading
> 
> -- 
> You received this message because you are subscribed to the Google 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/e12e-c9c9-4481-b0eb-c33a6632b768n%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/7816FC1C-8447-456D-9F2A-9608299D92F2%40k0dvb.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

Ian and Andy,
looks like the to string conversion works and even does not look ugly. :-)

Thank you so much.

пятница, 17 марта 2023 г. в 15:01:31 UTC+3, alex-coder: 

> Andy, thank you.
>
> In case there would be a choice between ugly and achievable, I must take 
> the last one:-)
>
> Another thing I have found it that it is impossible to use type as a 
> parameter when you call to a function.
> How to pass type to function argument in Go - Stack Overflow 
> 
>
> Thank you.
>
> пятница, 17 марта 2023 г. в 02:12:22 UTC+3, Andy Balholm: 
>
>> I would guess that in the case of AST nodes, you're likely more 
>> interested in the *identity* of the nodes than their *values*. In that 
>> case, you should use the pointers to the nodes as your map keys.
>>
>> If the *values* truly are what you care about, use the go/format package 
>> to convert the node back to source code, and use the resulting string as 
>> your map key.
>>
>> On Thursday, March 16, 2023 at 3:24:49 PM UTC-7 alex-coder wrote:
>>
>>> >> Sure, convert to a string and use that as a map key.
>>> :-) no, no, no. it looks very very ugly.
>>>
>>> четверг, 16 марта 2023 г. в 00:26:35 UTC+3, Ian Lance Taylor: 
>>>
 On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote: 
 > 
 > Ian, thank you. 
 > but may be the is any workaround ? 
 > Use as a key not directly but like a derived from those 
 interface/structure types ? 
 > Of course I may declare key like string and use switch + .(type) to 
 mimic it. 

 Sure, convert to a string and use that as a map key. 

 By the way, I should say that although you can't use `ast.Field` as a 
 map key type, you can use `*ast.Field`. Of course then two different 
 Field values that happen to look exactly the same will get different 
 map entries. So it kind of depends on what you want to do. 

 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/1a6849b1-35ae-4d3d-bdd9-28d5b342bcb9n%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

Andy, thank you.

In case there would be a choice between ugly and achievable, I must take 
the last one:-)

Another thing I have found it that it is impossible to use type as a 
parameter when you call to a function.
How to pass type to function argument in Go - Stack Overflow 


Thank you.

пятница, 17 марта 2023 г. в 02:12:22 UTC+3, Andy Balholm: 

> I would guess that in the case of AST nodes, you're likely more interested 
> in the *identity* of the nodes than their *values*. In that case, you 
> should use the pointers to the nodes as your map keys.
>
> If the *values* truly are what you care about, use the go/format package 
> to convert the node back to source code, and use the resulting string as 
> your map key.
>
> On Thursday, March 16, 2023 at 3:24:49 PM UTC-7 alex-coder wrote:
>
>> >> Sure, convert to a string and use that as a map key.
>> :-) no, no, no. it looks very very ugly.
>>
>> четверг, 16 марта 2023 г. в 00:26:35 UTC+3, Ian Lance Taylor: 
>>
>>> On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote: 
>>> > 
>>> > Ian, thank you. 
>>> > but may be the is any workaround ? 
>>> > Use as a key not directly but like a derived from those 
>>> interface/structure types ? 
>>> > Of course I may declare key like string and use switch + .(type) to 
>>> mimic it. 
>>>
>>> Sure, convert to a string and use that as a map key. 
>>>
>>> By the way, I should say that although you can't use `ast.Field` as a 
>>> map key type, you can use `*ast.Field`. Of course then two different 
>>> Field values that happen to look exactly the same will get different 
>>> map entries. So it kind of depends on what you want to do. 
>>>
>>> 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/b6ea9156-f4fd-4cf9-9a51-5942f5cbe715n%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[Andy Balholm]

I would guess that in the case of AST nodes, you're likely more interested 
in the *identity* of the nodes than their *values*. In that case, you 
should use the pointers to the nodes as your map keys.

If the *values* truly are what you care about, use the go/format package to 
convert the node back to source code, and use the resulting string as your 
map key.

On Thursday, March 16, 2023 at 3:24:49 PM UTC-7 alex-coder wrote:

> >> Sure, convert to a string and use that as a map key.
> :-) no, no, no. it looks very very ugly.
>
> четверг, 16 марта 2023 г. в 00:26:35 UTC+3, Ian Lance Taylor: 
>
>> On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote: 
>> > 
>> > Ian, thank you. 
>> > but may be the is any workaround ? 
>> > Use as a key not directly but like a derived from those 
>> interface/structure types ? 
>> > Of course I may declare key like string and use switch + .(type) to 
>> mimic it. 
>>
>> Sure, convert to a string and use that as a map key. 
>>
>> By the way, I should say that although you can't use `ast.Field` as a 
>> map key type, you can use `*ast.Field`. Of course then two different 
>> Field values that happen to look exactly the same will get different 
>> map entries. So it kind of depends on what you want to do. 
>>
>> 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/c08ef64c-a068-4a25-afd6-46cb64ce4f55n%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

>> Sure, convert to a string and use that as a map key.
:-) no, no, no. it looks very very ugly.

четверг, 16 марта 2023 г. в 00:26:35 UTC+3, Ian Lance Taylor: 

> On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote:
> >
> > Ian, thank you.
> > but may be the is any workaround ?
> > Use as a key not directly but like a derived from those 
> interface/structure types ?
> > Of course I may declare key like string and use switch + .(type) to 
> mimic it.
>
> Sure, convert to a string and use that as a map key.
>
> By the way, I should say that although you can't use `ast.Field` as a
> map key type, you can use `*ast.Field`. Of course then two different
> Field values that happen to look exactly the same will get different
> map entries. So it kind of depends on what you want to do.
>
> 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/f0556fc4-885a-4f13-a29e-1894983e5962n%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[Ian Lance Taylor]

On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote:
>
> Ian, thank you.
> but may be the is any workaround ?
> Use as a key not directly but like a derived from those interface/structure 
> types ?
> Of course I may declare key like string and use switch + .(type) to mimic it.

Sure, convert to a string and use that as a map key.

By the way, I should say that although you can't use `ast.Field` as a
map key type, you can use `*ast.Field`.  Of course then two different
Field values that happen to look exactly the same will get different
map entries.  So it kind of depends on what you want to do.

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/CAOyqgcUi%2BVpBSumSRQueJwC7BVCJCbsCtPE%2B-q_gcU3wPDf4mw%40mail.gmail.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

Ian, thank you.
but may be the is any workaround ?
Use as a key not directly but like a derived from those interface/structure 
types ?
Of course I may declare key like string and use switch + .(type) to mimic 
it.

So, a little bit more.
there is a go standard package named ast. the docs about it you may find 
there:
ast package - go/ast - Go Packages 

there is an arrea where are declared a lot of types:
type ArrayType struct {}
type AssignStmt struct {}
type BadDecl struct {}
and so on and ending with 
type ValueSpec struct {}
in fact there are a lot of them there.
What do I whant is to use those types of interfaces or structures as a key 
to access to a value in a map.  
So, the question is: what type of a key for a map I must use ?

Thank you. 

среда, 15 марта 2023 г. в 23:55:03 UTC+3, Ian Lance Taylor: 

> On Wed, Mar 15, 2023 at 9:17 AM alex-coder  wrote:
> >
> > There is a package named ast, inside there are a lot of structures like:
> > ast.Comment, ast.Field, ast.Node and so on.
> > And I whould like to use types of those structure as a keys.
> > So, I could not figure out what type of the key I should use
> > in order to store in a map something under the key ?
>
> I don't really understand the question. But I do know that most of
> the types in the go/ast package can't be used as map keys, because
> they can't be compared for equality, because they have fields of slice
> type. You can't use a slice, or a struct with a field of slice type,
> as a map key.
>
> 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/dfc41f67-5d71-4f2a-a0bf-569c5a582aedn%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[Ian Lance Taylor]

On Wed, Mar 15, 2023 at 9:17 AM alex-coder  wrote:
>
> There is a package named ast, inside there are a lot of structures like:
> ast.Comment, ast.Field, ast.Node and so on.
> And I whould like to use types of those structure as a keys.
> So, I could not figure out what type of the key I should use
> in order to store in a map something under the key ?

I don't really understand the question.  But I do know that most of
the types in the go/ast package can't be used as map keys, because
they can't be compared for equality, because they have fields of slice
type.  You can't use a slice, or a struct with a field of slice type,
as a map key.

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

Re: [go-nuts] Help with language change proposal

[Landon Cooper]

Thanks very much for the feedback, Axel. I didn't think it was harsh, this 
is just the kind of information I needed before burning needless effort on 
the idea.
Getting started with these conversations is quite intimidating because 
there is so much information and history, it's hard to find what is 
relevant, let alone digest it all. I appreciate that anyone spends the time 
to help a newbie.

Just for interest's sake, I wanted to respond to some of your questions. I 
take your point about some sections of the proposal being incomplete or too 
sparse, but I don't think there's any point in spending time on that when 
there are obvious problems.

> I also think one thing we should be clear on, is that methods 
fundamentally are never "just syntactic sugar for functions" - unless you 
really are proposing Uniform Function Call Syntax.
I don't understand this, but I do take your word for it. This is probably 
the "something very obvious" I missed. 

> In particular, your proposal has name spacing implications - it would be 
possible to have two methods of the same name on different interface types, 
while it is not possible to have two *functions* of the same name, even if 
they accept different interfaces as their first argument.
I believe I accounted for this in the restrictions and scratched the 
surface of this challenge in the section about composition. However, my 
approach is obviously naive, I expect there's a good name for this problem 
and it likely has to be dealt with more systematically.

> I believe it would be confusing for methods on a `MyReader` to disappear, 
when assigning them to an `io.Reader` and to appear, when assigning an 
`io.Reader` to a `MyReader`.
Agreed, and it only takes passing mr to a func(io.Reader) for the MyReader 
method information to be lost at compile time. This points out a serious 
limitation on the idea of implementing through code rewriting; it could 
only work for locally scoped variables.

> How do you deal with a situation where the *dynamic type* of an interface 
has that method, but not its static type? That is, what if I assign an 
`*os.File` to a `MyReader`, for example? What if I assign an `*os.File` to 
an `io.Reader` and then convert that to a `MyReader`?
Not sure I see your point here. *os.File to a MyReader would be Okay. The 
type would gain the WriteTo method.
*os.File to io.Reader, of course is okay, and then to a MyReader is also 
okay. The dynamic type would have only the Read and WriteTo methods.

I do think the proposal of using code rewriting avoids the issue of 
parametrized methods, but its usefulness is completely destroyed by the 
limitation you pointed out.

Thanks again Axel!
On Wednesday, March 15, 2023 at 1:53:16 AM UTC-6 Axel Wagner wrote:

> Hi,
>
> Some comments in-line:
>
> > > Who does this proposal help, and why?
> > go programmers who want to reduce boiler plate code.
>
> I believe you should definitely be more explicit with the problem you are 
> trying to solve. "Today, if you want to do X, you have to write Y. That is 
> bad, because Z".
>
> There are many different kinds of boiler plate, so just saying you help 
> "Go programmers who want to reduce boiler plate" carries little to no 
> information.
>
> > interfaces and named aliases would become allowable receivers. The 
> change would just be syntactic sugar for functions that accept this 
> interface.
>
> I don't have a specific reference handy, but more or less exactly this has 
> been proposed a couple of times in the past and always been rejected.
> So, apologies for being harsh, but I would predict that this has an 
> essentially zero chance of being accepted.
>
> I also think one thing we should be clear on, is that methods 
> fundamentally are never "just syntactic sugar for functions" - unless you 
> really are proposing Uniform Function Call Syntax. In particular, your 
> proposal has name spacing implications - it would be possible to have two 
> methods of the same name on different interface types, while it is not 
> possible to have two *functions* of the same name, even if they accept 
> different interfaces as their first argument.
>
> So, this is not just syntactic sugar, it carries semantic meaning. And if 
> it where, it would not be likely to solve the problem you are trying to 
> solve.
>  
> > There are some restrictions:
> > 
> > R1: Just like normal methods, “interface methods” can only be defined 
> within the package the interface is defined. This prevents imported code 
> from > potentially breaking or overriding the intended functionality.
>
> I don't think this is a good idea. Interfaces, by their nature, are mostly 
> package-agnostic. That is, I can define an interface
> type MyReader interface{ Read(p []byte) (int, error)
> and while it is not *identical* to io.Reader, it is mostly equivalent, 
> that is, they are mutually assignable.
>
> I believe it would be confusing for methods on a `MyReader` to disappear, 
> when assigning them to an `io.

Re: [go-nuts] Help with language change proposal

['Axel Wagner' via golang-nuts]

Hi,

Some comments in-line:

> > Who does this proposal help, and why?
> go programmers who want to reduce boiler plate code.

I believe you should definitely be more explicit with the problem you are
trying to solve. "Today, if you want to do X, you have to write Y. That is
bad, because Z".

There are many different kinds of boiler plate, so just saying you help "Go
programmers who want to reduce boiler plate" carries little to no
information.

> interfaces and named aliases would become allowable receivers. The change
would just be syntactic sugar for functions that accept this interface.

I don't have a specific reference handy, but more or less exactly this has
been proposed a couple of times in the past and always been rejected.
So, apologies for being harsh, but I would predict that this has an
essentially zero chance of being accepted.

I also think one thing we should be clear on, is that methods fundamentally
are never "just syntactic sugar for functions" - unless you really are
proposing Uniform Function Call Syntax. In particular, your proposal has
name spacing implications - it would be possible to have two methods of the
same name on different interface types, while it is not possible to have
two *functions* of the same name, even if they accept different interfaces
as their first argument.

So, this is not just syntactic sugar, it carries semantic meaning. And if
it where, it would not be likely to solve the problem you are trying to
solve.

> There are some restrictions:
>
> R1: Just like normal methods, “interface methods” can only be defined
within the package the interface is defined. This prevents imported code
from > potentially breaking or overriding the intended functionality.

I don't think this is a good idea. Interfaces, by their nature, are mostly
package-agnostic. That is, I can define an interface
type MyReader interface{ Read(p []byte) (int, error)
and while it is not *identical* to io.Reader, it is mostly equivalent, that
is, they are mutually assignable.

I believe it would be confusing for methods on a `MyReader` to disappear,
when assigning them to an `io.Reader` and to appear, when assigning an
`io.Reader` to a `MyReader`.

Note also, that Go has interface type-assertions. So how would this work,
for example?

func (r MyReader) WriteTo(w io.Writer) (int64, error) { … }
type R struct{}
func (R) Read(p []byte) (int, error) { return len(p), nil } // implements
io.Reader
func main() {
_, ok := io.Reader(R{}).(io.WriterTo) // fails
mr := MyReader(R{})
_, ok = io.Reader(mr).(io.WriterTo) // succeeds, presumably?
ch := make(chan io.Reader, 1)
ch <- mr
(<-ch).(io.WriterTo) // fails? succeds?
}

That is, a `MyReader` would implement `io.WriterTo`. But if it is
intermediately stored in an `io.Reader` (say, by passing it through a
channel), the compiler no longer knows if and where to find a `WriterTo`
method.

This really is just a corollary/demonstration of why it's confusing for
methods to appear/disappear when converting them between io.Reader and
MyReader.

> R2: interface methods cannot override existing methods. Attempting to
cast an object to an interface that it already fulfills or partially
fulfills would be
> a compile time error. This prevents interfaces from becoming
self-fulfilling, or overriding expected functionality. The compile time
error is necessary
> so future updates to packages don’t change functionality unexpectedly.

How do you deal with a situation where the *dynamic type* of an interface
has that method, but not its static type? That is, what if I assign an
`*os.File` to a `MyReader`, for example? What if I assign an `*os.File` to
an `io.Reader` and then convert that to a `MyReader`?

> My motivation for this feature is to mitigate limitations on dynamic
types. Consider the typical approach to handling dynamic json.
> […]
> Access could be simpler through a hypothetical jnode package.
> […]

I believe you can functionally achieve the same result if you make `node` a
struct type with an `UnmarshalJSON` method and an `any` or `map[string]any`
field or something like that.

> Fortunately, there’s no need to rush into this. We could start by saying
extension methods do not contribute to the method set, and therefore do not
> help fulfill interfaces. Unfortunately, that caveat would fall to
programmers to understand, raising the bar for learning go. I believe the
ultimate
> design here would definitely be to allow the extension methods into the
type’s method set.

Note that the resulting confusion of having methods that are not in the
method set, when considering interface satisfaction, is why we do not have
extra type parameters on methods .
I don't believe this proposal has significantly more advantages than
allowing that would have (it probably has significantly fewer) so I don't
think this proposal would overcome that concern.

> This example illustrates how the code rewriting can lead to a k

Re: [go-nuts] Help Bootstrapping to ESXi

[Brian Candler]

P.S. For using tinygo to generate Linux executables, see:
https://tinygo.org/getting-started/install/linux/
https://tinygo.org/docs/guides/linux/

But I couldn't find the minimum kernel version requirements.

On Saturday, 14 January 2023 at 11:41:21 UTC Brian Candler wrote:

> On Friday, 13 January 2023 at 20:42:28 UTC mi...@newclarity.net wrote:
> I SSHed into the ESXi server, used wget to pull down the Golang tarball, 
> used tar to extract it from within the ESXi shell, and then used `go run 
> hello.go` in the ESXi shell and got a runtime error of "epollwait on fd 4 
> failed with 38."  
>
> That error is basically the same error from this ticket for an unsupported 
> older version of CentOS: https://github.com/golang/go/issues/24980
>
> From there I realized it was beyond my skills to pursue and so I dropped 
> it.
>
> I wonder if anyone on the list can speak to the difference between what 
> you (Anthony) did and what I did, and Anthony's worked and mine didn't?  
>
> Anthony wrote a very simple "Hello world" program.  You tried to run an 
> extremely large and complex program (the Go compiler).
>  
> Further, I wonder if other runtime errors are waiting as soon as other 
> packages are pulled in that need greater access to the O/S?
>
> I think that's exactly right.  You can build simple binaries for Linux and 
> they'll run under ESXi, but because it's running on an ancient Linux kernel 
> which is below the minimum required by Go, anything sophisticated will fail.
>  
> Finally, I wonder if someone on the list would be able to help me get 
> around that error and continue exploring the compilation and execution of 
> Go programs on an ESXi server from within the ESXi SSH shell?
>
> Not directly, no.  The Go team themselves have dropped support for ancient 
> Linux kernels, and adding that back would be a major undertaking (which 
> nobody wants to do).
>
> I should ask though: what is the actual problem that you're trying to 
> solve, i.e. what is your ultimate goal?  Is it that you want to write admin 
> tools for managing your ESXi server? And your preference is that these 
> tools run directly on the ESXi host, *and* that they are written in Go?
>
> This doesn't require having a Go compiler which runs *on* the ESXi host, 
> because you could do the compilation elsewhere.  But it does require a 
> compiler which generates binaries which run on this host.  There are other 
> Go compilers, like tinygo , that you could try.  
> These are designed to generate code for older/smaller machines so might 
> work.
>
> Next thought: would you be happy to have admin tools that don't run on the 
> ESXi host itself, but instead talk to the ESXi API?  Are you using vcenter 
> or standalone ESXi hosts?  That would be the "cleanest" way to administer 
> them.
>
> Finally: at worst you can write a Go program which runs on a different 
> host, and simply ssh's to the ESXi server to run the ESXi command line 
> tools there.  Go includes an ssh client library:
> https://pkg.go.dev/golang.org/x/crypto/ssh
>
>

-- 
You received this message because you are subscribed to the Google 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/15de16db-7e1f-4739-b855-3eb0bf615de2n%40googlegroups.com.

Re: [go-nuts] Help Bootstrapping to ESXi

[Brian Candler]

On Friday, 13 January 2023 at 20:42:28 UTC mi...@newclarity.net wrote:
I SSHed into the ESXi server, used wget to pull down the Golang tarball, 
used tar to extract it from within the ESXi shell, and then used `go run 
hello.go` in the ESXi shell and got a runtime error of "epollwait on fd 4 
failed with 38."  

That error is basically the same error from this ticket for an unsupported 
older version of CentOS: https://github.com/golang/go/issues/24980

>From there I realized it was beyond my skills to pursue and so I dropped it.

I wonder if anyone on the list can speak to the difference between what you 
(Anthony) did and what I did, and Anthony's worked and mine didn't?  

Anthony wrote a very simple "Hello world" program.  You tried to run an 
extremely large and complex program (the Go compiler).
 
Further, I wonder if other runtime errors are waiting as soon as other 
packages are pulled in that need greater access to the O/S?

I think that's exactly right.  You can build simple binaries for Linux and 
they'll run under ESXi, but because it's running on an ancient Linux kernel 
which is below the minimum required by Go, anything sophisticated will fail.
 
Finally, I wonder if someone on the list would be able to help me get 
around that error and continue exploring the compilation and execution of 
Go programs on an ESXi server from within the ESXi SSH shell?

Not directly, no.  The Go team themselves have dropped support for ancient 
Linux kernels, and adding that back would be a major undertaking (which 
nobody wants to do).

I should ask though: what is the actual problem that you're trying to 
solve, i.e. what is your ultimate goal?  Is it that you want to write admin 
tools for managing your ESXi server? And your preference is that these 
tools run directly on the ESXi host, *and* that they are written in Go?

This doesn't require having a Go compiler which runs *on* the ESXi host, 
because you could do the compilation elsewhere.  But it does require a 
compiler which generates binaries which run on this host.  There are other 
Go compilers, like tinygo , that you could try.  These 
are designed to generate code for older/smaller machines so might work.

Next thought: would you be happy to have admin tools that don't run on the 
ESXi host itself, but instead talk to the ESXi API?  Are you using vcenter 
or standalone ESXi hosts?  That would be the "cleanest" way to administer 
them.

Finally: at worst you can write a Go program which runs on a different 
host, and simply ssh's to the ESXi server to run the ESXi command line 
tools there.  Go includes an ssh client library:
https://pkg.go.dev/golang.org/x/crypto/ssh

-- 
You received this message because you are subscribed to the Google 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/cca50861-6e0d-41be-abb9-0a44289fd665n%40googlegroups.com.

Re: [go-nuts] Help Bootstrapping to ESXi

[Anthony Brown]

I think the difference is that I didn't actually do the compilation on the 
ESXi host itself, I just ran the binary there. 

'go run hello.go' on the ESXi host will, attempt, to both compile and 
execute the compiled binary; I'm guessing the ESXi host itself though 
doesn't have some of the same shared library updates the supported Linux 
kernels have which may be required for the compilation.

A insightful test here would be to use the go compiler on the ESXi host 
initially to see if a 'go build' will even work, if not it's an issue with 
compilation. If that works and execution itself breaks, then it's outside 
of the go build toolchain and a difference in the Go runtime itself on 
Linux and VMkernel targets.

-Tony

On Friday, January 13, 2023 at 2:42:28 PM UTC-6 mi...@newclarity.net wrote:

> On Jan 13, 2023, at 1:32 AM, Anthony Brown  wrote:
>
> I haven't made a bootstrapped Go toolchain so I can't help with that but I 
> can provide the following information:
>
> ESXi knows how to run ELF binaries, the interesting part then becomes what 
> architecture of CPU do you have the ESXi server installed on. If it's x86 
> or any other architecture that the Go toolchain already supports you don't 
> have to make a bootstrap version for yourself. If it's not one of those, 
> then it might be easier to compile your binaries on a different machine 
> with the GOOS and GOARCH flags to specify your target OS (in this case 
> Linux) and whatever architecture you are trying to build for.
>
> Just to be sure, I just wrote a simple "Hello" binary in Go on Ubuntu. Did 
> a simple 'go build' so that it would target my host OS and architecture 
> then SCP'd it to an ESXi host I have available for testing also on x86. I 
> was able to run this binary without issue within the shell of the ESXi 
> server.
>
>
> That is quite surprising. 
>
> Brett sent me an off-list email and so I explored compiling and running Go 
> on my VMware ESXi 7.3 server but ran into problems.
>
> I SSHed into the ESXi server, used wget to pull down the Golang tarball, 
> used tar to extract it from within the ESXi shell, and then used `go run 
> hello.go` in the ESXi shell and got a runtime error of "epollwait on fd 4 
> failed with 38."  
>
> That error is basically the same error from this ticket for an unsupported 
> older version of CentOS: https://github.com/golang/go/issues/24980
>
> From there I realized it was beyond my skills to pursue and so I dropped 
> it.
>
> I wonder if anyone on the list can speak to the difference between what 
> you (Anthony) did and what I did, and Anthony's worked and mine didn't?  
>
> Further, I wonder if other runtime errors are waiting as soon as other 
> packages are pulled in that need greater access to the O/S?
>
> Finally, I wonder if someone on the list would be able to help me get 
> around that error and continue exploring the compilation and execution of 
> Go programs on an ESXi server from within the ESXi SSH shell?
>
> Thanks in advance for any insight into this.
>
> -Mike
>
>
> Hopefully that provides some insight.
>
> On Monday, January 9, 2023 at 3:20:15 PM UTC-6 brett@gmail.com wrote:
>
>> Good afternoon, hoping to get a little help.
>>
>> I am trying to build a bootstrap candidate that allows me to build and 
>> run go programs on an ESXi server.
>>
>> I am following this 
>> 
>>  blog, and the issue is that my bootstrap candidate doesn't contain the 
>> go binary in the bin directory that is required when running all.bash.
>>
>> Any help would be greatly appreciated.
>>
>
> -- 
> 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/u2hKqDg24R4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/05acc8d9-fe55-49fc-bf97-2b51e4d6c5e2n%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/df3edc67-438d-4162-9025-0a73b3a429ean%40googlegroups.com.

Re: [go-nuts] Help Bootstrapping to ESXi

[Mike Schinkel]

> On Jan 13, 2023, at 1:32 AM, Anthony Brown  wrote:
> 
> I haven't made a bootstrapped Go toolchain so I can't help with that but I 
> can provide the following information:
> 
> ESXi knows how to run ELF binaries, the interesting part then becomes what 
> architecture of CPU do you have the ESXi server installed on. If it's x86 or 
> any other architecture that the Go toolchain already supports you don't have 
> to make a bootstrap version for yourself. If it's not one of those, then it 
> might be easier to compile your binaries on a different machine with the GOOS 
> and GOARCH flags to specify your target OS (in this case Linux) and whatever 
> architecture you are trying to build for.
> 
> Just to be sure, I just wrote a simple "Hello" binary in Go on Ubuntu. Did a 
> simple 'go build' so that it would target my host OS and architecture then 
> SCP'd it to an ESXi host I have available for testing also on x86. I was able 
> to run this binary without issue within the shell of the ESXi server.

That is quite surprising. 

Brett sent me an off-list email and so I explored compiling and running Go on 
my VMware ESXi 7.3 server but ran into problems.

I SSHed into the ESXi server, used wget to pull down the Golang tarball, used 
tar to extract it from within the ESXi shell, and then used `go run hello.go` 
in the ESXi shell and got a runtime error of "epollwait on fd 4 failed with 
38."  

That error is basically the same error from this ticket for an unsupported 
older version of CentOS: https://github.com/golang/go/issues/24980 


>From there I realized it was beyond my skills to pursue and so I dropped it.

I wonder if anyone on the list can speak to the difference between what you 
(Anthony) did and what I did, and Anthony's worked and mine didn't?  

Further, I wonder if other runtime errors are waiting as soon as other packages 
are pulled in that need greater access to the O/S?

Finally, I wonder if someone on the list would be able to help me get around 
that error and continue exploring the compilation and execution of Go programs 
on an ESXi server from within the ESXi SSH shell?

Thanks in advance for any insight into this.

-Mike

> 
> Hopefully that provides some insight.
> 
> On Monday, January 9, 2023 at 3:20:15 PM UTC-6 brett@gmail.com wrote:
> Good afternoon, hoping to get a little help.
> 
> I am trying to build a bootstrap candidate that allows me to build and run go 
> programs on an ESXi server.
> 
> I am following this 
> 
>  blog, and the issue is that my bootstrap candidate doesn't contain the go 
> binary in the bin directory that is required when running all.bash.
> 
> Any help would be greatly appreciated.
> 
> -- 
> 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/u2hKqDg24R4/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/05acc8d9-fe55-49fc-bf97-2b51e4d6c5e2n%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/26712CF9-A5A6-47D5-B533-CF69FC9EA458%40newclarity.net.

Re: [go-nuts] Help debugging a SIGSEGV - "unexpected signal during runtime execution"

[Gerald Parker]

Hi Kurtis,

Thanks for the response. To be clear this issue 
 is the defect that I'm 
encountering. The issue was originally logged against *v1.0.0-beta4*. I am 
using *v1.0.0-beta6* but the defect has not been fixed. 

This defect occurs when calling *robotgo.KeyTap("a")*. It doesn't just 
happen when passing in "a", it seems to occurs whenever any value other 
than a whitespace value is passed in. I noticed that it happens when 
calling the *robotgo.KeyToggle* function also.

To answer your question about the main function. Yes I did alter it. I just 
changed it to the following so that I could try and debug the issue:

func main() {
 robotgo.KeyTap("a")
}

On a side note. The reason I'm using *v1.0.0-beta6 *is because when I tried 
to import it into my original project by running *go get -u 
github.com/go-vgo/robotgo* the branch that was pulled has an entirely 
different set of issues. I had to specify the beta6 tag using *go get -u 
github.com/go-vgo/robotgo@1.0.0-beta6*

On Thursday, December 8, 2022 at 7:13:14 PM UTC-6 kra...@skepticism.us 
wrote:

> It superficially looks like you're running the code from 
> https://github.com/go-vgo/robotgo/blob/master/examples/key/main.go. 
> However, The line number 136 in main.go in the backtrace doesn't make any 
> sense since the example code from the project only has 134 lines. Did you 
> modify the example code? If so you'll need to show us your modifications. 
> Does the example from that project work if you don't modify it?
>
> Note that the SIGSEGV is because the code is trying to use the value 8 as 
> an address. So it isn't a typical null/nil pointer dereference. Possibly 
> you're passing something like a length of some object as an argument which 
> should be the address of some object.
>
> On Thu, Dec 8, 2022 at 9:23 AM Gerald Parker  wrote:
>
>> Hi all,
>> I'm using go version 1.19.4 darwin-amd64
>>
>> I keep getting the following errors while trying to use a function from 
>> the robotgo package. I'm not experienced in C and could use some help 
>> trying to find the problem 
>>
>> fatal error: unexpected signal during runtime execution
>> [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x10016df88]
>>
>> runtime stack:
>> runtime.throw({0x1001c32bc?, 0x0?})
>> /Users/gp/go/go1.19.4/src/runtime/panic.go:1047 +0x5d 
>> fp=0x7ff7bfeff520 sp=0x7ff7bfeff4f0 pc=0x10003751d
>> runtime.sigpanic()
>> /Users/gp/go/go1.19.4/src/runtime/signal_unix.go:819 +0x369 
>> fp=0x7ff7bfeff570 sp=0x7ff7bfeff520 pc=0x10004cf89
>>
>> goroutine 1 [syscall]:
>> runtime.cgocall(0x10016df60, 0xc000187ce8)
>> /Users/gp/go/go1.19.4/src/runtime/cgocall.go:158 +0x5c 
>> fp=0xc000187cc0 sp=0xc000187c88 pc=0x16d1c
>> github.com/go-vgo/robotgo._Cfunc_keyCodeForChar(0x61)
>> _cgo_gotypes.go:729 +0x47 fp=0xc000187ce8 sp=0xc000187cc0 
>> pc=0x10016c527
>> github.com/go-vgo/robotgo.checkKeyCodes({0x1001b879b 
>> ?, 0x1?})
>> /Users/gp/Repositories/robotgo/key.go:344 +0x7f fp=0xc000187d40 
>> sp=0xc000187ce8 pc=0x10016c89f
>> github.com/go-vgo/robotgo.keyTaps({0x1001b879b 
>> , 0x1}, {0x0?, 
>> 0x1?, 0x0?}, 0x8?)
>> /Users/gp/Repositories/robotgo/key.go:402 +0x4d fp=0xc000187d78 
>> sp=0xc000187d40 pc=0x10016ce2d
>> github.com/go-vgo/robotgo.KeyTap({0x1001b879b 
>> , 0x1}, {0x0?, 
>> 0x0, 0x0?})
>> /Users/gp/Repositories/robotgo/key.go:519 +0x576 fp=0xc000187f28 
>> sp=0xc000187d78 pc=0x10016d436
>> main.keyTap()
>> /Users/gp/Repositories/robotgo/examples/key/main.go:47 +0x88 
>> fp=0xc000187f70 sp=0xc000187f28 pc=0x10016d908
>> main.main()
>> /Users/gp/Repositories/robotgo/examples/key/main.go:136 +0x17 
>> fp=0xc000187f80 sp=0xc000187f70 pc=0x10016d937
>> runtime.main()
>> /Users/gp/go/go1.19.4/src/runtime/proc.go:250 +0x212 
>> fp=0xc000187fe0 sp=0xc000187f80 pc=0x100039d32
>> runtime.goexit()
>> /Users/gp/go/go1.19.4/src/runtime/asm_amd64.s:1594 +0x1 
>> fp=0xc000187fe8 sp=0xc000187fe0 pc=0x100066861
>>
>> goroutine 2 [force gc (idle)]:
>> runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
>> /Users/gp/go/go1.19.4/src/runtime/proc.go:363 +0xd6 
>> fp=0xc58fb0 sp=0xc58f90 pc=0x10003a0f6
>> runtime.goparkunlock(...)
>> /Users/gp/go/go1.19.4/src/runtime/proc.go:369
>> runtime.forcegchelper()
>> /Users/gp/go/go1.19.4/src/runtime/proc.go:302 +0xad 
>> fp=0xc58fe0 sp=0xc58fb0 pc=0x100039f8d
>> runtime.goexit()
>> /Users/gp/go/go1.19.4/src/runtime/asm_amd64.s:1594 +0x1 
>> fp=0xc58fe8 sp=0xc58fe0 pc=0x100066861
>> created by runtime.init.6
>> /Users/gp/go/go1.19.4/src/runtime/proc.go:290 +0x25
>>
>> goroutine 3 [GC sweep wait]:
>> runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
>> /Users/gp/go/go1.19.4/src/

Re: [go-nuts] Help debugging a SIGSEGV - "unexpected signal during runtime execution"

[Kurtis Rader]

It superficially looks like you're running the code from
https://github.com/go-vgo/robotgo/blob/master/examples/key/main.go.
However, The line number 136 in main.go in the backtrace doesn't make any
sense since the example code from the project only has 134 lines. Did you
modify the example code? If so you'll need to show us your modifications.
Does the example from that project work if you don't modify it?

Note that the SIGSEGV is because the code is trying to use the value 8 as
an address. So it isn't a typical null/nil pointer dereference. Possibly
you're passing something like a length of some object as an argument which
should be the address of some object.

On Thu, Dec 8, 2022 at 9:23 AM Gerald Parker  wrote:

> Hi all,
> I'm using go version 1.19.4 darwin-amd64
>
> I keep getting the following errors while trying to use a function from
> the robotgo package. I'm not experienced in C and could use some help
> trying to find the problem
>
> fatal error: unexpected signal during runtime execution
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x10016df88]
>
> runtime stack:
> runtime.throw({0x1001c32bc?, 0x0?})
> /Users/gp/go/go1.19.4/src/runtime/panic.go:1047 +0x5d
> fp=0x7ff7bfeff520 sp=0x7ff7bfeff4f0 pc=0x10003751d
> runtime.sigpanic()
> /Users/gp/go/go1.19.4/src/runtime/signal_unix.go:819 +0x369
> fp=0x7ff7bfeff570 sp=0x7ff7bfeff520 pc=0x10004cf89
>
> goroutine 1 [syscall]:
> runtime.cgocall(0x10016df60, 0xc000187ce8)
> /Users/gp/go/go1.19.4/src/runtime/cgocall.go:158 +0x5c
> fp=0xc000187cc0 sp=0xc000187c88 pc=0x16d1c
> github.com/go-vgo/robotgo._Cfunc_keyCodeForChar(0x61)
> _cgo_gotypes.go:729 +0x47 fp=0xc000187ce8 sp=0xc000187cc0
> pc=0x10016c527
> github.com/go-vgo/robotgo.checkKeyCodes({0x1001b879b
> ?, 0x1?})
> /Users/gp/Repositories/robotgo/key.go:344 +0x7f fp=0xc000187d40
> sp=0xc000187ce8 pc=0x10016c89f
> github.com/go-vgo/robotgo.keyTaps({0x1001b879b
> , 0x1}, {0x0?,
> 0x1?, 0x0?}, 0x8?)
> /Users/gp/Repositories/robotgo/key.go:402 +0x4d fp=0xc000187d78
> sp=0xc000187d40 pc=0x10016ce2d
> github.com/go-vgo/robotgo.KeyTap({0x1001b879b
> , 0x1}, {0x0?,
> 0x0, 0x0?})
> /Users/gp/Repositories/robotgo/key.go:519 +0x576 fp=0xc000187f28
> sp=0xc000187d78 pc=0x10016d436
> main.keyTap()
> /Users/gp/Repositories/robotgo/examples/key/main.go:47 +0x88
> fp=0xc000187f70 sp=0xc000187f28 pc=0x10016d908
> main.main()
> /Users/gp/Repositories/robotgo/examples/key/main.go:136 +0x17
> fp=0xc000187f80 sp=0xc000187f70 pc=0x10016d937
> runtime.main()
> /Users/gp/go/go1.19.4/src/runtime/proc.go:250 +0x212
> fp=0xc000187fe0 sp=0xc000187f80 pc=0x100039d32
> runtime.goexit()
> /Users/gp/go/go1.19.4/src/runtime/asm_amd64.s:1594 +0x1
> fp=0xc000187fe8 sp=0xc000187fe0 pc=0x100066861
>
> goroutine 2 [force gc (idle)]:
> runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
> /Users/gp/go/go1.19.4/src/runtime/proc.go:363 +0xd6
> fp=0xc58fb0 sp=0xc58f90 pc=0x10003a0f6
> runtime.goparkunlock(...)
> /Users/gp/go/go1.19.4/src/runtime/proc.go:369
> runtime.forcegchelper()
> /Users/gp/go/go1.19.4/src/runtime/proc.go:302 +0xad
> fp=0xc58fe0 sp=0xc58fb0 pc=0x100039f8d
> runtime.goexit()
> /Users/gp/go/go1.19.4/src/runtime/asm_amd64.s:1594 +0x1
> fp=0xc58fe8 sp=0xc58fe0 pc=0x100066861
> created by runtime.init.6
> /Users/gp/go/go1.19.4/src/runtime/proc.go:290 +0x25
>
> goroutine 3 [GC sweep wait]:
> runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
> /Users/gp/go/go1.19.4/src/runtime/proc.go:363 +0xd6
> fp=0xc59790 sp=0xc59770 pc=0x10003a0f6
> runtime.goparkunlock(...)
> /Users/gp/go/go1.19.4/src/runtime/proc.go:369
> runtime.bgsweep(0x0?)
> /Users/gp/go/go1.19.4/src/runtime/mgcsweep.go:278 +0x8e
> fp=0xc597c8 sp=0xc59790 pc=0x10002738e
> runtime.gcenable.func1()
> /Users/gp/go/go1.19.4/src/runtime/mgc.go:178 +0x26 fp=0xc597e0
> sp=0xc597c8 pc=0x10001c246
> runtime.goexit()
> /Users/gp/go/go1.19.4/src/runtime/asm_amd64.s:1594 +0x1
> fp=0xc597e8 sp=0xc597e0 pc=0x100066861
> created by runtime.gcenable
> /Users/gp/go/go1.19.4/src/runtime/mgc.go:178 +0x6b
>
> goroutine 4 [GC scavenge wait]:
> runtime.gopark(0xc24070?, 0x10020b4a8?, 0x1?, 0x0?, 0x0?)
> /Users/gp/go/go1.19.4/src/runtime/proc.go:363 +0xd6
> fp=0xc59f70 sp=0xc59f50 pc=0x10003a0f6
> runtime.goparkunlock(...)
> /Users/gp/go/go1.19.4/src/runtime/proc.go:369
> runtime.(*scavengerState).park(0x10031a420)
> /Users/gp/go/go1.19.4/src/runtime/mgcscavenge.go:389 +0x53
> fp=0xc59fa0 sp=0xc59f70 pc=0x100025433
> runtime.bgscavenge(0x0?)
> /Users/gp/go/go1.19.4/src/runtime/mgcscavenge.go:617 +0x45
> fp=0xc59fc8 sp=0xc000

Re: [go-nuts] Help with sync.Cond failing to signal

[Kevin Burke]

I've added https://go-review.googlesource.com/c/go/+/412237 to try to make
this obvious to more people.




On Sun, Jun 12, 2022 at 2:47 AM Brian Candler  wrote:

> And just as an aside, I think you would be interested in the talk
> "Rethinking Classical Concurrency Patterns" by Bryan C. Mills
> https://www.youtube.com/watch?v=5zXAHh5tJqQ
>
> On Sunday, 12 June 2022 at 05:06:47 UTC+1 ke...@burke.dev wrote:
>
>> That's a very clear explanation, it's obvious what the problem is now.
>> Thank you!
>>
>> On Saturday, June 11, 2022 at 9:36:59 AM UTC-7 se...@liao.dev wrote:
>>
>>> sync.Cond does not affect goroutine scheduling priority, and Signal only
>>> makes the waiting goroutine available to be scheduled, but not force it to
>>> be.
>>> After a Signal() (and Unlock()), every other waiting worker and the
>>> flusher then contends (fairly) for the lock.
>>> What you want appears a better fit for either channels (send everything
>>> to the flusher) or just inlining the check+flush logic into writeEvent,
>>> essentially a proper serialization of events
>>>
>>> See also: https://github.com/golang/go/issues/21165
>>> > On top of that, condition variables are fiendishly difficult to use:
>>> they are prone to either missed or spurious signals [citation needed]
>>>
>>> - sean
>>>
>>>
>>> On Sat, Jun 11, 2022 at 3:27 PM Kevin Burke  wrote:
>>>
 Hi,
 Recently I inherited some code in production that was hitting an error
 case that I didn't think should be possible to hit. I reduced it down to
 this test case. To be clear, there are several different ways to improve
 the code here, but I'd like to understand why it's behaving the way it does
 first.

 You should be able to just do "go test ." here to reproduce the error:
 https://github.com/kevinburke/sync-cond-experiment

 What the code is doing:

- Multiple different goroutines are taking a sync.Cond lock and
then appending data to a shared buffer.
- A "flush" goroutine calls sync.Cond.Wait() to wait for an
incoming signal that data has been appended
- Each goroutine that appends to the buffer calls Signal() after
the write, to try to wake up the "flush" goroutine

 I *expect* that the flush goroutine will wake up after each call to
 Signal(), check whether the batch is ready to be flushed, and if not go
 back to sleep.

 What I see instead is that lots of other goroutines are taking out the
 lock before the flush goroutine can get to it, and as a result we're
 dropping data.

 I didn't expect that to happen based on my reading of the docs for
 sync.Cond, which (to me) indicate that Signal() will prioritize a goroutine
 that calls Wait() (instead of any other goroutines that are waiting on
 sync.Cond.L). Instead it looks like it's just unlocking any goroutine?
 Maybe this is because the thread that is calling Signal() holds the lock?

 Thanks for your help,
 Kevin

 --
 You received this message because you are subscribed 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/d7e17b2f-159c-4124-a023-eb2cdb8ba423n%40googlegroups.com
 
 .

>>> --
> 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/J-E3VR0UEYA/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/8d7ff74a-a623-4cce-b5fc-870ea8c1495en%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/CAKcy5eje4VN_ByT_226U7%3DLiq56HkHjtTc344oTz_YAH83k5OQ%40mail.gmail.com.

Re: [go-nuts] Help with sync.Cond failing to signal

[Brian Candler]

And just as an aside, I think you would be interested in the talk 
"Rethinking Classical Concurrency Patterns" by Bryan C. Mills
https://www.youtube.com/watch?v=5zXAHh5tJqQ

On Sunday, 12 June 2022 at 05:06:47 UTC+1 ke...@burke.dev wrote:

> That's a very clear explanation, it's obvious what the problem is now. 
> Thank you!
>
> On Saturday, June 11, 2022 at 9:36:59 AM UTC-7 se...@liao.dev wrote:
>
>> sync.Cond does not affect goroutine scheduling priority, and Signal only 
>> makes the waiting goroutine available to be scheduled, but not force it to 
>> be.
>> After a Signal() (and Unlock()), every other waiting worker and the 
>> flusher then contends (fairly) for the lock.
>> What you want appears a better fit for either channels (send everything 
>> to the flusher) or just inlining the check+flush logic into writeEvent,
>> essentially a proper serialization of events
>>
>> See also: https://github.com/golang/go/issues/21165 
>> > On top of that, condition variables are fiendishly difficult to use: 
>> they are prone to either missed or spurious signals [citation needed]
>>
>> - sean
>>
>>
>> On Sat, Jun 11, 2022 at 3:27 PM Kevin Burke  wrote:
>>
>>> Hi,
>>> Recently I inherited some code in production that was hitting an error 
>>> case that I didn't think should be possible to hit. I reduced it down to 
>>> this test case. To be clear, there are several different ways to improve 
>>> the code here, but I'd like to understand why it's behaving the way it does 
>>> first. 
>>>
>>> You should be able to just do "go test ." here to reproduce the error: 
>>> https://github.com/kevinburke/sync-cond-experiment
>>>
>>> What the code is doing:
>>>
>>>- Multiple different goroutines are taking a sync.Cond lock and then 
>>>appending data to a shared buffer.
>>>- A "flush" goroutine calls sync.Cond.Wait() to wait for an incoming 
>>>signal that data has been appended
>>>- Each goroutine that appends to the buffer calls Signal() after the 
>>>write, to try to wake up the "flush" goroutine
>>>
>>> I *expect* that the flush goroutine will wake up after each call to 
>>> Signal(), check whether the batch is ready to be flushed, and if not go 
>>> back to sleep. 
>>>
>>> What I see instead is that lots of other goroutines are taking out the 
>>> lock before the flush goroutine can get to it, and as a result we're 
>>> dropping data.
>>>
>>> I didn't expect that to happen based on my reading of the docs for 
>>> sync.Cond, which (to me) indicate that Signal() will prioritize a goroutine 
>>> that calls Wait() (instead of any other goroutines that are waiting on 
>>> sync.Cond.L). Instead it looks like it's just unlocking any goroutine? 
>>> Maybe this is because the thread that is calling Signal() holds the lock?
>>>
>>> Thanks for your help,
>>> Kevin
>>>
>>> -- 
>>> You received this message because you are subscribed 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/d7e17b2f-159c-4124-a023-eb2cdb8ba423n%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/8d7ff74a-a623-4cce-b5fc-870ea8c1495en%40googlegroups.com.

Re: [go-nuts] Help with sync.Cond failing to signal

[Kevin Burke]

That's a very clear explanation, it's obvious what the problem is now. 
Thank you!

On Saturday, June 11, 2022 at 9:36:59 AM UTC-7 se...@liao.dev wrote:

> sync.Cond does not affect goroutine scheduling priority, and Signal only 
> makes the waiting goroutine available to be scheduled, but not force it to 
> be.
> After a Signal() (and Unlock()), every other waiting worker and the 
> flusher then contends (fairly) for the lock.
> What you want appears a better fit for either channels (send everything to 
> the flusher) or just inlining the check+flush logic into writeEvent,
> essentially a proper serialization of events
>
> See also: https://github.com/golang/go/issues/21165 
> > On top of that, condition variables are fiendishly difficult to use: 
> they are prone to either missed or spurious signals [citation needed]
>
> - sean
>
>
> On Sat, Jun 11, 2022 at 3:27 PM Kevin Burke  wrote:
>
>> Hi,
>> Recently I inherited some code in production that was hitting an error 
>> case that I didn't think should be possible to hit. I reduced it down to 
>> this test case. To be clear, there are several different ways to improve 
>> the code here, but I'd like to understand why it's behaving the way it does 
>> first. 
>>
>> You should be able to just do "go test ." here to reproduce the error: 
>> https://github.com/kevinburke/sync-cond-experiment
>>
>> What the code is doing:
>>
>>- Multiple different goroutines are taking a sync.Cond lock and then 
>>appending data to a shared buffer.
>>- A "flush" goroutine calls sync.Cond.Wait() to wait for an incoming 
>>signal that data has been appended
>>- Each goroutine that appends to the buffer calls Signal() after the 
>>write, to try to wake up the "flush" goroutine
>>
>> I *expect* that the flush goroutine will wake up after each call to 
>> Signal(), check whether the batch is ready to be flushed, and if not go 
>> back to sleep. 
>>
>> What I see instead is that lots of other goroutines are taking out the 
>> lock before the flush goroutine can get to it, and as a result we're 
>> dropping data.
>>
>> I didn't expect that to happen based on my reading of the docs for 
>> sync.Cond, which (to me) indicate that Signal() will prioritize a goroutine 
>> that calls Wait() (instead of any other goroutines that are waiting on 
>> sync.Cond.L). Instead it looks like it's just unlocking any goroutine? 
>> Maybe this is because the thread that is calling Signal() holds the lock?
>>
>> Thanks for your help,
>> Kevin
>>
>> -- 
>> You received this message because you are subscribed 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/d7e17b2f-159c-4124-a023-eb2cdb8ba423n%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/6f11b3cd-4eb3-499c-a8d3-a3b88a332097n%40googlegroups.com.

Re: [go-nuts] Help with sync.Cond failing to signal

['Sean Liao' via golang-nuts]

sync.Cond does not affect goroutine scheduling priority, and Signal only
makes the waiting goroutine available to be scheduled, but not force it to
be.
After a Signal() (and Unlock()), every other waiting worker and the flusher
then contends (fairly) for the lock.
What you want appears a better fit for either channels (send everything to
the flusher) or just inlining the check+flush logic into writeEvent,
essentially a proper serialization of events

See also: https://github.com/golang/go/issues/21165
> On top of that, condition variables are fiendishly difficult to use: they
are prone to either missed or spurious signals [citation needed]

- sean


On Sat, Jun 11, 2022 at 3:27 PM Kevin Burke  wrote:

> Hi,
> Recently I inherited some code in production that was hitting an error
> case that I didn't think should be possible to hit. I reduced it down to
> this test case. To be clear, there are several different ways to improve
> the code here, but I'd like to understand why it's behaving the way it does
> first.
>
> You should be able to just do "go test ." here to reproduce the error:
> https://github.com/kevinburke/sync-cond-experiment
>
> What the code is doing:
>
>- Multiple different goroutines are taking a sync.Cond lock and then
>appending data to a shared buffer.
>- A "flush" goroutine calls sync.Cond.Wait() to wait for an incoming
>signal that data has been appended
>- Each goroutine that appends to the buffer calls Signal() after the
>write, to try to wake up the "flush" goroutine
>
> I *expect* that the flush goroutine will wake up after each call to
> Signal(), check whether the batch is ready to be flushed, and if not go
> back to sleep.
>
> What I see instead is that lots of other goroutines are taking out the
> lock before the flush goroutine can get to it, and as a result we're
> dropping data.
>
> I didn't expect that to happen based on my reading of the docs for
> sync.Cond, which (to me) indicate that Signal() will prioritize a goroutine
> that calls Wait() (instead of any other goroutines that are waiting on
> sync.Cond.L). Instead it looks like it's just unlocking any goroutine?
> Maybe this is because the thread that is calling Signal() holds the lock?
>
> Thanks for your help,
> Kevin
>
> --
> You received this message because you are subscribed to the Google 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/d7e17b2f-159c-4124-a023-eb2cdb8ba423n%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/CAGabyPp2U8yYi8FqWGC-urb4zGU4e1F33AxMekvxofjMHeCbeg%40mail.gmail.com.

Re: [go-nuts] Help with GOLLVM

['Than McIntosh' via golang-nuts]

Hi,

>>The whole point of my poc was to be able to get the LLVMIR of GO then put
it into an iOS app with bitcode enable. What are you saying is that it is
not possible to achieve this?

It's definitely outside the normal/expected use of gollvm, but it seems at
least possible to do this.

The key thing is that for a Go program to run, it needs copies of all its
dependent packages. That means that those packages need to be compiled down
to bitcode as well, and then the whole collection handed off to whatever is
going to be executing the bitcode.

To list your transitive dependencies, you can do something like

  $ go list -json hello2.go

and then look at the "Deps" section.

I think the last time this was attempted, some hacks were required in the
runtime (see https://go-review.googlesource.com/c/gofrontend/+/140917), so
you might need to dust off that CL and get it working again.

Thanks, Than




On Tue, Jan 4, 2022 at 2:49 AM Danilo bestbug 
wrote:

> Hello,
> Thanks for the answer. I've still some question then. The whole point of
> my poc was to be able to get the LLVMIR of GO then put it into an iOS app
> with bitcode enable. What are you saying is that it is not possible to
> achieve this? Or it's possible but I've to add the missing symbols? If is
> the second thing do you have any idea how to do this?
>
> Thanks!
>
> Il giorno gio 16 dic 2021 alle ore 22:38 Than McIntosh 
> ha scritto:
>
>> Greetings,
>>
>> The code that Go compilers emit is closely tied to the Go runtime-- any
>> compiled Go code (including *.ll files) will have references to symbols
>> that it needs from the runtime. When you try to convert your LLVM-produced
>> bitcode into a binary via
>>
>> clang helloworld.ll -o helloworldLLVM
>>
>> you're effectively not including definitions of any of those key runtime
>> routines (for example, "runtime.newobject", which is one of the functions
>> that supports memory allocation).
>>
>> It would be similar to what might happen if you took a C++ "hi mom"
>> program, compiled it down to an object file using "clang++", then tried to
>> link the resulting object into a binary using "gcc".
>>
>> Hope this helps--
>>
>> Than
>>
>> On Thu, Dec 16, 2021 at 1:07 PM Danilo bestbug <
>> bestbug.corporat...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at
>>> the moment a simple test repository
>>> , I was able to create
>>> the ll file with the following command:
>>>
>>> go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1
>>> WORK=$(egrep -m 1 '(WORK=|llvm-goc -c)' transcript.txt | awk '{ print
>>> substr ($0, 6 ) }')
>>>
>>> /gollvm/install/bin/llvm-goc -c -O2 -g -m64
>>> -fdebug-prefix-map=$WORK=/tmp/go-build \
>>> -gno-record-gcc-switches -fgo-pkgpath=$PWD \
>>> -fgo-relative-import-path=$PWD -o $WORK/b001/_go_.o \
>>> -I $WORK/b001/_importcfgroot_ -o $LLFILE -S -emit-llvm $MAINFILE
>>>
>>> But when I try to convert to binary via clang the file I've some error:
>>> clang helloworld.ll -o helloworldLLVM
>>> warning: overriding the module target triple with x86_64-pc-linux-gnu
>>> [-Woverride-module]
>>> 1 warning generated.
>>> /usr/bin/ld:
>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:
>>> in function `_start':
>>> (.text+0x24): undefined reference to `main'
>>> /usr/bin/ld: /tmp/helloworld-bcb8cc.o: in function
>>> `_..z2fopt..z2fvmsdk..z2fhelloworld.describe':
>>> /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
>>> `runtime.newobject'
>>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>>> to `runtime.writeBarrier'
>>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>>> to `fmt.Printf'
>>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>>> to `runtime.typedmemmove'
>>> /usr/bin/ld:
>>> /tmp/helloworld-bcb8cc.o:(.rodata.string..d[string..d]+0x18): undefined
>>> reference to `runtime.strequal..f'
>>> /usr/bin/ld:
>>> /tmp/helloworld-bcb8cc.o:(.rodata.type...1string[type...1string]+0x18):
>>> undefined reference to `runtime.memequal64..f'
>>> clang: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>>
>>>
>>> I'm this is the first time I use this buildchain and I don't understand
>>> what I'm doing wrong. Can someone help me?
>>> Those are the commit I've used for build gollvm, if needed
>>>
>>> llvm-project: 43ff75f2c3feef64f9d73328230d34dac8832a91
>>> llvm-project/llvm/tools/gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
>>> llvm-project/llvm/tools/gollvm/gofrontend:
>>> be0d2cc2df9f98d967c242594838f86362dae2e7
>>> llvm-project/llvm/tools/gollvm/libgo/libffi:
>>> 737d4faa00d681b4c758057f67e1a02d813d01c2
>>> llvm-project/llvm/tools/gollvm/libgo/libbacktrace:
>>> 5a99ff7fed66b8ea8f09c9805c138524a7035ece
>>>
>>> Thanks in advance!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-n

Re: [go-nuts] Help with GOLLVM

[Danilo bestbug]

Hello,
Thanks for the answer. I've still some question then. The whole point of my
poc was to be able to get the LLVMIR of GO then put it into an iOS app with
bitcode enable. What are you saying is that it is not possible to achieve
this? Or it's possible but I've to add the missing symbols? If is the
second thing do you have any idea how to do this?

Thanks!

Il giorno gio 16 dic 2021 alle ore 22:38 Than McIntosh 
ha scritto:

> Greetings,
>
> The code that Go compilers emit is closely tied to the Go runtime-- any
> compiled Go code (including *.ll files) will have references to symbols
> that it needs from the runtime. When you try to convert your LLVM-produced
> bitcode into a binary via
>
> clang helloworld.ll -o helloworldLLVM
>
> you're effectively not including definitions of any of those key runtime
> routines (for example, "runtime.newobject", which is one of the functions
> that supports memory allocation).
>
> It would be similar to what might happen if you took a C++ "hi mom"
> program, compiled it down to an object file using "clang++", then tried to
> link the resulting object into a binary using "gcc".
>
> Hope this helps--
>
> Than
>
> On Thu, Dec 16, 2021 at 1:07 PM Danilo bestbug <
> bestbug.corporat...@gmail.com> wrote:
>
>> Hello,
>>
>> I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at
>> the moment a simple test repository
>> , I was able to create
>> the ll file with the following command:
>>
>> go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1
>> WORK=$(egrep -m 1 '(WORK=|llvm-goc -c)' transcript.txt | awk '{ print
>> substr ($0, 6 ) }')
>>
>> /gollvm/install/bin/llvm-goc -c -O2 -g -m64
>> -fdebug-prefix-map=$WORK=/tmp/go-build \
>> -gno-record-gcc-switches -fgo-pkgpath=$PWD \
>> -fgo-relative-import-path=$PWD -o $WORK/b001/_go_.o \
>> -I $WORK/b001/_importcfgroot_ -o $LLFILE -S -emit-llvm $MAINFILE
>>
>> But when I try to convert to binary via clang the file I've some error:
>> clang helloworld.ll -o helloworldLLVM
>> warning: overriding the module target triple with x86_64-pc-linux-gnu
>> [-Woverride-module]
>> 1 warning generated.
>> /usr/bin/ld:
>> /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:
>> in function `_start':
>> (.text+0x24): undefined reference to `main'
>> /usr/bin/ld: /tmp/helloworld-bcb8cc.o: in function
>> `_..z2fopt..z2fvmsdk..z2fhelloworld.describe':
>> /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
>> `runtime.newobject'
>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>> to `runtime.writeBarrier'
>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>> to `fmt.Printf'
>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>> to `runtime.typedmemmove'
>> /usr/bin/ld:
>> /tmp/helloworld-bcb8cc.o:(.rodata.string..d[string..d]+0x18): undefined
>> reference to `runtime.strequal..f'
>> /usr/bin/ld:
>> /tmp/helloworld-bcb8cc.o:(.rodata.type...1string[type...1string]+0x18):
>> undefined reference to `runtime.memequal64..f'
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>
>>
>> I'm this is the first time I use this buildchain and I don't understand
>> what I'm doing wrong. Can someone help me?
>> Those are the commit I've used for build gollvm, if needed
>>
>> llvm-project: 43ff75f2c3feef64f9d73328230d34dac8832a91
>> llvm-project/llvm/tools/gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
>> llvm-project/llvm/tools/gollvm/gofrontend:
>> be0d2cc2df9f98d967c242594838f86362dae2e7
>> llvm-project/llvm/tools/gollvm/libgo/libffi:
>> 737d4faa00d681b4c758057f67e1a02d813d01c2
>> llvm-project/llvm/tools/gollvm/libgo/libbacktrace:
>> 5a99ff7fed66b8ea8f09c9805c138524a7035ece
>>
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/d503d8bf-e904-42be-9955-6813d4f8c29fn%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/CAMoLcsmKMaXjndFL2yu-aNrhQt5ixaQL%3DjJgVKi5sySYFVrGfA%40mail.gmail.com.

Re: [go-nuts] Help with GOLLVM

['Than McIntosh' via golang-nuts]

Greetings,

The code that Go compilers emit is closely tied to the Go runtime-- any
compiled Go code (including *.ll files) will have references to symbols
that it needs from the runtime. When you try to convert your LLVM-produced
bitcode into a binary via

clang helloworld.ll -o helloworldLLVM

you're effectively not including definitions of any of those key runtime
routines (for example, "runtime.newobject", which is one of the functions
that supports memory allocation).

It would be similar to what might happen if you took a C++ "hi mom"
program, compiled it down to an object file using "clang++", then tried to
link the resulting object into a binary using "gcc".

Hope this helps--

Than

On Thu, Dec 16, 2021 at 1:07 PM Danilo bestbug <
bestbug.corporat...@gmail.com> wrote:

> Hello,
>
> I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at
> the moment a simple test repository
> , I was able to create
> the ll file with the following command:
>
> go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1
> WORK=$(egrep -m 1 '(WORK=|llvm-goc -c)' transcript.txt | awk '{ print
> substr ($0, 6 ) }')
>
> /gollvm/install/bin/llvm-goc -c -O2 -g -m64
> -fdebug-prefix-map=$WORK=/tmp/go-build \
> -gno-record-gcc-switches -fgo-pkgpath=$PWD \
> -fgo-relative-import-path=$PWD -o $WORK/b001/_go_.o \
> -I $WORK/b001/_importcfgroot_ -o $LLFILE -S -emit-llvm $MAINFILE
>
> But when I try to convert to binary via clang the file I've some error:
> clang helloworld.ll -o helloworldLLVM
> warning: overriding the module target triple with x86_64-pc-linux-gnu
> [-Woverride-module]
> 1 warning generated.
> /usr/bin/ld:
> /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:
> in function `_start':
> (.text+0x24): undefined reference to `main'
> /usr/bin/ld: /tmp/helloworld-bcb8cc.o: in function
> `_..z2fopt..z2fvmsdk..z2fhelloworld.describe':
> /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `runtime.newobject'
> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `runtime.writeBarrier'
> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `fmt.Printf'
> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `runtime.typedmemmove'
> /usr/bin/ld: /tmp/helloworld-bcb8cc.o:(.rodata.string..d[string..d]+0x18):
> undefined reference to `runtime.strequal..f'
> /usr/bin/ld:
> /tmp/helloworld-bcb8cc.o:(.rodata.type...1string[type...1string]+0x18):
> undefined reference to `runtime.memequal64..f'
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> I'm this is the first time I use this buildchain and I don't understand
> what I'm doing wrong. Can someone help me?
> Those are the commit I've used for build gollvm, if needed
>
> llvm-project: 43ff75f2c3feef64f9d73328230d34dac8832a91
> llvm-project/llvm/tools/gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
> llvm-project/llvm/tools/gollvm/gofrontend:
> be0d2cc2df9f98d967c242594838f86362dae2e7
> llvm-project/llvm/tools/gollvm/libgo/libffi:
> 737d4faa00d681b4c758057f67e1a02d813d01c2
> llvm-project/llvm/tools/gollvm/libgo/libbacktrace:
> 5a99ff7fed66b8ea8f09c9805c138524a7035ece
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d503d8bf-e904-42be-9955-6813d4f8c29fn%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/CA%2BUr55EkHmiMhUXTWqWNY0bQOTzV6fkte-T5XieSWeQxnKJKsg%40mail.gmail.com.

Re: [go-nuts] Help Gmail Post Master

[Kurtis Rader]

Can you show us an example of the code you've written that doesn't do what
you expect? Can you expand on what you mean by "some problem"? Did you read
the associated documentation at
https://pkg.go.dev/google.golang.org/api@v0.56.0/gmailpostmastertools/v1
and have you verified you can get those examples to work?

On Wed, Sep 8, 2021 at 9:02 AM Muhammad Abdur Rofi 
wrote:

>
> Hello Guys, My name is Abdur Rofi, I'm from Indonesia.
> I'm new in Golang. I have some problem to use
> https://github.com/googleapis/google-api-go-client/tree/master/gmailpostmastertools
> .
>
> Maybe someone can help me to show some example about how to use this
> library.
>
> Thank's
>
> --
> You received this message because you are subscribed to the Google 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/abff4058-a490-48be-8b6f-c1131a86d334n%40googlegroups.com
> 
> .
>


-- 
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/CABx2%3DD_biVpYwGBURvpTVtGUF%3DJ7CwjgvaSL-2DBvnsY0VPxjw%40mail.gmail.com.

Re: [go-nuts] Help with tcpserver

[Perry Couprie]

It works now i added the ReadDeadline, thanks for the help :-)

Perry

On Wednesday, March 31, 2021 at 1:22:20 PM UTC+2 Brian Candler wrote:

> I think that in principle you are correct to perform your reads inside a 
> goroutine, to allow them to be received asynchronously.
>
> If Read() blocks, it's not a problem unless you want to shut down the 
> connection from the server side, and you can do that by setting a read 
> timeout which will unblock the read:
>
> go func() {
> select {
> case <-RecieverClose:  // sic
> conn.SetReadDeadline(time.Now())
> }
> }()
>
>

-- 
You received this message because you are subscribed to the Google 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/8f4fab08-8a26-4a41-9923-3a0263e77bean%40googlegroups.com.

Re: [go-nuts] Help with tcpserver

[Brian Candler]

I think that in principle you are correct to perform your reads inside a 
goroutine, to allow them to be received asynchronously.

If Read() blocks, it's not a problem unless you want to shut down the 
connection from the server side, and you can do that by setting a read 
timeout which will unblock the read:

go func() {
select {
case <-RecieverClose:  // sic
conn.SetReadDeadline(time.Now())
}
}()

-- 
You received this message because you are subscribed to the Google 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/459f0bf2-d66e-43c8-88e8-1f18dc39f986n%40googlegroups.com.

Re: [go-nuts] Help with tcpserver

[Perry Couprie]

The protocol i am programming for sends a header of 8 bytes that contains a 
body length.
My problem is dat c.Read(buf) is blocking. Can i read from the tcp 
connection non blocking ? 


On Wednesday, March 31, 2021 at 9:08:48 AM UTC+2 Brian Candler wrote:

> On Wednesday, 31 March 2021 at 04:13:12 UTC+1 matt@gmail.com wrote:
>
>>   for i := 0; i > 5; i++ {
>> // handle a single message
>> n, err := c.Read(buf)
>> if err == io.EOF {
>>   break
>> }
>> fmt.Fprintf(c, "Message Count %d, Data %s", i+1, buf[:n])
>>
>
> I will point out that it's possible for io.Read to return valid data *and* 
> an error (including io.EOF).  See https://golang.org/pkg/io/#Reader
>
>
> *"When Read encounters an error or end-of-file condition after 
> successfully reading n > 0 bytes, it returns the number of bytes read. It 
> may return the (non-nil) error from the same call or return the error (and 
> n == 0) from a subsequent call. An instance of this general case is that a 
> Reader returning a non-zero number of bytes at the end of the input stream 
> may return either err == EOF or err == nil. The next Read should return 0, 
> EOF."*
>
> So perhaps you want something more like this:
>
> n, err := c.Read(buf)
> if n > 0 {
>   fmt.Fprintf(c, "Message Count %d, Data %s", i+1, buf[:n])
> }
> if err == io.EOF {
>   break
> }
> if err != nil {
>   fmt.Fprintf("Error: %s", err)
>   break
> }
>
> Note that TCP is stream-oriented, so the number of bytes returned from 
>> Read is not at all guaranteed to match the number of bytes the client sent. 
>> The returned data can be part of one or more messages. You need some other 
>> mechanism to divide the data received into messages. For example you might 
>> want to read a line at a time instead.
>>
>
> That's critical.  Messages need to be delimited somehow.  Some protocols 
> send a length followed by that number of bytes of data.  Note that the JSON 
> encoder/decoder in go supports sending objects one after the other - that 
> is, the structure of a JSON object performs the delineation.  After the 
> start of an object '{' the decoder will keep consuming data until it gets 
> the matching close '}'
>

-- 
You received this message because you are subscribed to the Google 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/321c86c3-bed6-4afa-9291-b925d6072f8bn%40googlegroups.com.

Re: [go-nuts] Help with tcpserver

[Brian Candler]

On Wednesday, 31 March 2021 at 04:13:12 UTC+1 matt@gmail.com wrote:

>   for i := 0; i > 5; i++ {
> // handle a single message
> n, err := c.Read(buf)
> if err == io.EOF {
>   break
> }
> fmt.Fprintf(c, "Message Count %d, Data %s", i+1, buf[:n])
>

I will point out that it's possible for io.Read to return valid data *and* 
an error (including io.EOF).  See https://golang.org/pkg/io/#Reader


*"When Read encounters an error or end-of-file condition after successfully 
reading n > 0 bytes, it returns the number of bytes read. It may return the 
(non-nil) error from the same call or return the error (and n == 0) from a 
subsequent call. An instance of this general case is that a Reader 
returning a non-zero number of bytes at the end of the input stream may 
return either err == EOF or err == nil. The next Read should return 0, 
EOF."*

So perhaps you want something more like this:

n, err := c.Read(buf)
if n > 0 {
  fmt.Fprintf(c, "Message Count %d, Data %s", i+1, buf[:n])
}
if err == io.EOF {
  break
}
if err != nil {
  fmt.Fprintf("Error: %s", err)
  break
}

Note that TCP is stream-oriented, so the number of bytes returned from Read 
> is not at all guaranteed to match the number of bytes the client sent. The 
> returned data can be part of one or more messages. You need some other 
> mechanism to divide the data received into messages. For example you might 
> want to read a line at a time instead.
>

That's critical.  Messages need to be delimited somehow.  Some protocols 
send a length followed by that number of bytes of data.  Note that the JSON 
encoder/decoder in go supports sending objects one after the other - that 
is, the structure of a JSON object performs the delineation.  After the 
start of an object '{' the decoder will keep consuming data until it gets 
the matching close '}'

-- 
You received this message because you are subscribed to the Google 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/f7aa702c-80e2-4c2c-a269-a88d4cf43680n%40googlegroups.com.

Re: [go-nuts] Help with tcpserver

[Perry Couprie]

I am programming a binary protocol. The demo with telnet and the max of 5 
messages was for testing this problem. 
I need to be able send even when not recieving data. The program now works, 
when de the client breaks the connection, there is no problem. 
When de server stops the connection it some times works, some times not and 
even chrashes.

Perry
On Wednesday, March 31, 2021 at 5:13:12 AM UTC+2 matt@gmail.com wrote:

> Why are you using channels for this? I see some issues in the code, but 
> without knowing what you're actually trying to accomplish, it's hard to 
> give advice.
>
> To do exactly what you described, I would simply change 
> handleDeviceConnection() to look similar to this:
>
> func handleDeviceConnection(c net.Conn) {
>   defer c.Close()
>   buf := make([]byte, 2048)
>   for i := 0; i > 5; i++ {
> // handle a single message
> n, err := c.Read(buf)
> if err == io.EOF {
>   break
> }
> fmt.Fprintf(c, "Message Count %d, Data %s", i+1, buf[:n])
> }
> }
>
> Note that TCP is stream-oriented, so the number of bytes returned from 
> Read is not at all guaranteed to match the number of bytes the client sent. 
> The returned data can be part of one or more messages. You need some other 
> mechanism to divide the data received into messages. For example you might 
> want to read a line at a time instead.
>
> On Tue, Mar 30, 2021 at 3:11 PM Perry Couprie  wrote:
>
>> Hi,
>>
>> I create a tcp server with goroutines.
>>
>> When the tcp client closes the connection it workes.
>>
>> After recieving 5 message from a telnet client it tries to close the 
>> connection.
>> Some times it works, and sometimes not.
>>
>> I create a smal demo : https://pastebin.com/raw/BjZWzLFq
>>
>> This is my first try with channels.
>> What am i doing wrong ?
>>
>> Greeting from Amsterdam Netherland,
>> Perry
>>
>> -- 
>> You received this message because you are subscribed 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/fedfcbaf-2e7d-496a-bb6a-a31eeafe4407n%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/a070623a-ca11-4a05-b3d7-71896295ead9n%40googlegroups.com.

Re: [go-nuts] Help with tcpserver

[Matt Harden]

Why are you using channels for this? I see some issues in the code, but
without knowing what you're actually trying to accomplish, it's hard to
give advice.

To do exactly what you described, I would simply change
handleDeviceConnection() to look similar to this:

func handleDeviceConnection(c net.Conn) {
  defer c.Close()
  buf := make([]byte, 2048)
  for i := 0; i > 5; i++ {
// handle a single message
n, err := c.Read(buf)
if err == io.EOF {
  break
}
fmt.Fprintf(c, "Message Count %d, Data %s", i+1, buf[:n])
}
}

Note that TCP is stream-oriented, so the number of bytes returned from Read
is not at all guaranteed to match the number of bytes the client sent. The
returned data can be part of one or more messages. You need some other
mechanism to divide the data received into messages. For example you might
want to read a line at a time instead.

On Tue, Mar 30, 2021 at 3:11 PM Perry Couprie  wrote:

> Hi,
>
> I create a tcp server with goroutines.
>
> When the tcp client closes the connection it workes.
>
> After recieving 5 message from a telnet client it tries to close the
> connection.
> Some times it works, and sometimes not.
>
> I create a smal demo : https://pastebin.com/raw/BjZWzLFq
>
> This is my first try with channels.
> What am i doing wrong ?
>
> Greeting from Amsterdam Netherland,
> Perry
>
> --
> You received this message because you are subscribed to the Google 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/fedfcbaf-2e7d-496a-bb6a-a31eeafe4407n%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/CALRNMm0-vYjR4V3ChAY20dKaD1YSyNvCwcvA6C%2Bna0%2BBz0yU_w%40mail.gmail.com.

Re: [go-nuts] Help with contributing to the Golang

[Ian Lance Taylor]

On Thu, Mar 18, 2021 at 9:55 AM Kirill Prokopovich  wrote:
>
> Hello everyone!
> Can somebody help with some advice about starting contributing in Golang?
>
> I've already read https://golang.org/doc/contribute.html and tried to find 
> some issues from https://github.com/golang/go/labels/help%20wanted , but it's 
> not so obvious how to choose a free issue but I'm not sure about its status 
> (busy or not)

Most issues are not busy, and especially most "help wanted" issues are
not busy.  It is always OK to ask on an issue whether you can try
fixing it.  We only ask that if you do so, and you decide that you
aren't going to be able to fix it, that you say that too.

Thanks for your interest in Go!

Ian

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

Re: [go-nuts] Help with code reproducing a change in Go 1.15 CL 229578

[Florin Pățan]

Hi Ian,

Thank you for your reply.

At the moment, I don't have any data about this. The question raised from 
the fact that the language in the documentation suggests that a compiler 
error would occur, at least to me as a user with English as a second 
language.

So, when I created some test scenarios to know if we should add similar 
checks for this in GoLand, I was a bit surprised that there's nothing that 
would happen, either with `go build` or with `go vet`.

I'll see if I can find any such usages and report back here. For now, it 
seems we can omit to create such a check in the IDE / other static analysis 
tools.

Thank you,
Florin

On Friday, June 19, 2020 at 8:13:37 AM UTC+3 Ian Lance Taylor wrote:

> On Thu, Jun 18, 2020 at 1:54 AM Florin Pățan wrote: 
> > 
> > According to the Go 1.15 documentation, the change introduced in 
> https://golang.org/cl/229578 should change the program behavior, and 
> users are expected to perform modifications to their code. 
> > 
> > > Package unsafe's safety rules allow converting an unsafe.Pointer into 
> uintptr when calling certain functions. Previously, in some cases, the 
> compiler allowed multiple chained conversions (for example, 
> syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires 
> exactly one conversion. Code that used multiple conversions should be 
> updated to satisfy the safety rules. 
> > 
> > After reading that paragraph, I expect that the compiler fails to 
> compile code after that change. When running `go build` or `go build 
> -gcflags="-d=checkptr"` neither produce a failure. I used `go vet`, and 
> that doesn't catch this change either. 
> > 
> > The example I used is https://play.golang.org/p/a0B4kxLEAjb. 
> > 
> > Perhaps I failed to construct a correct example, in which case help 
> would be appreciated. 
> > 
> > I was not sure if this belongs to the mailing list or the issue tracker, 
> so I started here. 
>
> What has changed is that the compiler does not keep multiply-casted 
> pointers live across the call to syscall.Syscall. 
>
> Our assumption was that nobody actually wrote code like that. Why 
> would they? Do you know of any real code that does this? If there is 
> no real code, then it doesn't seem worth spending the time to write 
> checks. If we were going to do that, we might as well instead spend 
> the time to let the code continue to work. 
>
> 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/3545930b-1b40-44b3-89c7-3ba24a5be797n%40googlegroups.com.

Re: [go-nuts] Help with code reproducing a change in Go 1.15 CL 229578

[Ian Lance Taylor]

On Thu, Jun 18, 2020 at 1:54 AM Florin Pățan  wrote:
>
> According to the Go 1.15 documentation, the change introduced in 
> https://golang.org/cl/229578 should change the program behavior, and users 
> are expected to perform modifications to their code.
>
> > Package unsafe's safety rules allow converting an unsafe.Pointer into 
> > uintptr when calling certain functions. Previously, in some cases, the 
> > compiler allowed multiple chained conversions (for example, 
> > syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires 
> > exactly one conversion. Code that used multiple conversions should be 
> > updated to satisfy the safety rules.
>
> After reading that paragraph, I expect that the compiler fails to compile 
> code after that change. When running `go build` or `go build 
> -gcflags="-d=checkptr"` neither produce a failure. I used `go vet`, and that 
> doesn't catch this change either.
>
> The example I used is https://play.golang.org/p/a0B4kxLEAjb.
>
> Perhaps I failed to construct a correct example, in which case help would be 
> appreciated.
>
> I was not sure if this belongs to the mailing list or the issue tracker, so I 
> started here.

What has changed is that the compiler does not keep multiply-casted
pointers live across the call to syscall.Syscall.

Our assumption was that nobody actually wrote code like that.  Why
would they?  Do you know of any real code that does this?  If there is
no real code, then it doesn't seem worth spending the time to write
checks.  If we were going to do that, we might as well instead spend
the time to let the code continue to work.

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

Re: [go-nuts] [HELP] Install golang.org/x/tools/present successful but cannot find the binary

[gede . pentium]

Hi Sebastien, 

Thanks for the answer. Yes I just realised I was installing the package 
instead of the command. It works now :+1:

On Thursday, May 28, 2020 at 1:16:00 AM UTC+8, Sebastien Binet wrote:
>
> hi,
>
> golang.org/x/tools/present is the package.
> golang.org/x/tools/cmd/present is the command.
>
> you should install the command :) (which will in turn compile and install 
> the package under the cover).
>
> hth,
> -s
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, May 27, 2020 7:05 AM, Gede Pentium  > wrote:
>
> I've tried to install the *golang.org/x/tools/present 
> *, but still cannot find the *present* 
> binary in $GOPATH/bin
>
> Command: *go get -u -v golang.org/x/tools/present 
> *
>
> There is no error in the installation, even after adding *-v* flag there 
> is no error
>
> go version *go1.14.3* darwin/amd64
>
> My ./bashrc
>
> export GOPATH=$HOME/go
> export GOROOT=/usr/local/go
> export PATH=$PATH:$GOPATH/bin
> export PATH=$PATH:$GOROOT/bin
>
>
> --
> You received this message because you 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/fd88c1ca-394f-4cb0-bbb5-55e25a2bd4ee%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/55812bcf-28fc-4203-a806-967505208c8b%40googlegroups.com.

Re: [go-nuts] [HELP] Install golang.org/x/tools/present successful but cannot find the binary

[Sebastien Binet]

hi,

golang.org/x/tools/present is the package.
golang.org/x/tools/cmd/present is the command.

you should install the command :) (which will in turn compile and install the 
package under the cover).

hth,
-s

‐‐‐ Original Message ‐‐‐
On Wednesday, May 27, 2020 7:05 AM, Gede Pentium  
wrote:

> I've tried to install the golang.org/x/tools/present, but still cannot find 
> the present binary in $GOPATH/bin
>
> Command: go get -u -v golang.org/x/tools/present
>
> There is no error in the installation, even after adding -v flag there is no 
> error
>
> go version go1.14.3 darwin/amd64
>
> My ./bashrc
>
> export GOPATH=$HOME/go
> export GOROOT=/usr/local/go
> export PATH=$PATH:$GOPATH/bin
> export PATH=$PATH:$GOROOT/bin
>
> --
> You received this message because you are subscribed to the Google 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/fd88c1ca-394f-4cb0-bbb5-55e25a2bd4ee%40googlegroups.com](https://groups.google.com/d/msgid/golang-nuts/fd88c1ca-394f-4cb0-bbb5-55e25a2bd4ee%40googlegroups.com?utm_medium=email&utm_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/40HKfAJSjxi1C8UHNGXTd9QBGFn4-MVjEi3IN5Yy-nLPgR38QzKad4PpCJsujHmdDZnrmAZtIW3U6A02U_cEpVum7UJCNh5VtqduXq4wyoY%3D%40sbinet.org.

Re: [go-nuts] Help needed - os.exec

[Ian Lance Taylor]

On Sun, Apr 5, 2020 at 3:36 PM R Srinivasan  wrote:
>
> I cannot figure the error in the following.
> package main
>
> import (
> "io"
> "os"
> "os/exec"
> "strings"
> )
>
> func Run(args []string) {
> lf, _ := os.Create("lf.log")
> defer lf.Close()
> cmd := exec.Command(args[0], strings.Join(args[1:], " "))
> stderr, _ := cmd.StderrPipe()
> cmd.Start()
> io.Copy(lf, stderr)
> cmd.Wait()
> }
>
> func main() {
> args := []string{"go", "build", "./"}
> Run(args)
> }
>
> I can execute go build ./ and get an executable. However when I run it I get 
> the following in the logfile:
>
> cat lf.log go build ./: unknown command Run 'go help build' for usage.
>
> I exected that the "exec" will just execute go build ./
>
> I did rename the exe to something else before running it.
>
> Anyone can spot the error?

Besides other comments, always check your error returns.  Do that
before you ask for help on any program.  Thanks.

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/CAOyqgcUH%2BZKwvLJuUCB9FZNHopz_cAuAXR0%3DnbWz1reYMM0%3DUg%40mail.gmail.com.

Re: [go-nuts] Help needed - os.exec

[burak serdar]

On Sun, Apr 5, 2020 at 4:36 PM R Srinivasan  wrote:
>
> I cannot figure the error in the following.
> cmd := exec.Command(args[0], strings.Join(args[1:], " "))

Do not join the args. You're passing one arg, "build ./", instead of
two args "build" "./" to exec. Instead:

cmd := exec.Command(args[0], args[1:]...)




> stderr, _ := cmd.StderrPipe()
> cmd.Start()
> io.Copy(lf, stderr)
> cmd.Wait()
> }
>
> func main() {
> args := []string{"go", "build", "./"}
> Run(args)
> }
>
> I can execute go build ./ and get an executable. However when I run it I get 
> the following in the logfile:
>
> cat lf.log go build ./: unknown command Run 'go help build' for usage.
>
> I exected that the "exec" will just execute go build ./
>
> I did rename the exe to something else before running it.
>
> Anyone can spot the error?
>
> Thanks, srini
>
> PS - I am not sure if it matters but I am on a Mac and use go version 
> go1.13.6 darwin/amd64
>
> --
> You received this message because you are subscribed to the Google 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/a492a5a4-2fc1-4bd4-aadc-ed6ec5e45609%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/CAMV2RqrmhMrYydbcxw9M0UeidSiznKnxQ-g5Q2L0aXOTn96J6g%40mail.gmail.com.

Re: [go-nuts] help w/ therecipe/qt

[rob]

Yes, thanks Justin.  It looks that's just what I need.

--rob


On 3/1/20 3:16 PM, Justin Israel wrote:



On Mon, Mar 2, 2020 at 6:48 AM rob > wrote:


The exact problem is one of the first in chapter 4

MainWindow::MainWindow()
{
    setWindowTitle("SRM System");
    setFixedSize(500, 500);
    QPixmap newIcon("new.png");
    QPixmap openIcon("open.png");
    QPixmap closeIcon("close.png");

    // Setup File Menu
    fileMenu = menuBar()->addMenu("&File");
    quitAction = new QAction(closeIcon, "Quit", this);
    quitAction->setShortcuts(QKeySequence::Quit);
    newAction = new QAction(newIcon, "&New", this);
    newAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_C));
    openAction = new QAction(openIcon, "&New", this);
    openAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_O));
    fileMenu->addAction(newAction);
    fileMenu->addAction(openAction);
    fileMenu->addSeparator();
    fileMenu->addAction(quitAction);
    helpMenu = menuBar()->addMenu("Help");
    aboutAction = new QAction("About", this);
    aboutAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_H));
    helpMenu->addAction(aboutAction);

    // Setup Signals and Slots
    connect(quitAction, &QAction::triggered, this,
&QApplication::quit);
}


How about checking out the examples?
https://github.com/therecipe/qt/blob/master/internal/examples/widgets/textedit/textedit.go#L131 



That one shows how to use QKeySequence constants and custom keys.


Thanks

--rob solomon


On 2/29/20 2:55 PM, Rob Muhlestein wrote:
> Hi there Rob, would you mind sharing that book so I can share it
with people on my rwxrob.live stream. I like the idea of doing
what you are doing.
>
> I might be able to help you past that if I had the exact problem.
>
>
> ---
> “Mr. Rob” Muhlestein
> /^((Found|Teach|Hack)er|(Men|Jani)tor|C[A-Z]*O)$/
> r...@robs.io  • skilstak.io
 • twitch.tv/rwxrob 
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, February 29, 2020 11:48 AM, rob
mailto:drrob...@fastmail.com>> wrote:
>
>> Hi.  I'm trying to learn therecipe/qt by working my way thru a book
>> using C++ examples and translating them into Go. I'm stuck at
>> QKeySequence stuff.
>>
>> My computer runs ubuntu 18.04, and I installed Go 1.13.8 on it,
along w/
>> all the Qt development stuff from qt.io , and
therecipe/qt.
>>
>> Where are there resources for me to go thru on doing what I'm
trying?
>>
>> Thanks
>>
>>
>>


>>
>> You received this message because you are subscribed to the
Google Groups "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from
it, send an email to golang-nuts+unsubscr...@googlegroups.com
.
>> To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/7b6da064-cf87-513c-783f-379f2bfd0eed%40fastmail.com.
>

-- 
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/qvswkktCbYg/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/3d8b80e0-009b-7360-2d69-53e9c489d483%40fastmail.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/337d0990-0da9-8b34-3ac8-a8d9e3574edc%40fastmail.com.

Re: [go-nuts] help w/ therecipe/qt

[Justin Israel]

On Mon, Mar 2, 2020 at 6:48 AM rob  wrote:

> The exact problem is one of the first in chapter 4
>
> MainWindow::MainWindow()
> {
> setWindowTitle("SRM System");
> setFixedSize(500, 500);
> QPixmap newIcon("new.png");
> QPixmap openIcon("open.png");
> QPixmap closeIcon("close.png");
>
> // Setup File Menu
> fileMenu = menuBar()->addMenu("&File");
> quitAction = new QAction(closeIcon, "Quit", this);
> quitAction->setShortcuts(QKeySequence::Quit);
> newAction = new QAction(newIcon, "&New", this);
> newAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_C));
> openAction = new QAction(openIcon, "&New", this);
> openAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_O));
> fileMenu->addAction(newAction);
> fileMenu->addAction(openAction);
> fileMenu->addSeparator();
> fileMenu->addAction(quitAction);
> helpMenu = menuBar()->addMenu("Help");
> aboutAction = new QAction("About", this);
> aboutAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_H));
> helpMenu->addAction(aboutAction);
>
> // Setup Signals and Slots
> connect(quitAction, &QAction::triggered, this, &QApplication::quit);
> }
>

How about checking out the examples?
https://github.com/therecipe/qt/blob/master/internal/examples/widgets/textedit/textedit.go#L131


That one shows how to use QKeySequence constants and custom keys.


> Thanks
>
> --rob solomon
>
>
> On 2/29/20 2:55 PM, Rob Muhlestein wrote:
> > Hi there Rob, would you mind sharing that book so I can share it with
> people on my rwxrob.live stream. I like the idea of doing what you are
> doing.
> >
> > I might be able to help you past that if I had the exact problem.
> >
> >
> > ---
> > “Mr. Rob” Muhlestein
> > /^((Found|Teach|Hack)er|(Men|Jani)tor|C[A-Z]*O)$/
> > r...@robs.io • skilstak.io • twitch.tv/rwxrob
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Saturday, February 29, 2020 11:48 AM, rob 
> wrote:
> >
> >> Hi.  I'm trying to learn therecipe/qt by working my way thru a book
> >> using C++ examples and translating them into Go.  I'm stuck at
> >> QKeySequence stuff.
> >>
> >> My computer runs ubuntu 18.04, and I installed Go 1.13.8 on it, along w/
> >> all the Qt development stuff from qt.io, and therecipe/qt.
> >>
> >> Where are there resources for me to go thru on doing what I'm trying?
> >>
> >> Thanks
> >>
> >>
> >>
> 
> >>
> >> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7b6da064-cf87-513c-783f-379f2bfd0eed%40fastmail.com
> .
> >
>
> --
> 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/qvswkktCbYg/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/3d8b80e0-009b-7360-2d69-53e9c489d483%40fastmail.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/CAPGFgA0-YiaKzQ1xjHO88PmmP32Lhnmv_uDEfg9PAXcQYocdZw%40mail.gmail.com.

Re: [go-nuts] help w/ therecipe/qt

[rob]

The exact problem is one of the first in chapter 4

MainWindow::MainWindow()
{
   setWindowTitle("SRM System");
   setFixedSize(500, 500);
   QPixmap newIcon("new.png");
   QPixmap openIcon("open.png");
   QPixmap closeIcon("close.png");

   // Setup File Menu
   fileMenu = menuBar()->addMenu("&File");
   quitAction = new QAction(closeIcon, "Quit", this);
   quitAction->setShortcuts(QKeySequence::Quit);
   newAction = new QAction(newIcon, "&New", this);
   newAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_C));
   openAction = new QAction(openIcon, "&New", this);
   openAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_O));
   fileMenu->addAction(newAction);
   fileMenu->addAction(openAction);
   fileMenu->addSeparator();
   fileMenu->addAction(quitAction);
   helpMenu = menuBar()->addMenu("Help");
   aboutAction = new QAction("About", this);
   aboutAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_H));
   helpMenu->addAction(aboutAction);

   // Setup Signals and Slots
   connect(quitAction, &QAction::triggered, this, &QApplication::quit);
}

Thanks

--rob solomon


On 2/29/20 2:55 PM, Rob Muhlestein wrote:

Hi there Rob, would you mind sharing that book so I can share it with people on 
my rwxrob.live stream. I like the idea of doing what you are doing.

I might be able to help you past that if I had the exact problem.


---
“Mr. Rob” Muhlestein
/^((Found|Teach|Hack)er|(Men|Jani)tor|C[A-Z]*O)$/
r...@robs.io • skilstak.io • twitch.tv/rwxrob

‐‐‐ Original Message ‐‐‐
On Saturday, February 29, 2020 11:48 AM, rob  wrote:


Hi.  I'm trying to learn therecipe/qt by working my way thru a book
using C++ examples and translating them into Go.  I'm stuck at
QKeySequence stuff.

My computer runs ubuntu 18.04, and I installed Go 1.13.8 on it, along w/
all the Qt development stuff from qt.io, and therecipe/qt.

Where are there resources for me to go thru on doing what I'm trying?

Thanks




You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7b6da064-cf87-513c-783f-379f2bfd0eed%40fastmail.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/3d8b80e0-009b-7360-2d69-53e9c489d483%40fastmail.com.

Re: [go-nuts] help w/ therecipe/qt

[rob]

"Getting Started w/ Qt 5," by Benjamin Baka.  Published by Packtpub


On 2/29/20 2:55 PM, Rob Muhlestein wrote:

Hi there Rob, would you mind sharing that book so I can share it with people on 
my rwxrob.live stream. I like the idea of doing what you are doing.

I might be able to help you past that if I had the exact problem.


---
“Mr. Rob” Muhlestein
/^((Found|Teach|Hack)er|(Men|Jani)tor|C[A-Z]*O)$/
r...@robs.io • skilstak.io • twitch.tv/rwxrob

‐‐‐ Original Message ‐‐‐
On Saturday, February 29, 2020 11:48 AM, rob  wrote:


Hi.  I'm trying to learn therecipe/qt by working my way thru a book
using C++ examples and translating them into Go.  I'm stuck at
QKeySequence stuff.

My computer runs ubuntu 18.04, and I installed Go 1.13.8 on it, along w/
all the Qt development stuff from qt.io, and therecipe/qt.

Where are there resources for me to go thru on doing what I'm trying?

Thanks




You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7b6da064-cf87-513c-783f-379f2bfd0eed%40fastmail.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/f09d5453-50f4-164a-876e-20bb72fc5518%40fastmail.com.

Re: [go-nuts] help with using %q in fmt

['simon place' via golang-nuts]

Thanks a lot, i seem to have been a bit fixated on there already being more 
direct symmetry between print and scan.

anyway, i hacked up something that is working as i wanted;

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

(when you think about it, a recursive solution was always going to need a 
buffer.)

really i was most interested in getting a general way to make a fmt.Scanner 
work symmetrically to a fmt.Stringer when used hierarchically, so without 
messing with runes/tokens directly.


On Saturday, 22 February 2020 02:26:28 UTC, Ian Lance Taylor wrote:
>
> On Fri, Feb 21, 2020 at 4:35 PM 'simon place' via golang-nuts 
> > wrote: 
> > 
> > basically i want to save a file name in a file (with some url styling 
> for human readability); 
> > 
> > https://play.golang.org/p/sWYbyU7nuSo 
> > 
> > which works, but not with a space in the name; 
> > 
> > https://play.golang.org/p/sswqBRL8dZW 
> > 
> > it needs to be quoted, so i figure '%q' is for this; 
> > 
> > 
> >> %q a double-quoted string safely escaped with Go syntax 
> > 
> > 
> > 
> > but it doesn't work; 
> > 
> > https://play.golang.org/p/2QT-2UH4TsZ 
> > 
> > how can the format not match, when its the same one? 
> > 
> > nothing else a can think of, like quotes in the format itself, does 
> either, so i'm stuck. 
>
> In your program the type has a scan method that ignores the rune 
> parameter.  So the %q passed to fmt.Fscanf is irrelevant.  What 
> matters is the format character used in the Scan method, which is %v. 
>
> 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/8d3cab1c-8a40-44ad-9d0c-5901fb399e47%40googlegroups.com.

Re: [go-nuts] help with using %q in fmt

[Ian Lance Taylor]

On Fri, Feb 21, 2020 at 4:35 PM 'simon place' via golang-nuts
 wrote:
>
> basically i want to save a file name in a file (with some url styling for 
> human readability);
>
> https://play.golang.org/p/sWYbyU7nuSo
>
> which works, but not with a space in the name;
>
> https://play.golang.org/p/sswqBRL8dZW
>
> it needs to be quoted, so i figure '%q' is for this;
>
>
>> %q a double-quoted string safely escaped with Go syntax
>
>
>
> but it doesn't work;
>
> https://play.golang.org/p/2QT-2UH4TsZ
>
> how can the format not match, when its the same one?
>
> nothing else a can think of, like quotes in the format itself, does either, 
> so i'm stuck.

In your program the type has a scan method that ignores the rune
parameter.  So the %q passed to fmt.Fscanf is irrelevant.  What
matters is the format character used in the Scan method, which is %v.

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

Re: [go-nuts] Help with Oauth2 "grant_type=client_credentials"

[tmack8080]

This looks like what I need.

Thanks Chris.

On Tuesday, February 11, 2020 at 7:45:56 PM UTC-5, Chris Broadfoot wrote:
>
> Try this package:
> https://pkg.go.dev/golang.org/x/oauth2/clientcredentials?tab=doc
>
> On Tue, Feb 11, 2020, 4:43 PM andrey mirtchovski  > wrote:
>
>> i would strongly advise against implementing advice received online
>> for something as important as auth. my suggestion is to work with curl
>> from the command line (examples are given on the webpage you linked)
>> until you have the process working. implementing that afterwards using
>> http.Client will be more or less trivial.
>>
>> that said, you may be missing a call to SetBasicAuth with the client
>> id and secret, or sourcing a JWT beforehand from /oauth/token
>>
>> On Tue, Feb 11, 2020 at 4:56 PM tmack8080 > > wrote:
>> >
>> > Hi,
>> >
>> >
>> >
>> > I'm not a programmer.
>> >
>> > I have this working in PowerShell.
>> >
>> >
>> >
>> > Requirement:
>> >
>> > Query hardware vendor web APIs, using the device serial number, for 
>> device warranty status.
>> >
>> >
>> >
>> > The vendors require that the "client_id" and "client_secret", as well 
>> as the "grant_type=client_credentials" be passed.
>> >
>> >
>> >
>> > All of the documentation I've located discusses using Oauth for 3rd 
>> party authentication. Obviously, not what I'm doing. Can anyone point me to 
>> a tutorial that uses "client_credentials"? I've not found one.
>> >
>> >
>> >
>> > I tried using the example on the authO website; no luck: 
>> https://auth0.com/docs/api-auth/tutorials/client-credentials (you have 
>> select Go from the list of languages). When printing out the 'payload' 
>> variable I see it appended with a {0 -1} and I'm wondering if that's the 
>> problem:
>> >
>> >
>> > 
>> &{client_id=xx&client_secret=xx&grant_type=client_credentials
>>  
>> 0 -1}
>> >
>> > {
>> >
>> >   "error":"invalid_request",
>> >
>> >   "error_description":"Missing or duplicate parameters"
>> >
>> > }
>> >
>> >
>> >
>> > 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 golan...@googlegroups.com .
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/64214d0a-1191-4f46-8bfd-2c716cdb2d3f%40googlegroups.com
>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAK4xykVkQEspkzQ0D0wuZrznM4P1Mtt1KNXnobR9GZypxbUtrQ%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/faeb2e61-8d74-49f3-a393-45e9e5fe016a%40googlegroups.com.

Re: [go-nuts] Help with Oauth2 "grant_type=client_credentials"

[Chris Broadfoot]

Try this package:
https://pkg.go.dev/golang.org/x/oauth2/clientcredentials?tab=doc

On Tue, Feb 11, 2020, 4:43 PM andrey mirtchovski 
wrote:

> i would strongly advise against implementing advice received online
> for something as important as auth. my suggestion is to work with curl
> from the command line (examples are given on the webpage you linked)
> until you have the process working. implementing that afterwards using
> http.Client will be more or less trivial.
>
> that said, you may be missing a call to SetBasicAuth with the client
> id and secret, or sourcing a JWT beforehand from /oauth/token
>
> On Tue, Feb 11, 2020 at 4:56 PM tmack8080  wrote:
> >
> > Hi,
> >
> >
> >
> > I'm not a programmer.
> >
> > I have this working in PowerShell.
> >
> >
> >
> > Requirement:
> >
> > Query hardware vendor web APIs, using the device serial number, for
> device warranty status.
> >
> >
> >
> > The vendors require that the "client_id" and "client_secret", as well as
> the "grant_type=client_credentials" be passed.
> >
> >
> >
> > All of the documentation I've located discusses using Oauth for 3rd
> party authentication. Obviously, not what I'm doing. Can anyone point me to
> a tutorial that uses "client_credentials"? I've not found one.
> >
> >
> >
> > I tried using the example on the authO website; no luck:
> https://auth0.com/docs/api-auth/tutorials/client-credentials (you have
> select Go from the list of languages). When printing out the 'payload'
> variable I see it appended with a {0 -1} and I'm wondering if that's the
> problem:
> >
> >
> >
> &{client_id=xx&client_secret=xx&grant_type=client_credentials
> 0 -1}
> >
> > {
> >
> >   "error":"invalid_request",
> >
> >   "error_description":"Missing or duplicate parameters"
> >
> > }
> >
> >
> >
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/64214d0a-1191-4f46-8bfd-2c716cdb2d3f%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/CAK4xykVkQEspkzQ0D0wuZrznM4P1Mtt1KNXnobR9GZypxbUtrQ%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/CAM4ZPhBHsK8mK8g4%3Db6oE1yVD77btvoaw03ShkLyW6oV-7YE4Q%40mail.gmail.com.

Re: [go-nuts] Help with Oauth2 "grant_type=client_credentials"

[andrey mirtchovski]

i would strongly advise against implementing advice received online
for something as important as auth. my suggestion is to work with curl
from the command line (examples are given on the webpage you linked)
until you have the process working. implementing that afterwards using
http.Client will be more or less trivial.

that said, you may be missing a call to SetBasicAuth with the client
id and secret, or sourcing a JWT beforehand from /oauth/token

On Tue, Feb 11, 2020 at 4:56 PM tmack8080  wrote:
>
> Hi,
>
>
>
> I'm not a programmer.
>
> I have this working in PowerShell.
>
>
>
> Requirement:
>
> Query hardware vendor web APIs, using the device serial number, for device 
> warranty status.
>
>
>
> The vendors require that the "client_id" and "client_secret", as well as the 
> "grant_type=client_credentials" be passed.
>
>
>
> All of the documentation I've located discusses using Oauth for 3rd party 
> authentication. Obviously, not what I'm doing. Can anyone point me to a 
> tutorial that uses "client_credentials"? I've not found one.
>
>
>
> I tried using the example on the authO website; no luck: 
> https://auth0.com/docs/api-auth/tutorials/client-credentials (you have select 
> Go from the list of languages). When printing out the 'payload' variable I 
> see it appended with a {0 -1} and I'm wondering if that's the problem:
>
>
> &{client_id=xx&client_secret=xx&grant_type=client_credentials 
> 0 -1}
>
> {
>
>   "error":"invalid_request",
>
>   "error_description":"Missing or duplicate parameters"
>
> }
>
>
>
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/64214d0a-1191-4f46-8bfd-2c716cdb2d3f%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/CAK4xykVkQEspkzQ0D0wuZrznM4P1Mtt1KNXnobR9GZypxbUtrQ%40mail.gmail.com.

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

[Egon Kocjan]

On Thursday, December 12, 2019 at 3:53:07 PM UTC+1, Bryan C. Mills wrote:
>
> This is a bit off-topic now, but coincidentally we will have another talk 
>> (probably by my work colleague) that is related to one of your approaches 
>> from the talk:
>>
>> // Glob finds all items with names matching pattern
>> // and sends them on the returned channel.
>> // It closes the channel when all items have been sent.
>> func Glob(pattern string) <-chan Item { 
>>
>
>> We had a bug where due to panic+recover the channel consumer stopped 
>> reading from the channel prematurely and the producer deadlocked the entire 
>> process. I will argue that for exposed public API, sql-like defer Close / 
>> Next / Scan is safer than raw channels.
>>
>
> It seems that you didn't read/watch the whole talk, or even the whole 
> section of the talk?
> (I made exactly that point on slides 24–36. The asynchronous examples are 
> the pattern to be rethought, not the final result!
>

Yes I'm sorry, I skimmed through the slides quickly. This is the actual 
library: https://github.com/emersion/go-imap 

-- 
You received this message because you are subscribed to the Google 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/c9eb5a92-32ab-497e-9814-66251f5baa09%40googlegroups.com.

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

['Bryan C. Mills' via golang-nuts]

On Thu, Dec 12, 2019 at 1:17 AM Egon Kocjan  wrote:

> My demo is based on a real problem in our code. The issue here is that I
> cannot paste proprietary code and it's large and complex anyway. I
> distilled the problem to a bidi-communication coding exercise. The "go srv"
> in the real code is an external process with stdin and stdout with a simple
> line based protocol. Both pipes are then presented as go channels: one line
> = one channel message.
>

Part of my point (and, I think, Robert's point) is that presenting the
pipes as channels in the first place is the root of the problem.
If you avoid that mistake, then the concurrency problems down the stack
become moot.

Or, equivalently: if the concrete problem is multiplexing input from two
io.Readers, then start the presentation at the Readers — not the channels
to which they have been converted. (The channels should be an internal
implementation detail, not part of the higher-level API).

This is a bit off-topic now, but coincidentally we will have another talk
> (probably by my work colleague) that is related to one of your approaches
> from the talk:
>
> // Glob finds all items with names matching pattern
> // and sends them on the returned channel.
> // It closes the channel when all items have been sent.
> func Glob(pattern string) <-chan Item {
>

> We had a bug where due to panic+recover the channel consumer stopped
> reading from the channel prematurely and the producer deadlocked the entire
> process. I will argue that for exposed public API, sql-like defer Close /
> Next / Scan is safer than raw channels.
>

It seems that you didn't read/watch the whole talk, or even the whole
section of the talk?
(I made exactly that point on slides 24–36. The asynchronous examples are
the pattern to be rethought, not the final result!)


On Monday, December 9, 2019 at 10:54:05 PM UTC+1, Bryan C. Mills wrote:
>>
>> I agree. It seems to me that the problem in example 2 is deep in the
>> architecture of the program, not just a detail of the `select` statements.
>> The `connect` function essentially functions as a single-worker “worker
>> pool”, storing the data in a goroutine (specifically, in the closure of the
>> `srv` function). The need for the channels at all seems unmotivated, and so
>> the use of the channels seems inappropriate — I suspect that that is why
>> you aren't finding a satisfactory solution.
>>
>>
>> Stepping up a level: Egon, you say that you “want to show what not to do.”
>> That is pretty much the premise of my GopherCon 2018 talk, Rethinking
>> Classical Concurrency Patterns (
>> https://www.youtube.com/watch?v=5zXAHh5tJqQ).
>>
>> I would suggest going back to a more concrete problem and re-examining it
>> with the advice of that talk in mind.
>> (If you would like more detail on how to apply that advice, I'd be happy
>> to take a look at concrete examples — but I agree with Robert that the code
>> posted earlier is too abstract to elicit useful feedback.)
>>
>>
>> On Sunday, December 8, 2019 at 1:57:09 AM UTC-5, Robert Engels wrote:
>>>
>>> I’m sorry, but it’s very hard to understand when you start with
>>> solutions. I think maybe clearly restating the problem will allow more
>>> people to offer up ideas. To be honest at this point I’m not really certain
>>> what you’re trying to demonstrate or why.
>>>
>>> On Dec 8, 2019, at 12:44 AM, Egon Kocjan  wrote:
>>>
>>> I meant lock-free as in "without explicit locks".
>>>
>>> The original challenge still stands if someone has a better solution
>>> than me:
>>> "The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and
>>> wrong implementation of bidi-comm, which is what I'll be illustrating. I
>>> have three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is,
>>> can we remove the extra goroutine from 1_1.go and make the code nicer to
>>> read than 2_3.go and 2_4.go. The extra goroutine that I'd like to be
>>> removed is started here:
>>> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)"
>>>
>>> On Sunday, December 8, 2019 at 7:18:16 AM UTC+1, Robert Engels wrote:

 I understand what you are saying but I’ll still suggest that your
 premise/design is not correct. There are plenty of useful lock free
 structures in Go (see github.com/robaho/go-concurrency-test) but that
 is not what you are attempting here... you are using async processing -
 these are completely different things. Using async in Go is an anti-pattern
 IMO.

 On Dec 8, 2019, at 12:11 AM, Egon Kocjan  wrote:

 
 I'll cite myself:
 "I'm preparing a short talk about Go channels and select. More
 specifically, I want to show what not to do."
 and
 "it would be tempting to just combine two goroutines into one and
 handle caching in a single loop without using locks (I see developers avoid
 atomics and locks if they don't have a lot of previous experience with
 traditional MT primitives)"

 Before I say one can

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

[Egon Kocjan]

My demo is based on a real problem in our code. The issue here is that I 
cannot paste proprietary code and it's large and complex anyway. I 
distilled the problem to a bidi-communication coding exercise. The "go srv" 
in the real code is an external process with stdin and stdout with a simple 
line based protocol. Both pipes are then presented as go channels: one line 
= one channel message.

This is a bit off-topic now, but coincidentally we will have another talk 
(probably by my work colleague) that is related to one of your approaches 
from the talk:

// Glob finds all items with names matching pattern
// and sends them on the returned channel.
// It closes the channel when all items have been sent.
func Glob(pattern string) <-chan Item {

We had a bug where due to panic+recover the channel consumer stopped 
reading from the channel prematurely and the producer deadlocked the entire 
process. I will argue that for exposed public API, sql-like defer Close / 
Next / Scan is safer than raw channels.

On Monday, December 9, 2019 at 10:54:05 PM UTC+1, Bryan C. Mills wrote:
>
> I agree. It seems to me that the problem in example 2 is deep in the 
> architecture of the program, not just a detail of the `select` statements.
> The `connect` function essentially functions as a single-worker “worker 
> pool”, storing the data in a goroutine (specifically, in the closure of the 
> `srv` function). The need for the channels at all seems unmotivated, and so 
> the use of the channels seems inappropriate — I suspect that that is why 
> you aren't finding a satisfactory solution.
>
>
> Stepping up a level: Egon, you say that you “want to show what not to do.”
> That is pretty much the premise of my GopherCon 2018 talk, Rethinking 
> Classical Concurrency Patterns (
> https://www.youtube.com/watch?v=5zXAHh5tJqQ).
>
> I would suggest going back to a more concrete problem and re-examining it 
> with the advice of that talk in mind.
> (If you would like more detail on how to apply that advice, I'd be happy 
> to take a look at concrete examples — but I agree with Robert that the code 
> posted earlier is too abstract to elicit useful feedback.)
>
>
> On Sunday, December 8, 2019 at 1:57:09 AM UTC-5, Robert Engels wrote:
>>
>> I’m sorry, but it’s very hard to understand when you start with 
>> solutions. I think maybe clearly restating the problem will allow more 
>> people to offer up ideas. To be honest at this point I’m not really certain 
>> what you’re trying to demonstrate or why. 
>>
>> On Dec 8, 2019, at 12:44 AM, Egon Kocjan  wrote:
>>
>> I meant lock-free as in "without explicit locks".
>>
>> The original challenge still stands if someone has a better solution than 
>> me:
>> "The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and 
>> wrong implementation of bidi-comm, which is what I'll be illustrating. I 
>> have three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, 
>> can we remove the extra goroutine from 1_1.go and make the code nicer to 
>> read than 2_3.go and 2_4.go. The extra goroutine that I'd like to be 
>> removed is started here:
>> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)"
>>
>> On Sunday, December 8, 2019 at 7:18:16 AM UTC+1, Robert Engels wrote:
>>>
>>> I understand what you are saying but I’ll still suggest that your 
>>> premise/design is not correct. There are plenty of useful lock free 
>>> structures in Go (see github.com/robaho/go-concurrency-test) but that 
>>> is not what you are attempting here... you are using async processing - 
>>> these are completely different things. Using async in Go is an anti-pattern 
>>> IMO. 
>>>
>>> On Dec 8, 2019, at 12:11 AM, Egon Kocjan  wrote:
>>>
>>> 
>>> I'll cite myself:
>>> "I'm preparing a short talk about Go channels and select. More 
>>> specifically, I want to show what not to do."
>>> and
>>> "it would be tempting to just combine two goroutines into one and handle 
>>> caching in a single loop without using locks (I see developers avoid 
>>> atomics and locks if they don't have a lot of previous experience with 
>>> traditional MT primitives)"
>>>
>>> Before I say one can't do something in Go, I wanted to ask here to make 
>>> sure I'm not missing something obvious. Basically, I intend to show how 
>>> difficult lock-free programming can be so don't force it - just use 
>>> goroutines and locks.
>>>
>>> On Saturday, December 7, 2019 at 3:46:43 PM UTC+1, Robert Engels wrote:

 Probably not. Go is designed for 1:1 and there is no reason to do it 
 differently. You could probably try to write an async event driven layer 
 (which it looks like you’ve tried) but why???

 It’s like saying I’d really like my plane to float - you can do that 
 -but most likely you want a boat instead of a plane. 

 On Dec 7, 2019, at 2:38 AM, Egon Kocjan  wrote:

 
 I'll try to clarify as best as I can, thanks again to anyone looking at 
 this.

 The simpl

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

['Bryan C. Mills' via golang-nuts]

I agree. It seems to me that the problem in example 2 is deep in the 
architecture of the program, not just a detail of the `select` statements.
The `connect` function essentially functions as a single-worker “worker 
pool”, storing the data in a goroutine (specifically, in the closure of the 
`srv` function). The need for the channels at all seems unmotivated, and so 
the use of the channels seems inappropriate — I suspect that that is why 
you aren't finding a satisfactory solution.


Stepping up a level: Egon, you say that you “want to show what not to do.”
That is pretty much the premise of my GopherCon 2018 talk, Rethinking 
Classical Concurrency Patterns (https://www.youtube.com/watch?v=5zXAHh5tJqQ
).

I would suggest going back to a more concrete problem and re-examining it 
with the advice of that talk in mind.
(If you would like more detail on how to apply that advice, I'd be happy to 
take a look at concrete examples — but I agree with Robert that the code 
posted earlier is too abstract to elicit useful feedback.)


On Sunday, December 8, 2019 at 1:57:09 AM UTC-5, Robert Engels wrote:
>
> I’m sorry, but it’s very hard to understand when you start with solutions. 
> I think maybe clearly restating the problem will allow more people to offer 
> up ideas. To be honest at this point I’m not really certain what you’re 
> trying to demonstrate or why. 
>
> On Dec 8, 2019, at 12:44 AM, Egon Kocjan > 
> wrote:
>
> I meant lock-free as in "without explicit locks".
>
> The original challenge still stands if someone has a better solution than 
> me:
> "The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
> implementation of bidi-comm, which is what I'll be illustrating. I have 
> three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can 
> we remove the extra goroutine from 1_1.go and make the code nicer to read 
> than 2_3.go and 2_4.go. The extra goroutine that I'd like to be removed is 
> started here:
> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)"
>
> On Sunday, December 8, 2019 at 7:18:16 AM UTC+1, Robert Engels wrote:
>>
>> I understand what you are saying but I’ll still suggest that your 
>> premise/design is not correct. There are plenty of useful lock free 
>> structures in Go (see github.com/robaho/go-concurrency-test) but that is 
>> not what you are attempting here... you are using async processing - these 
>> are completely different things. Using async in Go is an anti-pattern IMO. 
>>
>> On Dec 8, 2019, at 12:11 AM, Egon Kocjan  wrote:
>>
>> 
>> I'll cite myself:
>> "I'm preparing a short talk about Go channels and select. More 
>> specifically, I want to show what not to do."
>> and
>> "it would be tempting to just combine two goroutines into one and handle 
>> caching in a single loop without using locks (I see developers avoid 
>> atomics and locks if they don't have a lot of previous experience with 
>> traditional MT primitives)"
>>
>> Before I say one can't do something in Go, I wanted to ask here to make 
>> sure I'm not missing something obvious. Basically, I intend to show how 
>> difficult lock-free programming can be so don't force it - just use 
>> goroutines and locks.
>>
>> On Saturday, December 7, 2019 at 3:46:43 PM UTC+1, Robert Engels wrote:
>>>
>>> Probably not. Go is designed for 1:1 and there is no reason to do it 
>>> differently. You could probably try to write an async event driven layer 
>>> (which it looks like you’ve tried) but why???
>>>
>>> It’s like saying I’d really like my plane to float - you can do that 
>>> -but most likely you want a boat instead of a plane. 
>>>
>>> On Dec 7, 2019, at 2:38 AM, Egon Kocjan  wrote:
>>>
>>> 
>>> I'll try to clarify as best as I can, thanks again to anyone looking at 
>>> this.
>>>
>>> The simple server implementation of "output <- input+1" is here and it 
>>> is not "under our control" - it's what we have to work with: 
>>> https://github.com/egonk/chandemo/blob/master/server.go
>>>
>>> The test runner or client is here: 
>>> https://github.com/egonk/chandemo/blob/master/demo.go (it just pushes 
>>> in ints and gets server replies back through a connection layer)
>>>
>>> The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and 
>>> wrong implementation of bidi-comm, which is what I'll be illustrating. I 
>>> have three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, 
>>> can we remove the extra goroutine from 1_1.go and make the code nicer to 
>>> read than 2_3.go and 2_4.go. The extra goroutine that I'd like to be 
>>> removed is started here:
>>> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)
>>>
>>> What I mean by removed - no go statement, replaced presumably by some 
>>> kind of for/select combination.
>>>
>>> On Saturday, December 7, 2019 at 7:02:50 AM UTC+1, robert engels wrote:

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

 i think yo

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

[Robert Engels]

I’m sorry, but it’s very hard to understand when you start with solutions. I 
think maybe clearly restating the problem will allow more people to offer up 
ideas. To be honest at this point I’m not really certain what you’re trying to 
demonstrate or why. 

> On Dec 8, 2019, at 12:44 AM, Egon Kocjan  wrote:
> 
> I meant lock-free as in "without explicit locks".
> 
> The original challenge still stands if someone has a better solution than me:
> "The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
> implementation of bidi-comm, which is what I'll be illustrating. I have three 
> working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can we remove 
> the extra goroutine from 1_1.go and make the code nicer to read than 2_3.go 
> and 2_4.go. The extra goroutine that I'd like to be removed is started here:
> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)"
> 
>> On Sunday, December 8, 2019 at 7:18:16 AM UTC+1, Robert Engels wrote:
>> I understand what you are saying but I’ll still suggest that your 
>> premise/design is not correct. There are plenty of useful lock free 
>> structures in Go (see github.com/robaho/go-concurrency-test) but that is not 
>> what you are attempting here... you are using async processing - these are 
>> completely different things. Using async in Go is an anti-pattern IMO. 
>> 
>>> On Dec 8, 2019, at 12:11 AM, Egon Kocjan  wrote:
>>> 
>>> 
>>> I'll cite myself:
>>> "I'm preparing a short talk about Go channels and select. More 
>>> specifically, I want to show what not to do."
>>> and
>>> "it would be tempting to just combine two goroutines into one and handle 
>>> caching in a single loop without using locks (I see developers avoid 
>>> atomics and locks if they don't have a lot of previous experience with 
>>> traditional MT primitives)"
>>> 
>>> Before I say one can't do something in Go, I wanted to ask here to make 
>>> sure I'm not missing something obvious. Basically, I intend to show how 
>>> difficult lock-free programming can be so don't force it - just use 
>>> goroutines and locks.
>>> 
 On Saturday, December 7, 2019 at 3:46:43 PM UTC+1, Robert Engels wrote:
 Probably not. Go is designed for 1:1 and there is no reason to do it 
 differently. You could probably try to write an async event driven layer 
 (which it looks like you’ve tried) but why???
 
 It’s like saying I’d really like my plane to float - you can do that -but 
 most likely you want a boat instead of a plane. 
 
> On Dec 7, 2019, at 2:38 AM, Egon Kocjan  wrote:
> 
> 
> I'll try to clarify as best as I can, thanks again to anyone looking at 
> this.
> 
> The simple server implementation of "output <- input+1" is here and it is 
> not "under our control" - it's what we have to work with: 
> https://github.com/egonk/chandemo/blob/master/server.go
> 
> The test runner or client is here: 
> https://github.com/egonk/chandemo/blob/master/demo.go (it just pushes in 
> ints and gets server replies back through a connection layer)
> 
> The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
> implementation of bidi-comm, which is what I'll be illustrating. I have 
> three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can 
> we remove the extra goroutine from 1_1.go and make the code nicer to read 
> than 2_3.go and 2_4.go. The extra goroutine that I'd like to be removed 
> is started here:
> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)
> 
> What I mean by removed - no go statement, replaced presumably by some 
> kind of for/select combination.
> 
>> On Saturday, December 7, 2019 at 7:02:50 AM UTC+1, robert engels wrote:
>> I’m sorry but your design is not comprehendible by me, and I’ve done 
>> lots of TCP based services. 
>> 
>> i think you only need to emulate classic TCP processing - a reader 
>> thread (Go routine) on each side of the connection using range to read 
>> until closed. The connection is represented by 2 channels - one for each 
>> direction.
>> 
>> I think you might be encountering a deadlock because the producer on one 
>> end is not also reading the incoming - so either restructure, or use 2 
>> more threads for the producers.
>> 
>> 
>> 
>>> On Dec 6, 2019, at 10:38 PM, Egon Kocjan  wrote:
>>> 
>>> Agreed, I see goroutines in general as a big win. But what I intend to 
>>> talk about in the presentation:
>>> - we have two unidirectional flows of data resembling something like a 
>>> TCP socket, easy to do with two goroutines with a for loop
>>> - let's add caching, so some requests do not go to the server
>>> - it would be tempting to just combine two goroutines into one and 
>>> handle caching in a single loop without using locks (I see developers 
>>> avoid ato

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

[Egon Kocjan]

I meant lock-free as in "without explicit locks".

The original challenge still stands if someone has a better solution than 
me:
"The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
implementation of bidi-comm, which is what I'll be illustrating. I have 
three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can 
we remove the extra goroutine from 1_1.go and make the code nicer to read 
than 2_3.go and 2_4.go. The extra goroutine that I'd like to be removed is 
started here:
https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)"

On Sunday, December 8, 2019 at 7:18:16 AM UTC+1, Robert Engels wrote:
>
> I understand what you are saying but I’ll still suggest that your 
> premise/design is not correct. There are plenty of useful lock free 
> structures in Go (see github.com/robaho/go-concurrency-test) but that is 
> not what you are attempting here... you are using async processing - these 
> are completely different things. Using async in Go is an anti-pattern IMO. 
>
> On Dec 8, 2019, at 12:11 AM, Egon Kocjan > 
> wrote:
>
> 
> I'll cite myself:
> "I'm preparing a short talk about Go channels and select. More 
> specifically, I want to show what not to do."
> and
> "it would be tempting to just combine two goroutines into one and handle 
> caching in a single loop without using locks (I see developers avoid 
> atomics and locks if they don't have a lot of previous experience with 
> traditional MT primitives)"
>
> Before I say one can't do something in Go, I wanted to ask here to make 
> sure I'm not missing something obvious. Basically, I intend to show how 
> difficult lock-free programming can be so don't force it - just use 
> goroutines and locks.
>
> On Saturday, December 7, 2019 at 3:46:43 PM UTC+1, Robert Engels wrote:
>>
>> Probably not. Go is designed for 1:1 and there is no reason to do it 
>> differently. You could probably try to write an async event driven layer 
>> (which it looks like you’ve tried) but why???
>>
>> It’s like saying I’d really like my plane to float - you can do that -but 
>> most likely you want a boat instead of a plane. 
>>
>> On Dec 7, 2019, at 2:38 AM, Egon Kocjan  wrote:
>>
>> 
>> I'll try to clarify as best as I can, thanks again to anyone looking at 
>> this.
>>
>> The simple server implementation of "output <- input+1" is here and it is 
>> not "under our control" - it's what we have to work with: 
>> https://github.com/egonk/chandemo/blob/master/server.go
>>
>> The test runner or client is here: 
>> https://github.com/egonk/chandemo/blob/master/demo.go (it just pushes in 
>> ints and gets server replies back through a connection layer)
>>
>> The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
>> implementation of bidi-comm, which is what I'll be illustrating. I have 
>> three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can 
>> we remove the extra goroutine from 1_1.go and make the code nicer to read 
>> than 2_3.go and 2_4.go. The extra goroutine that I'd like to be removed is 
>> started here:
>> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)
>>
>> What I mean by removed - no go statement, replaced presumably by some 
>> kind of for/select combination.
>>
>> On Saturday, December 7, 2019 at 7:02:50 AM UTC+1, robert engels wrote:
>>>
>>> I’m sorry but your design is not comprehendible by me, and I’ve done 
>>> lots of TCP based services. 
>>>
>>> i think you only need to emulate classic TCP processing - a reader 
>>> thread (Go routine) on each side of the connection using range to read 
>>> until closed. The connection is represented by 2 channels - one for each 
>>> direction.
>>>
>>> I think you might be encountering a deadlock because the producer on one 
>>> end is not also reading the incoming - so either restructure, or use 2 more 
>>> threads for the producers.
>>>
>>>
>>>
>>> On Dec 6, 2019, at 10:38 PM, Egon Kocjan  wrote:
>>>
>>> Agreed, I see goroutines in general as a big win. But what I intend to 
>>> talk about in the presentation:
>>> - we have two unidirectional flows of data resembling something like a 
>>> TCP socket, easy to do with two goroutines with a for loop
>>> - let's add caching, so some requests do not go to the server
>>> - it would be tempting to just combine two goroutines into one and 
>>> handle caching in a single loop without using locks (I see developers avoid 
>>> atomics and locks if they don't have a lot of previous experience with 
>>> traditional MT primitives)
>>> - this is surprisingly difficult to do properly with Go channels, see my 
>>> attempts: https://github.com/egonk/chandemo/blob/master/2_3.go and 
>>> https://github.com/egonk/chandemo/blob/master/2_4.go 
>>> 
>>> - it is easy to do in actor systems, just move the code for both actors 
>>> into a single actor!
>>>
>>> The lesson here is that select is not a nice and safe compose statement 
>>> ev

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

[Robert Engels]

I understand what you are saying but I’ll still suggest that your 
premise/design is not correct. There are plenty of useful lock free structures 
in Go (see github.com/robaho/go-concurrency-test) but that is not what you are 
attempting here... you are using async processing - these are completely 
different things. Using async in Go is an anti-pattern IMO. 

> On Dec 8, 2019, at 12:11 AM, Egon Kocjan  wrote:
> 
> 
> I'll cite myself:
> "I'm preparing a short talk about Go channels and select. More specifically, 
> I want to show what not to do."
> and
> "it would be tempting to just combine two goroutines into one and handle 
> caching in a single loop without using locks (I see developers avoid atomics 
> and locks if they don't have a lot of previous experience with traditional MT 
> primitives)"
> 
> Before I say one can't do something in Go, I wanted to ask here to make sure 
> I'm not missing something obvious. Basically, I intend to show how difficult 
> lock-free programming can be so don't force it - just use goroutines and 
> locks.
> 
>> On Saturday, December 7, 2019 at 3:46:43 PM UTC+1, Robert Engels wrote:
>> Probably not. Go is designed for 1:1 and there is no reason to do it 
>> differently. You could probably try to write an async event driven layer 
>> (which it looks like you’ve tried) but why???
>> 
>> It’s like saying I’d really like my plane to float - you can do that -but 
>> most likely you want a boat instead of a plane. 
>> 
 On Dec 7, 2019, at 2:38 AM, Egon Kocjan  wrote:
 
>>> 
>>> I'll try to clarify as best as I can, thanks again to anyone looking at 
>>> this.
>>> 
>>> The simple server implementation of "output <- input+1" is here and it is 
>>> not "under our control" - it's what we have to work with: 
>>> https://github.com/egonk/chandemo/blob/master/server.go
>>> 
>>> The test runner or client is here: 
>>> https://github.com/egonk/chandemo/blob/master/demo.go (it just pushes in 
>>> ints and gets server replies back through a connection layer)
>>> 
>>> The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
>>> implementation of bidi-comm, which is what I'll be illustrating. I have 
>>> three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can 
>>> we remove the extra goroutine from 1_1.go and make the code nicer to read 
>>> than 2_3.go and 2_4.go. The extra goroutine that I'd like to be removed is 
>>> started here:
>>> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)
>>> 
>>> What I mean by removed - no go statement, replaced presumably by some kind 
>>> of for/select combination.
>>> 
 On Saturday, December 7, 2019 at 7:02:50 AM UTC+1, robert engels wrote:
 I’m sorry but your design is not comprehendible by me, and I’ve done lots 
 of TCP based services. 
 
 i think you only need to emulate classic TCP processing - a reader thread 
 (Go routine) on each side of the connection using range to read until 
 closed. The connection is represented by 2 channels - one for each 
 direction.
 
 I think you might be encountering a deadlock because the producer on one 
 end is not also reading the incoming - so either restructure, or use 2 
 more threads for the producers.
 
 
 
> On Dec 6, 2019, at 10:38 PM, Egon Kocjan  wrote:
> 
> Agreed, I see goroutines in general as a big win. But what I intend to 
> talk about in the presentation:
> - we have two unidirectional flows of data resembling something like a 
> TCP socket, easy to do with two goroutines with a for loop
> - let's add caching, so some requests do not go to the server
> - it would be tempting to just combine two goroutines into one and handle 
> caching in a single loop without using locks (I see developers avoid 
> atomics and locks if they don't have a lot of previous experience with 
> traditional MT primitives)
> - this is surprisingly difficult to do properly with Go channels, see my 
> attempts: https://github.com/egonk/chandemo/blob/master/2_3.go and 
> https://github.com/egonk/chandemo/blob/master/2_4.go
> - it is easy to do in actor systems, just move the code for both actors 
> into a single actor!
> 
> The lesson here is that select is not a nice and safe compose statement 
> even if it appears so at the first glance, do not be afraid to use locks.
> 
> Of course, if somebody comes up with a better implementation than 2_3.go 
> and 2_4.go, I would be very happy to include it in the talk.
> 
>> On Saturday, December 7, 2019 at 4:17:04 AM UTC+1, robert engels wrote:
>> To clarify, with Go’s very lightweight threads it is “doing the 
>> multiplexing for you” - often only a single CPU is consumed if the 
>> producer and consumer work cannot be parallelized, otherwise you get 
>> this concurrency “for free”.
>> 
>> You are trying to manually perform the multiplexing - y

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

[Egon Kocjan]

I'll cite myself:
"I'm preparing a short talk about Go channels and select. More 
specifically, I want to show what not to do."
and
"it would be tempting to just combine two goroutines into one and handle 
caching in a single loop without using locks (I see developers avoid 
atomics and locks if they don't have a lot of previous experience with 
traditional MT primitives)"

Before I say one can't do something in Go, I wanted to ask here to make 
sure I'm not missing something obvious. Basically, I intend to show how 
difficult lock-free programming can be so don't force it - just use 
goroutines and locks.

On Saturday, December 7, 2019 at 3:46:43 PM UTC+1, Robert Engels wrote:
>
> Probably not. Go is designed for 1:1 and there is no reason to do it 
> differently. You could probably try to write an async event driven layer 
> (which it looks like you’ve tried) but why???
>
> It’s like saying I’d really like my plane to float - you can do that -but 
> most likely you want a boat instead of a plane. 
>
> On Dec 7, 2019, at 2:38 AM, Egon Kocjan > 
> wrote:
>
> 
> I'll try to clarify as best as I can, thanks again to anyone looking at 
> this.
>
> The simple server implementation of "output <- input+1" is here and it is 
> not "under our control" - it's what we have to work with: 
> https://github.com/egonk/chandemo/blob/master/server.go
>
> The test runner or client is here: 
> https://github.com/egonk/chandemo/blob/master/demo.go (it just pushes in 
> ints and gets server replies back through a connection layer)
>
> The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
> implementation of bidi-comm, which is what I'll be illustrating. I have 
> three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can 
> we remove the extra goroutine from 1_1.go and make the code nicer to read 
> than 2_3.go and 2_4.go. The extra goroutine that I'd like to be removed is 
> started here:
> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)
>
> What I mean by removed - no go statement, replaced presumably by some kind 
> of for/select combination.
>
> On Saturday, December 7, 2019 at 7:02:50 AM UTC+1, robert engels wrote:
>>
>> I’m sorry but your design is not comprehendible by me, and I’ve done lots 
>> of TCP based services. 
>>
>> i think you only need to emulate classic TCP processing - a reader thread 
>> (Go routine) on each side of the connection using range to read until 
>> closed. The connection is represented by 2 channels - one for each 
>> direction.
>>
>> I think you might be encountering a deadlock because the producer on one 
>> end is not also reading the incoming - so either restructure, or use 2 more 
>> threads for the producers.
>>
>>
>>
>> On Dec 6, 2019, at 10:38 PM, Egon Kocjan  wrote:
>>
>> Agreed, I see goroutines in general as a big win. But what I intend to 
>> talk about in the presentation:
>> - we have two unidirectional flows of data resembling something like a 
>> TCP socket, easy to do with two goroutines with a for loop
>> - let's add caching, so some requests do not go to the server
>> - it would be tempting to just combine two goroutines into one and handle 
>> caching in a single loop without using locks (I see developers avoid 
>> atomics and locks if they don't have a lot of previous experience with 
>> traditional MT primitives)
>> - this is surprisingly difficult to do properly with Go channels, see my 
>> attempts: https://github.com/egonk/chandemo/blob/master/2_3.go and 
>> https://github.com/egonk/chandemo/blob/master/2_4.go 
>> 
>> - it is easy to do in actor systems, just move the code for both actors 
>> into a single actor!
>>
>> The lesson here is that select is not a nice and safe compose statement 
>> even if it appears so at the first glance, do not be afraid to use locks.
>>
>> Of course, if somebody comes up with a better implementation than 2_3.go 
>> and 2_4.go, I would be very happy to include it in the talk.
>>
>> On Saturday, December 7, 2019 at 4:17:04 AM UTC+1, robert engels wrote:
>>>
>>> To clarify, with Go’s very lightweight threads it is “doing the 
>>> multiplexing for you” - often only a single CPU is consumed if the producer 
>>> and consumer work cannot be parallelized, otherwise you get this 
>>> concurrency “for free”.
>>>
>>> You are trying to manually perform the multiplexing - you need async 
>>> structures to do this well - Go doesn’t really support async by design - 
>>> and it’s a much simpler programming model as a result.
>>>
>>> On Dec 6, 2019, at 12:02 PM, Robert Engels  wrote:
>>>
>>> A channel is much closer to a pipe. There are producers and consumers 
>>> and these are typically different threads of execution unless you have an 
>>> event based (async) system - that is not Go. 
>>>
>>> On Dec 6, 2019, at 9:30 AM, Egon Kocjan  wrote:
>>>
>>> 
>>> There are goroutines in the examples of course, just a single goroutine 
>>> per bidi chan

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

[Robert Engels]

Probably not. Go is designed for 1:1 and there is no reason to do it 
differently. You could probably try to write an async event driven layer (which 
it looks like you’ve tried) but why???

It’s like saying I’d really like my plane to float - you can do that -but most 
likely you want a boat instead of a plane. 

> On Dec 7, 2019, at 2:38 AM, Egon Kocjan  wrote:
> 
> 
> I'll try to clarify as best as I can, thanks again to anyone looking at this.
> 
> The simple server implementation of "output <- input+1" is here and it is not 
> "under our control" - it's what we have to work with: 
> https://github.com/egonk/chandemo/blob/master/server.go
> 
> The test runner or client is here: 
> https://github.com/egonk/chandemo/blob/master/demo.go (it just pushes in ints 
> and gets server replies back through a connection layer)
> 
> The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
> implementation of bidi-comm, which is what I'll be illustrating. I have three 
> working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can we remove 
> the extra goroutine from 1_1.go and make the code nicer to read than 2_3.go 
> and 2_4.go. The extra goroutine that I'd like to be removed is started here:
> https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)
> 
> What I mean by removed - no go statement, replaced presumably by some kind of 
> for/select combination.
> 
>> On Saturday, December 7, 2019 at 7:02:50 AM UTC+1, robert engels wrote:
>> I’m sorry but your design is not comprehendible by me, and I’ve done lots of 
>> TCP based services. 
>> 
>> i think you only need to emulate classic TCP processing - a reader thread 
>> (Go routine) on each side of the connection using range to read until 
>> closed. The connection is represented by 2 channels - one for each direction.
>> 
>> I think you might be encountering a deadlock because the producer on one end 
>> is not also reading the incoming - so either restructure, or use 2 more 
>> threads for the producers.
>> 
>> 
>> 
>>> On Dec 6, 2019, at 10:38 PM, Egon Kocjan  wrote:
>>> 
>>> Agreed, I see goroutines in general as a big win. But what I intend to talk 
>>> about in the presentation:
>>> - we have two unidirectional flows of data resembling something like a TCP 
>>> socket, easy to do with two goroutines with a for loop
>>> - let's add caching, so some requests do not go to the server
>>> - it would be tempting to just combine two goroutines into one and handle 
>>> caching in a single loop without using locks (I see developers avoid 
>>> atomics and locks if they don't have a lot of previous experience with 
>>> traditional MT primitives)
>>> - this is surprisingly difficult to do properly with Go channels, see my 
>>> attempts: https://github.com/egonk/chandemo/blob/master/2_3.go and 
>>> https://github.com/egonk/chandemo/blob/master/2_4.go
>>> - it is easy to do in actor systems, just move the code for both actors 
>>> into a single actor!
>>> 
>>> The lesson here is that select is not a nice and safe compose statement 
>>> even if it appears so at the first glance, do not be afraid to use locks.
>>> 
>>> Of course, if somebody comes up with a better implementation than 2_3.go 
>>> and 2_4.go, I would be very happy to include it in the talk.
>>> 
 On Saturday, December 7, 2019 at 4:17:04 AM UTC+1, robert engels wrote:
 To clarify, with Go’s very lightweight threads it is “doing the 
 multiplexing for you” - often only a single CPU is consumed if the 
 producer and consumer work cannot be parallelized, otherwise you get this 
 concurrency “for free”.
 
 You are trying to manually perform the multiplexing - you need async 
 structures to do this well - Go doesn’t really support async by design - 
 and it’s a much simpler programming model as a result.
 
> On Dec 6, 2019, at 12:02 PM, Robert Engels  wrote:
> 
> A channel is much closer to a pipe. There are producers and consumers and 
> these are typically different threads of execution unless you have an 
> event based (async) system - that is not Go. 
> 
>> On Dec 6, 2019, at 9:30 AM, Egon Kocjan  wrote:
>> 
>> 
>> There are goroutines in the examples of course, just a single goroutine 
>> per bidi channel seems hard. By contrast, I've worked with actor systems 
>> before and they are perfectly fine with a single fiber.
>> 
>>> On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>>> Channels are designed to be used with multiple go routines - if you’re 
>>> not you are doing something wrong. 
>>> 
> On Dec 6, 2019, at 8:32 AM, Egon Kocjan  wrote:
> 
 
 Hello
 
 I'm preparing a short talk about Go channels and select. More 
 specifically, I want to show what not to do. I chose a bidirectional 
 communication channel implementation, because it seems to be a common 
 base for a 

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

[Egon Kocjan]

I'll try to clarify as best as I can, thanks again to anyone looking at 
this.

The simple server implementation of "output <- input+1" is here and it is 
not "under our control" - it's what we have to work with: 
https://github.com/egonk/chandemo/blob/master/server.go

The test runner or client is here: 
https://github.com/egonk/chandemo/blob/master/demo.go (it just pushes in 
ints and gets server replies back through a connection layer)

The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong 
implementation of bidi-comm, which is what I'll be illustrating. I have 
three working solutions - 1_1.go, 2_3.go, 2_4.go. So the question is, can 
we remove the extra goroutine from 1_1.go and make the code nicer to read 
than 2_3.go and 2_4.go. The extra goroutine that I'd like to be removed is 
started here:
https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)

What I mean by removed - no go statement, replaced presumably by some kind 
of for/select combination.

On Saturday, December 7, 2019 at 7:02:50 AM UTC+1, robert engels wrote:
>
> I’m sorry but your design is not comprehendible by me, and I’ve done lots 
> of TCP based services. 
>
> i think you only need to emulate classic TCP processing - a reader thread 
> (Go routine) on each side of the connection using range to read until 
> closed. The connection is represented by 2 channels - one for each 
> direction.
>
> I think you might be encountering a deadlock because the producer on one 
> end is not also reading the incoming - so either restructure, or use 2 more 
> threads for the producers.
>
>
>
> On Dec 6, 2019, at 10:38 PM, Egon Kocjan > 
> wrote:
>
> Agreed, I see goroutines in general as a big win. But what I intend to 
> talk about in the presentation:
> - we have two unidirectional flows of data resembling something like a TCP 
> socket, easy to do with two goroutines with a for loop
> - let's add caching, so some requests do not go to the server
> - it would be tempting to just combine two goroutines into one and handle 
> caching in a single loop without using locks (I see developers avoid 
> atomics and locks if they don't have a lot of previous experience with 
> traditional MT primitives)
> - this is surprisingly difficult to do properly with Go channels, see my 
> attempts: https://github.com/egonk/chandemo/blob/master/2_3.go and 
> https://github.com/egonk/chandemo/blob/master/2_4.go 
> 
> - it is easy to do in actor systems, just move the code for both actors 
> into a single actor!
>
> The lesson here is that select is not a nice and safe compose statement 
> even if it appears so at the first glance, do not be afraid to use locks.
>
> Of course, if somebody comes up with a better implementation than 2_3.go 
> and 2_4.go, I would be very happy to include it in the talk.
>
> On Saturday, December 7, 2019 at 4:17:04 AM UTC+1, robert engels wrote:
>>
>> To clarify, with Go’s very lightweight threads it is “doing the 
>> multiplexing for you” - often only a single CPU is consumed if the producer 
>> and consumer work cannot be parallelized, otherwise you get this 
>> concurrency “for free”.
>>
>> You are trying to manually perform the multiplexing - you need async 
>> structures to do this well - Go doesn’t really support async by design - 
>> and it’s a much simpler programming model as a result.
>>
>> On Dec 6, 2019, at 12:02 PM, Robert Engels  wrote:
>>
>> A channel is much closer to a pipe. There are producers and consumers and 
>> these are typically different threads of execution unless you have an event 
>> based (async) system - that is not Go. 
>>
>> On Dec 6, 2019, at 9:30 AM, Egon Kocjan  wrote:
>>
>> 
>> There are goroutines in the examples of course, just a single goroutine 
>> per bidi channel seems hard. By contrast, I've worked with actor systems 
>> before and they are perfectly fine with a single fiber.
>>
>> On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>>>
>>> Channels are designed to be used with multiple go routines - if you’re 
>>> not you are doing something wrong. 
>>>
>>> On Dec 6, 2019, at 8:32 AM, Egon Kocjan  wrote:
>>>
>>> 
>>> Hello
>>>
>>> I'm preparing a short talk about Go channels and select. More 
>>> specifically, I want to show what not to do. I chose a bidirectional 
>>> communication channel implementation, because it seems to be a common base 
>>> for a lot of problems but hard to implement correctly without using any 
>>> extra goroutines. All the code is here: 
>>> https://github.com/egonk/chandemo
>>>
>>> 1_1.go: easy with en extra goroutine (takes 1.2s for million ints)
>>> 2_1.go: nice but completely wrong
>>> 2_2.go: better but still deadlocks
>>> 2_3.go: correct but ugly and slow (takes more than 2s for million ints)
>>> 2_4.go: correct and a bit faster but still ugly (1.8s for million ints)
>>>
>>> So my question: is there a better way of doing it with just nested for 
>>> and select

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

[robert engels]

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

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

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



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

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

[Jason E. Aten]

@Egon, 

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a540a6bd-1f41-4f86-8e1f-4b5ac8288814%40googlegroups.com.

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

[Egon Kocjan]

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

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/75d69b4e-4fb7-4f62-8011-f21e2a4c294a%40googlegroups.com.

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

[robert engels]

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

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F798CDF8-8108-437F-A435-7C8B882BFA96%40ix.netcom.com.

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

[Robert Engels]

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9F3C3A18-9A8D-44A6-881F-729FB364FBED%40ix.netcom.com.

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

[Egon Kocjan]

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bdc57eb0-b26f-4364-87fb-241b0807e8ae%40googlegroups.com.

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

[Robert Engels]

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BD2088DD-59DA-4AA4-AE34-C8E81A79982A%40ix.netcom.com.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[George Hartzell]

George Hartzell writes:
 > 
 > Quick summary, I'm trying to understand the Go structures that cgo
 > gives me, how they map back onto the C structures and why a Go struct
 > that doesn't quite match the cgo output seems to work anyway.
 > [...]

Ian gave me a lot of good things to chew on, but didn't answer the
main question about why the different versions of the `i2c_msg` struct
definition all seem to work.

For those of you who've been sitting on the edges of your seats
awaiting the answer...

It turns out that my assumption, that the `buf` pointer's alignment
requirements end up inserting padding automagically, seems to be true.

I convinced myself of this using the `structlayout` tools from
https://github.com/dominikh/go-tools.

Starting with this input file:

```go
package main

// #include 
import "C"

// This is what `cgo -godefs` generates
type ViaGoDefs struct {
addr  uint16
flags uint16
len   uint16
buf   *uint8
}

// This is what @tetsu-koba used
type FromTetsu struct {
addr  uint16
flags uint16
len   uint16
__padding uint16
buf   uintptr
}

// This is the result of using cgo as Ian suggested
type ViaCGo C.struct_i2c_msg
```

you can see that all of the structs have the same shape:

```
pi@raspberrypi:~/temper/go/structures $ structlayout -json structures ViaGoDefs 
| structlayout-pretty
++
  0 || <- ViaGoDefs.addr uint16 (size 2, align 2)
++
  2 || <- ViaGoDefs.flags uint16 (size 2, align 2)
++
  4 || <- ViaGoDefs.len uint16 (size 2, align 2)
++
  6 || <- padding (size 2, align 0)
++
  8 || <- ViaGoDefs.buf *uint8 (size 4, align 4)
++
--
++
 11 ||
++
pi@raspberrypi:~/temper/go/structures $ structlayout -json structures FromTetsu 
| structlayout-pretty
++
  0 || <- FromTetsu.addr uint16 (size 2, align 2)
++
  2 || <- FromTetsu.flags uint16 (size 2, align 2)
++
  4 || <- FromTetsu.len uint16 (size 2, align 2)
++
  6 || <- FromTetsu.__padding uint16 (size 2, align 2)
++
  8 || <- FromTetsu.buf uintptr (size 4, align 4)
++
--
++
 11 ||
++
pi@raspberrypi:~/temper/go/structures $ structlayout -json structures ViaCGo | 
structlayout-pretty
++
  0 || <- ViaCGo.addr structures._Ctype_ushort (size 2, align 2)
++
  2 || <- ViaCGo.flags structures._Ctype_ushort (size 2, align 2)
++
  4 || <- ViaCGo.len structures._Ctype_ushort (size 2, align 2)
++
  6 || <- padding (size 2, align 0)
++
  8 || <- ViaCGo.buf *structures._Ctype_uchar (size 4, align 4)
++
--
++
 11 ||
++
pi@raspberrypi:~/temper/go/structures $
```

Phew.

g.

-- 
You received this message because you are subscribed to the Google 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/23914.46306.691997.964218%40alice.local.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[George Hartzell]

Ian Lance Taylor writes:
 > [...]
 > OK, that is true.  Since your program will be using cgo, even though
 > you aren't calling any C functions, it will be dynamically linked by
 > default.  You could try using "go build -ldflags=-extldflags=-static".
 > I don't know whether it will work.
 > 

To close the loop on this, using 

```
go build -ldflags=-extldflags=-static
```

does work, at least for the simple demo we've been discussing.

Onward!

Thanks again,

g.

-- 
You received this message because you are subscribed to the Google 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/23914.43161.264587.614979%40alice.local.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[George Hartzell]

George Hartzell writes:
 > [...]
 > ```
 > i2c/i2c.go:15:9: cannot use &buf[0] (type *byte) as type *_Ctype_uchar
 > in assignment
 > ```
 > 
 > I can't come up with any cast that makes the compiler happy.  I'm also
 > unsure whether that line runs afoul of this commandment: *Go code may
 > not store a Go pointer in C memory* from https://golang.org/cmd/cgo/.
 > 

Hmmm.  Well this works, and building/running with GODEBUG=cgocheck=2
doesn't complain, so perhaps it's ok?

```
[...]
buf := [2]C.__u8{}

im.addr = 0x18
im.flags = C.I2C_M_RD
im.len = C.__u16(len(buf))
im.buf = &buf[0]
[...]
```

g.

-- 
You received this message because you are subscribed to the Google 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/23913.48871.513272.764573%40alice.local.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[Ian Lance Taylor]

On Fri, Aug 30, 2019 at 4:57 PM George Hartzell  wrote:
>
> Ian Lance Taylor writes:
>  > On Thu, Aug 29, 2019 at 6:26 PM George Hartzell  
> wrote:
>  > [...]
>  > There is another approach, which is to use import "C", and then write code 
> like
>  >
>  > const IoctlConstant = C.IoctlConstant
>  > type GoIoctlType = C.CIoctlType
>  >
>  > and then use those types in code that calls unix.Syscall(SYS_IOCTL,
>  > IoctlConstant, &GoIoctlType{value}).
>
> Hi Ian,
>
> Thank you for the followup^2.
>
> After re-reading all of the things that you'd pointed me at, I'd
> started heading down that road a bit, but am stuck on one thing and
> have a question.
>
> # Where I'm currently stuck
>
> Here's something that compiles and runs:
>
> ```
> package i2c
>
> // #include 
> // #include 
> import "C"
> import "fmt"
>
> func Foo() {
>   im := C.struct_i2c_msg{}
>   buf := [2]byte{}
>
>   im.addr = 0x18
>   im.flags = C.I2C_M_RD
>   im.len = C.__u16(len(buf))
>   // im.buf = &buf[0]
>   fmt.Println(im)
> }
> 
>
> The original C structure is defined like so (w/ comments, #defines elided):
>
> ```
> struct i2c_msg {
>   __u16 addr; /* slave address  */
>   __u16 flags;
>   __u16 len;/* msg length   */
>   __u8 *buf;/* pointer to msg data  */
> };
> ```
>
> The other approaches that I cribbed supplied the buffer by declaring a
> byte slice and taking the address of the first element. If I uncomment
> line 15 in the above, I get
>
> ```
> i2c/i2c.go:15:9: cannot use &buf[0] (type *byte) as type *_Ctype_uchar
> in assignment
> ```
>
> I can't come up with any cast that makes the compiler happy.

im.buf = (*C.uchar)(unsafe.Pointer(&buf[0]))


> I'm also
> unsure whether that line runs afoul of this commandment: *Go code may
> not store a Go pointer in C memory* from https://golang.org/cmd/cgo/.

There is no C memory here as yet.  That code will be OK if you pass
&im to unix.Syscall.  But it will not be OK if you pass &im to
C.ioctl, as that would violate this rule from
https://golang.org/cmd/cgo: "Go code may pass a Go pointer to C
provided the Go memory to which it points does not contain any Go
pointers."  In this case the Go pointer &im would contain the Go
pointer &buf[0].  But that rule applies to calling cgo functions; it
does not apply to calling unix.Syscall.


> Perhaps I should be allocating that memory myself with a call to
> `C.malloc` or ???

That would also work, and be safe.


> # The question
>
> If I leave out the buf bit and build it, I end with a dynamically
> linked executable, e.g.
>
> ```
> pi@raspberrypi:~/temper/go/cgo-normal-way $ ldd dummy
> linux-vdso.so.1 (0x7ef23000)
> /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => 
> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76f14000)
> libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 
> (0x76ed3000)
> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76d85000)
> /lib/ld-linux-armhf.so.3 (0x76f29000)
> ```
>
> While this is an personal homework problem, I'm also heading towards
> building an application and one of the advantages of using Go is the
> statically compiled binary.  After your initial comment, I'd thought
> perhaps I'd just end up using some cgo magic for the types and structs
> but I'd still end up with a static binary.  That doesn't seem to be
> the case.

OK, that is true.  Since your program will be using cgo, even though
you aren't calling any C functions, it will be dynamically linked by
default.  You could try using "go build -ldflags=-extldflags=-static".
I don't know whether it will work.


> If I go back mimicking the approach used in the x/sys libraries (cgo
> -godefs), what particular "private" behavior am I depending on?  Is it
> the ability to use `cgo -godefs` to figure out a Go equivalent for the
> C data structures, or is it counting on the
> ``uintptr(unsafe.Pointer(...))` to do the right thing, or something
> else?

It is "cgo -godefs".  That is not supported for any use other than
generating the files used by the syscall and runtime packages.  It may
work for you today but there is no guarantee that it will continue to
work.

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

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[George Hartzell]

Ian Lance Taylor writes:
 > On Thu, Aug 29, 2019 at 6:26 PM George Hartzell  wrote:
 > [...]
 > There is another approach, which is to use import "C", and then write code 
 > like
 > 
 > const IoctlConstant = C.IoctlConstant
 > type GoIoctlType = C.CIoctlType
 > 
 > and then use those types in code that calls unix.Syscall(SYS_IOCTL,
 > IoctlConstant, &GoIoctlType{value}).

Hi Ian,

Thank you for the followup^2.

After re-reading all of the things that you'd pointed me at, I'd
started heading down that road a bit, but am stuck on one thing and
have a question.

# Where I'm currently stuck

Here's something that compiles and runs:

```
package i2c

// #include 
// #include 
import "C"
import "fmt"

func Foo() {
  im := C.struct_i2c_msg{}
  buf := [2]byte{}

  im.addr = 0x18
  im.flags = C.I2C_M_RD
  im.len = C.__u16(len(buf))
  // im.buf = &buf[0]
  fmt.Println(im)
}


The original C structure is defined like so (w/ comments, #defines elided):

```
struct i2c_msg {
  __u16 addr; /* slave address  */
  __u16 flags;
  __u16 len;/* msg length   */
  __u8 *buf;/* pointer to msg data  */
};
```

The other approaches that I cribbed supplied the buffer by declaring a
byte slice and taking the address of the first element. If I uncomment
line 15 in the above, I get

```
i2c/i2c.go:15:9: cannot use &buf[0] (type *byte) as type *_Ctype_uchar
in assignment
```

I can't come up with any cast that makes the compiler happy.  I'm also
unsure whether that line runs afoul of this commandment: *Go code may
not store a Go pointer in C memory* from https://golang.org/cmd/cgo/.

Perhaps I should be allocating that memory myself with a call to
`C.malloc` or ???

# The question

If I leave out the buf bit and build it, I end with a dynamically
linked executable, e.g.

```
pi@raspberrypi:~/temper/go/cgo-normal-way $ ldd dummy
linux-vdso.so.1 (0x7ef23000)
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => 
/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76f14000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76ed3000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76d85000)
/lib/ld-linux-armhf.so.3 (0x76f29000)
```

While this is an personal homework problem, I'm also heading towards
building an application and one of the advantages of using Go is the
statically compiled binary.  After your initial comment, I'd thought
perhaps I'd just end up using some cgo magic for the types and structs
but I'd still end up with a static binary.  That doesn't seem to be
the case.

If I go back mimicking the approach used in the x/sys libraries (cgo
-godefs), what particular "private" behavior am I depending on?  Is it
the ability to use `cgo -godefs` to figure out a Go equivalent for the
C data structures, or is it counting on the
``uintptr(unsafe.Pointer(...))` to do the right thing, or something
else?

Thanks again (you've plowed through lots of words...),

g.

-- 
You received this message because you are subscribed to the Google 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/23913.47082.559595.453308%40alice.local.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[Ian Lance Taylor]

On Thu, Aug 29, 2019 at 6:26 PM George Hartzell  wrote:
>
> I suppose I *could* write a cgo library that would wrap the C-based
> [i2c-tools] library, but I wanted to do it directly in Go, without
> adding the [i2c-tools] dependency.
>
> Or, are you saying that I should create a package that does the
> `import "C"` and `import "unsafe"` and then somehow uses "C.Ioctl" (or
> something, I haven't dug very far into this line of thought yet...) to
> make the call into the kernel.  I can see how every time such a thing
> was built it would use that Go version's latest/greatest understanding
> of how to map the Go and C structures, whereas the approach I'm
> copying is static and might become out of date.  But, in that case,
> why do the things in golang.org/x/sys exist (though they're probably
> built for each release and are therefor up-to-date by def'n)?

There is another approach, which is to use import "C", and then write code like

const IoctlConstant = C.IoctlConstant
type GoIoctlType = C.CIoctlType

and then use those types in code that calls unix.Syscall(SYS_IOCTL,
IoctlConstant, &GoIoctlType{value}).

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/CAOyqgcWmKCpXd%2BfmG68116UYvZ4OG8nb-8sQvEXhXiqukbcbJw%40mail.gmail.com.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[George Hartzell]

Ian Lance Taylor writes:
 > On Thu, Aug 29, 2019 at 5:15 PM George Hartzell  wrote:
 > >
 > > Quick summary, I'm trying to understand the Go structures that cgo
 > > gives me, how they map back onto the C structures and why a Go struct
 > > that doesn't quite match the cgo output seems to work anyway.
 > >
 > > I've called out two explicit questions down below.
 > >
 > > ---
 > >
 > > The Linux kernel provides a character device interface to I2C devices,
 > > and the [i2c-tools] package provides a C library with "convenient"
 > > access functions.
 > >
 > > I'm working on a Go library for the kernel interface on a Raspberry
 > > Pi, because I need it for a project *and* as an etude [so please,
 > > don't do too much of my "homework" for me...;)]
 > >
 > > [...]
 > 
 > This is not a helpful answer but I want to say that using "cgo
 > -godefs" in this way is not supported.  You're welcome to use it but
 > it may well break in the future.  The "-godefs" option is specifically
 > for generating files used in the syscall and golang.org/x/sys
 > packages, it's not intended for general use.  We instead recommend
 > using import "C" and using cgo in the usual way as described at
 > https://golang.org/cmd/cgo/ and https://blog.golang.org/c-go-cgo .

@iant, thanks for the quick response.  Everything's part of the
lesson, so it's useful.

Andrew's [c-go-cgo] article talks about an interface to a C library,
while I'm trying to wrap a set of IOCTL calls into the kernel w/out
requiring supporting C code.

I suppose I *could* write a cgo library that would wrap the C-based
[i2c-tools] library, but I wanted to do it directly in Go, without
adding the [i2c-tools] dependency.

Or, are you saying that I should create a package that does the
`import "C"` and `import "unsafe"` and then somehow uses "C.Ioctl" (or
something, I haven't dug very far into this line of thought yet...) to
make the call into the kernel.  I can see how every time such a thing
was built it would use that Go version's latest/greatest understanding
of how to map the Go and C structures, whereas the approach I'm
copying is static and might become out of date.  But, in that case,
why do the things in golang.org/x/sys exist (though they're probably
built for each release and are therefor up-to-date by def'n)?

I thought that what I was doing here was essentially extending the set
of syscalls (the C library in [i2c-tools] is "just" a set of wrappers
around the IOCTL's associated with the Linux i2c character device
interface), so the `cgo -godefs` usage was appropriate.

While starting out on this, I found a series of discussions about
adding various IOCTL calls to the golang.org/x/sys packages and
pushback limiting what actually went in there.  I thought that at a
minimum additions needed to prove themselves "stand-alone" before
making it into those packages.

Thanks again for the time and thoughts,

g.

[c-go-cgo]: https://blog.golang.org/c-go-cgo
[i2c-tools]: https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/

-- 
You received this message because you are subscribed to the Google 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/23912.31528.829329.295650%40alice.local.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[Ian Lance Taylor]

On Thu, Aug 29, 2019 at 5:15 PM George Hartzell  wrote:
>
> Quick summary, I'm trying to understand the Go structures that cgo
> gives me, how they map back onto the C structures and why a Go struct
> that doesn't quite match the cgo output seems to work anyway.
>
> I've called out two explicit questions down below.
>
> ---
>
> The Linux kernel provides a character device interface to I2C devices,
> and the [i2c-tools] package provides a C library with "convenient"
> access functions.
>
> I'm working on a Go library for the kernel interface on a Raspberry
> Pi, because I need it for a project *and* as an etude [so please,
> don't do too much of my "homework" for me...;)]
>
> While digging around for prior art, I found a [partial implementation
> by tetsu-koba][tetsu-koba].  Starting from that, I have working bits
> to talk to devices via the I2C versions of the commands.
>
> My next step was to implement the [i2c-tools] SMBus functions.  That
> requires Go versions of the two C structures that they use.  A bit of
> research into creating the mapping led to using `cgo -godefs`.  Along
> the way, I stumbled on a [partial implementation of the SMBus
> bits][brandonagr-smbus] by brandon...@gmail.com.
>
> I ended up with this cgo input file:
>
> ```go
> package main
>
> /*
> #include 
> #include 
> #include 
> */
> import "C"
>
> type I2CMsg C.struct_i2c_msg
>
> const Sizeof_I2CMsg = C.sizeof_struct_i2c_msg
>
> type I2CSMBusIoctlData C.struct_i2c_smbus_ioctl_data
>
> const Sizeof_I2CSMBusIoctlData = C.sizeof_struct_i2c_smbus_ioctl_data
>
> type Blort C.struct_blort
>
> type I2CSMBusData C.union_i2c_smbus_data
>
> const Sizeof_I2CSMBusData = C.sizeof_union_i2c_smbus_data
> ```
>
> It generates this output:
>
> ```go
> // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> // cgo -godefs foo.go
>
> package main
>
> type I2CMsg struct {
> Addruint16
> Flags   uint16
> Len uint16
> Buf *uint8
> }
>
> const Sizeof_I2CMsg = 0xc
>
> type I2CSMBusIoctlData struct {
> Write   uint8
> Command uint8
> Sizeuint32
> Data*[34]byte
> }
>
> const Sizeof_I2CSMBusIoctlData = 0xc
>
> type Blort struct{}
>
> type I2CSMBusData [34]byte
>
> const Sizeof_I2CSMBusData = 0x22
> ```
>
> @brandonagr ended up with something that's different for his version
> of the i2c_smbus_ioctl_data struct:
>
> ```go
> type i2c_smbus_ioctl_data struct {
> read_write uint8
> commanduint8
> size   int
> data   *uint8
> }
> ```
>
> but I can see how it's the same "shape".
>
> ## Question #1
>
> On the *other hand, @tetsu-koba's version of the i2c_msg struct:
>
> ```go
> type i2c_msg struct {
> addr  uint16
> flags uint16
> len   uint16
> __padding uint16
> buf   uintptr
> }
> ```
>
> seems to be fundamentally different from the `cgo -godefs` version:
>
> ```go
> type I2CMsg struct {
> Addruint16
> Flags   uint16
> Len uint16
> Buf *uint8
> }
> ```
>
> Before I figured out how to use `cgo -godefs`, I rationalized
> @tetsu-koba's struct with the explanation that the `buf` pointer was
> being padded out to a 32-bit boundary and was comforted by the fact
> that it seems to work (I can use it to talk to e.g. an MCP9808
> temperature sensor).
>
> But, the `cgo -godefs` output seems to be a different shape, I don't
> see how the Buf field ends up in the right place.  I haven't tried
> *using* it yet, I'd like to understand the why before I comfort myself
> with a "seems to work, onward...".  Left to my own devices I thought
> about trying to get at the assembly language output for the various
> structs and seeing what was going on, but that seemed to be One Yak
> Too Far.
>
> Can anyone explain [or a big big clue] what's going on?  Is one right
> and the other wrong?  Are both somehow correct?
>
> ## Question #2
>
> While I'm on this topic, I notice that `cgo -godefs` converted the
> struct/field names to Go camel case versions (and stripped the "read_"
> prefix from one).  But, both @tetsu-koba and @brandonagr stuck with
> the C struct names.  I've noticed that various go libaries that refer
> to kernel data structures (e.g. constants/#defines) don't rename them
> in Go style.
>
> What is the accepted practice in this situation?


This is not a helpful answer but I want to say that using "cgo
-godefs" in this way is not supported.  You're welcome to use it but
it may well break in the future.  The "-godefs" option is specifically
for generating files used in the syscall and golang.org/x/sys
packages, it's not intended for general use.  We instead recommend
using import "C" and using cgo in the usual way as described at
https://golang.org/cmd/cgo/ and https://blog.golang.org/c-go-cgo .

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 

Re: [go-nuts] [help] trying to use gccgo but missing something

[Ian Lance Taylor]

On Mon, Jun 3, 2019 at 1:59 PM anthony Place  wrote:
>
> there is a 100 or so containing gccgo; '.go','.a','.c', batch and '.html' but 
> no executable (other than the batch files)
>
> i was previously hopeful about one called 'gccgo_install.html', but it was 
> about compilation and then assumed the executable existed.
>
> it seems something was not set to make to 'executable'? there isn't any 
> reference to it in the package listing.
>
> my interest was not major.
>
> i had originally thought to use go in a container, and compile stuff, but 
> solus had good support for all i needed, so i didn't bother.
>
> many thanks for the help.

Most likely your distro has a different package that contains the
gccgo executable, and you'll need to install that one separately.

For example, if you are using Debian, you would have to install the
gccgo package as well as the gcc package.

Ian

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

Re: [go-nuts] [help] trying to use gccgo but missing something

[anthony Place]

there is a 100 or so containing gccgo; '.go','.a','.c', batch and '.html' 
but no executable (other than the batch files)

i was previously hopeful about one called 'gccgo_install.html', but it was 
about compilation and then assumed the executable existed.

it seems something was not set to make to 'executable'? there isn't any 
reference to it in the package listing.

my interest was not major.

i had originally thought to use go in a container, and compile stuff, but 
solus had good support for all i needed, so i didn't bother.

many thanks for the help.





-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/16faad5a-290c-4705-818e-2ac425ead666%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [help] trying to use gccgo but missing something

[Ian Lance Taylor]

On Mon, Jun 3, 2019 at 12:54 PM anthony Place  wrote:
>
> > What does "which gccgo" print?
>
> which: no gccgo in (/sbin:/bin:/usr/sbin:/usr/bin:/snap/bin)
>
> i was wondering if i had to add something to the path, or that it wasn't 
> being packaged, but..
>
> * gcc doc says go supported.

Yes, Go is supported, but that doesn't mean that installing your
distro's gcc package installed gccgo.

> * if i search the fs for gccgo i get all sorts of hits.

Is one of those an executable named "gccgo"?

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/CAOyqgcUCbPVM5QnVJb6dkQMb427GtY0gOVQHJSGM0vL7jtQs9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [help] trying to use gccgo but missing something

[anthony Place]

> What does "which gccgo" print? 

which: no gccgo in (/sbin:/bin:/usr/sbin:/usr/bin:/snap/bin)

i was wondering if i had to add something to the path, or that it wasn't 
being packaged, but..

* gcc doc says go supported.
* if i search the fs for gccgo i get all sorts of hits.





-- 
You received this message because you are subscribed to the Google 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/b564ac63-8b0c-42e9-9b0e-85428a5641f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [help] trying to use gccgo but missing something

[Ian Lance Taylor]

On Mon, Jun 3, 2019 at 8:48 AM anthony Place  wrote:
>
> i hoped adding -compiler gccgo to go build would just work but...
>
> > gccgo: exec: "gccgo": executable file not found in $PATH
>
> i have gcc (8.3) repo. package (solus 5) installed and the docs with it say 
> it supports go, and there doesn't seem to be anything else about gccgo in the 
> repo. so not really sure where to even look next.

What does "which gccgo" print?  If it doesn't print anything then
either you don't have gccgo installed or it's not on your PATH.  Note
that many distros package gccgo separately from the main gcc package.

Ian

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

Re: [go-nuts] Help - Mongodb JSON access

[Burak Serdar]

On Tue, Feb 19, 2019 at 9:09 AM  wrote:
>
> Hi,
>
> I have a json data  in mongodb in the format be bellow, i need help to access 
> the data using
> the  "nfinstanceID" which is a uuid string ID part of an api request for 
> example example
>
> "http://localhost:5050/nnrf-nfm/v1/nf-instances/3fa85f64-5717-4562-b3fc-2c963f66afaa";
>
> The api route is of the form 
> "".../nnrf-nfm/v1/nf-instances/{nfinstanceID}"
>
> instead of using "bson.ObjectId". My struct is in the format
>
>
> type NfInstance struct {
> ID bson.ObjectId `bson:"_id" json:"id"`
> ValidityPeriod int   `json:"validityPeriod" bson:"validityPeriod"`
> NfInstanceID   string`json:"nfinstanceID" bson:"nfinstanceID"`
> SNssais[]Snssai  `json:"sNssais" bson:"sNssais"`
> NfServices []Service `json:"nfServices" bson:"nfServices"`
>   ...
> }
>
> type Service struct {
> ServiceInstanceID string`json:"serviceInstanceId" 
> bson:"serviceInstanceId"`
> Versions  []Version `json:"versions" bson:"versions"`
> }
>
> type Version struct {
> APIVersionInURI string`json:"apiVersionInUri" bson:"apiVersionInUri"`
> ...
> }
>
> type Snssai struct {
> Sst int32 `json:"sst"`
> .
> }
>
> // Fuctions are
>
> // Find a instance by its id
> func (m *NfInstanceDataAccess) FindById(id string) (NfInstance, error) {
> var nfinstance NfInstance
> err := db.C(COLLECTION).FindId(bson.ObjectIdHex(id)).One(&nfinstance)
> return nfinstance, err
>
> }
>
> // Handler function
> func NfInstancebyIdGet(w http.ResponseWriter, r *http.Request) {
>
> vars := mux.Vars(r)
> id := vars["nfinstanceID"]
>
> nfinstance, err := da.FindById(id)
> if err != nil {
> respondWithError(w, http.StatusBadRequest, "Invalid nfinstance ID")
> return
> }
>
> respondWithJson(w, http.StatusOK, nfinstance)
> }
>
> Using this functions work but i would like to access the data not using  
> bson.ObjectId but rather "nfinstanceID" part.
> Completely new to golang.


Your question is not about golang, but about how to use mongodb. I
suggest you read the mongodb driver docs.

You have to search the database using the correct field, not the object id:

db.C(COLLECTION).Find(bson.M{"nfInstanceID":instanceId})


> Thanks in advance!!
>
> Abraham
>
>
> {
> "id": "5c6c238dfdde24520f7b1b69",
> "validityPeriod": 1,
> "nfinstanceID": "3fa85f64-5717-4562-b3fc-2c963f66afaa",
> "heartBeatTimer": 0,
> "nfType": "string",
> "nfStatus": [
> "REGISTERED"
> ],
> "sNssais": [
> {
> "sst": 0,
> "sd": "string"
> }
> ],
> "nsiList": [
> "string"
> ],
> "nfServices": [
> {
> "serviceInstanceId": "string",
> "versions": [
> {
> "apiVersionInUri": "http://{apiRoot}/v1/xxx";,
> "apiFullVersion": "string",
> "expiry": "2019-02-03T14:08:56.65+02:00"
> }
> ]
> }
> ]
> }
>
> --
> You received this message because you are subscribed to the Google 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] Help- Empty request header and body

[afriyie . abraham]

Hi,

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

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

Thanks in advance



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

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

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

[Lutz Horn]

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


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


Lutz


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

Re: [go-nuts] help- i cant run program

[Ian Lance Taylor]

On Thu, Jan 17, 2019 at 5:41 PM  wrote:
>
> hay
> Help, while I'm running and getting this error
>
>
> cannot find package "fmt" in any of: C:\Go\bin\src\fmt (from $GOROOT) 
> C:\Users\HP\go\src\fmt (from $GOPATH) package . imports runtime: cannot find 
> package "runtime" in any of: C:\Go\bin\src\runtime (from $GOROOT) 
> C:\Users\HP\go\src\runtime (from $GOPATH)
>
> I think it has to do with the definition of an "environment variable"
> I'd be happy to get help with this

Something is wrong with your Go installation.  Exactly how did you
install Go?  Is GOROOT set in your environment (it shouldn't be)?

Ian

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

Re: [go-nuts] help(rest call failed)

[Justin Israel]

On Tue, Nov 13, 2018, 5:23 AM  wrote:

> I just want to send a rest call with golang, but it failed, the error
> message :  {"header":{"code":201,"desc":"param data not exist"}} .(but
> when I send rest request with postman ,it success)
> the code as follow
>
> 1 package main
>   2
>   3 import(
>   4 "net/http"
>   5 "fmt"
>   6 "strings"
>   7 "io/ioutil"
>   8 )
>   9 func check(err error){
>  10 if err !=nil{
>  11 panic(err)
>  12 }
>  13 }
>  14 func main(){
>  15 url:="http://ip:8080/api";
>  16 method:="POST"
>  17 da:="base64 encoded string"
>  18 data:=strings.NewReader(da)
>

This isn't an encoded form. And your server is complaining that it can't
find a "data" form field. Use url.Values to encode a form:
https://golang.org/pkg/net/url/#Values.Encode

var vals url.Values
vals.Add("data", "form data")
data:=strings.NewReader(vals.Encode())

 19 req,err:=http.NewRequest(method,url,data)
>  20 check(err)
>  21
>  req.Header.Set("Content_Type","application/x-www-form-urlencoded")
>


Should be "Content-Type"

 22 client:=&http.Client{}
>  23 resp,err:=client.Do(req)
>  24 check(err)
>  25 defer resp.Body.Close()
>  26 result,err:=ioutil.ReadAll(resp.Body)
>  27 check(err)
>  28 fmt.Println(string(result[:]))
>  29 }
>
> --
> You received this message because you are subscribed to the Google 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] Help with bytes/writing to aws

['Borman, Paul' via golang-nuts]

It is not possible to tell from your code if that is the correct data or not.  
You code did not display the data it was sending (that might be illuminating).  
Are you sure that when you are reading the file you are displaying what was 
actually there?

Also, why are you specifying:

ContentLength: aws.Int64(int64(len(fileData))),
ContentType:   aws.String(http.DetectContentType([]byte(fileData))),

The ContentLength should be automatically determined if not set.  Do you know 
what ContentType is being set to?

I have code that looks like:

// var data []byte
// var bucket, name string
_, err := awss3.PutObject(&s3.PutObjectInput{
Body:   bytes.NewReader(data),
Bucket: &bucket,
Key:&name,
})

Which seems to write to S3 what I want.  To read the data I use:

obj, err := awss3.GetObject(&s3.GetObjectInput{
Bucket: &bucket,
Key:&name,
})
if err != nil {
return nil, err
}
return ioutil.ReadAll(obj.Body)

Those have appeared to work for me.

-Paul

On Sep 17, 2018, at 6:48 PM, agruet...@gmail.com 
wrote:

OK, I know I am doing something dumb and have a case of the Monday's. If anyone 
is able to point out my stupid it would be much appreciated.

Output when opening the file in S3:

       
       
       
       
       
7465 7374 2e65 6273 5f66 6163 745f 6773
742d 7161 6c2e 6170 705f 696e 6672 6173
7472 7563 7475 7265 5f70 6572 662e 6562
735f 6661 6374 5f67 7374 2d71 616c 2d61
7070 2e69 6e64 6976 6964 7561 6c5f 6e6f
6465 732e 7071 616c 6773 7461 736b 3031
636f 7270 696e 7475 6974 6e65 742e 6861
7264 7761 7265 5f72 6573 6f75 7263 6573
2e6e 6574 776f 726b 2e69 6e63 6f6d 696e
675f 6b62 2f73 6563 2035 2031 3533 3732
3237 3036 3020 0a00    
       
       
       
       

Code:

func (controller *controllerDetails) sendMetricBatch() error {
var err error
println("HERE89")
if controller.sendBuf.buffer.Len() > 0 {
println("HERE99")
//Create a UUID filename
fileName, err := uuid.NewV4()
if err != nil {
panic(err)
}

//FIX ME UNHARD CODE BUCKET
//controller.sendBuf.mux.Lock()
//defer controller.sendBuf.mux.Unlock()
//FIXME this byte read is lost if the upload fails
_, err = awss3.PutFileBytes(controller.s3Client, "appdoimbuckettest", 
fileName.String(), controller.sendBuf.buffer.Bytes())
if err != nil {
println("FML123")
panic(err)
}
}
return err
}

func PutFileBytes(s3Client *s3.S3, s3Bucket, copyTo string, fileData []byte) 
(*s3.PutObjectOutput, error) {
var err error

putInput := &s3.PutObjectInput{
Body: bytes.NewReader(fileData),
Bucket: aws.String(s3Bucket),
Key: aws.String(copyTo),
ContentLength: aws.Int64(int64(len(fileData))),
ContentType: aws.String(http.DetectContentType([]byte(fileData))),
}

results, err := s3Client.PutObject(putInput)
if err != nil {
return nil, err
}

return results, err
}

--
You received this message because you are subscribed to the Google 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] Help

[andybons via golang-nuts]

On Wednesday, September 5, 2018 at 2:01:20 PM UTC-4, Matthias B. wrote:
>
> On Wed, 5 Sep 2018 19:14:43 +0530 
> Kathiresh Kumar > wrote: 
>
> > How can I connect golang with mongoDB 
> > 
>
> http://lmgtfy.com/?q=How+can+I+connect+golang+with+mongoDB%3F%3F%3F%3F 
>

This is not a particularly helpful response. Please be sure to adhere to 
the values described at https://golang.org/conduct#values

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

Re: [go-nuts] Help

[Kathiresh Kumar]

Thank you friends.

On Sep 5, 2018 11:31 PM, "Matthias B."  wrote:

> On Wed, 5 Sep 2018 19:14:43 +0530
> Kathiresh Kumar  wrote:
>
> > How can I connect golang with mongoDB
> >
>
> http://lmgtfy.com/?q=How+can+I+connect+golang+with+mongoDB%3F%3F%3F%3F
>
> --
> You received this message because you are subscribed to the Google 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] Help

[Matthias B.]

On Wed, 5 Sep 2018 19:14:43 +0530
Kathiresh Kumar  wrote:

> How can I connect golang with mongoDB
> 

http://lmgtfy.com/?q=How+can+I+connect+golang+with+mongoDB%3F%3F%3F%3F

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

Re: [go-nuts] help seek: creating and using go package

[Sam Whited]

On Tue, Sep 4, 2018, at 01:33, Sayan Shankhari wrote:
> Probably I am making some nonsense post here and disturbing you but as a 
> beginner, I want to know how in Go I can implement the following. If I can 
> not, please suggest me suitable solution:

Not at all; welcome! If you're just getting started with Go, I recommend that 
you take the tour (https://tour.golang.org). This probably covers most of what 
you want.


> 1. Create a package "myNum"

This is a good resource for getting started with creating Go packages: 
https://golang.org/doc/code.html

It's a tiny bit out of date, there are some experimental features in Go 1.11 
that make using GOPATH obsolete, but it will still work for now.

> 2. containing data type like:
> type Num struct {
> n, d int // numerator, denominator
> }
> 3. and a function to print like
> func printMyNum(x Num) {
> fmt.Println("the fractional number is: %d/%d", x.n, x.d)
> }

Looks like you've already done this, good job :)



In Go, the case of the first letter of an identifier determines if it's 
exported or not.
In your code "Num" will be exported (it can be used from another package), but 
its fields are not (so you won't be able to set "n" or "d" from another 
package). Similarly, "printMyNum" will not be exported, so you won't be able to 
call it from another package.

Here is a more detailed explanation: 
https://stackoverflow.com/questions/38616687/which-way-to-name-a-function-in-go-camelcase-or-semi-camelcase/38617771#38617771

And here is a nice post about how to name things: 
https://blog.golang.org/package-names


I hope that's helpful. Welcome to Go!

—Sam

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

Re: [go-nuts] help with using crc32.Update for BE data.

[Dan Kortschak]

No, I don't think that works.

Dan

On Wed, 2018-08-22 at 12:04 +0200, Jan Mercl wrote:
> On Wed, Aug 22, 2018 at 7:23 AM Dan Kortschak  .edu.au>
> wrote:
> 
> > 
> > https://stackoverflow.com/questions/51960305/convert-crc32-sum-from
> > -
> lsb-first-algorithm-to-sum-for-msb-first-algorithm
>  lsb-first-algorithm-to-sum-for-msb-first-algorithm>
> 
> From the above it seems like one can use the algorithm for the other
> endianness directly and the just bit-reverse the resulting value...?
> 

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

Re: [go-nuts] help with using crc32.Update for BE data.

[Jan Mercl]

On Wed, Aug 22, 2018 at 7:23 AM Dan Kortschak 
wrote:

> https://stackoverflow.com/questions/51960305/convert-crc32-sum-from-
lsb-first-algorithm-to-sum-for-msb-first-algorithm


>From the above it seems like one can use the algorithm for the other
endianness directly and the just bit-reverse the resulting value...?

-- 

-j

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

Re: [go-nuts] help with using crc32.Update for BE data.

[Dan Kortschak]

Question cross-posted to SO because crickets scare me.

https://stackoverflow.com/questions/51960305/convert-crc32-sum-from-
lsb-first-algorithm-to-sum-for-msb-first-algorithm

On Sun, 2018-08-19 at 09:27 +0930, Dan Kortschak wrote:
> I am working on an MPEG-TS-using package at the moment and need to
> calculate CRC32 remainders for the packets I'm constructing. I can do
> this with a big-endian CRC32 update function (here https://play.golan
> g.
> org/p/nKnRHlhTkNT), but am struggling to figure out how to transform
> the inputs to use the crc32.Update function. The polynomial I'm using
> the normal form of the IEEE polynomial. I have read the linked WP
> article from the godoc, but it's not clear to me how I should use
> that
> information (though intuitively it feel like I need to reverse the
> bit
> order of the input data, which seem unreasonable).
> 
> thanks
> Dan
> 

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