Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

I think I may have discovered the issue. I made a sys call to duplicate the file descriptor dupFd, err := syscall.Dup(int(file.Fd())) if err != nil { log.Printf("Error duplicating file descriptor: %v", err) return 0, "" } which likely reset the FD_CLOEXEC Flag: (from Advanced Programming in

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

I think what Jeremy mentions in here is the key to the issue. There would be more consensus and less interest in "fixing" enums in Go if there was a tangible way to restrict their values to what is stated by the developer. El lunes, 4 de marzo de 2024 a la(s) 12:18:05 p.m. UTC-3, Jeremy French

Re: [go-nuts] Query Regarding ASAN C Call from Go Code

On Mon, Mar 4, 2024 at 9:55 AM Evgeny Chormonov wrote: > > I'm using Linux as my platform, but I'm curious why this solution is > restricted to Linux systems only? > https://github.com/golang/go/blob/master/src/runtime/asan/asan.go#L5 That's just the list of systems for which we support asan.

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

On Mon, Mar 4, 2024 at 9:40 AM Jan Mercl <0xj...@gmail.com> wrote: > > The static type of an interface can be verified at compile time. The > value of a variable of an enum type (or a Pascal-like subrange) type, > cannot be verified at compile time in the general case. You would have > to add

Re: [go-nuts] Query Regarding ASAN C Call from Go Code

Thanks for your answer, Ian. I've decided to use a code generator based on cgo instead of writing assembly code for each function. I'm using Linux as my platform, but I'm curious why this solution is restricted to Linux systems only?

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

On Mon, Mar 4, 2024 at 6:19 PM Jeremy French wrote: > More, to prevent PrintMonth(14), which the function would have to check for > and either return an error or panic, since there is no meaningful output. In > fact, it's fairly easy to see, even in this case, where the PrintMonth >

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

More, to prevent PrintMonth(14), which the function would have to check for and either return an error or panic, since there is no meaningful output. In fact, it's fairly easy to see, even in this case, where the PrintMonth signature would have to return an error, when that is pretty much the

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

OP here -> I'm going to put together some test apps - toss them on GitHub and make sure I actually know what I'm talking about :) On Friday, March 1, 2024 at 7:57:15 PM UTC-7 Ian Lance Taylor wrote: > On Fri, Mar 1, 2024 at 6:17 PM Robert Engels wrote: > > > > The could be calling fork() as

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

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

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

On Mon, Mar 4, 2024 at 4:19 PM Jeremy French wrote: > It's checked at compile-time rather than run time. That requires immutability of variables of enum type. Go does not support immutable variables. -- You received this message because you are subscribed to the Google Groups "golang-nuts"

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

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), without having to have boiler plate to check or throw errors if it's not one of the approved values. It's checked at

Re: [go-nuts] GO111MODULE=off go get deprecated?

Per https://go.dev/doc/go1.22#go-command: > go get is no longer supported outside of a module in the legacy GOPATH mode (that is, with GO111MODULE=off). Other build commands, such as go build and go test, will continue to work indefinitely for legacy GOPATH programs. This was discussed in

Re: [go-nuts] Adding context.Context as first parameter in every function

@axel Most of the functions I have (except the utility ones) will be needing the context parameter, that's why I thought of adding context to every function, and just using auto-refactoring to remove context from the functions which doesn't use it. @Sam Thanks for providing me with your repo

Re: [go-nuts] GO111MODULE=off go get deprecated?

Yes, I do understand the go-source/go-import part, but am I missing something? I don't understand how you would find the go-source other than parsing the HTML I mean 'go get' used to do that for me, do I now have to write a program to do that? I don't understand why that is some bad idea.

Re: [go-nuts] GO111MODULE=off go get deprecated?

On Sun, Mar 3, 2024 at 5:05 PM Jeffery Carr wrote: > "You can build large projects with many repos using Go modules. " > > Also, I forgot to add, lots of my repos are binaries, so module things > don't apply. How do I tell someone to download go.wit.com/apps/helloworld? > I can't now with a

Re: [go-nuts] GO111MODULE=off go get deprecated?

"You can build large projects with many repos using Go modules. " Also, I forgot to add, lots of my repos are binaries, so module things don't apply. How do I tell someone to download go.wit.com/apps/helloworld? I can't now with a single GO111MODULE=off go get. Can we have 'go download' or can

Re: [go-nuts] GO111MODULE=off go get deprecated?

I don't think I understand you. How can I download go.uber.org/zap sources? I need to be able to do it using the "go" binary. I was able to do it before, now I can't. Is there some way to do go download go.uber.org/zap and have it git clone? I don't know how to resolve the git clone path.

Re: [go-nuts] GO111MODULE=off go get deprecated?

Hi Jeffery, You can build large projects with many repos using Go modules. Firstly, you can reference the other repos and use the latest "master" version by writing "master" where the v verson is in the file, then use "go mod tidy" Second, you can use "go work" to create a workspace with

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

I have recently seen many are complaining about a lack of enums in Go. But while there are many ways in which I would like to see Go improved, enums barely even rank on my list of priorities. The majority of my experience prior to Go was with dynamic languages that did not have explicit

Re: [go-nuts] GO111MODULE=off go get deprecated?

I guess this boils down to: GO111MODULE=off go get go.uber.org/zap used to git clone into ~/go/src/go.uber.org/zap How am I supposed to do that now? I assume I'm not expected to parse the HTML for the go-import and go-source lines! jcarr -- You received this message because you are

Re: [go-nuts] Data structure code review

Some feedback: Instead of errors.New(emptyDataStructureMessage("stack")) use an emptyDataError type, where it implements the error interface by adding an Error() string method, for example: type emptyDataError string func (e emptyDataError) Error() string { return fmt.Sprintf("not empty %s

Re: [go-nuts] Query Regarding ASAN C Call from Go Code

On Sun, Mar 3, 2024 at 1:25 PM Evgeny Chormonov wrote: > > I noticed that ASAN checker in the Go source code is defined using CGO > https://github.com/golang/go/blob/master/src/runtime/asan/asan.go > But the C ASAN functions are called from the Go runtime using assembly code > instead of a

Re: [go-nuts] GO111MODULE=off go get deprecated?

On Sun, Mar 3, 2024 at 1:25 PM Jeffery Carr wrote: > > Has this been deprecated or maybe it is broken in debian sid, but: > > bash$ GO111MODULE=off go get -v go.wit.com/apps/test > go: modules disabled by GO111MODULE=off; see 'go help modules' > basj$ go version > go version go1.22.0 linux/amd64

[go-nuts] GO111MODULE=off go get deprecated?

Has this been deprecated or maybe it is broken in debian sid, but: bash$ GO111MODULE=off go get -v go.wit.com/apps/test go: modules disabled by GO111MODULE=off; see 'go help modules' basj$ go version go version go1.22.0 linux/amd64 this doesn't work anymore. Also, 'go help modules' is less than

[go-nuts] Query Regarding ASAN C Call from Go Code

I noticed that ASAN checker in the Go source code is defined using CGO https://github.com/golang/go/blob/master/src/runtime/asan/asan.go But the C ASAN functions are called from the Go runtime using assembly code instead of a common CGO call.

[go-nuts] Data structure code review

Hi! I wrote my first data structure in Go. I wonder how idiomatic my code is to enhance it. Previously, I had C# and Java experience. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Re: 64 Tiny Algorithmic Puzzles in Go

Exactly! On Sat, Mar 2, 2024 at 8:37 PM peterGo wrote: > qiulaidongfeng, > > A simpler, solution: > > https://go.dev/play/p/gLY7O_hwyxI > > peter > > On Saturday, March 2, 2024 at 8:25:33 PM UTC-5 qiulaidongfeng wrote: > >> I wrote a correct one, as shown here: >>

[go-nuts] Enums, Go1 and proposals

Hello, gophers. Lately I've been working quite a bit with enums as I'm moving a C program I had to Go, so I wondered if there was any progress on enums proposals and realized that none of them get anywhere without breaking the Go1 compatibility. I've decided to get a bit creative and share

[go-nuts] Re: c-shared library for Aix

llvm/clang? I've ditched gcc because of its many unfixable problems. After loosing quite some time, trying to cross-compile Go using gcc, I've switched to clang IIRC and this works beautifully, especially cross-building for Alpine/musl. However my AIX time with RS6000 was decades ago, and I

[go-nuts] Re: 64 Tiny Algorithmic Puzzles in Go

qiulaidongfeng, A simpler, solution: https://go.dev/play/p/gLY7O_hwyxI peter On Saturday, March 2, 2024 at 8:25:33 PM UTC-5 qiulaidongfeng wrote: > I wrote a correct one, as shown here: > https://go.dev/play/p/IDJP_iIsGDE > > On Sunday, March 3, 2024 at 1:42:51 AM UTC+8 BUGFIX 66 wrote: > >>

[go-nuts] Re: 64 Tiny Algorithmic Puzzles in Go

I wrote a correct one, as shown here: https://go.dev/play/p/IDJP_iIsGDE On Sunday, March 3, 2024 at 1:42:51 AM UTC+8 BUGFIX 66 wrote: > https://BUGFIX-66.com > > Solve each puzzle by making a tiny change to a short piece of Go code. > Edited code is compiled and tested on the host server. > Each

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

Glad you figured it out. Not certain how requests could crash a process like… I think you’d be better off configuring a maximum heap size rather than having the OOM killer kick in On Mar 2, 2024, at 3:50 PM, Russtopia wrote:SOLVED!Thank you all for the helpful suggestions. Although it has turned

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

SOLVED! Thank you all for the helpful suggestions. Although it has turned out to be something totally different, and a teachable lesson in web app design... This go tool of mine has a very simple web interface with controls for a set of jobs on the main page. The jobs on this list can be run,

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

My recommendation is run your program under the control of `strace`. The simplest way to do that is to rename the current program you're launching by adding something like a ".orig" extension. Then create a script with the name of the program containing this: #!/bin/sh exec strace -o

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

I’m guessing some other library or package you installed has corrupted your Linux installation. Sadly, my suggestion would be a fresh install of Linux. On Mar 2, 2024, at 1:58 PM, Russtopia wrote:It no longer does.. so it suggests to me there's something external that has changed, but I have no

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

.. I should add that I have often completely restarted the go program during testing here, so I don't think it could be a case of some long-term 'leak' in the go tool's own code since it's been relaunched and doesn't have any big 'state' to restore or anything. On Sat, Mar 2, 2024 at 7:57 PM

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

It no longer does.. so it suggests to me there's something external that has changed, but I have no clue as to what that might be -- as the process being started by my go tool will run just fine from a shell. And, it *does* run fine on my laptop (which granted is beefier, but again this server was

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

Please clarify - does it work using the older versions of Go?On Mar 2, 2024, at 12:53 PM, Russtopia wrote:I have tried rebuilding with go1.18.6, go1.15.15 with no difference.On Sat, Mar 2, 2024 at 6:23 PM Robert Engels wrote:I would  be also try reverting the Go version

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

I have tried rebuilding with go1.18.6, go1.15.15 with no difference. On Sat, Mar 2, 2024 at 6:23 PM Robert Engels wrote: > I would be also try reverting the Go version and ensure that it continues > to work. Other system libraries may have been updated. > > > On Mar 2, 2024, at 12:05 PM, Ian

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

Hi, I tried outputting the value of werr.(*exec.ExitError).Stderr, but it's empty. Outputting all of werr.(*exec.ExitError) via fmt.Printf("[job *ExitError:%+v]\n", werr.(*exec.ExitError)) ..gives merely [job *ExitError:signal: killed] On Sat, Mar 2, 2024 at 6:04 PM Ian Lance Taylor wrote:

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

I would be also try reverting the Go version and ensure that it continues to work. Other system libraries may have been updated. > On Mar 2, 2024, at 12:05 PM, Ian Lance Taylor wrote: > > On Sat, Mar 2, 2024 at 9:59 AM Russtopia wrote: >> >> Symptom: mysterious "signal: killed"

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

On Sat, Mar 2, 2024 at 9:59 AM Russtopia wrote: > > Symptom: mysterious "signal: killed" occurrences with processes spawned from > Go via exec.Cmd.Start()/Wait() The first step is to tell us the exact and complete error that you see. "signal: killed" can have different causes, and the rest of

[go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

Hi all, Symptom: mysterious "signal: killed" occurrences with processes spawned from Go via exec.Cmd.Start()/Wait() Actors: 'Server': Intel i5, running Funtoo 1.4 - 4GB RAM, 4GB swap 'Laptop': Intel Core i7 9thGen, running Devuan Chimaera - 15GB RAm, 15GB swap A quite small -- ~900 lines of

[go-nuts] c-shared library for Aix

I have written multiple c-shared libraries code in golang for Windows, Linux, MacOS . I am using GCC cross compiler for the same. This code is running fine in production without any issue since last 3 years. But, we have recently got a requirement to compile the same thing for AIX/PowerPC but

[go-nuts] 64 Tiny Algorithmic Puzzles in Go

https://BUGFIX-66.com Solve each puzzle by making a tiny change to a short piece of Go code. Edited code is compiled and tested on the host server. Each puzzle is a useful little algorithm or idea. Unfortunately, most users can't solve puzzle #3 and give up. Enjoy. -- You received this message

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

On Fri, Mar 1, 2024 at 6:17 PM Robert Engels wrote: > > The could be calling fork() as in the system call - which copies all file > descriptors but I didn’t think Go processes could fork. > > Seems you would need to remap stdin and stdout in the fork to do anything > useful. > > This sounds

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

The could be calling fork() as in the system call - which copies all file descriptors but I didn’t think Go processes could fork. Seems you would need to remap stdin and stdout in the fork to do anything useful. This sounds very PHP - what goes around comes around. > On Mar 1, 2024, at 8:01 

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

On Fri, Mar 1, 2024 at 5:57 PM Jeff Stein wrote: > > I'm struggling to understand if I'm able to do something. > > > In my very odd use case we are writing a websever that handles connections > via a forked process. > > I have a listener process that listens for TCP connections. > > So each

[go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

I'm struggling to understand if I'm able to do something. In my very odd use case we are writing a websever that handles connections via a forked process. I have a listener process that listens for TCP connections. So each net.Conn that comes in we pull off its file descriptor: *fd, err :=

Re: [go-nuts] Adding context.Context as first parameter in every function

Hi Yash, unfortunately that's the only approach at the moment. Your request is very apropos of my thread, "Could we trade all the `ctx context.Context` arguments for one pointer in `g`?". This is the exact use case I have in mind.  I believe it should be possible, and even a fairly naïve

Re: [go-nuts] Re: How to have panic messages show in a PowerShell console

I just discovered that the executable is created using -ldflags -H=windowsgui. Because of that, I need to pipe to out-text in a PowerShell to see Println output but that doesn’t show the panics. If I remove the flags, then I can see all the output. I don’t know if they are absolutely needed so

Re: [go-nuts] Do we need to drain a closed channel ?

On Fri, Mar 1, 2024 at 6:26 AM Shubha Acharya wrote: > > I have been working with buffered channels. I have stumbled upon a scenario > where buffered channel will be closed and the receivers of the channel > terminates before consuming all the elements in the buffer. So my question is > will

Re: [go-nuts] Re: How to have panic messages show in a PowerShell console

On Fri, Mar 1, 2024 at 5:09 AM jake...@gmail.com wrote: > > FWIW, in a very simple test on Windows 10 in a powershell console, running a > go executable built with go1.19 prints the panic just like in a regular cmd > console. There have been a lot of changes related to Windows consoles since

[go-nuts] Do we need to drain a closed channel ?

Hey, I have been working with buffered channels. I have stumbled upon a scenario where buffered channel will be closed and the receivers of the channel terminates before consuming all the elements in the buffer. So my question is will there be any issue regarding Garbage Collection of channel

Re: [go-nuts] I am having trouble getting go.crypto ssh client to connect

The error message "ssh: unable to authenticate, no supported methods remain" typically indicates that the SSH client and server were unable to negotiate a mutually supported authentication method. In your code, you're using password authentication (ssh.ClientAuthPassword), but it seems like

Re: [go-nuts] adding context.Context to new code

@nazri Were you able to achieve this? Adding context to every function. Is there any repository/library available for the same. I have been one of the unaware ones who started writing a new service without adding context explicitly. On Friday, May 19, 2017 at 9:34:22 AM UTC+5:30 Nazri Ramliy

[go-nuts] Adding context.Context as first parameter in every function

Hello, I recently started writing code in Golang and wasn't aware that unlike Java, we can't use ThreadLocals to propagate a context across the code. It's mandatory to explicitly pass a context. I have already written a service which is live in production now, however for monitoring and other

[go-nuts] Re: How to have panic messages show in a PowerShell console

FWIW, in a very simple test on Windows 10 in a powershell console, running a go executable built with go1.19 prints the panic just like in a regular cmd console. On Wednesday, February 28, 2024 at 3:20:55 PM UTC-5 Thom BENTLEY wrote: > Hi All, > > OS: Windows 10 > GoLang: go1.6.3 windows/386

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

I've created an issue for this on Golang's Github , let's see where that goes. I went for the "let's add to the docs first" approach for now. Thanks for the convo! On Thursday 29 February 2024 at 09:25:00 UTC+1 Axel Wagner wrote: > On Thu, Feb 29,

[go-nuts] logout/end session

Using token and the log in request struct i.e (userId, sessionId, timestamp) i generated a login/auth for log in process by creating and merging the request payload to generate the signature thus comparing for varification so the user is active in the system how will i end the session using

[go-nuts] Re: [security] Go 1.22.1 and Go 1.21.8 pre-announcement

Hello gophers, We accidentally repeated one of the CVEs in the pre-announcement. The correct list of CVEs being fixed are: - CVE-2024-24783 - CVE-2023-45290 - CVE-2023-45289 Thanks, Carlos for the Go team On Thursday, February 29, 2024 at 6:29:01 PM UTC-5 annou...@golang.org wrote:

[go-nuts] [security] Go 1.22.1 and Go 1.21.8 pre-announcement

Hello gophers, We plan to issue Go 1.22.1 and Go 1.21.8 during US business hours on Tuesday, March 5. These minor releases include PRIVATE security fixes to the standard library, covering the following CVEs: - CVE-2023-45289 - CVE-2023-45290 - CVE-2023-45289 Following our

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Thanks for your examples!  I'll cover them in reverse order, to build up the syntax. On 2/29/24 6:18 AM, 'TheDiveO' via golang-nuts wrote: The second example is unit test code, so TEST:

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

On Thursday, February 29, 2024 at 7:04:14 PM UTC+8 Axel Wagner wrote: Yes. It means "violating a rule, without setting a precedent for future violations". One of the main objections to the loop variable change has been the breaking of compatibility and the fear of setting a precedent for

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

On Thursday, February 29, 2024 at 3:14:40 PM UTC+8 Axel Wagner wrote: The loop var change *does* break compatibility. And it did so knowingly and - as clearly explained - was an exception. Stop arguing in bad faith. An exception. :D On Thu, Feb 29, 2024 at 7:03 AM tapi...@gmail.com

[go-nuts] gomobile - no stack traces on Android

With gomobile, I’m not able to see stack traces for errors in the native library. For example: ``` 02-29 00:50:16.021 10940 0 E Go : panic: runtime error: invalid memory address or nil pointer dereference 02-29 00:50:16.021 10940 0 E Go : [signal SIGSEGV: segmentation

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

On Thu, Feb 29, 2024 at 9:12 AM kredop...@gmail.com wrote: > Apologies - sent the response only to you, so I'll write it again here. > > > Doesn't the `go install` command explicitly instruct you to add > $GOBIN/$GOPATH/bin to your $PATH? > > I did check both golang installation docs and the

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

Apologies - sent the response only to you, so I'll write it again here. > Doesn't the `go install` command explicitly instruct you to add $GOBIN/$GOPATH/bin to your $PATH? I did check both golang installation docs and the output of `go help install` - it's very possible I'm missing something,

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

The loop var change *does* break compatibility. And it did so knowingly and - as clearly explained - was an exception. Stop arguing in bad faith. On Thu, Feb 29, 2024 at 7:03 AM tapi...@gmail.com wrote: > > > On Wednesday, February 28, 2024 at 3:19:37 PM UTC+8 Axel Wagner wrote: > > That would

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

On Wednesday, February 28, 2024 at 3:19:37 PM UTC+8 Axel Wagner wrote: That would break backwards compatibility, though. And it would be a re-definition (i.e. existing code would compile, but behave differently at runtime) and is hence not allowed even under the Go 2 transition rules. With

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

Doesn't the `go install` command explicitly instruct you to add $GOBIN/$GOPATH/bin to your $PATH? To me, that seems enough - it feels a bit arduous, to expect this piece of information at any single point on the web where `go install` is mentioned. On Thu, Feb 29, 2024 at 1:39 AM Robert Sawicki

Re: [go-nuts] How to have panic messages show in a PowerShell console

On Wed, Feb 28, 2024 at 4:39 PM 'BENTLEY Thom' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Thanks Jim. > At the moment, I’m using the 1.6.3 version as specified in the internal > documentation the project I’m learning. > I would definitely like to upgrade go to a much later version.

RE: [go-nuts] How to have panic messages show in a PowerShell console

Thanks Jim. At the moment, I’m using the 1.6.3 version as specified in the internal documentation the project I’m learning. I would definitely like to upgrade go to a much later version. Just don’t want to do it before I know it works on the specified version. From: Jim Idle Sent: Wednesday,

[go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

Hey! As I was looking through Go docs recently, I've noticed docs for x/pkgsite wrongly assume that user's $PATH includes $GOPATH/bin, by using `pkgsite` as a way to launch the command right after installing it. Golang installation docs only mention adding

Re: [go-nuts] How to have panic messages show in a PowerShell console

You should upgrade your Go installation to the latest version and retry. Go 1.6.3, if that is not a typo is very old. Jim On Feb 28 2024, at 11:35 am, Thom BENTLEY wrote: > Hi All, > > OS: Windows 10 > GoLang: go1.6.3 windows/386 > > I am trying to have a go executable run and show the panics

[go-nuts] How to have panic messages show in a PowerShell console

Hi All, OS: Windows 10 GoLang: go1.6.3 windows/386 I am trying to have a go executable run and show the panics it causes in the PowerShell console. I think I can use GODEBUG, but all the examples I've seen so far are for Linux. I've set that variable to paniclog=1, but nothing changed. If

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Hey, thanks for raising this important use case.  Do you have any specific examples in mind you could point to? I think the answer should follow easily from what defines a new scope.  New scopes get their own mini-stack frame created, and in that frame the context pointer can be saved like

Re: [go-nuts] assert library with generics?

I’m biased as well. FWIW, this is a subpackage of the error handling solution, err2 . The assertion pkg is proven to be a precious tool for many projects. It is unique because it can be used both for

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

That would break backwards compatibility, though. And it would be a re-definition (i.e. existing code would compile, but behave differently at runtime) and is hence not allowed even under the Go 2 transition rules. I'm also not sure you can exclude *all* pointers to zero-sized variables. Note that

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

> 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

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

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

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

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

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

* Kurtis Rader [240227 03:10]: > On Mon, Feb 26, 2024 at 11:52 PM tapi...@gmail.com > wrote: > > > On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote: > > > > On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com > > wrote: > > > > > From common sense, this is an obvious bug. But

[go-nuts] Minimum version of protoc for given protoc-gen-go version?

Howdy, I've been trying to determine if there is a mapping between the protobuf releases and the protobuf-go releases, without success. Specifically, I'd like to know if there is a requirement for a minimum protoc version to use for a given protoc-gen-go version. Thanks! Tricia -- You

[go-nuts] go build ./... vs. go install ./...

What's the reason for these 2 command to behave differently regarding producing binaries? Serious question for additional points: produce a string to search for ./... on the web, in gmail or on github. Afaict ellipsis won't help here. thanks! -- You received this message because you are

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

On Mon, Feb 26, 2024 at 11:52 PM tapi...@gmail.com wrote: > On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote: > > On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com > wrote: > > > From common sense, this is an obvious bug. But the spec is indeed not > clear enough. > > It

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

On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote: On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com wrote: > From common sense, this is an obvious bug. But the spec is indeed not clear enough. > It doesn't state whether or not comparisons of pointers to two distinct

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

On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com wrote: > From common sense, this is an obvious bug. But the spec is indeed not clear > enough. > It doesn't state whether or not comparisons of pointers to two distinct > zero-size variables should be consistent in a run session. > Though, from

[go-nuts] Re: Failed to compile a generic code using embedded struct

use type Test[T, V interface{A; I}] struct{} instead now. There are still several restrictions in custom generics: https://go101.org/generics/888-the-status-quo-of-go-custom-generics.html On Monday, February 26, 2024 at 10:44:46 PM UTC+8 Albert Widiatmoko wrote: > Hi Go community, > > I

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

On Tuesday, February 27, 2024 at 2:25:46 AM UTC+8 Brien Colwell wrote: Interesting. That seems to break the comparable spec. >> Pointer types are comparable. Two pointer values are equal if they point to the same variable or if both have value nil. Pointers to distinct zero-size variables

Re: [go-nuts] go/version, "go2.00.1" < "go1.0.0"

On Mon, Feb 26, 2024 at 8:26 PM leo zeng wrote: > > package main > > import "go/version" > > func main() { > var val int > val = version.Compare("go2.00.1", "go1.0.0") > print(val) // -1 > } Please write plain text as plain text. It's difficult to read against a dark background.

[go-nuts] go/version, "go2.00.1" < "go1.0.0"

package main import "go/version" func main() { var val int val = version.Compare("go2.00.1", "go1.0.0") print(val) // -1 } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

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

>> Note that there are two distinct variables involved (a and b). You’re right. I misread this. > On Feb 26, 2024, at 1:15 PM, Axel Wagner > wrote: > > On Mon, Feb 26, 2024 at 7:25 PM Brien Colwell > wrote: >> Interesting. That seems to break the comparable spec.

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

On Mon, Feb 26, 2024 at 7:25 PM Brien Colwell wrote: > Interesting. That seems to break the comparable spec. > > >> Pointer types are comparable. Two pointer values are equal if they > point to the same variable or if both have value nil. Pointers to distinct > zero-size variables may or may not

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

Interesting. That seems to break the comparable spec. >> Pointer types are comparable. Two pointer values are equal if they point to >> the same variable or if both have value nil. Pointers to distinct zero-size >> variables may or may not be equal. >> it would be valid for `==` on pointers

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

package main var a, b [0]int var p, q = , func main() { if (p == q) { p, q = , println(p == q) // false } } On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote: > I'm confused by this output. It appears that the interface of two > different pointers to an empty struct are

Re: [go-nuts] Failed to compile a generic code using embedded struct

see https://go.dev/issue/51183 - sean On Mon, Feb 26, 2024, 15:44 Albert Widiatmoko wrote: > Hi Go community, > > I was playing with Go generics and writing some codes, but I faced some > problems. I want to ask questions and help from the community if possible. > Below, I am trying to build a

[go-nuts] Failed to compile a generic code using embedded struct

Hi Go community, I was playing with Go generics and writing some codes, but I faced some problems. I want to ask questions and help from the community if possible. Below, I am trying to build a generic struct via a method through another generic struct. Here's the link to Go Playground:

Re: [go-nuts] [gollvm] Are there any plans to sync with LLVM16 or above?

Hi Sophie, Thanks for the question. The chief blocker for updating gollvm to later versions of LLVM trunk is dealing with LLVM's opaque pointer migration in the gollvm bridge

Re: [go-nuts] assert library with generics?

I'm biased because I had a big hand in designing the API, but I get a lot of pleasure from using this package: https://pkg.go.dev/github.com/go-quicktest/qt It does a lot more than just "equals" and "not equals" but it's still relatively small and low-dependency. And the error messages when

<    1   2   3   4   5   6   7   8   9   10   >