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

[go-nuts] Optional dependencies in module

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 it, sen

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

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. >

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

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

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(, "do(%s)", name) s, err := works(name); if err != nil {

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

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:

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

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

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

mance 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. >> >> The

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 that g

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

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 functions to >

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

t 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 > > implementation [1], I have re

[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.

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

ce{} >> } >> >> 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. >> Thanks all fo

[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 c

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

816f5c7b5364a08ec47ab >> >> -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 wrote: >>> >>>> O

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

//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 at 11:06:05 UTC Jan Mercl wrote: &g

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 MacOS). >

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

ere 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 easy access to a Linux

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

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

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 the end (I

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

>> >> func ReleaseIntValue(v Value) { >> addToPool(Int64IPointerFromInt64Iface(v)) >> } >> >> func getFromPool() *int64 { >> // returns nil if there is no available pointer in the pool >> } >> >> func

[go-nuts] Interfaces holding integers and memory allocations

e? 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 messa

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

s.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. What > got me excited is this ex

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

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 to