Re: [go-nuts] Non pointer constraint for generic func

Ah yes, that does help, thanks. I've read that essay in the past, but it was a good re-read! On Thu, 14 Nov 2024 at 11:24, Ian Lance Taylor wrote: > On Wed, Nov 13, 2024 at 1:28 PM ben...@gmail.com > wrote: > > > > > Personally I mostly think that is OK. One of the guidelines that Go > > > foll

Re: [go-nuts] Re: any Go based supervisor alternative?

I presume you're referring to API access? I wasn't around when the initial API and access control stuff was designed (it's inherited from snapd), but here's my understanding of how it works. The bulk of the API is exposed using HTTP-over-unix-socket, so is only accessible if you have permission to

Re: [go-nuts] Re: New site go.dev is awful

Thanks for that, Axel. Good to know they're aware of it and working on a solution (of sorts). On Thu, Nov 25, 2021 at 8:57 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > https://github.com/golang/go/issues/49765 > https://go-review.googlesource.com/c/website/+/366976/ >

Re: [go-nuts] Anyway to wrap or tweak a test file before running go test?

Agreed. I've always found the "just add an argument with the right name" fixture feature too magical and implicit (read: confusing). I much prefer Go's explicitness here, even if slightly more verbose. IMO even in Python that kind of magic is usually frowned upon. -Ben On Thu, Nov 4, 2021 at 9:2

Re: [go-nuts] Re: How to negotiate authentication over HTTP ? (the Go way)

should not attempt to > // handle higher-level protocol details such as redirects, > // authentication, or cookies. > // RoundTrip should not modify the request > > > > > *On 27/10/2021 02:09, Ben Hoyt wrote:* > *Oh, I see. An "ExecuteHTTP" function seems reaso

Re: [go-nuts] Source links on cs.opensource.google are slow (links for stdlib on pkg.go.dev)

> Every site you access probably uses Google analytics or something similar. > > It is often used to understand usage patterns, site design, etc. > Yeah, fair enough. I shouldn't have side-tracked my own discussion. :-) -Ben -- You received this message because you are subscribed to the Google

Re: [go-nuts] Source links on cs.opensource.google are slow (links for stdlib on pkg.go.dev)

> I'm in Santa Clara, CA. Just a handful of miles away from Google headquarters. > Your two links exhibit orders of magnitude differences in load time for me. I presume you mean orders of magnitude, with cs.opensource being slower? What are the actual figures you get? Just for the record, for my

Re: [go-nuts] Leading dash invalid in test filename inside module

t module directly from vcs and not to > contact GOSUMDB for it. > > On Wed, Aug 18, 2021 at 2:57 PM Ben Hoyt wrote: > >> (I wasn't quite sure whether golang-nuts or golang-dev was the best place >> for this -- sending to golang-nuts for now.) >> >> I just rel

[go-nuts] Leading dash invalid in test filename inside module

(I wasn't quite sure whether golang-nuts or golang-dev was the best place for this -- sending to golang-nuts for now.) I just released a new version of GoAWK (v1.8.0) using Go version 1.17, and then tested installing it using "go install". However, go install complains with the following: $ go in

Re: [go-nuts] How are interfaces marked by the GC?

Interesting, thanks for the explanation! On Thu, Jul 15, 2021 at 12:23 PM Ian Lance Taylor wrote: > On Wed, Jul 14, 2021 at 2:11 PM ben...@gmail.com > wrote: > > > > Out of interest, why was that changed? Was the optimization not worth > it? Did it just require too much special handling so the

Re: [go-nuts] Re: A message from the CoC committee

Fair response - pragmatic and helpful. Thanks, Ian. -Ben On Thu, Mar 25, 2021 at 8:34 AM Ian Lance Taylor wrote: > On Wed, Mar 24, 2021 at 12:19 PM ben...@gmail.com > wrote: > > > > > permanent bans were given to multiple individuals, with no possibility > for appeal > > > > I don't disagree wi

Re: [go-nuts] Performance issue with os.File.Write

> @Ben interesting, I did something similar and also ended up with a 64KB buffer (seemed like the default of 4KB didn't work very well in my context). How did you decide of the buffer size? I forget how I ended up with 64KB. I think I was doing performance testing and a buffer larger than the 4KB

Re: [go-nuts] "Interfaces" with type lists are a strange beast

> Yes, I think that the ability to write generics using operators is not > optional. As I've said before, there are some functions that must be > possible to write using any plausible generics mechanism. One of them > is the Min function that returns the smaller of two values of some > ordered ty

Re: [go-nuts] "Interfaces" with type lists are a strange beast

Thanks for the thoughtful response. > I'm still strongly in favor of not having it. In particular, there is a large > section of conceptual overlap between interfaces and constrained > type-parameters. And at least as far as function parameters go, an interface > parameter can always be re-writ

[go-nuts] "Interfaces" with type lists are a strange beast

Per Ian's suggestion on the other thread I started (https://groups.google.com/g/golang-nuts/c/u9jqLPhEYO0/m/tnqezci8AwAJ), I'm breaking out this topic into a separate thread: It seems strange to me that interfaces with type lists are really a different beast than regular interfaces, and aren't eve

Re: [go-nuts] A few thoughts on type parameters

> That is an experiment. We don't seem to need the type keyword for > generic functions. But we do need it for generic types, to avoid > confusion with an array type (but only if there is exactly one type > parameter with no constraint). I'm not personally a big fan of > optional syntax, so we w

[go-nuts] A few thoughts on type parameters

I've played with generics a bit more, including the new square brackets syntax. A few notes (some of the threads have been long, so apologies if I'm doubling up): 1) I definitely prefer the square brackets syntax. It makes it clear where you're using type parameters, and IMO it sets them off much

Re: [go-nuts] Generics: type-list vs method-based constraints -- not orthogonal?

Thanks. You're right about the Map with the comparison function being more flexible. That helps allay my concerns for ordered data structures. I guess what I'm worried about is for someone writing a "slices" library and wants to include a function like slices.Smallest(). Do they give it an Ordered

[go-nuts] Re: func before function

> > Why is it necessary to write func in go before declaring a function; if in > C, when parsing a function, there is no such need? > Why "func sum(a, b int) int {...}" can't be "sum(a, b int) int {...}" > See discussion at very similar thread: https://groups.google.com/forum/#!topic/golang-nut

Re: [go-nuts] keyword func

Yeah, I agree with Marvin. "func" is also needed for anonymous functions and defining function types. This would be quite weird (and probably not easily parseable): add := (a, b int) int { return a+b } type adder (a, b int) int Most importantly for me, explicit syntax for this allows me

[go-nuts] Re: [ANN] grobotstxt - a Go port of Google's robots.txt parser and matcher

This looks really nice! I was looking for something like this recently, but ended up using https://github.com/temoto/robotstxt. However, something that's closer to the Google version might well have made me choose that. A couple of comments: 1) I always love packages that only depend on the Go

[go-nuts] Re: A proof-of-concept implementation of my generics proposal for Go

I really, really like this. I liked the original proposal, but using the "type" keyword seems very natural. And I like the 80/20 constraints thing with eq/ord/num. Good work -- I hope this gets turned into an official proposal and debated. -Ben On Thursday, June 27, 2019 at 10:29:03 AM UTC-4,

[go-nuts] Re: Adding a timeout to a script interpreter (without leaking a goroutine)

> > Using `context` is the recommended mechanism to pass timeouts and other > information to functions, > so it's probably already the "best" way, at least from the design point of > view. > > I recommend benchmarking it before searching for other solutions: > if it turns out to cause excessive

[go-nuts] Adding a timeout to a script interpreter (without leaking a goroutine)

I'm looking at adding a timeout option to my GoAWK script interpreter using either a timeout or a context value. This is mainly for safety when using it in an embedded context, for example to avoid someone doing a denial-of-service attack by submitting a `BEGIN { while (1); }` script. This seems s

[go-nuts] Re: Quirk with width of format string like %#05x

Thanks, that's a very helpful link! On Thursday, January 3, 2019 at 9:36:10 AM UTC-5, Martin Möhrmann wrote: > > To keep backwards compatibility with go1 changing fmt to count in the 0x > for the padding was discussed and abandoned in > https://go-review.googlesource.com/c/go/+/22136/. > -- Yo

[go-nuts] Quirk with width of format string like %#05x

Hi folks, I noticed that the following format string handles the width in an unexpected way (the "gosnip" program just runs snippets of Go code): $ gosnip 'fmt.Printf("%#05x\n", 45)' 0x0002d I would have expected the width (5) to include the "0x", but it's prepended to the string. In contrast, w

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

e this helps for you to form an opinion. > > Best! > > > *Leonel Quinteros* > Director of Technology > Global Brigades <https://www.globalbrigades.org/> > > > > El lun., 3 de dic. de 2018 a la(s) 20:54, Ben Hoyt (benh...@gmail.com) > escribió: > >>

[go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

Ah yes, that's a nice way -- thanks. Still has the issue that it's fairly easy to forget ... oh well. -Ben On Monday, December 3, 2018 at 7:17:21 PM UTC-5, Jesse Rittner wrote: > > In this situation, we normally use named return variables. That way we can > just check if we are returning with a

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

Just like you do with the insert and avoiding the *:=* operand > > Let me know if that works. > > > Best! > Leonel > > > El lunes, 3 de diciembre de 2018, 18:53:30 (UTC-3), Ben Hoyt escribió: >> >> Hi folks, >> >> We found some subtle bugs in

Re: [go-nuts] Best way to handle database transactions? (commit, or rollback on error)

les defined error here? > > On Dec 3, 2018, at 3:53 PM, Ben Hoyt wrote: > > Hi folks, > > We found some subtle bugs in our db transaction code for handling > commits/rollbacks. Here's the pattern we were using (not real, but shows > the issue): > > func DoTwoThing

[go-nuts] Best way to handle database transactions? (commit, or rollback on error)

Hi folks, We found some subtle bugs in our db transaction code for handling commits/rollbacks. Here's the pattern we were using (not real, but shows the issue): func DoTwoThings() error { tx, err := db.Begin() if err != nil { return err } // commit or rollback the transa

Re: [go-nuts] GoAWK: an AWK interpreter written in Go

> I wonder if it makes sense, to expose more of the interpreter to go. > E.g.: register a user function or add an action written in go. > I had thought about this before, but your comment made me want to try it. It wasn't actually that hard, so I've added backwards-compatible support for this now

Re: [go-nuts] gosnip: run small snippets of Go code from the command line

: > Instead of writing your own logic to resolve missing imports, could you > run the goimports tool? It will automatically select imports from the > standard library and GOPATH. > > S > > On Sat, Nov 24, 2018 at 5:06 PM Ben Hoyt wrote: > >> I just finished a little tool c

Re: [go-nuts] gosnip: run small snippets of Go code from the command line

> > I've actually been using gomacro for this (testing a quick bit of syntax). > I have to import the std libs that I need (auto import would be nice if > it's not ambiguous), but it has nice output evaluation and state. > > https://github.com/cosmos72/gomacro > Ha, nice! You know, I think I remem

[go-nuts] gosnip: run small snippets of Go code from the command line

I just finished a little tool called "gosnip" that allows you to run little snippets of Go code from the command line: https://github.com/benhoyt/gosnip To use it, just type something like: $ gosnip 'fmt.Println("Hello world")' Hello world gosnip automatically adds (standard library) im

Re: [go-nuts] GoAWK: an AWK interpreter written in Go

> > probably this is better tool for the >> case >> > > - please don't just post a link, but include descriptions. > - please justify your claim "better" - a specific log file parser is > better than general-purpose awk scripts? In what way? > - please don't hija

Re: [go-nuts] GoAWK: an AWK interpreter written in Go

> Hope there are future plans to extend it so that, > - people can define user function in go and use it in goawk > > handling, > as kty... has pointed out. > I toyed

Re: [go-nuts] Re: GoAWK: an AWK interpreter written in Go

u, Nov 22, 2018 at 11:24 PM Tong Sun wrote: > > > On Tuesday, August 28, 2018 at 9:06:22 AM UTC-4, Ben Hoyt wrote: >> >> Once you have some proper benchmarks, it might be fun to compare GoAWK's >>> performance to that of my awk package <https://github.com/spakin/

Re: [go-nuts] GoAWK: an AWK interpreter written in Go

building > something non-trivial and making it both correct and fast. Nice work. > > I'm sure you knew already, but Peter Weinberger (the W in AWK) is on the > Go team at Google. > > > > On 17 November 2018 at 12:44, Ben Hoyt wrote: > >> I've &quo

Re: [go-nuts] GoAWK: an AWK interpreter written in Go

allocations in many instances Here's a write-up about GoAWK for those that are interested: https://benhoyt.com/writings/goawk/ It's pretty much a toy project, not being used for anything real, but it seems to be in a good shape. Feedback welcome! -Ben On Fri, Aug 24, 2018 at 5:13 PM Ben

[go-nuts] Re: Announcing pytogo. a crude but surprisingly effective Python to Go translator

How well does pytogo work on the pytogo source? :-) On Monday, October 1, 2018 at 6:00:17 AM UTC-4, Eric Raymond wrote: > > I've fixed the bug in handling of multiline strings. > > 1.1 also translate commion for-loop patterns to Go, including traversing > lists and dictionaries and doing enumerat

Re: [go-nuts] Re: GoAWK: an AWK interpreter written in Go

> > Once you have some proper benchmarks, it might be fun to compare GoAWK's > performance to that of my awk package . > Nice -- will do! I don't know how much performance difference this makes in practice, but my > value struct (also in a value.go file) lazily conv

[go-nuts] GoAWK: an AWK interpreter written in Go

I recently wrote an AWK interpreter in Go: https://github.com/benhoyt/goawk It's a pretty simple implementation: hand-rolled lexer, recursive-descent parser, and tree-walk interpreter. It's pretty complete according to the POSIX spec, and it passes the AWK ("one true awk") test suite as well as

Re: [go-nuts] Re: Learning Go: suggestions for code review?

Yeah, I copied the go/token style there. However, thanks Nigel -- I didn't realize you could do "renaming imports", that's nice. -Ben On Thu, Dec 14, 2017 at 4:35 AM, Jan Mercl <0xj...@gmail.com> wrote: > On Thu, Dec 14, 2017 at 6:27 AM Nigel Tao wrote: > > > As per https://golang.org/doc/effect

[go-nuts] Re: Learning Go: suggestions for code review?

> Don't do relative imports (littlelang/tokenizer) or . littlelang/tokenizer > . Unless you want to run into corner cases with tools not knowing where > code is defined or if you want to confuse other developers. > > Using the full path makes it very clear where the code is, yes, if you > move

[go-nuts] Re: Learning Go: suggestions for code review?

Thanks! I've used the full github path (github.com/benhoyt/littlelang/tokenizer) > for my subpackages when importing them but the tradeoffs for your approach (. > "littlelang/tokenizer") isn't clear to me. > Aha, thanks, I've finally realized why using full import paths (import "github.com/ben

[go-nuts] Learning Go: suggestions for code review?

Hi folks, I've recently been learning Go on the side, so haven't had work colleagues to discuss best practices with. To speed up the learning process, I'm wondering if anyone would like to review the Go code in my side project (a toy language, kind of a cross between JavaScript and Python with

Re: [go-nuts] Re: Announcing: Skylark in Go

On Tue, Nov 7, 2017 at 3:16 PM, Alan Donovan wrote: > On 7 November 2017 at 15:06, Ben Hoyt wrote: > >> >> 2x as fast as CPython sounds pretty good to me -- nice! >>>> >>> > No, CPython is 2x as fast as Skylark in Go. It's implemented in C, so it

Re: [go-nuts] Re: Announcing: Skylark in Go

> On Thursday, November 2, 2017 at 9:42:27 PM UTC-4, Ben Hoyt wrote: >>> >>> I'm very curious how the performance of Skylark in Go compares to >>> Skylark in Java (and CPython 3.6 for that matter) -- any benchmarks on that? >>> >> > I don't

Re: [go-nuts] Rationale in docs on why you need to use the result of append()

> > I don't follow. It had been shown, that the result of append is actually > not needed/can be constructed by other means - except in the case where the > backing array gets reallocated. Then you can't get away without it. > Hmmm, it feels like we're talking past each other. Of course you can ig

Re: [go-nuts] Rationale in docs on why you need to use the result of append()

run-time data structure holding the pointer, length, and capacity) is passed by value" makes good sense to me. The other two statements seem confusing. Does that make sense? -Ben On Sat, Nov 4, 2017 at 9:24 AM, Jan Mercl <0xj...@gmail.com> wrote: > On Sat, Nov 4, 2017 at 1:53 PM Be

[go-nuts] Rationale in docs on why you need to use the result of append()

Hi folks, It seems to me that the reasons given for why you need to use the return value of append() are confusing and not quite right. For example, at https://blog.golang.org/slices#TOC_9. Rob Pike says: "In this case it's especially important to return the slice, since when it reallocates th

[go-nuts] Re: Announcing: Skylark in Go

That looks really neat. I will dive into the code! I'm very curious how the performance of Skylark in Go compares to Skylark in Java (and CPython 3.6 for that matter) -- any benchmarks on that? -Ben On Monday, October 2, 2017 at 12:39:43 PM UTC-4, Alan Donovan wrote: > > I'm pleased to announ