Re: [go-nuts] Need help: Calling panic() is corrupting system stack

2023-04-04 Thread mariappan balraj
Hi Ian, In my test case, I have tried, Go-->C-->Go->panic() only. On Wed, Apr 5, 2023 at 3:35 AM Ian Lance Taylor wrote: > On Mon, Apr 3, 2023 at 9:26 PM mariappan balraj > wrote: > > > > Hi Kurtis Rader, > > > > Thanks for your response. I am working on it. I will quickly share it. > Before t

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

2023-04-04 Thread mariappan balraj
Sorry. Forgot to share go environment. root@soomohan:/home/soomohan/mbalraj/test_hb2# go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/root/.cache/go-build" GOENV="/root/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/root/g

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

2023-04-04 Thread Kurtis Rader
On Tue, Apr 4, 2023 at 3:30 PM robert engels wrote: > Unfortunately, I am on OSX - and Go doesn’t appear to generate a core dump > on panic despite the GOTRACEBACK setting. > > That being said, the stack-traces look ok to me. See attached. > Since I also use macOS (aka "OS X") I investigated why

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

2023-04-04 Thread robert engels
Unfortunately, I am on OSX - and Go doesn’t appear to generate a core dump on panic despite the GOTRACEBACK setting.That being said, the stack-traces look ok to me. See attached. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe fro

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

2023-04-04 Thread Ian Lance Taylor
On Mon, Apr 3, 2023 at 9:26 PM mariappan balraj wrote: > > Hi Kurtis Rader, > > Thanks for your response. I am working on it. I will quickly share it. Before > that one more update. I have commented the below two lines. Now from the > core, I am able to see the correct stack trace. > > 326 func

Re: [go-nuts] There are many private methods with identical code in several different packages, which is clearly not elegant; But adding a public method that can be accessed by other packages (a propo

2023-04-04 Thread Ian Lance Taylor
On Tue, Apr 4, 2023 at 12:05 PM fliter wrote: > > There are many private methods with identical code in several different > packages, which is clearly not elegant; But adding a public method that can > be accessed by other packages (a proposal needs to be made) does not seem > very necessary. I

[go-nuts] Re: There are many private methods with identical code in several different packages, which is clearly not elegant; But adding a public method that can be accessed by other packages (a propo

2023-04-04 Thread Jason Phillips
If you're trying to share code among related packages within a module but not external to the module, "internal" packages[1][2] are one common way to accomplish that. It's a convention that's enforced by the "go" command. This solution is used within the standard library and other official pack

[go-nuts] There are many private methods with identical code in several different packages, which is clearly not elegant; But adding a public method that can be accessed by other packages (a proposal

2023-04-04 Thread fliter
There are many private methods with identical code in several different packages, which is clearly not elegant; But adding a public method that can be accessed by other packages (a proposal needs to be made) does not seem very necessary. Is there a better solution? -- You received this message

Re: [go-nuts] Packages vs methods

2023-04-04 Thread 温博格
If one is using gopls for Go support for an IDE (like vscode), with semantic tokens enabled, the two cases are colored differently. It's incrementally cheap, as gopls already typechecks source. [to enable in vscode: in settings, in the gopls section, "ui.semanticTokens": true] I don't know that t

Re: [go-nuts] Interesting "select" examples

2023-04-04 Thread Jesper Louis Andersen
On Tue, Apr 4, 2023 at 2:22 AM Nigel Tao wrote: > > I'd have to study mux9p for longer, but its select chooses between two > receives, so it could possibly collapse to a single heterogenous > channel. Indeed, both its channels are already heterogenous in some > sense. Both its processTx and proce

Re: [go-nuts] Packages vs methods

2023-04-04 Thread 'Axel Wagner' via golang-nuts
This ist actually a syntactical difference. Both are syntactically just selector expressions. So you'd need *semantic* highlighting, which not a lot of highlighters do. One reason is performance and another is that it means highlighting might fail for incorrectly typed (but syntactically valid) pr

[go-nuts] Re: Interesting "select" examples

2023-04-04 Thread Gaal Yahas
https://github.com/gaal/prolix-go/blob/master/prolix.go#L521 selects on several channels. This was written as an exercise when I was learning the language and may be buggy. The application is an interactive console filter. On Monday, April 3, 2023 at 6:44:43 AM UTC+3 Nigel Tao wrote: > I'm wo

Re: [go-nuts] Packages vs methods

2023-04-04 Thread Reto
On Mon, Apr 03, 2023 at 10:19:49PM -0700, joseph.p...@gmail.com wrote: > Is there an easy way to make > this determination? Sure, use syntax highlighting in your favor. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this gr

Re: [go-nuts] Redfining loop variable semantics - what's the plan?

2023-04-04 Thread Brian Candler
On Tuesday, 4 April 2023 at 07:57:58 UTC+1 Marcello H wrote: The "scary" thing is, that if people don't have enough tests, they are probably not aware of such a bug, or can they still be aware somehow? Do you mean bugs due to the *old* behaviour? You're quite right, the first they may be aware