Hi, it seems that the http client automatically performs a DNS lookup when an
existing connection is terminated by the server. I simulated it via changing
the IP address in /etc/hosts.
Can someone point me to the code where this logic is checked?
I am looking at https://golang.org/src/net/http/
Hi all,
Time is complicated.
Today I found myself in a rabbit hole. For some unrelated reason, I got a
time value in a non-UTC location that's otherwise zero (IsZero=true). This
value doesn't seem to survive a roundtrip to JSON. See this playground for
a minimal reproduction: https://play.gola
Is this because the 2-second offset of LMT gets lost in RFC 3339
representation?
On Fri, Nov 27, 2020 at 6:33 PM Robert Ma wrote:
> Hi all,
>
> Time is complicated.
>
> Today I found myself in a rabbit hole. For some unrelated reason, I got a
> time value in a non-UTC location that's otherwise z
On Fri, Nov 27, 2020 at 12:57 PM Daniel Fava wrote:
>
> Does anyone know how the Go memory model came to be? I don't have technical
> questions about it. I just would like to know the historical context.
>
> The model is specified in terms of happens-before, due to Lamport. But the
> followin
Hi,
Does anyone know how the Go memory model came to be? I don't have
technical questions about it. I just would like to know the historical
context.
The model is specified in terms of happens-before, due to Lamport. But the
following rule, which allows channels to be used as locks, was not
Great! I liked Mill's lecture. After having seen it, here's my favourite:
*Clojure core.async*, lecture (45 mins). Rich Hickey discusses the
motivation, design and use of the Clojure core.async library. He also talks
about go. See https://www.infoq.com/presentations/clojure-core-async/
(lecture
This is best solved by syntax highlighting in an editor. Doesn’t do much for b
& w printed training materials - but you can achieve similar results with bold
/ font choice.
> On Nov 27, 2020, at 9:49 AM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
>> On Fri, Nov 27, 2020 at 3:42 PM Yaw Boak
On Fri, Nov 27, 2020 at 3:42 PM Yaw Boakye wrote:
> I disagree on accepting "that generic function signatures are inherently
> more crowded and less readable." I mean, inherently more crowded and less
> readable looks like something that one should apologize for (1) when
> teaching the language,
On potentially introducing backwards incompatible change, good point. I
agree that we shouldn't which means the colon would be optional.
I disagree on accepting "that generic function signatures are inherently
more crowded and less readable." I mean, inherently more crowded and less
readable looks
On Fri, Nov 27, 2020 at 3:14 PM wher...@gmail.com
wrote:
> I'd like to propose that we separate the type and function parameters from
> the return parameters with a colon
>
That would mean that either a) generic and non-generic functions would
differ by a : after the arguments, which seems confu
Thanks, Jan, but the error type in question is 3rd party so can't be
extended with Is() :)
Best,
Arve
On Fri, Nov 27, 2020 at 3:00 PM Jan Mercl <0xj...@gmail.com> wrote:
> On Fri, Nov 27, 2020 at 2:46 PM Arve Knudsen
> wrote:
>
> > I've noticed that errors.Is returns false if you compare two er
Hello,
Consider the code below (taken from the Design Draft and slightly modified):
func ConcatTo[S Stringer, P Plusser](s []S, p []P) (r []string) {
r = make([]string, len(s))
for i, v := range s {
r[i] = p[i].Plus(v.String())
}
return r
}
It becomes immediately obvious that the set
On Fri, Nov 27, 2020 at 2:46 PM Arve Knudsen wrote:
> I've noticed that errors.Is returns false if you compare two error instances
> that are implemented as pointers. I.e., I'm using a struct where the Error
> method has a pointer receiver, and when passing struct instance pointers to
> errors
Actually, never mind about this. I realized in the meantime that I
shouldn't be using `errors.Is` in this case, where I basically want to see
if the error is of a certain type. `errors.As` makes more sense for this
use case.
On Friday, November 27, 2020 at 2:46:36 PM UTC+1 Arve Knudsen wrote:
Hello!
I've noticed that errors.Is returns false if you compare two error
instances that are implemented as pointers. I.e., I'm using a struct where
the Error method has a pointer receiver, and when passing struct instance
pointers to errors.Is, it ends up comparing them by pointer address. Ple
I should add: using channels often means the mutex is not required.
Imagine, for example, that you want a concurrency-safe counter (that
multiple goroutines can read, increment and decrement). You can put the
counter value into a buffered channel:
counter := make(chan int, 1)
counter <- 0
The
On Friday, 27 November 2020 at 10:32:11 UTC oyvin...@teigfam.net wrote:
> Thread safety, concurrency safety, goroutines safety. The same stuff to
> me.
>
> It's important that concurrent goroutines don't interfere with each other
> in such a way that internal state is compromised by other goro
Yeah, NFS would work as well (similar tradeoffs as 9P, though the linux
kernel driver might perform better because it's more widely used).
nbd is not suitable for the use case, I think :) I'd also recommend against
using my nbd package if performance is the goal - it is not at all
optimized, I wro
Thread safety, concurrency safety, goroutines safety. The same stuff to me.
It's important that concurrent goroutines don't interfere with each other
in such a way that internal state is compromised by other goroutines.
Typically through access to internal data, through pointers. If only go
One possibility is to use the 9P client of the kernel and implements a 9P
server in Go - there are a few 9P libraries for Go around.
I doubt it will be more efficient than FUSE though, and btw FUSE is largely
based on the ideas promoted by 9P.
Another possibility is to use the ndb client of the
Hi,
THanks!!
BR
Abraham
On Friday, November 27, 2020 at 11:12:53 AM UTC+2 b.ca...@pobox.com wrote:
> On Friday, 27 November 2020 at 06:14:48 UTC Afriyie Abraham Kwabena wrote:
>
>> What I would like to ask is, using mutex OK and if not the best way of
>> solving it, how can i use
>> channels i
On Friday, 27 November 2020 at 06:14:48 UTC Afriyie Abraham Kwabena wrote:
> What I would like to ask is, using mutex OK and if not the best way of
> solving it, how can i use
> channels in this case.
>
There's nothing wrong with mutex, but you can use channels for a more
native-Go experience.
22 matches
Mail list logo
