Re: [go-nuts] Re: Call the .net dlls into the golang

['Brian Candler' via golang-nuts]

"try building at the command line"

That's your clue. You'll most likely get a meaningful error message on 
stderr, which your IDE is hiding.

On Thursday 23 May 2024 at 13:47:10 UTC+1 Pavan Kumar A R wrote:

> Hello , 
>
> I am try to call the c program in the golang , but i am getting the issue 
> .  please see the error message :
> package main
>
> go list failed to return CompiledGoFiles. This may indicate failure to 
> perform cgo processing; try building at the command line. See 
> https://golang.org/issue/38990.go list
> View Problem (Alt+F8)
>
>
> //#cgo LDFLAGS: -L. -llibCWrapper-win64 -Wl,-rpath,.
> //#include "ealApiLib.h"
>
> import "C"
> import "fmt"
>
> func main() {
>
> result := C.Connect("192.168.1.1")
>
> fmt.Println("connection success" + result)
>
> }
>
>
>
> On Thursday 23 May 2024 at 02:53:12 UTC+5:30 peterGo wrote:
>
>> cgo command
>> https://pkg.go.dev/cmd/cgo
>> Cgo enables the creation of Go packages that call C code.
>>
>> On Wednesday, May 22, 2024 at 4:41:13 PM UTC-4 Carla Pfaff wrote:
>>
>>> Yes, you can call C functions from Go, it's called Cgo: 
>>> https://go.dev/blog/cgo
>>>
>>> On Wednesday 22 May 2024 at 18:04:19 UTC+2 Pavan Kumar A R wrote:
>>>

> Okay,  it's possible to call the C program to Golang. Because I also 
> have the C platform dlls and the C platform dlls  we using in the cross 
> platform mono and in the mono internally call the.net dlls function , 
> can I use the C program dlls in Golang?  
>


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

Re: [go-nuts] Errors trying to use external pkg z3

['Brian Candler' via golang-nuts]

* Start in an empty directory
* Run "go mod init example"
* Create your main.go with that import statement in it
* Run:

go mod tidy
go run .

On Wednesday 22 May 2024 at 16:26:54 UTC+1 Kenneth Miller wrote:

> I tried that, same error
>
> On Wednesday, May 22, 2024 at 9:12:58 AM UTC-6 Brian Candler wrote:
>
>> It's because the name of the module is "github.com/aclements/go-z3/z3", 
>> not "z3"
>>
>> Only packages in the standard library have short names, like "fmt", 
>> "strings" etc.
>>
>> On Wednesday 22 May 2024 at 15:46:30 UTC+1 robert engels wrote:
>>
>>> If it is your own code, you have to use
>>>
>>> import “github.com/aclements/go-z3/z3”
>>>
>>> or you need a special go.mod file.
>>>
>>> On May 22, 2024, at 9:38 AM, robert engels  wrote:
>>>
>>> What are you trying to run? z3 is a library.
>>>
>>> On May 22, 2024, at 9:29 AM, Kenneth Miller  
>>> wrote:
>>>
>>> I did go get -u github.com/aclements/go-z3/z3
>>>
>>> but when I go run . I get
>>>
>>> main.go:5:2: package z3 is not in std
>>>
>>> the offending line is 
>>>
>>> import "z3"
>>>
>>> can someone help me please? I'm sure this has been asked before but I 
>>> couldn't find it
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/d46b52fb-fa96-4544-914a-42bf83d75322n%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...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.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/75533bfc-b63b-41cc-9f66-0885d0c00c7cn%40googlegroups.com.

Re: [go-nuts] Errors trying to use external pkg z3

['Brian Candler' via golang-nuts]

It's because the name of the module is "github.com/aclements/go-z3/z3", not 
"z3"

Only packages in the standard library have short names, like "fmt", 
"strings" etc.

On Wednesday 22 May 2024 at 15:46:30 UTC+1 robert engels wrote:

> If it is your own code, you have to use
>
> import “github.com/aclements/go-z3/z3”
>
> or you need a special go.mod file.
>
> On May 22, 2024, at 9:38 AM, robert engels  wrote:
>
> What are you trying to run? z3 is a library.
>
> On May 22, 2024, at 9:29 AM, Kenneth Miller  wrote:
>
> I did go get -u github.com/aclements/go-z3/z3
>
> but when I go run . I get
>
> main.go:5:2: package z3 is not in std
>
> the offending line is 
>
> import "z3"
>
> can someone help me please? I'm sure this has been asked before but I 
> couldn't find it
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d46b52fb-fa96-4544-914a-42bf83d75322n%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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.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/ebeb05d6-5649-4ad4-b0d7-28ef36ee6dd7n%40googlegroups.com.

[go-nuts] Re: var errors stdlib

['Brian Candler' via golang-nuts]

On Friday 10 May 2024 at 17:03:46 UTC+1 Sebastian Bogan wrote:

Would something like the following work (and be less risky)?:

  type ConstError string
  func (e ConstError) Error() string {
return string(e)
  }
  const ErrNotExist = ConstError("file does not exist")


If you compare an error value against this constant, and the error value 
has the correct type, then you're actually doing a character-by-character 
comparison of the string text, not unique object identity.

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7cafdb37-9e29-4ab5-8bab-49d7b9fc59fcn%40googlegroups.com.

[go-nuts] Re: Slice conversion function not working on big endian platform

['Brian Candler' via golang-nuts]

That code doesn't even compile in go 1.22 or go.1.21:
https://go.dev/play/p/mPCBUQizSVo
./prog.go:20:14: cannot convert unsafe.Pointer(s) (value of type 
unsafe.Pointer) to type []To

What's the underlying requirement? In the test case it looks like you want 
to take a slice of int32's, in whatever their internal in-memory 
representation is, and re-represent them as a slice of half as many 
int64's?? Then of *course* each pair of int32's will become one int64, and 
the order of the hi/lo halves will depend entirely on the system's internal 
representation of int64's. It *is* working, in the sense that it's doing 
exactly what you told it to do. There's a reason why the "unsafe" package 
is called "unsafe"!

It would be straightforward to write a function which takes a slice 
containing pairs of int32's and assembles them into int64's in a consistent 
way. What you've not explained is:
- why you need to do this with generics (for example, what behaviour would 
you expect from other types?)
- why you need to do this in-place with "unsafe"

On Wednesday 8 May 2024 at 10:24:30 UTC+1 Srinivas Pokala wrote:

> Hello gopher's,
>
> I have simple go program which convert slice of one type to slice of other 
> type using go generics for handling all the supported types.
> Below is the code snippest for this:
> package main
>
> import "fmt"
> import "unsafe"
>
> type slice struct {
> ptr unsafe.Pointer
> len int 
> cap int 
> }
>
> func Slice[To, From any](data []From) []To {
> var zf From
> var zt To
> var s = (*slice)(unsafe.Pointer())
> s.len = int((uintptr(s.len) * unsafe.Sizeof(zf)) / 
> unsafe.Sizeof(zt))
> s.cap = int((uintptr(s.cap) * unsafe.Sizeof(zf)) / 
> unsafe.Sizeof(zt))
> x := ([]To)(unsafe.Pointer(s))
> return x
> }
> func main() {
> a := make([]uint32, 4, 13) 
> a[0] = 1 
> a[1] = 0 
> a[2] = 2 
> a[3] = 0 
> // 1 0 2 0
> b := Slice[int64](a)
> //Expecxted : []int64[]{0x 0001,  0x 0002}
> //Got: []int64{0x0001 , 0x0002 000}
> if b[0] != 1 { 
> fmt.Printf("wrong value at index 0: want=1 got=0x%x \n", 
> b[0])
> }
> if b[1] != 2 { 
> fmt.Printf("wrong value at index 1: want=2 got=0x%x\n", 
> b[0])
> }
>
> }
>
> This is working fine on little endian architectures(amd64,arm64 etc), but 
> when i run on big endian machine(s390x) it is not working , it is resulting 
> wrong data
> //Expecxted : []int64[]{0x 0001,  0x 0002}
>  //Got: []int64{0x0001 , 0x0002 000}
> Can somepoint point me how do we write such scenario which should work on 
> both little/endian platforms.
> Any leads on this?
>
> Thanks,
> Srinivas
>

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

[go-nuts] Re: tuples! tuples! tuples!

['Brian Candler' via golang-nuts]

A few questions (I'm ignoring generics for now, and have not 
cross-referenced the other proposals).

1. Is it possible to access the n'th element of an implicitly typed tuple? 
More generally, how do you unpack such a tuple - other than by assigning to 
a compatible named tuple type?

2. How does it interact with multiple assignment? Is the following valid, 
with or without "..." notation?

a, b := (1, 2)

3. Are implicit tuples allowed on the LHS? Are either of the following 
valid?

(a, b) := (1, 2)
(a, b) := 1, 2

4. How does it interact with functions returning multiple values? If I have 
a function which returns (string, error) then can I write

t := myfunc()

and is t implicitly a tuple of (string, error) ? Also with explicit types, 
e.g.

var t (msg string, err error)
t = myfunc()

More generally, does there remain a difference between a function returning 
multiple values, and a function returning a tuple?

5. Given that you write

type Point (X, Y int)

does this mean that "(X, Y int)" is valid wherever a type is normally 
specified, e.g.

var a (X, Y int)

This could lead to ambiguity with functions:

function foo() (X, Y int) { ... }

Currently that's a function returning two named values (and "X" and "Y" are 
available for assignment within the functino body); but under your scheme, 
"(X, Y int)" is also a single type literal.

I guess you could resolve that ambiguity by requiring:

function foo() ((X, Y int)) { ... }  // function returns a tuple

6. Is a one-element tuple allowed? e.g.

t := (0,)
t := (X int)(0)

7. Do untyped constants work as per normal assignment? I would expect:

t1 := (0, 0)  // OK, implicit type is (int, int)

int32 a, b
t2 := (a, b)  // implicit type is (int32, int32)

type Pair64 (X, Y int64)
var t3, t4, t5 Pair64
t3 = (0, 0)   // allowed: an untyped constant can be assigned to int64
t4 = t1   // not allowed, t1 is implicitly (int, int) and int cannot be 
assigned to int64 without conversion
t5 = t2   // not allowed, cannot assign int32 to int64

// Casting??
x := Pair64((0, 0))
y := Pair64(t1)
z := (X, Y int64)((0, 0))

8. Observation: you now have two very similar but different concepts, 
tuples and structs:

type Point1 (X, Y int)
type Point2 struct{X, Y int}

The alternative ISTM would be to have "implicitly typed struct literals", 
e.g.

var a Point2
a = {1, 2}

That seems to be a smaller change, and I thought I had seen a proposal like 
this before, but I haven't dug around to find a reference. Are there use 
cases that your proposal allows, which this doesn't?

On Sunday 28 April 2024 at 12:10:02 UTC+1 Andrew Harris wrote:

> Bouncing out from some recent discussions on the github issue tracker, it 
> seems like there's some interest in tuples in Go. I thought the discussion 
> in #66651 led to some interesting ideas, but it's also beginning to drift. 
> Maybe this is a better place to brain-dump some ideas. (This could be a 
> proposal but I'm not sure that's quite right either, that might be spammy.)
>
> Some recent issues:
> 1. #64457 "Tuple types for Go"  
> (@griesemer)
> 2. #66651 "Variadic type parameters" 
>  (@ianlancetaylor)
> 3. "support for easy packing/unpacking of struct types" 
>  (@griesemer)
>
> Synthesizing from those discussions, and satisfying requirements framed 
> by @rogpeppe 
> , the 
> following is a design for tuples that comes in two parts. The first part 
> explores tuples in non-generic code, resembling a restrained version of 
> #64457. The second part explores tuple constraints for generic code, 
> reframing some ideas from #66651 in terms of tuples. It's a fungal kingdom 
> approach, where tuples occupy some unique niches but aren't intended to 
> dominate the landscape.
>
> *TUPLES IN NON-GENERIC CODE*
>
> Tuples are evil 
>  because 
> the naming schemes are deficient. To enjoy greater name abundancy, this 
> design tweaks tuple *types* from #64457 in the direction of 
> "super-lightweight 
> structs" 
> . It 
> still allows tuple *expressions* from #64457, for tuples constructed from 
> bare values.
>
> *1. Tuple types*
> Outside of generics, tuple *type* syntax requires named fields.
>
> TupleType = "(" { IdentifierList Type [ ", " ] } ")" .
>
> // e.g.:
> type Point (X, Y int)
>
> More irregularly, the TupleType syntax is used *exclusively* to declare 
> named types, and these named tuple types cannot implement methods. As a 
> result, a named tuple type is entirely defined at the site of the type 
> definition.
>
> *2. Tuple literals*
> The tuple *expression* syntax of #64457 remains valid. The result is an 
> implicitly typed tuple value. Literals of a named tuple type are also 
> valid, and 

[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)

['Brian Candler' via golang-nuts]

Really I was unsure whether you can guarantee that the first few bytes of a 
TLS "client hello" can never happen to be the ASCII characters P R O X Y 
  As a binary protocol I think it's unlikely to occur, but I've not 
attempted to prove it.

On Friday 26 April 2024 at 02:30:51 UTC+1 Eli wrote:

> > And whilst HTTP is a text protocol (and can distingush between PROXY and 
> GET/POST/PUT etc), what about TLS?
>
> Proxy protocol is sent as the first bytes on wire after TCP is 
> established, not carried via HTTP headers, so it is easily distinguishable 
> from TLS. 
>
> I agree with all other points, but wanted to mention that.  
>
> -eli
>
>
> On Monday, April 15, 2024 at 4:43:50 PM UTC-4 Brian Candler wrote:
>
> > My point is that a http server that is using the standard library always 
>  reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part 
> of the tcp package.
>
> That's the correct response, because the request is not compliant with 
> HTTP.
>
> > So the net/http should just handle the http request like they do without 
> the proxy protocol.
>
> Why should it do that? It would mask a configuration error - either that 
> the upstream device is sending with proxy protocol when it should be 
> sending plain HTTP, or that the downstream server has not been configured 
> correctly to interpret the proxy protocol.
>
> At worst, it would open security problems, when the upstream proxy 
> *thinks* it is successfully passing along source IP address information, 
> but the downstream server is ignoring it.
>
> Can you point to any other well-known HTTP server implementation which 
> ignores inserted PROXY headers like this? I know that Apache doesn't: you 
> have to configure each vhost to either use or not use proxy protocol.
>
> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html#remoteipproxyprotocol
>
> And whilst HTTP is a text protocol (and can distingush between PROXY and 
> GET/POST/PUT etc), what about TLS?
>
> On Monday 15 April 2024 at 21:06:37 UTC+1 HappyTobi wrote:
>
> Hi,
>
> thanks for the answer, but thats not the point.
> I think it's fine to use a library or implement something to add something 
> to the http layer to parse the proxy protocol.
>
> My point is that a http server that is using the standard library always 
>  reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part 
> of the tcp package.
> So the net/http should just handle the http request like they do without 
> the proxy protocol.
> If someone needs to parse the proxy protocol, it's fine to implement or 
> add a 3rd party lib, but I think the "default" should just work.
>
> Brian Candler schrieb am Montag, 15. April 2024 um 20:41:50 UTC+2:
>
> Your answer was given here:
> https://github.com/golang/go/issues/65078#issuecomment-1890419683
>
> In other words:
> - net/http handles HTTP
> - go-proxyprotocol handles the proxy protocol
> - you combine the two to get the behaviour you want
>
> Orthogonal pieces which handle their own responsibilities are a Good 
> Thing™ IMO.
>
> If you want to wrap this up in a library which has the same API as 
> net/http but implements proxy protocol, you are free to do so (and publish 
> it, if you wish). However, there is a very high bar for putting 
> functionality into the core Go library, because the backwards compatibility 
> promise means it has to be supported forever.
>  
> > I have previously posted two issues on this topic, but neither has been 
> accepted
>
> I think that answers your question.
>
> On Monday 15 April 2024 at 17:47:24 UTC+1 HappyTobi wrote:
>
> Dear Gophers,
>
> I would like to bring to your attention.
> There is an “issue” with the Go standard implementation when handling HTTP 
> requests that are extended by the proxy protocol v1 or v2.
>
> While the simple HTTP server works fine with regular requests, it fails 
> when a proxy protocol is added.
>
>
> Example:
>
> Simple http server:
>
> *package* main
>
>  
>
> *import* (
>
> "*fmt*"
>
> "*net/http*"
>
> )
>
>  
>
> *func* hello(*w* http.ResponseWriter, *req* ***http.Request) {
>
> fmt.Fprintf(w, "*hello world**\n*")
>
> }
>
>  
>
> *func* main() {
>
> http.HandleFunc("*/hello*", hello)
>
> http.ListenAndServe("*:8080*", *nil*)
>
> }
>
> The server is working fine when you do something like:
>
> curl -kv http://*localhost:8080/hello*
>
>  
>
> But the implementation is failing when you add a proxy protocol (v1) to 
> the tcp request.
>
> curl -kv *--*haproxy-protocol http://*localhost:8080/hello*
>
>  
>
> The issue arises because the implementation fails to read the HTTP 
> message, as the message starts with the proxy protocol. 
> Go read request function: 
> https://github.com/golang/go/blob/91c04826723a10f6778a935e743a34de81312489/src/net/http/request.go#L1068
>  
>
> The proxy protocol is widely used, and it would be beneficial for the Go 
> standard implementation to handle such requests.
>
>  
>
> I have previously posted two issues on this 

[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)

['Brian Candler' via golang-nuts]

> My point is that a http server that is using the standard library always 
 reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part 
of the tcp package.

That's the correct response, because the request is not compliant with HTTP.

> So the net/http should just handle the http request like they do without 
the proxy protocol.

Why should it do that? It would mask a configuration error - either that 
the upstream device is sending with proxy protocol when it should be 
sending plain HTTP, or that the downstream server has not been configured 
correctly to interpret the proxy protocol.

At worst, it would open security problems, when the upstream proxy *thinks* 
it is successfully passing along source IP address information, but the 
downstream server is ignoring it.

Can you point to any other well-known HTTP server implementation which 
ignores inserted PROXY headers like this? I know that Apache doesn't: you 
have to configure each vhost to either use or not use proxy protocol.
https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html#remoteipproxyprotocol

And whilst HTTP is a text protocol (and can distingush between PROXY and 
GET/POST/PUT etc), what about TLS?

On Monday 15 April 2024 at 21:06:37 UTC+1 HappyTobi wrote:

> Hi,
>
> thanks for the answer, but thats not the point.
> I think it's fine to use a library or implement something to add something 
> to the http layer to parse the proxy protocol.
>
> My point is that a http server that is using the standard library always 
>  reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part 
> of the tcp package.
> So the net/http should just handle the http request like they do without 
> the proxy protocol.
> If someone needs to parse the proxy protocol, it's fine to implement or 
> add a 3rd party lib, but I think the "default" should just work.
>
> Brian Candler schrieb am Montag, 15. April 2024 um 20:41:50 UTC+2:
>
>> Your answer was given here:
>> https://github.com/golang/go/issues/65078#issuecomment-1890419683
>>
>> In other words:
>> - net/http handles HTTP
>> - go-proxyprotocol handles the proxy protocol
>> - you combine the two to get the behaviour you want
>>
>> Orthogonal pieces which handle their own responsibilities are a Good 
>> Thing™ IMO.
>>
>> If you want to wrap this up in a library which has the same API as 
>> net/http but implements proxy protocol, you are free to do so (and publish 
>> it, if you wish). However, there is a very high bar for putting 
>> functionality into the core Go library, because the backwards compatibility 
>> promise means it has to be supported forever.
>>  
>> > I have previously posted two issues on this topic, but neither has 
>> been accepted
>>
>> I think that answers your question.
>>
>> On Monday 15 April 2024 at 17:47:24 UTC+1 HappyTobi wrote:
>>
>>> Dear Gophers,
>>>
>>> I would like to bring to your attention.
>>> There is an “issue” with the Go standard implementation when handling 
>>> HTTP requests that are extended by the proxy protocol v1 or v2.
>>>
>>> While the simple HTTP server works fine with regular requests, it fails 
>>> when a proxy protocol is added.
>>>
>>>
>>> Example:
>>>
>>> Simple http server:
>>>
>>> *package* main
>>>
>>>  
>>>
>>> *import* (
>>>
>>> "*fmt*"
>>>
>>> "*net/http*"
>>>
>>> )
>>>
>>>  
>>>
>>> *func* hello(*w* http.ResponseWriter, *req* ***http.Request) {
>>>
>>> fmt.Fprintf(w, "*hello world**\n*")
>>>
>>> }
>>>
>>>  
>>>
>>> *func* main() {
>>>
>>> http.HandleFunc("*/hello*", hello)
>>>
>>> http.ListenAndServe("*:8080*", *nil*)
>>>
>>> }
>>>
>>> The server is working fine when you do something like:
>>>
>>> curl -kv http://*localhost:8080/hello*
>>>
>>>  
>>>
>>> But the implementation is failing when you add a proxy protocol (v1) to 
>>> the tcp request.
>>>
>>> curl -kv *--*haproxy-protocol http://*localhost:8080/hello*
>>>
>>>  
>>>
>>> The issue arises because the implementation fails to read the HTTP 
>>> message, as the message starts with the proxy protocol. 
>>> Go read request function: 
>>> https://github.com/golang/go/blob/91c04826723a10f6778a935e743a34de81312489/src/net/http/request.go#L1068
>>>  
>>>
>>> The proxy protocol is widely used, and it would be beneficial for the Go 
>>> standard implementation to handle such requests.
>>>
>>>  
>>>
>>> I have previously posted two issues on this topic, but neither has been 
>>> accepted. I would like to open a discussion on this topic and work towards 
>>> implementing a solution that could be merged into the Go standard library. 
>>> Your input and feedback is more than welcome!
>>>
>>> Thank you all.
>>>
>>>  
>>>
>>> Github issue links that I posted:
>>>
>>> net/http: Http Server (request) is not working with enabled Proxy 
>>> Protocol · Issue #64365 · golang/go (github.com) 
>>> 
>>>
>>> proposal: net/tspsock: filter/interceptor - concept with default 
>>> implementation for proxyprotocol (v1/v2) · Issue 

[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)

['Brian Candler' via golang-nuts]

Your answer was given here:
https://github.com/golang/go/issues/65078#issuecomment-1890419683

In other words:
- net/http handles HTTP
- go-proxyprotocol handles the proxy protocol
- you combine the two to get the behaviour you want

Orthogonal pieces which handle their own responsibilities are a Good Thing™ 
IMO.

If you want to wrap this up in a library which has the same API as net/http 
but implements proxy protocol, you are free to do so (and publish it, if 
you wish). However, there is a very high bar for putting functionality into 
the core Go library, because the backwards compatibility promise means it 
has to be supported forever.
 
> I have previously posted two issues on this topic, but neither has been 
accepted

I think that answers your question.

On Monday 15 April 2024 at 17:47:24 UTC+1 HappyTobi wrote:

> Dear Gophers,
>
> I would like to bring to your attention.
> There is an “issue” with the Go standard implementation when handling HTTP 
> requests that are extended by the proxy protocol v1 or v2.
>
> While the simple HTTP server works fine with regular requests, it fails 
> when a proxy protocol is added.
>
>
> Example:
>
> Simple http server:
>
> *package* main
>
>  
>
> *import* (
>
> "*fmt*"
>
> "*net/http*"
>
> )
>
>  
>
> *func* hello(*w* http.ResponseWriter, *req* ***http.Request) {
>
> fmt.Fprintf(w, "*hello world**\n*")
>
> }
>
>  
>
> *func* main() {
>
> http.HandleFunc("*/hello*", hello)
>
> http.ListenAndServe("*:8080*", *nil*)
>
> }
>
> The server is working fine when you do something like:
>
> curl -kv http://*localhost:8080/hello*
>
>  
>
> But the implementation is failing when you add a proxy protocol (v1) to 
> the tcp request.
>
> curl -kv *--*haproxy-protocol http://*localhost:8080/hello*
>
>  
>
> The issue arises because the implementation fails to read the HTTP 
> message, as the message starts with the proxy protocol. 
> Go read request function: 
> https://github.com/golang/go/blob/91c04826723a10f6778a935e743a34de81312489/src/net/http/request.go#L1068
>  
>
> The proxy protocol is widely used, and it would be beneficial for the Go 
> standard implementation to handle such requests.
>
>  
>
> I have previously posted two issues on this topic, but neither has been 
> accepted. I would like to open a discussion on this topic and work towards 
> implementing a solution that could be merged into the Go standard library. 
> Your input and feedback is more than welcome!
>
> Thank you all.
>
>  
>
> Github issue links that I posted:
>
> net/http: Http Server (request) is not working with enabled Proxy Protocol 
> · Issue #64365 · golang/go (github.com) 
> 
>
> proposal: net/tspsock: filter/interceptor - concept with default 
> implementation for proxyprotocol (v1/v2) · Issue #65078 · golang/go 
> (github.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/4aa1edea-4c34-44ea-80fb-84743443f77en%40googlegroups.com.

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

['Brian Candler' via golang-nuts]

I clicked the "Report message" button for each of them, selecting type of 
abuse "Spam". Whether anyone reads these is doubtful though.

The first spam was on 3 Jan 2024 and I reported it straight away; it hasn't 
stopped the new ones coming through.

On Saturday 30 March 2024 at 10:21:18 UTC Steven Hartland wrote:

> Johans account looks like a bot designed to inject links, possibly 
> malicious, is there an admin who can investigate and take the appropriate 
> action?
>
>
> On Fri, 29 Mar 2024 at 12:11, Johan Liebert  wrote:
>

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

Re: [go-nuts] Nil pointer panic that should be impossible

['Brian Candler' via golang-nuts]

And as Axel's own reproducer shows, even having two threads reading and 
writing the same *variable* which points to a string can result in 
indeterminate behaviour, since a string is really a struct containing two 
parts (a pointer and a len).  You're not mutating the string itself, but 
you are updating a variable at the same time as it's being read.

In this regard, Go is no more thread-safe than C or C++, unless you make 
use of the concurrency features it provides (i.e. channels) instead of 
concurrently reading and writing the same variables.

On Monday 25 March 2024 at 13:18:15 UTC Axel Wagner wrote:

> TBQH the word "mutable" doesn't make a lot of sense in Go (even though the 
> spec also calls strings "immutable").
> Arguably, *all* values in Go are immutable. It's just that all *pointers* 
> in Go allow to modify the referenced variables - and some types allow you 
> to get a pointer to a shared variable, which strings don't.
>
> That is, a `[]byte` is immutable - you have to write `x = append(x, v)` 
> specifically because `append` creates a new slice value and overwrites the 
> variable `x` with it.
> However, a `[]byte` refers to an underlying array and `[0]` allows you 
> to obtain a pointer to that underlying array. So a `[]byte` represents a 
> reference and that reference allows to mutate the referenced storage 
> location. The same goes for a `*T`, a `map[K]V`, or a `type S struct{ X 
> int; P *int }` - `S` itself is immutable, but `S.X` is a reference to some 
> potentially shared variable.
>
> A `string` meanwhile, does not allow you to obtain a pointer to the 
> underlying storage and that's what makes it "immutable". And that does 
> indeed mean that if you pass a `string` value around, that can't lead to 
> data races, while passing a `[]byte` around *might*.
>
> But for this case, it doesn't really matter whether or not the field is a 
> `string` or a `[]byte` or an `int`: Because the "mutable" type is the 
> `*URL`. Which represents a reference to some underlying `URL` variable, 
> that you can then mutate. The race happens because you have a method on a 
> pointer that mutates a field - *regardless* of the type of that field.
>
> I don't know if that helps, it's a bit subtle.
>
> On Mon, Mar 25, 2024 at 1:35 PM 'Lirong Wang' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Wow, i am from other language and i thought `string` is immutable or 
>> something like that, so thread-safe for this operation. learned 
>> something new!!! Thanks 
>> On Thursday, March 21, 2024 at 11:42:24 PM UTC+8 Ethan Reesor wrote:
>>
>>> I hadn't used the race detector before. I do see a race warning for 
>>> (*URL).String() among an embarrassing number of other results. I'm going to 
>>> update (*URL).String() to use atomic.Pointer to remove the race.
>>>
>>> Thanks,
>>> Ethan
>>>
>>> On Thu, Mar 21, 2024 at 8:59 AM 'Axel Wagner' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
 On Thu, Mar 21, 2024 at 2:48 PM 王李荣  wrote:

> hi Axel, 
>
> is not modifying `u.memoize.str` thread-safe?  the len and the data 
> point should become visible at same time?
>

 What makes you think that? To be clear, there are no benign data races. 
 Even a data-race on a variable smaller than a word is still a data-race, 
 unless you do it holding a lock or using atomic instructions. But strings 
 are *larger* than single words.

 To demonstrate that the effect I am talking about is real, look at this 
 code: https://go.dev/play/p/LzRq9-OH-Xb
  

>
> 在2024年3月16日星期六 UTC+8 06:29:06 写道：
>
>> Have you tried running the code with the race detector enabled? I 
>> suspect that you are concurrently modifying `u.memoize.str` by calling 
>> `u.String()` from multiple goroutines. And the non-zero length of the 
>> string header written by one goroutine becomes visible to the other one, 
>> before the modification to the data pointer.
>>
>> On Fri, Mar 15, 2024 at 11:15 PM Ethan Reesor  
>> wrote:
>>
>>> From this CI job 
>>> :
>>>
>>> panic: runtime error: invalid memory address or nil pointer 
>>> dereference
>>> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 
>>> pc=0x51d8b7]
>>> goroutine 1589381 [running]:
>>> strings.EqualFold({0xc000beec20?, 0x0?}, {0x0?, 0xacace7?})
>>>  /usr/local/go/src/strings/strings.go: +0x37
>>>
>>> gitlab.com/accumulatenetwork/accumulate/pkg/url.(*URL).Equal(0xc000a74e40?,
>>>  
>>> 0xc00094c540)
>>>  /builds/accumulatenetwork/accumulate/pkg/url/url.go:472 +0x10c
>>>
>>> This is in a docker container based on the go:1.22 image, so the 
>>> panic appears to be happening here:
>>>
>>> func EqualFold(s, t string) bool {
>>> // ASCII fast path
>>> i := 0
>>> for ; i < len(s) && i < len(t); i++ {

Re: [go-nuts] Nillable basic types?

['Brian Candler' via golang-nuts]

I got the impression the proposal was motivated by scalars that did not 
currently allow `nil` values


Under the heading "Alternatives and why they're bad" he describes some ways 
this is currently dealt with - such as the common idiom of returning or 
passing a pointer to a value, instead of a plain value.  (He didn't mention 
using an interface, incidentally - which doesn't have some of the downsides 
he described. For example, a plain numeric value wrapped in an interface 
can't be mutated)

As has already been observed, if you're going to allow the full range of 
values of some type T (i.e. all possible bit patterns), *plus* the sentinel 
value of "unset", then you need an extra bit - which can be done using a 
struct, or by indirecting through a pointer or an interface. 

The problem that the OP has is that none of those options will force you to 
check the state of the extra bit, or that the pointer/interface is not nil 
- which could be argued is a problem with pointers/interfaces in general.

But I think this is not really worth arguing. If you change fundamental 
things like this in the language, then you'll suggesting turning Go into 
something that looks like Rust. In which case, you may as well just use 
Rust.

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

Re: [go-nuts] Nillable basic types?

['Brian Candler' via golang-nuts]

On Wednesday 20 March 2024 at 09:01:43 UTC Mike Schinkel wrote:

Your comments made me go back and read the whole thing, but I was unable to 
find a list of enumerated objectives, and I did not find the text you 
quoted.  Did I miss it somehow?


It's in the very first post that opened this thread, under the heading "## 
Summary". This link should take you to it:
https://groups.google.com/g/golang-nuts/c/pN0AO7a_S2k/m/3osyz_NyBgAJ

Quoting directly:

# Proposal: Nillable types

## Summary

I propose that for any type T, the type `T | nil` should also be a valid 
type with the following properties:
1. The zero value of a `T | nil` is `nil`.
2. Any `T` or `nil` may be used as a value of `T | nil`
3. It is a compile-time error to use a `T | nil` as a `T` without first 
checking that it is non-nil.

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

Re: [go-nuts] Nillable basic types?

['Brian Candler' via golang-nuts]

When you say "var x NillableUint8" then you've just declared a variable of 
an interface type, and interface types are already nilable, so there's no 
need for "| nil" in the type!

https://go.dev/play/p/f54akG65qJ3
https://go.dev/play/p/Jmtlta0h9m9   // generic version

It's a perfectly valid way of specifying an optional value ("error" works 
this way, after all). However, I don't think this meets the OP's  objective 
number 3:

> 3. It is a compile-time error to use a `T | nil` as a `T` without first 
checking that it is non-nil.

Therefore I think the underlying request a completely different one: that 
you should never be able to use an interface (or a pointer or a channel, or 
insert into a map), without first checking that it's not nil, in a way that 
can be statically validated by the compiler. I'm sure that suggestion has 
come up before and been discussed to death - e.g. you end up with static 
types like "a pointer which can never be nil".

On Wednesday 20 March 2024 at 07:34:10 UTC Mike Schinkel wrote:

> On Mar 19, 2024, at 2:43 PM, Daniel Lepage  wrote:
>
> I'm not proposing that *any* value be made nillable, I'm proposing the 
> explicit syntax
>
> var x uint8 | nil
>
> that would create a nillable uint8. A variable of type `byte` would still 
> only take up one byte; a variable of type `byte | nil` would be larger. 
> Existing code, which obviously doesn't use the `| nil` syntax because it 
> doesn't exist yet, would be completely unaffected by this change.
>
>
> Focusing the proposal like that was helpful, at least for me.  The 
> original proposal? tldr; 
>
> Question: Assuming the following was currently possible with type 
> constraints, how would your proposal differ from the following?
>
> type NillableUInt8 interface {
>
>uint8 | nil 
>
> }
>
> var x NillableUInt8
>
>
> Also, if the above were possible in future Go, would that achieve the same 
> objectives you are seeking, or not?  And if not, why not?
>
> Finally, for the Go team, if that would be meet his objectives, would 
> extending type constraints in this manner be a viable potential?
>
>
> -Mike
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9e78e0c1-81cc-46c0-87ac-5bfd183093aen%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

['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

['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?

['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

['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?

['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

['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

['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

['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

['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

['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

['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?

['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?

['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

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

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

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

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 
.

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

['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?

['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

['Brian Candler' via golang-nuts]

Documentation could certainly be improved, since the Part.Close() method 
 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

['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)?

['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)?

['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

['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

['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?

['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?

['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

['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

['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

['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

['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

['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

['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' ?

['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' ?

['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?

['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?

['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)

['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

['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

['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

['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?

['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

['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?

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

Re: [go-nuts] sql string not interpolated as expected

['Brian Candler' via golang-nuts]

I think the nearest is:

labelStrs := []interface{}{"carnivore", "mammal", "vertebrate"}
rows, err := c.Database.Db.Query(`
select id from mbk_user_label where label_name in (?,?,?)
`, labelStrs...)

Of course, you may need to change the number of question-marks to match 
len(labelStrs), but that's easily done with a helper function.  It would be 
nice if a placeholder could be a list and expand accordingly, though.

On Sunday, 3 January 2021 at 09:29:25 UTC Reto wrote:

> On Sun, Jan 03, 2021 at 12:53:03AM -0800, Alexander Mills wrote:
> > rows, err := c.Database.Db.Query(`
> >
> > select *, (
> > select count(*) from mbk_file_label
> > where file_id = mbk_file.id and label_id IN (
> > select id
> > from mbk_user_label
> > where label_name IN (
> > $2
> > )
> > )
> > ) as xxx
> > from mbk_file
> > where user_id = $1
> > order by xxx DESC
> > `,
> > loggedInUserId,
> > labelStr,
> > )
> >
> >
> > then the query doesnt work and I dont know why?
>
> You might want to debug log your statements in the database engine...
> What you want to do is not what it's doing.
>
> You ask the sql engine to escape the input you give it.
>
> So your question becomes `where label_name in ('"carnivore", "mammal", 
> "vertebrate"')`
> Meaning the string exactly as given as single element.
>
> Maybe that helps: https://stackoverflow.com/a/38878826/6212932 if you use 
> postgres.
>
> Cheers,
> Reto
>

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

Re: [go-nuts] Generics and formatting

['Brian Candler' via golang-nuts]

Raised as https://github.com/golang/go/issues/43470

On Friday, 1 January 2021 at 18:40:36 UTC Ian Lance Taylor wrote:

> On Fri, Jan 1, 2021 at 9:50 AM 'Brian Candler' via golang-nuts
>  wrote:
> >
> > Just a minor issue, but playing with this example:
> > https://go2goplay.golang.org/p/IUL1QDrtOwW
> > - click "Run" and it works
> > - click "Format" and it fails with the following error:
> >
> > prog.go:40:24: expected ']', found ',' (and 6 more errors)
>
> Hmmm, perhaps we failed to update gofmt the last time we updated the
> go2go playground. The gofmt on the tip of the dev.go2go branch does
> seem to work correctly. Can you open an issue at
> https://golang.org/issue? Thanks.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/57571d69-21d9-4d08-810e-32eb2647a928n%40googlegroups.com.

[go-nuts] Re: Generics Error - How to fix?

['Brian Candler' via golang-nuts]

If by "generics doc" you mean this one 
,
 
then note:

*"Generic types can have methods. The receiver type of a method must 
declare the same number of type parameters as are declared in the receiver 
type's definition. They are declared without any constraint."*

That is, you can't define a method on plain Table, but you can define a 
method on Table[T1, T2, T3]

Without actually looking further into what your code is doing, that implies 
the following change:

func (t *Table*[T1, T2, T3]*) Add (a, b, c interface{}){
row := Row {colA: a, colB: b, colC: c}
append(t.rows, row) 
}

However that's also not right, because you're ignoring the return value 
from append (for more info read the blog posting on slices 
).  So:

func (t *Table[T1, T2, T3]) Add (a, b, c interface{}){
row := Row {colA: a, colB: b, colC: c}
t.rows := append(t.rows, row) 
}

The next problem is here:

func (t *Table[T1, T2, T3]) Print (){
fmt.Println("table format is: %v, %v, %v", reflect.TypeOf(t.colATemplate), 
reflect.TypeOf(t.colBTemplate), reflect.TypeOf(t.colCTemplate))
for row := range t.rows {
fmt.Println("%v, %v, %v", row.colA, row.colB, row.colC) 
}
}

*prog.go2:72:33: row.colA undefined (type int has no field or method colA)*
*prog.go2:72:43: row.colB undefined (type int has no field or method colB)*
*prog.go2:72:53: row.colC undefined (type int has no field or method colC)*

Iterating over a slice with just one receiver variable gives you only the 
index.  This needs to be:

func (t *Table[T1, T2, T3]) Print (){
fmt.Println("table format is: %v, %v, %v", reflect.TypeOf(t.colATemplate), 
reflect.TypeOf(t.colBTemplate), reflect.TypeOf(t.colCTemplate))
for _, row := range t.rows {
fmt.Println("%v, %v, %v", row.colA, row.colB, row.colC) 
}
}

This then breaks because t.rows is a slice of interface{}, not a slice of 
Row.  So I changed it to []Row.  Then fixing your Println's to Printf's, 
this gives https://go2goplay.golang.org/p/dAnPU_r0DpM and now it runs.

However, I think this still needs work. There should be no need for 
interface{} in Row; you should use generics for this too, and then your 
Table just needs to be a slice of Row[T1, T2, T3]

On Friday, 1 January 2021 at 15:06:15 UTC da...@suarezhouse.net wrote:

> I thought I read the generics doc well but.. :-)  Help is appreciated:
>
> I instantiate a generic table example here in line 41: 
> https://go2goplay.golang.org/p/SadxA0khqx7 
>
> Then I use it in lines 42 and 43.
>
> The errors I get are below:
> prog.go2:67:10: cannot use generic type Table[colA, colB, colC 
> fmt.Stringer] without instantiation 
> prog.go2:72:10: cannot use generic type Table[colA, colB, colC 
> fmt.Stringer] without instantiation  
>
> I am using the same table.  The method belongs to the struct so I would 
> think should be considered instantiated and that I wouldn't have to repeat 
> in lines 42 and 43 the types.
>
> Is this a bug and it should infer since created in line 41 or what did I 
> misunderstand in the doc?
>
> Thanks in advance for the help!
> David
>

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

[go-nuts] Generics and formatting

['Brian Candler' via golang-nuts]

Just a minor issue, but playing with this example:
https://go2goplay.golang.org/p/IUL1QDrtOwW
- click "Run" and it works
- click "Format" and it fails with the following error:

prog.go:40:24: expected ']', found ',' (and 6 more errors)

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