Re: [go-nuts] Re: Possible issue with go vet and/or gopls

ayground and locally (1.23.0) so I expect go vet to have the same output. -- Arnaud > peter > > On Sunday, August 25, 2024 at 5:30:25 PM UTC-4 Arnaud Delobelle wrote: > >> Hi Peter, >> >> Thanks for mentioning gotypesalias. Looking into that, I see that the >&g

Re: [go-nuts] Re: Possible issue with go vet and/or gopls

rnaud > peter > > On Sunday, August 25, 2024 at 5:30:25 PM UTC-4 Arnaud Delobelle wrote: > >> Hi Peter, >> >> Thanks for mentioning gotypesalias. Looking into that, I see that the >> go1.23 release notes mention that: >> >> By default, go/type

Re: [go-nuts] Re: Possible issue with go vet and/or gopls

o1.23 run alias.go && GODEBUG=gotypesalias=1 go1.23 > vet alias.go > go version go1.23.0 linux/amd64 > b = {X:0xc141c0 Y:0xc141d0} > $ > > peter > > On Saturday, August 24, 2024 at 5:37:20 PM UTC-4 Arnaud Delobelle wrote: > >> Hi all >> >> I

[go-nuts] Possible issue with go vet and/or gopls

Hi all I ran into this error with generic types. Here is the sample program below, which is my best effort to boil it down to its simplest expression. I can build and run the program fine with go 1.23.0. However, on line 15 vscode reports the error I put in the comment on that line. I do not kn

Re: [go-nuts] Re: Optional dependencies in module

On Tue, 8 Feb 2022 at 20:55, Manlio Perillo wrote: > Note that a single repository can have multiple modules, so you can make > cmd/golua-repls a separate module, adding github.com/arnodel/golua as a > dependency. > See https://go.dev/ref/mod#vcs-version. That is good to know! My question was

[go-nuts] Optional dependencies in module

very good approach either. And these are the only other approaches I can think of. Thanks in advance, Arnaud Delobelle -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from i

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

Nice! Arnaud On Tue, 7 Sep 2021, 18:02 Keith Randall, wrote: > Sounds good. CL up for review at > https://go-review.googlesource.com/c/go/+/347917 > > On Mon, Sep 6, 2021 at 7:30 PM Arnaud Delobelle wrote: > >> If the growing function is currently >> >> f(x)

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

If the growing function is currently f(x) = 2x for x < 1024 f(x) = x + x/4 otherwise (Which I haven't checked), couldn't a simple way be to use e.g. f(x) = 2xfor x < 1024 f(x) = x + x/4 + 768 otherwise Then f(1023) = 2046 f(1024) = 2048 So the function is monotonic

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

On Sun, 5 Sep 2021, 14:59 jake...@gmail.com, wrote: [...] > In the example given (https://play.golang.org/p/RJbEkmFsPKM > ), the capacities *are *"monotonically > increasing", as no number in the second column is smaller than the one > before it. > Nitpick

Re: [go-nuts] Re: WASM Performance

Hi Stephen, I haven't really looked at your code in detail but one obvious difference between your version and the original is the rendering code. Are you certain that the slowness is not confined to your rendering code (I have no reason to believe it is btw)? Here is a suggestion. I have had a

Re: [go-nuts] Contrary to popular opinion...

E.g. compare a = 1 b = 2 And a = 1 b = 2 They do no mean the same in Go. Arnaud On Sun, 28 Feb 2021, 08:05 'Dan Kortschak' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > On Sun, 2021-02-28 at 08:40 +0100, Jan Mercl wrote: > > Actually Go has that problem as well, just

Re: [go-nuts] type checking custom interface{} is not working as expected

You need you Json type to be a concrete type, e.g. (if the underlying type is a string) type Json string Then users can try to assert that what they get is of concrete type Json Cheers, Arnaud On Tue, 16 Feb 2021, 08:20 Santhosh Kumar T, wrote: > I am not using either json.Marshaler or json.

Re: [go-nuts] Error handling

I do sometimes do something similar, but without the check() function. The exit points are explicit, it is guaranteed that errors will be wrapped. func do(name string) (err error) { defer PWrapf(&err, "do(%s)", name) s, err := works(name); if err != nil { r

Re: [go-nuts] Possible Go 2 proposal for built-in Remove method for Slices.

On Sat, 6 Feb 2021 at 11:25, Martin Schnabel wrote: > > > > On 06.02.21 03:32, Wojciech S. Czarnecki wrote: > > Dnia 2021-02-04, o godz. 00:30:57 > > Selahaddin Harmankaya napisał(a): > > > >> There are obviously more things to consider > > > > Slice is not an array, it is a _view_into_ an array.

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

Hello FWIW I had a go at imagining a way to make a variant of your idea (package-level parametrisation) work. At the time my principal worry was contracts and I was keen to use interfaces instead to express parametric constraints: https://arnodel.github.io/marooned/go/generics/2020/06/06/go-spec2

Re: [go-nuts] Runtime cost of type assertions

x27; reflect.Value possibly created >> // via a reflect.MakeFunc. >> func (bldr *TypeBuilder) AddMethod(name string, fct reflect.Value) { ... } >> >> // Build seals the type and returns the finalized named type. >> func (bldr *TypeBuilder) Build() reflect.Type { ..

Re: [go-nuts] Runtime cost of type assertions

On Tuesday, 29 December 2020 at 16:25:41 UTC axel.wa...@googlemail.com wrote: > On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle wrote: > >> Question 1: I *think* that the compiler has all the information necessary >> to implement type assertion to the Cont interface as I h

Re: [go-nuts] Runtime cost of type assertions

On Tuesday, 29 December 2020 at 16:25:41 UTC axel.wa...@googlemail.com wrote: > On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle wrote: > >> Question 1: I *think* that the compiler has all the information necessary >> to implement type assertion to the Cont interface as I h

[go-nuts] Runtime cost of type assertions

Hi there! Looking at performance bottlenecks for my implementation of Lua in Go ([1]), I found that type assertions can have a significant cost, which feels unnecessary to me. I couldn't explain it without quite a lot of context, which makes my post quite long - sorry about that! I have a Val

Re: [go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

> improves performance by avoiding the need for reallocation. > > On Sun, Dec 27, 2020 at 4:23 AM Arnaud Delobelle wrote: > >> In my opinion, the issue is that there are two ways to express (almost) >> the same thing and that in itself creates friction in the language. >

Re: [go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

In my opinion, the issue is that there are two ways to express (almost) the same thing and that in itself creates friction in the language. There may be a valid reason to choose one version over the other, but every time it will be necessary to review the pros and cons of each alternative. If we

Re: [go-nuts] Obtaining an efficient hash for Go values

20 at 4:08 PM Arnaud Delobelle wrote: > > > The order is undefined but stable (provided you don't insert new > values), and accessible via the `next` function. Here is an example: > > Quoting from the provided link: > > """" > next (table [, index])

Re: [go-nuts] Obtaining an efficient hash for Go values

On Thursday, 24 December 2020 at 14:31:22 UTC Jan Mercl wrote: > On Thu, Dec 24, 2020 at 3:12 PM Arnaud Delobelle > wrote: > > That's interesting, thanks. Although I don't think it fits my use case > because I need something stronger than an iterator: a function th

Re: [go-nuts] Obtaining an efficient hash for Go values

4 December 2020 at 10:45:30 UTC axel.wa...@googlemail.com wrote: > On Thu, Dec 24, 2020 at 11:19 AM Arnaud Delobelle > wrote: > >> Does that sound like a sensible approach? I.e. is it safe enough to use >> the go:linkname directive, and do those seem like the right functio

Re: [go-nuts] Obtaining an efficient hash for Go values

a reflect equivalent that it provided by > https://golang.org/pkg/reflect/#MapIter. > > Dan > > On Thu, 2020-12-24 at 02:18 -0800, Arnaud Delobelle wrote: > > Hi there! > > > > In my continued efforts to improve the performance of my Go Lua > > implement

[go-nuts] Obtaining an efficient hash for Go values

Hi there! In my continued efforts to improve the performance of my Go Lua implementation [1], I have reached a bottleneck which causes me a quandary. Lua has a data structure which is called 'table', which is essentially a hashmap. So far I have implemented it as a Go map, which works OK. Ho

[go-nuts] Re: Interfaces holding integers and memory allocations

gt; iface interface{} >> } >> >> That significantly decreased memory management pressure on the program >> for many workloads, without having to manage a pool of say integer values. >> It also had the consequence of speeding up many arithmetic operations.

[go-nuts] Re: Interfaces holding integers and memory allocations

On Wednesday, 16 December 2020 at 11:15:32 UTC Arnaud Delobelle wrote: > Ah interesting, I guess that could mean I would need to switch to using > reflect.Value as the "value" type in the Lua runtime. I am unclear about > the performance consequences, but I guess I could

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

mit/60745c3503ba3d99297816f5c7b5364a08ec47ab >> >> -Ben >> >> On Monday, December 21, 2020 at 12:27:43 AM UTC+13 arn...@gmail.com >> wrote: >> >>> Ah, that is it, thank you! >>> >>> On Sunday, 20 December 2020 at 11:06:05 UTC Jan Mercl wro

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

gave me a 10x speedup. > https://github.com/benhoyt/goawk/commit/60745c3503ba3d99297816f5c7b5364a08ec47ab > > -Ben > > On Monday, December 21, 2020 at 12:27:43 AM UTC+13 arn...@gmail.com wrote: > >> Ah, that is it, thank you! >> >> On Sunday, 20 December 2020

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

Ah, that is it, thank you! On Sunday, 20 December 2020 at 11:06:05 UTC Jan Mercl wrote: > On Sun, Dec 20, 2020 at 11:53 AM Arnaud Delobelle > wrote: > > > TLDR; a simple test program appears to show that Go's (*os.File).Write > is 10x slower than C's fputs (on Ma

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

is it so? Is there something that I can do to overcome this performance penalty? Any insights would be appreciated. FWIW, I am running these on MacOS Catalina $ uname -v Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 (sorry I haven't got eas

[go-nuts] Re: Interfaces holding integers and memory allocations

func int64IfaceToInt64Pointer(v interface{}) *int64 { >>> // returns the pointer that v holds >>> } >>> >>> then I would be able to "pool" the allocations as follows: >>> >>> func NewIntValue(n int64) Value { >

Re: [go-nuts] Re: Interfaces holding integers and memory allocations

(sorry about the code formatting gone wrong, I replied in gmail it it seems to have removed all indentation!) On Wednesday, 16 December 2020 at 10:15:07 UTC Arnaud Delobelle wrote: > Hi Ben, that's an interesting idea. I considered it at the start but > didn't go for it in

Re: [go-nuts] Re: Interfaces holding integers and memory allocations

gt; return Int64PointerToint64Iface(p) >> } >> >> func ReleaseIntValue(v Value) { >> addToPool(Int64IPointerFromInt64Iface(v)) >> } >> >> func getFromPool() *int64 { >> // returns nil if there is no availab

[go-nuts] Interfaces holding integers and memory allocations

ten me? Or even better, would there be a different way of modelling Lua values that would allow good Go interoperability and allow controlling heap allocations? If you got to this point, thank you for reading! Arnaud Delobelle [1] https://github.com/arnodel/golua -- You received this

Re: [go-nuts] Go Generics using interfaces - alternative take

rics/2020/06/21/go-against-contracts.html Kind regards, Arnaud Delobelle On Wednesday, 17 June 2020 at 06:10:08 UTC+1 Ian Lance Taylor wrote: > On Tue, Jun 16, 2020 at 1:54 PM Arnaud Delobelle > wrote: > > > > I noticed today the blog post about the revised Generics proposal. W

[go-nuts] Go Generics using interfaces - alternative take

it was meant to be an exploration of a possible approach). Kinds regards, Arnaud Delobelle -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email