Re: [go-nuts] Graphics/Image example programs

Thanks Nigel! I found this one also: https://github.com/veandco/go-sdl2 Let me try these things. Regards dharani On Sun, Jun 27, 2021 at 5:17 PM Nigel Tao wrote: > On Sun, Jun 27, 2021 at 8:44 AM Tharaneedharan Vilwanathan < > vdhar...@gmail.com> wrote: > >> But I need something that display

[go-nuts] about golang defer?

a defer call generate some code like: - - v42 (8) = StaticLECall {AuxCall{runtime.deferprocStack}} [8] v36 v41 - v43 (8) = SelectN [0] v42 - Defer v42 → b2 b3 (likely) (8) - b2: ← b1- - - v48 (7) = Copy v43 - v49 (7) = VarKill {.autotmp_0} v48

[go-nuts] Re: Named types vs not named types

A some weak reason not to support the change. Using unnamed parameter types could avoiding some explicit conversions. package main import "net/http" type MyHandlerFunc func(http.ResponseWriter, *http.Request) func f(http.HandlerFunc) {} func g(MyHandlerFunc) {} func h(func(http.ResponseWriter

Re: [go-nuts] Graphics/Image example programs

On Sun, Jun 27, 2021 at 8:44 AM Tharaneedharan Vilwanathan < vdhar...@gmail.com> wrote: > But I need something that displays images and accepts mouse input, etc but > not vector graphics (say, in OpenGL) for now. Can you please provide some > pointers? > https://pkg.go.dev/github.com/BurntSushi/x

Re: [go-nuts] Re: Upgrade to Go1.16 from Go1.14 broke my query

Update: I did a re-installation of Go1.14.15. Reinstalled the FirebirdSQL driver, yet the problem persist. On Sunday, June 27, 2021 at 1:43:23 PM UTC-5 Hugh Myrie wrote: > The version I saw in the go.mod file was v0.9.1. However, looking at the > modified date of the files in the library fol

Re: [go-nuts] How to verify whether gollvm is picked

On Sat, Jun 26, 2021 at 11:59 PM Kavindu Gimhan Zoysa wrote: > > I have ran the commands in https://go.googlesource.com/gollvm/#installing, (I > did not run `ninja install-gollvm`). Then I set the path of bin folder to my > $PATH using `export PATH=build-debug/bin:$PATH`. > > Finally, I was able

Re: [go-nuts] Named types vs not named types

> Nit: The nomenclature is "defined", not "named" (it changed when type aliases where introduced, which give a type a name, without defining a new type - so "named" became confusing). Note taken. You give me a lot knowledge's food that I need to digest ... So don't expect me to answer you now, in

Re: [go-nuts] Named types vs not named types

whoops: "…because the first is a *defined* type", of course. On Sun, Jun 27, 2021 at 9:58 PM Axel Wagner wrote: > On Sun, Jun 27, 2021 at 9:41 PM Victor Giordano > wrote: > >> Ok. Thanks for the insight again. Correction noted. I do get that types >> are named or not, and any not named type is

Re: [go-nuts] Named types vs not named types

On Sun, Jun 27, 2021 at 9:41 PM Victor Giordano wrote: > Ok. Thanks for the insight again. Correction noted. I do get that types > are named or not, and any not named type is a type of its own; and two not > named types are different despite having the same definition (like in > Pascal) > Nit: T

Re: [go-nuts] Named types vs not named types

> and two not named types are different despite having the same definition (like in Pascal) Mmmm.. I really don't know if what I stated is actually true perhaps two not named types with the same definition are the same underlying type. El dom, 27 jun 2021 a las 16:41, Victor Giordano () escr

Re: [go-nuts] Named types vs not named types

Ok. Thanks for the insight again. Correction noted. I do get that types are named or not, and any not named type is a type of its own; and two not named types are different despite having the same definition (like in Pascal) Nice to clarify the issue. Now regarding our friendly discussion... > T

Re: [go-nuts] Data race problem with mutex protected maps

On Sunday, 27 June 2021 at 19:33:40 UTC+1 ro...@campbell-lange.net wrote: > Thank you for the pointers and the excellent video (actually by Bryan C. > Mills, it seems). > > Argh! My apologies to Bryan. I copied the link directly from my local bookmarks/notes file, and I had misattributed it t

Re: [go-nuts] Named types vs not named types

BTW, to be clear: You misuse the term "Untyped" in your example. Both methods are fully typed. They just use different types. This is kind of relevant, because you say "typed is better" - but both are typed to the same degree. On Sun, Jun 27, 2021 at 8:55 PM Axel Wagner wrote: > On Sun, Jun 27,

Re: [go-nuts] Named types vs not named types

On Sun, Jun 27, 2021 at 8:17 PM Victor Giordano wrote: > But but but... just bear with me... cuz, in this specific case, I guess > you could employ both "approaches". See my example here > . > Yes, I'm aware this works. That wasn't in doubt. The question is

Re: [go-nuts] Re: Upgrade to Go1.16 from Go1.14 broke my query

The version I saw in the go.mod file was v0.9.1. However, looking at the modified date of the files in the library folder was last year. So I deleted the library and reinstalled it . I suppose doing a "go get" without specifying a version would retrieve the latest version. Correct me if I'm wrong h

Re: [go-nuts] Data race problem with mutex protected maps

On 27/06/21, Brian Candler (b.cand...@pobox.com) wrote: > On Sunday, 27 June 2021 at 10:32:22 UTC+1 ro...@campbell-lange.net wrote: > > > By the way, as a golang newbie, it isn't clear to me when it is advisable > > to use a channel for locking as opposed to a mutex. Do people tend to use > > the

Re: [go-nuts] Named types vs not named types

Axel, thanks for the insight! You give a lot to think about and that is what was looking for. The path example is very nice btw!. Is like working with a raw data value that needs a little bit validation to ensure it correctines. Like having a type for natural numbers (like 'Natural') that can be cr

Re: [go-nuts] Named types vs not named types

On Sun, Jun 27, 2021 at 6:05 PM Victor Giordano wrote: > Thanks to all for the answer, i really try to see any actual reason but i > still don't get it. For me, to my humble acknowledgement, if I define a > type I tend to use everywhere it appears. Period. End of the story. > > > FWIW, arguing t

Re: [go-nuts] Named types vs not named types

Thanks to all for the answer, i really try to see any actual reason but i still don't get it. For me, to my humble acknowledgement, if I define a type I tend to use everywhere it appears. Period. End of the story. > FWIW, arguing that `http.HandleFunc` should take a `http.HandlerFunc` because ther

Re: [go-nuts] Named types vs not named types

FWIW, arguing that `http.HandleFunc` should take a `http.HandlerFunc` because there exists a defined type with the same underlying type as the parameter is a bit like arguing every function that takes an `int64` should instead take a time.Duration . That's jus

Re: [go-nuts] Named types vs not named types

On Sun, Jun 27, 2021 at 5:25 PM Victor Giordano wrote: > I keep wondering if they code that way for any reason. With "code that > way" I mean: define a type and then not use it. > As I said: It's used plenty of times. Both inside of `net/http` and outside of it. > >- So, ¿why not employ the

Re: [go-nuts] Named types vs not named types

On Sun, Jun 27, 2021 at 5:25 PM Victor Giordano wrote: > If you see here you will find a definition for a function. This defines type `HandlerFunc`: https://github.com/golang/go/blob/37f9a8f69d6299783eac8848d87e27eb563500ac/src/net/http/server.go#L2042 > Then if you look here you will find that

Re: [go-nuts] Go and GPUs

Didn't AMD and Intel open source their drivers. Or are you talking about firmware here? I thought that is how OpenBSD can run well with them but not with Nvidia hw? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group a

Re: [go-nuts] Named types vs not named types

Thanks for the answers. I'm not saying that what I proposed in the ticket should be engaged, no! I get the idea why not and I'm okay with that. The related discussion about typification could be addressed on a different thread. The thing I bring here are my doubts about this: I keep wondering if th

Re: [go-nuts] Named types vs not named types

If I understand you correctly, you are suggesting to replace the parameter type `func(http.ResponseWriter, *http.Request)` with the parameter type `http.HandlerFunc`. You've been (correctly) told that we can't make that change, because it would break the Go 1 compatibility change (as there is code

Re: [go-nuts] Named types vs not named types

Hi, I'm not sure what type you are referring to here. This file defines many named types and interfaces and I'd say from a quick read that all of them are used. Could you clarify what you mean? Le dim. 27 juin 2021 à 15:53, Victor Giordano a écrit : > Hello gophers! > > While studing at this s

[go-nuts] Named types vs not named types

Hello gophers! While studing at this source code in search for some knowledge and enlightment, i do note that in some file a type is defined and then is not used in a place where it could be use

Re: [go-nuts] Data race problem with mutex protected maps

On 27/06/21, Brian Candler (b.cand...@pobox.com) wrote: > > Shouldn't that result in a panic, even without -race? > > It's not *guaranteed* to panic when you make concurrent accesses to the > same map (hence the point of the race checker). And having two structs > refer to the same map is no di

Re: [go-nuts] Data race problem with mutex protected maps

On Sunday, 27 June 2021 at 10:32:22 UTC+1 ro...@campbell-lange.net wrote: > By the way, as a golang newbie, it isn't clear to me when it is advisable > to > use a channel for locking as opposed to a mutex. Do people tend to use the > former? > > There is an absolutely excellent video on this t

Re: [go-nuts] Data race problem with mutex protected maps

On 26/06/21, Ian Lance Taylor (i...@golang.org) wrote: > On Sat, Jun 26, 2021 at 3:27 PM Rory Campbell-Lange wrote: > > > > I'm trying to work out why I have a data race problem (on go 1.15 and 1.16). > > > > *SearchResults.Set is called from several goroutines. I am trying to avoid > > concurren

Re: [go-nuts] Data race problem with mutex protected maps

One way to be robust against this particular problem is to carry a pointer to a mutex, rather than embedding a mutex. https://play.golang.org/p/UPY7EBKSYl5 On Sunday, 27 June 2021 at 10:18:52 UTC+1 Brian Candler wrote: > > Shouldn't that result in a panic, even without -race? > > It's not *guara

Re: [go-nuts] Data race problem with mutex protected maps

> Shouldn't that result in a panic, even without -race? It's not *guaranteed* to panic when you make concurrent accesses to the same map (hence the point of the race checker). And having two structs refer to the same map is no different to having two variables refer to the same map. For the

Re: [go-nuts] Re: Upgrade to Go1.16 from Go1.14 broke my query

On Sunday, 27 June 2021 at 03:27:28 UTC+1 hugh@gmail.com wrote: > I agree. So far, I've Installed Go1.15, reinstalled the Firebird library. Which version? The latest tagged version (v0.9.1) or the tip of the master branch? Having said that: the commit