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

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

I think you should still wait for the outcome of that issue. On Mon, Feb 26, 2024 at 10:39 AM brien colwell wrote: > I learned a lot from this thread, thank you. > > Intuitively the spec seems to conclude a pointer to an empty struct is a > different type of pointer? Normally a pointer wouldn't

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

I learned a lot from this thread, thank you. Intuitively the spec seems to conclude a pointer to an empty struct is a different type of pointer? Normally a pointer wouldn't be able to change values during execution, so we can do things like key maps by pointers. But if every evaluation of the

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

Hello, We want to add support for the loongarch architecture to gollvm, which requires using an LLVM version that supports loongarch (that is, a version >= 16.0.0). The current gollvm only syncs with LLVM trunk at 09629215c272. We did some work synchronizing LLVM locally, but it wasn't enough.

[go-nuts] Using client-go to access a specific context, not current context

I'm relatively new to golang, although I'm pretty familiar with Kubernetes. I want to see if I can use client-go as a framework for a set of scripts that get (or set) information on a specific cluster. I don't want to use the current context, I want to set the context name on the command

Re: [go-nuts] How to have a raw parameter value in cobra?

Ok, that worked. I had tried that before, but I had done it wrong. On Sunday, February 25, 2024 at 1:04:10 PM UTC-8 burak serdar wrote: > Somewhere in your main, you should be calling rootCmd.Execute(). Instead: > > func main() { > // first, make sure there are at least 2 args. Then, process the

Re: [go-nuts] How to have a raw parameter value in cobra?

Somewhere in your main, you should be calling rootCmd.Execute(). Instead: func main() { // first, make sure there are at least 2 args. Then, process the 1st parameter // Then rootCmd.SetArgs(os.Args[2:]) rootCmd.Execute() } On Sun, Feb 25, 2024 at 1:50 PM David Karr wrote: > > But

Re: [go-nuts] How to have a raw parameter value in cobra?

But where would that be done? I'm not certain of the exact role of the "rootCmd.Execute()" function, or the optional "Run" function in the Command object. Neither of those appear to be executed, when I just run " You can do rootCmd.SetArgs(os.Args[2:]), and process the first > parameter

Re: [go-nuts] How to have a raw parameter value in cobra?

You can do rootCmd.SetArgs(os.Args[2:]), and process the first parameter yourself. On Sun, Feb 25, 2024 at 11:43 AM David Karr wrote: > > I am not a new programmer, but I am pretty new to golang, having only written > a couple of small applications, and that was several months ago. I'm trying

[go-nuts] How to have a raw parameter value in cobra?

I am not a new programmer, but I am pretty new to golang, having only written a couple of small applications, and that was several months ago. I'm trying to construct an application using Cobra, using some nonstandard conventions. Is it better to ask a question like this in an issue in the

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

The behavior of Go 1.9 or 1.10 is even more weird. They make the following code print false. ;D package main type T struct {} func main() { var a, b = {}, {} println(a == b || a != b) } On Sunday, February 25, 2024 at 4:30:22 PM UTC+8 tapi...@gmail.com wrote: > Absolutely a bug. > > On

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

Absolutely a bug. 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 equal. In all other cases, > interface equality seems to be the pointer equality. What's

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

FWIW I believe there is enough subtlety here (small changes in the code might trigger different compiler optimizations) that I wouldn't rely too much on probing the compiler with different programs. Instead, I'd suggest decompiling the binary and/or running it in a debugger, to check what the

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

I encountered this tricky bug today. After going through all the playground examples, I finally understood what was happening. Similar to Jochen, I was including encoding.MarshalBinary() and encoding.UnmarshalBinary() in the interface definition. A question though. Why does this bug resolve by

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

What is really fantastical is that a==b prints false, even though the pointers are actually the same. I am guessing some sort of optimization effect is at play here. https://go.dev/play/p/Dsqeh_aAXKT type Foo struct { } func main() { a := {} b := {} fmt.Printf("%t\n", *a == *b)

Re: [go-nuts] Re: Range over int

So in 2012 Cyril Oblikov wrote Why isn't this code correct? var N int = ... for i := range N { doSmth(i) } In my opinion it looks much simpler than: var N int = ... for i := 0; i < N; i++ { doSmth(i) } So we should say to Cyril (whether he is today), that it is now correct. You just

Re: [go-nuts] Re: Range over int

I made some changes to use range over int in our code base and was pleasantly surprised with the improvement in readability. We had quite a few instances where the number of iterations involved a function call which we don't want to repeat: - for i, n := 0, f(); i < n; i++ { + for i := range

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

https://pkg.go.dev/github.com/pierrre/assert#section-readme Le vendredi 23 février 2024 à 09:34:43 UTC+1, Harmen a écrit : > On Thu, Feb 22, 2024 at 04:41:53PM -0800, Seth Hoenig wrote: > > https://github.com/shoenig/test > > > > We've been using this for a couple years now, and it's been

[go-nuts] coverage seems to show code as not covered, but code is actually executed

I've noticed what looks at its surface that some code that is covered doesn't show up in the cover profile data. Unfortunately, I don't have a minimal example as I have no idea how to drill down. So please bear with my explanations and hopefully it's a problem between VT100 and chair, I just

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

On Thu, Feb 22, 2024 at 04:41:53PM -0800, Seth Hoenig wrote: > https://github.com/shoenig/test > > We've been using this for a couple years now, and it's been great. I am > biased though, for obvious reasons. It makes use of the go-cmp library > under the hood for creating legible diffs, and

Re: [go-nuts] Re: Range over int

This is one feature that provides little value beyond saving a few keystrokes and looking slightly nice, but with potential of increased complexity when we need to implement more important features to the language down the road. This is my opinion. It shouldn't have been added, but what was

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

https://github.com/shoenig/test We've been using this for a couple years now, and it's been great. I am biased though, for obvious reasons. It makes use of the go-cmp library under the hood for creating legible diffs, and integrates well with protocmp for when you need to work with protobufs.

Re: [go-nuts] Re: pprof CPU profiles missing inlined frames

Got it. Sent from Yahoo Mail for iPhone On Sunday, February 18, 2024, 12:26 AM, Prashant V wrote: Ahh, I simplified the test too much, my mistake. I modified the example and verified that the profile does capture the inline function:      3.95s 79.16% 79.16%      3.95s 79.16%  main.modify

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

On Thu, Feb 22, 2024 at 10:39 AM Axel Wagner wrote: > > > > On Thu, Feb 22, 2024 at 6:06 PM burak serdar wrote: >> >> I don't think this case really applies here. I get that comparison of >> a==b may or may not be true. The problem is that if a==b at some point >> in a program, it should be the

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

I don't think this case really applies here. I get that comparison of a==b may or may not be true. The problem is that if a==b at some point in a program, it should be the case that a==b for all other cases in that same program. That is, if a==b, then interface{}(a)==interface{}(b), and vice

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

Creating an interface is not creating a pointer to a zero sized variable. a==b prints false. That means, a and b point to different locations Bar(a)==Bar(b) prints true. If a!=b, then Bar(a) must be different from Bar(b) On Thu, Feb 22, 2024 at 9:15 AM Axel Wagner wrote: > > If you expect

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

On Thu, Feb 22, 2024 at 9:00 AM Axel Wagner wrote: > > Note that in the Spec section I quoted above it says "Two distinct zero-size > variables may have the same address in memory" (emphasis mine). > There is no guarantee, that all zero-sized values have the same address > (otherwise, you'd get

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

The compiler can allocate the same address for empty structs, so I actually expected a==b to be true, not false. However, there's something more interesting going on here because: a := {} b := {} fmt.Printf("%t\n", *a == *b) fmt.Printf("%t\n", a == b) fmt.Printf("%p %p\n", a, b) x := Bar(a) y :=

Re: [go-nuts] Probable bug in database/sql

Thank you for the quick response! Let me elaborate a bit: my doubt arose from the hitEOF doc string which says that it's expected to be true when there are no more rows AND no errors where encountered; within Next, hitEOF is set to true when nextLocked's ok is false. That seems misleading to

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

>From the spec : > A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory. On Thu, Feb 22, 2024 at

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

I'm confused by this output. It appears that the interface of two different pointers to an empty struct are equal. In all other cases, interface equality seems to be the pointer equality. What's going on in the empty struct case? ``` package main import "fmt" type Foo struct { } func (self

Re: [go-nuts] Unhappy with the official generics tutorial

On Thursday 22 February 2024 at 10:19:58 UTC+1 Jan Mercl wrote: On Thu, Feb 22, 2024 at 10:06 AM 'Carla Pfaff' via golang-nuts wrote: > This omission is notable considering "any" is among the most frequently used constraints in writing generic code. Interesting to know, I'd naively guess

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

Hi! One more thing to keep in mind for the proposal: sometimes we need to merge two contexts. https://github.com/golang/go/issues/36503 https://github.com/golang/go/issues/57928 -- WBR, Alex. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Unhappy with the official generics tutorial

On Thu, Feb 22, 2024 at 10:06 AM 'Carla Pfaff' via golang-nuts wrote: > This omission is notable considering "any" is among the most frequently used > constraints in writing generic code. Interesting to know, I'd naively guess the opposite. Can you please share the source data set? Thank you.

Re: [go-nuts] Unhappy with the official generics tutorial

The feedback was not specific to the "SumIntsOrFloats" example in the tutorial. The tutorial fails to demonstrate any generic data structures utilizing the "[T any]" constraint or a function with an 'any' constraint, such as "slices.Clone[S ~[]E, E any](s S) S". This omission is notable

[go-nuts] assert library with generics?

Hi, anyone has a tip for a nice (small) "assert" test help library which uses generics for the "equals" and "not equals" functions? testify is the obvious library to use for tests, which works fine, but it would be nice to have something which uses generics here. Thanks! -- You received this

Re: [go-nuts] Unhappy with the official generics tutorial

I don't understand your feedback. How, exactly, should generics handle the `any` type? Documentation can always be improved but how would a generic function that accepts two `any` types perform addition of those "any" values? On Thu, Feb 22, 2024 at 12:01 AM 'Carla Pfaff' via golang-nuts <

[go-nuts] Unhappy with the official generics tutorial

The Go documentation, available at https://go.dev/doc/, features only one tutorial dedicated to generics, found at https://go.dev/doc/tutorial/generics. This tutorial lacks any examples employing the 'any' constraint, nor does it mention it. Instead, it begins with the use of an 'int64 |

Re: [go-nuts] heap pprof profile showing only 10Gi out of 50Gi of actually used memory

Worth studying https://tip.golang.org/doc/gc-guide The heap profile will show you the heap memory in use, but the OS process info will tell you the total process size, including memory in use, and memory GC which has been marked as free and reclaimed by the GC, but not relinquished to the OS.

Re: [go-nuts] Probable bug in database/sql

On Wed, Feb 21, 2024 at 4:27 PM Marco De Zio wrote: > > It seems to me that the second flag returned by Rows.nextLocked is wrongly > interpreted by Rows.Next as it sets rs.hitEOF = true when ok is false; also > Rows.nextLocked should set ok to true in some of the cases where right now >

[go-nuts] Probable bug in database/sql

It seems to me that the second flag returned by Rows.nextLocked is wrongly interpreted by Rows.Next as it sets rs.hitEOF = true when ok is false; also Rows.nextLocked should set ok to true in some of the cases where right now returns false. Reference in code:

Re: [go-nuts] heap pprof profile showing only 10Gi out of 50Gi of actually used memory

it's a purely golang app On Tuesday, February 20, 2024 at 9:38:35 PM UTC+3 Kurtis Rader wrote: > Is your app built with CGO? That is, do you link it against any C/C++ code > that might be calling malloc? > > On Tue, Feb 20, 2024 at 5:22 AM Frank Flipper wrote: > >> I have an app that's put

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

On Wed, Feb 21, 2024 at 1:36 AM Sam Vilain wrote: > I had a brief look on the Golang issues in Github and could not find any > prior proposals along this line using "context" and "dynamic scope" as > search terms, so I'll submit this as a "new" proposal for now > FWIW some prior discussion on

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

That is a good reason as to why putting timeouts and cancellation in the “context” always felt wrong to me. These are per request notions - and creating a new context to specify them seems off. But as I mentioned in the other post, without a concept of security context it doesn’t matter much -

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

https://go.dev/issue/21335 - sean On Wed, Feb 21, 2024, 00:36 Sam Vilain wrote: > Alright, well thanks for your input. > > I do think these questions can be answered; exploring the use cases in a > proposal format should hopefully show that the impact of closures would not > normally be an

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

Forgive me if I missed that, but what if I have multiple context vars, because I need to pass different (derived) contexts into different functions/receivers? Take unit tests as real-world examples. On Wednesday, February 21, 2024 at 1:37:05 AM UTC+1 Sam Vilain wrote: > Alright, well thanks

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

FWIW, I think having a bound context to an execution context is a valuable addition. One thing about Go that has always felt lacking is dynamic code loading execution. There is the plugin facility but it doesn’t seem to have been widely adopted. If it were, I think the Go team would find it needs

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

Alright, well thanks for your input. I do think these questions can be answered; exploring the use cases in a proposal format should hopefully show that the impact of closures would not normally be an issue.  Possibly the worst case is if you had a library to some external service, and at

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

If I may quote myself: > And no matter which choice you make for the language - it means that if the programmers wanted the other, they'd have to jump through annoying hoops and get confusing and hard to debug problems. Having a mechanism to get one or the other semantic doesn't change the fact

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

On 2/17/24 1:32 AM, Axel Wagner wrote: On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain wrote: I would argue that the matter can be simply decided by choosing the /calling/ stack, not the destination stack. I agree that this is *one choice*. But the point is, that *sometimes* you'd want

Re: [go-nuts] heap pprof profile showing only 10Gi out of 50Gi of actually used memory

Is your app built with CGO? That is, do you link it against any C/C++ code that might be calling malloc? On Tue, Feb 20, 2024 at 5:22 AM Frank Flipper wrote: > I have an app that's put inside k8s container and is being monitored in > grafana. Memory usage graph shows me that one of the pods is

Re: [go-nuts] Ghost/indirect dependency on a custom package

Is there no `cmd/migrations/go.mod`? Have you not tried debugging with Delve? -Mike On Tuesday, February 20, 2024 at 5:29:19 AM UTC-5 Peter Bočan wrote: > That seems to work on the repo/go.mod level, if I am not mistaken. I would > need something finer on the binary/compilation unit level. >

Re: [go-nuts] When i try to input name from keyboard it is not taking the input

* Marvin Renich [240220 10:52]: > * Sagar Byahatti [240220 08:22]: > > package main > > > > import "fmt" > > > > func main() { > > > > var projectName = "APY" > > var sub = 50 > > > > fmt.Println("Welcome to", projectName, " the number of subscriber is ", > > sub) > >

Re: [go-nuts] When i try to input name from keyboard it is not taking the input

* Sagar Byahatti [240220 08:22]: > package main > > import "fmt" > > func main() { > > var projectName = "APY" > var sub = 50 > > fmt.Println("Welcome to", projectName, " the number of subscriber is ", > sub) > fmt.Println("Enter your name: ") > var userName string > >

[go-nuts] When i try to input name from keyboard it is not taking the input

package main import "fmt" func main() { var projectName = "APY" var sub = 50 fmt.Println("Welcome to", projectName, " the number of subscriber is ", sub) fmt.Println("Enter your name: ") var userName string fmt.Scan() fmt.Printf("%v, your PRAN Number is",

[go-nuts] heap pprof profile showing only 10Gi out of 50Gi of actually used memory

I have an app that's put inside k8s container and is being monitored in grafana. Memory usage graph shows me that one of the pods is using 50Gi of memory, but when I go to /debug/pprof/heap I only see that it's using only 10-11Gi. I'm aware that pprof is not meant to track and show every

Re: [go-nuts] Ghost/indirect dependency on a custom package

That seems to work on the repo/go.mod level, if I am not mistaken. I would need something finer on the binary/compilation unit level. Peter. On Tuesday 20 February 2024 at 10:19:04 UTC Jan Mercl wrote: > On Tue, Feb 20, 2024 at 11:07 AM Peter Bočan wrote: > > > Is there a way to debug this?

Re: [go-nuts] Ghost/indirect dependency on a custom package

On Tue, Feb 20, 2024 at 11:07 AM Peter Bočan wrote: > Is there a way to debug this? Is there a way to step over the initialisation > order? I try to get help from '$ go mod graph' in similar investigations. -- You received this message because you are subscribed to the Google Groups

[go-nuts] Ghost/indirect dependency on a custom package

Hello Gophers! I am facing a very odd issue. I have recently joined a company and wrote a small database migration binary which is co-located in the same github repo as the service which database migrations it. For whatever reason the DB migration binary, when it runs on the cluster, it

[go-nuts] Re: CGO ld: Undefined symbols

I'd like to state my observations (this is not a definitive answer). On macOS it is okay to ignore the undefined symbols with -undefined dynamic_lookup On Windows you need to link with a library containing the symbols On Linux you don't need to care at all... as long as the binary during

Re: [go-nuts] Need help to close/shutdown http server when underlying socket fd explicitly bind used

On Sat, Feb 17, 2024 at 10:23:40AM -0800, binbinschen00 wrote: > If I want to bind the socket fd to another interface for the same http > server (meaning same address:port), do I need to close/shutdown the > existing server first and start a new one? Is there a way to just modify > the socket

[go-nuts] CGO ld: Undefined symbols

Hello all, I try to build a Go library that uses Lua. This library will be used together with an executable that contains the Lua functions, so I (believe) I don't need to have the dynamic Lua library. My code: ~~~ package main /* #include #include #include #include #cgo CFLAGS:

Re: [go-nuts] help

Your code includes this line: log.Println("DATABASE_URL:", os.Getenv("DATABASE_URL")) What does the log message actually show? This will confirm whether the environment variable is being passed correctly or not. I note you are using a different YAML structure for "environment" under go_app than

Re: [go-nuts] help

What’s your DATABASE_URL? If your on Windows make sure you use localhost not 127.0.0.1 as they aren’t necessarily the same thing On Sun, 18 Feb 2024 at 04:54, Sunday Ajayi wrote: > Hi guys, > Please I am having a little issue with my go project using docker. > > I set up my Postgres db in

Re: [go-nuts] help

Hi. Error says that the connection string that is executed is pointing to TCP 127.0.0.1:5432 from your docker compose file there is no such string, you are correctly using go_db host name to work inside the docker network. So my guess is that you are not executing what you think you are

[go-nuts] Re: pprof CPU profiles missing inlined frames

Ahh, I simplified the test too much, my mistake. I modified the example and verified that the profile does capture the inline function: 3.95s 79.16% 79.16% 3.95s 79.16% main.modify (inline) 1.04s 20.84% 100% 4.99s 100% main.main

Re: [go-nuts] help

Hi guys, Please I am having a little issue with my go project using docker. I set up my Postgres db in docker with my go app but it is unable to connect. Please what could be the issue? I will share the docker-compose file and the main.go here main.go package main import ( "database/sql"

Re: [go-nuts] Need help to close/shutdown http server when underlying socket fd explicitly bind used

Thanks Reto, that works! If I want to bind the socket fd to another interface for the same http server (meaning same address:port), do I need to close/shutdown the existing server first and start a new one? Is there a way to just modify the socket bind without close/shutdown the socket?

[go-nuts] help

hi everyone. my name is pilar. im trying to learn coding for the first time in my life..im so lost can anyone let me know how to even begin on this mission. please any advise will be greatly appreciated. you folks have a great day cant waint to hear from ya -- You received

Re: [go-nuts] Re: Range over int

I agree with you. Powered By Citizen  On Saturday, February 17, 2024, 1:19 AM, Kurtis Rader wrote: It's not just changing `k` inside the loop body that makes the transformation invalid -- your observation also applies to modifying `i` inside the loop body. Modifying either variable inside

Re: [go-nuts] XML Canonicalization and signing

Hi Karlovsly Thanks for the prompt reply . Let me try it out and get back to you. Kind regards, Shivli On Thursday, February 15, 2024 at 2:26:43 PM UTC+5:30 Karlovsky Alexey wrote: > It's a strange task, because for xml there is a XMLDSIG standard for > signing XML documents. I recommend

[go-nuts] Re: pprof CPU profiles missing inlined frames

This is a problem with your test. pprof is correct here. Since you never use n, when double is inlined its body is compiled completely away. On Thursday, February 15, 2024 at 10:18:07 PM UTC-8 Prashant V wrote: > Is it expected that CPU profiles taken with pprof don't include inlined > frames?

Re: [go-nuts] Re: Range over int

It's not just changing `k` inside the loop body that makes the transformation invalid -- your observation also applies to modifying `i` inside the loop body. Modifying either variable inside the loop body is extremely rare in my experience and doing so warrants a "dragons be here" comment. Still,

<    5   6   7   8   9   10   11   12   13   14   >