Re: [go-nuts] Go 1.19 comparison of variables of generic type
On Wed, Jan 18, 2023 at 8:08 PM Andrew Athan wrote: > > The remaining issue is that, irrespective of the "wideness" of the "any" type > constraint, which apparently includes non-comparable types, the resolution of > v's type is to a comparable type, yet the error is still emitted. The body of the generic function is required to compile for any type that satisfies the constraint. That means that the compilation of a generic function is independent of the actual type argument used to instantiate it. This is explained at https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#constraints . Ian -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXROm8USypmS4bgeq5OQFLwFHGzmvnQ2g-sZCb3U-6LcQ%40mail.gmail.com.
Re: [go-nuts] Endlessly increasing CPU usage problem
@Rustam Abdullaev you're a lifesaver!! I was having this same issue with rising CPU and was going crazy trying to find the resource leak until I saw your comment - pulled up a heap dump and saw 75% time.NewTicker, found a dangling ticker I was instantiating in a goroutine, added a defer ticker.Stop() and voila, problem solved. For my own edification and that of future debuggers, as far as I understand it the issue with leaked tickers is that the time package uses the netpoller (interaction there is beyond me) to continuously loop over all timers on the heap, checking if each is ready to fire and running the associated function if so. With respect to tickers, that means that every new ticker will produce a new call to time.sendTime() on the configured interval until its timer is removed from the heap via Ticker.Stop() - that call to time.sendTime() runs a non-blocking send of time.Now() to the ticker channel (which explicitly never gets closed as per the ticker docs), which altogether comprises that 'tight loop' that Dave suggested earlier in this thread. Is it just me or could this be made a little clearer in the docs? I suppose you're meant to implicitly understand that any allocated resources need to be cleaned up, but this rather mystifying rising CPU issue seems like it could be worth an explicit mention. On Monday, March 8, 2021 at 12:25:11 PM UTC-5 Rustam Abdullaev wrote: > You might have a ticker leak. > Check that you're not accidentally calling time.NewTicker in a loop. > Get a pprof heap dump and look for time.NewTicker objects. The total size > of them should not be large. If it is, then you have a ticker leak. > > On Tuesday, 13 November 2018 at 15:26:29 UTC+1 Anon wrote: > >> Hi Ian, >> >> I am facing the same issue. The CPU usage on my servers increases from >> very low to 100% of CPU. Did you find the solution to your problem? >> >> go version : 1.10.1 >> OS : centOS >> >> Thanks, >> >> >> On Thursday, January 31, 2013 at 7:27:33 AM UTC+5:30, Ian Ragsdale wrote: >>> >>> Thanks Dave, those look like great suggestions. I'm running Go 1.0.3 on >>> Ubuntu: >>> >>> # go version >>> >>> >>>go version >>> go1.0.3 >>> >>> # uname -a >>> Linux 4bf343d4-786f-4fa6-b37c-8bdd018fc63b 2.6.32-350-ec2 #57-Ubuntu SMP >>> Thu Nov 15 15:59:03 UTC 2012 x86_64 GNU/Linux >>> >>> I'll work on gathering the SIGQUIT & GOGCTRACE output - didn't know >>> about those techniques. I can't really share the source, and I'm not sure >>> if there's a good way to cut it down to a sharable chunk, but I'll give it >>> a shot. Strace was going to be my next move. >>> >>> I think your theory in general makes sense, as I'm familiar with that >>> kind of failure, but if that was the case, would it not immediately shoot >>> up to 100% cpu usage as soon as the problem occurred? In this situation, >>> the cpu usage creeps up quite slowly, in a nearly perfect linear fashion >>> over the course of many hours. >>> >>> - Ian >>> >>> On Jan 30, 2013, at 4:00 PM, Dave Cheney wrote: >>> >>> >>> Can you please provide the following details >>> >>> * your Go version and operating system details >>> * the full output from the process when sent a SIGQUIT, once it entered >>> the high CPU usage scenario. >>> * the full output from running the process with GOGCTRACE=1 as above. >>> * the source, I possible, or at least a sample that reproduces the >>> issue. >>> * if you are using Linux, try running the process under the perf(1) >>> tool. >>> * if you able, try running the process under strace(1). >>> >>> My gut feeling is your code, or a library is not checking an error code >>> from a socket operation and entering into a tight loop. If this is the case >>> temporarily breaking the networking on this host may induce the failure. >>> >>> >>> >>> >> ::DISCLAIMER:: >> >> >> >> >> >> This message is intended only for the use of the addressee and may >> contain information that is privileged, confidential and exempt from >> disclosure under applicable law. If the reader of this message is not the >> intended recipient, or the employee or agent responsible for delivering the >> message to the intended recipient, you are hereby notified that any >> dissemination, distribution or copying of this communication is strictly >> prohibited. If you have received this e-mail in error, please notify us >> immediately by return e-mail and delete this e-mail and all attachments >> from your system. >> > -- You received this message because you are subscribed to the Google Groups
Re: [go-nuts] Go 1.19 comparison of variables of generic type
Ian:
Thanks. The example I posted is a silly uber short simplification of my
usecase. In fact, have a complex struct with a large set of methods and
only one of the methods requires comparable types; it'd be nice to not have
to constrain to comparable at the struct level, and only have actual uses
of the one method that does need comparables fail to compile if it's called
on a non-comparable instantiation, or, fall back at runtime to some
acceptable behavior ... anyway: Thanks for the docs pointer. I'll read.
On Wednesday, January 18, 2023 at 7:01:51 PM UTC-8 Ian Lance Taylor wrote:
> On Wed, Jan 18, 2023 at 6:58 PM Christian Stewart
> wrote:
> >
> > On Wed, Jan 18, 2023 at 6:56 PM Ian Lance Taylor
> wrote:
> > > > // IsEmpty checks if the interface is equal to nil.
> > > > func IsEmpty[T Block](blk T) bool {
> > > > var empty T
> > > > return empty == blk
> > > > }
> > > >
> > > > (I had blk Block before, instead of blk T).
> > > >
> > > > Comparing with empty is something I've needed to do a bunch of times
> > > > and have been unable to do.
> > >
> > > The type argument to a function like IsEmpty is rarely an interface
> > > type. So the comparison in the instantiation IsEmpty is not comparing
> > > values of interface type. It's comparing values of whatever type
> > > IsEmpty is instantiated with. And it is possible to instantiate
> > > IsEmpty with types that can't be compared, even with their zero value,
> > > such as [1][]byte.
> >
> > This makes sense, however, is there any way to compare against empty
> > in this context? I was wondering how to go about doing that.
>
> You can use a constraint of "comparable". A function that uses such a
> constraint can only be instantiated with type arguments that are
> comparable.
>
> Or, don't bother to use generics, and just write
> reflect.ValueOf(x).IsZero().
>
> Ian
>
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/d900d93e-c5c0-4806-a0ec-bb4bf4c1afb4n%40googlegroups.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
By the way, what is the idiomatic way to assert that a variable that is
type constrained as "any" in the generic declaration, is in fact comparable
(if there is a way)?
I.e., in my example "Foo" function, is there a way for me to further
constrain (or rather, assert that) v's type is comparable, so that I can in
fact do the comparison?
Constraining to comparable for a single function is typically not a
hardship, but if you have a struct with a bunch of interface functions,
most of which don't need comparable, but only one of which does, it'd be
nice not to jump through declarative hoops to make that happen.
A.
On Wednesday, January 18, 2023 at 4:59:51 PM UTC-8 bse...@computer.org
wrote:
> On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan wrote:
>
>> (Possibly related to issues such as those discussed in
>> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
>>
>> If I do:
>>
>> ```
>> func Foo[V any](v V)bool {
>> return v==v
>> }
>> ```
>>
>> golang 1.19 reports:
>>
>> ```
>> invalid operation: v == v (incomparable types in type set)
>> ```
>>
>> There are two issues with this in my mind: (1) It is ambiguous in that I
>> cannot be sure, as a new user, whether what's being indicated is an
>> incompatibility between the actual types on either side of the equality
>> test or between the set of possible types that COULD be on either side of
>> the equality test due to V's any type constraing in either the case where
>> the left and right side are same or different types (2) In this case, the
>> type V appears to be determinable at compile time and yet it is claimed
>> this equality test is in some way problematic.
>>
>> I'm sure I'm misunderstanding something about golang generics.
>>
>> Can someone comment on this?
>>
>> Thanks in advance :)
>>
>
>
> The problem here is that a type constraint is different from a type, but
> the same identifier is overloaded in the language so "any" as a type
> constraint means something else from "any" as a type.
>
> The error is there, because without that Foo([]string{}) would satisfy the
> constraint but it is still a compile error. Foo[V comparable)(v V) bool is
> the correct declaration.
>
>
>>
>> --
>> 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 golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com
>>
>>
>> .
>>
>
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/414ec7ec-33af-492c-b4c6-ed3b807fbc7dn%40googlegroups.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
Thank you for the practical tip on how to avoid the error. The wording of
the error could be improved, IMHO, and there is a remaining issue I raised
which is not addressed by the suggestion to use the "comparable" constraint
(btw, the documentation I've so far been served up by duckduckgo when
looking for info on generics is way too introductory, and makes no mention
of things like 'comparable').
The remaining issue is that, irrespective of the "wideness" of the "any"
type constraint, which apparently includes non-comparable types, the
resolution of v's type is to a comparable type, yet the error is still
emitted.
By the way, this is a classic case of seeing what you want to see ... my
near vision is worsening and I read "comparable" in the error message as
"compatible," which is at least in part why I found the error message so
confusing. v==v, after all, involves two variables of the exact same type
by definition :)
A.
On Wednesday, January 18, 2023 at 4:59:51 PM UTC-8 bse...@computer.org
wrote:
> On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan wrote:
>
>> (Possibly related to issues such as those discussed in
>> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
>>
>> If I do:
>>
>> ```
>> func Foo[V any](v V)bool {
>> return v==v
>> }
>> ```
>>
>> golang 1.19 reports:
>>
>> ```
>> invalid operation: v == v (incomparable types in type set)
>> ```
>>
>> There are two issues with this in my mind: (1) It is ambiguous in that I
>> cannot be sure, as a new user, whether what's being indicated is an
>> incompatibility between the actual types on either side of the equality
>> test or between the set of possible types that COULD be on either side of
>> the equality test due to V's any type constraing in either the case where
>> the left and right side are same or different types (2) In this case, the
>> type V appears to be determinable at compile time and yet it is claimed
>> this equality test is in some way problematic.
>>
>> I'm sure I'm misunderstanding something about golang generics.
>>
>> Can someone comment on this?
>>
>> Thanks in advance :)
>>
>
>
> The problem here is that a type constraint is different from a type, but
> the same identifier is overloaded in the language so "any" as a type
> constraint means something else from "any" as a type.
>
> The error is there, because without that Foo([]string{}) would satisfy the
> constraint but it is still a compile error. Foo[V comparable)(v V) bool is
> the correct declaration.
>
>
>>
>> --
>> 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 golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com
>>
>>
>> .
>>
>
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/9067ad89-957c-4445-87b9-de9517f83052n%40googlegroups.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
On Wed, Jan 18, 2023 at 6:58 PM Christian Stewart wrote:
>
> On Wed, Jan 18, 2023 at 6:56 PM Ian Lance Taylor wrote:
> > > // IsEmpty checks if the interface is equal to nil.
> > > func IsEmpty[T Block](blk T) bool {
> > > var empty T
> > > return empty == blk
> > > }
> > >
> > > (I had blk Block before, instead of blk T).
> > >
> > > Comparing with empty is something I've needed to do a bunch of times
> > > and have been unable to do.
> >
> > The type argument to a function like IsEmpty is rarely an interface
> > type. So the comparison in the instantiation IsEmpty is not comparing
> > values of interface type. It's comparing values of whatever type
> > IsEmpty is instantiated with. And it is possible to instantiate
> > IsEmpty with types that can't be compared, even with their zero value,
> > such as [1][]byte.
>
> This makes sense, however, is there any way to compare against empty
> in this context? I was wondering how to go about doing that.
You can use a constraint of "comparable". A function that uses such a
constraint can only be instantiated with type arguments that are
comparable.
Or, don't bother to use generics, and just write reflect.ValueOf(x).IsZero().
Ian
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVFtZpWpwJvE-MjgeNkArLHm8U8ViQG-eNRw-ENnSX1vg%40mail.gmail.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
On Wed, Jan 18, 2023 at 4:52 PM Andrew Athan wrote:
>
> (Possibly related to issues such as those discussed in
> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
>
> If I do:
>
> ```
> func Foo[V any](v V)bool {
> return v==v
> }
> ```
>
> golang 1.19 reports:
>
> ```
> invalid operation: v == v (incomparable types in type set)
> ```
>
> There are two issues with this in my mind: (1) It is ambiguous in that I
> cannot be sure, as a new user, whether what's being indicated is an
> incompatibility between the actual types on either side of the equality test
> or between the set of possible types that COULD be on either side of the
> equality test due to V's any type constraing in either the case where the
> left and right side are same or different types (2) In this case, the type V
> appears to be determinable at compile time and yet it is claimed this
> equality test is in some way problematic.
>
> I'm sure I'm misunderstanding something about golang generics.
Start reading here:
https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#operators
Ian
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXsT4A2nhDmUyEkJdzib%2Bh4BgOaKwrgLSBX21FNh1b4kA%40mail.gmail.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
Hi Ian, all,
On Wed, Jan 18, 2023 at 6:56 PM Ian Lance Taylor wrote:
> > // IsEmpty checks if the interface is equal to nil.
> > func IsEmpty[T Block](blk T) bool {
> > var empty T
> > return empty == blk
> > }
> >
> > (I had blk Block before, instead of blk T).
> >
> > Comparing with empty is something I've needed to do a bunch of times
> > and have been unable to do.
>
> The type argument to a function like IsEmpty is rarely an interface
> type. So the comparison in the instantiation IsEmpty is not comparing
> values of interface type. It's comparing values of whatever type
> IsEmpty is instantiated with. And it is possible to instantiate
> IsEmpty with types that can't be compared, even with their zero value,
> such as [1][]byte.
This makes sense, however, is there any way to compare against empty
in this context? I was wondering how to go about doing that.
Thanks,
Christian
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2Bh8R2qyGdhrJ7%3DuCAJRN_SSruKDfxZ8zrV3mdgmN3x9_Rbh9Q%40mail.gmail.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
On Wed, Jan 18, 2023 at 6:28 PM 'Christian Stewart' via golang-nuts
wrote:
>
> Thing is an interface in the first example I gave:
>
> If you want to compare two interfaces:
>
> var foo1 Thing
> var foo2 Thing
>
> Ordinarily you can do foo1 == foo2 and it does pointer-wise comparison.
It's true that if you store pointer values in a variable of interface
type that it does pointer-wise comparisons. But you can store values
of any type in a variable of interface type, not just pointer values.
https://gotipplay.golang.org/p/3swFWinr8Pb
> But in a generic function, as an example:
>
> // IsEmpty checks if the interface is equal to nil.
> func IsEmpty[T Block](blk T) bool {
> var empty T
> return empty == blk
> }
>
> (I had blk Block before, instead of blk T).
>
> Comparing with empty is something I've needed to do a bunch of times
> and have been unable to do.
The type argument to a function like IsEmpty is rarely an interface
type. So the comparison in the instantiation IsEmpty is not comparing
values of interface type. It's comparing values of whatever type
IsEmpty is instantiated with. And it is possible to instantiate
IsEmpty with types that can't be compared, even with their zero value,
such as [1][]byte.
Ian
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWc69k0iWG8Y_LEAFg29wxP%2BXtc0876ek_WtrS4_AXKqA%40mail.gmail.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
Kurtis,
Thing is an interface in the first example I gave:
If you want to compare two interfaces:
var foo1 Thing
var foo2 Thing
Ordinarily you can do foo1 == foo2 and it does pointer-wise comparison.
This absolutely is the case: https://gotipplay.golang.org/p/ODG9xvyVEqs
Now, I understand the confusion because I did have a major typo in the
second part of the question;
But in a generic function, as an example:
// IsEmpty checks if the interface is equal to nil.
func IsEmpty[T Block](blk T) bool {
var empty T
return empty == blk
}
(I had blk Block before, instead of blk T).
Comparing with empty is something I've needed to do a bunch of times
and have been unable to do.
On Wed, Jan 18, 2023 at 5:40 PM Kurtis Rader wrote:
>
> On Wed, Jan 18, 2023 at 5:14 PM 'Christian Stewart' via golang-nuts
> wrote:
>>
>> The thing I ran into with this today was, if you want to compare two
>> interfaces:
>>
>> var foo1 Thing
>> var foo2 Thing
>>
>> Ordinarily you can do foo1 == foo2 and it does pointer-wise comparison.
>
>
> No, it does not. Consider the following example. Do all three vars have the
> same address?
>
> package main
>
> type Thing struct{}
>
> var foo1 Thing
>
> func main() {
> var foo2 Thing
> var foo3 Thing
> println(foo1 == foo2, , )
> println(foo2 == foo3, , )
> }
>
> The output will probably surprise you. See
> https://go.dev/ref/spec#Comparison_operators. An empty struct is handled
> thusly:
>
> Struct values are comparable if all their fields are comparable. Two struct
> values are equal if their corresponding non-blank fields are equal.
>
> Obviously, depending on how "Thing" is defined the results may be different.
> Perhaps you are thinking of the case where "Thing" is an interface.
>
>> But in a generic function, as an example:
>>
>> // IsEmpty checks if the interface is equal to nil.
>> func IsEmpty[T Block](blk Block) bool {
>> var empty T
>> return empty == blk
>> }
>>
>> ... that doesn't work due to the errors mentioned in this thread. And
>> I can't make the type constraint comparable either, that doesn't seem
>> to work.
>>
>> On Wed, Jan 18, 2023 at 4:59 PM burak serdar wrote:
>> >
>> >
>> >
>> > On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan wrote:
>> >>
>> >> (Possibly related to issues such as those discussed in
>> >> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
>> >>
>> >> If I do:
>> >>
>> >> ```
>> >> func Foo[V any](v V)bool {
>> >> return v==v
>> >> }
>> >> ```
>> >>
>> >> golang 1.19 reports:
>> >>
>> >> ```
>> >> invalid operation: v == v (incomparable types in type set)
>> >> ```
>> >>
>> >> There are two issues with this in my mind: (1) It is ambiguous in that I
>> >> cannot be sure, as a new user, whether what's being indicated is an
>> >> incompatibility between the actual types on either side of the equality
>> >> test or between the set of possible types that COULD be on either side of
>> >> the equality test due to V's any type constraing in either the case where
>> >> the left and right side are same or different types (2) In this case, the
>> >> type V appears to be determinable at compile time and yet it is claimed
>> >> this equality test is in some way problematic.
>> >>
>> >> I'm sure I'm misunderstanding something about golang generics.
>> >>
>> >> Can someone comment on this?
>> >>
>> >> Thanks in advance :)
>> >
>> >
>> >
>> > The problem here is that a type constraint is different from a type, but
>> > the same identifier is overloaded in the language so "any" as a type
>> > constraint means something else from "any" as a type.
>> >
>> > The error is there, because without that Foo([]string{}) would satisfy the
>> > constraint but it is still a compile error. Foo[V comparable)(v V) bool is
>> > the correct declaration.
>> >
>> >>
>> >>
>> >> --
>> >> 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 golang-nuts+unsubscr...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com.
>> >
>> > --
>> > 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 golang-nuts+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqo_nrhZfvJ_9qykTkg%3DTxbgdZMC7zFHx1rNnGcdgQk8cA%40mail.gmail.com.
>>
>> --
>> 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 golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web
Re: [go-nuts] Go 1.19 comparison of variables of generic type
On Wed, Jan 18, 2023 at 5:14 PM 'Christian Stewart' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> The thing I ran into with this today was, if you want to compare two
> interfaces:
>
> var foo1 Thing
> var foo2 Thing
>
> Ordinarily you can do foo1 == foo2 and it does pointer-wise comparison.
>
No, it does not. Consider the following example. Do all three vars have the
same address?
package main
type Thing struct{}
var foo1 Thing
func main() {
var foo2 Thing
var foo3 Thing
println(foo1 == foo2, , )
println(foo2 == foo3, , )
}
The output will probably surprise you. See
https://go.dev/ref/spec#Comparison_operators. An empty struct is handled
thusly:
- Struct values are comparable if all their fields are comparable. Two
struct values are equal if their corresponding non-blank
fields are equal.
Obviously, depending on how "Thing" is defined the results may be
different. Perhaps you are thinking of the case where "Thing" is an
interface.
But in a generic function, as an example:
>
> // IsEmpty checks if the interface is equal to nil.
> func IsEmpty[T Block](blk Block) bool {
> var empty T
> return empty == blk
> }
>
> ... that doesn't work due to the errors mentioned in this thread. And
> I can't make the type constraint comparable either, that doesn't seem
> to work.
>
> On Wed, Jan 18, 2023 at 4:59 PM burak serdar wrote:
> >
> >
> >
> > On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan
> wrote:
> >>
> >> (Possibly related to issues such as those discussed in
> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
> >>
> >> If I do:
> >>
> >> ```
> >> func Foo[V any](v V)bool {
> >> return v==v
> >> }
> >> ```
> >>
> >> golang 1.19 reports:
> >>
> >> ```
> >> invalid operation: v == v (incomparable types in type set)
> >> ```
> >>
> >> There are two issues with this in my mind: (1) It is ambiguous in that
> I cannot be sure, as a new user, whether what's being indicated is an
> incompatibility between the actual types on either side of the equality
> test or between the set of possible types that COULD be on either side of
> the equality test due to V's any type constraing in either the case where
> the left and right side are same or different types (2) In this case, the
> type V appears to be determinable at compile time and yet it is claimed
> this equality test is in some way problematic.
> >>
> >> I'm sure I'm misunderstanding something about golang generics.
> >>
> >> Can someone comment on this?
> >>
> >> Thanks in advance :)
> >
> >
> >
> > The problem here is that a type constraint is different from a type, but
> the same identifier is overloaded in the language so "any" as a type
> constraint means something else from "any" as a type.
> >
> > The error is there, because without that Foo([]string{}) would satisfy
> the constraint but it is still a compile error. Foo[V comparable)(v V) bool
> is the correct declaration.
> >
> >>
> >>
> >> --
> >> 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 golang-nuts+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com
> .
> >
> > --
> > 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 golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqo_nrhZfvJ_9qykTkg%3DTxbgdZMC7zFHx1rNnGcdgQk8cA%40mail.gmail.com
> .
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2Bh8R2pDwa0ygGvcZwV-2aa3zhtVqZoZ9YPiFRFmBmF7JsKzqg%40mail.gmail.com
> .
>
--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_HJQGCg8xo2yU%3DahnQD%3DqiUA-08ZHhNu9-XUmc0Jeu7Q%40mail.gmail.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
The thing I ran into with this today was, if you want to compare two interfaces:
var foo1 Thing
var foo2 Thing
Ordinarily you can do foo1 == foo2 and it does pointer-wise comparison.
But in a generic function, as an example:
// IsEmpty checks if the interface is equal to nil.
func IsEmpty[T Block](blk Block) bool {
var empty T
return empty == blk
}
... that doesn't work due to the errors mentioned in this thread. And
I can't make the type constraint comparable either, that doesn't seem
to work.
On Wed, Jan 18, 2023 at 4:59 PM burak serdar wrote:
>
>
>
> On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan wrote:
>>
>> (Possibly related to issues such as those discussed in
>> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
>>
>> If I do:
>>
>> ```
>> func Foo[V any](v V)bool {
>> return v==v
>> }
>> ```
>>
>> golang 1.19 reports:
>>
>> ```
>> invalid operation: v == v (incomparable types in type set)
>> ```
>>
>> There are two issues with this in my mind: (1) It is ambiguous in that I
>> cannot be sure, as a new user, whether what's being indicated is an
>> incompatibility between the actual types on either side of the equality test
>> or between the set of possible types that COULD be on either side of the
>> equality test due to V's any type constraing in either the case where the
>> left and right side are same or different types (2) In this case, the type V
>> appears to be determinable at compile time and yet it is claimed this
>> equality test is in some way problematic.
>>
>> I'm sure I'm misunderstanding something about golang generics.
>>
>> Can someone comment on this?
>>
>> Thanks in advance :)
>
>
>
> The problem here is that a type constraint is different from a type, but the
> same identifier is overloaded in the language so "any" as a type constraint
> means something else from "any" as a type.
>
> The error is there, because without that Foo([]string{}) would satisfy the
> constraint but it is still a compile error. Foo[V comparable)(v V) bool is
> the correct declaration.
>
>>
>>
>> --
>> 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 golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com.
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqo_nrhZfvJ_9qykTkg%3DTxbgdZMC7zFHx1rNnGcdgQk8cA%40mail.gmail.com.
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2Bh8R2pDwa0ygGvcZwV-2aa3zhtVqZoZ9YPiFRFmBmF7JsKzqg%40mail.gmail.com.
Re: [go-nuts] Go 1.19 comparison of variables of generic type
On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan wrote:
> (Possibly related to issues such as those discussed in
> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
>
> If I do:
>
> ```
> func Foo[V any](v V)bool {
> return v==v
> }
> ```
>
> golang 1.19 reports:
>
> ```
> invalid operation: v == v (incomparable types in type set)
> ```
>
> There are two issues with this in my mind: (1) It is ambiguous in that I
> cannot be sure, as a new user, whether what's being indicated is an
> incompatibility between the actual types on either side of the equality
> test or between the set of possible types that COULD be on either side of
> the equality test due to V's any type constraing in either the case where
> the left and right side are same or different types (2) In this case, the
> type V appears to be determinable at compile time and yet it is claimed
> this equality test is in some way problematic.
>
> I'm sure I'm misunderstanding something about golang generics.
>
> Can someone comment on this?
>
> Thanks in advance :)
>
The problem here is that a type constraint is different from a type, but
the same identifier is overloaded in the language so "any" as a type
constraint means something else from "any" as a type.
The error is there, because without that Foo([]string{}) would satisfy the
constraint but it is still a compile error. Foo[V comparable)(v V) bool is
the correct declaration.
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com
>
> .
>
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqo_nrhZfvJ_9qykTkg%3DTxbgdZMC7zFHx1rNnGcdgQk8cA%40mail.gmail.com.
[go-nuts] Go 1.19 comparison of variables of generic type
(Possibly related to issues such as those discussed
in https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
If I do:
```
func Foo[V any](v V)bool {
return v==v
}
```
golang 1.19 reports:
```
invalid operation: v == v (incomparable types in type set)
```
There are two issues with this in my mind: (1) It is ambiguous in that I
cannot be sure, as a new user, whether what's being indicated is an
incompatibility between the actual types on either side of the equality
test or between the set of possible types that COULD be on either side of
the equality test due to V's any type constraing in either the case where
the left and right side are same or different types (2) In this case, the
type V appears to be determinable at compile time and yet it is claimed
this equality test is in some way problematic.
I'm sure I'm misunderstanding something about golang generics.
Can someone comment on this?
Thanks in advance :)
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com.
Re: [go-nuts] Can I use the Golang logo on my site about Golang?
golang.ru is a good name for such a site, but please keep in mind that the language itself is called just Go, as the logo itself should make clear. -rob On Thu, Jan 19, 2023 at 4:05 AM Ian Lance Taylor wrote: > On Wed, Jan 18, 2023 at 8:30 AM Василий Рузин wrote: > > > > Can I use the Golang logo on my site? > > > > My site will be dedicated to Golang. ( https://golang.ru ) > > > > The site will have documentation, articles, videos, vacancies and jobs, > free training. > > > > Perhaps in the future there will be paid training, but I have not yet > decided whether to do it or not. If your license suggests that it is > forbidden to teach golang for a fee, then I will not do it. > > > > I want to gather a Russian-speaking community of Go developers on the > site and I want to make good documentation in Russian. > > > > At the moment, I have not found information on whether I can place the > Golang logo on this site as a site logo. > > > > Please give me an answer! I would be grateful if you could send me a > link where it says that I can use the Golang logo as the logo for my Golang > website. > > > > I really want to see a link to the license where all this is written! > It's even better if you can send a document that I can use the Golang logo. > > In general the logo and the Gopher images are covered by the Creative > Commons Attribution 4.0 License. See https://go.dev/copyright. So go > ahead and use the logo, with attribution. Thanks for your interest. > > Ian > > -- > 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 golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUGm7jTnP55MhL8OtXGoR6_JkdWU8DmyH1qyXoa-%2BBH4w%40mail.gmail.com > . > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOXNBZS0nbu4UogbvLPri8jX-nUSyKt4eJ83ejY%2B2dW_6RrEMA%40mail.gmail.com.
[go-nuts] Embedding shared libraries into gomobile archive
Hi all! I've got a golang project that uses cgo to interface with an external C library. So golang builds depend on that library's *.h and *.so files. Is there a way to tell `gomobile bind` to embed these external shared libraries into generated Android AAR or iOS Framework files? Thanks. -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3dba67c2-6179-4a38-8050-6643a2f38e7cn%40googlegroups.com.
Re: [go-nuts] Can I use the Golang logo on my site about Golang?
On Wed, Jan 18, 2023 at 8:30 AM Василий Рузин wrote: > > Can I use the Golang logo on my site? > > My site will be dedicated to Golang. ( https://golang.ru ) > > The site will have documentation, articles, videos, vacancies and jobs, free > training. > > Perhaps in the future there will be paid training, but I have not yet decided > whether to do it or not. If your license suggests that it is forbidden to > teach golang for a fee, then I will not do it. > > I want to gather a Russian-speaking community of Go developers on the site > and I want to make good documentation in Russian. > > At the moment, I have not found information on whether I can place the Golang > logo on this site as a site logo. > > Please give me an answer! I would be grateful if you could send me a link > where it says that I can use the Golang logo as the logo for my Golang > website. > > I really want to see a link to the license where all this is written! It's > even better if you can send a document that I can use the Golang logo. In general the logo and the Gopher images are covered by the Creative Commons Attribution 4.0 License. See https://go.dev/copyright. So go ahead and use the logo, with attribution. Thanks for your interest. Ian -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUGm7jTnP55MhL8OtXGoR6_JkdWU8DmyH1qyXoa-%2BBH4w%40mail.gmail.com.
[go-nuts] Can I use the Golang logo on my site about Golang?
Hello. Can I use the Golang logo on my site? My site will be dedicated to Golang. ( https://golang.ru ) The site will have documentation, articles, videos, vacancies and jobs, free training. Perhaps in the future there will be paid training, but I have not yet decided whether to do it or not. If your license suggests that it is forbidden to teach golang for a fee, then I will not do it. I want to gather a Russian-speaking community of Go developers on the site and I want to make good documentation in Russian. At the moment, I have not found information on whether I can place the Golang logo on this site as a site logo. Please give me an answer! I would be grateful if you could send me a link where it says that I can use the Golang logo as the logo for my Golang website. I really want to see a link to the license where all this is written! It's even better if you can send a document that I can use the Golang logo. -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3dff028a-0ee3-4784-8aa5-67249a98b3c4n%40googlegroups.com.
[go-nuts] Re: httptest and gorilla/mux route variables
Kevin this is brilliant. It Works <3 <3
On Saturday, 4 December 2021 at 04:29:57 UTC+5 Kevin Mathew S wrote:
> This works perfectly for me
>
> func newReq(method, path, body string, vars map[string]string)
> *http.Request {
> r := httptest.NewRequest(method, path, strings.NewReader(body))
> return mux.SetURLVars(r, vars)
> }
>
>
> On Tuesday, May 12, 2015 at 7:34:21 PM UTC+5:30 al...@getloopd.com wrote:
>
>> Awesome! This works great Thomas :)
>>
>>
>> On Monday, August 25, 2014 at 3:21:08 PM UTC+8, Thomas Bruyelle wrote:
>>>
>>> I found a solution that doesn't require you to manually add the mux Vars
>>> in your tests or use the mux Context.
>>>
>>> The key is to create your mux router in a separate function like that
>>>
>>> func Router() *mux.Router {
>>> r := mux.Router()
>>> r.HandleFunc("/employees/{1}", employeeHandler)
>>> (...)
>>> return r
>>> }
>>>
>>> func init() {
>>> http.Handle("/", Router())
>>> }
>>>
>>> Then in your tests, you can use directly the Router(), just like that
>>>
>>> func TestEmployeeHandler(t *testing.T) {
>>> r := http.NewRequest("GET", "employees/1
>>> ", nil)
>>> w := httptest.NewRecorder()
>>>
>>> Router().ServeHTTP(w, r)
>>>
>>> ...
>>>
>>> }
>>>
>>>
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/01bc729e-abe0-4bb5-a076-6bd38dab050an%40googlegroups.com.
Re: [go-nuts] How to understand runtime.gogo?
Thanks, solved my problem 在2023年1月17日星期二 UTC+8 00:49:03 写道： > On Mon, Jan 16, 2023 at 8:43 AM j2gg0s wrote: > > > > As a newbie of golang's assembly, i cant understand why we MOVQ DX CX > twice in runtime.gogo. WHY? > > I don't see any MOVQ DX, CX instructions here. Can you clarify by > saying exactly which instructions you are asking about? > > Note that MOVQ 0(DX), CX treats DX as a memory address, and moves the > 8-byte value at that address into CX. And MOVQ DX, g(CX) treats CX as > a memory address, and moves the value in DX into the address as "g" > bytes offset from the address in CX. > > Ian > > > > Source code: > > ``` > > 255 // func gogo(buf *gobuf) > > 256 // restore state from Gobuf; longjmp > > 257 TEXT runtime·gogo(SB), NOSPLIT, $0-8 > > 258 MOVQ buf+0(FP), BX // gobuf > > 259 MOVQ gobuf_g(BX), DX > > 260 MOVQ 0(DX), CX // make sure g != nil > > 261 JMP gogo<>(SB) > > 262 > > 263 TEXT gogo<>(SB), NOSPLIT, $0 > > 264 get_tls(CX) > > 265 MOVQ DX, g(CX) > > 266 MOVQ DX, R14 // set the g register > > 267 MOVQ gobuf_sp(BX), SP // restore SP > > 268 MOVQ gobuf_ret(BX), AX > > 269 MOVQ gobuf_ctxt(BX), DX > > 270 MOVQ gobuf_bp(BX), BP > > 271 MOVQ $0, gobuf_sp(BX) // clear to help garbage collector > > 272 MOVQ $0, gobuf_ret(BX) > > 273 MOVQ $0, gobuf_ctxt(BX) > > 274 MOVQ $0, gobuf_bp(BX) > > 275 MOVQ gobuf_pc(BX), BX > > 276 JMP BX > > ``` > > > > Link: > https://github.com/golang/go/blob/go1.17.13/src/runtime/asm_amd64.s#L255 > > > > > > -- > > 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 golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/5fafeb38-1bc7-4a96-b386-41e14c431273n%40googlegroups.com > . > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3ba1a60a-f0be-497c-bdda-f72316cc1d2an%40googlegroups.com.
