Re: [go-nuts] [generics] type constraint for structs

. On Thursday, April 4, 2024 at 6:53:27 AM UTC+2 Axel Wagner wrote: > How does `interface{ AsElement() *Element }` not do exactly what you want? > > On Thu, Apr 4, 2024 at 4:14 AM atd...@gmail.com wrote: > >> Might have come across this today as I was trying to simplify some cod

Re: [go-nuts] [generics] type constraint for structs

Ah, I forgot to use reflection for instance... That might be doable. On Thursday, April 4, 2024 at 4:13:35 AM UTC+2 atd...@gmail.com wrote: > Might have come across this today as I was trying to simplify some code. > > Basically, I have a base type called *Element that has a method &g

Re: [go-nuts] [generics] type constraint for structs

Might have come across this today as I was trying to simplify some code. Basically, I have a base type called *Element that has a method AsElement() *Element that returns itself. And this base element is used as a base for many others, for isntance: type Div struct{ *Element} type Span

[go-nuts] Re: How to abstract away a method implementation and replace it?

, June 18, 2023 at 1:38:33 PM UTC+2 atd...@gmail.com wrote: > I have exposed the following problem in a bit more details here: > > https://gist.github.com/atdiar/6568964896231bfde734f6bddf9ff46c > > Basically, I need to modify the implementation of the method of a given &

[go-nuts] Re: How to abstract away a method implementation and replace it?

Suddenly thinking that I can actually just use type parameters but the type argument can also created lazily by being instantiations of parametred types.. Might actually be sufficient to have value scoped type instantiations. On Sunday, June 18, 2023 at 1:38:33 PM UTC+2 atd...@gmail.com wrote

[go-nuts] How to abstract away a method implementation and replace it?

I have exposed the following problem in a bit more details here: https://gist.github.com/atdiar/6568964896231bfde734f6bddf9ff46c Basically, I need to modify the implementation of the method of a given type depending on the encasing scope of the value its called on. (and not just the value

Re: [go-nuts] Do I need a reentrant locks?

. On Wednesday, July 6, 2022 at 3:33:50 PM UTC+2 atd...@gmail.com wrote: > Well, in my case, only the writing goroutine should be able to have access > to the datastructure (to keep the invariants). So I think a mutex should do > the trick. > Indeed, it looks like transactions or a reim

Re: [go-nuts] syscall/js: strange deadlock caused by wasm event handling callback (runtime bug?)

Filed an issue with a reproducer ; https://github.com/golang/go/issues/54328 On Sunday, August 7, 2022 at 12:08:33 AM UTC+2 atd...@gmail.com wrote: > Doesn't seem that this is a known issue. I will try and write a short > reproducer and file an issue. > > On Fri, Aug 5, 2022,

[go-nuts] syscall/js: strange deadlock caused by wasm event handling callback (runtime bug?)

Hi, I have a little concurrency problem. Seems that my Go-wasm-defined event handlers run concurrently instead of synchronously. Basically, the event handler is called by runtime.handleEvent which calls into the syscall/js defined version of it Link to source

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

this if/when multithreaded support is introduced. On Monday, July 4, 2022 at 3:24:01 PM UTC+2 atd...@gmail.com wrote: > ok so, thinking about it again, I guess that here, there is no preemption > point within functions. So when a wrapped function returns, the event loop >

Re: [go-nuts] Do I need a reentrant locks?

Well, in my case, only the writing goroutine should be able to have access to the datastructure (to keep the invariants). So I think a mutex should do the trick. Indeed, it looks like transactions or a reimplementation of a UI thread/event loop. A concurrent hash=array mapped trie might

Re: [go-nuts] Re: Do I need a reentrant locks?

lock. > > https://go.dev/play/p/M1XuC8bxCxL > > > > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: > > > > > Hi, > > > > > > I have a tree datastructure where mutating some nodes *may *trigger a > > > mutation on so

[go-nuts] Re: Do I need a reentrant locks?

which assumes it's already running under the lock. > https://go.dev/play/p/M1XuC8bxCxL > > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: > >> Hi, >> >> I have a tree datastructure where mutating some nodes *may *trigger a >> mutation on som

[go-nuts] Do I need a reentrant locks?

Hi, I have a tree datastructure where mutating some nodes *may *trigger a mutation on some other tree nodes. This tree should be accessible by multiple goroutines but mutated by only one at a time. As such, I wanted to have a global lock on the tree such that mutatiing node methods should

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

able to multiplex goroutines on different threads (I don't think that is the case yet) since there is potentially simultaneous access by different goroutines. So concurrent access needs to be serialized in my case, I think. On Monday, July 4, 2022 at 4:27:04 AM UTC+2 atd...@gmail.com wrote

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

the use of the event loop would block? So how are goroutines scheduled here? Can goroutines be interleaved? How does it not block then if several goroutines have to interact with the event loop? Am I misunderstanding something? On Saturday, July 2, 2022 at 3:57:11 PM UTC+2 atd...@gmail.com wrote: &

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

:10 PM UTC+2 atd...@gmail.com wrote: > Hi, > > I just have a quick question. > I am using callbacks that run Go code to modify a Go-wasm datastructure. > These callbacks are essentially Wrapped Go Funcs called from js. > > Reading the docs, I've realized that each cal

[go-nuts] syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

Hi, I just have a quick question. I am using callbacks that run Go code to modify a Go-wasm datastructure. These callbacks are essentially Wrapped Go Funcs called from js. Reading the docs, I've realized that each callback runs in its own goroutine. Now, I'm wondering if I should protect access

[go-nuts] Re: Quick poll: Which of these declarative UI trees looks the most legible to you?

9, 2022 at 5:59:04 AM UTC+2 Henry wrote: > Alternatively, you may experiment using structs with exported fields. It > may be a bit less verbose. > > On Thursday, June 9, 2022 at 8:28:32 AM UTC+7 atd...@gmail.com wrote: > >> Hey, >> >> Yes, they all look kin

[go-nuts] Re: Quick poll: Which of these declarative UI trees looks the most legible to you?

Hey, Yes, they all look kind of similar because they all use function composition and are variations of the same tree, just not with the same level of expansion. I've made a new gist that shows more distinct approaches. https://gist.github.com/atdiar/725844d85d4b9835c58f7f834570ab69 Thanks

[go-nuts] Quick poll: Which of these declarative UI trees looks the most legible to you?

Hi, So I have a working implementation of a UI framework underway. I've ended up providing ways to define the UI tree in a declarative way. But to make sure it is legible, I have a gist with 3 examples of how the UI tree could be defined. (taken from an implementation of TODOMVC)

[go-nuts] Re: Functions vs Methods: explain reasoning behind STD

A short way to see it for me is to reason in terms of capabilities. What is an instance of a given type supposed to be able to do? (method) versus what am I able to do with or upon a given instance (function). It's not always clear though but it can help. On Thursday, June 2, 2022 at 4:38:37 PM

[go-nuts] Re: syscall/js: wasm perf question

at 8:51:43 PM UTC+2 atd...@gmail.com wrote: > Seems like it might be a slow handling of wasm in Chrome. Firefox is > almost twice as fast. There seems to be almost no overhead. > > On Tuesday, May 31, 2022 at 3:19:24 PM UTC+2 atd...@gmail.com wrote: > >> Hi, >> >>

[go-nuts] Re: syscall/js: wasm perf question

Seems like it might be a slow handling of wasm in Chrome. Firefox is almost twice as fast. There seems to be almost no overhead. On Tuesday, May 31, 2022 at 3:19:24 PM UTC+2 atd...@gmail.com wrote: > Hi, > > I am trying to optimize some wasm code that runs into the browser.

[go-nuts] syscall/js: wasm perf question

Hi, I am trying to optimize some wasm code that runs into the browser. So far, the performance is acceptable if not slightly faster than probably unoptimized js DOM manipulation (comparing my implementation of TODOMVC with the vanilla javascript one and react one) One issue I see is that

[go-nuts] Re: Issue: x/net/html Node and attributes constructor function

Like func NewNode(...) and func NewAttr(...) Also a SetAttr on Nodes On Monday, July 12, 2021 at 7:38:08 PM UTC+2 atd...@gmail.com wrote: > Just wondering if people would feel it worthy to have COnstructor > functions to create html.Nodes, attributes, and set attributes on > h

[go-nuts] Issue: x/net/html Node and attributes constructor function

Just wondering if people would feel it worthy to have COnstructor functions to create html.Nodes, attributes, and set attributes on html.Nodes. I'm writing some kind of metaframework targeting the web and mobile (think flutter for Go) and basically finished the web target via wasm. But I'd

Re: [go-nuts] Type parameters syntax... Can it be improved?

Nevermind, I forgot about function return values. Difficult to infer them without specifying them, isn'it? Sorry... should have thought better. On Wednesday, March 24, 2021 at 12:23:12 AM UTC+1 atd...@gmail.com wrote: > Mmmh, :/ depends. What is the type of IntMin for the compiler in y

Re: [go-nuts] Type parameters syntax... Can it be improved?

than those of types and interface types. Could make brackets redundant. On Tuesday, March 23, 2021 at 11:22:51 PM UTC+1 Ian Lance Taylor wrote: > On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com wrote: > > > > Since, we also know the type of v, It would

Re: [go-nuts] Type parameters syntax... Can it be improved?

something that resemble a type definition beforehand. A type parameter definition. On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote: > On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com wrote: > > > > Quick question... > > > > Why do we need brack

[go-nuts] Type parameters syntax... Can it be improved?

Quick question... Why do we need brackets to define a parametered function, struct etc...? Why not change Go kinds to accept either a type (would produce a regular, function, structs, etc) or a new type parameter object that would implement the constraints (would produce a generic function

[go-nuts] Re: encoding/html package to generate html markup programmatically

h 14, 2021 at 7:36:52 PM UTC-4 atd...@gmail.com wrote: > >> Hi, >> >> I am currently thinking about implementing SSR for a Go client-side >> framework. >> Not only that but I would like to be able to create static html from the >> same code I use to creat

Re: [go-nuts] No generic, part -2

I am in favor of the proposal but I think that accounting for popularity votes is not a good measure of things. A lot of people are at various stages of their technical journey in computer science and engineering and there has to be a weight given to the more technical opinions that is not

[go-nuts] encoding/html package to generate html markup programmatically

Hi, I am currently thinking about implementing SSR for a Go client-side framework. Not only that but I would like to be able to create static html from the same code I use to create dynamic wasm-based webapps. I was trying to find a package that would enable me to generate an html document

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

, February 4, 2021 at 2:54:09 AM UTC+1 atd...@gmail.com wrote: > Just coming back to this quickly, although it is unlikely to change > anything at this stage, but, re. a transform function, instead of using > parametric polymorphism, I think it is possible to do it with interface &g

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

ferent max functions, (just like we do these days anyway) mint.Max(2,3) mfloat.Max(2.0,3.0) No opinion on this. I don't think it would bother me but... Am I missing something? On Thursday, January 21, 2021 at 4:37:17 PM UTC+1 atd...@gmail.com wrote: > Looking briefly, seems interesting

[go-nuts] sycall/js : does it require build tags? if so whihc ones?

Hello, I'm using atom and am trying to import the syscall/js package. My issue is that I do not know which build constraints I should specify for the static analysers to process the code. I'm getting a message as such: js.go:7:3: build constraints exclude all Go files in

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

Jan 20, 2021 at 4:22 PM atd...@gmail.com wrote: > >> It' has probably been discussed somewhere but I am curious about what >> might have been the issues when considering an implementation of generics >> that would parameterized packages? >> >> > You can take a l

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

and both of which I have used in the > past in real code. > > On Thu, Jan 21, 2021 at 1:35 AM atd...@gmail.com wrote: > >> Oh, I know it does, as mentioned above. Typically to emulate matrices. >> >> My point was that it is still different from a linked list of linked

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

. In the end, I am sure you have more data points than I have, my questions have been mostly answered, I'll leave the rest in your care. Cheers, On Thursday, January 21, 2021 at 1:09:23 AM UTC+1 Ian Lance Taylor wrote: > On Wed, Jan 20, 2021 at 1:19 PM atd...@gmail.com wrote: > > > &

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

rovide enough value to justify their complexity. I feel that *if* we > introduce generics, we should make sure they actually pay for their cost. > I'd much rather have no generics at all, than a bad and useless > implementation of them. > > On Wed, Jan 20, 2021 at 10:19 PM atd...@gma

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

Wed, Jan 20, 2021 at 11:42 AM atd...@gmail.com > wrote: > > > > > > It didn't seem to me like proposal-killers enoguh so much so that they > might not have liked some of the design choices they entailed. > > > > The proble with the current running proposal is

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

quot; situation, if the Go team feels it is awkward, their opinion will > be what tips the scales. > > On Wed, Jan 20, 2021 at 7:09 PM atd...@gmail.com wrote: > >> Also, the distinction I see is that it would not be the same >> instantiation of the same package as much

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

al/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages > > On Wednesday, January 20, 2021 at 10:22:19 AM UTC-5 atd...@gmail.com > wrote: > >> Hello, >> >> It' has probably been discussed somewhere but I am curious about w

[go-nuts] Re: GODOC: how to create a reference to another definition in a comment?

ake a jump to the relevant part of the documentation for instance. Is there any facility already for this? On Saturday, January 16, 2021 at 2:20:33 PM UTC+1 atd...@gmail.com wrote: > Hello, > > Just wondering if there is a way to create references to other fields in > go comments. > If it

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

Hello, It' has probably been discussed somewhere but I am curious about what might have been the issues when considering an implementation of generics that would parameterized packages? The rationale being that usually, packages have a non-mutable interface for the user and are the ompilation

[go-nuts] GODOC: how to create a reference to another definition in a comment?

Hello, Just wondering if there is a way to create references to other fields in go comments. If it does not exist, wouldn't it be something valuable, for easier navigation in godoc and its new iteration? (I would assume that we would have to check comments for broken references on code change)

[go-nuts] I'd like to write a CSS StyleSheet Parser but...

Hello, I am currently in need of a css stylesheet parser to retrieve the CSSOM as a go datastructure. (probably in a map[*selector* string]map[*cssproperty* string]interface{}) The existing Go libraries that can be found online are a bit lacking in that respect, imho. But I also have never

[go-nuts] Quick question about calling Set-Cookie twice in a row

Hello, As I am writing some tests, I was wondering what should be the correct behavior when http.SetCookie is called twice with cookies of a same name but different values. For example, what should a user-agent see as the cookie value and hence, what should it return back to the server with

Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

Yes, the issue is twofold. Because everything is passed by "copy", it might feel safe to pass around structs with slice fields, especially and perhaps unknowingly as "interior fat pointers" in structs. But, one should remember that these objects are always shallow copies in the sense that

Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

On Saturday, October 26, 2019 at 9:47:39 PM UTC+2, Ian Lance Taylor wrote: > > On Sat, Oct 26, 2019 at 10:50 AM atd...@gmail.com > wrote: > > > > I get that we can do that but it's not strictly about slices operations > such as appending or copying. > > Of co

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

ith fields that are "snapshot" slices. On Saturday, October 26, 2019 at 7:49:50 PM UTC+2, atd...@gmail.com wrote: > > I get that we can do that but it's not strictly about slices operations > such as appending or copying. > Of course, we could copy slices all the time but then there

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

rld!") // n3 == 5, b == []byte("Hello") > > > On Saturday, October 26, 2019 at 3:02:37 PM UTC+2, atd...@gmail.com wrote: >> >> Hi, >> >> Thank you for the response. >> >> My issue is not really about append but can be illustrated by this : >>

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

ng habits that can prevent this, like use x = append(x, y) and > never x = append(y, x) Basically we only need a Go proverb bible mentioned > in one of Rob Pike's talks and we will be fine :) > > On Saturday, October 26, 2019 at 1:40:23 PM UTC+2, atd...@gmail.com wrote: >>

[go-nuts] Slices, backing array, goroutines, perhaps Considerations for Go2

Hello, I've just realized that slices were much more delicate to use than initially thought. The main issue is that when slices share the same backing array, it is too easy to inadvertently have an unprotected concurrent Read/Write if one is not careful. That can easily happen for a struct

Re: [go-nuts] CFG for a Go program

I concur. On Monday, November 28, 2016 at 4:35:13 AM UTC+1, Michael Jones wrote: > > Details of this would make a great Go Blog post… > > > > *From: *adonovan via golang-nuts > *Reply-To: * > *Date: *Sunday, November 27, 2016 at 6:07 PM > *To:

Re: [go-nuts] Why doens't function type support comparision but channel type does?

It highly depends on what you define a function. If it's in the mathematical sense, it won't work. A function, in practice, is a small embedded program (stored as a valur in the main program). It's not just the text (semantics). It's defined somewhere (in some package etc...) That's all those

[go-nuts] Re: Interface vs first-class function

16 at 1:25:11 PM UTC+1, atd...@gmail.com wrote: > > You have less indirection with the interface. More ergonomic. > An interface also allows to define a set of constraints whereas the first > class function does not coerce you into having a defined set of function > arguments. &

[go-nuts] Re: Interface vs first-class function

You have less indirection with the interface. More ergonomic. An interface also allows to define a set of constraints whereas the first class function does not coerce you into having a defined set of function arguments. On Sunday, November 20, 2016 at 6:22:57 AM UTC+1, Henry wrote: > > Hi, > >

Re: [go-nuts] Re: [ANN] httpsnoop, an easy way to capture http related metrics (response time, bytes written, and http status code)

having to > go over every handler used by the application in order to see where this is > needed? > > If yes, then I don’t like it, because that’s exactly what I was trying to > avoid. The whole idea was to make the wrapping/instrumentation transparent > to all handlers. > >

[go-nuts] Re: [ANN] httpsnoop, an easy way to capture http related metrics (response time, bytes written, and http status code)

I haven't thought too much about it but there is possibly an alternative logic by having the wrappers add a Wrap() http.ResponseWriter that would return the wrappee. So first, one would test for that Wrapper interface, then return the wrappee if the test turns out to be positive. Then one

Re: [go-nuts] Re: Golang should have a center packages index hosting like npm, rust crates

On Thursday, October 27, 2016 at 4:41:42 PM UTC+2, Michal Bohuslávek wrote: > > It's not much of a penalisation IMO. It doesn't have to be a large message > in red saying: "The author of this package doesn't use semantic versioning. > Be careful!". I mean the list of versions can only appear

Re: [go-nuts] map values visibility when the map is populated in a goroutine yet used in another ?

Which I should have read more carefully. Thank you! On Monday, August 15, 2016 at 5:57:13 PM UTC+2, Jan Mercl wrote: > > On Mon, Aug 15, 2016 at 5:28 PM atd...@gmail.com <atd...@gmail.com > > wrote: > > > Is there an happen/before edge between spawning a goroutine a

[go-nuts] map values visibility when the map is populated in a goroutine yet used in another ?

Let's say I have a map in one goroutine that I populate. Then I make a copy of this map by ranging over its keys/values and pass the variable holding the map copy to another goroutine. Will the values in the copy be necessary visible to the last goroutine? Is there an happen/before edge

Re: [go-nuts] Why can't interface value be constant?

, 2016 at 2:37:40 PM UTC+2, atd...@gmail.com wrote: > > If you carelessly do anything, you can introduce bugs. > > Also note that it is fairly easy in Go to construct immutable "values". > > The only thing we do not have is immutable value holders (let in other > langu

Re: [go-nuts] Why can't interface value be constant?

n Saturday, August 6, 2016 at 1:08:56 PM UTC+2, T L wrote: > > > > On Saturday, August 6, 2016 at 6:04:00 PM UTC+8, atd...@gmail.com wrote: >> >> >> >> On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote: >>> >>> >>> >>>

Re: [go-nuts] Why can't interface value be constant?

On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote: > > > > On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote: >> >> No, I'm saying that the current implementation is two pointers. >> The value is addressed by the second poi

Re: [go-nuts] Why can't interface value be constant?

Possibily, if you freeze the type of things that can be boxed by the interface. But what would it be useful for ? That would just mean that an interface is constant. Not even that the value it wraps can't be changed (because with the current implementation, the values an interface wraps need to

[go-nuts] Re: How to check that a Go package has not been modified?

y to create" > especially when you add the compileable requirement. If you're uneasy > about md5 you could always use more bits - like SHA1 used by "git" or > SHA256 (or larger) if you're really paranoid. > > On Wednesday, August 3, 2016 at 1:14:53 PM UTC-4, atd..

[go-nuts] Re: How to check that a Go package has not been modified?

So yeah, md5 or blake2 would work just fine. > > On Wednesday, August 3, 2016 at 10:14:53 AM UTC-7, atd...@gmail.com wrote: >> >> Would a md5 hash suffice? >> >> I mean, it is probably easy to create collisions, but the source still >> needs to compile so... >

Re: [go-nuts] Re: What lead to the versionning debate?

Having an interface between go get and the location of the repositories should really allow people to move packages around at will provided the registration of a package provides a canonical import path. (and a facility for the declaration of mirrors) Now, to accomodate with vcs and demands

Re: [go-nuts] Re: What lead to the versionning debate?

Indeed, that's where we are coming short. The Go ecosystem does not own its package releasing process. (with a release identification scheme that may different from semver since we do not need to worry about major versions for reasons of different release semantics) A `go release` command that

Re: [go-nuts] Re: What lead to the versionning debate?

That's somewhat the intent in enabling the timestamping of packages especially wrt. library-vendored package. Flattening dependencies will still be needed but it would be simply a matter of switching a package to the latest package release that a package may have vendored. But again, I would