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
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
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 shoul
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 ex
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 g
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
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 a
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 rep
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 consta
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 i
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 mec
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 po
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 f
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
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
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 := &http.Client{}
re
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 par
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 ema
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 gro
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, J
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 net
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 t
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 communicat
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
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 othe
25 matches
Mail list logo
