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 > } > ```

Re: [go-nuts] Why can't I use an interface which needs another interface inside of it

> On Mar 13, 2024, at 10:27 AM, Brian Hatfield wrote: > > Client.GetChild() must return GetChilder, not Child. Actually, Client.GetChild() must return b.GetDataer, not b.GetChilder, but the example is a mind bender so it was easy to get wrong. I only got it correct by testing the code and

Re: [go-nuts] Why can't I use an interface which needs another interface inside of it

Regardless, that's the reason what you've attempted doesn't work. It has its own entry in the Go FAQ: https://go.dev/doc/faq#covariant_types On Wednesday, March 13, 2024 at 1:00:34 PM UTC-4 Rodrigo Araujo wrote: > 'Cause this dependency makes code more "rigid". A refactor in an isolated >

Re: [go-nuts] Why can't I use an interface which needs another interface inside of it

'Cause this dependency makes code more "rigid". A refactor in an isolated package would let to change other packages. Also makes testing more difficult. It is kind of described here: https://go.dev/wiki/CodeReviewComments#interfaces Em qua., 13 de mar. de 2024 às 13:41, burak serdar escreveu: >

Re: [go-nuts] Why can't I use an interface which needs another interface inside of it

On Wed, Mar 13, 2024 at 10:31 AM Rodrigo Araujo wrote: > > Do you mean b.GetChilder? In this case, package A will depend on package B > and I don't think this is a good approach. Why would it not be a good approach? You have a package declaring interfaces, and if you have another package using

Re: [go-nuts] Why can't I use an interface which needs another interface inside of it

Do you mean b.GetChilder? In this case, package A will depend on package B and I don't think this is a good approach. Em qua., 13 de mar. de 2024 às 11:28, Brian Hatfield escreveu: > Client.GetChild() must return GetChilder, not Child. > > On Wed, Mar 13, 2024 at 10:02 AM Rodrigo Araujo wrote:

Re: [go-nuts] Why can't I use an interface which needs another interface inside of it

Client.GetChild() must return GetChilder, not Child. On Wed, Mar 13, 2024 at 10:02 AM Rodrigo Araujo wrote: > Given the code bellow, I'm trying to keep my packages completely > separated, without knowing each other, but the code doesn't work. I just > can get it running when I define (or use)

Re: [go-nuts] Why Go opt for using * in signature of function that returns a pointer instead of using &?

Thank for your answers, makes a lot of sense. Em quarta-feira, 6 de março de 2024 às 02:24:50 UTC-3, Kurtis Rader escreveu: > Anyone familiar with C/C++ will be familiar with the current convention of > using an asterisk to indicate a pointer to the value. Yes, there is a > reasonable

Re: [go-nuts] Why Go opt for using * in signature of function that returns a pointer instead of using &?

Anyone familiar with C/C++ will be familiar with the current convention of using an asterisk to indicate a pointer to the value. Yes, there is a reasonable argument for using an ampersand but either syntax is essentially arbitrary; thus a coin flip as to which to use. So we might as well use the C

Re: [go-nuts] Why Go opt for using * in signature of function that returns a pointer instead of using &?

On Tue, Mar 5, 2024, 8:33 PM Matheus Fassis Corocher < matheuscoroc...@gmail.com> wrote: > I was studying about pointers and struct in Golang and one thing that I > don't understand is why using * in return of signature of function instead > of & if the return of function is an address of

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Any updates on ROC for golang? I think our services encountered some scalability issues, similar to https://github.com/golang/go/issues/17969 On Tuesday, May 16, 2017 at 10:06:25 PM UTC+8 Ian Lance Taylor wrote: > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compact gc have

Re: [go-nuts] Why causes []any trouble in type equations?

On Oct 11, 2023, at 11:09 AM, Torsten Bronger wrote: > > Then, all boils down to the fact that you can’t pass []float64 as an > []any. To be honest, I still don’t fully understand why this is > forbidden, so I just accept that the language does not allow it. I think in the first case []any is

Re: [go-nuts] Why causes []any trouble in type equations?

This has nothing to do with generics. It is a FAQ regarding the conversion of a container type value. You cannot modify the type of the object in a container in a called context. This has been true before generics was introduced. Ignoring generics what do you think should happen if you call a

Re: [go-nuts] Why causes []any trouble in type equations?

In the second case, the type argument is inferred to be `[]float64`. The constraint on `T` in `do` is that it has to be `[]any`. `[]float64` is not `[]any`, the two are different types, so instantiation fails. Note that even if you explicitly instantiate `do` to `[]any`, you still could not pass a

Re: [go-nuts] Why is pdfcpu v0.5.0 290MiB on proxy.golang.org ?

Not sure if it's a good idea, but you could put them in a separate Go module and only import that from tests. That way they *should* not get downloaded when the module is only imported as a dependency. I think. OTOH you'd have to use `go:embed` to export them, which means every `go test` has to

Re: [go-nuts] Why is pdfcpu v0.5.0 290MiB on proxy.golang.org ?

You're right, thanks. Do you have any simple solution for this (beside deleting those files)? Putting such files in a git submodule or git-LFS seems appropriate but complex. Axel Wagner a következőt írta (2023. augusztus 25., péntek, 10:08:47 UTC+2): > ISTM that's because they include a lot

Re: [go-nuts] Why is pdfcpu v0.5.0 290MiB on proxy.golang.org ?

ISTM that's because they include a lot of PDFs for samples and test data in their repository now: https://github.com/pdfcpu/pdfcpu/tree/master/pkg/samples (245 MB) https://github.com/pdfcpu/pdfcpu/tree/master/pkg/testdata (77 MB) This isn't due to the module mirror doing anything weird, it's just

Re: [go-nuts] Why is foo in my go.sum file?

test case? On Friday, August 18, 2023 at 9:18:05 AM UTC+2 Dan Kortschak wrote: > On Fri, 2023-08-18 at 16:49 +1000, Nigel Tao wrote: > > The go.sum file in the golang.org/x/image repo has a line that is not > > another golang.org.x/* module: > > > > github.com/yuin/goldmark v1.4.13/go.mod > >

Re: [go-nuts] Why is foo in my go.sum file?

On Fri, 2023-08-18 at 16:49 +1000, Nigel Tao wrote: > The go.sum file in the golang.org/x/image repo has a line that is not > another golang.org.x/* module: > > github.com/yuin/goldmark v1.4.13/go.mod > h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY= > >

Re: [go-nuts] Why is reflect.Type defined as an interface, but reflect.Value is defined as a struct?

On Thu, Aug 17, 2023 at 10:02 AM Hu Jian wrote: > > I'm curious why reflect.Type is defined as an interface, but reflect.Value is > defined as a struct? I don't see any other implementation of the reflect.Type > interface. reflect.Value is an ordinary struct. The reflect.Type interface is

Re: [go-nuts] why the go install package download from official website of go1.21 is less than go1.20?

I think that for 1.21 the biggest difference is that we aren't including debug info with the binaries in $GOROOT/pkg/tool/$GOOS_$GOARCH. That change was made in https://go.dev/cl/475378. Ian Ian On Wed, Aug 16, 2023 at 12:46 PM Jeremy Cattone wrote: > > Looks like on-going work, finally

Re: [go-nuts] why the go install package download from official website of go1.21 is less than go1.20?

Looks like on-going work, finally completed in 1.21? https://github.com/golang/go/issues/27151 On Tuesday, August 15, 2023 at 9:31:41 PM UTC-7 Kurtis Rader wrote: > All of the packages are significantly smaller -- not just those for macOS. > So this isn't due to anything specific to the macOS

Re: [go-nuts] why the go install package download from official website of go1.21 is less than go1.20?

All of the packages are significantly smaller -- not just those for macOS. So this isn't due to anything specific to the macOS package(s). Looking at the release notes for Go 1.21.0 I don't see an obvious explanation for the reduction. Downloading and extracting those two packages shows the

Re: [go-nuts] Why does Go (so far) not have support for generators/ iterators for custom types ?

Small corrections: 1. in the first sentence, add an "early days Go" 2. In the second sentence, "now we do have *generics*", not iterators. On Sun, Aug 6, 2023 at 11:35 AM Axel Wagner wrote: > For one, Go did not have generic types or functions, which really limits > the usefulness (and

Re: [go-nuts] Why does Go (so far) not have support for generators/ iterators for custom types ?

For one, Go did not have generic types or functions, which really limits the usefulness (and abilities to write) custom iterators in Go. Now we do have iterators, but it turns out there still are a lot of subtle Go-specific issues with how to support custom iterator types, which to be honest are

Re: [go-nuts] Why is type inference still so rudimentary?

I wish there were more cases where the types could be elided. Always leaving it off would be a bad idea but how much to put in should be at the author's discretion. There are times when it clarifies but more times when it just adds extra steps. I know that the current rules have justifications but

Re: [go-nuts] Why is type inference still so rudimentary?

On Fri, Aug 4, 2023 at 8:08 AM Nate Finch wrote: > > If I have a struct > > type User struct { > Name string > ID int > } > > type Group struct { > Leader User > } > > Why is it that the go tool can't infer what type I'm constructing for the > Leader field here? > > g := Group{ >

Re: [go-nuts] Why not return after calling http.Error()

Thanks to everyone who reassured me. I considered posting a set of links from the most popular Golang tutorials that do not return after calling http.Error(), but then baulked In any case, thanks once again to all in this thread. Regards On Wed, Jul 5, 2023 at 4:13 AM ben...@gmail.com wrote:

Re: [go-nuts] Why not return after calling http.Error()

> Every example of http Handler that I have seen so far looks like this: Yes, that's definitely odd. I just grepped my Go source directory (which includes the Go compiler and stdlib and a bunch of other Go code), and almost all of them have a "return" on the next line. For example: $ rg

Re: [go-nuts] Why not return after calling http.Error()

On Tue, Jul 4, 2023 at 5:38 PM Gurunandan Bhat wrote: > Every example of http Handler that I have seen so far looks like this: > > func handleSomeRequest(w http.ResponseWriter, r *http.Request) { > > // do something that returns an error > if err != nil { > http.Error(w,

Re: [go-nuts] Why is reflect.CanAddr() returning false in this case ?

On Thu, Jun 22, 2023 at 12:16 PM christoph...@gmail.com wrote: > > I'm trying to get the uintptr address of a value p for which I have the > reflect.Value so that I can compare it with the value obtained with > v.Pointer() when p is a pointer. > > Here is a simple recursive pointer example code

Re: [go-nuts] Why does sudog g field hold unsafe.Pointer?

On Wed, Jun 7, 2023 at 5:13 AM 'Mikhail Gritsenko' via golang-nuts wrote: > > Why does sudog struct for elem field for the second node in sendq of a chan > hold unsafe.Pointer BUT the first node of the sendq holds actual value? Is it > somehow related with sendDirect or this is just an address

Re: [go-nuts] Why is there no pure StableSort in golang.org/x/exp/slices?

I have written the code now and run a benchmark. In the benchmark function slices.Sort is 9% faster than slices.SortFunc, which is ca. 9% faster than slices.SortStableFunc for my benchmark. I don't need stable sort, but assumed that merge sorting would benefit more from presorted runs. On

Re: [go-nuts] Why is there no pure StableSort in golang.org/x/exp/slices?

It has not been added because it is pointless. Stable sorting is generally slower than regular sorting, as it puts extra constraints on the output and keeping to those makes things slower. And for a total order, *every* sorting algorithm produces a stable sort, as stability only matters if you

Re: [go-nuts] why golang not provide likely/unlikely syntax?

pgo is great tool for optmize branch prediction, hope branch prediction feature merge into pgo as soon as possible On Tuesday, March 21, 2023 at 5:49:34 AM UTC+8 Ian Lance Taylor wrote: > On Mon, Mar 20, 2023 at 9:17 AM cheng dong wrote: > > > > i see golang source ssa guess

Re: [go-nuts] why golang not provide likely/unlikely syntax?

On Mon, Mar 20, 2023 at 9:17 AM cheng dong wrote: > > i see golang source ssa guess BranchLikely/BranchUnLikely, however we could > not tell golang whether if is likely or unlikely. and looks the guess logic > might be far away from real condition We don't want to complicate the language.

Re: [go-nuts] Why the extra call to `seed` in this situation?

Yeah this actually makes sense ``` On Wednesday, March 15, 2023 at 12:11:11 AM UTC Ian Lance Taylor wrote: > On Tue, Mar 14, 2023 at 3:47 PM Kwaku Biney wrote: > > > > i was digging in the rand package and came across NewSource(seed) in the > randpackage which creates a new source in case you

Re: [go-nuts] Why the extra call to `seed` in this situation?

On Tue, Mar 14, 2023 at 3:47 PM Kwaku Biney wrote: > > i was digging in the rand package and came across NewSource(seed) in the > randpackage which creates a new source in case you don't want the global > source set by the package. It returns a Source interface. For some reason, > there's a

Re: [go-nuts] Why would Go not be able put floats in registers without loss of precision?

On Thu, Mar 2, 2023 at 12:07 PM Ian Lance Taylor wrote: > > On Thu, Mar 2, 2023 at 8:43 AM 'Grant Seltzer Richman' via golang-nuts > wrote: > > > > So you're saying this should never happen on arm64? That would make sense > > but i'm having trouble finding the float64 values in registers via

Re: [go-nuts] Why would Go not be able put floats in registers without loss of precision?

On Thu, Mar 2, 2023 at 8:43 AM 'Grant Seltzer Richman' via golang-nuts wrote: > > So you're saying this should never happen on arm64? That would make sense but > i'm having trouble finding the float64 values in registers via bpf. Perhaps > my issue lies in how i'm reading the raw bytes and my

Re: [go-nuts] Why would Go not be able put floats in registers without loss of precision?

Hi Ian, So you're saying this should never happen on arm64? That would make sense but i'm having trouble finding the float64 values in registers via bpf. Perhaps my issue lies in how i'm reading the raw bytes and my understanding of ARM. Hard to give an example without just sending a whole

Re: [go-nuts] Why would Go not be able put floats in registers without loss of precision?

On Thu, Mar 2, 2023 at 8:22 AM 'Grant Seltzer Richman' via golang-nuts wrote: > > I'm tracing go functions with uprobes/bpf and printing the contents of > registers/stacks. So I can see the content of registers and stack at the > entry of specified go functions. > > I'm looking at a function

Re: [go-nuts] Why is runtime.Gosched needed in this single-threaded, no-goroutines cgo program?

That's good to know, thanks. I did log the current OS thread ID using `pthread_self()` as well as with `pthread_threadid_np()` and the thread ID is constant for all hid_write and hid_read calls. The issue appears anyway, unless the scheduler is invoked. On Wed, 15 Feb 2023 at 23:52, Ian Lance

Re: [go-nuts] Why is runtime.Gosched needed in this single-threaded, no-goroutines cgo program?

On Wed, Feb 15, 2023 at 4:05 PM Ian Lance Taylor wrote: > On Wed, Feb 15, 2023 at 8:42 AM 'Marko Bencun' via golang-nuts > wrote: > > > > I am running into a a weird error in C code that only materializes > > when calling it from Go using cgo. I hope you could help me understand > > this

Re: [go-nuts] Why is runtime.Gosched needed in this single-threaded, no-goroutines cgo program?

On Wed, Feb 15, 2023 at 2:36 PM Marko Bencun wrote: > > That is a good hint, thanks. However, in the Go code above, there are > no goroutines and everything runs in one thread as far as I can tell, > but the issue appears anyway. There are always goroutines, even if your program doesn't start

Re: [go-nuts] Why is runtime.Gosched needed in this single-threaded, no-goroutines cgo program?

That is a good hint, thanks. However, in the Go code above, there are no goroutines and everything runs in one thread as far as I can tell, but the issue appears anyway. On Wed, 15 Feb 2023 at 22:05, Ian Lance Taylor wrote: > > On Wed, Feb 15, 2023 at 8:42 AM 'Marko Bencun' via golang-nuts >

Re: [go-nuts] Why is runtime.Gosched needed in this single-threaded, no-goroutines cgo program?

On Wed, Feb 15, 2023 at 8:42 AM 'Marko Bencun' via golang-nuts wrote: > > I am running into a a weird error in C code that only materializes > when calling it from Go using cgo. I hope you could help me understand > this behaviour and why calling runtime.Gosched() seems to resolve the > issue. I

Re: [go-nuts] Why can't a regexp.Regexp be const

On Monday, February 13, 2023 at 7:08:35 PM UTC-5 David Finkel wrote: So, why can't the regexp be a constant? Only primitive types are allowed to be constant in go Oh, this is what I missed. For cases like this, I tend to create an unexported package variable

Re: [go-nuts] Why can't a regexp.Regexp be const

On Mon, Feb 13, 2023 at 6:48 PM Pat Farrell wrote: > This won't compile > > var ExtRegex = > regexp.MustCompile("(M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") > > with a > ./prog.go:10:18: > regexp.MustCompile("((M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") (value of > type *regexp.Regexp) is not

Re: [go-nuts] Why can't a regexp.Regexp be const

This compiles just fine, but the regexp compilation fails: https://go.dev/play/p/QvC8CIITUU6 On Mon, Feb 13, 2023 at 4:49 PM Pat Farrell wrote: > This won't compile > > var ExtRegex = > regexp.MustCompile("(M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") > > with a > ./prog.go:10:18: >

Re: [go-nuts] Why not sync.Mutex is designed as an interface

That makes sense. Thanks for replying. regards On Wednesday, November 9, 2022 at 1:11:35 AM UTC+8 Ian Lance Taylor wrote: > On Tue, Nov 8, 2022 at 7:55 AM Xie Yuchen wrote: > > > > I checked with the issue about how to refer no-copy and the check of > cmd/vet. After checking, I'm curious that

Re: [go-nuts] Why not sync.Mutex is designed as an interface

On Tue, Nov 8, 2022 at 7:55 AM Xie Yuchen wrote: > > I checked with the issue about how to refer no-copy and the check of cmd/vet. > After checking, I'm curious that why not define mutex as an interface, as > interface always copy like a reference, which means users don't worry to copy > by

Re: [go-nuts] Why channel latency depends on CPU utilization?

On Mon, Oct 31, 2022 at 2:38 PM Sergey Kurenkov wrote: > > > Your sample code above is entering the scheduler > continuously, which is not a typical characteristic of a real program > that has heavy CPU usage. It's possible that what you are seeing is > contention on the scheduler lock. > > Ian,

Re: [go-nuts] Why channel latency depends on CPU utilization?

Entering the scheduler continuously will improve performance - it is known as “keeping things hot”. Waking a thread is usually about 6-7 usecs. So if you never “sleep” you get much lower latency. > On Oct 31, 2022, at 4:55 PM, Sergey Kurenkov > wrote: > >  > > Your sample code above is

Re: [go-nuts] Why channel latency depends on CPU utilization?

> Your sample code above is entering the scheduler continuously, which is not a typical characteristic of a real program that has heavy CPU usage. It's possible that what you are seeing is contention on the scheduler lock. Ian, Don't understand your point. The sample code above actually has

Re: [go-nuts] Why channel latency depends on CPU utilization?

> Your sample code above is entering the scheduler continuously, which is not a typical characteristic of a real program that has heavy CPU usage. It's possible that what you are seeing is contention on the scheduler lock. Ian, Don't understand your point. The sample code above actually has

Re: [go-nuts] Why channel latency depends on CPU utilization?

github.com/robaho/go-currency-test has some investigation on this > On Oct 31, 2022, at 3:53 PM, Ian Lance Taylor wrote: > > On Mon, Oct 31, 2022 at 1:34 PM Sergey Kurenkov > wrote: >> >> I am trying to understand why higher CPU utilization leads to longer latency >> in reading from

Re: [go-nuts] Why channel latency depends on CPU utilization?

On Mon, Oct 31, 2022 at 1:34 PM Sergey Kurenkov wrote: > > I am trying to understand why higher CPU utilization leads to longer latency > in reading from channels in golang. Could you help me with this question? > > I wrote a test that reads from channels and measure latency between writing >

Re: [go-nuts] Why declaring multiple variable at once for same type feature exists in Golang?

On 18 August 2022 7:20:45 am UTC, Yasser Sinjab wrote: >Hi, > >I'm just wondering why this feature is in Golang: such as > >var x, y, z string > >Thanks, >Yasser > Because it's the greatest programming language, ever ! Saifi. -- You received this message because you are subscribed to the

Re: [go-nuts] Why traversing Go hashmap so slower then C++ hashmap

On Tue, Jun 28, 2022 at 9:56 PM Yan Li wrote: > > Question: > Go 161.385148ms vs C++ ms:31 > Go 851.517707ms vs C++ ms:104 > My question is why traversing go map Significantly slowly? > Can it be improved? I don't know exactly why there is a speed difference. That said, there are significant

Re: [go-nuts] Why Go has only slice and map

Interestingly, Go also kind of has a built-in set data type by using map keys! https://go.dev/play/p/3-ZEKPSPUEh I know that's not really what you mean, but I think it's a cool pattern. On Tue Apr 12, 2022, 07:50 PM GMT, Ian Lance Taylor wrote: On Mon, Apr 11, 2022 at 11:19 PM 'Jack Li' via

Re: [go-nuts] Why Go has only slice and map

On Mon, Apr 11, 2022 at 11:19 PM 'Jack Li' via golang-nuts wrote: > > Why Go provides only 2 built-in data structures, slice and map. It has just > more than C, but less than all other programming languages I've heard of, > C++, Python, Swift, Rust. > > I think this simplicity attracts me very

Re: [go-nuts] Why Go has only slice and map

Very true! On Tue, Apr 12, 2022 at 8:36 PM Robert Engels wrote: > Nit but you can certainly create maps and slices in a library - you use > methods not language syntax - as long as you have pointers and type > casting. > > On Apr 12, 2022, at 1:30 PM, Jesper Louis Andersen < >

Re: [go-nuts] Why Go has only slice and map

Nit but you can certainly create maps and slices in a library - you use methods not language syntax - as long as you have pointers and type casting. > On Apr 12, 2022, at 1:30 PM, Jesper Louis Andersen > wrote: > >  >> On Tue, Apr 12, 2022 at 8:19 AM 'Jack Li' via golang-nuts >> wrote: >>

Re: [go-nuts] Why Go has only slice and map

On Tue, Apr 12, 2022 at 8:19 AM 'Jack Li' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi group, > > Why Go provides only 2 built-in data structures, slice and map. It has > just more than C, but less than all other programming languages I've heard > of, C++, Python, Swift, Rust. > >

Re: [go-nuts] why the opendefer optimization will close when my function's named return value escape

On Thu, Apr 7, 2022 at 11:03 AM ワタナベハルキ wrote: > > GOARCH="amd64" > GOHOSTOS="linux" > GOVERSION="go1.17.2" > > Here is my test code > > var sink *int > > func main(){ > escape() > } > > // named return value r > func escape() (r int) { > defer func(){ > recover() > }() >

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

I've hit this problems a few times, and I immediately thumbs-upped that issue report. To correct @Ben, I suggest the purest reasoning for an error being displayed is "The process completed, and did not succeed". In your case, @Ben, yeah, it was killed while waiting on something, but the normal

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

> Depending on implementation, infinite recursion is not guaranteed to blow > the stack for the program given. The function call is in tail position, so > a tail-call optimization (TCO) pass would be able to rewrite the program > into an infinite loop by reusing the existing stack frame for

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

On Wed, Apr 6, 2022 at 3:18 AM ben...@gmail.com wrote: > Normally the Go Playground gives errors when a runtime panic or other > error occurs, including "timeout running program" for programs that run too > long. I'm wondering why the Playground doesn't show a stack overflow error > (or any

Re: [go-nuts] Why does Go not have intrinsic functions?

FWIW, I took a stab at a SIMD-oriented feature (https://go.dev/issue/48499), but as @Ian%20Lance%20Taylor put it, it's about the right approach. I skewed too far towards convenience in what I proposed, gaining significant maintainability concerns. On Thursday, April 7, 2022 at 3:35:35 PM UTC-5

Re: [go-nuts] Why does Go not have intrinsic functions?

On Thu, Apr 7, 2022 at 11:03 AM Arthur Comte wrote: > > Intrinsic functions (functions that compile down to one hardware instruction) > are common in (relatively) low-level languages. Go even supports embed ASM > (though a weird flavour of it) > Can someone explain why we do not have an

Re: [go-nuts] Why does Go not have intrinsic functions?

Go does have them. math/big compiles down to single instructions on platforms where it's supported. sync/atomic does as well. On Thu, Apr 7, 2022 at 8:03 PM Arthur Comte wrote: > Intrinsic functions (functions that compile down to one hardware > instruction) are common in (relatively) low-level

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

Like, I get that the extra type-pointer for a declared struct of float64+bool isn't that big of a deal, I do wish we could express tuple types naturally. What you suggest is probably the closest we get for now. For `if v, ok := value.(bool); ok && v`, the value is tuly 0. For `if v, ok :=

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

I agree, and there's a clear benefit that it's harder to dereference a nil interface than a nil pointer, when that interface has no methods. The problem is that statically it doesn't tell you anything about the possible contained type. In comparison, a pointer tells you exactly the type

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

Oh wait, looks like it's public: https://github.com/golang/playground On Wednesday, April 6, 2022 at 3:32:11 PM UTC+12 ben...@gmail.com wrote: > Sure, report an issue against the playground. I honestly have no idea >> how difficult this would be to fix. >> > > Thanks, done:

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

> Sure, report an issue against the playground. I honestly have no idea > how difficult this would be to fix. > Thanks, done: https://github.com/golang/go/issues/52176 The source for the Playground is private, correct? -Ben -- You received this message because you are subscribed to the

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

On Tue, Apr 5, 2022 at 6:50 PM ben...@gmail.com wrote: > >> The playground isn't intended to be an exact replica of running a >> program on a real machine. If the program uses too many resources it >> will simply be stopped. > > > Both fair enough. But surely the runner can distinguish when the

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

On Tue, Apr 5, 2022 at 6:18 PM ben...@gmail.com wrote: > Normally the Go Playground gives errors when a runtime panic or other > error occurs, including "timeout running program" for programs that run too > long. I'm wondering why the Playground doesn't show a stack overflow error > (or any

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

> The playground isn't intended to be an exact replica of running a > program on a real machine. If the program uses too many resources it > will simply be stopped. > Both fair enough. But surely the runner can distinguish when the program ran successfully to completion versus when it was

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

On Tue, Apr 5, 2022 at 6:18 PM ben...@gmail.com wrote: > > Normally the Go Playground gives errors when a runtime panic or other error > occurs, including "timeout running program" for programs that run too long. > I'm wondering why the Playground doesn't show a stack overflow error (or any >

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

I get what you're saying, and for what it's worth, you're absolutely correct. Something like above is a set of tradeoffs, and I guess all I can assert is that it works for me. I do think it's a good design, given Go's lack of a None type to enforce well-defined behavior on a nil pointer

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

I did look at the code briefly. The main thing I noticed was that the return type of float8.Get() was an interface{} - so it's up to the caller to check at runtime whether the value is nil, a float64, or a Status. So you're right, it's not that they are compile-time unsafe, but rather that

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

Uh, you should check the code: github.com/jackc/pgtype/blob/master/float8.go If you know what you have and what you're dealing with, and if you actually check the error result, you do get safety. If you don't know what you've got, or if you're iterating through the values, then you end up

Re: [go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

Thanks for your reply,Ian.I've always had a misunderstanding about atomic operation,I thought atomic operation is only used to protect the CPU instructions from being interrupted. I have watched some lectures about C++ memory order on youtube.As you mentioned,another function of atomic

Re: [go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

Thanks for your reply,eric.I've always focused on this situation,without atomic operator,If goroutine A set a variable v to 0 and goroutine B set the variable a to 1,anther goroutine C would probably get a unexpected value which is neither 0 nor 1 when its read operation of a is

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

Correct repository path is: https://github.com/jackc/pgtype Interesting. These structs generally contain a Status value as well: type Int8 struct { Int int64 Status Status } where pgtype.go has: type Status byte const ( Undefined Status = iota Null Present ) They also have

Re: [go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

Why is it not safe to read here? The real write operation is done through CAS, assuming the read value is out of date, then the CAS operation will fail. 在2022年4月2日星期六 UTC+8 11:41:00 写道： > On Fri, Apr 1, 2022 at 8:31 PM 机智的小小帅 wrote: > > > > Hi,all. I'm reading the source code of sync package

Re: [go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

On Fri, Apr 1, 2022 at 8:31 PM 机智的小小帅 wrote: > > Hi,all. I'm reading the source code of sync package recently. > > Here is a code snippet in sync/mutex.go. > > // src/sync/mutex.go > type Mutex struct { > state int32 > sema uint32 > } > > func (m *Mutex) lockSlow() { > var

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

Thanks for clarifying that, @Brian. Yeah. It took a bit to warm up to that approach, but the github.com/jackc/pgtypes convinced me that the results were worth it. The benefits: A, package interpretation methods with a piece of data, B, lazily valuate data when needed, and C, gain

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

That wasn't literal code with anglebrackets - you're supposed to fill that in yourself. I think he meant something like: type fooString struct{ string } https://go.dev/play/p/4Q94xMZDciV What this is doing is *embedding* a string value into a struct; if you have not come across type

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

Hi Sam! Your solution does not seem to work: package main import( "fmt" "strconv" ) type String struct{string} func (s String) print(){ fmt.Println(s) } func main() { var a String ="hello, world\n" a.print() fmt.Println(strconv.ParseInt("78",10, 64)) var x

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

This works: n, _ := strconv.ParseInt(string(x), 10, 64) Go intentionally does no automatic type conversion, not even this: var a int32 = 1234 var b int64 = a// error: use int64(a) instead It would be inconsistent if passing "mystr" to a function which accepts

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

My workaround like is something like `type String struct{string}. It can be reasonably treated as a string for most cases in which as string is needed, and it lets you convert back conveniently from any scope in which it's reasonable for your program to know the difference. On Friday, March

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

My own preference is to have a small number of methods and put the general functionalities into functions. By putting the general functionalities into functions, you allow code reuse. In object-oriented programming, you normally attach as many functionalities as possible to their corresponding

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

On Thu, Mar 17, 2022 at 7:17 PM Zhaoxun Yan wrote: > > I just came across this taboo in golang - new methods cannot be added to an > existing type: Yes. If we didn't have this prohibition, then the set of interfaces satisfied by a type would depend on which package was using the type. See the

Re: [go-nuts] Why, oh why, do people do this? Things that annoy me in Go code.

Naming things is one of the hardest things a programmer needs to do. Seriously. On Tuesday, March 8, 2022 at 6:08:09 AM UTC+7 ba...@iitbombay.org wrote: > GoBOL, anyone? > > > On Mar 7, 2022, at 2:20 PM, Rob Pike wrote: > > > > It could have been > > > > interface >

Re: [go-nuts] Why, oh why, do people do this? Things that annoy me in Go code.

GoBOL, anyone? > On Mar 7, 2022, at 2:20 PM, Rob Pike wrote: > > It could have been > > interface > UnreceivedMasterOrdersInterfaceThatCanBeUsedToCallGetUnreceivedByProductsWarehouseAndCompany > > Seriously, though, your example isn't even on the same planet as some > of the examples I've

Re: [go-nuts] Why Go allow function with unused arguments?

> By enforcing blanks, you'd lose the chance to name them something useful to tell the reader why they're ignored. For me this is quite straightforward: they are omitted because, they aren't needed. True question to me is: why other functions need them? But, this wouldn't be answered by

  1   2   3   4   5   6   7   8   >