Re: [go-nuts] Nillable basic types?

2024-03-18 Thread 'Brian Candler' via golang-nuts
I like Go because it's relatively simple and low-level, like C, except with 
things like garbage collection and channels integrated.  If Go were to have 
"| nil" types then the internal representation of such variables would have 
to be something like this:

type Maybe[T any] struct {
Value T
IsSet bool
}

In which case, why not just use that form explicitly? The code you write is 
then clear and obvious. Taking one of your examples:

func foo3(x Maybe[int]) {
  if x.IsSet {
fmt.Println("x squared is", x.Value*x.Value)
  } else {
fmt.Println("No value for x")
  }
}

// https://go.dev/play/p/ci10fhU1zqL

I also think that you need to find multiple compelling use cases (of which 
that example is not one), before fundamentally adding complexity to the 
language. Remember that "nil" is already overloaded in Go, so adding 
another (similar but different) meaning increases complexity for the reader.

Full union types are a different thing again, and I can see the attraction 
of those - except at that point, the language is no longer Go. Having 
"int32 | int64" as a union type, but also as a generic type constraint, 
would also be somewhat mind-boggling. How would you write a type constraint 
that allows a union type?

On Monday 18 March 2024 at 07:01:25 UTC Jan Mercl wrote:

> On Mon, Mar 18, 2024 at 4:41 AM Daniel Lepage  wrote:
>
> > This change would be entirely backward-compatible ...
>
> Let's consider, for example, the type uint8, aka byte. A variable of
> type byte is specified* to occupy 8 bits of memory and has 256
> possible values. To represent all those values and the new possibility
> of the value being nil, we need 257 distinct values. But that does not
> fit 8 in bits anymore. However, changing the size and/or the bit
> representation of such a variable is observable, making it not
> backwards-compatible.
>
> 
> *: From https://go.dev/ref/spec#Numeric_types:
>
> 
> The value of an n-bit integer is n bits wide and represented using
> two's complement arithmetic.
> 
>

-- 
You received this message because you are subscribed to the Google 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/a1e89e97-e879-4bc8-9110-50b8432767bdn%40googlegroups.com.


Re: [go-nuts] How To Reduce Json Marshalling Time

2024-03-09 Thread 'Brian Candler' via golang-nuts
Perhaps it would be helpful to give some concrete figures for the 
real-world application.

"the response time of Go API is higher than PHP" - how much? Are we 
talking, say, 1.2ms versus 1ms? Or 10ms versus 1ms? Is this testing between 
a client and server adjacent on the same LAN, or is the server running is a 
cloud somewhere?

"the response contains around 30k keys" - what's the total size of the 
response? Are the values for each key all simple strings?

Then, it would be useful to have small PHP and Go programs which reproduce 
the issue as seen, with data of this size.  You should prepare static data 
structures ready to be encoded for the response, so that you're only 
measuring the encoding and response time.

Then you could try pre-encoding the entire response to a JSON string, and 
return that string as the response, to eliminate the JSON encoding overhead.

Finally, it would be worth looking at the response using tcpdump or 
wireshark just to see if anything odd is happening, e.g. there is chunked 
encoding with lots of tiny chunks.

On Saturday 9 March 2024 at 05:31:32 UTC Mike Schinkel wrote:

> On Saturday, March 9, 2024 at 12:16:51 AM UTC-5 Robert Engels wrote:
>
> My guess is that most applications are decoding 25gb json files with any 
> regularity. Even transferring 25 GB over the fastest of networks takes 20 
> secs? So that reduces the cost to less than 10%???
>
>
> How about rather than guessing, you let the OP consider the input you gave 
> in your first reply — which I acknowledged was likely the issue in my first 
> reply — and then move on?
>
> This is either a troll post or by someone that needs more education in 
> performance monitoring. Sorry. 
>
>
> Everything beyond your first reply on this thread — except when you 
> replied to my ask for clarification — was unnecessary as you had already 
> made your only point.
>
> If there was trolling here, your reply to my first reply on the thread was 
> the start of that trolling.
>
> -Mike
>
> P.S. The types of replies you've made on this thread is why I always ask 
> myself if it worth the pain to answer someone's questions. Rest assured I 
> will think twice next time before going to the effort.
>

-- 
You received this message because you are subscribed to the Google 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/579ea671-0140-4817-a7e9-8b995bbf9418n%40googlegroups.com.


[go-nuts] Re: How to add labels to Go runtime prometheus metrics?

2024-03-06 Thread 'Brian Candler' via golang-nuts
The server name will be added by Prometheus itself as an "instance" label 
for each target being scraped (or you can manually set the instance label 
for each target), so in general what you're asking is not necessary.  None 
of the standard Prometheus exporters include a label for the hostname (e.g. 
node_exporter, windows_exporter etc).

If there's something special about your situation which means you need to 
do this, can you explain your use case further?

On Wednesday 6 March 2024 at 10:40:29 UTC cpu...@gmail.com wrote:

> The Go runtime exposes various metrics. To collect metrics from multiple 
> servers I'd like to add labels for server name. Is it possible to extend 
> the build-in metrics for this purpose?
>
> Thanks,
> Andi
>

-- 
You received this message because you are subscribed to the Google 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/fba0add8-7b74-4546-99b0-70a22230647en%40googlegroups.com.


Re: [go-nuts] Enums, Go1 and proposals

2024-03-04 Thread 'Brian Candler' via golang-nuts
On Monday 4 March 2024 at 15:18:05 UTC Jeremy French wrote:

What I find valuable is to be able to accept an enum as a parameter to a 
function, and know that it will be one of several approved values (e.g. 
month of the year)


ISTM all that's needed is to have a way to create a named type which cannot 
be assigned from the values of the underlying type, except inside a const 
declaration.

Does this represent the problem statement?
https://go.dev/play/p/kLME_dJE9a5

-- 
You received this message because you are subscribed to the Google 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/480133d3-9795-4e2d-878d-1750c9b6c806n%40googlegroups.com.


Re: [go-nuts] Equality of interface of an empty struct - why?

2024-02-27 Thread 'Brian Candler' via golang-nuts
> let's consider the two possible definitions:
>
> 1. Pointers to distinct zero-size variables are equal: [...]
> 2. Pointers to distinct zero-size variables are not equal:

Another possibility:

3. Equality comparisons between pointers to zero-size variables are 
forbidden at compile time.
3a. If you wrap two such values in interfaces and try to compare them, then 
you get a runtime panic, same as certain cases today 
.

Indeed, what if it were forbidden to take a pointer to a zero-sized 
variable in the first place? There is nothing to point at, after all.

On Wednesday 28 February 2024 at 07:17:24 UTC+7 Brien Colwell wrote:

> I think the surprising part is that the comparison result can change for 
> the same values because of the assumption that pointers never change. This 
> is implied by the spec but easy to miss.
>
> "Pointers to distinct zero-size variables may or may not be equal."
> "Pointers to distinct zero-size variables may or may not be equal and the 
> results may or may not be repeatable in any context."
>
> Agree once a programmer is aware of the behavior it can be avoided.
>
> Best,
> Brien
>
>
> On Feb 27, 2024, at 3:06 PM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> On Tue, Feb 27, 2024 at 8:19 PM Marvin Renich  wrote:
>
>> Prior to generics, the type of the
>> arguments to == were easily known to the programmer, and so it was
>> obvious when this "undefined" exception would raise its ugly head, and
>> you just didn't use it for empty struct types.  But now, with generics,
>> this can only be classified as a glaring BUG in the spec.
>
>
> There is pretty much a 0% chance that we'd change the spec in this regard, 
> at this point. It would mean that variable declarations like 
> `[1<<30]struct{}` would have to allocate huge chunks of heap, to ensure 
> that different index-expressions can have different addresses. And while 
> there shouldn't be any code relying on that not happening for correctness, 
> there is definitely code out there relying on it for performance (e.g. 
> there is a pattern of adding struct fields like `_ [0]func()` to ensure a 
> type is not comparable - such a struct would now change alignment and size).
>
> The optimization that variables of zero size can re-use the same address 
> has been in Go since before Go 1. Given this, it is pretty much implied 
> that comparison of those pointers will sometimes have weird results - the 
> only question is, *which* results are weird. I agree that this is one of 
> the weirder cases. But I don't think we can practically define `==` for 
> pointers to zero-sized variables.
>
> I'll also point out that for generics specifically, I'm not sure *any* 
> action would have a practical effect. If the type argument is not 
> statically known, we also can't special-case it to take into account that 
> it's a pointer to a zero-sized variable. Note that the triggered 
> optimization isn't necessarily "these are pointers to zero-sized variables, 
> hence I can do whatever I want" - it's "these are pointers to distinct 
> variables, hence I can assume they are unequal". That is a generally useful 
> optimization and it would still be applied to generic code.
>
> How can a programmer count on x == y having any meaning at all in code 
>> like this:
>>
>> func IsEqual[T comparable](x, y T) bool {
>> return x == y
>> }
>>
>> if the definition of == for empty structs is undefined?
>
>
> The result is defined for empty structs, just not for *pointers* to empty 
> structs.
> Note that `==` has other edge-cases as well. In particular, for floating 
> point/complex type arguments, `==` is irreflexive (e.g. NaN is unequal to 
> itself).
> I'm not sure that pointers to zero-sized variables make this significantly 
> worse.
>  
>
>> If we can at least agree that this ambiguity is no longer desirable,
>>
>
> I don't think we can agree on that, sorry.
>  
>
>> let's consider the two possible definitions:
>>
>> 1. Pointers to distinct zero-size variables are equal:
>>
>> This allows the compiler to easily optimize virtual address usage, but
>> is inconsistent with the non-zero-size definition.
>>
>
> Please look at the issue I filed for some discussion of edge-cases we are 
> unlikely to be able to cover satisfactorily. One obvious case is when 
> converting them to `unsafe.Pointer`, in which case the compiler no longer 
> knows that they point at zero-sized variables. Potentially, any such 
> conversion would have to re-assign them the magic "zero-sized variable" 
> address, which then would potentially lead to other weird comparison 
> implications, when code assumes that two `unsafe.Pointer` pointing at 
> distinct variables should have distinct addresses.
>
> We could probably make *more* such comparisons evaluate to `true`, but 
> it's unlikely that we could ever cover *all* of them. It would potentially 
> have prohibitive performance-impact on slicing operations, for example.

Re: [go-nuts] help

2024-02-18 Thread '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(, , ); err != nil {
>> log.Fatal(err)
>> }
>> users = append(users, u)
>> }
>> if err := rows.Err(); err != nil {
>> log.Fatal(err)
>> }
>>
>> json.NewEncoder(w).Encode(users)
>> }
>> }
>>
>> // get user by id
>> func getUser(db *sql.DB) http.HandlerFunc {
>> return func(w http.ResponseWriter, r *http.Request) {
>> vars := mux.Vars(r)
>> id := vars["id"]
>>
>> var u User
>> err := db.QueryRow("SELECT * FROM users WHERE id = $1", id).Scan(, 
>> , 
>> )
>> if err != nil {
>> w.WriteHeader(http.StatusNotFound)
>> return
>> }
>>
>> json.NewEncoder(w).Encode(u)
>> }
>> }
>>
>> // create user
>> func createUser(db *sql.DB) http.HandlerFunc {
>> return func(w http.ResponseWriter, r *http.Request) {
>> var u User
>> json.NewDecoder(r.Body).Decode()
>>
>> err := db.QueryRow("INSERT INTO users (name, email) VALUES ($1, $2) 
>> RETURNING id", u.Name, u.Email).Scan()
>> if err != nil {
>> log.Fatal(err)
>> }
>>
>> json.NewEncoder(w).Encode(u)
>> }
>> }
>>
>> // update user
>> func updateUser(db *sql.DB) http.HandlerFunc {
>> return func(w http.ResponseWriter, r *http.Request) {
>> var u User
>> json.NewDecoder(r.Body).Decode()
>>
>> vars := mux.Vars(r)
>> id := vars["id"]
>>
>> _, err := db.Exec("UPDATE users SET name = $1, email = $2 WHERE id = $3", 
>> u.Name, u.Email, id)
>> if err != nil {
>> log.Fatal(err)
>> }
>>
>> json.NewEncoder(w).Encode(u)
>> }
>> }
>>
>> // delete user
>> func deleteUser(db *sql.DB) http.HandlerFunc {
>> return func(w http.ResponseWriter, r *http.Request) {
>> vars := mux.Vars(r)
>> id := vars["id"]
>>
>> var u User
>> err := db.QueryRow("SELECT * FROM users WHERE id = $1", id).Scan(, 
>> , 
>> )
>> if err != nil {
>> w.WriteHeader(http.StatusNotFound)
>> return
>> } else {
>> _, err := db.Exec("DELETE FROM users WHERE id = $1", id)
>> if err != nil {
>> //todo : fix error handling
>> 

[go-nuts] Re: Trying to understand aversion to main package

2024-02-15 Thread 'Brian Candler' via golang-nuts
On Thursday 15 February 2024 at 00:08:44 UTC Jerry Londergaard wrote:

If code is outside of the main function but still in the main package, it 
seems its testable like other functions?


Yes indeed.
 

I suspect though if one is putting tests in package main_test, then I guess 
you can't import the main package to test it :(


Works fine as far as I can see:
https://go.dev/play/p/7UtYP2j8hg6

(Tests don't run in the playground, unless you explicitly invoke a runner, 
but you can run this locally to demonstrate)

-- 
You received this message because you are subscribed to the Google 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/1266c8e9-6e25-4347-87a3-eab6356a3cc5n%40googlegroups.com.


Re: [go-nuts] big int panic on text conversion

2024-02-14 Thread 'Brian Candler' via golang-nuts
Have you tried running your entire code under the race detector?
https://go.dev/blog/race-detector

On Wednesday 14 February 2024 at 06:02:02 UTC Kurtis Rader wrote:

> Maybe provide a minimal reproducible example (
> https://stackoverflow.com/help/minimal-reproducible-example)?
>
> While it is theoretically possible there is a bug in the `big` package 
> that could result in such panics it is much more likely the bug is in your 
> code. So showing us how you are using the `big` package will help us help 
> you.
>
> On Tue, Feb 13, 2024 at 9:36 PM Poonai  wrote:
>
>> big int panics during text conversion randomly 
>>
>> stack trace:
>>
>> panic: runtime error: index out of range [1] with length 1
>>
>> goroutine 2088184 [running]:
>> math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
>> /usr/local/go/src/math/big/natconv.go:340 +0x3d2
>> math/big.(*Int).Text(...)
>> /usr/local/go/src/math/big/intconv.go:25
>> math/big.(*Int).String(...)
>> /usr/local/go/src/math/big/intconv.go:40
>>
>> It shows up randomly, help me debug
>>
>> -- 
>> You received this message because you are subscribed 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/db0a5e73-0a1d-4dfb-9629-1d54cf492f95n%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/116c8dea-af9d-418d-b5fd-41548d923c7an%40googlegroups.com.


[go-nuts] Re: KeepAlive with net.Listen

2024-02-11 Thread 'Brian Candler' via golang-nuts
You're thinking backwards. "Long polling" is something done at the *client* 
side: this is where you send a HTTP request, but the reply intentionally 
doesn't come back for a long time - generally until the server detects some 
event that needs reporting.

At a web *server*, you simply read the request from the socket(*), process 
it, reply, and go straight back to reading the next request. Read will 
block until the next request comes in (or the connection is closed).  In 
other words, the goroutine handling that TCP connection just has a loop. 
There's no need to "wake" this goroutine from anywhere.

(*) You need to read until the end of the request (request headers + body, 
if any). Again, RFC2616 tells you how the request is delimited - see 
section 5.

On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:

> Thanks, that makes so much sense. So should I long-poll until next request 
> line comes or keep-alive times out? Is there a better way to detect 
> incoming requests and then maybe awake the goroutine using channels?
> On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:
>
>> Handling keep-alives on the *server* side doesn't require any sort of 
>> connection pool. Just create one goroutine for each incoming TCP 
>> connection, and once you've handled one request, loop around, waiting for 
>> another request on the same connection.
>>
>> (That's assuming the client does request use of keep-alives of course; if 
>> they don't, you should close the connection. This depends on which HTTP 
>> version they requested and the Connection: header if present. Full details 
>> in RFC 2616)
>>
>> On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:
>>
>>> Hello fellow gophers, I am currently building an experimental HTTP/1.1 
>>> framework based on TCP sockets as part of my course project. In project 
>>> requirements, I have been asked to make a web server which can handle 
>>> keep-alive properly without using the net/http library. The project link 
>>> can be found below:
>>> https://github.com/roychowdhuryrohit-dev/slug
>>> I have recently found out that if I *SetKeepAlive(true)* and 
>>> *SetKeepAlivePeriod(time.Second 
>>> * time.Duration(timeout))*, it is not enough to hold the connection. 
>>> Additionally, any subsequent requests are freezing.
>>> [image: Screenshot 2024-02-09 at 9.39.08 PM.png]
>>>
>>> Then I found out that net/http's Transport manages a pool for idle 
>>> connections. I want to go for a similar approach for my project. But I am 
>>> not able to figure out how to detect income requests for my idle 
>>> connections that I will be storing in the pool. Specifically, I want to 
>>> know how listener.Accept() can give me an idle connection if it exists in 
>>> the pool.
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/40fbf74d-81a4-43e2-b439-0b4afa9bb29an%40googlegroups.com.


[go-nuts] Re: KeepAlive with net.Listen

2024-02-10 Thread 'Brian Candler' via golang-nuts
Handling keep-alives on the *server* side doesn't require any sort of 
connection pool. Just create one goroutine for each incoming TCP 
connection, and once you've handled one request, loop around, waiting for 
another request on the same connection.

(That's assuming the client does request use of keep-alives of course; if 
they don't, you should close the connection. This depends on which HTTP 
version they requested and the Connection: header if present. Full details 
in RFC 2616)

On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:

> Hello fellow gophers, I am currently building an experimental HTTP/1.1 
> framework based on TCP sockets as part of my course project. In project 
> requirements, I have been asked to make a web server which can handle 
> keep-alive properly without using the net/http library. The project link 
> can be found below:
> https://github.com/roychowdhuryrohit-dev/slug
> I have recently found out that if I *SetKeepAlive(true)* and 
> *SetKeepAlivePeriod(time.Second 
> * time.Duration(timeout))*, it is not enough to hold the connection. 
> Additionally, any subsequent requests are freezing.
> [image: Screenshot 2024-02-09 at 9.39.08 PM.png]
>
> Then I found out that net/http's Transport manages a pool for idle 
> connections. I want to go for a similar approach for my project. But I am 
> not able to figure out how to detect income requests for my idle 
> connections that I will be storing in the pool. Specifically, I want to 
> know how listener.Accept() can give me an idle connection if it exists in 
> the pool.
>

-- 
You received this message because you are subscribed to the Google 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/a644122f-40ea-4d65-9d71-192e07595fc9n%40googlegroups.com.


Re: [go-nuts] Opening network connections blocks system thread

2024-02-10 Thread 'Brian Candler' via golang-nuts
I can't see how a large number of waiting goroutines would cause an 
increase in the number of OS threads, which was the OP's original problem 
(hitting the 10,000 thread limit)

What the OP is implying - but we have not seen good evidence for yet - is 
that in some circumstances a non-blocking connect() becomes blocking. But 
even then, how would Go know to allocate an OS thread for it *before* 
calling it??

I suspect something else is going on. Does the original program with the 
10,000 thread problem make any use of external C code, directly or 
indirectly?

On Saturday 10 February 2024 at 05:17:21 UTC Kurtis Rader wrote:

> On Fri, Feb 9, 2024 at 2:10 PM Ian Lance Taylor  wrote:
>
>> On Fri, Feb 9, 2024 at 11:57 AM Kurtis Rader  
>> wrote:
>> >
>> > The connect() syscall is normally blocking. It doesn't return until the 
>> connection is established or an error occurs. It can be made non-blocking 
>> by putting the file-descriptor into non-blocking mode before the connect() 
>> call. However, that then requires either an async callback or another 
>> syscall to check whether the connection was established or an error 
>> occurred. Neither approach is idiomatic Go.
>>
>> That is true, but the Go standard library's net package does use
>> non-blocking calls to connect internally when implementing net.Dial
>> and friends.
>>
>> I don't have any problem running the original program on Linux 6.5.13.
>>
>
> Yes, I realized after my previous reply that Go could obviously use 
> non-blocking connect() calls coupled with select(), poll(), or similar 
> mechanisms to wakeup a goroutine blocked waiting for a net.Dial() (or 
> equivalent) connection to complete in order to minimize the number of OS 
> threads required to handle in-flight network connections. Without requiring 
> exposing an async callback or a mechanism to explicitly start a connection 
> and at a later time test whether it has been established or failed.
>
> What might be happening for the O.P. is that the systems they are 
> connecting to are not explicitly accepting or rejecting the connections in 
> a timely manner. Thus causing a huge number of goroutines blocked waiting 
> for the net.Dial() to complete. The systems they are connecting to may be 
> simply discarding the TCP SYN packets due to firewall rules or something 
> similar. This is something that is going to be hard for the Go community to 
> provide help since it is fundamentally not an issue with Go itself.
>
> -- 
> 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/7a585302-ba38-4822-bdd7-76f9076ccd91n%40googlegroups.com.


[go-nuts] Re: Go 1.22 binary size improvements?

2024-02-09 Thread 'Brian Candler' via golang-nuts
Sorry you're right, it's "otool -L" for macOS.

And you say that if you cross-compile from Linux with 1.22.0 to build a 
macOS binary, you get a size approx 93.8MB as well? Very odd.

On Friday 9 February 2024 at 14:43:35 UTC cpu...@gmail.com wrote:

> Yes, CGO is disabled. ldd doesn't seem to exist on MacOS:
>
> make build && ls -la ./evcc && otool -L ./evcc
>
> 1.21.7
>
> CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
> github.com/evcc-io/evcc/server.Version=0.124.1 -X 
> github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
> -rwxr-xr-x  1 andig  staff  *93824418*  9 Feb 14:38 ./evcc
> ./evcc:
> /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> /usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> 
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 0.0.0, current version 0.0.0)
> /System/Library/Frameworks/Security.framework/Versions/A/Security 
> (compatibility version 0.0.0, current version 0.0.0)
>
> 1.22.0
>
> CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
> github.com/evcc-io/evcc/server.Version=0.124.1 -X 
> github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
> -rwxr-xr-x  1 andig  staff  *81119026*  9 Feb 14:37 ./evcc
> ./evcc:
> /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> /usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> 
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 0.0.0, current version 0.0.0)
> /System/Library/Frameworks/Security.framework/Versions/A/Security 
> (compatibility version 0.0.0, current version 0.0.0)
>
> On Friday, February 9, 2024 at 2:22:36 PM UTC+1 Brian Candler wrote:
>
>> Have you at any point set CGO_ENABLED=0 ?
>>
>> What does "ldd /path/to/binary" show on both the old (larger) and new 
>> (smaller) binaries?  Maybe one is dynamically linked and the other 
>> statically linked?
>>
>

-- 
You received this message because you are subscribed to the Google 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/510198df-4b95-4c55-8cc1-a40c13703578n%40googlegroups.com.


[go-nuts] Re: Go 1.22 binary size improvements?

2024-02-09 Thread 'Brian Candler' via golang-nuts
Have you at any point set CGO_ENABLED=0 ?

What does "ldd /path/to/binary" show on both the old (larger) and new 
(smaller) binaries?  Maybe one is dynamically linked and the other 
statically linked?

-- 
You received this message because you are subscribed to the Google 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/fb7d0cf7-0ebf-4205-aaac-cc8422fab2cfn%40googlegroups.com.


[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

2024-02-08 Thread 'Brian Candler' via golang-nuts
$ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count || echo "flaky:$?"
example.com/m: open 
/tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
no such file or directory

C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
-coverpkg=./internal/... -covermode count
example.com/m: open 
C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
The system cannot find the file specified.

Those look like the underlying errors causing the exit code 1. But it works 
fine for me under both Linux and macOS, as long as I have "go 1.22.0" in 
go.mod. Maybe someone who knows more about Windows can help?

On Thursday 8 February 2024 at 17:03:18 UTC Martin Schallnahs wrote:

> Hi Brian,
>
> thanks for checking out, yes that I wanted also to write you.
> We need it currently in our CI as some dependency scanner tool does not 
> work with the "go X.Y.Z." syntax, but I tried, and for my problem it did 
> not was the cause.
>
>
> > If a test fails, I would expect it to terminate with an error (exit code 
> 1 in this case).
>
> See my second mail, the test case should not fail, it was kinda a typo 
> (tried to shorten the reproducer to much in my first mail).
>
> > If I run your reproducer locally (not in Docker) with the modified 
> TestHelloer, it works fine(*) and gives me an exit code of 0
>
> Yes, when I run it with golang 1.21.7 it works fine as well, as my problem 
> statement is about golang 1.22.0.
>
> > Therefore, if your problem only occurs when using Docker, then you 
> should provide a docker-based reproducer (including the Dockerfile)
>
> Happens locally as well. And in my original setup it was using a fresh 
> docker container from golang (in an CI/GitLab pipeline) and did this:
>
> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count || echo "flaky:$?"
> example.com/m: open 
> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> no such file or directory
>
> === RUN   TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
> coverage: 100.0% of statements in ./internal/...
> ok   example.com/m/internal 0.004s coverage: 100.0% of statements in 
> ./internal/...
> flaky:1
> $ go tool cover -html=coverage.out -o coverage.html
> $ go tool cover -func=coverage.out
> example.com/m/internal/helloer.go:3: Helloer 100.0%
> total: (statements) 100.0%
>
>
> But I just tried it locally (Windows) and there it happens as well:
>
> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
> -coverpkg=./internal/... -covermode count
> example.com/m: open 
> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> The system cannot find the file specified.
>
> === RUN   TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
> coverage: 100.0% of statements in ./internal/...
> ok  example.com/m/internal  15.260s coverage: 100.0% of statements in 
> ./internal/...
>
>
> So for now I checked it on:
> - windows
> - debian (via docker container)
> - alpine (via docker container)
>
> All with 1.22.0.
>
> >  since you say that the coverage file is created, and presumably you 
> would have noticed the "toolchain not available" error message. In any 
> case, you're using a base image with go 1.22.0.
>
> Exactly.
> As seen in the output above, further commands (go tool cover) using the 
> coverage.out work fine.
>
> On Thursday 8 February 2024 at 10:46:44 UTC+1 Brian Candler wrote:
>
>> I found the solution to the "toolchain not available" problem: put "go 
>> 1.22.0" instead of "go 1.22" in go.mod. Clues picked up from #62278 
>> <https://github.com/golang/go/issues/62278>.
>>
>> It's confusing for people who've been using go for a while though, when 
>> go.mod used to contain "go X.Y" and it was invalid to put "go X.Y.Z". Now 
>> that appears to have swapped around 
>> <https://github.com/golang/go/issues/62278#issuecomment-1698829945>.
>>
>> On Thursday 8 February 2024 at 08:30:25 UTC Brian Candler wrote:
>>
>>> Is it a bug or exepected behaviour?
>>>
>>>
>>> If a test fails, I would expect it to terminate with an error (exit code 
>>> 1 in this case).
>>>
>>> If I run your reproducer locally (not in Docker) with the modified 
>>> TestHelloer, it works fine

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

2024-02-08 Thread 'Brian Candler' via golang-nuts
I found the solution to the "toolchain not available" problem: put "go 
1.22.0" instead of "go 1.22" in go.mod. Clues picked up from #62278 
<https://github.com/golang/go/issues/62278>.

It's confusing for people who've been using go for a while though, when 
go.mod used to contain "go X.Y" and it was invalid to put "go X.Y.Z". Now 
that appears to have swapped around 
<https://github.com/golang/go/issues/62278#issuecomment-1698829945>.

On Thursday 8 February 2024 at 08:30:25 UTC Brian Candler wrote:

> Is it a bug or exepected behaviour?
>
>
> If a test fails, I would expect it to terminate with an error (exit code 1 
> in this case).
>
> If I run your reproducer locally (not in Docker) with the modified 
> TestHelloer, it works fine(*) and gives me an exit code of 0:
>
> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> ?   example.com/m [no test files]
> === RUN   TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
>
> coverage: 100.0% of statements in ./internal/...
> ok   example.com/m/internal 0.135s coverage: 100.0% of statements in 
> ./internal/...
> % echo $?
> 0
>
> Therefore, if your problem only occurs when using Docker, then you should 
> provide a docker-based reproducer (including the Dockerfile)
>
> (*) However, I had to change the go.mod file to say version 1.21.  If it 
> says 1.22, I get an error.
>
> Under Linux (go1.21.7):
>
> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> go: downloading go1.22 (linux/amd64)
> go: download go1.22 for linux/amd64: toolchain not available
>
> Under macOS (go1.21.6):
>
> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> go: downloading go1.22 (darwin/arm64)
> go: download go1.22 for darwin/arm64: toolchain not available
>
> I don't *think* this is the same problem as you're seeing, since you say 
> that the coverage file is created, and presumably you would have noticed 
> the "toolchain not available" error message. In any case, you're using a 
> base image with go 1.22.0.
>

-- 
You received this message because you are subscribed to the Google 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/9247783b-ea6f-43ed-9ba5-9384dd7e4e08n%40googlegroups.com.


[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

2024-02-08 Thread 'Brian Candler' via golang-nuts


Is it a bug or exepected behaviour?


If a test fails, I would expect it to terminate with an error (exit code 1 
in this case).

If I run your reproducer locally (not in Docker) with the modified 
TestHelloer, it works fine(*) and gives me an exit code of 0:

% go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
?   example.com/m [no test files]
=== RUN   TestHelloer
--- PASS: TestHelloer (0.00s)
PASS
coverage: 100.0% of statements in ./internal/...
ok   example.com/m/internal 0.135s coverage: 100.0% of statements in 
./internal/...
% echo $?
0

Therefore, if your problem only occurs when using Docker, then you should 
provide a docker-based reproducer (including the Dockerfile)

(*) However, I had to change the go.mod file to say version 1.21.  If it 
says 1.22, I get an error.

Under Linux (go1.21.7):

$ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
go: downloading go1.22 (linux/amd64)
go: download go1.22 for linux/amd64: toolchain not available

Under macOS (go1.21.6):

% go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
go: downloading go1.22 (darwin/arm64)
go: download go1.22 for darwin/arm64: toolchain not available

I don't *think* this is the same problem as you're seeing, since you say 
that the coverage file is created, and presumably you would have noticed 
the "toolchain not available" error message. In any case, you're using a 
base image with go 1.22.0.

-- 
You received this message because you are subscribed to the Google 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/9c635e17-c1a4-46d0-92a1-d553e1b503f4n%40googlegroups.com.


Re: [go-nuts] Re: new range over int docs?

2024-02-07 Thread 'Brian Candler' via golang-nuts
But the main point is, the canonical version published 
at https://go.dev/ref/spec is still from Aug 2, 2023

On Wednesday 7 February 2024 at 12:02:28 UTC Rob Pike wrote:

> Ha ha, someone forgot to change the year. It should read Jan 30, 2024.
>
> That's confusing.
>
> -rob
>
>
> On Wed, Feb 7, 2024 at 8:47 PM peterGo  wrote:
>
>> Jason,
>>
>> The Go 1.22 source code says:
>>
>> "Subtitle": "Language version go1.22 (Jan 30, 2023)",
>>
>> Blame
>>
>> #569 9289b9c gri@*.*** 2024-01-31 16:40
>> [release-branch.go1.22] spec: clarify iteration variable type for range 
>> over integer
>> Change-Id: I4f1d220d5922c40a36264df2d0a7bb7cd0756bac
>>
>>
>> https://cs.opensource.google/go/go/+/release-branch.go1.22:doc/go_spec.html
>>
>> I consider the Go source code to be the truth.
>>
>> What are you looking at?
>>
>> Peter
>>
>>
>> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>>
>>> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>>>
 You are reading a specification dated Version of Aug 2, 2023. The 
 current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 
 10:08:15 PM EST.

>>>
>>> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, 
>>> which is what the 1.22 release notes points to.
>>>
>>>  
>>>
>> -- 
>> You received this message because you are subscribed 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/0e4fa760-1259-4b9c-9ff6-b60ba34413ccn%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/530cc20c-3125-42bc-87c7-906d9d7e31cen%40googlegroups.com.


[go-nuts] Re: Do we need to call multipart.Part.Close

2024-02-06 Thread 'Brian Candler' via golang-nuts
Documentation could certainly be improved, since the Part.Close() method 
<https://pkg.go.dev/mime/multipart#Part.Close> has literally no 
documentation.

Whilst it does feel unsound, in practice I don't think the behaviour could 
be changed now without breaking the Go compatibility guarantee (unless it 
was fundamental to a security issue, and even then I'd expect it to allow 
existing use cases).

On Tuesday 6 February 2024 at 14:29:07 UTC Pedro Luis Guzmán Hernández 
wrote:

> Thanks Brian. That is an implementation detail though, so relying on it 
> with no mention in the documentation at all feels unsound. A Close method 
> usually means you have to defer it right after getting the resource, so I 
> would have expected the docs to be more clarifying on its usage.
> El martes, 6 de febrero de 2024 a las 15:11:55 UTC+1, Brian Candler 
> escribió:
>
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325
>>
>> All it does is read all the remainder of the part to io.Discard.  So if 
>> you're sure you've read each part before moving onto the next one, it looks 
>> like you should be good.
>>
>> On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández 
>> wrote:
>>
>>> multipart.Part, returned by multipart.Reader's NextPart method, have a 
>>> Close() method. The only example here 
>>> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() 
>>> method at all, so what's it purpose? Can we safely ignore it?
>>>
>>> The reason I'm asking is that, calling *defer part.Closer *is a bit 
>>> annoying when you loop through a Reader (see the example mentioned above). 
>>> Calling the defer within the loop means all parts are closed at the end of 
>>> the function. The alternative would be to have an anonymous function within 
>>> the loop and call defer within it, but it feels so awkward.
>>
>>

-- 
You received this message because you are subscribed to the Google 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/ce483cc2-3129-4fe7-a594-84afe9c76248n%40googlegroups.com.


[go-nuts] Re: Do we need to call multipart.Part.Close

2024-02-06 Thread 'Brian Candler' via golang-nuts
https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325

All it does is read all the remainder of the part to io.Discard.  So if 
you're sure you've read each part before moving onto the next one, it looks 
like you should be good.

On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández 
wrote:

> multipart.Part, returned by multipart.Reader's NextPart method, have a 
> Close() method. The only example here 
> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() 
> method at all, so what's it purpose? Can we safely ignore it?
>
> The reason I'm asking is that, calling *defer part.Closer *is a bit 
> annoying when you loop through a Reader (see the example mentioned above). 
> Calling the defer within the loop means all parts are closed at the end of 
> the function. The alternative would be to have an anonymous function within 
> the loop and call defer within it, but it feels so awkward.

-- 
You received this message because you are subscribed to the Google 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/06a6bef9-cac1-4b0d-a04f-343f58e6f566n%40googlegroups.com.


Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread 'Brian Candler' via golang-nuts
> Thanks! In addition to that, It also helps with code with upper limit
> memory-requirement, which fmt.Sprintf() can't.

If you're processing data from untrusted sources, then you probably ought 
to validate it first.

> How to use a limiting
> io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
> memory usage?

Proof-of-concept: https://go.dev/play/p/kJabvvTzFH0

I don't know under what circumstances this would cause Fprintf to terminate 
early; it depends on how much buffering it does internally. I would guess 
that a large single argument like "%s" would be treated as a single entity, 
and very likely allocate an intermediate buffer of the full size.

If this matters in your use case, then I think you shouldn't be using 
Sprintf and friends.

-- 
You received this message because you are subscribed to the Google 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/960530e8-b872-4c86-8232-8fad8bd9d76cn%40googlegroups.com.


[go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread 'Brian Candler' via golang-nuts
The C functions are mainly there to prevent overrunning already-allocated 
buffers, which isn't an issue with Go.

You could truncate the response:

a := fmt.Sprintf("%s", "Blah blah blah")[0:10]

You could use suitable precision specifiers:

a := fmt.Sprintf("%.10s", "Blah blah blah")

You could make a custom type which implements io.Writer and truncates at a 
given size, and pass it to fmt.Fprintf

On Tuesday 6 February 2024 at 09:52:29 UTC fge...@gmail.com wrote:

> C *nprintf(3) implementations stop the conversion when n is reached.
> I couldn't find a similar functionality in the standard library, what
> did I miss?
> If there isn't any, any idea how to implement that without
> reimplementing all format helpers?
> 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/966c0d89-1570-4837-bf5c-657c09ca43e4n%40googlegroups.com.


[go-nuts] Re: Golang formating of alternate form with zero padding

2024-02-03 Thread 'Brian Candler' via golang-nuts
Admittedly, C and Python work the same way, which is different to Go.

#include 

int main(void) {
printf("%07x\n", 42);
printf("%0#7x\n", 42);
printf("0x%07x\n", 42);
return 0;
}

// Output
02a
0x0002a
0x02a

On Wednesday 31 January 2024 at 13:56:07 UTC Brian Candler wrote:

> https://pkg.go.dev/fmt#hdr-Printing
>
> The '#' means you want the alternate format with the 0x prepended, and the 
> '7' means you want the number itself padded to 7 digits 
>
> x := fmt.Sprintf("%07x", 42)   // 02a
> y := fmt.Sprintf("%0#7x", 42)   // 0x02a
> z := fmt.Sprintf("0x%07x", 42)   // 0x02a
>
> Seems pretty logical to me. If Python chooses to do it a different way, 
> that's because Python is a different language.
>
> On Wednesday 31 January 2024 at 13:23:01 UTC Lukas Toral wrote:
>
>> Hello,
>>
>> I am working on code that formats strings. I have an issue with 
>> formatting the alternate form with zero padding of signed hexadecimals.
>>
>> I have a format string like this: "%#07x", I would expect the zero 
>> padding to make sure the total width is 7. However, when I format the 
>> string using fmt.Sprintf I get the following results: 0x02a which has 
>> the length of 9 characters instead of the expected result: 0x0002a with the 
>> width of 7 characters.
>>
>> Example code: x := fmt.Sprintf("%#07x", 42) 
>> x will be equal to: 0x02a
>>
>> Example of python code that works as I would expect: result = 
>> "{:#07x}".format(42)
>> results will be equal to: 0x0002a
>>
>> I am suspicious that this might be a bug where the 0x is not accounted in 
>> the width but maybe I am doing something wrong.
>> Thanks for any 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/ff60170d-47d8-4ce2-be88-48d398740a18n%40googlegroups.com.


[go-nuts] Re: Golang formating of alternate form with zero padding

2024-01-31 Thread 'Brian Candler' via golang-nuts
https://pkg.go.dev/fmt#hdr-Printing

The '#' means you want the alternate format with the 0x prepended, and the 
'7' means you want the number itself padded to 7 digits 

x := fmt.Sprintf("%07x", 42)   // 02a
y := fmt.Sprintf("%0#7x", 42)   // 0x02a
z := fmt.Sprintf("0x%07x", 42)   // 0x02a

Seems pretty logical to me. If Python chooses to do it a different way, 
that's because Python is a different language.

On Wednesday 31 January 2024 at 13:23:01 UTC Lukas Toral wrote:

> Hello,
>
> I am working on code that formats strings. I have an issue with formatting 
> the alternate form with zero padding of signed hexadecimals.
>
> I have a format string like this: "%#07x", I would expect the zero padding 
> to make sure the total width is 7. However, when I format the string using 
> fmt.Sprintf I get the following results: 0x02a which has the length of 
> 9 characters instead of the expected result: 0x0002a with the width of 7 
> characters.
>
> Example code: x := fmt.Sprintf("%#07x", 42) 
> x will be equal to: 0x02a
>
> Example of python code that works as I would expect: result = 
> "{:#07x}".format(42)
> results will be equal to: 0x0002a
>
> I am suspicious that this might be a bug where the 0x is not accounted in 
> the width but maybe I am doing something wrong.
> Thanks for any 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/2a1e0976-4298-4e27-92c4-c5cf079482bfn%40googlegroups.com.


Re: [go-nuts] Re: Is encoding/json POSIX compatible?

2024-01-30 Thread 'Brian Candler' via golang-nuts
By the definition of "3.403 Text File 
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403>"
 
then no, because a JSON file can have arbitrarily long lines.

Note also: "Although POSIX.1-2017 does not distinguish between text files 
and binary files (see the ISO C standard), many utilities only produce 
predictable or meaningful output when operating on text files"

Hence there's no guarantee that a line-based text processing utility like 
grep or sed will behave meaningfully with arbitrary JSON data. Typically 
they do work with "incomplete" lines (3.195), but not arbitrarily long ones.

On Tuesday 30 January 2024 at 15:20:00 UTC Javier Marti wrote:

> So, as per the link that I sent, a json file is not a text file, right? is 
> just a file, I want to have this clear
>
>
> thanks
>
> On Tue, Jan 30, 2024 at 3:50 PM 'Brian Candler' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> The JSON spec does not require any whitespace after the object, newline 
>> or otherwise. And POSIX does not require that files end with a newline.
>>
>> Maybe you are thinking of another spec, like https://jsonlines.org/ - 
>> but that's not part of JSON.
>>
>> On Tuesday 30 January 2024 at 14:16:35 UTC Xabi Martí wrote:
>>
>>> I'm writing a program that uses enconding/json and when writing the 
>>> files I see that it doesn't add a newline character at the end of the file, 
>>> according to 
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
>>>  
>>> it is supposed that a line is:
>>>
>>> 3.206 Line
>>> A sequence of zero or more non-  characters plus a terminating 
>>>  character.
>>>
>>> so, I've to add it manually? why is not POSIX compatible? 
>>>
>>> example:
>>>
>>> cat -e file.json | tail -n 2
>>>   }$
>>> }%
>>>
>>> any help? thanks!
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/qjxJ3Zunzfc/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/692bd65e-74f4-448a-b399-de8c38785aefn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/692bd65e-74f4-448a-b399-de8c38785aefn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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


[go-nuts] Re: Is encoding/json POSIX compatible?

2024-01-30 Thread 'Brian Candler' via golang-nuts
The JSON spec does not require any whitespace after the object, newline or 
otherwise. And POSIX does not require that files end with a newline.

Maybe you are thinking of another spec, like https://jsonlines.org/ - but 
that's not part of JSON.

On Tuesday 30 January 2024 at 14:16:35 UTC Xabi Martí wrote:

> I'm writing a program that uses enconding/json and when writing the files 
> I see that it doesn't add a newline character at the end of the file, 
> according to 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
>  
> it is supposed that a line is:
>
> 3.206 Line
> A sequence of zero or more non-  characters plus a terminating 
>  character.
>
> so, I've to add it manually? why is not POSIX compatible? 
>
> example:
>
> cat -e file.json | tail -n 2
>   }$
> }%
>
> any help? 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/692bd65e-74f4-448a-b399-de8c38785aefn%40googlegroups.com.


[go-nuts] Re: Rendering fonts in Go

2024-01-12 Thread 'Brian Candler' via golang-nuts
At worst, it may possible to compile C into Go. It sounds mad, but I 
believe SQLite has been ported to pure Go this way.

https://pkg.go.dev/modernc.org/sqlite
https://twitter.com/bradfitz/status/855271867162083329?lang=en
https://groups.google.com/g/golang-nuts/c/QDEczMhlQBU/m/4lCn2kP0AwAJ
https://github.com/elliotchance/c2go

On Thursday 11 January 2024 at 22:05:56 UTC Yuliana Zigangirova wrote:

> Thank you, I will have a look.  I have hoped on finding pure Go, 
> but may be it is unrealistic.
>
> On Saturday, December 23, 2023 at 1:10:13 AM UTC+3 Howard C. Shaw III 
> wrote:
>
>> I think Freetype may still be your best bet - but rather than the 
>> Freetype port, you would need to use a wrapper that calls the Freetype C 
>> library, such as https://github.com/danielgatis/go-freetype
>>
>>

-- 
You received this message because you are subscribed to the Google 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/a81de428-ce73-4a80-ae3e-ed516e01b206n%40googlegroups.com.


[go-nuts] Re: mmapping over Go heap

2024-01-10 Thread 'Brian Candler' via golang-nuts
> accessing it after munmap leads to SIGSEGV or worse

There must be a hundred different ways you can make a Go program segfault, 
and this doesn't sound any worse that the rest of them.

Besides, unless the GC is changed to handle mmap regions differently, I 
think you would have the problem the opposite way around. What if you have 
an area of heap memory which has been mmap'd, and you don't call munmap, 
but there are no pointers left referring to it? Wouldn't the heap quietly 
start allocating other objects from that address space?

On Wednesday 10 January 2024 at 16:44:28 UTC Nick Zavaritsky wrote:

> Hi,
>
> Packages offering memory mapped files in golang follow one of the two 
> possible routes:
>
> 1) memory is accessed via io.Reader (e.g. golang.org/x/exp/mmap);
>
> 2) mapped memory is directly exposed as []byte; accessing it after munmap 
> leads to SIGSEGV or worse (e.g. github.com/edsrzf/mmap-go).
>
> I'm not happy with option #1 due to the added overhead. There are multiple 
> high performance interfaces in Linux based on memory mappings such as 
> io-uring, ebpf ring buffers, and AF_XDP.. I'd love to avoid extra copies, 
> call overhead and *especially* heap allocations.
>
> On the other hand, option #2 makes me concerned about dangling pointers 
> that remain after the memory is unmapped.
>
> I'm curious if the following approach might work.
>
> 1) obtain []byte from golang heap;
> 2) mmap on top.
>
> Munmap will turn the address range into anonymous memory mapping again, 
> similar to other pages backing golang heap. Dangling pointers, if any, are 
> safe to follow. Once GC proves that no references remain, the address range 
> naturally becomes available for reuse.
>
> I'm not familiar with the runtime internals. Please let me know if this is 
> a bad idea.
>
> Best,
>
> N
>

-- 
You received this message because you are subscribed to the Google 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/ca520972-aab9-45af-b961-f9b0fe856795n%40googlegroups.com.


[go-nuts] Cipher suite oddity

2024-01-09 Thread 'Brian Candler' via golang-nuts
Something just pointed out to me(*) that I don't understand:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is in tls.CipherSuites() 

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is in tls.InsecureCipherSuites() 


Why is the SHA256 variant considered "insecure", but the SHA (presumably 
SHA1) variant "secure"?

Are these actually different cipher suites but with confusingly similar 
names?

(*) https://groups.google.com/g/prometheus-users/c/SJYu7cH_XKQ

-- 
You received this message because you are subscribed to the Google 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/9c08a688-051c-4b95-9d55-6b5c42d12086n%40googlegroups.com.


Re: [go-nuts] Re: [RFC] Syntactic Dissonance

2024-01-06 Thread 'Brian Candler' via golang-nuts
Full explanation here:
https://blog.merovius.de/posts/2018-06-03-why-doesnt-go-have-variance-in/

On Saturday 6 January 2024 at 11:55:27 UTC John Pritchard wrote:

> Hi,
>
> Thinking about types and their conception, I could avoid the type 
> assertion boilerplate and rationalize the type membership relationship if 
> this code compiled.
>
> Best,
>
> John
>  
>
> On Sat, Jan 6, 2024 at 3:21 AM Tamás Gulácsi  wrote:
>
>> Where does TestObject implement the Comparable interface, esp. the 
>> Compare method?
>> I don't see such in that rep.
>> The implemented TestObject.Compare method has different signature: it 
>> requests a TestObject, not a Comparable interface, as your spec!
>> This is only the first error.
>>
>> The second is that a slice of objects cannot be converted to a slice of 
>> interface - only by manually copying:
>>
>> ```
>> diff --git a/sort_test.go b/sort_test.go
>> index 0874721..c89b3b3 100644
>> --- a/sort_test.go
>> +++ b/sort_test.go
>> @@ -13,10 +13,10 @@ type TestObject string
>>  
>>  type TestList []TestObject
>>  
>> -func (this TestObject) Compare(that TestObject) int {
>> +func (this TestObject) Compare(that Comparable) int {
>>  
>>   var bi, bj byte
>> - var x, y, z int = 0, len(this), len(that)
>> + var x, y, z int = 0, len(this), len(that.(TestObject))
>>   var d, c int = 0, 0
>>  
>>   if y == z {
>> @@ -34,7 +34,7 @@ func (this TestObject) Compare(that TestObject) int {
>>  
>>   for ; x < c; x++ {
>>   bi = this[x]
>> - bj = that[x]
>> + bj = (that.(TestObject))[x]
>>   if bi != bj {
>>  
>>   if bi < bj {
>> @@ -58,7 +58,11 @@ func (this TestList) Print() {
>>  func TestSort(t *testing.T) {
>>   var vector TestList = TestList{TestObject("20231219192613"), 
>> TestObject("20231221074246"), TestObject("20240102214104"), 
>> TestObject("20231222063428"), TestObject("20240104112200"), 
>> TestObject("20231217190339"), TestObject("20231213155157"), 
>> TestObject("20231219065525"), TestObject("20231231120412"), 
>> TestObject("20231221152849"), TestObject("20240102073948"), 
>> TestObject("20240101083455")}
>>  
>> - Sort(vector)
>> + objs := make([]Comparable, len(vector))
>> + for i := range vector {
>> + objs[i] = vector[i]
>> + }
>> + Sort(objs)
>>  
>>   vector.Print()
>>  }
>> ```
>> John Pritchard a következőt írta (2024. január 6., szombat, 8:53:01 
>> UTC+1):
>>
>>> Hi,
>>>
>>> Here's a case of "type dissonance" I don't understand.  Why should it be?
>>>
>>> https://github.com/syntelos/go-sort
>>>
>>>
>>> An interface type not passing through a static public package function 
>>> that employs the interface.
>>>
>>> type Comparable interface {
>>>
>>>
>>> Compare(Comparable) int
>>>
>>> }
>>>
>>> func Sort(array []Comparable) ([]Comparable)
>>>
>>>
>>> With go-1.20.12:
>>>
>>> $ go test
>>> # github.com/syntelos/go-sort [github.com/syntelos/go-sort.test]
>>> ./sort_test.go:61:7: cannot use vector (variable of type TestList) as 
>>> []Comparable value in argument to Sort
>>> FAILgithub.com/syntelos/go-sort [build failed]
>>>
>>>
>>> Any comments?
>>>
>>> Best,
>>>
>>> John
>>>
>>>
>>> -- 
>> You received this message because you are subscribed 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/ba7239c1-cb52-4f86-9e56-da6ffa721fa5n%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/a44e7a3b-9390-460e-9b80-e9f5ffe5a18bn%40googlegroups.com.


[go-nuts] Re: <-ctx.Done() panic

2024-01-03 Thread 'Brian Candler' via golang-nuts
Panics can be caused by all sorts of things, but concurrency issues are a 
big one. Have you tried running your code under the race detector?
https://go.dev/blog/race-detector

On Wednesday 3 January 2024 at 10:57:49 UTC cheng dong wrote:

> i have a program paniced with 
>
> ```
> runtime.deferCallSave(0xc0313d56d8, 0xc0401839e8?)
> /home/ubuntu/go/go1.19.5/src/runtime/panic.go:796 +0x88 
> fp=0xc0313d5618 sp=0xc0313d5608 pc=0x43b248
> runtime.runOpenDeferFrame(0xc02349b860?, 0xc0300967d0)
> /home/ubuntu/go/go1.19.5/src/runtime/panic.go:769 +0x1a5 
> fp=0xc0313d5660 sp=0xc0313d5618 pc=0x43b065
> panic({0x344a800, 0xc03352c8d0})
> /home/ubuntu/go/go1.19.5/src/runtime/panic.go:884 +0x212 
> fp=0xc0313d5720 sp=0xc0313d5660 pc=0x43b4b2
> runtime.panicdottypeE(0x6648f00, 0x32b77a0, 0x33adc40)
> /home/ubuntu/go/go1.19.5/src/runtime/iface.go:262 +0x6a 
> fp=0xc0313d5740 sp=0xc0313d5720 pc=0x40cb2a
> context.(*cancelCtx).Done(0xc040183824?)
> /home/ubuntu/go/go1.19.5/src/context/context.go:361 +0x1d4 
> fp=0xc0313d57c0 sp=0xc0313d5740 pc=0x512554
> ```
>
> however, this code just not match with go1.19.5 context/context.go:361. so 
> i cant figure out what happened
>

-- 
You received this message because you are subscribed to the Google 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/1009082f-2528-4adb-b853-a2bebc5e018dn%40googlegroups.com.


[go-nuts] Re: How to get net.Conn in rpc function in net/rpc

2023-12-28 Thread 'Brian Candler' via golang-nuts
What do you mean by "Real IP" and in particular how does it differ from the 
TCP source address? If the client is behind a NAT, then (a) you won't know 
the client's real IP unless they tell it to you (and you trust what they 
say), and (b) you won't be able to connect to that address anyway.

If your actual requirement is to issue RPC calls in the 'reverse' direction 
down the same TCP connection, then you can look at how it's done here:
https://github.com/cenkalti/rpc2

On Thursday 28 December 2023 at 15:31:02 UTC York gao wrote:

> I have a requirement that requires the rpc server to get the client’s 
> **real IP** and current connection `net.Conn`.
>
>  The reason for needing **real IP** and `net.Conn` is roughly for 
> **two-way communication**. I hope to be able to send RPC requests to the 
> client of a specific IP to perform certain operations. For example, issue 
> RPC commands to certain Agent services to execute a certain script.
>
> I can get the remoteip through the following RemoteAddr method, but this 
> is not necessarily the real IP of the client.
> ```go
> // example_server.go
> type MathService struct{}
> type Args struct {
> A, B int
> }
> type Reply struct {
> Result int
> }
> func (m *MathService) Multiply(args *Args, reply *Reply) error {
> reply.Result = args.A * args.B
> return nil
> }
> func main() {
> // Create an instance of the MathService
> mathService := new(MathService)
> // Register MathService for RPC
> rpc.Register(mathService)
> // Create a TCP listener
> listener, err := net.Listen("tcp", "0.0.0.0:1234")
> if err != nil {
> fmt.Println("Error starting server:", err)
> return
> }
> defer listener.Close()
> fmt.Println("Server listening on :1234")
> for {
> // Accept incoming connections
> conn, err := listener.Accept()
> if err != nil {
> fmt.Println("Error accepting connection:", err)
> continue
> }
> fmt.Printf("remote ip addr: %s\n", conn.RemoteAddr().String())
> // Serve the connection in a new goroutine
> go rpc.ServeConn(conn)
> }
> }
>
> // example_client.go
> type Args struct {
> A, B int
> }
> type Reply struct {
> Result int
> }
> func main() {
> // Connect to the server
> client, err := rpc.Dial("tcp", "127.0.0.1:1234")
> if err != nil {
> fmt.Println("Error connecting to server:", err)
> return
> }
> defer client.Close()
> // Prepare the arguments for the RPC call
> args := {A: 5, B: 3}
> // Call the Multiply method remotely
> var reply Reply
> err = client.Call("MathService.Multiply", args, )
> if err != nil {
> fmt.Println("Error calling Multiply:", err)
> return
> }
> // Print the result
> fmt.Printf("Result: %d\n", reply.Result)
> }
> ```
>
> Therefore, I hope to manually call the`ReportRealIP` function to report 
> the **real IP**, but I cannot get the **current** connected `net.Conn` in 
> the **rpc function**.
>
> But I searched some information and found no way to achieve my needs. Is 
> there a way to get the two variables I want? Looking forward to your reply
>
>

-- 
You received this message because you are subscribed to the Google 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/1734f6df-b8c9-4466-8e53-2243a88bb991n%40googlegroups.com.


[go-nuts] Re: regexp docs for 'Index' ?

2023-12-14 Thread 'Brian Candler' via golang-nuts
No: result is the result, which is a bunch of 2-element arrays concatenated.

As the documentation says: "result[2*n:2*n+2] identifies *the indexes* of 
the nth submatch"  (i.e. the start index and the end index)

In principle, accessing the i'th result is like this:

start, end := matches[i*2:i*2+2]

However Go doesn't actually allow a slice to be unpacked that way (only 
certain multi-valued things like function results and channel receives)

On Thursday 14 December 2023 at 10:30:06 UTC Peter Galbavy wrote:

> Ah! My bad. I misread the docs - "result" is the input, while the "n" 
> indexes are actually the values of the submatches, not the indexes. I still 
> think it's confusing, but makes more sense when I write it like this: 
> https://go.dev/play/p/SHl_aSU3kPZ 
>
> On Thursday 14 December 2023 at 09:06:00 UTC Brian Candler wrote:
>
>> [a:b] gives you the elements from a to b-1 inclusive. So if you want the 
>> pair at position x, it has to be [x:x+2]
>>
>> https://go.dev/play/p/3nvEfOjdfnj
>>
>> On Thursday 14 December 2023 at 08:38:57 UTC Peter Galbavy wrote:
>>
>>> I noticed today that the regexp docs read:
>>>
>>> If 'Index' is present, matches and submatches are identified by byte 
>>> index pairs within the input string: result[2*n:2*n+2] identifies the 
>>> indexes of the nth submatch. 
>>>
>>> I think that should be result[2*n:2*n+1] - at least in my code that's 
>>> how it is working.
>>>
>>> If I'm right, happy to raise a doc bug, but never done that, so not sure 
>>> how - for a one digit change?
>>>
>>> Peter
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/f19eff98-2073-4229-a631-7856dd0952efn%40googlegroups.com.


[go-nuts] Re: regexp docs for 'Index' ?

2023-12-14 Thread 'Brian Candler' via golang-nuts
[a:b] gives you the elements from a to b-1 inclusive. So if you want the 
pair at position x, it has to be [x:x+2]

https://go.dev/play/p/3nvEfOjdfnj

On Thursday 14 December 2023 at 08:38:57 UTC Peter Galbavy wrote:

> I noticed today that the regexp docs read:
>
> If 'Index' is present, matches and submatches are identified by byte index 
> pairs within the input string: result[2*n:2*n+2] identifies the indexes of 
> the nth submatch. 
>
> I think that should be result[2*n:2*n+1] - at least in my code that's how 
> it is working.
>
> If I'm right, happy to raise a doc bug, but never done that, so not sure 
> how - for a one digit change?
>
> Peter
>

-- 
You received this message because you are subscribed to the Google 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/415721e0-ddff-4b35-9490-79be363f7215n%40googlegroups.com.


[go-nuts] Re: detecting deleted file that is still open and appending without error in Go?

2023-12-11 Thread 'Brian Candler' via golang-nuts
On Sunday 10 December 2023 at 16:41:00 UTC Jason E. Aten wrote:

My question is: is there a way to have the Go process detect if the file it 
is writing to has been deleted by another process (git in this case) so 
that attempting to append to the file is no longer effective?


On Unix, I'd fstat the open file, stat the file on disk by name, and 
compare the inode numbers.

In Go, it's easy enough to get FileInfo but you need to dig a bit into 
Sys() to pull out the underlying Unix stat data.
https://stackoverflow.com/questions/28339240/get-file-inode-in-go

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


[go-nuts] Re: Sending Context across channel - is it an anti-pattern?

2023-12-06 Thread 'Brian Candler' via golang-nuts
A (cancellable) context is mostly just a channel, which is closed as a 
broadcast signal, wrapped in an interface. I don't think that how you pass 
it around makes any difference, including sending it over another channel.

Aside: it can be argued that "worker pool" is an anti-pattern in Go. 
Goroutines are so cheap that there's very little point in re-using them; 
you might as well just create one, let it do some work then terminate. Of 
course you want to limit the amount of *concurrent* work that is done, but 
there are other ways to achieve that. If there's stuff you need to keep 
around from task to task, like a persistent database connection, then maybe 
"worker pool" still makes sense.

This is covered in the talk "Rethinking Classical Concurrency Patterns" by 
Bryan C. Mills:
https://www.youtube.com/watch?v=5zXAHh5tJqQ
It's all well worth watching - keep the pause and rewind buttons under your 
fingers!  Code at 32:15 shows limiting concurrency amongst goroutines, 
giving worker-pool-like behaviour but without leaving idle goroutines lying 
around.

On Wednesday 6 December 2023 at 06:02:31 UTC Sharad Jain wrote:

> Hello,
>
> All the material about Golang Context on web confirm that passing Context 
> to goroutines is a-ok and encouraged. I didn't find much information on 
> whether passing Context across channel is ok or not.
>
> In our use-case, we have a worker pool which is setup to allow a finite 
> number of goroutines to process the work. The work items are fed using a 
> go-channel. We can think of each work-item as a separate request (kafka 
> event in our case). We create a new Context for each of these incoming 
> event and send them across channel to the worker pool. The question is 
> whether including Context as part of this work-item is an ok thing to do or 
> not. It seems to be working fine, though we are curious if there is any 
> downside, and if so what would be a better design.
>
> Thanks for your time,
>

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


[go-nuts] Re: Using Go in picore (tinycore)

2023-12-06 Thread 'Brian Candler' via golang-nuts
You should note that you don't necessarily need to install the go compiler 
on your target machine. You can build ARM binaries on an x86_64 machine for 
example - set the parameters GOOS and GOARCH. Go is especially good for 
this sort of cross-compilation, as it doesn't require any special 
toolchains to be installed. It's out-of-the-box functionality.

But if you do want to run go on the target system itself, then I'd expect 
just installing the binary distribution should work.  Try it and see!

As for crash safety: it's normally a matter of what type of filesystem is 
being used.

On Wednesday 6 December 2023 at 02:04:35 UTC 王富民awaw wrote:

> Hi Gophers and embedded systems experts
>
> How can I use the latest version of Go, 1.21.5, in picore 
> , which is the 
> raspberry pi port of the lightweight linux OS tinycore 
> ?
> Although, the x86_64 version includes 
> Go, the picore version doesn't 
> .
>
> To use Go, could I simply download
>
> https://go.dev/dl/go1.21.5.linux-armv6l.tar.gz
>
> into the picore OS, and simply use Go straightaway?
> If not, can anyone share the steps to compile Go from source on picore?
>
> If anyone is curious why we're not using the default raspberry pi OS,
> it is because our users often unplug the pi's power abruptly without 
> proper shutdown causing sd card corruption and eventually OS boot failures. 
> To this end, we also evaluated TinyGo, but there are two issues:
> * TinyGo does not have wifi 
> yet.
> * We need to segment 
> live
>  
> stream from a camera, and thus need ffmpeg
>
> Some people in the raspberry pi community recommend Ultibo 
> for use cases where abrupt power unplugging is 
> required.
> However, since Ultibo is not Go, I'd preferably rather not use it, as I 
> really don't want to code in anything other than Go.
>

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


[go-nuts] Re: Mongo Go Models (mgm) module and order by

2023-11-22 Thread 'Brian Candler' via golang-nuts
https://github.com/Kamva/mgm/discussions perhaps?  (Open, but nothing 
posted since June 2022).

On Wednesday, 22 November 2023 at 17:02:35 UTC Tong Sun wrote:

> Any Mongo Go Models (mgm) user here?
> https://github.com/Kamva/mgm
>
> Looks like that mgm can do aggregation but not "order by".
> Is that so? 
>
> Can anyone do order by with mgm please?
>
> PS. 
>
> Support requests are supposed to be post to mongo-go-models Google Group 
> , however, that 
> seems to be gone and searching Mongo Go Models (mgm) in Google Group landed 
> me here into this mlist instead. 
>
>

-- 
You received this message because you are subscribed to the Google 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/e309dafc-6971-4651-a6d1-5f9483bdc747n%40googlegroups.com.


[go-nuts] Re: Deciding between better documentation or making a module harder to misuse

2023-11-18 Thread 'Brian Candler' via golang-nuts
Maybe you're overthinking this. One option would be for Number to have a 
boolean attribute saying whether it's definitely finite, exposed as an 
IsFinite() method on Sequence. Calling FindLast() on a sequence where 
IsFinite() is false would panic. It's not compile-time safe, but it's 
better than an infinite loop.

Potentially, sqroot.Sqrt(9) could set IsFinite true (if that's cheap to 
determine).

> But in v3, Number has to be an interface because FiniteNumber has to 
extend Number

I don't think it has to "extend" (do you mean "embed"?): there are other 
ways to share common code, e.g. factor it out into helper functions.

There is no need for types which implement the same interface to have any 
structural commonality at all.  Nor do overlapping interfaces for that 
matter.

In Go, the rule of thumb is: accept interfaces, return concrete types.  
(The main exception is errors, where it's conventional to return an error 
interface value, and a nil interface means "no error")

Hence you could have interfaces Sequence and FiniteSequence defined with 
the same set of methods, except that FiniteSequence has an extra dummy 
method like ReallyIsFinite().  It's never called, but is implemented by 
FiniteNumber and not Number, for type checking purposes only.

On Saturday, 18 November 2023 at 13:41:37 UTC Travis Keep wrote:

> I have published this module: 
> https://pkg.go.dev/github.com/keep94/sqroot/v2 for analysing square roots 
> and cube roots.  The module works, but it is easy to write code that will 
> run forever. For example in v2:
>
> // Print the position of the last 7 in the square root of 2. Oops, the 
> square root of 2 goes
> // goes forever.
> fmt.Println(sqroot.FindLast(sqroot.Sqrt(2), []int{7}))
>
> // This code snippet runs in a finite amount of time as it prints the 
> position of the
> // last 7 within the first 100 digits of the square root of 2.
> fmt.Println(sqroot.FindLast(sqroot.Sqrt(2).WithSignificant(100), []int{7}))
>
> v3, which hasn't been published makes it so that most code that would run 
> forever won't compile.  It does this by introducing new types: 
> FiniteSequence which extends Sequence and FiniteNumber which extends 
> Number.  In v3, sqroot.Sqrt() returns a Number since square roots can have 
> either a finite or infinite number of digits, but 
> sqroot.Sqrot(2).WithSignificant(100) returns a FiniteNumber because it can 
> have no more than 100 digits.  In v3, sqroot.FindLast() takes a 
> FiniteSequence as a parameter, which is how 
> fmt.Println(sqroot.FindLast(sqroot.Sqrt(2), []int{7})) won't compile in v3.
>
> The safety that v3 adds is great, but it comes at a cost. In v2, Number is 
> a concrete type. Its methods have examples in the documentation. But in v3, 
> Number has to be an interface because FiniteNumber has to extend Number and 
> Go does not support inheritance of concrete types.  With Number as an 
> interface, all the examples for the Number methods disappear from the 
> documentation.  
>
> Also v3 adds some extra complexity with its diamond inheritance tree. 
> FiniteSequence and Number extend Sequence, and FiniteNumber extends Number 
> and FiniteSequence.
>
> So I am wondering whether or not to publish v3.  v3 is definitely harder 
> to misuse than v2, but v3 can't have all the code examples that v2 has 
> because Number is an interface in v3 not a concrete type.
>
> So I am wondering what the community thinks is best in this situation.
>

-- 
You received this message because you are subscribed to the Google 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/0b62c02c-a812-4cb7-878a-ceadc173dc88n%40googlegroups.com.


[go-nuts] Re: Go-native abstract service interface design

2023-11-17 Thread 'Brian Candler' via golang-nuts
I think it depends on what your semantic contract is for this interface.

If the caller starts a server with Run(ctx), is it implied that cancelling 
of ctx should stop the running server? If so, ISTM that there is no need 
for a separate Shutdown() method.  (And there would be no need for App and 
Runnable to be different interfaces)

Note that if the caller wanted to be able to signal a shutdown without 
cancelling the overall context, they could have passed in a child context 
 and cancelled that instead.  
Equally, if the server needs to receive an explicit Shutdown call for 
whatever reason, it can run a goroutine which waits for the ctx to be 
cancelled and then do whatever it would do if Shutdown() were called.

Indeed, I cannot see what Shutdown(ctx context.Context) would actually do. 
What is the purpose of the ctx passed in here? What if the ctx passed to 
Shutdown is different to the one passed to Run?

Another question I have around semantics is: if a server has been shutdown, 
is it permitted to call Run() on it a second time?  You could allow this, 
but it depends on whether Run() does all initialization, or it depends on a 
clean underlying object.

There is also a question as to whether the error result from Shutdown() is 
required - actually, a server might terminate for reasons other than 
Shutdown() being called - and to know when shutdown has finished after 
being requested. In that case, you might want a separate way to signal (a) 
that the server has terminated, and (b) to return the error value. That 
could for example be a channel returned by Run(). If you make it a 
1-element buffered channel then it doesn't matter whether the value is 
consumed or not.

On Thursday, 16 November 2023 at 13:40:37 UTC Grant Zvolský wrote:

> Upon reflection, I would make the following improvements to bring the 
> interfaces closer to Go's philosophical ideals:
>
> * Remove the App interface because it only has one implementation
> * Remove the Named interface because all its usages seem to be replaceable 
> with a package-scoped const
> * Split the Runnable interface into Runner and Shutdowner (inspired by 
> Reader/Writer) with the advice not to use Shutdowner if context-based 
> shutdown is sufficient
>
> Redesigned interfaces:
> ```
> type Runner interface {
>Run(ctx context.Context) error
> }
>
> // Shutdowner adds a Shutdown method for services whose shutdown procedure 
> needs to be cancellable.
> type Shutdowner interface {
>Shutdown(ctx context.Context) error
> }
> ```
>

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


[go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?

2023-11-15 Thread 'Brian Candler' via golang-nuts
On Tuesday, 14 November 2023 at 03:38:04 UTC Mike Schinkel wrote:

1. A value variable and multiple value receivers  <--- compiles
2. A pointer variable and multiple value receivers <--- compiles
3. A pointer variable and multiple pointer receivers.  <--- compiles 
4. A value variable and multiple pointer receivers.  <--- will NOT compile
5. A pointer variable and mixed value+pointer receivers  <--- compiles 
6. A value variable and mixed value+pointer receivers. <--- will NOT compile

Permutation #4 and #6 are consistent with the description above, and they 
both have *a value variable *in common.

However, given than #5 DOES compile, I was left wondering why the standard 
that mixed receivers should be flagged as an error? 


I am not sure that "the standard" is for mixed receivers to be flagged as 
an error. Can you give a specific example of where the standard Go 
toolchain does this?

Is this question really about Goland, a third-party product, and/or some 
underlying third-party linter that it uses?  If so, it's an issue for that 
third party.

Arguably it's not great style to do this, and it might make it confusing 
for users of your package. But it's not an error, either for the compiler 
or "go vet". https://go.dev/play/p/fBgrltIEjA2

-- 
You received this message because you are subscribed to the Google 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/4fe6a954-696c-40f1-86cf-ea9148e42ba2n%40googlegroups.com.


[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

2023-10-17 Thread 'Brian Candler' via golang-nuts
Are you sure that the writer isn't closing the named pipe between writing 
JSON objects? If necessary you can check this with strace.

I'm pretty sure you'll get an EOF in the *reader* when the *writer* closes 
from their side. You can demonstrate this with the shell:

(In terminal 1)
mkfifo /tmp/fifo
cat /tmp/fifo

(In terminal 2)
cat >/tmp/fifo
abcd
efgh
<< wait a while >>
^D

When you hit ^D in terminal 2, the cat in terminal 1 ends.

The solution (or as you asked, "how to reset this?") is simply to re-open 
the fifo for reading.

On Tuesday, 17 October 2023 at 13:40:47 UTC+1 Christopher C wrote:

> I was thinking partial reads could be an issue and the Decoder seemed to 
> do the initial checking for me. Would the ReadAll() be able to recover from 
> EOF state?
>
> On Tuesday, October 17, 2023 at 4:37:58 AM UTC-4 Volker Dobler wrote:
>
>> Why do you use a json.Decoder? It seems as reading
>> everything (io.ReadAll) until EOF and json.Unmarshal'ling
>> would be a cleaner/simpler solution?
>>
>> V.
>>
>> On Tuesday, 17 October 2023 at 09:10:09 UTC+2 Christopher C wrote:
>>
>>> Hello all!
>>> I'm trying to read json objects from a named pipe.  The pipe will be  
>>> filled intermittently by bash scripts.  After the Decode() of the first 
>>> object, any more calls to Decode() will return EOF.  This seems proper 
>>> since the script has completed, but once it errors with EOF, there doesn't 
>>> seem to be a way to read any more.
>>>
>>> Is there a way to 'reset' the decoder so when another script writes to 
>>> the pipe it can process the next object, or should I be doing some pipe 
>>> length validation before trying to decode?
>>>
>>> Current read code snippet  is...
>>>
>>> decoder := json.NewDecoder(fpipe)
>>> for {
>>> err := decoder.Decode()
>>> if err != nil {
>>> if err == io.EOF {
>>> // how to reset this?
>>> } else {
>>> logger.Fatal(err)
>>> }
>>> } else {
>>> // send out the msg
>>>
>>>

-- 
You received this message because you are subscribed to the Google 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/75667b50-9eaf-4721-b3a4-75f023be753fn%40googlegroups.com.


[go-nuts] Re: Is there a race in exec.CombinedOutput?

2023-10-04 Thread 'Brian Candler' via golang-nuts
Code reference:
https://cs.opensource.google/go/go/+/refs/tags/go1.21.1:src/os/exec/exec.go;l=523-565

* c.writerDescriptor creates the pipe, and a copying function is appended 
to the slice c.goroutine. This slice contains the functions which will be 
started in their own goroutines.
* c.childStdout calls c.writerDescriptor
* c.childStderr reuses the exiting childStdout if Stdout and Stderr are the 
same (and therefore there is still only one function in c.goroutine)
* interfaceEqual implements the check that Jason quoted:
https://cs.opensource.google/go/go/+/refs/tags/go1.21.1:src/os/exec/exec.go;l=473-480

On Wednesday, 4 October 2023 at 05:58:29 UTC+1 Jason Phillips wrote:

> From the Stdout/Stderr field documentation on the os/exec.Cmd type 
> :
>
> "If Stdout and Stderr are the same writer, and have a type that can be 
> compared with ==, at most one goroutine at a time will call Write."
>
> On Tuesday, October 3, 2023 at 9:55:16 PM UTC-4 王富民awaw wrote:
>
> exec.CombinedOutput uses the same io.Writer for both stdout and stderr in  
> exec.go 
> - Go (opensource.google) 
> 
>  .
> This io.Writer is written in  exec.go - Go (opensource.google) 
> 
>  .
> These two writes happens concurrently in two goroutines in exec.go - Go 
> (opensource.google) 
> 
>  .
> As far as I know, bytes.Buffer is not safe to concurrent writes.
> Is this not a race?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5fd62068-f540-4a89-8fdb-10eaf86b5850n%40googlegroups.com.


[go-nuts] Re: Why doesn't the database/sql package in Go support using placeholders "?" to replace the database name and username in SQL statements?

2023-09-18 Thread Brian Candler
Or else it's a prepared statement which gets invoked with parameters.

Mysql's own documentation is unclear on where placeholders can be 
used: https://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html

Note that they give this example:

mysql> SET @table = 't1'; mysql> SET @s = CONCAT('SELECT * FROM ', @table);

mysql> PREPARE stmt3 FROM @s; mysql> EXECUTE stmt3;

They don't do "SELECT * FROM ?" because you're not allowed to use a 
placeholder for the table name - it must be inlined into the SQL. (And in 
this example @table had better be from a trusted source, since they don't 
do any quoting or escaping)

On Monday, 18 September 2023 at 13:01:52 UTC+1 Vladimir Varankin wrote:

> A thing, that it may be valuable to explain further, is that Go's 
> "database/sql" doesn't come with a built-in query builder. 
>
> The package implements the database connection pooling/management, but it 
> passes the user's SQL input and its arguments to the "driver". Depending on 
> the particular database kind, the driver may or may not try to interpret 
> the query (and the args), before it passes them to the database server.
>
> In the specific example of MySQL/MariaDB, the support for placeholder "?" 
> is a part of this database's flavour of SQL. Thus, it's likely, the driver 
> you're using, passes the query with a placeholder to the DB server, but the 
> DB's support of placeholders is limited to only a subset of queries (or 
> places inside a query) — as the link to SO's answer, shared previously, 
> explained.
>
> Hope this makes it a little bit more clear.
>
> On Sunday, September 17, 2023 at 10:45:27 AM UTC+2 Brian Candler wrote:
>
>> According to this SO answer, CREATE USER in mysql doesn't support 
>> placeholders:
>>
>> https://stackoverflow.com/questions/20647115/how-to-write-create-user-with-mysql-prepared-statement
>> *"+1 for a legitmiate use of QUOTE() which is really the sanest thing 
>> that can be done here, since CREATE USER doesn't support ? placeholders"*
>>
>> You can test this by trying a simple DML statement, e.g.
>> UPDATE users SET name=? where name=?
>>
>> On Sunday, 17 September 2023 at 01:02:08 UTC+1 John Zh wrote:
>>
>>> Hi !
>>> I am going to make some kind of manager app over MySQL clusters by using 
>>> Golang. But I found that when I try to exec some SQL line includes user 
>>> name or db name, the SQL line can't be correctly parameterized.
>>> For example:
>>> Using GORM based on database/sql or directly using database/sql
>>> ```
>>> err := db.Exec("CREATE USER ? IDENTIFIED BY ?", a.Name, a.Pwd).Error
>>> ```
>>> Got
>>> ```
>>> [1.824ms] [rows:0] CREATE USER 'Reiis' IDENTIFIED BY '12345'
>>> Error 1064 (42000): You have an error in your SQL syntax; check the 
>>> manual that corresponds to your MySQL server version for the right syntax 
>>> to use near '? IDENTIFIED BY ?' at line 1
>>> ```
>>>
>>> Seems like it does not replace "?" with a.Name, but rather passes the 
>>> SQL command with "?" directly to MySQL.  What is more wired, it prints 
>>> the SQL command with correctly replaced parameters in the log.
>>>
>>> I don't know the the underlying reason behind this phenomenon, is it 
>>> intentionally designed like that?
>>> Thx!
>>>
>>

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


[go-nuts] Re: cannot find package "github.com/go-redis/redis/v8"

2023-09-18 Thread Brian Candler
You always need a go.mod file if you are importing other modules. But if 
you're not publishing your code, you can name your own module however you 
like: "go mod init example" is fine.

On Monday, 18 September 2023 at 11:27:09 UTC+1 Aadi Sharma wrote:

> I am using go-redis package and can not use it's any version without mod 
> file.
> Do golang does not allow us to  use this package without mod file ? 
> I use  
> . github.com/go-redis/redis/v8 ,  go get github.com/go-redis/redis and 
> github.com/go-redis/redis/v9
>  but with none of these three comands i was not able to import the redis 
> package.
> On the other hand i  use to import this package with the presence of mod 
> file and
> it get's imported.
> How to use this package without any mod file
>
>
>
> With regards
> Aadi
>

-- 
You received this message because you are subscribed to the Google 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/a53ed8a6-562f-48d2-9c21-3876ac61f277n%40googlegroups.com.


[go-nuts] Re: Help with WASM performance

2023-09-16 Thread Brian Candler
What WASM runtime are you using to execute the code?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7f629585-17a6-406f-81df-ac668db62c75n%40googlegroups.com.


[go-nuts] Re: Weird error when trying to fetch a module.

2023-09-15 Thread Brian Candler
> I can not find the go.mod for flatbuffers! It is not in the root of the 
repository and also not inside the go subdir where the code resides

Presumably relies on this:
https://go.dev/ref/mod#non-module-compat

See also
https://stackoverflow.com/questions/67030123/can-a-go-module-have-no-go-mod-file

On Friday, 15 September 2023 at 16:36:03 UTC+1 Bruno Albuquerque wrote:

> So, I am still curious about something. Flatbuffers, which is a project I 
> depend on, does have its go code in a subdirectory and I can go get it:
>
> ➜  ~ go get -x github.com/google/flatbuffers/go
> # get https://proxy.golang.org/github.com/@v/list
> # get https://proxy.golang.org/github.com/google/flatbuffers/@v/list
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@v/list
> # get https://proxy.golang.org/github.com/google/@v/list
> # get https://proxy.golang.org/github.com/@v/list: 404 Not Found (0.156s)
> # get https://proxy.golang.org/github.com/google/@v/list: 404 Not Found 
> (0.230s)
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@v/list: 
> 200 OK (0.236s)
> # get https://proxy.golang.org/github.com/google/flatbuffers/@v/list: 200 
> OK (0.236s)
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@latest
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@latest: 
> 404 Not Found (0.023s)
> go: added github.com/google/flatbuffers v23.5.26+incompatible
>
> As comparison, here is what I get for flatgeobuf:
>
> ➜  ~ go get -x github.com/flatgeobuf/flatgeobuf/go 
> # get https://proxy.golang.org/github.com/@v/list
> # get https://proxy.golang.org/github.com/flatgeobuf/@v/list
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@v/list
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/go/@v/list
> # get https://proxy.golang.org/github.com/@v/list: 404 Not Found (0.124s)
> # get https://proxy.golang.org/github.com/flatgeobuf/@v/list: 404 Not 
> Found (0.126s)
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@v/list: 
> 200 OK (0.130s)
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@latest
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@latest: 
> 200 OK (0.023s)
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/go/@v/list: 
> 404 Not Found (4.152s)
> go: module github.com/flatgeobuf/flatgeobuf@upgrade found 
> (v0.0.0-20230914202020-25c11d75fe28), but does not contain package 
> github.com/flatgeobuf/flatgeobuf/go
>
> Is the difference simply that flatbuffers has an associated tag and 
> flatgeobuf currently does not?
>
> While we are at it, I can not find the go.mod for flatbuffers! It is not 
> in the root of the repository and also not inside the go subdir where the 
> code resides. Is there some special casing for this project in place?
>
> -Bruno
>
> On Thu, Sep 14, 2023 at 5:58 PM Bruno Albuquerque  wrote:
>
>> It is likely that I am doing something stupid but as I am out of ideas, 
>> here goes nothing.
>>
>> I pushed an initial Go flatgeobuf implementation here:
>>
>> github.com/flatgeobuf/flatgeobuf/src/go
>>
>> This directory in the repository has a go.mod file with the following 
>> contents:
>>
>> module github.com/flatgeobuf/flatgeobuf/src/go
>> go 1.20
>> require github.com/google/flatbuffers v22.11.23+incompatible
>>
>> Just in case it might be relevant, the actual repository is 
>> github.com/flatgeobuf/flatgeobuf, src/go is a subdirectory there.
>>
>> If I try to use this module, it fails. For example:
>>
>> # go get -u github.com/flatgeobuf/flatgeobuf/src/go
>> go: downloading github.com/flatgeobuf/flatgeobuf 
>> v0.0.0-20230914202020-25c11d75fe28
>> go: module github.com/flatgeobuf/flatgeobuf@upgrade found 
>> (v0.0.0-20230914202020-25c11d75fe28), but does not contain package 
>> github.com/flatgeobuf/flatgeobuf/src/go
>>
>> What am I missing?
>>
>> -Bruno
>>
>>

-- 
You received this message because you are subscribed to the Google 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/257a32dc-4797-457d-a2dd-ac4abf4804can%40googlegroups.com.


Re: [go-nuts] Re: Weird error when trying to fetch a module.

2023-09-15 Thread Brian Candler
> Keep your go source at the root of the repo and tag that

Or would it be OK just to put go.mod at the root of the repo, containing
module github.com/flatgeobuf/flatgeobuf
- and leave the rest of the source where it is?

I believe that will still allow someone to import or get
github.com/flatgeobuf/flatgeobuf/src/go
(not that that's a pretty import path). But I don't know if it will behave 
any differently to what the OP sees today.

-- 
You received this message because you are subscribed to the Google 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/9638fac0-caa9-491e-bfb2-1d5e51df678en%40googlegroups.com.


Re: [go-nuts] Re: Parsing difficult JSON

2023-09-14 Thread Brian Candler
Could you just unmarshal it to a map[string]IntTSList, and then walk it and 
build whatever structure you want?

If you want to pick certain fixed fields into a struct and separate out the 
leftovers to be parsed as "subnet[X].Y", then see
https://stackoverflow.com/questions/33436730/unmarshal-json-with-some-known-and-some-unknown-field-names
The last answer points to some other JSON libraries which can handle this 
part for you - but you'd still have to process the "subnet[X].Y" keys.

On Thursday, 14 September 2023 at 16:18:09 UTC+1 Tobias Klausmann wrote:

> Hi! 
>
> On Thu, 14 Sep 2023, Peter Galbavy wrote:
> > You will need to create a custom type and unmarshal method. Plenty of 
> > example if you search for "golang custom json unmarshal".
> > 
> > As I've only had to implement it for a couple of simple types I can't 
> offer 
> > my own valid example.
>
> I am aware of the ability to make custom unmarshalers, but in this
> particular case, I would have to ma an unmarshaler for basically the
> whole JSON - since I cant map all variants of foo[n].something to one
> type/unmarshaler: the stdlib JSON functionality using struct tags does
> not allow fro wildcards/patterns, as far as I can tell, and I don't know
> what range N might be in, so I can't hardcode it.
>
> Best,
> Tobias
>

-- 
You received this message because you are subscribed to the Google 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/64c2d808-fcd7-4238-a5d3-187f1f7c6b49n%40googlegroups.com.


Re: [go-nuts] How ignore a subdirectory

2023-09-13 Thread Brian Candler
I believe that "go fmt ." (note the space after "go") works on the current 
package only.

On Wednesday, 13 September 2023 at 11:34:35 UTC+1 Jan Mercl wrote:

> On Wed, Sep 13, 2023 at 12:25 PM John Souvestre  
> wrote:
> > I did try that also.  I get this error message:
> >
> > CreateFile *.go: The filename, directory name, or volume label 
> syntax is incorrect.
>
> Sorry, I'm not familiar with Windows and only TIL cmd.exe does not expand 
> globs. I suggest to install WSL and try something like
>
> C:\>bash -c 'gofmt *.go'
>
> HTH
>
>

-- 
You received this message because you are subscribed to the Google 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/cf14f4f9-14fa-495e-905e-d7a62d8c070dn%40googlegroups.com.


Re: [go-nuts] Using go module 101, undefined types

2023-09-12 Thread Brian Candler
> I also tried to build the whole project with `go build .`

To do that you would need:

mkdir -p bin
go build -o bin ./...

The following compiles fine for me. Note that in your original post the 
error talks about api.PetStore, but the code you showed was a call to 
api.NewPetStore. Incidentally, you might also want to 
read https://google.github.io/styleguide/go/best-practices#naming

==> ./go.mod <==
module backend

==> ./internal/petstore/main.go <==
package main

import api "backend/internal/petstore/interfaces/ports"

func main() {
_ = api.PetStore{}
}

==> ./internal/petstore/interfaces/ports/type.go <==
package api
type PetStore struct {}

-- 
You received this message because you are subscribed to the Google 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/3925d84f-6d7a-46c5-a6c9-eb9806bed253n%40googlegroups.com.


[go-nuts] Re: Generic function for types with common method name but different return type

2023-09-10 Thread Brian Candler
> https://go.dev/play/p/h5jzISRyTkF In this approach, I'm not fond of how I 
must call the f function on line 30. Without specifying a type parameter, 
the call fails to compile.

If I replace f[A](a, "") with f(a, "") it still works for me, in the 
playground.

What go version are you using? There were several improvements to type 
inference for generics in 1.21.
https://tip.golang.org/doc/go1.21#language

On Sunday, 10 September 2023 at 01:17:55 UTC+1 Oleh Lomaka wrote:

> Hello everybody,
>
> Gophers' superpower is required and highly appreciated.
>
> I have two types, A and B, each of which has a method named "M". This 
> method accepts a string and returns an instance of the type it is declared 
> on.
>
> ```go
> type A struct {}
> func (a A) M (string) A {
> return a
> }
> type B struct {}
> func (b B) M (string) B {
>return b
> }
> ```
> What's the best way to declare a generic function that receives an 
> instance of one of these types along with a string? Depending on the 
> string, this function should either return the instance it received or call 
> method M on it and return the instance produced by this method.
>
> Currently, I've come up with two solutions, but I'm not entirely satisfied 
> with either:
>
> https://go.dev/play/p/h5jzISRyTkF In this approach, I'm not fond of how I 
> must call the f function on line 30. Without specifying a type parameter, 
> the call fails to compile. Additionally, I'm concerned about potential 
> panics on line 23. If I expand the code with new types in the future, 
> there's a risk of type assertion failures.
>
> https://go.dev/play/p/rHHjV_A-hvK While this solution appears cleaner, 
> it's prone to panicking if I introduce another type with an incompatible M 
> signature (or without M method completely)
>
> Maybe someone has better ideas.
>
> Thank you.
> All the best,
>

-- 
You received this message because you are subscribed to the Google 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/967a1949-eae2-4920-b4c1-34443575cf4dn%40googlegroups.com.


Re: [go-nuts] go1.21.0 panics when loading plugin

2023-09-05 Thread Brian Candler
But if you remove the reference to regexp/syntax in the top-level main.go, 
then it also works fine (with no change to the plugin code itself).

On Tuesday, 5 September 2023 at 20:05:58 UTC+1 Howard C. Shaw III wrote:

> It looks to me like the regexp package has an func init() that never gets 
> called when Re is only imported in a plugin, which is why it works when you 
> uncomment the lines that use regexp in the main package.
>
> Howard
>

-- 
You received this message because you are subscribed to the Google 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/9d61d856-8630-41bd-823d-079101305dacn%40googlegroups.com.


Re: [go-nuts] go1.21.0 panics when loading plugin

2023-09-05 Thread Brian Candler
Slightly simplified version:

==> go.mod <==
module example.com

go 1.20

==> main.go <==
package main

import (
"plugin"
"regexp/syntax"
)

func main() {
if syntax.Perl != 212 {
panic("Unexpected flags")
}

p, err := plugin.Open("p1.so")
if err != nil {
panic(err)
}
s, err := p.Lookup("F")
if err != nil {
panic(err)
}

f := s.(func())
f()
}

==> p1/plugin.go <==
package main

import (
"regexp"
)

func F() {
_ = regexp.MustCompile(`\w+`)
}

func main() {}


FWIW, it also fails in the same way on macOS:

$ go build -buildmode=plugin ./p1 && go run main.go
panic: regexp: Compile(`\w+`): error parsing regexp: invalid escape 
sequence: `\w`

goroutine 1 [running]:
regexp.MustCompile({0x107aa6eea, 0x3})
/usr/local/go/src/regexp/regexp.go:319 +0xb4
example.com/p1.F()
/Users/brian/tmp/go/62430/p1/plugin.go:8 +0x1f
main.main()
/Users/brian/tmp/go/62430/main.go:23 +0x103
exit status 2

-- 
You received this message because you are subscribed to the Google 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/e6767616-877e-4362-9c2f-21522646ccc9n%40googlegroups.com.


Re: [go-nuts] go1.21.0 panics when loading plugin

2023-09-05 Thread Brian Candler
I forgot to include

==> go.mod <==
module example.com

go 1.20

-- 
You received this message because you are subscribed to the Google 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/ef1aa868-6604-45a9-ae91-4cfd6d4ce277n%40googlegroups.com.


Re: [go-nuts] go1.21.0 panics when loading plugin

2023-09-05 Thread Brian Candler
I have been able to replicate the OP's problem with go 1.21.0

==> main.go <==
package main

import (
"plugin"
//"regexp"
"regexp/syntax"
)

func main() {
//_, _ = regexp.Compile(`\w+`)

p, err := plugin.Open("p1.so")
if err != nil {
panic(err)
}
s, err := p.Lookup("F")
if err != nil {
panic(err)
}

f := s.(func() (syntax.Flags, error))
_, err = f()
if err != nil {
panic(err)
}
}

==> p1/plugin.go <==
package main

import (
"regexp"
"regexp/syntax"
)

func F() (syntax.Flags, error) {
_, err := regexp.Compile(`\w+`)
return syntax.Flags(0), err
}

func main() {}


$ go version
go version go1.21.0 linux/amd64
$ go build -buildmode=plugin ./p1 && go run main.go
panic: error parsing regexp: invalid escape sequence: `\w`

goroutine 1 [running]:
main.main()
/home/ubuntu/62430/main.go:24 +0x129
exit status 2

The problem goes away if you uncomment the two commented-out lines in 
main.go

I had an idea about what might be happening.  In this situation, 
MustCompile is behaving like MustCompilePOSIX (which doesn't accept the \w 
character class).

Package regexp/syntax defines a constant "Perl" which includes various 
flags, including PerlX which allows this class:

func Compile(expr string) (*Regexp, error) {
return compile(expr, syntax.Perl, false)
}

I'm wondering if somehow this value hasn't been initialized, and is treated 
as zero.  However, if I print the value of syntax.Perl within main() or 
F(), I see that it is 212 as expected, even when the error occurs.

On Monday, 4 September 2023 at 18:55:07 UTC+1 Brian Candler wrote:

> I'm afraid I have to contradict that answer (from an AI chatbot perhaps?)
>
> Go's regexp library, called re2, is documented here: 
> https://github.com/google/re2/wiki/Syntax
>
> It *does* support the \w character class. See the section headed "Perl 
> character classes (all ASCII-only)".  Furthermore, the OP was successfully 
> using \w with go 1.20.7.  The problem arose with 1.21 and is something to 
> do with plugin loading or initialization.
>
> On Monday, 4 September 2023 at 17:56:32 UTC+1 Google's Affiliate (Google 
> Business Affiliate) wrote:
>
>> Hello, this is Jonathan, I can help you with your question about the 
>> error parsing regexp in Go.
>>
>> The error you are getting is caused by the use of \w in your regular 
>> expression. This is an invalid escape sequence in Go, because \w is not 
>> a predefined character class 
>> <https://stackoverflow.com/questions/6770898/unknown-escape-sequence-error-in-go>
>> 1 
>> <https://stackoverflow.com/questions/6770898/unknown-escape-sequence-error-in-go>
>> . Go only supports the following escape sequences in regular expressions 
>> <https://www.bing.com/search?form=MY0291=MY0291=Bing+AI=1#>
>> 2 
>> <https://stackoverflow.com/questions/24836885/go-regex-error-parsing-regexp-invalid-escape-sequence-k>
>> :
>>
>>- \t for tab
>>- \n for newline
>>- \r for carriage return
>>- \f for form feed
>>- \a for alert
>>- \b for word boundary
>>- \B for non-word boundary
>>- \d for decimal digit
>>- \D for non-decimal digit
>>- \s for whitespace character
>>- \S for non-whitespace character
>>- \w for word character (alphanumeric plus _)
>>- \W for non-word character
>>
>> To match a word character in Go, you need to use [[:word:]], which is 
>> equivalent to [0-9A-Za-z_]. Alternatively, you can use [[:alnum:]]_, 
>> which is equivalent to [0-9A-Za-z]_. So, your regular expression should 
>> be:
>>
>> regexp.Compile(`^([[:word:]./]+)/((?:[[:word:]]+)|[*])(.+)?$`)
>>
>> or
>>
>> regexp.Compile(`^([[:alnum:]_./]+)/((?:[[:alnum:]_]+)|[*])(.+)?$`)
>>
>> This should fix the error and allow you to load the plugin successfully.
>>
>> I hope this helps you with your problem. If you have any further 
>> questions, please feel free to ask. 
>>
>>
>>
>> On Sunday, September 3, 2023 at 4:47:39 AM UTC-4 Olivier Szika wrote:
>>
>>> Hi,
>>>
>>> Unexpectedly, unicode.Categories is an empty map when it's only used 
>>> with a plugin.
>>> I opened a ticket: https://github.com/golang/go/issues/62430
>>>
>>> Regards,
>>>
>>> Le samedi 12 août 2023 à 18:13:31 UTC+2, Wojciech S. Czarnecki a écrit :
>>>
>>>> Dnia 2023-08-08, o godz. 18:11:56 
>>>> Bernd Fix  napisał(a): 
>>>>
>>>> > After switching from go1.20.7 to go1.21.0 one of my applications 
>>>> > compiles without warnings or errors,

Re: [go-nuts] go1.21.0 panics when loading plugin

2023-09-04 Thread Brian Candler
I'm afraid I have to contradict that answer (from an AI chatbot perhaps?)

Go's regexp library, called re2, is documented 
here: https://github.com/google/re2/wiki/Syntax

It *does* support the \w character class. See the section headed "Perl 
character classes (all ASCII-only)".  Furthermore, the OP was successfully 
using \w with go 1.20.7.  The problem arose with 1.21 and is something to 
do with plugin loading or initialization.

On Monday, 4 September 2023 at 17:56:32 UTC+1 Google's Affiliate (Google 
Business Affiliate) wrote:

> Hello, this is Jonathan, I can help you with your question about the error 
> parsing regexp in Go.
>
> The error you are getting is caused by the use of \w in your regular 
> expression. This is an invalid escape sequence in Go, because \w is not a 
> predefined character class 
> 
> 1 
> 
> . Go only supports the following escape sequences in regular expressions 
> 
> 2 
> 
> :
>
>- \t for tab
>- \n for newline
>- \r for carriage return
>- \f for form feed
>- \a for alert
>- \b for word boundary
>- \B for non-word boundary
>- \d for decimal digit
>- \D for non-decimal digit
>- \s for whitespace character
>- \S for non-whitespace character
>- \w for word character (alphanumeric plus _)
>- \W for non-word character
>
> To match a word character in Go, you need to use [[:word:]], which is 
> equivalent to [0-9A-Za-z_]. Alternatively, you can use [[:alnum:]]_, 
> which is equivalent to [0-9A-Za-z]_. So, your regular expression should 
> be:
>
> regexp.Compile(`^([[:word:]./]+)/((?:[[:word:]]+)|[*])(.+)?$`)
>
> or
>
> regexp.Compile(`^([[:alnum:]_./]+)/((?:[[:alnum:]_]+)|[*])(.+)?$`)
>
> This should fix the error and allow you to load the plugin successfully.
>
> I hope this helps you with your problem. If you have any further 
> questions, please feel free to ask. 
>
>
>
> On Sunday, September 3, 2023 at 4:47:39 AM UTC-4 Olivier Szika wrote:
>
>> Hi,
>>
>> Unexpectedly, unicode.Categories is an empty map when it's only used with 
>> a plugin.
>> I opened a ticket: https://github.com/golang/go/issues/62430
>>
>> Regards,
>>
>> Le samedi 12 août 2023 à 18:13:31 UTC+2, Wojciech S. Czarnecki a écrit :
>>
>>> Dnia 2023-08-08, o godz. 18:11:56 
>>> Bernd Fix  napisał(a): 
>>>
>>> > After switching from go1.20.7 to go1.21.0 one of my applications 
>>> > compiles without warnings or errors, but fails at run-time with the 
>>> > following panic when loading a plugin: 
>>>
>>> IIRC release notes tools now are version aware, so likely you need to 
>>> bring 
>>> all go.mod's version to state 1.21.0 
>>>
>>> hope this helps, 
>>>
>>> > Cheers, Bernd. 
>>> > 
>>>
>>>

-- 
You received this message because you are subscribed to the Google 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/e43019b7-3fd7-4163-ac9f-c7b6e5465204n%40googlegroups.com.


[go-nuts] Re: go-embed results in http 404

2023-09-02 Thread Brian Candler
Firstly, there must be no space between "//" and "go:embed". Otherwise it's 
just treated as a regular comment, and you get an empty fs with no error.  
(Perhaps "go vet" could be enhanced to catch this?)

After fixing this, you'll see the underlying error:
main.go:10:12: pattern public: no matching files found

For an explanation see https://pkg.go.dev/embed#hdr-Directives

"The patterns are interpreted relative to the package directory containing 
the source file"

These means you'll need to move your public/ directory inside the cmd/ 
directory. (You can't use a symlink; this causes the embed process to fail 
with error "cannot embed irregular file")

After that, it should be OK :-)

On Saturday, 2 September 2023 at 09:28:11 UTC+1 Sankar wrote:

> I have the following go code where I try to embed a html file from a 
> public directory and running into HTTP 404.  What am I doing wrong ? 
> Relevant code snippet:
>
>
> // go:embed public
> var public embed.FS
>
> func main() {
> // cd to the public directory
> publicFS, err := fs.Sub(public, "public")
> if err != nil {
> log.Fatal(err)
> }
> http.Handle("/embedded/", http.FileServer(http.FS(publicFS)))
>
> http.Handle("/public/",
> http.StripPrefix("/public/", http.FileServer(http.Dir("public"
>
> log.Fatal(http.ListenAndServe(":8080", nil))
> }
>
> The entire golang file and the html file are available in 
> https://github.com/psankar/static-serve
>
> I have tried adding even a `http.StripPrefix` for the `/embedded/` path 
> also but even that does not help. Any pointers on what I am doing wrong ?
>

-- 
You received this message because you are subscribed to the Google 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/788df31e-daa1-4d92-8d0a-d52e136bb8den%40googlegroups.com.


[go-nuts] Re: go build of a *_unix.go file still used under windows ?

2023-08-31 Thread Brian Candler


During a particular build, the following build tags are satisfied:

   - ...
   - "unix", if GOOS is a Unix or Unix-like system.
   - ...


It then says:

If a file's name, after stripping the extension and a possible _test 
suffix, matches any of the following patterns:
*_GOOS *_GOARCH *_GOOS_GOARCH 

(example: source_windows_amd64.go) where GOOS and GOARCH represent any 
known operating system and architecture values respectively, then the file 
is considered to have an implicit build constraint requiring those terms 
(in addition to any explicit constraints in the file).

This says that only GOOS and GOARCH are considered; it doesn't say that all 
possible build tags are interpreted when in the filename, and indeed there 
are many that are not.  For example, "foo_gccgo.go" and "foo_go1.12.go" are 
not treated specially. So I think it's fairly clear here, as long as you 
accept that "unix" is neither a GOOS nor a GOARCH.

Aside: finding a comprehensive list of GOOS and GOARCH values is a bit 
tricker. You can run "go tool dist list", or there are third-party 
summaries like
https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63

On Thursday, 31 August 2023 at 10:44:14 UTC+1 Peter Galbavy wrote:

> Ah! Got it. Thanks.
>
> Would it perhaps be good to mention this in the docs, here: 
> https://pkg.go.dev/cmd/go#hdr-Build_constraints ?
>
> The bullet points refer to "unix" (which is true) and then a naïve reader, 
> like me, would think the later paragraphs about GOOS also apply.
>
> Peter 
>
> On Thursday, 31 August 2023 at 10:13:12 UTC+1 Brian Candler wrote:
>
>> https://github.com/golang/go/issues/51572
>>
>> On Thursday, 31 August 2023 at 08:57:15 UTC+1 Peter Galbavy wrote:
>>
>>> I have used comment level build constraints for a while but I moved to 
>>> using _linux.go and _windows.go over time as it makes it clearer for 
>>> external viewing.
>>>
>>> A user reported they tried to build on MacOS and of course this didn't 
>>> work. I renamed the _linux.go files to _unix.go suffixes but then when I do 
>>> "GOOS=windows go build" those files were pulled in too. While I would say 
>>> Windows is a POSIX-ish system I would contend it's not UNIX :-)
>>>
>>> I have gone and added "//go:build !windows" to all the renamed files for 
>>> now, but is this intended behaviour?
>>>
>>> Peter
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/1cfb5996-93ee-4ce6-94dc-eb7cc80bbc5dn%40googlegroups.com.


[go-nuts] Re: go build of a *_unix.go file still used under windows ?

2023-08-31 Thread Brian Candler
https://github.com/golang/go/issues/51572

On Thursday, 31 August 2023 at 08:57:15 UTC+1 Peter Galbavy wrote:

> I have used comment level build constraints for a while but I moved to 
> using _linux.go and _windows.go over time as it makes it clearer for 
> external viewing.
>
> A user reported they tried to build on MacOS and of course this didn't 
> work. I renamed the _linux.go files to _unix.go suffixes but then when I do 
> "GOOS=windows go build" those files were pulled in too. While I would say 
> Windows is a POSIX-ish system I would contend it's not UNIX :-)
>
> I have gone and added "//go:build !windows" to all the renamed files for 
> now, but is this intended behaviour?
>
> Peter
>

-- 
You received this message because you are subscribed to the Google 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/f9baed25-1414-4ac5-affc-ca1e8c2e0dedn%40googlegroups.com.


Re: [go-nuts] Re: wtf

2023-08-26 Thread Brian Candler
In both cases, the argument inside parenthesis is evaluated at the time 
"defer" is executed - as indeed is the value of "p".

In the first case, you wrote "defer p.close(err)".  Since err is nil at 
this point, at the end of the function body, p.close(nil) is called.

In the second case, you wrote "defer p.close(pt)" where pt is a pointer to 
some variable. Therefore, at the end of the function body, p.close(pt) is 
called, with the value of the pointer at that time.

Since in the second case you have a valid pointer to some data, then you 
can modify that data through the pointer. Note that if the pointer pt had 
changed, it would still be referring to the original value of pt, since 
that was captured at the time "defer" was called.

Maybe this clarifies?
https://go.dev/play/p/T2OXfmh-slj

On Saturday, 26 August 2023 at 16:37:43 UTC+1 Aln Kapa wrote:

> Well here is the code that works as I need, what is wrong with the 
> previous one ?
> https://go.dev/play/p/ZW-GmEP5uqu
>
> package main
>
> import (
>
> "fmt"
> )
>
> type process struct {
> }
>
> func (p *process) close(err any) {
> v, _ := err.(*int)
> if *v == 1 {
>
> fmt.Println("error")
> } else {
> fmt.Println("no error")
> }
> }
> func Handle(b bool) {
> p := process{}
> var i = 2
> var pt any = 
> defer func() {
> p.close(pt)
> }()
> if b {
> i = 1
>
> }
> }
>
> func HandleWTF(b bool) {
> p := process{}
> var i = 2
> var pt any = 
> defer p.close(pt)
> if b {
> i = 1
>
> }
> }
>
> func main() {
> Handle(true)// error
> Handle(false)   // no error
> HandleWTF(true) // error
> }
>
>
> On Sat, Aug 26, 2023 at 6:10 PM Brian Candler  wrote:
>
>> Any arguments to defer functions are evaluated at the time that the defer 
>> is executed.  In HandleWTF, defer p.close(err) is called immediately after 
>> err is declared with value nil, so nil is what is used.
>>
>> From the specification <https://go.dev/ref/spec#Defer_statements>:
>>
>> "Each time a "defer" statement executes, the function value and 
>> parameters to the call are evaluated as usual 
>> <https://go.dev/ref/spec#Calls> and saved anew but the actual function 
>> is not invoked."
>>
>> On Saturday, 26 August 2023 at 15:58:06 UTC+1 Aln Kapa wrote:
>>
>>> Hi All ! 
>>> Need some help, what am I doing wrong?
>>>
>>> https://go.dev/play/p/bBlA-i1CxNO
>>>
>>> // You can edit this code!
>>> // Click here and start typing.
>>> package main
>>>
>>> import (
>>> "errors"
>>> "fmt"
>>> )
>>>
>>> type process struct {
>>> }
>>>
>>> func (p *process) close(err error) {
>>> if err != nil {
>>> fmt.Println("error")
>>> } else {
>>> fmt.Println("no error")
>>> }
>>> }
>>> func Handle(b bool) {
>>> p := process{}
>>> var err error
>>> defer func() {
>>> p.close(err)
>>> }()
>>> if b {
>>> err = errors.New("err")
>>> }
>>> }
>>>
>>> func HandleWTF(b bool) {
>>> p := process{}
>>> var err error
>>> defer p.close(err)
>>> if b {
>>> err = errors.New("err")
>>> }
>>> }
>>>
>>> func main() {
>>> Handle(true)// error
>>> Handle(false)   // no error
>>> HandleWTF(true) // no error ?
>>> }
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/25846715-b3bf-4d1d-81b4-4a2799e69d27n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/25846715-b3bf-4d1d-81b4-4a2799e69d27n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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


[go-nuts] Re: wtf

2023-08-26 Thread Brian Candler
Any arguments to defer functions are evaluated at the time that the defer 
is executed.  In HandleWTF, defer p.close(err) is called immediately after 
err is declared with value nil, so nil is what is used.

>From the specification :

"Each time a "defer" statement executes, the function value and parameters 
to the call are evaluated as usual  and 
saved anew but the actual function is not invoked."

On Saturday, 26 August 2023 at 15:58:06 UTC+1 Aln Kapa wrote:

> Hi All ! 
> Need some help, what am I doing wrong?
>
> https://go.dev/play/p/bBlA-i1CxNO
>
> // You can edit this code!
> // Click here and start typing.
> package main
>
> import (
> "errors"
> "fmt"
> )
>
> type process struct {
> }
>
> func (p *process) close(err error) {
> if err != nil {
> fmt.Println("error")
> } else {
> fmt.Println("no error")
> }
> }
> func Handle(b bool) {
> p := process{}
> var err error
> defer func() {
> p.close(err)
> }()
> if b {
> err = errors.New("err")
> }
> }
>
> func HandleWTF(b bool) {
> p := process{}
> var err error
> defer p.close(err)
> if b {
> err = errors.New("err")
> }
> }
>
> func main() {
> Handle(true)// error
> Handle(false)   // no error
> HandleWTF(true) // no error ?
> }
>

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


Re: [go-nuts] does gonum insist on row-major?

2023-08-26 Thread Brian Candler
Could you explain the comment "all of Go is cm"?
https://go.dev/play/p/tDJiSTqsiSC

On Saturday, 26 August 2023 at 14:02:34 UTC+1 Dan Kortschak wrote:

> On Sat, 2023-08-26 at 13:45 +0100, Jason E. Aten wrote:
> > ah... there is documentation, it is just buried...
> > 
> > https://pkg.go.dev/gonum.org/v1/gonum/mat#section-readme
> > 
> > "All matrices are stored in row-major format and users should
> > consider this when expressing matrix arithmetic to ensure optimal
> > performance."
> > 
> > Seems odd not to allow both; since this is usually very important for
> > perf.
>
> The original Cgo code did allow both. The maintenance burden or
> providing both for the Go implementation would have been far too
> onerous, so the column-major implementation option was remove from the
> Cgo wrapper for parity.
>
> I don't think the docs are buried; that is the first place people will
> look in general.
>
> FWIW The choice between rm and cm is difficult; all of Go is cm. All of
> Fortran is cm (also any GPU code). We've had this discussion internally
> and probably if we did it again, we might have chosen cm, but then we'd
> get people complaining that they can't represent matrices in source
> easily.
>
> Dan
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5782b6e8-7e1c-4a7e-8982-6f39b217b866n%40googlegroups.com.


[go-nuts] Re: Using underscore in return statements - a small convenience idea

2023-08-23 Thread Brian Candler
Something similar is in the pipeline: 
https://github.com/golang/go/issues/61372

When implemented, it will be spelled "zero" rather than "_"

As I understand it, you'll still need to say 0, "" or nil where those are 
available for the type in question. Therefore in the f1() example you gave, 
you'll still need
return 0, errors.New("something went wrong")

-- 
You received this message because you are subscribed to the Google 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/a17439a0-39cd-4fe3-99d9-63238f4b990bn%40googlegroups.com.


[go-nuts] Re: how to constrain a type

2023-08-17 Thread Brian Candler
Then make a dummy interface, with a method with a unique name that you 
never call.

On Thursday, 17 August 2023 at 16:48:28 UTC+1 Mark wrote:

> Hi Brian,
> Sorry for not being clearer. Ideally I don't want an interface: each Shape 
> is essentially a store of different kinds of values so at some point I'm 
> going to iterate over them and within that iterating use a type switch. 
> This is because the shapes _don't_ know how to draw themselves but an 
> external function that reads them will know.
>
> On Thursday, August 17, 2023 at 4:35:10 PM UTC+1 Brian Candler wrote:
>
>> I'm not sure without knowing *how* you want to use []*Shape{}.  Perhaps 
>> you want Shape to be an interface?
>>
>> type Shape interface {
>> DrawMe()
>> }
>>
>> type BoxShape struct ...
>> func (*BoxShape) DrawMe() { }
>>
>> type LineShape struct ...
>> func (*LineShape) DrawMe() { }
>>
>> shapes := []Shape{}
>>
>> (Note that interfaces internally carry pointers, so you don't generally 
>> want to have pointers to interface types)
>>
>> On Thursday, 17 August 2023 at 13:44:10 UTC+1 Mark wrote:
>>
>>> Here's something that works but uses `any` which is too broad in scope:
>>> ```go
>>> type Shape any // Want to constrain to BoxShape and LineShape only
>>>
>>> type BaseShape struct {
>>> X int
>>> Y int
>>> PenColor  color
>>> PenWidth  int
>>> FillColor color
>>> }
>>>
>>> type BoxShape struct {
>>> BaseShape
>>> Width  int
>>> Height int
>>> }
>>>
>>> type LineShape struct {
>>> BaseShape
>>> X2 int
>>> Y2 int
>>> }
>>>
>>> shapes := []*Shape{}
>>> ```
>>> Is there a nice way to create a `Shape` type which will allow me to do 
>>> `shapes := []*Shape{}` and that _also_ constrains the shapes to `BoxShape` 
>>> and `LineShape`?
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/09798318-1a13-4570-a8a2-af6ccb3f0155n%40googlegroups.com.


[go-nuts] Re: how to constrain a type

2023-08-17 Thread Brian Candler
I'm not sure without knowing *how* you want to use []*Shape{}.  Perhaps you 
want Shape to be an interface?

type Shape interface {
DrawMe()
}

type BoxShape struct ...
func (*BoxShape) DrawMe() { }

type LineShape struct ...
func (*LineShape) DrawMe() { }

shapes := []Shape{}

(Note that interfaces internally carry pointers, so you don't generally 
want to have pointers to interface types)

On Thursday, 17 August 2023 at 13:44:10 UTC+1 Mark wrote:

> Here's something that works but uses `any` which is too broad in scope:
> ```go
> type Shape any // Want to constrain to BoxShape and LineShape only
>
> type BaseShape struct {
> X int
> Y int
> PenColor  color
> PenWidth  int
> FillColor color
> }
>
> type BoxShape struct {
> BaseShape
> Width  int
> Height int
> }
>
> type LineShape struct {
> BaseShape
> X2 int
> Y2 int
> }
>
> shapes := []*Shape{}
> ```
> Is there a nice way to create a `Shape` type which will allow me to do 
> `shapes := []*Shape{}` and that _also_ constrains the shapes to `BoxShape` 
> and `LineShape`?
>

-- 
You received this message because you are subscribed to the Google 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/b2d706b5-71f8-461f-ab5f-7da5b238ec17n%40googlegroups.com.


[go-nuts] Re: [rfc] build bug in type abstraction?

2023-08-16 Thread Brian Candler
On Wednesday, 16 August 2023 at 14:05:49 UTC+1 John Pritchard wrote: 

I have a disparity between "go run" [
https://go.dev/play/p/5mr5M0luZ9k?v=goprev] 
and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].  
Using go version 1.21.0.


I don't quite understand where "go run" comes into this.  In your Makefile 
, both 
options use "go build".

"make list" is doing something dubious:

go_sources := $(shell ls *.go)
...
list: main/main.go $(go_sources)
go build -o $@ $<

That is, I think you're trying to compile "main/main.go" and "types.go" at 
the same time into a single object file.  But types.go is "package types" 
whereas main.go is "package main".  That should give you an error; if it 
doesn't, that makes me suspect that go_sources is in fact empty.  The "make 
list" output you show in README.txt appears to confirm this:

$ make
go build -o list main/main.go# <<< note that no additional sources are 
listed on the command line

In main.go, there is a pretty clear error that the compiler calls out in 
line 46:
main/main.go:46:15: undefined: Abstract

The corresponding source line 
 
is:
var abstract Abstract = types.Init()

and as far as I can see, it's correct: you have no type "Abstract" in 
package main in main.go (in otherwise, you should be referring to 
"types.Abstract")


-- 
You received this message because you are subscribed to the Google 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/a0716bee-a6b9-4ea7-b4a7-165c4ef43fabn%40googlegroups.com.


[go-nuts] Re: What does `shallow clone` mean?

2023-08-14 Thread Brian Candler
On Friday, 11 August 2023 at 17:56:01 UTC+1 Shinya Sakae wrote:

I often hear the term `shallow copy', but I don't know what `shallow clone` 
means.


Don't worry: they are the same thing.

When cloning a map, the keys and values are set using ordinary assignment, 
as the description says.  It means there is no recursive cloning of nested 
structures.

For example: assignment of a map ends up with two values pointing at the 
*same* data structure:
https://go.dev/play/p/NzCII0hy92R
(that's why clone is needed in the first place: so you can 
add/update/delete to the clone, without affecting the source map)

Therefore, if you have an outer map containing inner maps as values, and 
you clone the outer map, the clone will still refer to the same inner maps.

-- 
You received this message because you are subscribed to the Google 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/27dac806-a1a8-42bd-bbe1-06d21a796eedn%40googlegroups.com.


[go-nuts] Re: How to convert an svg to a png (or gif) image?

2023-08-04 Thread Brian Candler
Also there's a project which compiles C code to Go - ISTR it was used to 
build a pure Go version of Sqlite.  Presumably the same approach could be 
applied to an image processing library.

https://twitter.com/bradfitz/status/855271867162083329?lang=en
https://groups.google.com/g/golang-nuts/c/QDEczMhlQBU/m/4lCn2kP0AwAJ
https://github.com/elliotchance/c2go

On Friday, 4 August 2023 at 11:58:19 UTC+1 Mandolyte wrote:

> and https://pkg.go.dev/github.com/canhlinh/svg2png
>
> On Friday, August 4, 2023 at 4:48:26 AM UTC-4 Mark wrote:
>
>> Thanks!
>>
>> On Friday, August 4, 2023 at 8:46:18 AM UTC+1 Tamás Gulácsi wrote:
>>
>>> https://pkg.go.dev/github.com/goki/gi/svg
>>>
>>> Mark a következőt írta (2023. augusztus 3., csütörtök, 13:18:48 UTC+2):
>>>
 I know this has been asked before, just wondered if there were any 
 pure-Go solutions?

>>>

-- 
You received this message because you are subscribed to the Google 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/c2523fb7-2308-4f77-ae60-56779c696402n%40googlegroups.com.


[go-nuts] Re: Any option to substitute plug-in package ?

2023-08-03 Thread Brian Candler
I believe Hashicorp's go-plugin was developed long before Go's stdlib 
plugin functionality was made available.

But they still use it. It's well established and tested, the architecture 
has security benefits, and it works cross-platform. It also makes it easier 
for plugins to be distributed by third parties: they don't have to be 
compiled with the exact same toolchain. In fact, they don't even have to be 
written in Go.

Of course, shared libraries will be much faster - so it depends on your use 
case, whether you need large volumes of low-latency calls.

If your production environment is Linux, and the only issue is around 
*development* under Windows, then you can look into WSL or virtual machines.

On Thursday, 3 August 2023 at 07:17:49 UTC+1 alex-coder wrote:

> Hi All,
>
> so, binary code plugin as a RPC - frankly, never thought about :-)
>
> What is written in go spec is a 
> >> dynamically discovering and loading *shared lib*
> as I see it but community developed much further
>
> Thank you.
>
> среда, 2 августа 2023 г. в 15:03:38 UTC+3, TheDiveO: 
>
>> It really depends on what you want to achieve...
>>
>>1. dynamically discovering *out-of-process* RPC plugins ... 
>>Hashicorp's might be the most famous one.
>>2. dynamically discovering and loading *shared lib *plugins ... this 
>>needs some plumbing above the pure stdlib plugin functionality. 
>> Personally, 
>>I find the shared libs to be finicky and haven't yet done a real project 
>>that needed this variant (but I wrote a go-plugger 
>> module as an example).
>>3. statically binary-builtin plugins: this actually is what I tend to 
>>use in several of my own projects, where there is no need for dynamically 
>>extending but instead to easily maintain and use a fixed set of "plugins" 
>>and that set of plugins tends to slowly grow. The plugin mechanism might 
>>help organizing, such as my own go-plugger 
>> supporting type-safe plugin 
>>APIs and ordering and iterating plugins at runtime. For instance, I use 
>>this mechanism to simplify adding new types to factories, or to 
>> "decorate" 
>>containers with additional labels, such as in Docker compose contexts, or 
>>k8s contexts, or ...
>>
>>
>> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>>
>>> Hi All !
>>> Plug-in package is very interesting, but in case the development under 
>>> windows it does not work,
>>> So, any hint to use some option instead will be highly appreciated.
>>>
>>> Thank you.
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/c3905d16-f759-42e1-a838-ee667a96e481n%40googlegroups.com.


Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

2023-08-02 Thread Brian Candler
s3 == []int{0, 0, 2, 3, 5, 7, 0, 0}

Therefore,
s3[3:6] is {3, 5, 7}   // from index 3 up to but not including 6
s3[2:] is {2, 3, 5, 7, 0, 0}  // from index 2 to end

Unless I'm missing something?

On Wednesday, 2 August 2023 at 17:59:06 UTC+1 Kamil Ziemian wrote:

> Hello,
>
> First, as I probably end my first reading of Go Spec in coming days, I 
> want to thank you all for helping me in that. Thank you. :)
>
> Second, I have question about example shown in section "Appending to and 
> copying slices".
>
> s0 := []int{0, 0}
> s1 := append(s0, 2)// append a single element s1 == 
> []int{0, 0, 2}
> s2 := append(s1, 3, 5, 7)  // append multiple elementss2 == 
> []int{0, 0, 2, 3, 5, 7}
> s3 := append(s2, s0...)// append a slice  s3 == 
> []int{0, 0, 2, 3, 5, 7, 0, 0}
> s4 := append(s3[3:6], s3[2:]...)   // append overlapping slices4 == 
> []int{3, 5, 7, 2, 3, 5, 7, 0, 0}
>
> I didn't understand why s4 looks that after append. I would guess that if 
> I call append(s3[3:6], s3[:2]...) (s3[2:] replaced by s3[:2]) it should 
> produce result above. But I don't think clearly recently, to much on my 
> head.
>
> Best regards,
> Kamil
>
> sobota, 29 lipca 2023 o 19:50:51 UTC+2 Kamil Ziemian napisał(a):
>
>> "The confusion may come from the fact that a list of forbidden built-in 
>> operations is immediately followed by a list of (mostly) allowed operations 
>> that illustrate the original rule?"
>> You hit the nail on the head.
>>
>> I don't have much faith in me as programmer, so I ask about any such 
>> issue that is bothering me.
>>
>> Best regards,
>> Kamil
>>
>> pt., 28 lip 2023 o 17:32 Brian Candler  napisał(a):
>>
>>> If you wanted to be absolutely clear, you could insert "The following 
>>> are examples of expression statements" - although it didn't really trouble 
>>> me as-is.
>>>
>>> On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:
>>>
>>>> The confusion may come from the fact that a list of forbidden built-in 
>>>> operations is immediately followed by a list of (mostly) allowed 
>>>> operations 
>>>> that illustrate the original rule? With the exception of "len", it may be 
>>>> more clear for it to be structure like:
>>>> ExpressionStmt = Expression .
>>>>
>>>> h(x+y)
>>>> f.Close()
>>>> <-ch
>>>> (<-ch)
>>>> len("foo") // illegal if len is the built-in function
>>>>
>>>> The following built-in functions are not permitted in statement 
>>>> context:
>>>> append cap complex imag len make new real
>>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof 
>>>> unsafe.Slice
>>>>
>>>> But, that leaves the "len" example with zero context upfront.
>>>>
>>>> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>>>>
>>>>> Note also, that you didn't paste the entire section:
>>>>>
>>>>> With the exception of specific built-in functions, function and method 
>>>>> calls and receive operations can appear in statement context. Such 
>>>>> statements may be parenthesized. […] The following built-in functions are 
>>>>> not permitted in statement context:
>>>>>
>>>>> This is IMO very clear about those other examples being allowed.
>>>>>
>>>>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner  
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> After a long break, I go back to reading Go Spec.
>>>>>>>
>>>>>>> In the section "Expression statements" we read that "The following 
>>>>>>> built-in functions are not permitted in statement context:
>>>>>>>
>>>>>>> append cap complex imag len make new real
>>>>>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>>>>>>>
>>>>>>> h(x+y)
>>>>>>> f.Close()
>>>>>>> <-ch
>>>>>>> (<-ch)
>>>

[go-nuts] Re: Any option to substitute plug-in package ?

2023-08-02 Thread Brian Candler
The plugin package is very limiting even under Linux: see this reddit post 
.

I suggest you look at hashicorp's go-plugin 
.  This takes a different approach: 
it spawns a separate process for each plugin, and talks to it over RPC.  
It's very robust: it's the plugin library used by their other products such 
as Vault.

On Wednesday, 2 August 2023 at 11:14:15 UTC+1 alex-coder wrote:

> Hi All !
> Plug-in package is very interesting, but in case the development under 
> windows it does not work,
> So, any hint to use some option instead will be highly appreciated.
>
> Thank you.
>

-- 
You received this message because you are subscribed to the Google 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/636677cb-dbc7-47d7-be6e-3fb978f3a56fn%40googlegroups.com.


Re: [go-nuts] Error handling

2023-08-02 Thread Brian Candler
FWIW, I'm in the "I like how it is now better than any other proposal so 
far" camp; I think this happens as you get used to the Go way. Go is Go.

The only thing I would consider is making *interface* types (only) 
implicitly usable in a boolean context, e.g.

if err { ... }

However, I suppose people would ask "why not pointers? why not channels?" 
etc.  I'm not suggesting it should become like Python where every non-zero 
value is treated as "true".  Interface values are special, and there's very 
little you can do with a nil interface (whereas for example, a nil pointer 
can still have methods called on it).  But this does add a special case, 
and Go already has its share of surprises you have to learn.

On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:

> Yes. Go is no longer the simple language it was. I suspect because of 
> internal pressures within Google as evidenced by multiple innovations that 
> seem to come from nowhere eg dir embedding and associated fs package that 
> duplicated perfectly good ways of doing things. The module system while 
> useful is quite complex. Generics and all the associated packages inflated 
> the mental burden of learning and reading Go code significantly. And having 
> the go 1 compatibility guarantee means that old stuff remains valid code 
> and must be learned too. 
>
> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:
>
>> Yeah.. I mean, the "idiom" `err != nil return` err is something of the 
>> language. I complain about the boilerplate that idiom produces and that is 
>> fact fact (no one can deny it).
>>
>> You know, your approach implies making the language a little more 
>> complicated as new ways to deal with errors appear. I do understand that 
>> some folks provide some push back on the idea simply because there is 
>> nothing wrong with the language right now regarding error handling. 
>>
>> As I see things, the language was simple in their origins, but from time 
>> to time they complicated a little more some things, for example "what about 
>> generics?"  (are they really necessary?, I mean... I think using interfaces 
>> provides all the genericity you may need). So I guess there is room to make 
>> some changes and make the language easier. I would say that both ways of 
>> handling errors are valid, the most important is to be as simple 
>> as possible so you ensure that other people understand it. Like Generics, 
>> you don't have to use them. So I would praise it for adding another way, 
>> less repetitive.
>>
>> Also like to see how people react and what their opinions are. So far 
>> what I read is just personal taste.
>>
>>
>> El mar, 1 ago 2023 a las 16:04, 'Luke Crook' via golang-nuts (<
>> golan...@googlegroups.com>) escribió:
>>
>>> And of course I forgot the "if" at the beginning of all those 
>>> conditional. *sigh*
>>>
>>> -- 
>>> 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/dRLR4hxxI8A/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/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> V
>>
>

-- 
You received this message because you are subscribed to the Google 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/11d57ab3-e7d8-4636-8ef7-6de64404bc54n%40googlegroups.com.


[go-nuts] Re: Error handling

2023-07-30 Thread Brian Candler
 err := io.Copy(w, r) *orelse* {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

My question still stands. Semantically, what value exactly does the 
"orelse" condition test is not equal to nil?

- does it test the value from the preceding assignment? If so, is "orelse" 
only valid immediately following an assignment expression? The original 
posting didn't say this.  And if it *is* linked to an assignment expression 
which assigns multiple values, does it only look at the last value? (Again, 
that was not specified)

- does it always test a variable called "err"? The original posting said it 
was equivalent to "if err!=nil" but a later post contradicted this

- does it test the value from the 'return' expression at the end of the 
block following orelse? Except in this case, it can't because it's buried 
inside fmt.Errorf

On Sunday, 30 July 2023 at 17:55:34 UTC+1 DrGo wrote:

> Good point Harri,
>
> This is what the correct version will look like using this proposal 
>
> func CopyFile(src, dst string) error {
> r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", src, 
> dst, err)
> defer r.Close()
>
> w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s: %v", 
> src, dst, err)
> err := io.Copy(w, r) *orelse* {
> w.Close()
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> err := w.Close() *orelse* {
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> }
>
> In a more complex func, the error formatting/handling code can be further 
> deduplicated by extracting it into a closure. 
> e.g., 
>
> func CopyFile(src, dst string) error {
> copyErr:= func(err error) {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> } 
> r, err := os.Open(src) *orelse* return copyErr(err) 
> defer r.Close()
>
> w, err := os.Create(dst); *orelse* return copyErr(err)
> err := io.Copy(w, r) *orelse* {
> w.Close()
> os.Remove(dst)
> return copyErr(err)
> }
>
> err := w.Close() *orelse* {
> os.Remove(dst)
> return copyErr(err)
> }
> }
>
> On Sunday, July 30, 2023 at 8:17:31 AM UTC-6 Harri L wrote:
>
>> IMHO, you have used the irrelevant example (== 2nd code block) from Russ 
>> Cox's paper. The paper says:
>> > This code is not nice, not clean, not elegant, *and still wrong:* like 
>> the previous version, it does not remove dst when io.Copy or w.Close
>>  fails.
>>
>> I want to compare your proposal with the third example from the paper, 
>> which does (proper) error annotation and cleanup. Thanks.
>> On Sunday, July 30, 2023 at 8:57:15 AM UTC+3 DrGo wrote:
>>
>>> I looked at the long list of proposals to improve error handling in go 
>>> but I have not seen the one I am describing below. If I missed a similar , 
>>> can you pls direct me to where I can find it. If not what do you think of 
>>> this approach. 
>>>
>>> This involves introducing a new keyword "orelse" that is a syntactic 
>>> sugar for an "if err!=nil" block.
>>>
>>> The example code in Russ Cox's paper[1] will look something like this:
>>>
>>> func CopyFile(src, dst string) error {
>>>
>>> r, err := os.Open(src) orelse return err 
>>>
>>> defer r.Close()
>>>
>>> w, err := os.Create(dst) orelse return err
>>>
>>> defer w.Close()
>>>
>>>   err = io.Copy(w, r) orelse return err
>>>
>>> err = w.Close() orelse return err
>>>
>>> }
>>>
>>> It is an error to not return an error from an orelse block.
>>>
>>> In my eyes, this has the same explicitness and flexibility of the 
>>> current style but is significantly less verbose. It permits ignoring the 
>>> error, returning it as is or wrapping it. Because orelse is not used for 
>>> any other purpose, it would be easy for reviewers and linters to spot lack 
>>> of error handling.  
>>>
>>> It also works well with named returns. e.g., 
>>>
>>> func returnsObjorErro() (obj Obj, err error) {
>>>
>>>   obj, err := createObj() orelse return  //returns nil and err
>>>
>>> } 
>>>
>>> otherwise orelse is like "else" so e.g., it can be followed by a block 
>>> if additional cleanup or error formatting etc is needed before returning, 
>>> eg 
>>> w, err := os.Create(dst) orelse {
>>>   
>>>   return err 
>>> }
>>>
>>> Similarity to "else" hopefully means that it is easy to learn. It is 
>>> obviously backward compatible  
>>>
>>> What do you think?
>>>
>>> [1] 
>>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/7f52cab8-7829-4e8e-9bf4-b1878c3bc7aen%40googlegroups.com.


[go-nuts] Re: Error handling

2023-07-30 Thread Brian Candler
Typo: should have said

var foo error
r, bar := os.Open(src) orelse return foo   // does this do "if foo != nil { 
return foo }" ??

On Sunday, 30 July 2023 at 10:20:12 UTC+1 Brian Candler wrote:

> On Sunday, 30 July 2023 at 09:40:25 UTC+1 DrGo wrote:
>
> orelse must return an error (ie satisfies the error interface); the 
> specific type and variable name do not matter.
>
>
> But how does "orelse" perform the check in the first place? Does it look 
> for the variable named in the return statement?
>
> var foo error
> r, bar := os.Open(src) orelse return foo   // does this do "if foo != nil 
> { return bar }" ??
>
> Also, you are explicitly allowing bare return.  In that case, does it look 
> at the return values in the function definition?  If the function returns 
> multiple values, how does it know which one?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0410013a-6036-4f06-9a8b-8900b8dd4765n%40googlegroups.com.


[go-nuts] Re: Error handling

2023-07-30 Thread Brian Candler
On Sunday, 30 July 2023 at 09:40:25 UTC+1 DrGo wrote:

orelse must return an error (ie satisfies the error interface); the 
specific type and variable name do not matter.


But how does "orelse" perform the check in the first place? Does it look 
for the variable named in the return statement?

var foo error
r, bar := os.Open(src) orelse return foo   // does this do "if foo != nil { 
return bar }" ??

Also, you are explicitly allowing bare return.  In that case, does it look 
at the return values in the function definition?  If the function returns 
multiple values, how does it know which one?

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


[go-nuts] Re: Error handling

2023-07-30 Thread Brian Candler


On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:

I looked at the long list of proposals to improve error handling in go but 
I have not seen the one I am describing below.


There is a meta-ticket here: https://github.com/golang/go/issues/40432

Under the section "Simplifications of if err != nil, to reduce boilerplate" 
I found a link to
https://github.com/golang/go/issues/32946
which seems very similar to yours, using keyword "onErr" after a semicolon, 
instead of "orelse".

if c, err := fn(); onErr { return 0, 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0ee7e166-9aac-402c-871c-5e143a606fdbn%40googlegroups.com.


[go-nuts] Re: Error handling

2023-07-30 Thread Brian Candler
Just to be clear: are you hard-coding the variable name "err" into the 
semantics of "orelse"?  That is, you can't assign the error return to a 
variable of any other name?

I disagree that this makes the job of linters any easier than it is today.  
For example, if you'd written

...

   err = io.Copy(w, r)

err = w.Close() orelse return err
}

then you'd still need to detect "value assigned but not used" in the linter 
(assuming it doesn't become *compulsory* to use "orelse" on any assignment 
to a variable called "err")

On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:

> I looked at the long list of proposals to improve error handling in go but 
> I have not seen the one I am describing below. If I missed a similar , can 
> you pls direct me to where I can find it. If not what do you think of this 
> approach. 
>
> This involves introducing a new keyword "orelse" that is a syntactic sugar 
> for an "if err!=nil" block.
>
> The example code in Russ Cox's paper[1] will look something like this:
>
> func CopyFile(src, dst string) error {
>
> r, err := os.Open(src) orelse return err 
>
> defer r.Close()
>
> w, err := os.Create(dst) orelse return err
>
> defer w.Close()
>
>   err = io.Copy(w, r) orelse return err
>
> err = w.Close() orelse return err
>
> }
>
> It is an error to not return an error from an orelse block.
>
> In my eyes, this has the same explicitness and flexibility of the current 
> style but is significantly less verbose. It permits ignoring the error, 
> returning it as is or wrapping it. Because orelse is not used for any other 
> purpose, it would be easy for reviewers and linters to spot lack of error 
> handling.  
>
> It also works well with named returns. e.g., 
>
> func returnsObjorErro() (obj Obj, err error) {
>
>   obj, err := createObj() orelse return  //returns nil and err
>
> } 
>
> otherwise orelse is like "else" so e.g., it can be followed by a block if 
> additional cleanup or error formatting etc is needed before returning, eg 
> w, err := os.Create(dst) orelse {
>   
>   return err 
> }
>
> Similarity to "else" hopefully means that it is easy to learn. It is 
> obviously backward compatible  
>
> What do you think?
>
> [1] 
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
>

-- 
You received this message because you are subscribed to the Google 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/330e88d9-8072-4614-ae56-8ce9c59517f3n%40googlegroups.com.


Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

2023-07-28 Thread Brian Candler
If you wanted to be absolutely clear, you could insert "The following are 
examples of expression statements" - although it didn't really trouble me 
as-is.

On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:

> The confusion may come from the fact that a list of forbidden built-in 
> operations is immediately followed by a list of (mostly) allowed operations 
> that illustrate the original rule? With the exception of "len", it may be 
> more clear for it to be structure like:
> ExpressionStmt = Expression .
>
> h(x+y)
> f.Close()
> <-ch
> (<-ch)
> len("foo") // illegal if len is the built-in function
>
> The following built-in functions are not permitted in statement 
> context:
> append cap complex imag len make new real
> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof 
> unsafe.Slice
>
> But, that leaves the "len" example with zero context upfront.
>
> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>
>> Note also, that you didn't paste the entire section:
>>
>> With the exception of specific built-in functions, function and method 
>> calls and receive operations can appear in statement context. Such 
>> statements may be parenthesized. […] The following built-in functions are 
>> not permitted in statement context:
>>
>> This is IMO very clear about those other examples being allowed.
>>
>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner  
>> wrote:
>>
>>>
>>>
>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  
>>> wrote:
>>>
 Hello,

 After a long break, I go back to reading Go Spec.

 In the section "Expression statements" we read that "The following 
 built-in functions are not permitted in statement context:

 append cap complex imag len make new real
 unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice

 h(x+y)
 f.Close()
 <-ch
 (<-ch)
 len("foo")  // illegal if len is the built-in function"

 Are things following "h(x+y)" also forbidden in the statement context? 
 This part of spec isn't specially clear in my opinion.

>>>
>>> No, they are not. Otherwise, they'd have a comment following them saying 
>>> "illegal for $reason".
>>>  
>>>

 Best regards,
 Kamil
 poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):

> Although the sentence is OK as it stands, the section should be 
> tweaked a bit. One of the examples there (myString(0x65e5)) is valid Go 
> but 
> vet rejects it, as part of the move towards disallowing this conversion, 
> which was there mostly for bootstrapping the libraries.
>
> -rob
>
>
> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Ah, the spec does actually say:
>>>
>>> Converting a signed or unsigned integer value to a string type 
>>> yields a string containing the UTF-8 representation of the integer. 
>>> Values 
>>> outside the range of valid Unicode code points are converted to 
>>> "\uFFFD".
>>
>>
>> Personally, I think this is fine as is. I think people understand 
>> what happens from these two sentences. 
>>
>> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner <
>> axel.wa...@googlemail.com> wrote:
>>
>>> I'm not entirely sure. I don't think your phrasing is correct, as it 
>>> doesn't represent what happens if the integer value exceeds the range 
>>> of 
>>> valid codepoints (i.e. if it needs more than 32 bits to represent). 
>>> That 
>>> being said, the sentence as is also isn't really precise about it. From 
>>> what I can tell, the result is not valid UTF-8 in any case.
>>>
>>> I think it might make sense to file an issue about this, though in 
>>> general that conversion is deprecated anyway and gets flagged by `go 
>>> vet` 
>>> (and `go test`) because it is not what's usually expected. So I'm not 
>>> sure 
>>> how important it is to get this exactly right and understandable.
>>>
>>>
>>> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian  
>>> wrote:
>>>
 I have some hair splitting question. In the "Conversions to and 
 from a string type" we read:
 "Converting a signed or unsigned integer value to a string type 
 yields a string containing the UTF-8 representation of the integer."

 Would it be more corrected to say, that conversion from integer to 
 string gives you UTF-8 representation of code point described by value 
 of 
 the integer? Or maybe it is indeed representation of integer described 
 by 
 UTF-8 specification?

 Best regards,
 Kamil
 czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian 
 napisał(a):

> Hello,
>
> From what I 

[go-nuts] Re: Possible Go Compiler or Runtime bug?

2023-07-27 Thread Brian Candler
Interesting:
https://play.golang.com/p/nSZ7tKSeot4

With the Printf commented out, it shows t has a cap of 32.  With Printf 
uncommented, the cap drops to 0.  Maybe the slice buffer is allocated on 
the stack in one case, and the heap on another?

The slice header of 24 bytes shouldn't have anything to do with this. The 
cap() of a slice relates to the amount of storage allocated for the data 
elements (which the header points to), not the space consumed by the header 
itself.

On Thursday, 27 July 2023 at 13:42:21 UTC+1 Brian Candler wrote:

> That looks very weird. The panic is triggered if I uncomment line 17 (the 
> final fmt.Printf) even though it never reaches there - it panics when 
> getStrBytes is called from line 9 (in line 23).
>
> On Thursday, 27 July 2023 at 13:12:40 UTC+1 Kyle Harrity wrote:
>
>> I first asked this on https://reddit.com/r/golang but the contribution 
>> guide on github recommends this forum, so I'll post here before finally 
>> raising an issue on github if this appears to be a real bug.
>>
>> ORIGINAL POST:
>>
>> I came across this issue in some code I was reviewing today where a 
>> string is converted into a []byte and then a 32 byte slice is taken from 
>> that and returned. It returns a 32 byte slice even if the string is empty 
>> or less than 32 bytes in length as long as its not a string literal (comes 
>> from a function or stored in variable). I can index the slice normally and 
>> iterate over its elements, but attempting to print it with fmt.Printf 
>> causes a runtime error where it realizes the capacity is not actually 32. 
>> Trying to get a slice larger than 32 fails though smaller slices are okay. 
>> I think that has something to do with the storage needed to describe a 
>> slice 8 bytes for memory location, 8 bytes for size, 8 bytes for capacity, 
>> 8 for padding as explained here: 
>> https://stackoverflow.com/questions/67839752/why-does-an-empty-slice-have-24-bytes
>>
>> Here's a playground demo: https://play.golang.com/p/yiLPvRYq8PJ 
>>
>> Maybe this is a known issue and or expected behavior so I thought I'd ask 
>> here before raising an issue on github.
>>
>

-- 
You received this message because you are subscribed to the Google 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/a5654b4d-304e-4cf9-b2d3-70e72b54132cn%40googlegroups.com.


[go-nuts] Re: Possible Go Compiler or Runtime bug?

2023-07-27 Thread Brian Candler
That looks very weird. The panic is triggered if I uncomment line 17 (the 
final fmt.Printf) even though it never reaches there - it panics when 
getStrBytes is called from line 9 (in line 23).

On Thursday, 27 July 2023 at 13:12:40 UTC+1 Kyle Harrity wrote:

> I first asked this on https://reddit.com/r/golang but the contribution 
> guide on github recommends this forum, so I'll post here before finally 
> raising an issue on github if this appears to be a real bug.
>
> ORIGINAL POST:
>
> I came across this issue in some code I was reviewing today where a string 
> is converted into a []byte and then a 32 byte slice is taken from that and 
> returned. It returns a 32 byte slice even if the string is empty or less 
> than 32 bytes in length as long as its not a string literal (comes from a 
> function or stored in variable). I can index the slice normally and iterate 
> over its elements, but attempting to print it with fmt.Printf causes a 
> runtime error where it realizes the capacity is not actually 32. Trying to 
> get a slice larger than 32 fails though smaller slices are okay. I think 
> that has something to do with the storage needed to describe a slice 8 
> bytes for memory location, 8 bytes for size, 8 bytes for capacity, 8 for 
> padding as explained here: 
> https://stackoverflow.com/questions/67839752/why-does-an-empty-slice-have-24-bytes
>
> Here's a playground demo: https://play.golang.com/p/yiLPvRYq8PJ 
>
> Maybe this is a known issue and or expected behavior so I thought I'd ask 
> here before raising an issue on github.
>

-- 
You received this message because you are subscribed to the Google 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/deff8771-ab58-43ee-b479-16c41d74582dn%40googlegroups.com.


[go-nuts] Re: Can a struct be made comparable?

2023-07-14 Thread Brian Candler
The 'diff' package you showed identifies the changed object index by means 
of a "Path" attribute in the Changelog entry. If the top level object is a 
slice, then Atoi(change.Path[0]) is the index into the slice.

On Friday, 14 July 2023 at 10:47:47 UTC+1 Mark wrote:

> Hi Brian,
> Your code certainly identifies the different items.
> However, that's not a diff tool in the sense I mean.
> Unix diff and tools like it don't just say x[i] != y[i], they find the 
> longest common subsequences and in essence produce a series of edit 
> commands that would turn slice x into slice y.
> There are quite a few go diff tools that will do this, including my own 
> <https://pkg.go.dev/github.com/mark-summerfield/go-diff> based on 
> Python's difflib sequence matcher.
> What I want to do is find one that does this for slices of structs where 
> only one struct field is considered for comparison purposes.
>
> On Friday, July 14, 2023 at 10:00:34 AM UTC+1 Brian Candler wrote:
>
>> I forgot you wanted generics:
>> https://go.dev/play/p/PhGVjsWWTdB
>>
>> On Friday, 14 July 2023 at 09:47:21 UTC+1 Brian Candler wrote:
>>
>>> You seem to be saying "if the S field is different then I want to 
>>> consider these two structs different, and get pointers to the two structs. 
>>> If the S field is the same then I want to skip the pair entirely". Is that 
>>> right?
>>>
>>> The required semantics are not entirely clear, but it sounds like a 
>>> handful of lines of code to implement - there's no point importing and 
>>> learning a third party library.
>>>
>>> On the assumption that all the elements to be compared are in 
>>> corresponding positions in a and b:
>>> https://go.dev/play/p/Y71sLUpftzR
>>>
>>> On Friday, 14 July 2023 at 09:11:35 UTC+1 Mark wrote:
>>>
>>>> In fact the diff pkg mentioned above does work but is of no use to me 
>>>> since for each change it gives back only the field(s) used, not the 
>>>> original structs (or pointers to them), so I can't see any way back to the 
>>>> original structs (or their slice indexes).
>>>>
>>>> On Friday, July 14, 2023 at 8:58:41 AM UTC+1 Mark wrote:
>>>>
>>>>> What I really want to do is to be able to diff slices of structs on 
>>>>> the basis of one single field.
>>>>> For example, given:
>>>>> ```
>>>>> type Item struct {
>>>>>   I int
>>>>>   S string
>>>>> }
>>>>> ```
>>>>> and given `a` and `b` are both of type`[]Item`, I want to diff these 
>>>>> slices based purely on the `S` field, ignoring the `I` field.
>>>>>
>>>>> This diff pkg <https://pkg.go.dev/github.com/r3labs/diff/v3> claims 
>>>>> to be able to do this (something I'm testing, so I don't know either way 
>>>>> yet), but in any case, it is incredibly slow.
>>>>>
>>>>> On Friday, July 14, 2023 at 8:31:39 AM UTC+1 Peter Galbavy wrote:
>>>>>
>>>>>> As a slight digression - I thought I was going mad, but 'slices' and 
>>>>>> 'maps' are new :-) Only in 1.21 though...
>>>>>>
>>>>>> Well, there is a lot of boiler plate that maps.Keys() will get rid of.
>>>>>>
>>>>>> On Thursday, 13 July 2023 at 10:06:01 UTC+1 Brian Candler wrote:
>>>>>>
>>>>>>> Structs are already comparable, but all fields must be the same:
>>>>>>> https://go.dev/play/p/XwhSz4DEDwL
>>>>>>>
>>>>>>> I think your solution with function 'eq' is fine.  You can see the 
>>>>>>> same thing in the standard library in slices.CompactFunc and 
>>>>>>> slices.EqualFunc
>>>>>>> https://pkg.go.dev/slices#CompactFunc
>>>>>>> https://pkg.go.dev/slices#EqualFunc
>>>>>>>
>>>>>>> For the case of "ordered" rather than "comparable", have a look at 
>>>>>>> slices.BinarySearchFunc and related functions.
>>>>>>>
>>>>>>> On Thursday, 13 July 2023 at 09:29:38 UTC+1 Mark wrote:
>>>>>>>
>>>>>>>> I have a package which has a function `Do[T comparable](a, b []T) 
>>>>>>>> Result`.
>>>>>>>> I have a struct:
>>>>>>>> ```go
>>>>>>>> type N struct {
>>>>>>>>   x int
>>>>>>>>   y int
>>>>>>>>   t string
>>>>>>>> }
>>>>>>>> ```
>>>>>>>> Is it possible to make `N` comparable; in particular by a field of 
>>>>>>>> my choice, e.g., `t`?
>>>>>>>>
>>>>>>>> Or will I have to make, say, `DoFunc(a, b []N, eq func(i, j N) 
>>>>>>>> bool) Result` with, say,
>>>>>>>> `func eq(i, j N) { return i.t == j.t }`?
>>>>>>>>
>>>>>>>

-- 
You received this message because you are subscribed to the Google 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/5cc6237b-1dcc-49f8-b426-69edf2405484n%40googlegroups.com.


[go-nuts] Re: Can a struct be made comparable?

2023-07-14 Thread Brian Candler
I forgot you wanted generics:
https://go.dev/play/p/PhGVjsWWTdB

On Friday, 14 July 2023 at 09:47:21 UTC+1 Brian Candler wrote:

> You seem to be saying "if the S field is different then I want to consider 
> these two structs different, and get pointers to the two structs. If the S 
> field is the same then I want to skip the pair entirely". Is that right?
>
> The required semantics are not entirely clear, but it sounds like a 
> handful of lines of code to implement - there's no point importing and 
> learning a third party library.
>
> On the assumption that all the elements to be compared are in 
> corresponding positions in a and b:
> https://go.dev/play/p/Y71sLUpftzR
>
> On Friday, 14 July 2023 at 09:11:35 UTC+1 Mark wrote:
>
>> In fact the diff pkg mentioned above does work but is of no use to me 
>> since for each change it gives back only the field(s) used, not the 
>> original structs (or pointers to them), so I can't see any way back to the 
>> original structs (or their slice indexes).
>>
>> On Friday, July 14, 2023 at 8:58:41 AM UTC+1 Mark wrote:
>>
>>> What I really want to do is to be able to diff slices of structs on the 
>>> basis of one single field.
>>> For example, given:
>>> ```
>>> type Item struct {
>>>   I int
>>>   S string
>>> }
>>> ```
>>> and given `a` and `b` are both of type`[]Item`, I want to diff these 
>>> slices based purely on the `S` field, ignoring the `I` field.
>>>
>>> This diff pkg <https://pkg.go.dev/github.com/r3labs/diff/v3> claims to 
>>> be able to do this (something I'm testing, so I don't know either way yet), 
>>> but in any case, it is incredibly slow.
>>>
>>> On Friday, July 14, 2023 at 8:31:39 AM UTC+1 Peter Galbavy wrote:
>>>
>>>> As a slight digression - I thought I was going mad, but 'slices' and 
>>>> 'maps' are new :-) Only in 1.21 though...
>>>>
>>>> Well, there is a lot of boiler plate that maps.Keys() will get rid of.
>>>>
>>>> On Thursday, 13 July 2023 at 10:06:01 UTC+1 Brian Candler wrote:
>>>>
>>>>> Structs are already comparable, but all fields must be the same:
>>>>> https://go.dev/play/p/XwhSz4DEDwL
>>>>>
>>>>> I think your solution with function 'eq' is fine.  You can see the 
>>>>> same thing in the standard library in slices.CompactFunc and 
>>>>> slices.EqualFunc
>>>>> https://pkg.go.dev/slices#CompactFunc
>>>>> https://pkg.go.dev/slices#EqualFunc
>>>>>
>>>>> For the case of "ordered" rather than "comparable", have a look at 
>>>>> slices.BinarySearchFunc and related functions.
>>>>>
>>>>> On Thursday, 13 July 2023 at 09:29:38 UTC+1 Mark wrote:
>>>>>
>>>>>> I have a package which has a function `Do[T comparable](a, b []T) 
>>>>>> Result`.
>>>>>> I have a struct:
>>>>>> ```go
>>>>>> type N struct {
>>>>>>   x int
>>>>>>   y int
>>>>>>   t string
>>>>>> }
>>>>>> ```
>>>>>> Is it possible to make `N` comparable; in particular by a field of my 
>>>>>> choice, e.g., `t`?
>>>>>>
>>>>>> Or will I have to make, say, `DoFunc(a, b []N, eq func(i, j N) bool) 
>>>>>> Result` with, say,
>>>>>> `func eq(i, j N) { return i.t == j.t }`?
>>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google 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/e15b25de-afc5-47fe-9fb1-37ae6c8446ccn%40googlegroups.com.


[go-nuts] Re: Can a struct be made comparable?

2023-07-14 Thread Brian Candler
You seem to be saying "if the S field is different then I want to consider 
these two structs different, and get pointers to the two structs. If the S 
field is the same then I want to skip the pair entirely". Is that right?

The required semantics are not entirely clear, but it sounds like a handful 
of lines of code to implement - there's no point importing and learning a 
third party library.

On the assumption that all the elements to be compared are in corresponding 
positions in a and b:
https://go.dev/play/p/Y71sLUpftzR

On Friday, 14 July 2023 at 09:11:35 UTC+1 Mark wrote:

> In fact the diff pkg mentioned above does work but is of no use to me 
> since for each change it gives back only the field(s) used, not the 
> original structs (or pointers to them), so I can't see any way back to the 
> original structs (or their slice indexes).
>
> On Friday, July 14, 2023 at 8:58:41 AM UTC+1 Mark wrote:
>
>> What I really want to do is to be able to diff slices of structs on the 
>> basis of one single field.
>> For example, given:
>> ```
>> type Item struct {
>>   I int
>>   S string
>> }
>> ```
>> and given `a` and `b` are both of type`[]Item`, I want to diff these 
>> slices based purely on the `S` field, ignoring the `I` field.
>>
>> This diff pkg <https://pkg.go.dev/github.com/r3labs/diff/v3> claims to 
>> be able to do this (something I'm testing, so I don't know either way yet), 
>> but in any case, it is incredibly slow.
>>
>> On Friday, July 14, 2023 at 8:31:39 AM UTC+1 Peter Galbavy wrote:
>>
>>> As a slight digression - I thought I was going mad, but 'slices' and 
>>> 'maps' are new :-) Only in 1.21 though...
>>>
>>> Well, there is a lot of boiler plate that maps.Keys() will get rid of.
>>>
>>> On Thursday, 13 July 2023 at 10:06:01 UTC+1 Brian Candler wrote:
>>>
>>>> Structs are already comparable, but all fields must be the same:
>>>> https://go.dev/play/p/XwhSz4DEDwL
>>>>
>>>> I think your solution with function 'eq' is fine.  You can see the same 
>>>> thing in the standard library in slices.CompactFunc and slices.EqualFunc
>>>> https://pkg.go.dev/slices#CompactFunc
>>>> https://pkg.go.dev/slices#EqualFunc
>>>>
>>>> For the case of "ordered" rather than "comparable", have a look at 
>>>> slices.BinarySearchFunc and related functions.
>>>>
>>>> On Thursday, 13 July 2023 at 09:29:38 UTC+1 Mark wrote:
>>>>
>>>>> I have a package which has a function `Do[T comparable](a, b []T) 
>>>>> Result`.
>>>>> I have a struct:
>>>>> ```go
>>>>> type N struct {
>>>>>   x int
>>>>>   y int
>>>>>   t string
>>>>> }
>>>>> ```
>>>>> Is it possible to make `N` comparable; in particular by a field of my 
>>>>> choice, e.g., `t`?
>>>>>
>>>>> Or will I have to make, say, `DoFunc(a, b []N, eq func(i, j N) bool) 
>>>>> Result` with, say,
>>>>> `func eq(i, j N) { return i.t == j.t }`?
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google 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/e3bae2b0-6f0b-4302-b7e3-04103954d361n%40googlegroups.com.


[go-nuts] Re: Can a struct be made comparable?

2023-07-13 Thread Brian Candler
Structs are already comparable, but all fields must be the same:
https://go.dev/play/p/XwhSz4DEDwL

I think your solution with function 'eq' is fine.  You can see the same 
thing in the standard library in slices.CompactFunc and slices.EqualFunc
https://pkg.go.dev/slices#CompactFunc
https://pkg.go.dev/slices#EqualFunc

For the case of "ordered" rather than "comparable", have a look at 
slices.BinarySearchFunc and related functions.

On Thursday, 13 July 2023 at 09:29:38 UTC+1 Mark wrote:

> I have a package which has a function `Do[T comparable](a, b []T) Result`.
> I have a struct:
> ```go
> type N struct {
>   x int
>   y int
>   t string
> }
> ```
> Is it possible to make `N` comparable; in particular by a field of my 
> choice, e.g., `t`?
>
> Or will I have to make, say, `DoFunc(a, b []N, eq func(i, j N) bool) 
> Result` with, say,
> `func eq(i, j N) { return i.t == j.t }`?
>

-- 
You received this message because you are subscribed to the Google 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/a697e28e-4d38-4c1a-b0b7-dccecb1c4309n%40googlegroups.com.


[go-nuts] Re: Issue with integration test coverage

2023-07-11 Thread Brian Candler
Why are you using kill -9?  That doesn't allow the process any time to tidy 
up whilst exiting.

But also see https://go.dev/testing/coverage/#FAQ

"If my program panics, will coverage data be written?

Programs built with go build -cover will only write out complete profile 
data at the end of execution if the program invokes os.Exit() or returns 
normally from main.main. If a program terminates in an unrecovered panic, 
or if the program hits a fatal exception (such as a segmentation violation, 
divide by zero, etc), profile data from statements executed during the run 
will be lost."

On Tuesday, 11 July 2023 at 14:17:18 UTC+1 savita juyal wrote:

> Hello All,
>
> I am trying to collect integration test coverage but its not generating 
> covcounters file. Please looks steps I am following to generate covearge.
>
> - *Build go binary* : go build -race -*cover* -o 
> $(ROOT)/go/bin/appwithrace -ldflags "-X app/handler.proxyVersion=$(VERSION) 
> -X app/handler.gitVersion=$(GITVERSION) -X 
> app/handler.buildTime=$(BUILDTIME)" cmd/proxy/proxy.go
>
> - *Run go binary* : ENABLE_TLS=false ENABLE_TLS_TO_DB=false 
> LOAD_BALANCED=false *GOCOVERDIR=./coverage/int *./go/bin/appwithrace 2>&1 
> >/dev/null &
>
> - *Exit go program* : Kill -9 go_process_id
>
> Now we only covmetadata file generated under the given path. Please me 
> know what I am doing wrong or if I am missing something?
>
> Regards
> Savita Juyal
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google 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/83281291-dda6-4a30-8989-1d7157e8e757n%40googlegroups.com.


[go-nuts] Re: How to run extra routine for http server properly ?

2023-07-07 Thread Brian Candler
If it's an important business task which needs to take place even if the 
machine crashes, then maybe you want to post a request into a persistent 
message queue (e.g. NATS, Kafka) before returning to the user.

The task can then be picked up by a separate worker process.

On Friday, 7 July 2023 at 08:58:03 UTC+1 alex-coder wrote:

> Yes, the question is set too broadly, it is necessary to specify the 
> context, 
> thank you.
>
> четверг, 6 июля 2023 г. в 02:33:18 UTC+3, ben...@gmail.com: 
>
>> For simple things, you can fire up a goroutine to do the "something else" 
>> after the request finishes. For example, I've used this before to kick off 
>> sending an email to a customer in the background (you'll want to 
>> handle/report errors somehow though):
>>
>> package main
>>
>> import (
>> "fmt"
>> "log"
>> "net/http"
>> "time"
>> )
>>
>> func main() {
>> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
>> fmt.Fprint(w, "sending email in the background")
>> go sendEmail()
>> // response is sent, but sendEmail goroutine continues
>> })
>> log.Print("listening on http://localhost:8080;)
>> http.ListenAndServe(":8080", nil)
>> }
>>
>> func sendEmail() {
>> log.Printf("would send an email here")
>> time.Sleep(time.Second)
>> log.Printf("done sending email")
>> }
>>
>> On Thursday, July 6, 2023 at 2:03:47 AM UTC+12 alex-coder wrote:
>>
>> Hi All !
>>
>> So, http server looks like is a request / response processing.
>> But in case it is nesessary to do something else after the response has 
>> been sent to the client, how to do it properly ?
>> Is there any example to read ?
>>
>> Thank you.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google 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/b0f2eb59-a375-46de-bdb4-85b3c9c75cf9n%40googlegroups.com.


Re: [go-nuts] Go 1.21 new builtin function clear()

2023-07-06 Thread Brian Candler
In principle I agree with the sentiment, in the sense this is what you'd 
expect from other languages like Python.

However, slices are fundamentally different to maps in Go. Map values 
contain a pointer to a mutable data structure (that's why you can't insert 
into a zero map - you have to allocate the structure first).  Slices are 
structs that contain ptr/len/cap which are never mutated (although the data 
elements pointed to by ptr may mutate, of course).  To alter the len or cap 
you have to create a new slice value to replace the old one. e.g.

a := []int{1,2,3}
a = a[0:0]   // "clear"

So an in-place "clear" of a slice in the way you suggest, which alters the 
existing len to zero, would have to take a pointer to a slice, not a plain 
slice value.

TBH, I don't see the point of the new clear(slice) function.  It clears 
values up to len, not to cap:
https://go.dev/play/p/1N27HXHpEdZ?v=gotip

In which case, you might as well just write:
var z T  // zero value
for i := 0; i < len(a); i++ {
a[i] = z
}

I've never felt the need to do this - certainly not enough to warrant a 
built-in function.  (I would allocate a new slice, and let the garbage 
collector deal with the old one)

On Thursday, 6 July 2023 at 08:41:25 UTC+1 Henry wrote:

> 'make' allocates the required memory. 'len' returns the length. 'cap' 
> returns the capacity. The underlying implementation may be different, but 
> the concept is the same. There is no issue with those. 
>
> It is common for a collection to have methods such as 'Add', 'Delete', and 
> 'Clear'. The common interpretation of clearing a collection means removing 
> all items from the collection and setting its length to zero. Clear works 
> like that with map, but it does differently with slice. I would not say 
> replacing the values in a slice with the default values as clearing. Maybe 
> you can call that zeroing, but that's not clearing. Many people would 
> expect after calling 'Clear(slice)' then the slice length should be zero.  
> That's why I think the function is incoherent. 
>
> On Thursday, July 6, 2023 at 1:17:39 PM UTC+7 Axel Wagner wrote:
>
>> Oh and FWIW: You are right (in my opinion) that the different things 
>> `clear` does are, well, different. But note that clear is not the only 
>> builtin for which that is the case. `make`, `len` and `cap` all do 
>> different things (to varying degrees) on maps, slices and channels.
>> That's not necessarily a good reason to add more builtins that do 
>> different things, but there is precedent.
>>
>> On Thu, Jul 6, 2023 at 8:14 AM Axel Wagner  
>> wrote:
>>
>>> On Thu, Jul 6, 2023 at 7:49 AM Henry  wrote:
>>>
 So, if I get this right, clear on map will result in map length equals 
 to zero, but clear on slice is only a value-zeroing operation and the 
 slice 
 length remains unchanged?
>>>
>>>
>>> That understanding is correct.
>>>  
>>>
 They seem like two different operations to me. I don't think that 
 built-in clear function is necessary. It doesn't seem like the function 
 has 
 a good reason to be there.

>>>
>>> There is one thing that `clear` allows which is impossible without it 
>>> and that's removing irreflexive keys (those that contain floating point 
>>> types/elements/fields which are NaN) from a map.
>>>
>>> Whether that's a "good" reason is up for debate, of course. There has 
>>> been quite a bit of that in the issue already: 
>>> https://github.com/golang/go/issues/56351
>>>  
>>>

 On Wednesday, July 5, 2023 at 3:54:43 PM UTC+7 Tharaneedharan 
 Vilwanathan wrote:

> Hi Axel,
>
> Okay, that helps! Thanks for the details.
>
> Regards
> dharani
>
>
> On Wed, Jul 5, 2023 at 1:38 AM Axel Wagner  
> wrote:
>
>> Hi,
>>
>> this has come up on the issue as well. Robert Griesemer provided an 
>> explanation 
>> :
>>
>> If the argument type (the type of the argument provided to clear) is 
>>> a type parameter (is of type parameter type), all types in its type set 
>>> (in 
>>> the type set of the constraint corresponding to the type parameter) 
>>> must be 
>>> maps or slices, and clear performs the operation corresponding to the 
>>> actual type argument (corresponding to the type of the actual type 
>>> argument 
>>> with which the type parameter was instantiated).
>>
>>
>> That is, the sentence is about this situation:
>>
>> func Clear[T, any, S ~[]T](s S) {
>> clear(s)
>> }
>> func main() {
>> Clear(make([]int, 42))
>> }
>>
>> In this case, the type of s is S, which is a type parameter. So 
>> `clear` performs the operation corresponding to the type argument - in 
>> this 
>> example []int.
>>
>> The sentence is a bit confusing (I've seen this question come up four 
>> times now), so it 

Re: [go-nuts] how to close a child process after father process be killed

2023-07-05 Thread Brian Candler
> Is there any way to create a child process that is detached from the 
original cgroup using exec.Command?
> I don't want my child process to be killed when the parent process dies.

This might be an issue with process groups, not cgroups, in which case I 
think Setsid is what you want, something like (untested):

p.theCommand.SysProcAttr = {Setsid: true}
err := p.theCommand.Start()

I had a related problem: I wanted to make sure that when a timeout occurs, 
I forcibly kill the child process and all its descendants. Solution was to 
use Setsid, and then send the signal to the newly-formed process group:
https://groups.google.com/g/golang-nuts/c/V1VccYYCp9o/m/rZRfhP_bCAAJ

-- 
You received this message because you are subscribed to the Google 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/16e02502-c948-4261-aabb-845bc234430fn%40googlegroups.com.


[go-nuts] Re: how to diagnose slow build

2023-06-29 Thread Brian Candler
What platform are you building under - in particular, is it Windows?

On Thursday, 29 June 2023 at 13:11:07 UTC+1 王富民awaw wrote:

> My builds have been very slow recently and I want to know why is `go 
> build` so slow for me.
> Is it due to reading disks or something else?
>
> What is the recommended way of profiling/debugging `go build`?
>
> I know that the `-x` flag prints detailed information of `go build` but it 
> doesn't tell where is time spent.
> I am familiar with profiling ordinary Go programs with pprof, but how can 
> I apply it to `go build`.
> An extensive search returned very few information as it hard to come up 
> with a query for profiling `go build`, not profiling ordinary Go programs 
> nor info about the `build` command itself.
>
> 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/c29d8b4f-9f0e-4887-98a9-137166cc9debn%40googlegroups.com.


Re: [go-nuts] Unexpected circular type definition limitation

2023-06-15 Thread Brian Candler
> You can always solve name spacing issues by splitting it up into separate 
packages.

Or type aliases:
https://go.dev/play/p/Slhgs8SLyo6

On Thursday, 15 June 2023 at 09:47:39 UTC+1 Axel Wagner wrote:

> Type declarations in functions are only scoped from the point of their 
> declaration until the end of the function.
> So the reason you can not do the recursive type definition in a function 
> is that at the point of the first declaration, the second is not yet in 
> scope.
> Package scoped declarations are different from function scoped 
> definitions, because in a function, you have a notion of "progress" - one 
> statement comes after the next. At the package scope, that isn't he case. 
> All package scoped declarations are "simultaneous", in a sense. That was 
> intentional, to avoid an issue C has, where you have to sometimes declare a 
> function before separately, to get mutual recursion.
>
> I think it would have been possible to make type declarations apply to the 
> entire function scope. But that wouldn't even solve the entire issue - for 
> example, you run into a similar problem when defining recursive functions 
> locally. Python does actually solve this by making every declaration apply 
> to the entire function scope - but that has its own surprises. Either way, 
> it's a decision that was made and we can't really reverse it now, as it 
> would break existing code. For example, you can do this today:
>
> func F(x int) {
> x = 42
> type x string
> var y x
> }
>
> which would presumably break.
>
> Ultimately, you just have to bite the bullet here and define your types at 
> package scope. You can always solve name spacing issues by splitting it up 
> into separate packages.
>
> On Thu, Jun 15, 2023 at 10:32 AM Christophe Meessen <
> christoph...@gmail.com> wrote:
>
>> The following playground example shows the problem:
>>
>> https://go.dev/play/p/1kC2j57M_fW
>>
>>
>> Le 15/06/2023 à 10:28, Jan Mercl a écrit :
>> > On Thu, Jun 15, 2023 at 10:16 AM christoph...@gmail.com
>> >  wrote:
>> >
>> >> It is possible to define two structures globally with mutual type 
>> dependency as this:
>> >>
>> >> type A struct {
>> >>  B []B
>> >> }
>> >>
>> >> type B struct {
>> >>  A A[]
>> >> }
>> >>
>> >> but I just noticed that we can't do that inside a function:
>> >>
>> >> func Foo() {
>> >>  type A struct {
>> >>  B []B
>> >>  }
>> >>
>> >>  type B struct {
>> >> A A[]
>> >>  }
>> >> }
>> >>
>> >> Is there a reason for this limitation ?
>> > Syntax error: https://go.dev/play/p/ZOGyZyQDW0I
>>
>> -- 
>> Bien cordialement,
>> Ch.Meessen
>>
>> -- 
>> You received this message because you are subscribed 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/801e7e6b-d3f8-c1df-8eae-46aa619d49a5%40gmail.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/38adb9bf-ddc7-49e0-bad2-1a72b3a8c849n%40googlegroups.com.


[go-nuts] Re: tool for ast graph visualization

2023-06-14 Thread Brian Candler
Aside: draw.io also has functionality like graphviz for the web 2.0 
generation:
https://drawio-app.com/blog/automatically-create-draw-io-diagrams-from-csv-files/

On Wednesday, 14 June 2023 at 10:01:10 UTC+1 Vraj Reshamdalal wrote:

> Hi alex-coder!
> You can try using Graphviz.
> Graphviz (https://graphviz.org/) is a powerful open-source graph 
> visualization software. It provides a collection of tools for visualizing 
> and manipulating graph structures (such as AST graphs).
>
> To generate and visualize a graph using Graphviz, you can follow these 
> steps:
>
>1. Create a DOT output file (e.g., graph.dot).
>2. Write the graph structure in the DOT language. For example, you can 
>use the following code:
>digraph G {
>Node1 [label="C"];
>Node2 [label="D"];
>Node3 [label="d"];
>Node4 [label="f"];
>Node1 -> Node2;
>Node2 -> Node3;
>Node3 -> Node4;
>}
>3. Save the file as *graph.dot*
>4. Open your command-line interface and navigate to the directory 
>where graph.dot is located.
>5. Use the *dot* command from Graphviz to generate an image file. Run 
>the following command: ` dot -Tpng graph.dot -o graph.png `
>This command specifies that the input file is graph.dot, the output 
>format is PNG (-Tpng flag), and the output file name is graph.png (-o 
>graph.png flag).
>6. *graph.png* will be generated in the same directory. This file will 
>contain the visual representation of the graph based on the DOT 
> description.
>
>
> Thanks,
> Vraj
> On Wednesday, June 14, 2023 at 2:44:37 AM UTC+5:30 alex-coder wrote:
>
>> Hi All !
>>
>> Could you please advice me a tool to visualize an ast graph.
>>
>> Thank you.
>>
>

-- 
You received this message because you are subscribed to the Google 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/05182cba-c026-463a-8fc4-12a3e74beb36n%40googlegroups.com.


Re: [go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-12 Thread Brian Candler
On Monday, 12 June 2023 at 07:55:24 UTC+1 Brian Candler wrote:

I don't know if it's possible to use 'reflect' to build the struct type 
dynamically


FWIW, I tried it, but could only make a program which crashes spectacularly.
https://go.dev/play/p/BIFFT3FgUrz
 
There is a comment in the documentation of reflect.StructOf 
<https://pkg.go.dev/reflect#StructOf> which may or may not be relevant:
*StructOf currently does not generate wrapper methods for embedded fields 
and panics if passed unexported StructFields. These limitations may be 
lifted in a future version.*

-- 
You received this message because you are subscribed to the Google 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/1865cc1f-503a-4f58-bcd3-b7bb044aaf60n%40googlegroups.com.


Re: [go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-12 Thread Brian Candler
If runtime is a problem, then you could use a lookup table.  Suppose you 
have (say) 10 possible interfaces in the object: then you test those ten, 
build a 10-bit binary number from the 'ok' values, and use this as an index 
into 2^10 possible constructor functions.

You still need to compile those 2^10 functions though, each of which has a 
different struct type. I don't know if it's possible to use 'reflect' to 
build the struct type dynamically; if you can, I know you could create an 
instance of it dynamically.
https://medium.com/kokster/go-reflection-creating-objects-from-types-part-ii-composite-types-69a0e8134f20

Otherwise, I'd check for interfaces where you can safely provide a dummy 
implementation: Resetter, Validator, Pinger are good examples. For those, 
you can do what Tamás suggested: always provide an implementation in your 
wrapper object, and then if the underlying object doesn't have one, just do 
nothing and return OK. Even if you only handle those three, you'll speed up 
your compile time and runtime by a factor of 8.

On Sunday, 11 June 2023 at 20:56:14 UTC+1 Vasiliy Tolstov wrote:

> Yes, you are right. Mostly i'm worry about compile/run time. As i see on 
> my mac air m1 compilation on go 1.20 slowdown to 1-2s (i think because file 
> parsing) 
> And don't know about running time of such checks for many interface 
> implementations...
> I'm try to check in number of interfaces in descending order... But don't 
> understand how this can be optimized... May be run profile with all known 
> sql drivers and create pairs with most used combinations ?
>
> -- 
> Vasiliy Tolstov,
> e-mail: v.to...@selfip.ru
>
>
> На 11 июня 2023 г., 19:31:01, Brian Candler  написали:
>
>> I think the issue is that the *consumer* of this object checks whether 
>> certain methods (or rather, interfaces) are present, and behaves 
>> differently depending whether they are or not.
>>
>> There are a whole load of public interfaces defined here:
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/driver/driver.go
>> And the supplied object, which the OP is trying to wrap, could implement 
>> some arbitrary combination of these interfaces.
>>
>> I think that for *some* of these interfaces, it would be OK to provide 
>> dummy implementations if there is no underlying method to call: e.g.
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=552-554
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=567-569
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=834-838
>>
>> But for others it's much less clear, and it may make a semantic 
>> difference whether the the object you provide implements these interfaces 
>> or not, e.g.
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=1865-1867
>>
>> For these, I can't think of a better implementation that the OP's. It 
>> doesn't seem like the greatest API design though.
>>
>> On Sunday, 11 June 2023 at 08:10:01 UTC+1 Tamás Gulácsi wrote:
>>
>>> As Far as I See, you check all the combinations of methods in wideness 
>>> order.
>>> Why not have a generic wrapper struct, that is filled with the 
>>> underlying driver.Conn's methods, 
>>> and use that if not nil, but use the generic implementation if not.
>>>
>>> Like
>>> ```
>>> type wrappedConn struct {
>>>   driver.Conn
>>>   queryContext func(...)
>>> }
>>> func (wc wrappedConn) QueryContext(...) ... {
>>>   if wc.queryContext != nil { return wc.queryContext(...) }
>>>   return wc.Conn.Query(...)
>>> }
>>> ```
>>>
>>> This way you only have to check for each method on driver.Conn, and fill 
>>> the wrappedConn's functions as they axist/not.
>>>
>>> Vasiliy Tolstov a következőt írta (2023. június 10., szombat, 12:16:34 
>>> UTC+2):
>>>
>>>> I have sql driver that wraps original driver.Driver, to be able to work 
>>>> with drivers that not have ExecerContext or QuerierContext i need to 
>>>> return 
>>>> wrapped to that supports only needed interfaces.
>>>> I'm to want to write all cases via handmade switch case and write 
>>>> generator that creates full combo list of methods and generate interfaces 
>>>> for this methods.
>>>> But this brings file that contains 20K lines 
>>>> https://git.unistack.org/unistack-org/micro-wrapper-sql/src/branch/master/wrap_gen.go
>>>> Does it possible to have 

[go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-11 Thread Brian Candler
I think the issue is that the *consumer* of this object checks whether 
certain methods (or rather, interfaces) are present, and behaves 
differently depending whether they are or not.

There are a whole load of public interfaces defined here:
https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/driver/driver.go
And the supplied object, which the OP is trying to wrap, could implement 
some arbitrary combination of these interfaces.

I think that for *some* of these interfaces, it would be OK to provide 
dummy implementations if there is no underlying method to call: e.g.
https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=552-554
https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=567-569
https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=834-838

But for others it's much less clear, and it may make a semantic difference 
whether the the object you provide implements these interfaces or not, e.g.
https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/database/sql/sql.go;l=1865-1867

For these, I can't think of a better implementation that the OP's. It 
doesn't seem like the greatest API design though.

On Sunday, 11 June 2023 at 08:10:01 UTC+1 Tamás Gulácsi wrote:

> As Far as I See, you check all the combinations of methods in wideness 
> order.
> Why not have a generic wrapper struct, that is filled with the underlying 
> driver.Conn's methods, 
> and use that if not nil, but use the generic implementation if not.
>
> Like
> ```
> type wrappedConn struct {
>   driver.Conn
>   queryContext func(...)
> }
> func (wc wrappedConn) QueryContext(...) ... {
>   if wc.queryContext != nil { return wc.queryContext(...) }
>   return wc.Conn.Query(...)
> }
> ```
>
> This way you only have to check for each method on driver.Conn, and fill 
> the wrappedConn's functions as they axist/not.
>
> Vasiliy Tolstov a következőt írta (2023. június 10., szombat, 12:16:34 
> UTC+2):
>
>> I have sql driver that wraps original driver.Driver, to be able to work 
>> with drivers that not have ExecerContext or QuerierContext i need to return 
>> wrapped to that supports only needed interfaces.
>> I'm to want to write all cases via handmade switch case and write 
>> generator that creates full combo list of methods and generate interfaces 
>> for this methods.
>> But this brings file that contains 20K lines 
>> https://git.unistack.org/unistack-org/micro-wrapper-sql/src/branch/master/wrap_gen.go
>> Does it possible to have smaller code that provides the same effect?
>> Or I'm miss something?
>>
>> -- 
>> Vasiliy Tolstov,
>> e-mail: v.to...@selfip.ru
>>
>

-- 
You received this message because you are subscribed to the Google 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/4dc775df-6627-4134-8b32-e9f659e48831n%40googlegroups.com.


Re: [go-nuts] Hard-to-explain race detector report

2023-06-08 Thread Brian Candler
> In this case however, what is reported is a concurrent write-after-read. 
Is that really a memory race?

In general, it would be: if these accesses are not synchronized, there's a 
risk that the goroutines could slip relative to each other so that the 
write and read take place at the same time, and the read sees an 
inconsistent value.

In this particular case: if there's some external synchronization which 
means that the read is always strictly before the next write, then the 
problem may not occur in practice.

I would be inclined to change newconns to atomic.Int32 
 so it's safe either way, and the 
race detector should be silenced.

On Thursday, 8 June 2023 at 08:24:56 UTC+1 burak serdar wrote:

> On Wed, Jun 7, 2023 at 2:19 PM Sven Anderson  wrote:
>
>>
>>
>> Caleb Spare  schrieb am Mi. 7. Juni 2023 um 19:22:
>>
>>> On Wed, Jun 7, 2023 at 2:33 AM Sven Anderson  wrote:
>>> >
>>> > That’s not only a read/write race, it’s also a write/write race. Every 
>>> request to the server creates a new Go routine that might increment 
>>> newConns in parallel, so it may get corrupted. Same for lines 39/40.
>>> >
>>> > You might claim, that for infrastructural reasons, there can be no 
>>> concurrent requests to your server, but that would just mean that the race 
>>> is not triggered, it’s there nevertheless.
>>>
>>> The race detector reports on races that actually happened, not races
>>> that could happen.
>>>
>>
>> A race condition is a condition, not an event, so I think „happened“ is 
>> not correct, but maybe someone who knows the heuristics of the race 
>> detector better can clear that up.
>>
>
> The race detector reports when shared memory is accessed concurrently from 
> multiple goroutines. So it detects when a memory race happens. In this case 
> however, what is reported is a concurrent write-after-read. Is that really 
> a memory race?
>  
>
>>
>> And why would it matter then if it understands the causalities of TCP? 
>> One must be incorrect: Either your understanding of the TCP causalities or 
>> of how the race detector is working, because it does indeed report 
>> something, right? ;-)
>>
>>
>> >
>>> > Caleb Spare  schrieb am Mi. 7. Juni 2023 um 01:31:
>>> >>
>>> >> Can  someone explain why the following test shows a race between the
>>> >> indicated lines?
>>> >>
>>> >> 
>>> https://github.com/cespare/misc/blob/b2e201dfbe36504c88e521e02bc5d8fbb04a4532/httprace/httprace_test.go#L12-L43
>>> >>
>>> >> The race seems to be triggered by the very last line of the test:
>>> >>
>>> >> get(client1)
>>> >>
>>> >> If I comment that out, then the race detector doesn't complain. But
>>> >> then it seems that a read of a variable which happens before an HTTP
>>> >> request which causes a write of the variable ultimately races with the
>>> >> original read, which doesn't make sense.
>>> >>
>>> >> It seems like a false positive (perhaps the race detector doesn't
>>> >> understand causality across a TCP connection?), but so far I've never
>>> >> seen the race detector have a false positive, so I think I must be
>>> >> missing something.
>>> >>
>>> >> I wrote a slightly simpler test (see TestHTTPRace2 right below in the
>>> >> same file) which tries to make the race happen using a regular HTTP
>>> >> handler and a single client and the race detector doesn't complain.
>>> >>
>>> >> Caleb
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed 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/CAGeFq%2B%3DZGE5agaLYDgsdYvykbaWwHgjtKJf9q%2B1YJhR26%3DY45Q%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAFwXxZTO0fsRRK%3DiShNL1xjbaXN7tDc8wN_uAy3J3FQXPwK7Pg%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/50c3c2db-e2bf-45fe-905f-2b05a0970462n%40googlegroups.com.


[go-nuts] Re: Map and slice are also concurrency-unsafe data structures. Why is map designed to throw a fatal that cannot be recovered when there is a concurrency conflict, but slice does not have any

2023-06-02 Thread Brian Candler
Is it actually "designed" to do that? I think it just crashes when the map 
data structure is in a corrupted state, because of concurrent updates.

In principle, you may be able to get a panic when updating a slice 
concurrently, but it's much rarer. That's because a slice allocates a 
contiguous area of memory for N (cap) elements, so normally the slice data 
structure itself (which contains the pointer/cap/len) is not being 
modified, just the area of memory that it points to. That means that you 
could end up with an element of the slice containing a corrupted value, but 
the slice itself would not be corrupt. Also, operations which re-slice or 
append to the slice return a new slice structure - which may or may not 
point to the original allocated memory.

The race detector is helpful to identify any unsafe concurrent operations, 
to variables of any type.

On Friday, 2 June 2023 at 12:59:07 UTC+1 fliter wrote:

> Map and slice are also concurrency-unsafe data structures. Why is map 
> designed to throw a fatal that cannot be recovered when there is a 
> concurrency conflict, but slice does not have any prompt? Are there any 
> design considerations?
>
> 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/9f92a2de-e9b0-4c05-92e0-800cff9fe676n%40googlegroups.com.


[go-nuts] Re: Transferring a Go repository and installing old releases

2023-05-26 Thread Brian Candler
Ah, I think I see the problem.

github.com/terramate-io/terramate/cmd/terramate@v0.2.18
refers to the tag v0.2.18 - and at that point, go.mod had not been updated. 
(Try "git checkout v0.2.18; head go.mod")

You *could* rewrite history globally to make it believe that it had been 
terramate-io/terramate since day one.

But I don't know if anyone has any better ideas.

On Friday, 26 May 2023 at 11:55:48 UTC+1 Tiago de Bem Natel de Moura wrote:

> This is the real project: https://github.com/terramate-io/terramate
>
> It was transferred from https://github.com/mineiros-io/terramate
>
> So my problem is that all existent releases can be installed with "go 
> install" if using the old module name (github.com/mineiros-io/terramate).
>
> This works: go install 
> github.com/mineiros-io/terramate/cmd/terr...@v0.2.18 
> <http://github.com/mineiros-io/terramate/cmd/terramate@v0.2.18>
> But this does not: go install 
> github.com/terramate-io/terramate/cmd/terr...@v0.2.18 
> <http://github.com/terramate-io/terramate/cmd/terramate@v0.2.18>
> It gives the error:
> go: github.com/terramate-io/terramate/cmd/terr...@v0.2.18 
> <http://github.com/terramate-io/terramate/cmd/terramate@v0.2.18>: 
> github.com/terramate-io/terr...@v0.2.18 
> <http://github.com/terramate-io/terramate@v0.2.18>: parsing go.mod:
> module declares its path as: github.com/mineiros-io/terramate
> but was required as: github.com/terramate-io/terramate
>
> I'm wondering, why?
> From the proxy, it retrieves the modfile containing the (correct) old 
> module name:
> https://proxy.golang.org/github.com/terramate-io/terramate/@v/v0.2.18.mod
> And downloads the zip from: 
> https://proxy.golang.org/github.com/terramate-io/terramate/@v/v0.2.18.zip
>
> But go install is picky and disallow the installation.
> It fails at this line: 
> https://github.com/golang/go/blob/055c186f53493da473c69ad468861ba25f1a/src/cmd/go/internal/modload/modfile.go#L643
>
> But if I manually unpack the v0.2.18 zip, cd into and run "go build", "go 
> install", etc, everything works...
>
> If this is the intended behavior, can someone explain the reasoning behind 
> it?
>
> So is it that the only option here is documenting to our users that 
> releases before v0.2.19 need to be installed with the old module name (if 
> using go install) ?
> On Friday, 26 May 2023 at 10:45:39 UTC+1 Tiago de Bem Natel de Moura wrote:
>
>> Hi Brian,
>>
>> I updated go.mod and all import paths in the main branch already, but the 
>> issue is related to installing releases (with go install) that had the old 
>> name in the go.mod.
>>
>> On Friday, 26 May 2023 at 09:10:39 UTC+1 Brian Candler wrote:
>>
>>> What happens if you change the go.mod file, and all imports within the 
>>> project, to use github.com/new/project instead of github.com/old/project 
>>> ?
>>> (If you make this change, the issue then is whether you can still "go 
>>> install github.com/old/project...")
>>>
>>> The reason it works with a local clone is that you can put anything you 
>>> like in go.mod, even
>>>
>>> module blahdiblah/dontcare
>>>
>>> and then do
>>>
>>> import "blahdiblah/dontcare/foo"
>>>
>>> within the same local filetree.  The fact that the module name includes "
>>> github.com" doesn't require any access to github, if the module name 
>>> can be found within the local workspace.
>>>
>>> On Thursday, 25 May 2023 at 18:00:48 UTC+1 Tiago de Bem Natel de Moura 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'd like to transfer a Go repository to another Github organization but 
>>>> somehow make the "go install" still able to install the old releases using 
>>>> the new import path. Is this possible?
>>>>
>>>> I did the transfer using the Github UI, and updated the go.mod and all 
>>>> imports to use the new project path, but now I'm unable to install the 
>>>> existing releases using the new import path.
>>>>
>>>> Example:
>>>>
>>>> works: go install github.com/old/project/c...@v1.0.0 
>>>> <http://github.com/old/project/cmd@v1.0.0>
>>>>
>>>> The "github.com/old/project" repository now automatically redirects to 
>>>> "github.com/new/project" (Github Feature).
>>>>
>>>> But this fails: go install github.com/new/project/c...@v1.0.0 
>>>> <http://github.com/new/projec

[go-nuts] Re: Transferring a Go repository and installing old releases

2023-05-26 Thread Brian Candler
What happens if you change the go.mod file, and all imports within the 
project, to use github.com/new/project instead of github.com/old/project ?
(If you make this change, the issue then is whether you can still "go 
install github.com/old/project...")

The reason it works with a local clone is that you can put anything you 
like in go.mod, even

module blahdiblah/dontcare

and then do

import "blahdiblah/dontcare/foo"

within the same local filetree.  The fact that the module name includes 
"github.com" doesn't require any access to github, if the module name can 
be found within the local workspace.

On Thursday, 25 May 2023 at 18:00:48 UTC+1 Tiago de Bem Natel de Moura 
wrote:

> Hi,
>
> I'd like to transfer a Go repository to another Github organization but 
> somehow make the "go install" still able to install the old releases using 
> the new import path. Is this possible?
>
> I did the transfer using the Github UI, and updated the go.mod and all 
> imports to use the new project path, but now I'm unable to install the 
> existing releases using the new import path.
>
> Example:
>
> works: go install github.com/old/project/c...@v1.0.0 
> 
>
> The "github.com/old/project" repository now automatically redirects to "
> github.com/new/project" (Github Feature).
>
> But this fails: go install github.com/new/project/c...@v1.0.0 
> 
>
> error below:
> go: github.com/new/project/c...@v1.0.0 
> : github.com/new/pro...@v1.0.0 
> : parsing go.mod:
> module declares its path as: github.com/old/project
> but was required as: github.com/new/project
>
> If I clone the "github.com/new/project" repository then everything works 
> fine (go build, go test, etc) but only "go install" fails...
>
> Is there a solution?
>
>
>
>

-- 
You received this message because you are subscribed to the Google 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/efafbc39-30f5-4d21-8221-85d3cc92d66an%40googlegroups.com.


Re: [go-nuts] Idiomatic distribute-process-collect pattern

2023-05-22 Thread Brian Candler
Isn't Ian's solution basically the same, but using a Waitgroup instead of 
an Errgroup?

I think the Fetch() is just a placeholder for "this is where the 
implementation detail of the task would go"

On Sunday, 21 May 2023 at 21:54:39 UTC+1 Andrew Harris wrote:

> The recipe on 10:26 should work but it's definitely contrived - using 
> Fetch looks strange to me, and the cancellation behavior of errgroup is 
> another moving part that adds some overhead. If it's sufficient, Ian's 
> solution groks better :)
>
>
> On Sunday, May 21, 2023 at 7:38:31 AM UTC-7 Tobias Klausmann wrote:
>
>> Hi! 
>>
>> First off, thanks both Ian and Andrew! 
>>
>> On Sat, 20 May 2023, Ian Lance Taylor wrote: 
>> > On Sat, May 20, 2023 at 1:23 AM Tobias Klausmann 
>> >  wrote: 
>> > > What I wonder about is the collection stage: the assumption that 
>> there 
>> > > will be exactly as many results as inputs seems brittle, and the only 
>> > > real way to handle errors is to put them into the result struct and 
>> > > examining them later. 
>> > > 
>> > > I also usually prefer handling workers with a `waitgroup`, but that 
>> only 
>> > > really works if there is no return channel to handle, either because 
>> > > the workers do the output/final processing, or because results are 
>> > > written to a global. The former is not always possible, and the 
>> latter 
>> > > is ugly. 
>> > > 
>> > > There is also the option of just making the result channel big enough 
>> > > to hold all results, but that seems a bit ugly as well. 
>> > > 
>> > > So what's the most idiomatic way of doing this? 
>> > 
>> > The pattern I tend to prefer is 
>> > 
>> > rc := make(chan result, numprocs) 
>> > var wg sync.WaitGroup 
>> > for i := 0; i < numprocs; i++ { 
>> > wg.Add(1) 
>> > go func() { 
>> > defer wg.Done() 
>> > sendResults(rc) 
>> > }() 
>> > } 
>> > go func() { 
>> > wg.Wait() 
>> > close(rc) 
>> > }() 
>> > This ensures that the channel is closed when all the results are sent. 
>> > Then you can collect the results using one or more goroutines with 
>> > "for result := range rc". 
>> > 
>> > Note that for this kind of pattern it's usually a good idea to use a 
>> > buffered channel to hold the results, to avoid tight synchronization 
>> > between the senders and the processors. Of course sometimes you want 
>> > that tight synchronization, but usually you don't. The exact size of 
>> > the buffer doesn't matter too much. 
>>
>> I'm now using this approach, and my mind is much more at ease about the 
>> robustness. As for the channel size, I've tried numproc, *2, *10 and 
>> *100, and it all makes no practical difference time-wise, so I'll just 
>> stay 
>> with numproc 
>>
>> > You may also want to watch Bryan's talk at 
>> > https://www.youtube.com/watch?v=5zXAHh5tJqQ . 
>>
>> Started watching and tried the recipe outlined/on screen at 10:26, but 
>> couldn't get it to work: the result-gathering loop reading from c would 
>> do zero iterations. Not sure what was going on ther. But the above 
>> solution is one I grok, so I'm staying with that :) 
>>
>>
>> Best, 
>> Tobias 
>>
>

-- 
You received this message because you are subscribed to the Google 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/6c410c55-1a5e-4a54-8fed-d77eddcbf94an%40googlegroups.com.


[go-nuts] Re: how do I use go test for code that needs a flag defined in flag package

2023-05-07 Thread Brian Candler
Since the CLI parsing sets global variables which affect how your code 
operates, you can just set those variables directly in your test functions.

func TestWithDots(t *testing.T) {
noDotsFlag = false
...
}

func TestWithNoDots(t *testing.T) {
noDotsFlag = true
...
}

On Saturday, 6 May 2023 at 21:50:16 UTC+1 Robert Solomon wrote:

> thank you
>
> On Saturday, May 6, 2023 at 4:32:57 PM UTC-4 Jason Phillips wrote:
>
>> The testing package documentation mentions this case explicitly:
>> https://pkg.go.dev/testing#hdr-Main
>>
>> In short, you can define a main function (called TestMain) for your test 
>> package and call flag.Parse from there.
>>
>> On Saturday, May 6, 2023 at 4:03:59 PM UTC-4 Robert Solomon wrote:
>>
>>> A related issue:
>>> Now that I can run go test and it's running, how do I define the flag.  
>>> Currently, I define it in main(), and also the flag.Parse() is in main().
>>> But main() is not run in go test, so I tried putting flag.BoolVar() and 
>>> flag.Parse() in an init() function, but that doesn''t work either.
>>>
>>> How do I test the operations of the flag package when running go test?
>>>
>>>
>>>
>>> On Saturday, May 6, 2023 at 3:45:10 PM UTC-4 Robert Solomon wrote:
>>>
>>>> Looks like I didn't copy everything I have to the playground.  But I do 
>>>> have the correct imports and the top statement, package main.
>>>>
>>>> Thank you for answering, that's working.
>>>>
>>>> --rob solomon
>>>>
>>>>
>>>> On Saturday, May 6, 2023 at 11:24:11 AM UTC-4 Brian Candler wrote:
>>>>
>>>>> Your code is incomplete (it's missing all the imports), and "go test" 
>>>>> doesn't run your main() function anyway, so it's not going to parse the 
>>>>> flags.
>>>>>
>>>>> But otherwise I think it would be something like this: (single dash, 
>>>>> -args not --args)
>>>>>
>>>>> go test . -v -args - -dots
>>>>>
>>>>> https://go.dev/play/p/HFJBO1j54iE
>>>>>
>>>>> On Saturday, 6 May 2023 at 14:02:35 UTC+1 Robert Solomon wrote:
>>>>>
>>>>>>
>>>>>> I have a routine that I want to test, that I have to pass a flag into 
>>>>>> this test.  This is on Win10 using Go 1.20.4.  This code is here:
>>>>>> https://go.dev/play/p/p-YeGDk1KaM
>>>>>>
>>>>>> I want to pass a flag I call dots into the test code for this 
>>>>>> function.  I tried from within the correct directory
>>>>>>
>>>>>> go test --args -dots
>>>>>> or
>>>>>> go test . --args -dots
>>>>>>
>>>>>> Or from the top of my source tree where the go.mod file is :
>>>>>>
>>>>>> go test .\detox --args -dots
>>>>>> go test .\detox\... --args -dots
>>>>>>
>>>>>> I get an error message saying:
>>>>>>
>>>>>> flag provided but not defined: -dots.  
>>>>>>
>>>>>> But that flag does show up when I run the program using the -h flag, 
>>>>>> and it works when not in go test mode.
>>>>>> The full pgm is in the link above.
>>>>>>
>>>>>> What am I missing?
>>>>>>
>>>>>> --rob solomon
>>>>>>
>>>>>> PS: a stackoverflow question that's similar to this, from 2014, does 
>>>>>> not work for me.
>>>>>>
>>>>>>

-- 
You received this message because you are subscribed to the Google 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/13b4aba4-ebbf-4880-b2df-ea30c5049da3n%40googlegroups.com.


  1   2   3   4   5   6   7   8   >