Re: [go-nuts] Re: MCP <> DAP server written in Go

Anyone who uses LLMs knows they make mistakes. That doesn't mean it's not a useful tool. I would have died and gone to heaven had someone shown me LLM capabilities in 2015. Many of us thought this wouldn't be possible in our lifetimes. It's a fancy autocomplete, but a very very fancy one. Don't

Re: [go-nuts] Re: MCP <> DAP server written in Go

Dnia Thu, 24 Jul 2025 00:28:48 -0700 (PDT) "'Christian Stewart' via golang-nuts" napisał/a: > this should be a big leap forward in LLM capability for software bugfixing. https://arstechnica.com/information-technology/2025/07/ai-coding-assistants-chase-phantoms-destroy-real-user-data/ :) -- Wo

Re: [go-nuts] Re: Could go test make running static analyzers easier?

Thanks for the links, Sean. I was unaware of these issues and they seem to be working towards a very similar goal - I'll drop a note somewhere appropriate that links in Axel's typed struct tags issue. Re: source text, it seems like embedding at some point in routines under src/cmd/go/internal/t

Re: [go-nuts] Re: Could go test make running static analyzers easier?

On Sun, 20 Jul 2025 at 10:42, 'Brian Candler' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Does the compiled binary even carry enough information about the original > source to be able to do that, for a useful set of analyses? > It could: //go:embed *.go var source embed.FS `go test

Re: [go-nuts] Re: Use a hash/maphash uint64 as map key

On Thursday, June 26, 2025 at 9:22:14 AM UTC+2 Robert Engels wrote: “ negligible chance of collision” is not scientific. It depends on the use case whether or not it is negligible. On Jun 26, 2025, at 2:14 AM, Jason E. Aten wrote: negligible chance of collision Thanks Robert. You're just se

Re: [go-nuts] Re: Use a hash/maphash uint64 as map key

“ negligible chance of collision” is not scientific. It depends on the use case whether or not it is negligible. > On Jun 26, 2025, at 2:14 AM, Jason E. Aten wrote: > > negligible chance of collision -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] Re: Self Built Utility package cannot access variables beyond main

No, the function does return two variables, as I take out "er" from "out, err:=" go vet report a flaw: /util.go:51:9: cannot initialize 1 variables with 2 values On Tue, Jun 10, 2025 at 10:28 AM Robert Engels wrote: > Just use VSCode with the standard Go plugin. > > On Jun 9, 2025, at 9:23 PM, K

Re: [go-nuts] Re: Self Built Utility package cannot access variables beyond main

Just use VSCode with the standard Go plugin. On Jun 9, 2025, at 9:23 PM, Kurtis Rader wrote:On Mon, Jun 9, 2025 at 7:01 PM Zhaoxun Yan wrote:Oh! Thank you Kurtis. So do you have a special Editor to inform you about the functions? My current editor cannot even tell what typ

Re: [go-nuts] Re: Self Built Utility package cannot access variables beyond main

On Mon, Jun 9, 2025 at 7:01 PM Zhaoxun Yan wrote: > Oh! Thank you Kurtis. So do you have a special Editor to inform you about > the functions? My current editor cannot even tell what type of variable a > go function would return, let alone parameter hints, etc. > I use a VIM plugin that talks to

Re: [go-nuts] Re: Self Built Utility package cannot access variables beyond main

Oh! Thank you Kurtis. So do you have a special Editor to inform you about the functions? My current editor cannot even tell what type of variable a go function would return, let alone parameter hints, etc. On Mon, Jun 9, 2025 at 1:50 PM Kurtis Rader wrote: > > > On Sun, Jun 8, 2025 at 9:35 PM Zh

Re: [go-nuts] Re: Self Built Utility package cannot access variables beyond main

On Sun, Jun 8, 2025 at 9:35 PM Zhaoxun Yan wrote: > it turned out to be an error misjudgement. The real line that caused > trouble is this: > s = er.Error()+string(out) > The error is gone after I changed it to this line : > s = fmt.Sprintf("%v %s", er, out) > The stdlib os.exec.Command()

Re: [go-nuts] Re: url.ParseRequestURI validation of path

Hi Diego, You're absolutely right to point out the flaw in my snippet, thanks for catching that. That said, my goal wasn't to provide a complete solution, but rather a minimal example to highlight the core issue. Judging from your ability to spot the edge case, I’m sure you’re more than capable of

Re: [go-nuts] Re: url.ParseRequestURI validation of path

Hi Alexander, thank you for your response. In your example, strings.Contains(strings.ToLower(original), "%2f") will give a false positive if we have passed a "/" in a query param since it would also be url-encoded, and this is valid and expected. You will come across this in your new API if you

Re: [go-nuts] Re: [security] Go 1.24.3 and Go 1.23.9 are released

On Sun, 2025-05-11 at 13:30 +, 'Eric Jacksch' via golang-nuts wrote: > > > How to build go from source The instructions at https://go.dev/doc/install/source should help with this. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubsc

Re: [go-nuts] Re: Goroutines and channels optimization

Thanks, I'll check it out. On Sun, 11 May 2025, 22:44 Robert Engels, wrote: >  > This seems to be a decent meta reference > https://www.linkedin.com/advice/0/what-key-skills-tools-cloud-performance-tuning?utm_source=share&utm_medium=member_ios&utm_campaign=share_via#:~:text=Cloud%20performance%

Re: [go-nuts] Re: Goroutines and channels optimization

Thanks for the tip! Could you suggest some resources for the same regarding these design considerations if you know of any ? On Sun, 11 May 2025, 21:48 Robert Engels, wrote: > Of that I’m not sure. It is based on deep knowledge of how these things > are built from the hardware to the kernel to

Re: [go-nuts] Re: Goroutines and channels optimization

Of that I’m not sure. It is based on deep knowledge of how these things are built from the hardware to the kernel to network protocols to the service layers. It broadly falls under performance tuning of which there is lots of literature. The key element of how channels and go routines play into thi

Re: [go-nuts] Re: Goroutines and channels optimization

Does we have any kind of documented material or mathematical theory type stuff for these things or is it more like hit or try On Sun, 11 May 2025, 08:04 ren...@ix.netcom.com, wrote: > The two most likely limiters in performance will be your network pipe to > the cloud and the QPS quota offered b

Re: [go-nuts] Re: Meet Golid : A Solid.js inspired framework written 100% in Go.

The plan is : 1. Some additional wrappers around scyscall/js 2. A more sophisticated CLI : I am working on code generators and also on HTML-to-Gomponents converter which allows for optional definition of the components in HTML. 3. Add more examples : Todo list, etc. A this stage, d

Re: [go-nuts] Re: url.ParseRequestURI validation of path

EscapedPath() sometimes re-generates the escaped path, especially if the original path contains unencoded characters like Ñ or literal spaces. When it does this reconstruction, it works from the decoded path segments, which is likely why the original %2F encoding was lost in your example. This seem

Re: [go-nuts] Re: A CLI that generates tests using AI

I like command line tools, but the docs here are a little too Spartan/sparse. For example, how does one describe to the AI what kind of test you want it to write? Does it guess? That would be risky, or asking a bit much. On Sunday, May 4, 2025 at 8:59:48 AM UTC+1 Cheikh Seck wrote: > It's a st

Re: [go-nuts] Re: A CLI that generates tests using AI

It's a standalone tool and can be used with these ai IDEs On Sun, 4 May 2025, 03:32 Rashmin Mudunkotuwa (Rashm1n), < rashmin.ravi...@gmail.com> wrote: > What does this do that the existing AI IDE's (Curser, Windsurf etc.) don't > ? > > On Saturday, 3 May 2025 at 7:19:14 pm UTC+5:30 Cheikh Seck wr

Re: [go-nuts] Re: hhtp mux performance question

Here is a minimal program that I tried out: https://go.dev/play/p/Rp03LxuvDVw . Note that it measures the duration of w.Write(msg). On my local host I displayed the web page http://localhost:8080/firefox with Firefox, and http://localhost:8080/chromium with chromium. I don’t have chrome insta

Re: [go-nuts] Re: hhtp mux performance question

Hi. Unless you provide a standalone test program it will very difficult for anyone to assist you. On Apr 29, 2025, at 5:03 AM, christoph...@gmail.com wrote:More strange result.With Firefox, the time measured with time.Since is 55μs on average, and with Chromium it’s on average 200μs but with a bi

Re: [go-nuts] Re: Implementing Server-Sent Events (SSE)

You can use the EventSource API: https://developer.mozilla.org/en-US/docs/Web/API/EventSource Il giorno gio 24 apr 2025 alle ore 03:28 Kevin Chowski ha scritto: > > It would be nice to see an example of how to utilize this from the browser > rather than curl, e.g. some JavaScript client code. >

Re: [go-nuts] Re: slog default logger: replace and then revert

Thanks Andrew, I see. As you mentioned I get a consistent behaviour if I define my own logger in the first place. https://play.golang.com/p/PriUZnVKJOn Chris Am Fr., 18. Apr. 2025 um 01:27 Uhr schrieb Andrew Harris < harris.and...@gmail.com>: > Sorry for spam, quick clarification: where I said "t

Re: [go-nuts] Re: *-TeX (Star-TeX) v0.7.1 w/ pure-Go PDF generation

Hallo Patrick, On Tue Apr 15, 2025 at 11:59 CET, Patrick wrote: > Hello Sebastien, [...] > I have given up on > it but at least tried to mimic the algorithmic behaviour > in https://github.com/boxesandglue/boxesandglue yes, I had stumbled upon your nice set of packages. they gave me some clues

Re: [go-nuts] Re: Why this compilation error ?

Inline cost is part of how Go decides what funcs to inline. There are some interesting patterns (maybe even idioms?) in Go that specifically try to inline a lot of code to prevent values from escaping to the heap when they don't have to. Concrete examples from -gcflags='-m -m': ./main.go:7:6: c

Re: [go-nuts] Re: Why this compilation error ?

s/code/cost On Tuesday, March 18, 2025 at 10:22:48 PM UTC+8 tapi...@gmail.com wrote: > Inline cost is estimated at compile time, not the real code. > > But I sorry to say "*new(T) has a smaller inline cost than T{}". it is a > little larger in fact. > The inline cost of new(T) is smaller than T{

Re: [go-nuts] Re: Why this compilation error ?

See the section wrapped in """ in Jan's reply. Quoted differently: > A parsing ambiguity arises when a composite literal using the TypeName form of the LiteralType appears as an operand between the keyword and the opening brace of the block of an "if", "for", or "switch" statement, and the comp

Re: [go-nuts] Re: Why this compilation error ?

I couldn't find a clear answer to my question. I didn't see what I was supposed to find in the reference manual. On my side I understood that the {} caused an ambiguity with the { of the if clause. The ambiguity is removed by putting the expression in parenthesis. if (v == Version{}) {. // <-

Re: [go-nuts] Re: Why this compilation error ?

Inline cost is estimated at compile time, not the real code. But I sorry to say "*new(T) has a smaller inline cost than T{}". it is a little larger in fact. The inline cost of new(T) is smaller than T{}. I got it mixed up. On Tuesday, March 18, 2025 at 2:39:19 PM UTC+8 Dan Kortschak wrote: >

Re: [go-nuts] Re: Why this compilation error ?

On Mon, 2025-03-17 at 21:03 -0700, tapi...@gmail.com wrote: > I prefer *new(T) over T{}, because not only the reason here, but also > the former has a smaller inline cost. What do you mean by "inline cost"? https://godbolt.org/z/h8Krq7W8G -- You received this message because you are subscribed

Re: [go-nuts] Re: Why this compilation error ?

I prefer *new(T) over T{}, because not only the reason here, but also the former has a smaller inline cost. On Monday, March 17, 2025 at 4:49:51 PM UTC+8 Jan Mercl wrote: > On Mon, Mar 17, 2025 at 9:45 AM tapi...@gmail.com > wrote: > > > You can use *new(Version) instead of Version{} to avoid

Re: [go-nuts] Re: Why this compilation error ?

On Mon, Mar 17, 2025 at 9:45 AM tapi...@gmail.com wrote: > You can use *new(Version) instead of Version{} to avoid parsing ambiguity. FTR: This would never pass my review. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from thi

Re: [go-nuts] Re: Exposing newcoro/coroswitch

I may be missing something, but if your concern about passing the iterator to another goroutine, is with closing the wait channel here (which is indeed problematic), I think this change

Re: [go-nuts] Re: GC hint for collection timing

One other note, it often works for large programs as well if you control the access pattern, as the OS will page out based on LRU so you can just keep allocating and never free… until you end. To make this work you sometimes need a special allocator so that old pages aren’t touched when allocating

Re: [go-nuts] Re: GC hint for collection timing

Btw this technique is common place for small utility programs - it is often harder to code the object life cycle in a complicated tree - so just don’t free until the process ends. Which is why GC is so beneficial for most programs. On Feb 27, 2025, at 5:47 PM, Robert Engels wrote:This is a perfec

Re: [go-nuts] Re: GC hint for collection timing

This is a perfect case of weak references BUT these are still objects the GC needs to track, etc. A better solution for a compiler, is that if the original code did not need to free - and that was a substantial amount of the compiler garbage to make a difference - just run the compiler with GC turn

Re: [go-nuts] Re: GC hint for collection timing

>GOMEMLIMIT (https://go.dev/doc/gc-guide#Memory_limit) applies this idea to all allocations. (GC doesn't need to run if there is lots of headroom). Isn't that only useful if there's a limit, and you know what it is? That isn't the case for the Go command in general. >I'm not sure I understand the

Re: [go-nuts] Re: GC hint for collection timing

On Thu, Feb 27, 2025 at 5:56 PM Amnon wrote: > Go nearly had Arenas a few years ago. And I think they are still used in > Google. > But they were pulled because the polluted the API's of too many libraries. > See https://github.com/golang/go/issues/51317 > On Thursday, 27 February 2025 at 07:55:2

Re: [go-nuts] Re: Exposing newcoro/coroswitch

On Wed, Feb 26, 2025 at 2:18 AM Nuno Cruces wrote: > > On Tuesday 25 February 2025 at 18:15:40 UTC Ian Lance Taylor wrote: > > I think what you're presenting is an argument for > > package iter > > // Push returns an iterator, a yield function, and a stop function. > // The iterator will return al

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Assuming I'm not wrong, this is my updated proposal: package iter // Push takes a consumer function, and returns a yield and a stop function. // It arranges for the consumer to be called with a Seq iterator. // The iterator will return all the values passed to the yield function. // The iterator

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Hi Ian, On Tuesday 25 February 2025 at 18:15:40 UTC Ian Lance Taylor wrote: I think what you're presenting is an argument for package iter // Push returns an iterator, a yield function, and a stop function. // The iterator will return all the values passed to the yield function. // The iter

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Hi Andrew. My personal goal here is exclusively to support aggregate functions, which in SQLite terms actually have `Step(V)` and `Final() R` callbacks (rather than `Step(V)` and `Value() R`), because those semantics more closely match iterators and `iter.Seq`. I have a different interface for

Re: [go-nuts] Re: Exposing newcoro/coroswitch

I just want to highlight a theoretical cliff around `iter.Push` or `func processor(seq iter.Seq[V]) R` contrasted with solutions involving step and value callbacks (built-in or custom sqlite aggregate

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Ian, just to note that your message is not at all lost. I just need to look at it carefully in front of a computer, which I won't be able to do today. But if it works, I agree that looks like a nicer, more general API than mine proposal, which is exactly what I was hoping for, so many thanks! Reg

Re: [go-nuts] Re: Exposing newcoro/coroswitch

On Tue, Feb 25, 2025 at 11:52 AM 'Brian Candler' via golang-nuts wrote: > > You can curry a function? > > On Tuesday, 25 February 2025 at 18:52:09 UTC Jason E. Aten wrote: >> >> Hi Ian, I'm not quite understanding -- is Push meant to take an input seq >> too? like >> >> func Push[E any](inputSeq

Re: [go-nuts] Re: Exposing newcoro/coroswitch

I agree. Simplifying the number of ways to perform iteration is a huge win for readability. I’ve never seen an advanced use of co routines I would consider readable. A higher level construct is immensely more readable. The blog post I shared goes into the reasons why. A language that doesn’t

Re: [go-nuts] Re: Exposing newcoro/coroswitch

You can curry a function? On Tuesday, 25 February 2025 at 18:52:09 UTC Jason E. Aten wrote: > Hi Ian, I'm not quite understanding -- is Push meant to take an input seq > too? like > > func Push[E any](inputSeq iter.Seq[E]) (seq iter.Seq[E], yield func(E), > stop func()) > ^

Re: [go-nuts] Re: Exposing newcoro/coroswitch

On Tue, Feb 25, 2025 at 6:17 AM Nuno Cruces wrote: > > I wanted a solution that doesn't necessarily involve goroutines and channels, > for the same reason that iter.Pull was created: because goroutines and > channels add unnecessary parallelism that has the potential to introduce data > races,

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Buffering trivially solves the issue, sure, but the point (of both the interface and Seq) is not to buffer. The database could spit (many) millions of rows that we want to aggregate into a result. It's why we have algorithms like HyperLogLog , and T-Dig

Re: [go-nuts] Re: Exposing newcoro/coroswitch

I agree with Aston's insight. Step could be just buffering. Re "the "standard" Go iteration interface." <- this is not.a great API to offer clients, for the reasons you observe. Hence I don't think it should be considered as an API standard, or much of a standard at all, as such. Its better as

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Nuno, can you say more about the constraints here? It seems you could you accomplish your goal of creating an AggregateFunction out of an iter.Seq processor function by storing all of the results in a slice as Step is called, then running your processor function on the slice of values ( slices.Valu

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Hi Jason, First of all, thank you for your interest. On Tue, 25 Feb 2025 at 12:28, Jason E. Aten wrote: > > The problem specification you originally gave was this: > > > "to implement... a "processor" function that accepts an iter.Seq and > returns a result: > >func processor(seq iter.Seq[v

Re: [go-nuts] Re: Exposing newcoro/coroswitch

That project has a link to a very interesting get in the weeds related blog post https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/On Feb 25, 2025, at 8:02 AM, Robert Engels wrote:Also, there’s this project in Go that looks interesting https://github.com/s

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Also, there’s this project in Go that looks interesting https://github.com/sourcegraph/concOn Feb 25, 2025, at 7:17 AM, Robert Engels wrote:Hi Jason. I don’t think I was clear. I think a parser implementation is a natural fit for a generator - a generator being a specialization of a coroutine. Th

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Hi Jason. I don’t think I was clear. I think a parser implementation is a natural fit for a generator - a generator being a specialization of a coroutine. The message I was responding to was the request to open the co routine facility that powers it. That’s what I was going against. I agree that ma

Re: [go-nuts] Re: Exposing newcoro/coroswitch

On Tuesday, February 25, 2025 at 4:29:44 AM UTC Robert Engels wrote: You don’t need co routines if you have real concurrency. The generator use case is simply an optimization that wouldn’t be necessary if the concurrency model was more efficient - and there was a more expressive way to use it.

Re: [go-nuts] Re: Exposing newcoro/coroswitch

You don’t need co routines if you have real concurrency. The generator use case is simply an optimization that wouldn’t be necessary if the concurrency model was more efficient - and there was a more expressive way to use it. I demonstrated on some Java boards that generators are easily implemented

Re: [go-nuts] Re: https://go-talks.appspot.com still working?

Hi Sebastien Binet, can you show us how to do it? I'm struggling to deploy my slides to app engine on GCP. thanks, Srini On Saturday, May 13, 2023 at 11:15:52 AM UTC-4 Sebastien Binet wrote: > > On Sat May 13, 2023 at 17:02 CET, Jens-Uwe Mager wrote: > > Someone must have fixed something, as

Re: [go-nuts] Re: Go Module Mirror

Also I don’t see the version hash listed on the package page (browsing in iOS Safari). That would help to compare against the repo for tampering.On Feb 5, 2025, at 9:25 AM, will@gmail.com wrote:Looks like the package is still in the proxy, and sadly is used by one known person.It would be use

Re: [go-nuts] Re: Race in table driven tests with httptest server

That’s true. I should have mentioned, that there are many test cases and several handlers involved in the real code. I tried to boil it down to a simple snippet reproducing the issue (https://sscce.org/), and some context got lost on that path. Let me explain a little more: I test a binary (as par

Re: [go-nuts] Re: Getting new coverage output format from go test -cover

I'm so glad to hear it helped you! > I wonder where the blog author found that flag? It's not exposed in `go test` I guess "-test.gocoverdir" parameter is not exposed to go test users well. There is an another comment that it was very hard to find documents about "-test.gocoverdir" parameter.

Re: [go-nuts] Re: Getting new coverage output format from go test -cover

Oh that's perfect! Pretty much what I was looking for. Let me test it and get back to you. I wonder where the blog author found that flag? It's not exposed in `go test` On Tuesday, January 14, 2025 at 5:27:07 AM UTC-8 Byungjun You wrote: > Have you try go test with -args -test.gocoverdir param

Re: [go-nuts] Re: Issue with Adding Exception Vector Handler in Go

Thanks for answering. Basically I found a work around. As I said, I understand go handles error differently, but imagine my windows OS send an exception signal not handled by go, how to handle this ? Escpecially given I don;'t just want the default Go handler that print the stack with the exce

Re: [go-nuts] Re: Issue with Adding Exception Vector Handler in Go

You may also want to look into ago “signal handling” as a potential solution. On Jan 18, 2025, at 8:06 AM, Robert Engels wrote:If that wasn’t clear. It doesn’t seem to be supported. You need to catch the exception in the native code and return an error code back to Go. On Jan 18, 2025, at 7:32 AM

Re: [go-nuts] Re: Issue with Adding Exception Vector Handler in Go

If that wasn’t clear. It doesn’t seem to be supported. You need to catch the exception in the native code and return an error code back to Go. On Jan 18, 2025, at 7:32 AM, Robert Engels wrote:Go and C handle errors differently: Go: Go uses error values returned from functions to handle errors. Th

Re: [go-nuts] Re: Issue with Adding Exception Vector Handler in Go

Go and C handle errors differently: Go: Go uses error values returned from functions to handle errors. This approach makes error handling explicit and encourages developers to handle them gracefully. C: C often uses exceptions and signals to handle errors. However, C's error handling mechanisms don

Re: [go-nuts] Re: how to get dirt memory in go

Thanks, i'm check bench with modernc ср, 15 янв. 2025 г. в 10:57, tapi...@gmail.com : > > see https://go101.org/q-and-a/make-dirty-byte-slices.html > > On Tuesday, January 14, 2025 at 9:44:40 PM UTC+8 Vasiliy Tolstov wrote: >> >> Hi! I'm try to search answers but have no luck. In go i can create >

Re: [go-nuts] Re: Getting new coverage output format from go test -cover

Have you try go test with -args -test.gocoverdir parameters? > go test -cover ./... -args -test.gocoverdir="{a directory where coverage reports should be generated}" I found this blog post is very helpful when merging unit and integration test coverage reports. https://dustinspecker.com/posts/g

Re: [go-nuts] Re: Getting new coverage output format from go test -cover

The blog post doesn't provide a way to translate the output of `go test -coverprofile ...` (which is the so-called legacy text format) into the new binary format, which `go tool covdata merge` expects. It only provides it in the reverse, i.e. the new binary format to the legacy format. So it me

Re: [go-nuts] Re: Getting new coverage output format from go test -cover

On Sat, Jan 11, 2025 at 10:07 AM Paul Chesnais (papacharlie) wrote: > > Is there another forum I can ask about this? Should this be a feature request > against the go team directly? It seems strange that the formats haven't been > converged, or that there's no way to get the new binary format fr

Re: [go-nuts] Re: Working with release candidates

On Friday, December 20, 2024 at 5:49:04 PM UTC-6 Dan Kortschak wrote: Almost certainly not. The point of module version specification is to allow reproducible builds. Leaving this up to things outside the build's dependencies makes this non-achievable. Well, we agree then, but is this "tool

Re: [go-nuts] Re: Working with release candidates

Opened https://github.com/golang/go/issues/70949 On Friday, December 20, 2024 at 10:57:50 PM UTC+1 Michael Pratt wrote: > Could you file an issue about this with reproduction steps? My attempt to > reproduce this works fine. > > go.mod > > ``` > module example.com > > go 1.24rc1 > > tool ( >

Re: [go-nuts] Re: Working with release candidates

If you want to know clearly which toolchain version you are using, you can try GoTV (https://go101.org/apps-and-libs/gotv.html). I have used it for two years almost without touching the `go` command directly. On Saturday, December 21, 2024 at 6:07:35 AM UTC+8 Jeffery Carr wrote: > Wow. This syn

Re: [go-nuts] Re: Working with release candidates

On Fri, 2024-12-20 at 16:13 -0600, Jeffery Carr wrote: > versions of required binaries are, in my experience, best left to the > OS distribution and packaging people. Almost certainly not. The point of module version specification is to allow reproducible builds. Leaving this up to things outside

Re: [go-nuts] Re: Working with release candidates

tool ( golang.org/x/tools/cmd/stringer golang.org/x/tools/cmd/toolstash ) Also, I would think you don't want to specify paths here ( stringer toolstash ) would be sufficient. I have a particular use for this feature you are talking about because I have a number of

Re: [go-nuts] Re: Working with release candidates

Wow. This syntax is amazing! This would be really helpful. However, that is not what I was talking about. I see go 1.22 toolchain go1.23.4 The above syntax is much worse than what you posted below. In either case, can you please put this in a new file "go.tool" perhaps? That would be fantastic

Re: [go-nuts] Re: Working with release candidates

Could you file an issue about this with reproduction steps? My attempt to reproduce this works fine. go.mod ``` module example.com go 1.24rc1 tool ( golang.org/x/tools/cmd/stringer golang.org/x/tools/cmd/toolstash ) require ( golang.org/x/mod v0.22.0 // indirect

Re: [go-nuts] Re: Working with release candidates

OK, thank you! I will say I don't understand the thought process or improvement this is adding. I guess I have to change my docs? This seems not ideal. For the purposes of explaining to new users how to do things: go build go.wit.com/apps/helloworld@latest was pretty simple. Now I have to actua

Re: [go-nuts] Re: VCS Stamping - How To Use It? How to debug failures?

It appears this issue was previously reported: https://github.com/golang/go/issues/53532 On Monday, May 13, 2024 at 1:03:22 PM UTC-4 Adam Kaplan wrote: > I forgot to add one more detail - the go-toolset image defaults to running > as user "default" (UID 1001). > > Adding `USER root` right after

Re: [go-nuts] Re: zero in the new unique package

On Thu, 28 Nov 2024 at 23:36, 'Константин Иванов' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hello. > > May be because all zero-size values have the same pointer: > https://go.dev/play/p/n0dKQFN2EpR > Because the values have no memory location. > I think that's *part* of the story:

Re: [go-nuts] Re: Why doesn't Go use Windows's time zone data for time.LoadLocation?

Hi Jason! Thanks, makes sense. Will On Fri, Nov 29, 2024 at 7:07 AM Jason E. Aten wrote: > Hi Will! > > For Windows, there is some context here > https://github.com/golang/go/issues/21881 > > I think the short answer is that Windows does time zones differently > enough that there would be subt

Re: [go-nuts] Re: The possibilty run go source code as real scripts

Thanks Brian. I've checked that, it probably what I want. I don't know how I missed it. Thanks again. On Sun, 24 Nov 2024 at 05:59, 'Brian Candler' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Have you looked at this? > > https://github.com/traefik/yaegi?tab=readme-ov-file#as-a-comma

Re: [go-nuts] Re: memory issues

Indeed, setting -wb=false is going to break ~every program. It is intended only to be used in some very specialized tests (that don't run the code in question). On Sunday, November 17, 2024 at 6:53:35 PM UTC-8 蔺林 wrote: > I'm debugging a similar issue, just out of curiosity why did you set the

Re: [go-nuts] Re: memory issues

I'm debugging a similar issue, just out of curiosity why did you set the gcflag ' -wb=false'? On Friday, 10 February 2023 at 15:24:45 UTC+8 Marcello H wrote: > You could actually make a stress test inside a main_test.go with a > benchmark for example, run that locally and see. > > It works over

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

There are a few options for post-processing, all within the set of supported Go APIs. One is to use the `-focus` flag of `go tool pprof` so it only displays samples that match a particular call stack. If the code to be profiled is in a single function, that might be all you need. Another is to set

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

On Wed, Nov 13, 2024, 5:31 AM Jason E. Aten wrote: > All good. I still think that the hack of blocking and restoring the > runtime's SIGPROF signal > handler might actually work though. It might not work. But if it does, it > is almost > exactly what you were looking for. > > Ian or others more

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

(On gopherslack, the #darkarts folks are performance oriented) On Wed, Nov 13, 2024 at 1:30 PM Jason E. Aten wrote: > All good. I still think that the hack of blocking and restoring the > runtime's SIGPROF signal > handler might actually work though. It might not work. But if it does, it >

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

All good. I still think that the hack of blocking and restoring the runtime's SIGPROF signal handler might actually work though. It might not work. But if it does, it is almost exactly what you were looking for. Ian or others more knowledgeable myself might be able to advise better if it _should_

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

On Wednesday 13 November 2024 at 12:02:12 UTC Jason E. Aten wrote: > I've tried but this unfortunately, the Start and Stop processes are too expensive and really require writing to a different file for every stop. The nature of the program means I need to do the Start/Stop process 60+ times per

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

> I've tried but this unfortunately, the Start and Stop processes are too expensive and really require writing to a different file for every stop. The nature of the program means I need to do the Start/Stop process 60+ times per second, so it would generate a lot of files and be very slow on top.

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

On Wednesday 13 November 2024 at 06:05:36 UTC scott beeker wrote: 2. **Start Profiling**: Use `pprof.StartCPUProfile(file)` to start profiling, where `file` is an `os.File` object to write the profile data. 3. **Restrict Profiling**: Place `pprof.StartCPUProfile()` before the code section you w

Re: [go-nuts] Re: runtime/pprof - pausing CPU profiling

create a runtime CPU profile but to restrict the profile to a specific part of the program. runtime/pprof - pausing CPU profiling To create a runtime CPU profile for a specific part of a Go program, you can use the `runtime/pprof` package. Here's how you can do it: 1. **Import the Package**: Add

Re: [go-nuts] Re: Issue updating pkg.go.dev

Upon more investigation, the issue was already reported in 2020: https://github.com/golang/go/issues/39748 but never fixed There is a workaround with Hugo to prevent minification from removing quotes. Add this to hugo conf file: minify: tdewolff: html: keepQuotes: true Le mardi 12

Re: [go-nuts] Re: Issue updating pkg.go.dev

Much thanks for finding the issue ! The site is generated by Hugo, I'll try to fix the template. Le mardi 12 novembre 2024 à 17:19:14 UTC+1, Sean Liao a écrit : > No, it;s a bug similar to https://github.com/prettier/prettier/issues/8210 > > `go` follows the redirects, but there are several el

Re: [go-nuts] Re: Issue updating pkg.go.dev

No, it;s a bug similar to https://github.com/prettier/prettier/issues/8210 `go` follows the redirects, but there are several elements in your html that cause parsing issues (unquoted attribute values containing `/`). > > > > > > See https://go.dev/play/p/XOe6Z1czYWe go parser https://go.g

Re: [go-nuts] Re: Equivalent of DLL_PROCESS_ATTACH in Go

I never needed to do CreateThread(), so I doubt it is needed? I would add printf debugging statements to see when things are happening. Since Windows processes do not normally have the concept of stdout however, you do have to write them to a file instead of "the console", which is not there by d

Re: [go-nuts] Re: no direct write to a complex types components?

OK, i have it, apologies.. i was benching the complex path with an extra dereference and with such a tight loop it makes so much more difference than i thought was possible. now all makes sense. thanks. On Sunday 10 November 2024 at 19:25:39 UTC Axel Wagner wrote: > On Mon, 11 Nov 2024 at 03

  1   2   3   4   5   6   7   8   9   10   >