[go-nuts] alloc_space in go pprof
Hello everyone, recently I encounted a strange thing when using go pprof. A project written in Go was often killed by Linux OOM-killer after running for a while . So I used go pprof to find out if any memory leaks there. But when RSS of the process reached to nearly 20G(by top command), pprof showed that only 10G was allocated on heap. this is the peek view in go pprof. —— File: logic Type: alloc_space Time: Jul 7, 2020 at 8:38pm (CST) Showing nodes accounting for 10991.31MB, 100% of 10991.31MB total —— In my understanding, alloc_space is the allocated bytes throughout the run-time of the program. So are there any other memory used by Go program but not recored in pprof? And where may the extra 10G be used. Thanks Ge -- 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/510ace94-946a-4cd1-a62f-44effe9f3bdfn%40googlegroups.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wednesday, July 8, 2020 at 4:50:30 PM UTC-7, simon place wrote: > > wait a minute, so this... https://play.golang.org/p/x5SQVgSJsIs > > could return anything! > > I think float -0 should be guaranteed to convert to integer 0. Just like -0.25 and 0.25. The spec says "fraction discarded" but I interpret that as throwing away the - in front of the zero (being an infinitesimal negative fraction). Only if *after* rounding towards zero, if the value doesn't fit then the result is implementation dependent. > On Wednesday, 8 July 2020 19:57:30 UTC+1, Ian Lance Taylor wrote: >> >> The spec is not particularly helpful, but it is not entirely silent. >> It says: "In all non-constant conversions involving floating-point or >> complex values, if the result type cannot represent the value the >> conversion succeeds but the result value is implementation-dependent." >> >> 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/e3d22561-b2ea-43a6-98f6-6840d0e878e3o%40googlegroups.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wed, Jul 8, 2020 at 4:50 PM 'simon place' via golang-nuts wrote: > > wait a minute, so this... https://play.golang.org/p/x5SQVgSJsIs > > could return anything! On different implementations, including different processors, yes. On the same implementation on the same processor, the value should be consistent. Ian > On Wednesday, 8 July 2020 19:57:30 UTC+1, Ian Lance Taylor wrote: >> >> The spec is not particularly helpful, but it is not entirely silent. >> It says: "In all non-constant conversions involving floating-point or >> complex values, if the result type cannot represent the value the >> conversion succeeds but the result value is implementation-dependent." >> >> 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/40aa201e-884a-4ca3-8d3d-4a5a503934bbo%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/CAOyqgcVuAB-AO1BVkLk4b4kAoH5uhGrgJ_5oUmuevM53A0bzzQ%40mail.gmail.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wed, Jul 8, 2020 at 4:50 PM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > wait a minute, so this... https://play.golang.org/p/x5SQVgSJsIs > > could return anything! > In theory, yes, because negative zero can't be represented as an int or uint. In practice, I would expect zero. At least on any platform using the IEEE 754 standard due to how the sign is encoded by that standard and the instructions for converting such a value to an int behave. Of the five magic values that is the only one you can (probably) safely handle using the straightforward conversion. -- 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%3DD8yiA6G9zXKV%3D88JUwZJzB%2BpvpjXf1PhN_SruraNoyuXw%40mail.gmail.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wed, Jul 8, 2020 at 3:26 PM 'simon place' via golang-nuts wrote: > > i was just reading that! > > does it mean (or just imply) that constant conversions are not implementation > dependent? Constant conversions are mostly not implementation dependent. Constant conversions follow the rules of general constant expressions described at https://golang.org/ref/spec#Constant_expressions. See the "Implementation restriction" note at the end of that section. > i remember wondering, a while ago, why it was that NaN etc. weren't > constants, after-all their encoding is unique and can't vary. > > seems the reason for this is. > > "Numeric constants represent exact values of arbitrary precision and do not > overflow. Consequently, there are no constants denoting the IEEE-754 negative > zero, infinity, and not-a-number values." > > not sure how negative zero, for example, fails here, its a value of a float > type, so it is Numeric, an exact value, and i don't really see how "of > arbitrary precision and do not overflow" apply? Constants in Go are intended to act more like mathematical representations than like computer types. Hence values have no precision limits, and concepts like negative zero and infinity and NaN do not exist. > but this is stymieing the whole point of the way i was doing it, > simple/clear/short/std.lib leveraging, because it seems you HAVE to check > them all, (NaN/+Inf/-Inf/-0) because an "implementation-dependent" value > could be anything and so potentially exactly what you were expecting right up > until it isn't! > > seems quite like map iteration randomisation. if it can be anything better > make it random to cause earliest failure. Unfortunately I think using that approach for conversions would have significant execution time costs. For map iteration it's almost free. 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/CAOyqgcXwXFAddnjO9WkN-J3n2T%2B%2Bp_0sHqNiuhGu8SspyBBCMg%40mail.gmail.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
wait a minute, so this... https://play.golang.org/p/x5SQVgSJsIs could return anything! On Wednesday, 8 July 2020 19:57:30 UTC+1, Ian Lance Taylor wrote: > > The spec is not particularly helpful, but it is not entirely silent. > It says: "In all non-constant conversions involving floating-point or > complex values, if the result type cannot represent the value the > conversion succeeds but the result value is implementation-dependent." > > 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/40aa201e-884a-4ca3-8d3d-4a5a503934bbo%40googlegroups.com.
Re: [go-nuts] [generics] Issues with identifying the matched predeclared type
On Wed, Jul 8, 2020 at 3:59 AM roger peppe wrote:
>
> That's another interesting syntax. I'm not sure whether there's any
> particular advantage in mentioning the type parameter in each case,
> although I guess it does mean that the syntax for multiple matches is
> straightforward and can allow an "any" match.
The meaning of case io.Stringer: in existing type switches is asymmetrical.
Matching is based on interface satisfaction (for interface constraints),
but the matched value has an exact type of io.Stringer inside the body of
the case. Choosing either exact matching semantics *or* constraint
refinement semantics for generic type switches will be inconsistent with
one of these two behaviours, potentially leading to confusion about what a
generic type switch is doing.
The advantage of mentioning the type parameter in each case is that it
makes the parallel to type parameter lists very obvious. If matching is
done on constraint satisfaction, then this syntax should suggest the
correct semantics. Also, just the fact that it's different from the
existing type switch case clause syntax helps avoid confusion between the
two.
Another advantage of mentioning the type parameter in each case is that
it allows you to change between T and *T constraints within the same
switch, as needed. Using constraints on *T could allow you to do exact type
matching as well:
type switch {
case *T interface{ type *string }:
// `T` is treated as identical to `string` in this case
case T io.Stringer:
// `T` can be any type that satisfies `io.Stringer` in this case
}
Maybe the type matching could be written using a shorthand like the one you
were suggesting, but with the opposite meaning:
type switch {
case *T type(*string):
// `T` is treated as identical to `string` in this case
}
(Or just case T = string: could work and would be more obvious, I suppose).
I'd hope that most people using type switches for specialisation would
> include a generic fallback for unknown types. The main use cases I see for
> it are optimisation and preserving backward compatibility.
Yeah, I was more thinking that if you *functionally required* the ability
to match to an exact type in order to implement your generic function, then
it wouldn't be total over its type parameter domain. For optimizations, I
can see how you might be relying on existing code that is only written to
support particular types for one reason or another.
On Wed, Jul 8, 2020 at 3:59 AM roger peppe wrote:
>
>
> On Wed, 8 Jul 2020 at 00:33, Steven Blenkinsop
> wrote:
>
>> On Tue, Jul 7, 2020 at 10:44 AM, roger peppe wrote:
>>
>>>
>>> In my description, there's no assumption that doing it over the type
>>> parameter implies a refinement of the previously set type constraints. In
>>> fact it definitely implies otherwise because (for example) if you know that
>>> a generic type parameter has the known type "string", then it's a loosening
>>> rather than a tightening of the constraint - you can now do more things
>>> with values of that type than you could previously.
>>>
>>
>> I think this is speaking at cross purposes. The identity of the type is
>> more constrained (it must be string as opposed to any other type
>> satisfying a particular interface), but you can do more with it in your
>> generic code. You're refining the constraint on the identity of the type
>> while at the same time expanding its capabilities. An unconstrained type
>> parameter can be any type but supports the fewest operations.
>>
>
> Fair point.
>
>
>>
>> I don't think it's sufficient. Consider this program:
>>> https://go2goplay.golang.org/p/wO0JHIuHH2l. If "string" matches both
>>> "myString" and "string" itself, then the type checker would allow the
>>> assignment of a function of type "func(string) uint64" to a function of
>>> type "func(myString) uint64" with no explicit type conversion, which breaks
>>> an important safety constraint in the language. Worse, if we let an
>>> interface type match any concrete type that happens to implement that
>>> interface, then there's a serious issue because those types probably don't
>>> have the same shape, so can't be used interchangeably. For example, this
>>> program would be valid, but isn't possible to compile because io.Stringer
>>> and string have different representations:
>>> https://go2goplay.golang.org/p/_uLjQxb-z-b
>>>
>>
>> I would think that in the second case, the assignment to xx wouldn't
>> type check because T is only known to implement io.Stringer rather than
>> being identical to io.Stringer.
>>
>
> That depends on the semantics of the type switch. In my suggestion, it
> would type check because the case would only be chosen if the argument type
> is *exactly* that type (but the xx slice wouldn't be assigned to). You'd
> need to add a "type" qualifier to match on any type that implements
> io.Stringer.
>
> Perhaps this would be more clear if it was written as
>>
>> type switch {
>> case T io.Stringer:
>> // Code
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wed, Jul 8, 2020 at 3:26 PM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > i remember wondering, a while ago, why it was that NaN etc. weren't > constants, after-all their encoding is unique and can't vary. > > seems the reason for this is. > > "Numeric constants represent exact values of arbitrary precision and do > not overflow. Consequently, there are no constants denoting the IEEE-754 > negative zero, infinity, and not-a-number values." > > not sure how negative zero, for example, fails here, its a value of a > float type, so it is Numeric, an exact value, and i don't really see how > "of arbitrary precision and do not overflow" apply? > If you're on a system with twos-complement representation for ints, rather than ones-complement or sign-and-magnitude, you can't represent negative zero in an int type. How would you convert float64(-0) to an int without losing information? It isn't overflow in the usual sense but the point is that those values cannot be represented by any of the int data types. but this is stymieing the whole point of the way i was doing it, > simple/clear/short/std.lib leveraging, because it seems you HAVE to check > them all, (NaN/+Inf/-Inf/-0) because an "implementation-dependent" value > could be anything and so potentially exactly what you were expecting right > up until it isn't! > The way you were doing it relies on implementation dependent behavior. Which is risky even if you never intend to support anything but a single architecture (e.g., x86_64) and should have a prominent "HERE BE DRAGONS" comment in the code. -- 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-1bY-nezMOzE0deg6dY06OS_Yc-xR%3DFdrss49HV0tM5w%40mail.gmail.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
i was just reading that! does it mean (or just imply) that constant conversions are not implementation dependent? i remember wondering, a while ago, why it was that NaN etc. weren't constants, after-all their encoding is unique and can't vary. seems the reason for this is. "Numeric constants represent exact values of arbitrary precision and do not overflow. Consequently, there are no constants denoting the IEEE-754 negative zero, infinity, and not-a-number values." not sure how negative zero, for example, fails here, its a value of a float type, so it is Numeric, an exact value, and i don't really see how "of arbitrary precision and do not overflow" apply? but this is stymieing the whole point of the way i was doing it, simple/clear/short/std.lib leveraging, because it seems you HAVE to check them all, (NaN/+Inf/-Inf/-0) because an "implementation-dependent" value could be anything and so potentially exactly what you were expecting right up until it isn't! seems quite like map iteration randomisation. if it can be anything better make it random to cause earliest failure. The spec is not particularly helpful, but it is not entirely silent. > It says: "In all non-constant conversions involving floating-point or > complex values, if the result type cannot represent the value the > conversion succeeds but the result value is implementation-dependent." > > 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/7937ab3d-31bf-4806-8380-49b894c7f611o%40googlegroups.com.
[go-nuts] Re: decode unknown CBOR type with set of known types
My first question would be, is the type encoded into the CBOR blob somehow?
Like by a tag?
If structs are encoded as maps, with no type information, then the input
doesn't have enough information to do what you want. How could the blob
(using JSON notation)
{"X": 1, "Y": 2}
know whether it should decode into
type Point struct { X, Y int}
or
type Chromosome {X, Y int}
?
You have to encode the type somehow. If you control the encoding process
and you're encoding a fixed set of types that you want to distinguish at
decode time,
you can do something like this:
type (
This ...
That ...
TheOther ...
Thing struct {
This *This
That *That
TheOther *TheOther
}
)
To encode a `This` named `t`, actually encode `Thing{This: }`. When you
decode that into a `Thing`, only the `This` field will be non-nil, so you
know you've got a `This`.
(Disclaimer: I know this technique works with the encoding/json package; I
can't guarantee it works with the cbor package you're using because I'm not
familiar with it,
but if it behaves like encoding/json, you should be OK.)
On Wednesday, July 8, 2020 at 3:44:36 PM UTC-4, David Stainton wrote:
>
>
> Greetings,
>
> Similar questions have been asked in the past and I've read those posts...
> and I believe I'm asking something different here.
>
> I'm using length prefixed CBOR over unix domain socket as my wire format.
> However the reader doesn't known which CBOR type it needs to decode.
> I'd like a mechanism similar to the golang switch type assertion where a
> known set of types are specified.
>
> Before you go and tell me to use the empty interface let me explain that
> certainly this works:
>
> // "github.com/fxamacker/cbor"
> var v interface{}
> err = cbor.Unmarshal(out, )
>
> It works for some definitions of "works". It doesn't tell me what type it
> is but it does allow me to access each struct field by name in the map of
> type: map[interface {}]interface {}
>
> The reason this is not good enough is that it doesn't concretely tell me
> the type!
> Of course I could go ahead and add a struct field called TypeName and set
> it's value to a string encoding the name. But that feels wrong and I'd feel
> bad after writing it.
>
> I've also tried to ask this question on a ticket here:
> https://github.com/fxamacker/cbor/issues/241
>
> Is the least incorrect solution to iteratively try cbor.Unmarshal with all
> the types in the known set of possible types until one of them works?
>
> Certainly this problem isn't specific to CBOR. Am I asking the question
> incorrectly here?
>
>
> Sincerely,
> David
>
--
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/019fb798-f282-451d-947c-79a7c1bc2b98o%40googlegroups.com.
[go-nuts] decode unknown CBOR type with set of known types
Greetings,
Similar questions have been asked in the past and I've read those posts...
and I believe I'm asking something different here.
I'm using length prefixed CBOR over unix domain socket as my wire format.
However the reader doesn't known which CBOR type it needs to decode.
I'd like a mechanism similar to the golang switch type assertion where a
known set of types are specified.
Before you go and tell me to use the empty interface let me explain that
certainly this works:
// "github.com/fxamacker/cbor"
var v interface{}
err = cbor.Unmarshal(out, )
It works for some definitions of "works". It doesn't tell me what type it
is but it does allow me to access each struct field by name in the map of
type: map[interface {}]interface {}
The reason this is not good enough is that it doesn't concretely tell me
the type!
Of course I could go ahead and add a struct field called TypeName and set
it's value to a string encoding the name. But that feels wrong and I'd feel
bad after writing it.
I've also tried to ask this question on a ticket here:
https://github.com/fxamacker/cbor/issues/241
Is the least incorrect solution to iteratively try cbor.Unmarshal with all
the types in the known set of possible types until one of them works?
Certainly this problem isn't specific to CBOR. Am I asking the question
incorrectly here?
Sincerely,
David
--
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/f48f6955-0478-4adf-a775-268a480dfdbfo%40googlegroups.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wed, Jul 8, 2020 at 11:24 AM Kurtis Rader wrote: > > On Wed, Jul 8, 2020 at 10:50 AM 'simon place' via golang-nuts > wrote: >> >> i understand, but think that since Go particularly allows these >> conversations transparently, consistency should be covered by language >> specification. it potentially causes bugs that doesn't fail fast, didn't for >> me anyway. > > > The spec is silent on this point: https://golang.org/ref/spec#Conversions. > Which makes sense since we do not want to pay the cost of the additional > logic for consistently handling NaN every time a float is converted to an int > since almost none of those conversions will involve NaN. The spec is not particularly helpful, but it is not entirely silent. It says: "In all non-constant conversions involving floating-point or complex values, if the result type cannot represent the value the conversion succeeds but the result value is implementation-dependent." 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/CAOyqgcVSN2qs5gVXPG4a-%3Dte--J9C6gAi1RiWaj8htq%2BvaMvtw%40mail.gmail.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wed, Jul 8, 2020 at 10:50 AM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > i understand, but think that since Go particularly allows these > conversations transparently, consistency should be covered by language > specification. it potentially causes bugs that doesn't fail fast, didn't > for me anyway. > The spec is silent on this point: https://golang.org/ref/spec#Conversions. Which makes sense since we do not want to pay the cost of the additional logic for consistently handling NaN every time a float is converted to an int since almost none of those conversions will involve NaN. > how much code out there would break if you changed the existing returned > value on x86? > Zero, or so close to it that it doesn't matter. Any code that is depending on int64(float64(NaN)) to result in a particular value is already broken since the language spec doesn't mandate any particular value and the behavior is therefore likely to depend on the compiler version, CPU architecture, and phase of the moon. -- 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%3DD9P%3DAKmj0m2kbR6bzRbq%3DchBQarPAwKEZC%2BqBiWhDoqgg%40mail.gmail.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
i understand, but think that since Go particularly allows these conversations transparently, consistency should be covered by language specification. it potentially causes bugs that doesn't fail fast, didn't for me anyway. how much code out there would break if you changed the existing returned value on x86? On Wednesday, 8 July 2020 18:37:03 UTC+1, Kurtis Rader wrote: > > > The result of what you're doing is undefined. You might as well be > executing the HCF instruction. See > https://stackoverflow.com/questions/10366485/problems-casting-nan-floats-to-int > for > one reasonably good discussion. You absolutely have to special-case NaN if > it can be an input to your code. You should not assume it will be converted > to a particular int value. > > -- > 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/a15d1ee7-361e-42f5-9ece-fb8209f0a93co%40googlegroups.com.
Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
On Wed, Jul 8, 2020 at 10:09 AM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > summary: > > converting to int from NaN results in arch dependent values. > ... > i see that NaN isn't really defined as an int, so any returned value isn't > 'incorrect', but shouldn't the value returned be consistent across > architectures? these end-of-range values play fine with my algorithm but 0 > doesn't. > > i've fixed by special-casing NaN values. (may end up using a build flag.) > The result of what you're doing is undefined. You might as well be executing the HCF instruction. See https://stackoverflow.com/questions/10366485/problems-casting-nan-floats-to-int for one reasonably good discussion. You absolutely have to special-case NaN if it can be an input to your code. You should not assume it will be converted to a particular int value. -- 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_wLW7F%3DF_BiUgdTLTGF_7uMsWp%2B%2BH03bYFGgY5NVa9%2Bg%40mail.gmail.com.
[go-nuts] error: Authentication Site
Hello friends,
I need to authenticate to a PHP application running on the Apache server.
Authentication type: Basic. I'm trying this code, but I get the
unauthorized user.
func
username = ""
passwd = "*"
myurl = "http://aplicacao:8085/;
client := {}
req, err := http.NewRequest("GET", myurl, nil)
req.Header.Add("Www-Authenticate", "Basic realm= ")
req.Header.Add("Authorization", "Restricted")
req.SetBasicAuth(username, passwd)
// req.BasicAuth(
resp, err := client.Do(req)
if err != nil {
log.Println("ERRO: ", err)
}
log.Println("RESP: ", resp)
defer resp.Body.Close()
bodyText, err := ioutil.ReadAll(resp.Body)
log.Println("BODY: ", string(bodyText))
I get the error:
2020/07/08 11:58:38 RESP: &{401 Unauthorized 401 HTTP/1.0 1 0
map[Content-Length:[139] Content-Type:[text/html] Server:[Aplicacao]
Www-Authenticate:[Basic realm="Aplicacao"]] 0xc000186080 139 [] true false
map[] 0xc00012c000 } 2020/07/08 11:58:38 BODY: 401
UnauthorizedYou need a password to access this
page!Home
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/24f66d37-75b7-4548-8050-7862a15dcd9bo%40googlegroups.com.
[go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)
summary: converting to int from NaN results in arch dependent values. use case: i'm using ints (scaled) for a type where this is the real underlying meaning. but to avoid rounding issues in intermediate comp, i convert to float for these, and then back. this seemed fine. but for a particular use i increased the resolution of my scaled int from int32 to int64. and the arm code broke! (the amd64 didn't) what i find is this; int32(NaN) returns math.MinInt32 on both amd64 and armv7(32bit) int64(NaN) returns math.MinInt64 on amd64 but ZERO on armv7(32bit) i see that NaN isn't really defined as an int, so any returned value isn't 'incorrect', but shouldn't the value returned be consistent across architectures? these end-of-range values play fine with my algorithm but 0 doesn't. i've fixed by special-casing NaN values. (may end up using a build flag.) extra info: int32(NaN) and int64(NaN) both return 0 on armv5 -- 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/4a5912d8-62bb-4ba3-bf47-7d00dc0fc9c8o%40googlegroups.com.
[go-nuts] Re: gopls performance question
To follow up, I did submit an issue and it is related to a bug in gopls: https://github.com/golang/vscode-go/issues/299 -- 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/9fe795e4-d5e8-47ba-9bfd-9043da61e3d7o%40googlegroups.com.
Re: [go-nuts] Clean shutdown when blocked on I/O
Cool, thanks. One thing I also need to unblock is the Listen loop. Unfortunately, net.Listener doesn't have a SetDeadline call, so I'll just have to Close it anyway. -- 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/45f43f2b-c5bc-46b6-b19e-526d2ef3ff67o%40googlegroups.com.
Re: [go-nuts] Clean shutdown when blocked on I/O
Indeed, servers are easier, and if all you're looking to do is to issue a
cancellation signal which immediately closes every active connection, the
code you posted is perfectly adequate.
I don't expect calling SetDeadline to ever cause a panic, regardless of the
state of the connection.
On Wed, Jul 8, 2020 at 1:43 PM Brian Candler wrote:
> On Wednesday, 8 July 2020 11:17:56 UTC+1, Andrei Tudor Călin wrote:
>>
>> I think this works for some cases, but it is potentially wasteful (and
>> even leaky) in terms of resource usage.
>>
>> For example, if ctx is context.Background(), it leaks a goroutine for
>> every connection
>>
>
> If this is a network server, that's easily fixed: you make a new ctx for
> each connection (derived from the main one), and cancel it just before the
> connection is closed. I think it's useful anyway to have a context which
> covers the lifetime of that connection.
>
> > It also keeps the additional goroutine around for the entire lifetime
> of the connection.
>
> Goroutines are cheap.
>
> How about the following?
>
> type Deadliner interface {
> SetDeadline(t time.Time) error
> }
>
> func addContext(ctx context.Context, d Deadliner) {
> go func() {
> <-ctx.Done()
> d.SetDeadline(time.Now())
> }()
> }
>
> func handleConnection(ctx context.Context, conn net.Conn) {
> ctx, cancel := context.WithCancel(ctx)
> defer cancel()
> addContext(ctx, conn)
>
> ... rest of code goes here
> }
>
> That seems pretty clean to me. My only concern is there's a possibility
> of calling SetDeadline on an already-closed connection, and whether that
> would cause a panic.
>
>> --
> 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/aa0eaf7a-27a8-4dc0-a6d7-245317cc4187o%40googlegroups.com
>
> .
>
--
Andrei Călin
--
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/CANnvmN7Lk0qO2L-D1e9nj0zK9LZjs2mjbR8cFLcVEHkU_otoMw%40mail.gmail.com.
Re: [go-nuts] Clean shutdown when blocked on I/O
On Wednesday, 8 July 2020 11:17:56 UTC+1, Andrei Tudor Călin wrote:
>
> I think this works for some cases, but it is potentially wasteful (and
> even leaky) in terms of resource usage.
>
> For example, if ctx is context.Background(), it leaks a goroutine for
> every connection
>
If this is a network server, that's easily fixed: you make a new ctx for
each connection (derived from the main one), and cancel it just before the
connection is closed. I think it's useful anyway to have a context which
covers the lifetime of that connection.
> It also keeps the additional goroutine around for the entire lifetime of
the connection.
Goroutines are cheap.
How about the following?
type Deadliner interface {
SetDeadline(t time.Time) error
}
func addContext(ctx context.Context, d Deadliner) {
go func() {
<-ctx.Done()
d.SetDeadline(time.Now())
}()
}
func handleConnection(ctx context.Context, conn net.Conn) {
ctx, cancel := context.WithCancel(ctx)
defer cancel()
addContext(ctx, conn)
... rest of code goes here
}
That seems pretty clean to me. My only concern is there's a possibility of
calling SetDeadline on an already-closed connection, and whether that would
cause a panic.
>
--
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/aa0eaf7a-27a8-4dc0-a6d7-245317cc4187o%40googlegroups.com.
Re: [go-nuts] Clean shutdown when blocked on I/O
I think this works for some cases, but it is potentially wasteful (and even
leaky) in terms of resource usage.
For example, if ctx is context.Background(), it leaks a goroutine for every
connection. It also keeps the additional goroutine around for the entire
lifetime of the connection. I'd like to present a more involved, but more
robust and precise approach: https://play.golang.org/p/OgsE3erjJTK
I have not tested the code on anything real, but I hope it's correct, and
that it helps. You might not need the entire machinery, but maybe other
readers of this thread do.
On Wed, Jul 8, 2020 at 11:45 AM Brian Candler wrote:
> Thank you, that was what I was looking for. I had forgotten about
> deadlines, and I didn't realise that you could change a deadline even while
> a read was in progress.
>
> In case it's helpful to anyone, here's a proof-of-concept. It doesn't
> work on play.golang.org because of the network communication.
>
> package main
>
> import (
> "context"
> "fmt"
> "io"
> "net"
> "os"
> "time"
> )
>
> type ConnWithContext struct {
> net.Conn
> Ctx context.Context
> }
>
> func NewConnWithContext(ctx context.Context, conn net.Conn)
> *ConnWithContext {
> go func() {
> <-ctx.Done()
> conn.SetDeadline(time.Now())
> }()
> return {
> Conn: conn,
> Ctx: ctx,
> }
> }
>
> func (c *ConnWithContext) Read(b []byte) (n int, err error) {
> return c.Conn.Read(b)
> }
>
> func main() {
> ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
> defer cancel()
>
> conn, err := net.Dial("tcp", "smtp.gmail.com:25")
> if err != nil {
> fmt.Println(err)
> return
> }
> cwc := NewConnWithContext(ctx, conn)
> n, err := io.Copy(os.Stdout, cwc)
> fmt.Println(n, err)
> cwc.Close()
> }
>
> --
> 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/c7d926b1-7b05-47a0-9eb3-f0e1533b81a6o%40googlegroups.com
>
> .
>
--
Andrei Călin
--
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/CANnvmN4ycskVCsSxtqDJC%2Bzb8STLnH4EeyWRoqOq14QDwPeG%2Bw%40mail.gmail.com.
Re: [go-nuts] Clean shutdown when blocked on I/O
Thank you, that was what I was looking for. I had forgotten about
deadlines, and I didn't realise that you could change a deadline even while
a read was in progress.
In case it's helpful to anyone, here's a proof-of-concept. It doesn't work
on play.golang.org because of the network communication.
package main
import (
"context"
"fmt"
"io"
"net"
"os"
"time"
)
type ConnWithContext struct {
net.Conn
Ctx context.Context
}
func NewConnWithContext(ctx context.Context, conn net.Conn)
*ConnWithContext {
go func() {
<-ctx.Done()
conn.SetDeadline(time.Now())
}()
return {
Conn: conn,
Ctx: ctx,
}
}
func (c *ConnWithContext) Read(b []byte) (n int, err error) {
return c.Conn.Read(b)
}
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
conn, err := net.Dial("tcp", "smtp.gmail.com:25")
if err != nil {
fmt.Println(err)
return
}
cwc := NewConnWithContext(ctx, conn)
n, err := io.Copy(os.Stdout, cwc)
fmt.Println(n, err)
cwc.Close()
}
--
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/c7d926b1-7b05-47a0-9eb3-f0e1533b81a6o%40googlegroups.com.
Re: [go-nuts] pure function on golang
On Mon, Jul 6, 2020 at 6:46 PM wrote: > > to my understanding, a pure function is a function that doesn't have a > side effect, so we can limit pure function to: > - unable to call non-pure function > - unable to modify a variable that is not declared on current function > (like a global variable) > > You also need an additional property, namely that the function always returns the same output for a given input. That is, it is a "stable" relation from inputs to outputs. Consider e.g. https://play.golang.org/p/XI4IgfiLoub where we read a global variable as part of the function body. You could make this into an escaping variable in a closure if you want something more local, but the global will serve the same purpose. There are many variants of this scheme, for instance by reading on a channel as part of the function body, and having that channel fed random values, etc. Marking an expression as pure is a nominal type of language construction. Go usually prefers structural language constructions in most places, so I don't think it fits into the language design as a whole. -- 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/CAGrdgiUj339ySGiG5L2aE7jrV4OfhDr%2BW73%2B%2B4w49VG%2BrLFUNw%40mail.gmail.com.
Re: [go-nuts] [generics] Issues with identifying the matched predeclared type
On Wed, 8 Jul 2020 at 00:33, Steven Blenkinsop wrote:
> On Tue, Jul 7, 2020 at 10:44 AM, roger peppe wrote:
>
>>
>> In my description, there's no assumption that doing it over the type
>> parameter implies a refinement of the previously set type constraints. In
>> fact it definitely implies otherwise because (for example) if you know that
>> a generic type parameter has the known type "string", then it's a loosening
>> rather than a tightening of the constraint - you can now do more things
>> with values of that type than you could previously.
>>
>
> I think this is speaking at cross purposes. The identity of the type is
> more constrained (it must be string as opposed to any other type
> satisfying a particular interface), but you can do more with it in your
> generic code. You're refining the constraint on the identity of the type
> while at the same time expanding its capabilities. An unconstrained type
> parameter can be any type but supports the fewest operations.
>
Fair point.
>
> I don't think it's sufficient. Consider this program:
>> https://go2goplay.golang.org/p/wO0JHIuHH2l. If "string" matches both
>> "myString" and "string" itself, then the type checker would allow the
>> assignment of a function of type "func(string) uint64" to a function of
>> type "func(myString) uint64" with no explicit type conversion, which breaks
>> an important safety constraint in the language. Worse, if we let an
>> interface type match any concrete type that happens to implement that
>> interface, then there's a serious issue because those types probably don't
>> have the same shape, so can't be used interchangeably. For example, this
>> program would be valid, but isn't possible to compile because io.Stringer
>> and string have different representations:
>> https://go2goplay.golang.org/p/_uLjQxb-z-b
>>
>
> I would think that in the second case, the assignment to xx wouldn't type
> check because T is only known to implement io.Stringer rather than being
> identical to io.Stringer.
>
That depends on the semantics of the type switch. In my suggestion, it
would type check because the case would only be chosen if the argument type
is *exactly* that type (but the xx slice wouldn't be assigned to). You'd
need to add a "type" qualifier to match on any type that implements
io.Stringer.
Perhaps this would be more clear if it was written as
>
> type switch {
> case T io.Stringer:
> // Code here can treat the type parameter T
> // as though the generic type list defining
> // it was `(type T io.Stringer)`
> }
>
That's another interesting syntax. I'm not sure whether there's any
particular advantage in mentioning the type parameter in each case,
although I guess it does mean that the syntax for multiple matches is
straightforward and can allow an "any" match.
type switch {
case T1 string, T2 string:
case T1 []byte, T2 string:
case T1 string:
}
If my syntax were to support multiple type parameters, that might look like
switch T1, T2 {
case (string, string):
case ([]byte, string):
case (string, type interface{}):
}
One could define _ to be a synonym for "type interface{}", I guess.
Of course, this wouldn't allow you to write either of your examples. But
> then, your stringHash example could be written using:
>
> func stringHash(type S interface{type string})(s S) uint64 {
> return 1
> }
>
That doesn't seem ideal to me. There are many potentially useful
non-generic functions out there and I think it would be nice to be able to
use them in this way.
>
> https://go2goplay.golang.org/p/FAaqnFalYCL
>
> I think the key tension with allowing you to match on the specific type
> passed in is that, if you actually need to do this, then that means your
> function can't handle certain type parameters which are permitted by its
> signature, i.e. it's not total over its type parameter domain.
>
ISTM that technically the function is still total over the type parameter
domain (assuming you don't panic in the default case) - it just has
different behaviour depending on the type parameters, which is exactly what
the type switch is for. Also, you can *already* do this in a slightly more
limited way, by converting to interface{} and type switching on that,
although that's restrictive because it doesn't allow you to assign back to
generic values - the types aren't unified - which is why we're talking
about this feature here.
> If interfaces allowed you to restrict the type parameters passed in to the
> specific ones you can handle, then you would necessarily also be able to
> handle each specific case by matching on interface satisfaction as well.
>
I'd hope that most people using type switches for specialisation would
include a generic fallback for unknown types. The main use cases I see for
it are optimisation and preserving backward compatibility.
cheers,
rog.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
