On Fri, Dec 20, 2019 at 5:07 PM Michel Levieux wrote:
>
> I was working on a project and for simplicity reasons I just happened to
> write a lot of useless, effectless conditions.
> What I mean by "useless, effectless condition" is a condition that makes no
> function call, that has no body, and
hi all!
someone knows if ts there a way to customize connection server errors (from
net/http), specially with " func (c *conn) serve(ctx context.Context) "
since I have to register the clients ip and other metadata with handshake
errors and edit the "Client sent an HTTP request to an HTTPS serve
Hi everyone,
I was working on a project and for simplicity reasons I just happened to
write a lot of useless, effectless conditions.
What I mean by "useless, effectless condition" is a condition that makes no
function call, that has no body, and that makes no assignment of any
variable outside the
Actually I realized I can get the behavior I want using log.SetOutput and
glog.InfoDepth(3, ...) + some original log parsing but it'd be nice to have
something built-in in glog.
On Friday, December 20, 2019 at 11:01:52 AM UTC-8, Dmitry Ilyevsky wrote:
>
> Hi All,
>
> I was wondering if something
Hi All,
I was wondering if something like MoveStandardLogTo could be added to
golang/glog package in addition to CopyStandardLogTo that would NOT also
emit redirected log on stderr. Currently when I try to DIY it via
log.SetOutput I get header nesting like so (which is slightly annoying):
I122
To clarify, the `// +build tools` should make the compiler skip building
this file because the "tools" constraint will never be met, but allows go
modules to add it to the dependency list. It just looks like go mod tidy
doesn't like non go repositories.
On Thursday, December 19, 2019 at 10:42:5
Ok, first at all, thanks to all of you for the valuable feedback!!!
So the "untyped"|"typed" comes from the terminology that Go uses
for defining constants, that, in turn, is based on how you write those
constants. If you explicit the type is a typed if not, is untyped.
And, for the sake of explan
Personally, in a classroom context, I'd avoid the term "untyped nil" (or
"typed nil", for that matter) for interface values - specifically *because*
I find it confusing. That is, I would point out that it is sometimes used
that way (so people don't get confused if they hear it), but insist on the
p
It's probably also worth saying that this is a bit more fuzzy with nil than
with other constants, because in some sense every nil interface value,
although having a static type (the interface type) is untyped in the sense
that it doesn't have a dynamic type.
This is a common source of confusion.
