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

*func main() {for x := range FSeq(strconv.Atoi) { fmt.Println(reflect.TypeOf(x))}}func FSeq[V (... any)](f func(string) V) iter.Seq[V] {return func(yield func(v V) bool)) { yield(f("1234"))}}* *>>> If it wouldn't

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

On Mon, 29 Apr 2024 at 22:06, Andrew Harris wrote: > 2. On implementation, before considering variadic tuple constraints: There > is tuple machinery already in the type system > , used > for assignments and signatures, but tuples

Re: [go-nuts] Re: command to pre-compile vendor libs

> > It all works fine, just wondering if there's a nicer way to get all > > "compilable" packages stored in /vendor. > > go list ./vendor/... I knew there had to be a simpler way, thanks! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: command to pre-compile vendor libs

Harmen once said: > It all works fine, just wondering if there's a nicer way to get all > "compilable" packages stored in /vendor. go list ./vendor/... Cheers, Anthony -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

[go-nuts] command to pre-compile vendor libs

Hi, in both my Nix and Docker builds I have a step to build all libraries in /vendor, and then cache that. Works great, saves me multiple minutes for every CI build. Now I would like to improve the command, this is what I currently use: $ go build -v `cat vendor/modules.txt |grep -v '#'|grep -v

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

Then that type probably won't work with encoding/asn1. If you have control over the call to asn1.Marshal, you could always create a "data transfer object " to translate between this third-party type and a type that you control that has a

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

*> FWIW this kind of restriction has no precedent in Go. Currently any type may be unnamed. This restriction seems arbitrary and irregular to me. * It seems unpopular. *> Isn't this illegal according to your TupleType syntax above? * Further evidence of a wrong idea :) *>> [T (any, any)]

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

Thank you very much for your answer, but I cannot modify the definition of the field because this is the structure of the third-party library. On Monday, April 29, 2024 at 1:01:18 AM UTC+8 Def Ceb wrote: > Most marshal/unmarshal functions are unwilling to marshal/unmarshal > structs with

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

On Sun, 28 Apr 2024 at 12:10, 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

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

Brian: 1: There would be no access to implicitly typed tuple elements. Both implicit and named tuple values would expand with `...`, for example in an assignment like `x, y := (0, 0)...`. (FWIW, #64457 suggested decimal names for tuple elements `.0`, `.1` etc.) 2: #64457 and #66651 revealed

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

I agree with Ian that the named field syntax is too close to structs. For me, tuples start to make sense in Go mainly because they map directly to and from the tuple-like values we already pass to and from functions, and specifically in the context of a variadic type parameter language feature

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

Most marshal/unmarshal functions are unwilling to marshal/unmarshal structs with pointer fields. Changing them to direct values fixes this. Example: https://go.dev/play/p/ykmpBm0bXqn I do not think there is any other simple alternative. J Liu: I understand this problem. My real program uses

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

On Sun, Apr 28, 2024 at 4:10 AM Andrew Harris wrote: > > 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

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

I understand this problem. My real program uses export correctly, but the problem I have is not export, asn1: structure error: unknown Go type: *pkg.Girl On Sunday, April 28, 2024 at 9:27:42 AM UTC+8 Jan Mercl wrote: > > > On Sun, Apr 28, 2024, 03:03 J Liu <88592...@gmail.com> wrote: > >> My

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

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

[go-nuts] tuples! tuples! tuples!

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

Re: [go-nuts] Re: all.bash fails on Ubuntu 24.04?

As mentioned in #67088 TestAmbientCaps is skipped because the execve call returns operation not permitted (EPERM). It is not successful as I wrote. Am Sa., 27. Apr. 2024 um 22:58 Uhr schrieb Uli Kunitz : > I agree. Ubuntu 22.04 has gdb version 12.1, Ubuntu 24.04 has 15.0.50. > > The second bug

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

On Sun, Apr 28, 2024, 03:03 J Liu <8859210...@gmail.com> wrote: > My program is like this: > > type Girl struct { > Name string > Age int > } > > type Person struct { > girl *Girl > job string > } > > > What should I do to Marshal 'Person'? > I think you need to export

[go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

My program is like this: type Girl struct { Name string Age int } type Person struct { girl *Girl job string } What should I do to Marshal 'Person'? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

[go-nuts] Re: all.bash fails on Ubuntu 24.04?

I agree. Ubuntu 22.04 has gdb version 12.1, Ubuntu 24.04 has 15.0.50. The second bug may be a change by kernel 6.8 in the handling of ambient capabilities if the user namespace is changed. The test without changing the user namespace is successful. I have created two issues for the two

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

Yes. It is this https://github.com/robaho/fixed/blob/5493e8737df761ffcf6be9441b4b8ae41fcf5da4/fixed_bench_test.go#L10On Apr 27, 2024, at 10:31 AM, Steven Hartland wrote:Do you have the test code for that specific test?That would allow others to have a look at it and also confirm if the test is

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

Do you have the test code for that specific test? That would allow others to have a look at it and also confirm if the test is somehow optimising the function call away. On Sat, 27 Apr 2024 at 05:12, robert engels wrote: > Apologies. The assembly files were reversed. But the timings remain the

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

Why would it be optimized away in 1.12 and not optimized away in 1.21?I could have made a mistake in my recording so I’ll test it again tomorrow. On Apr 26, 2024, at 10:03 PM, 'Keith Randall' via golang-nuts wrote:Isn't that assembly exactly the opposite? The code that is passing in registers

Re: [go-nuts] time.ParseDuration does not accept scientific notation

On Friday, April 26, 2024 at 6:08:02 PM UTC-6 Ian Lance Taylor wrote: The first step would be to open a proposal for this change. See https://github.com/golang/proposal#readme. Thanks. Done: proposal: time: allow scientific notation in ParseDuration

[go-nuts] Re: all.bash fails on Ubuntu 24.04?

The first issue there could very well be an incompatibility with the gdb version. On Thursday, April 25, 2024 at 11:02:00 PM UTC-7 Uli Kunitz wrote: > Hi, > > I have installed Ubuntu 24.04 yesterday and there are two failures running > all.bash compiling go from source. I want to check whether

Re: [go-nuts] time.ParseDuration does not accept scientific notation

On Fri, Apr 26, 2024 at 3:39 PM Scott Pakin wrote: > > While parsing output from some third-party program, I discovered that > time.ParseDuration does not accept inputs expressed in scientific notation > even though strconv.ParseFloat does accept such inputs. Here’s an playground > example

[go-nuts] time.ParseDuration does not accept scientific notation

While parsing output from some third-party program, I discovered that time.ParseDuration does not accept inputs expressed in scientific notation even though strconv.ParseFloat does accept such inputs. Here’s an

[go-nuts] Re: Reproducible builds with CGO

golang will embed the path of the source file into the binary, also the .gopclntab will contains the path. try use -trimpath and see if there's any change. 在2024年4月27日星期六 UTC+8 01:28:05 写道： > Hi All, > > *Does anybody have experience in how the use of CGO and dynamic linking > may affect the

[go-nuts] Reproducible builds with CGO

Hi All, *Does anybody have experience in how the use of CGO and dynamic linking may affect the reproducibility of a Go project?* *Context* I am trying to reproduce a Linux amd64 binary release using the same source commit, os & dist, Go, C compiler, and linker version. It reproduces locally

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

The first few bytes on a new TLS connection will be the record layer bytes denoting a handshake and the TLS version field, so 0x160301 or 0x160303. ASCII-based proxy protocol v1 will start out 0x5052 etc, and binary-based proxy protocol v2 has its own initial 12 byte signature of 0x0D0A0D0A

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

I agree but in this case it is very consistent. Even if that were the case, wouldn’t that mean that 1.12 had better optimization in this case?I will dig in today and report back with the generated code. On Apr 26, 2024, at 12:17 AM, 'Keith Randall' via golang-nuts wrote:> There is a pretty

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

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

[go-nuts] all.bash fails on Ubuntu 24.04?

Hi, I have installed Ubuntu 24.04 yesterday and there are two failures running all.bash compiling go from source. I want to check whether others experienced the same before creating one or two golang issues. git describe --tags returns go1.22.2. Here are the relevant pieces of the ouput of

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

> There is a pretty significant degradation in AddFixed() which may be concerning to the Go team What is the benchmark for this? I am usually suspicious of sub-nanosecond benchmark times. Generally that indicates that the benchmark completely optimized away and all you are measuring is an

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

> 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

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

Thanks. I noticed those but didn’t look into how to address. Appreciate it. I will rerun. > On Apr 25, 2024, at 12:23 PM, Steven Hartland > wrote: > > Thanks for these, not sure if you noticed the notes from each run e.g. need > >= 4 samples to detect a difference at alpha level 0.05. > >

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

Thanks for these, not sure if you noticed the notes from each run e.g. need >= 4 samples to detect a difference at alpha level 0.05. Basically run the benchmark with a -count=6 or more and then run the tool, and you get a the comparison values which are typically the interesting bit On Thu, 25

Re: [go-nuts] xml to json, parsing xml

I could really have used the go-xmlstruct a year ago :-) But, if I need to fill in more blanks I will try it! On Thursday 25 April 2024 at 02:24:45 UTC+1 twp...@gmail.com wrote: > You can parse XML and JSON quickly with these tools: > > https://github.com/twpayne/go-xmlstruct >

Re: [go-nuts] xml to json, parsing xml

You can parse XML and JSON quickly with these tools: https://github.com/twpayne/go-xmlstruct https://github.com/twpayne/go-jsonstruct They generate Go code that parses all the example XML and JSON files that you throw at them. Regards, Tom On Tuesday, April 23, 2024 at 9:17:33 PM UTC+2 Don

[go-nuts] Re: Offline version of A Tour of Go

thanks this was helpful. Is there a good rule of thumb when updating old "go get" instructions. e.g. Go Tour (googlesource.com)

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

And for the 1.12 vs 1.22: │ /Users/robertengels/go1.12.17.txt │ /Users/robertengels/go1.22.2.txt│ │ sec/op │sec/op vs base │ AddFixed-8 0.5900n ± ∞ ¹ 0.7931n ± ∞ ¹~

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

│ /Users/robertengels/go1.21.5.txt │ /Users/robertengels/go1.22.2.txt│ │

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

What’s it look like when your run it through https://pkg.go.dev/golang.org/x/perf/cmd/benchstat which will provide a nice side by side comparison? On Wed, 24 Apr 2024 at 19:26, 'Robert Engels' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I have a fairly stable project

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

Rough guess, it seems about the same. 1.22.2: BenchmarkAddFixed-8 10 0.7931 ns/op 0 B/op 0 allocs/op

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

How does it perform with v1.22.0? I found a small but measurable drop in throughput in one of my projects when compiled with 1.22.0. Issue raised here: https://github.com/golang/go/issues/65647#issuecomment-1944830588 I have a feeling it's an issue with my older development hardware. But it's

[go-nuts] Congrats to the Go team

I have a fairly stable project github.com/robaho/fixed which is almost 100% cpu bound. It doesn’t change so it makes a great way to compare the performance of different Go versions using the same hardware. I took the time to re-run the tests today. Using

Re: [go-nuts] go build v go build .

On Wed, Apr 24, 2024 at 06:24:33PM +0100, Steve Mynott wrote: > Is there any difference between "go build" and "go build ."? The last param of "go build" is the package to build. If you don't specify anything, it builds the package in the current directory. In you second case, it builds the

[go-nuts] go build v go build .

Is there any difference between "go build" and "go build ."? -- Steve Mynott rsa3072/629FBB91565E591955B5876A79CEFAA4450EBD50 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it,

Re: [go-nuts] Where is my type?

Your answer has put me on the right track. Here's the long version: https://stackoverflow.com/questions/48790663/why-value-stored-in-an-interface-is-not-addressable-in-golang On Wednesday, April 24, 2024 at 6:55:53 PM UTC+2 cpu...@gmail.com wrote: > > In the first case, the interface contains

Re: [go-nuts] Where is my type?

> In the first case, the interface contains a value of type S, which is not writable. The value contained in the interface is not addressable. Thank you for the quick feedback. Why is that? Memory for val has been allocated and val is passed by value (hence copied). Why is that copy not be

[go-nuts] Re: Where is my type?

It's worth noting that before the Unmarshal v is {}(main.S) and afterwards {}(map[string]interface{}) On Wednesday, April 24, 2024 at 6:46:18 PM UTC+2 cpu...@gmail.com wrote: > Every time I feel I've come to terms with how Go works I round a corner > and hit a wall, even after doing this for

Re: [go-nuts] Where is my type?

In the first case, the interface contains a value of type S, which is not writable. The value contained in the interface is not addressable. So Unmarshal creates a new map and fills that. In the second case the interface contains *S, which is writable, so unmarshal fills it in via reflection. On

[go-nuts] Where is my type?

Every time I feel I've come to terms with how Go works I round a corner and hit a wall, even after doing this for >5 years. Here's one. Consider this simple code (https://go.dev/play/p/bph5I80vc99): package main import ( "encoding/json" "fmt" ) type S struct { Foo int } func update(v any) {

Re: [go-nuts] Critical Section - static analysis

The github link you provided results in a 404 error. > On Apr 22, 2024, at 1:58 PM, Stephen Illingworth > wrote: > > Hello, > > I've created a proof-of-concept for a method of defining critical sections. > Crucially, the scheme allows for static analysis, thereby helping prevent > violations

Re: [go-nuts] xml to json, parsing xml

Oops, I didn't look carefully at the json output of my little program. It does sometimes emit arrays. For example: go build xmlparse.go ./xmlparse -url 'https://news.google.com/atom' This produces what, for some part, represents acceptable json. The exceptions are the atom entries that would

Re: [go-nuts] generics question

On Mon, Apr 22, 2024 at 11:01 PM Jochen Voss wrote: > > This works, see my code below. Followup question: is there a way to refer to > the new type without having to list both the element type and the pointer > type separately? Unfortunately there is not. At some point in the future the

Re: [go-nuts] xml to json, parsing xml

I agree. The link that I sent demonstrates one very simple way. Mapping XML with repetitive tag sets to JSON arrays, though, would take a bit of work meaning, I think, at least two passes. D On Tue, Apr 23, 2024, 13:04 robert engels wrote: > I don’t think that is true. There are multiple ways

Re: [go-nuts] xml to json, parsing xml

I don’t think that is true. There are multiple ways to model XML into json. See this http://badgerfish.ning.com for one of them. > On Apr 23, 2024, at 11:43 AM, burak serdar wrote: > > In general, you cannot convert xml to json. They have incompatible > models.

Re: [go-nuts] Re: xml to json, parsing xml

In general, you cannot convert xml to json. They have incompatible models. XML elements are ordered similar to a JSON array, but in many cases you want to map XML elements to JSON objects, which are unordered name-value collections. Also, there is no JSON equivalent of an XML attribute. If you

[go-nuts] Re: xml to json, parsing xml

Disclaimer - I am very new to golang. I puzzled about this for a few days. After some struggle, I got a little program working that parses arbitrary xml into a structure that json can understand. You can find it here: https://github.com/dfwcnj/gxmldecode On Thursday, October 7, 2021 at 10:06:30 

Re: [go-nuts] generics question

Thank you both! This works, see my code below. Followup question: is there a way to refer to the new type without having to list both the element type and the pointer type separately? Below I have to write C[A, *A], which looks slightly ugly. And in my real application something like

Re: [go-nuts] generics question

On Mon, Apr 22, 2024 at 9:54 PM Ian Lance Taylor wrote: > > On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss wrote: > > > > Using generics, can I somehow write a constraint which says that *T > > (instead of T) implements a certain interface? The following code > > illustrated what I'm trying to

Re: [go-nuts] generics question

On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss wrote: > > Using generics, can I somehow write a constraint which says that *T (instead > of T) implements a certain interface? The following code illustrated what > I'm trying to do: > > type A int > > func (a *A) Set(x int) { > *a = A(x) > } > >

Re: [go-nuts] Is golang.org/x/text/message's Printer thread safe?

Thanks for the tip! Jan Mercl <0xj...@gmail.com> 于2024年4月22日周一 17:38写道： > On Mon, Apr 22, 2024 at 11:23 AM Xiangrong Fang wrote: > > > Is golang.org/x/text/message's *message.Printer safe to use in > goroutines? > > I don't know, but usually things are safe for concurrent use by > multiple

[go-nuts] generics question

Using generics, can I somehow write a constraint which says that *T (instead of T) implements a certain interface? The following code illustrated what I'm trying to do: type A int func (a *A) Set(x int) { *a = A(x) } type B string func (b *B) Set(x int) { *b = B(strconv.Itoa(x)) } type C1

[go-nuts] Critical Section - static analysis

Hello, I've created a proof-of-concept for a method of defining critical sections. Crucially, the scheme allows for static analysis, thereby helping prevent violations of the critical sections. It's a simple concept but I think it's something that can be built upon.

Re: [go-nuts] error : undefined: app.NewWindow

The latest tagged version of Gio removed that function. Please have a look at the release notes: https://gioui.org/news/2024-04 Hth, -s Apr 22, 2024 19:56:34 Ian Lance Taylor : > On Mon, Apr 22, 2024 at 10:54 AM AndyPeng wrote: >> >> Imported the "gioui.org/app" package,but got an error

Re: [go-nuts] error : undefined: app.NewWindow

On Mon, Apr 22, 2024 at 10:54 AM AndyPeng wrote: > > Imported the "gioui.org/app" package,but got an error when compiling: > undefined: app.NewWindow. Please tell us exactly what you did and exactly what happened. Show us the code. Ian -- You received this message because you are subscribed

[go-nuts] error : undefined: app.NewWindow

Imported the "gioui.org/app" package,but got an error when compiling: undefined: app.NewWindow. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[go-nuts] Manual changes to /go/pkg/mod ?

Hello, I would like to ask you all, what will the Go compiler do, if somebody manually modifies the package stored in the /go/pkg/mod? Will the compiler redownload the unmodified change? Will the compiler recognise there has been a change in the mod folder? Regards, Peter. -- You received

Re: [go-nuts] Is golang.org/x/text/message's Printer thread safe?

On Mon, Apr 22, 2024 at 11:23 AM Xiangrong Fang wrote: > Is golang.org/x/text/message's *message.Printer safe to use in goroutines? I don't know, but usually things are safe for concurrent use by multiple goroutines only when explicitly documented as such. -- You received this message because

[go-nuts] Is golang.org/x/text/message's Printer thread safe?

Is golang.org/x/text/message's *message.Printer safe to use in goroutines? 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

Re: [go-nuts] compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http package

Thanks for informing it is actually installed fine at the time it is failing the test. My TCL VM is running as a nested VM, and resources are limited (one CPU, 8GB Ram is assigned for this VM). Assuming only fixes are back-ported to 1.21.x it is likely a fix that affects both 1.22.2 and 1.21.9 in

Re: [go-nuts] Re: couldn't print numbers ordered with goroutine

On Sun, 2024-04-21 at 15:06 +1200, Justin Israel wrote: > And really I wasn't even commenting on the nature of the channel. > Only the scheduling of the goroutines. Buffered or not, they would > still be random order right?  Absolutely. Your answer was spot on. The issue is the ordering of the

Re: [go-nuts] Re: couldn't print numbers ordered with goroutine

On Sun, Apr 21, 2024, 2:07 PM 'Dan Kortschak' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Sat, 2024-04-20 at 18:55 -0700, Robert Solomon wrote: > > channels are not queues, as Justin said > > They can be; buffered channels are queues. > > From https://go.dev/ref/spec#Channel_types

Re: [go-nuts] compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http package

On Sat, Apr 20, 2024 at 7:34 PM Ron Hermsen wrote: > > compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http > package > > I tried a number of earlier releases but looks only the latest two fail. > (each build takes about 40min, so didn't try more options) > > > ok

[go-nuts] compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http package

compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http package I tried a number of earlier releases but looks only the latest two fail. (each build takes about 40min, so didn't try more options) ok net 8.598s panic: test timed out after 9m0s running tests: FAIL

Re: [go-nuts] Re: couldn't print numbers ordered with goroutine

On Sat, 2024-04-20 at 18:55 -0700, Robert Solomon wrote: > channels are not queues, as Justin said They can be; buffered channels are queues. >From https://go.dev/ref/spec#Channel_types > Channels act as first-in-first-out queues. For example, if one > goroutine sends values on a channel and a

[go-nuts] Re: couldn't print numbers ordered with goroutine

channels are not queues, as Justin said On Saturday, April 20, 2024 at 8:18:18 PM UTC-4 Justin Israel wrote: > On Sunday, April 21, 2024 at 11:18:24 AM UTC+12 Taňryberdi Şyhmyradow > wrote: > > Hello guys, > For the following lines, I wanted to print numbers in ordered, but > couldn't. Could

[go-nuts] Re: couldn't print numbers ordered with goroutine

On Sunday, April 21, 2024 at 11:18:24 AM UTC+12 Taňryberdi Şyhmyradow wrote: Hello guys, For the following lines, I wanted to print numbers in ordered, but couldn't. Could you please help me and explain the reason Thanks in advance ``` numbers := []int{1, 2, 3, 4, 5} // Create a buffered

[go-nuts] couldn't print numbers ordered with goroutine

Hello guys, For the following lines, I wanted to print numbers in ordered, but couldn't. Could you please help me and explain the reason Thanks in advance ``` numbers := []int{1, 2, 3, 4, 5} // Create a buffered channel to handle multiple values printed := make(chan int, len(numbers)) for _, n

Re: [go-nuts] why math.Pow gives different results depending on exp type

Also, Staticcheck catches this: $ curl -Os https://go.dev/play/p/oIKGb_uyLb3.go $ staticcheck oIKGb_uyLb3.go oIKGb_uyLb3.go:9:38: the integer division '1 / 13' results in zero (SA4025) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] why math.Pow gives different results depending on exp type

This has nothing to do with the math.Pow function. Dividing two ints (1/13) is not the same as dividing a float by an int (1.0/13). Replace your two `fmt.Printf()` calls with println(1 / 13) println(1.0 / 13) and observe the difference. The fact that both `math.Pow` arguments are of type

Re: [go-nuts] why math.Pow gives different results depending on exp type

On Fri, 2024-04-19 at 22:51 -0700, DrGo wrote: > ``` > package main > > import ( > "fmt" > "math" > ) > > func main() { > fmt.Printf("%g\n", 1-(math.Pow(0.6, 1/13)))   //result=0 > fmt.Printf("%g\n", 1-(math.Pow(0.6, 1.0/13))) // > result=0.038532272011602364 > } > ```

[go-nuts] why math.Pow gives different results depending on exp type

``` package main import ( "fmt" "math" ) func main() { fmt.Printf("%g\n", 1-(math.Pow(0.6, 1/13))) //result=0 fmt.Printf("%g\n", 1-(math.Pow(0.6, 1.0/13))) // result=0.038532272011602364 } ``` https://go.dev/play/p/oIKGb_uyLb3 -- You received this message because you are subscribed to the

Re: [go-nuts] Re: Concurrent queries in a single transaction

As you state, the driver (and db) need to support this. The synchronization for something like this is internal. But, if the operations are modifying the same tables you may end up with serialized operations anyway in order to ensure consistency while avoiding deadlocks. On Apr 20, 2024, at 12:11 

[go-nuts] Re: Concurrent queries in a single transaction

Does any solution exist for this problem? I'm facing similar problem, want to run bunch of queries inside a transaction, but want to run them concurrently, as running sequential is taking more than 1 second. On Friday, June 29, 2018 at 6:32:40 PM UTC+5:30 Space A. wrote: > Hi, > > DB in

Re: [go-nuts] Re: go mod conflict whith v2 pre-release

@Jason That's really helpful, thanks. I/we adopted Go long after modules were introduced and have never had to deal with GOPATH mode, which probably explains why I didn't read the aspects relating to that (or wiped them from my memory subsequently - lol). On Friday 19 April 2024 at 02:02:36

[go-nuts] go tool covdata SDK

is there a way to invoke `go tool covdata` programmatically in a go application ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [go-nuts] Re: go mod conflict whith v2 pre-release

@Jolyon > Is this the correct approach to major-v-bumping a module? There are two approaches supported by the Go tooling. This is one of them. Neither is more correct than the other, there are pros and cons to each. Using a major version directory has the benefit of working transparently with

Re: [go-nuts] Re: go mod conflict whith v2 pre-release

As a matter of fact, I gained a somewhat complete understanding of the whole concept of Go modules and the go-get facade mechanism through writing a simple pkgsvr (https://xrfang.coding.net/public/go/pkgsvr/git/files). However, before this issue came up, I hadn't noticed the significance of the

Re: [go-nuts] Re: go mod conflict whith v2 pre-release

Is this the correct approach to major-v-bumping a module? I had understood the "vN" slug in the module to be a "virtual" element, signalling the deliberate introduction of an upgrade to a new major version of a dependency. i.e. it avoids (or at least makes less likely) the chance of

Re: [go-nuts] Is it possible to "extract" the generic [T] from a reflected type ?

If I understand correctly, the restriction is that the compiler has to know all possible instantiations of a generic func/type/etc at compile time. So listing out each specific Hello instantiation is the workaround, which allows you to approximate this if you have a closed set of types you want

Re: [go-nuts] Re: go mod conflict whith v2 pre-release

Yeah. After clean modcache. Thanks! Jason Phillips 于2024年4月17日周三 22:41写道： > It works for me, now. > > > go get go.xrfang.cn/hap/v2@v2.0.0-alpha.2 > go: downloading go.xrfang.cn/hap/v2 v2.0.0-alpha.2 > go: go.xrfang.cn/hap/v2@v2.0.0-alpha.2 requires go >= 1.22.1; > switching to

Re: [go-nuts] Re: go mod conflict whith v2 pre-release

It works for me, now. > go get go.xrfang.cn/hap/v2@v2.0.0-alpha.2 go: downloading go.xrfang.cn/hap/v2 v2.0.0-alpha.2 go: go.xrfang.cn/hap/v2@v2.0.0-alpha.2 requires go >= 1.22.1; switching to go1.22.2 go: upgraded go 1.22.0 => 1.22.1 go: added toolchain go1.22.2 go: added

Re: [go-nuts] Re: go mod conflict whith v2 pre-release

Hi Jason, Acutally I wrote the go hosting service myself. According to your comments, I modified the output now it is: $ curl https://go.xrfang.cn/hap/v2?go-get=1 https://e.coding.net/xrfang/go/hap.git;> But it still not working: $ GOPROXY=direct go get -v -x -u

[go-nuts] Re: go mod conflict whith v2 pre-release

I believe the hosting provider is returning a meta tag for "go.xrfang.cn/hap/v2" when it shouldn't? > curl https://go.xrfang.cn/hap/v2?go-get=1 https://e.coding.net/xrfang/go/hap.git;> The above meta tag says that the "go.xrfang.cn/hap/v2" module is at the root of the repository, but

[go-nuts] go mod conflict whith v2 pre-release

Hello, I am developing version 2 of my hap package, which is a HTTP API framework. Version 2 is not ready yet, and the latest release ls v2.0.0-alpha.2, like so: * 9319436 - bug fix, refined action error output

Re: [go-nuts] Executing JAR from Go

On Tue, Apr 16, 2024 at 11:09 PM Shivli Srivastava wrote: > On Wed, Apr 17, 2024 at 11:37 AM Shivli Srivastava > wrote: > >> java -cp /Users/shivli.srivastava/Downloads/jars/bcmail-jdk15on- >> 159.jar:/Users/shivli.srivastava/Downloads/jars/ >>

Re: [go-nuts] Executing JAR from Go

*The class should be written as org.Sign instead of org/Sign.* I tried with both , both are valid options On Tue, Apr 16, 2024 at 11:04 AM Roland Müller wrote: > The class should be written as org.Sign instead of org/Sign. > > Am Dienstag, 16. April 2024 schrieb Kurtis Rader : > > On Mon, Apr

  1   2   3   4   5   6   7   8   9   10   >