Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[David Riley]

On Feb 18, 2020, at 9:15 PM, Wojciech S. Czarnecki  wrote:
> 
> [1] use marker relative to the opening brace hinting at the desired comment
> position, ie. compute type-start position relative to the opening brace then
> comment-start position relative to the marker from the comment of the brace
> line. Adjust both positions modulo 8 rounded up. Field name that gets over
> past the established type-start position stays over.

If I'm understanding what's proposed here, I think I like it.  The other option 
would be a wider fixed tab stop, but no one is ever going to agree on what that 
should be (but it worked for Fortran 77, I guess).


- Dave

-- 
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/15D2D587-2593-447D-B81B-B485F58F3255%40gmail.com.

Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[andrey mirtchovski]

?w=1 is an option.

On Tue, Feb 18, 2020 at 7:16 PM Wojciech S. Czarnecki  wrote:
>
> Dnia 2020-02-18, o godz. 10:16:57
> Manlio Perillo  napisał(a):
>
> > Here is an example of a diff with a lot of noise, where the actual change
> > is very hard to see:
> > https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd
> >
> > Note that using `git diff -w` is not a solution, since it can only be used
> > locally.  The full diff will be shown by github and friends.
>
> Yes. It could be easily fixed with cosmetic changes to gofmt in a way that
> is tab-width neutral [1] but I doubt it would be seriously considered given
> current NIH-driven mood of dev's hive.
>
> [1] use marker relative to the opening brace hinting at the desired comment
> position, ie. compute type-start position relative to the opening brace then
> comment-start position relative to the marker from the comment of the brace
> line. Adjust both positions modulo 8 rounded up. Field name that gets over
> past the established type-start position stays over.
>
> Done.
>
> Everything, except overlong names, lines up on the screen with ts=2, ts=3, 
> ts=4
> as well as with ts=8. Changesets contain no whitespace changes, because there
> is no such gofmt introduced changes anymore — ofc unless you change type
> identifier past the rounded 8 boundary. Then whole struct will make to the
> changeset, not just huge parts of it.
>
> Hope this helps,
>
> > Manlio
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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/20200219031558.77411fc7%40xmint.

-- 
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/CAK4xykUszUOJYGxv2WGxUegnY6eHR-tEcYbgqMkLJiXBknxx0w%40mail.gmail.com.

Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[Wojciech S. Czarnecki]

Dnia 2020-02-18, o godz. 10:16:57
Manlio Perillo  napisał(a):

> Here is an example of a diff with a lot of noise, where the actual change 
> is very hard to see:
> https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd
> 
> Note that using `git diff -w` is not a solution, since it can only be used 
> locally.  The full diff will be shown by github and friends.

Yes. It could be easily fixed with cosmetic changes to gofmt in a way that
is tab-width neutral [1] but I doubt it would be seriously considered given
current NIH-driven mood of dev's hive.

[1] use marker relative to the opening brace hinting at the desired comment
position, ie. compute type-start position relative to the opening brace then
comment-start position relative to the marker from the comment of the brace
line. Adjust both positions modulo 8 rounded up. Field name that gets over
past the established type-start position stays over.

Done. 

Everything, except overlong names, lines up on the screen with ts=2, ts=3, ts=4 
as well as with ts=8. Changesets contain no whitespace changes, because there
is no such gofmt introduced changes anymore — ofc unless you change type
identifier past the rounded 8 boundary. Then whole struct will make to the
changeset, not just huge parts of it.

Hope this helps,

> Manlio

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200219031558.77411fc7%40xmint.

[go-nuts] [security] golang.org/x/crypto/ssh fix pre-announcement

[Filippo Valsorda]

Hello gophers,

We plan to issue a security fix for the golang.org/x/crypto/ssh package
in the golang.org/x/crypto module on Thursday, February 20th.

Cheers,
Filippo for the Go team

-- 
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%2B2K_Kox3xkjj6gWkp%3DY6fmp7sO4T%2BbgudjjZZ%3Duwgp476pmEw%40mail.gmail.com.

Re: [go-nuts] Linux, unix.Capset, and runtime.LockOSThread

[Caleb Spare]

Thanks for the reply.

On Fri, Feb 14, 2020 at 8:33 PM Ian Lance Taylor  wrote:
>
> On Thu, Feb 13, 2020 at 1:14 PM Caleb Spare  wrote:
> >
> > Hi! I have a Linux-specific question about capabilities, threads, and 
> > syscalls.
> >
> > I have a Go program which runs other programs with specific
> > capabilities set. It basically does the following:
> >
> > cmd := exec.Command(...)
> > runtime.LockOSThread()
> > unix.RawSyscall(unix.CAPSET, ...)
> > cmd.Start()
> >
> > Empirically, it seems to work well, having run in production for several 
> > years.
> >
> > I wrote it this way because, from my reading of capabilities
> > documentation, capset only affects the current thread, so it's
> > important that we use the same OS thread for running the capset
> > syscall as the fork. I also used RawSyscall (rather than Syscall) for
> > this reason.
> >
> > I noticed that more recently the x/sys/unix package added Capget and
> > Capset which use Syscall rather than RawSyscall. Thinking about it
> > more now, ISTM that using Syscall is fine, and that LockOSThread is
> > all I need to ensure that the thread with the raised capabilities is
> > the one that runs the fork. Is that correct?
>
> Yes.
>
> The difference between Syscall and RawSyscall is that the latter does
> not inform the scheduler that it is entering the kernel, and therefore
> using RawSyscall will break your program if the system call blocks.
> There is no difference between Syscall and RawSyscall with regard to
> the behavior of LockOSThread.
>
>
> > Relatedly, how does one definitively know whether a syscall is
> > nonblocking? AFAICT setcap and getcap shouldn't block. Why does unix
> > use Syscall for Capset/Capget but RawSyscall for calls like Getpgid?
>
> It's possible that this is a performance bug.  I don't know of any
> reason why Capset/Capget might block.

Okay, I can send a CL for that.

>
> 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/CAGeFq%2B%3DXMT-t2eCw69MV10tjj2AqUNNMeyEEPa_b%2B%2BES-xUtWg%40mail.gmail.com.

Re: [go-nuts] Why isn't there strings.reverse("str") function?

[howardcshaw]

My most common use case for reversing strings has not come up in Go yet - 
basically, some languages provide a string search function that finds a 
character or substring starting from the beginning of the string. For 
example, in T-SQL, CharIndex. If they do not provide a corresponding search 
that works from the end towards the beginning, then removing something at 
the end of the string involves either searching to exhaustion then backing 
up to the last found index - this is easy in an imperative language like Go 
but trickier in a set-based language like SQL - or cheating by reversing 
the string, performing the search and modification, and reversing it again.

UPDATE Addresses SET Zip = SUBSTRING(Addr,LEN(Addr)-CHARINDEX(' 
',REVERSE(Addr))+2,99)

Another use-case involves zero-filling a number to right align it (again in 
SQL) and ensure a proper field-size: 
REVERSE(SUBSTRING(REVERSE('' + UPC),1,12))

These are janky solutions that only work because I know the data being 
operated on is ASCII and just save doing some fiddly math instead. 

I guess this is neatly reflected by the fact that I only managed to find 
examples when I was searching the folder where I did my data conversions 
for customers - a search in the actual code found no instances.

I have not needed it in Go code so far.


-- 
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/81d73b9b-a234-460a-a415-fb828b692dc9%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jake Montgomery]

>
> The problem with that reasoning is that you could use it for anything and 
> then we would never improve any programming language or create others. 
> Ideally, the compiler will catch all the bugs it possibly can so that the 
> programmer can spend the thinking energy on resolving the problem. 
>
 
That is a good point. However, in reality, creating a language is about 
trade offs. There may be a place for a language that does not allow nil 
pointers, but it is a trade off that the designers of go decided not to 
make. 
 

>  
>>
>> I'd say that's not solving the problem, but making it bigger. Do not 
>> recover from nil panics, instead fix the nil dereference bug and avoid 
>> the panic completely. 
>>
>
> It is never that easy in a medium to big application with a 10+ people 
> team working on it. 
>

I have to agree with Jan here, that is a bad idea. If you have a bug, it 
has to be fixed, not covered up. It may not always be "that easy", but it 
is always necessary.  And if you are finding it to be consistently 
difficult to find and fix nil dereference bugs, then you probably have a 
problem with your culture or code design that really is not about Go at 
all. 

I have worked on large go projects with many developers, and frankly nil 
pointer dereference was not a significant source of bugs. If it is for your 
team, then maybe you need to look at the bigger picture. There are a number 
of things you can do, both technically and culturally to reduce this. Some 
general ideas are below. You may be already be doing some or all of these 
...

   - On the team level, I would start with the fact that you have 10+ 
   people on a team. If you actually have 10 programmers all working on the 
   same code, then IMHO, you are bound to fail. Break the code up into 
   separate projects with clearly defined boundaries, so you can have smaller 
   teams responsible for their own code. 
   - Null pointer references are often going to be the result of poor 
   detail design. (More about the technical thing you can do later). I have 
   found that thorough code reviews of all commits are invaluable. At least 
   one senior engineer should be on every code review, and preferably every 
   team member will at least look at the commit, and the code review comments. 
   This seems like a big burden, and it is, but it pays off many fold. There 
   will be fewer bugs, better overall design, and better low level design, 
   like function signatures and documentation that help prevent these 
   problems. But most importantly, everyone learns from everyone else, and 
   code consistency and hygiene continually increases. My experience is that 
   bugs like null pointer defer will be reduced or disappear.
   - Of course, the item above relies on each team having one or more 
   talented programmers to lead the way. And there are simply some folks who 
   are incompetent, and will never write reliable code. But even "middle of 
   the road" programmers can write reliable code in go, with the proper 
   culture and guidance. 
   - Your code should have enough high level tests, so that the code is 
   thoroughly exercised before going into production. Most nil dereference 
   bugs should show up there. 
   
Technically, there are some things that will help with null pointers. This 
is where the code reviews come in, to create a culture of good practices. A 
few are ...

   - To start, don't use pointers without a justification. The default 
   should always be to pass around objects by reference, not pointers. If a 
   structure needs to contain another, maybe include it directly, instead of 
   using a pointer, etc. Some developers will automatically use pointers "for 
   efficiency", but in most cases there is no benefit, or at least not 
   significant enough to warrant the premature optimization. Of course, there 
   are places where pointers are necessary. 
   - If a structure must contain a pointer, and the code is not going to be 
   written to allow it to be nil, then document that in the structure, and 
   create a "New" function that *must* be used to create instances of the 
   structure.
   - Any function that takes a pointer should be aware that it could be 
   nil. If nil is not allowed, then be sure to indicate that in the function 
   documentation. If the nil is passed it should panic early. That may mean 
   putting a nil check, and panic at the function start, but in practice that 
   is rarely actually needed.
   
For example, Go could have perfectly followed the same approach as C for 
> the arrays: rely on the user to pass the length everywhere and forget about 
> protecting against out-of-bounds accesses. The designers decided not to do 
> so, and thanks to that, you can forget about memory corruption and focus on 
> what matters.
>
 
Yes and no. You may not have to worry about "memory corruption", but you 
still need to worry about accessing out of bonds on a slice, just like C. 
Otherwise you get a 

[go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[Manlio Perillo]

On Wednesday, January 29, 2020 at 6:56:35 PM UTC+1, Manlio Perillo wrote:
>
> This is a proposal for the next version Go.
>
> Currently gofmt formats struct fields to make the field name and type 
> aligned.
> However this may cause extra changes in a commit diff when one field is 
> added or removed.
>
>
Here is an example of a diff with a lot of noise, where the actual change 
is very hard to see:
https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd

Note that using `git diff -w` is not a solution, since it can only be used 
locally.  The full diff will be shown by github and friends.

> [...]


Manlio

-- 
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/949e9bc8-0c85-4f6a-a4b1-5e25b3f8ab83%40googlegroups.com.

Re: [go-nuts] Re: What are finalizers missing?

[Robert Engels]

You should always use an explicit Close() - a Close() performed by a finalizer should only be use to simplify the case of a shared resource that would typically involve manual reference counting (which is very susceptible to bugs - especially in a concurrent environment).If you have a highly concurrent environment with lots of shared files (enough to run out of resources), you probably need explicit resource management.-Original Message-
From: Tyler Compton 
Sent: Feb 18, 2020 11:29 AM
To: Jake Montgomery 
Cc: golang-nuts 
Subject: Re: [go-nuts] Re: What are finalizers missing?

Good point, I had forgotten about the 2 minute rule the GC has.So it's not a matter of  the go runtime not knowing "which Go objects it can finalize in order to get that [a resource] back", its simply a matter of the variable pace of GC. In theory GC can happen as infrequently as every 2 minutes. So if you are ok with you non-Go resource lingering for that long, then use finalizers. In most cases that is not sufficient though.I think you're touching on the point I'm trying to make. The variable pace of the GC is okay for Go memory, because it can adjust that pace if necessary to keep up with garbage production. The GC can't make pace adjustments based on the consumption of any non-Go-memory resources, which means we can only count on a maximum of 2 minutes between GC runs.I could certainly see situations where there's no way the GC could make a smart enough decision to fit an application's needs, however. For example, if your program writes to a file that another program then uses, you would want to make sure that the file is closed before that other program is spun up. Even a 1 second GC delay might not work here.On Sat, Feb 15, 2020 at 10:52 AM Jake Montgomery  wrote:On Friday, February 14, 2020 at 2:10:01 PM UTC-5, Tyler Compton wrote:The conventional wisdom I see in the Go community is to avoid using finalizers to manage file descriptors, C memory, or any other non-Go memory resource. The generally accepted rationale (at least to my understanding) is that the garbage collector cannot be expected to run the finalizer promptly, and it may never be run at all. This is where I start speculating. I assume this is because the garbage collector has no understanding of C memory, file descriptors, or any other kind of resource. If we're running out of memory due to a malloc in C, there's no way for the garbage collector to know which Go objects it can finalize in order to get that memory back. I don't think your analysis is correct. IIRC, the spec makes no guarantees about finalizers ever actually being run. But in practice they will all be found and run after the first garbage collection after the object becomes unreachable. (Assuming the app continues to run.) So it's not a matter of  the go runtime not knowing "which Go objects it can finalize in order to get that [a resource] back", its simply a matter of the variable pace of GC. In theory GC can happen as infrequently as every 2 minutes. So if you are ok with you non-Go resource lingering for that long, then use finalizers. In most cases that is not sufficient though. One other, minor, consideration, is also that setting a finalizer will cause the object to escape to the heap.



-- 
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/9d2fd31b-f283-4dec-bb38-8cc8cc844249%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/CAA%3DXfu1OF_tBMKXgJKCFU9U_SNvdiKTvg1c%2B9-4KFL7e5jo5bA%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/1347019225.1980.1582049246729%40wamui-fuzz.atl.sa.earthlink.net.

Re: [go-nuts] Re: What are finalizers missing?

[Tyler Compton]

Good point, I had forgotten about the 2 minute rule the GC has.

So it's not a matter of  the go runtime not knowing "which Go objects it
> can finalize in order to get that [a resource] back", its simply a matter
> of the variable pace of GC. In theory GC can happen as infrequently as
> every 2 minutes. So if you are ok with you non-Go resource lingering for
> that long, then use finalizers. In most cases that is not sufficient though.
>

I think you're touching on the point I'm trying to make. The variable pace
of the GC is okay for Go memory, because it can adjust that pace if
necessary to keep up with garbage production. The GC can't make pace
adjustments based on the consumption of any non-Go-memory resources, which
means we can only count on a maximum of 2 minutes between GC runs.

I could certainly see situations where there's no way the GC could make a
smart enough decision to fit an application's needs, however. For example,
if your program writes to a file that another program then uses, you would
want to make sure that the file is closed before that other program is spun
up. Even a 1 second GC delay might not work here.

On Sat, Feb 15, 2020 at 10:52 AM Jake Montgomery  wrote:

> On Friday, February 14, 2020 at 2:10:01 PM UTC-5, Tyler Compton wrote:
>>
>> The conventional wisdom I see in the Go community is to avoid using
>> finalizers to manage file descriptors, C memory, or any other non-Go memory
>> resource. The generally accepted rationale (at least to my understanding)
>> is that the garbage collector cannot be expected to run the finalizer
>> promptly, and it may never be run at all.
>>
>>
>
>> This is where I start speculating. I assume this is because the garbage
>> collector has no understanding of C memory, file descriptors, or any other
>> kind of resource. If we're running out of memory due to a malloc in C,
>> there's no way for the garbage collector to know which Go objects it can
>> finalize in order to get that memory back.
>>
>
> I don't think your analysis is correct. IIRC, the spec makes no guarantees
> about finalizers ever actually being run. But in practice they will all be
> found and run after the first garbage collection after the object becomes
> unreachable. (Assuming the app continues to run.) So it's not a matter of
> the go runtime not knowing "which Go objects it can finalize in order to
> get that [a resource] back", its simply a matter of the variable pace of
> GC. In theory GC can happen as infrequently as every 2 minutes. So if you
> are ok with you non-Go resource lingering for that long, then use
> finalizers. In most cases that is not sufficient though.
>
> One other, minor, consideration, is also that setting a finalizer will
> cause the object to escape to the heap.
>
> --
> 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/9d2fd31b-f283-4dec-bb38-8cc8cc844249%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/CAA%3DXfu1OF_tBMKXgJKCFU9U_SNvdiKTvg1c%2B9-4KFL7e5jo5bA%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Robert Engels]

Code that is subject to null dereferences, it also susceptible to any incorrect dereference - (e.g. look up in a map using the the wrong key (not just type)) - the program may not crash, but produce incorrect results - which is arguably worse.There is no silver bullet to solve bad dereferences.-Original Message-
From: kloste...@gmail.com
Sent: Feb 18, 2020 9:55 AM
To: golang-nuts 
Subject: Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

I'd say that's not solving the problem, but making it bigger. Do not recover from nil panics, instead fix the nil dereference bug and avoid the panic completely. It is never that easy in a medium to big application with a 10+ people team working on it. The problem with that reasoning is that you could use it for anything and then we would never improve any programming language or create others. Ideally, the compiler will catch all the bugs it possibly can so that the programmer can spend the thinking energy on resolving the problem. For example, Go could have perfectly followed the same approach as C for the arrays: rely on the user to pass the length everywhere and forget about protecting against out-of-bounds accesses. The designers decided not to do so, and thanks to that, you can forget about memory corruption and focus on what matters.They could have thought: "Hey, fix all the memory corruption bugs and you will not have those problems". But that's something really hard to accomplish.I would love to be able to forget about nil-pointer dereference errors. Sure! I can add checks everywhere, but this means I need to think about this, and that is precious energy that doesn't go to solving the problem I really want to solve.Being said this, I know it is not an easy problem to solve and there are always trade-offs. But, hey!, maybe there is a good solution hidden somewhere that fits perfectly in Go. Let's find it out!El martes, 18 de febrero de 2020, 12:22:38 (UTC), Jan Mercl  escribió:On Tue, Feb 18, 2020 at 12:44 PM  wrote:

> Well, other languages use the optional/maybe type.

The CPU does not care how humans call the abstraction. It has still to
do the same old thing: check some value for being equal/not equal to a
sentinel value or check a tag value for the same effect. That means
additional cost wrt to memory consumption. Additionally, now the
compiler may enforce the check everywhere when humans may know better.
So it buys more safety, undeniably, but as always, there are no free
lunches.

> The problem with nil-errors struck me hard in Go when I realized that, no matter how many "recovers" I write in my server app, if a goroutine is spawned and hits a nil pointer dereference, the whole server crashes. There is no protection inside the language against this (let me know if there is a way)

I'd say that's not solving the problem, but making it bigger. Do not
recover from nil panics, instead fix the nil dereference bug and avoid
the panic completely.




-- 
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/e6c9b79c-bf3a-413f-8a79-063a3e1da271%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/145256857.1124.1582043369067%40wamui-fuzz.atl.sa.earthlink.net.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[kloster08]

>
> I'd say that's not solving the problem, but making it bigger. Do not 
> recover from nil panics, instead fix the nil dereference bug and avoid 
> the panic completely. 
>

It is never that easy in a medium to big application with a 10+ people team 
working on it. 
The problem with that reasoning is that you could use it for anything and 
then we would never improve any programming language or create others. 
Ideally, the compiler will catch all the bugs it possibly can so that the 
programmer can spend the thinking energy on resolving the problem. 
For example, Go could have perfectly followed the same approach as C for 
the arrays: rely on the user to pass the length everywhere and forget about 
protecting against out-of-bounds accesses. The designers decided not to do 
so, and thanks to that, you can forget about memory corruption and focus on 
what matters.
They could have thought: "Hey, fix all the memory corruption bugs and you 
will not have those problems". But that's something really hard to 
accomplish.

I would love to be able to forget about nil-pointer dereference errors. 
Sure! I can add checks everywhere, but this means I need to think about 
this, and that is precious energy that doesn't go to solving the problem I 
really want to solve.
Being said this, I know it is not an easy problem to solve and there are 
always trade-offs. But, hey!, maybe there is a good solution hidden 
somewhere that fits perfectly in Go. Let's find it out!

El martes, 18 de febrero de 2020, 12:22:38 (UTC), Jan Mercl escribió:
>
> On Tue, Feb 18, 2020 at 12:44 PM > wrote: 
>
> > Well, other languages use the optional/maybe type. 
>
> The CPU does not care how humans call the abstraction. It has still to 
> do the same old thing: check some value for being equal/not equal to a 
> sentinel value or check a tag value for the same effect. That means 
> additional cost wrt to memory consumption. Additionally, now the 
> compiler may enforce the check everywhere when humans may know better. 
> So it buys more safety, undeniably, but as always, there are no free 
> lunches. 
>
> > The problem with nil-errors struck me hard in Go when I realized that, 
> no matter how many "recovers" I write in my server app, if a goroutine is 
> spawned and hits a nil pointer dereference, the whole server crashes. There 
> is no protection inside the language against this (let me know if there is 
> a way) 
>
> I'd say that's not solving the problem, but making it bigger. Do not 
> recover from nil panics, instead fix the nil dereference bug and avoid 
> the panic completely. 
>

-- 
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/e6c9b79c-bf3a-413f-8a79-063a3e1da271%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Vincent Blanchon]

Yes, definitely, good point.
Both are them are good depending on the case actually.


Le mardi 18 février 2020 16:55:02 UTC+4, Jan Mercl a écrit :
>
> On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon 
> > wrote: 
>
> > However, in real code, I guess we will have that many constants, so it 
> does not make really sense to increase the number. 
>
> Design decisions may be driven by the desire to maximize the 
> performance in the average case or in the worst case scenario. 
>
> That's why Go has a regexp package that's slower in the average case 
> wrt PCRE, but it guarantees linear, not exponential, performance of 
> the worst case. 
>

-- 
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/69db18c0-31a4-4d52-94c6-a168ef815e0a%40googlegroups.com.

[go-nuts] Re: Proposal: Implement an interface based on function signature if method name is ambiguous. #37280

[Jan Mercl]

No need for a language change: https://play.golang.org/p/l7Cvf2fKzx4

-- 
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/CAA40n-WWkfdxQ77wVocD-rs9zYp-6oXB1oOe%3DuyamgWBa5GR3A%40mail.gmail.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon
 wrote:

> However, in real code, I guess we will have that many constants, so it does 
> not make really sense to increase the number.

Design decisions may be driven by the desire to maximize the
performance in the average case or in the worst case scenario.

That's why Go has a regexp package that's slower in the average case
wrt PCRE, but it guarantees linear, not exponential, performance of
the worst case.

-- 
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/CAA40n-V8hcW5V-mJN8eALozxkUPD7mRuHBSkR%3DyrA1Yh0G7PZQ%40mail.gmail.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Vincent Blanchon]

With 100 constants:

Stringer-4 4.96ns ± 0%

StringerWithSwitch-4   4.99ns ± 1%

StringerWithMap-4 30.40ns ± 0%


The gap between the switch and the current implement is much smaller. I 
guess it is due to the number of JMP instructions the code has to go 
through.
It confirms that the results before was accurate. I guess if I increase the 
number of constant, the current implementation will become faster.
However, in real code, I guess we will have that many constants, so it does 
not make really sense to increase the number.

It does not explain why this choice of design^^
The only thing I can see is the binary size... it is slightly bigger with 
the switch and 100 constants.


Le mardi 18 février 2020 14:24:55 UTC+4, pierr...@gmail.com a écrit :
>
>
> I did not add it since it was not the original question ^^
>> But why can't we have the check and a switch?
>>
>>
> Definitely can. Just didnt see it. My response was somewhat tangential to 
> your question, sry. 
>

-- 
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/9fa488e0-73ae-49fc-9a01-f60f7ebc6cfb%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jesper Louis Andersen]

On Tue, Feb 18, 2020 at 1:22 PM Jan Mercl <0xj...@gmail.com> wrote:

>
> The CPU does not care how humans call the abstraction. It has still to
> do the same old thing: check some value for being equal/not equal to a
> sentinel value or check a tag value for the same effect. That means
> additional cost wrt to memory consumption. Additionally, now the
> compiler may enforce the check everywhere when humans may know better.
> So it buys more safety, undeniably, but as always, there are no free
> lunches.
>
>
This is the reason I prefer to unwrap option types as much as possible in
program flows. You avoid a lot of checks which the programmer has to write.
And the compiler can be dead sure things cannot be null, so it doesn't have
to insert a check. But it often requires you to think hard about your data
representation. After a while, you can write down a type in e.g., Haskell,
Rust, or OCaml and immediately have a feel for how the program flow will
be. This allows you to abort certain representations early because you know
they'll be a mess to work with.

I think the best example that is similar I can give is that you can have a
JSON structure with some RFC3339 date in it. In Go, you could pass that
around in your program as a string, but it quickly becomes a mess. If you,
on the other hand, convert that into a value of type time.Time, you
immediately gain all of Go's stdlib tooling for manipulating time, and a
lot of corner cases are eliminated. You simply chose a better
representation. Null values follow the same scheme are not something
special that needs special handling. In fact, they are just a special case
of a variant/sum type.

-- 
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/CAGrdgiXxTa9J6G-1T9YFptJr-xH_1Mpdr8ukMOkyX_bnbgYWkA%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jesper Louis Andersen]

If you have

type 'a option = None | Some 'a

you have a so-called "lift" where "None"  is a new value playing the role
as no-information or "null". This allows you use the full range of 'a
whatever that is, because you glued a new null-value to it.

However, the problem you may face is that a lot of programming *do* need a
null value. So you end up having to handle these values quite a lot in your
program. Of course, as you grow better at detecting this, you seek to
untangle an option type early on in your program flow such that you avoid
those pesky null checks, and case/switch/match splits in the program. But
there are data out there for which this is hard to do correctly. Also for
the fact that the rest of the world is littered with data representations
in which null occurs all over the place.

The option type is theoretically stronger because the programmer can choose
when they need a nullable value and when they don't. It is usually easier
to add something (i.e., a null) than it is to remove it. This means it
carries more information to be exploited by the compiler and users of the
type. In practice, the world has miserable handling of data, and we spend a
considerable amount of time trying to get it pristine for use in our
programs. Thus, the value diminishes somewhat. However, if you manage to
carve out a small bubble in which you have absolute control over the data,
you are definitely in for a treat.


On Tue, Feb 18, 2020 at 12:58 PM Volker Dobler 
wrote:

> On Tuesday, 18 February 2020 12:44:16 UTC+1, klos...@gmail.com wrote:
>>
>> Well, other languages use the optional/maybe type. It handles sentinel
>> values pretty well and I don't think they bring new kind of bugs (while
>> they remove the nil-pointer related bugs).
>>
>
> That is the market claim. And typically for such claims it does not hold
> up.
>
> V.
>
> --
> 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/7199346c-36c8-46ba-97d3-d3ceec6632c1%40googlegroups.com
> 
> .
>


-- 
J.

-- 
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/CAGrdgiVJk0%3D_PnWHAny0TPLgbT%3D52_Td_wZiJRoQm3KmfLEgCA%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jan Mercl]

On Tue, Feb 18, 2020 at 12:44 PM  wrote:

> Well, other languages use the optional/maybe type.

The CPU does not care how humans call the abstraction. It has still to
do the same old thing: check some value for being equal/not equal to a
sentinel value or check a tag value for the same effect. That means
additional cost wrt to memory consumption. Additionally, now the
compiler may enforce the check everywhere when humans may know better.
So it buys more safety, undeniably, but as always, there are no free
lunches.

> The problem with nil-errors struck me hard in Go when I realized that, no 
> matter how many "recovers" I write in my server app, if a goroutine is 
> spawned and hits a nil pointer dereference, the whole server crashes. There 
> is no protection inside the language against this (let me know if there is a 
> way)

I'd say that's not solving the problem, but making it bigger. Do not
recover from nil panics, instead fix the nil dereference bug and avoid
the panic completely.

-- 
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/CAA40n-XVWcKk7-zN-5A%3DKTjA2LO7gyhv%2B63%2BB4Ftv1Ssih3NtA%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jesper Louis Andersen]

On Mon, Feb 17, 2020 at 10:11 PM Rick Hudson  wrote:

> > type Treenode struct {
> >  left *Treenode
> >  right *Treenode
> > }
>
> One could of course design a language where Treenode is called cons and
> left is called car and right is called cdr and (car nil) is nil and (cdr
> nil) is nil. You could implement such a language by putting 2 words of 0
> at location 0 and add a write barrier or page protection to enforce nil
> immutable.
>
>
Roughly also what happens in e.g., OCaml. If you define

type 'a tree = Leaf | Node of 'a * 'a tree * 'a tree

then the variant is represented with leaf being the integer 0 and node
being a box with integer tag 1. If we follow that up with

type x = Foo | Bar

then Foo has tag 0 and Bar has tag 1, reusing the tag counters. The type
system ensures we cannot accidentally use something of type x in lieu of 'a
tree and vice versa.

The important part is that the representation is somewhat hidden from us as
programmers. The system decides upon one, and uses it consistently. It is
one of the defining characteristics of Go that this won't happen in the
language (where representations are often quite explicit and chosen by the
programmer. This comes with certain advantages in that the memory layout is
known).

As for hash tables in OCaml, they have no "nil" representation and are
plain old structs. I guess this leans much the same way as the Go
representation.

-- 
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/CAGrdgiW0RuO3oUSOd41HzGHB5kQzAu29d-7AngbGNEsjCs4DaQ%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Volker Dobler]

On Tuesday, 18 February 2020 12:44:16 UTC+1, klos...@gmail.com wrote:
>
> Well, other languages use the optional/maybe type. It handles sentinel 
> values pretty well and I don't think they bring new kind of bugs (while 
> they remove the nil-pointer related bugs). 
>

That is the market claim. And typically for such claims it does not hold up.

V.

-- 
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/7199346c-36c8-46ba-97d3-d3ceec6632c1%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[kloster08]

Well, other languages use the optional/maybe type. It handles sentinel 
values pretty well and I don't think they bring new kind of bugs (while 
they remove the nil-pointer related bugs). 
It is true that they can be a bit cumbersome to use and maybe we lose what 
you said: *"the nice and cheap HW support for detecting of using the 
sentinel value on most CPUs"*

However, I normally lean a bit more towards program correctness than to 
speed of execution, nice compiler code, or HW support. Others might have 
different preferences.

The problem with nil-errors struck me hard in Go when I realized that, no 
matter how many "recovers" I write in my server app, if a goroutine is 
spawned and hits a nil pointer dereference, the whole server crashes. There 
is no protection inside the language against this (let me know if there is 
a way)

So here I am trying to gather as much information as possible to see if, 
first, more people are in a similar situation as me, and second, learn 
about the design decisions regarding this topic so that I might be able to 
come up with a proposal that makes sense for the current state of Go.

El martes, 18 de febrero de 2020, 11:20:21 (UTC), Jan Mercl escribió:
>
> On Tue, Feb 18, 2020 at 12:09 PM > wrote: 
> > 
> > Regarding pointers: For me, point number 2 (and 3) is the key that 
> forces us having some way of expressing emptiness in a pointer. 
>
> I'd say that nil pointers are not really special. It's just a sentinel 
> value. And we definitely need some sentinel value to mark the end of a 
> linked list, for example. If a language gets rid of nil/null 
> sentinels, it has to chose some other sentinel value for marking the 
> .next field as not being actually a next item in the list. So it does 
> not really solve much, if anything at all. And it enables completely 
> new bugs to exists in exchange for avoiding the nil/null pointer 
> dereference exception. Additionally it loses the nice and cheap HW 
> support for detecting of using the sentinel value on most CPUs. 
>

-- 
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/65406cc2-e932-4b42-adc1-b05107f86fb2%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jan Mercl]

On Tue, Feb 18, 2020 at 12:09 PM  wrote:
>
> Regarding pointers: For me, point number 2 (and 3) is the key that forces us 
> having some way of expressing emptiness in a pointer.

I'd say that nil pointers are not really special. It's just a sentinel
value. And we definitely need some sentinel value to mark the end of a
linked list, for example. If a language gets rid of nil/null
sentinels, it has to chose some other sentinel value for marking the
.next field as not being actually a next item in the list. So it does
not really solve much, if anything at all. And it enables completely
new bugs to exists in exchange for avoiding the nil/null pointer
dereference exception. Additionally it loses the nice and cheap HW
support for detecting of using the sentinel value on most CPUs.

-- 
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/CAA40n-WGNk5_QOzR75-AjQ65QU4Pn%3Dr9ixxSLHjcu5B7jwNQSQ%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[kloster08]

Thanks for the example, it is a really good one. At least for me, it is the 
first one where I see the real usefulness.

I don't know why, but eventually, I was able to see the parallelism between 
maps and slices. All the confusion comes because we have "append" for 
slices and not for maps (because of semantics). "append" handles the 
nil-case for us, while for maps we always have to handle the nil-case 
ourselves.

El lunes, 17 de febrero de 2020, 14:07:11 (UTC), Axel Wagner escribió:
>
> On Mon, Feb 17, 2020 at 11:18 AM > wrote:
>
>> Out of curiosity: Could you please tell when calling methods on nil 
>> pointers is useful?
>>
>
> In general, linked datastructures - like linked lists or trees. As a 
> somewhat trivial example, consider this:
> https://play.golang.org/p/Y-4aSVLzEFO
> Interpreting a nil-pointer as "an empty tree" makes a lot of the 
> traversal-algorithms easier to express.
> I also have an internal package that wraps the openat/mkdirat/linkat/… 
> class of syscalls, to make it possible to still read/write a directory that 
> has been bind-mounted over. It uses a struct to encapsulate the 
> file-descriptor of that directory, which is used as a pointer to keep track 
> of whether it has been closed and such. It also interprets a nil-pointer as 
> "relative to the current directory" (it uses AT_FDCWD). I could, of course, 
> also use the zero-value of that struct for that (in fact, I do as well), 
> but as there is a meaningful way to interpret a nil-pointer, there's no 
> harm in doing so as well.
>
> In general, it's of course never *necessary* to interpret a nil-pointer a 
> specific way. But it does sometimes make things easier to express or nicer 
> to use.
>
> BTW, as far as slices are concerned: They behave strikingly similar to 
> maps, as far as the zero-value is concerned - in that all read-operations 
> work just fine on both a nil-map and a nil-slice, it's just that 
> write-operations panic (and again, in both cases). The main difference 
> between them is that *non*-nil maps behave very differently. We don't tend 
> to notice the "uselessness" of nil-slices in general, though, because we 
> tend to either assume a certain size for them (in which case they can't be 
> nil) or we check the length beforehand (just like checking if a map is nil) 
> when writing to them. i.e. the read-operations are far more common with 
> slices and we find the idea of "checking" their nil-ness via ranging over 
> them or explicitly checking their len somewhat more natural.
>

-- 
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/8823d367-135c-4ce4-90e3-82ece5128bd6%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[kloster08]

Regarding pointers: For me, point number 2 (and 3) is the key that forces 
us having some way of expressing emptiness in a pointer. I would say that 
point 1 could be optimized by the compiler
Regarding interfaces: Yep! nil-interfaces are a different beast. That's the 
reason I focused on just one nillable type (pointers) this time and, 
especially, left nil-interfaces away.

El lunes, 17 de febrero de 2020, 13:40:36 (UTC), Brian Candler escribió:
>
> A "usable" nil map, i.e. being able to insert into it straight away, I 
> sympathise with.  Remember though that you can't append "in place" to a nil 
> slice: it returns a new slice object.  
> https://play.golang.org/p/dL-r74C5m_w
>
> I presume you don't want to write the same for maps as you do for slices:
>
> m2 := m.set(42, "hello")   // instead of: m[42] = "hello"
>
> I suppose in principle it might be possible to pre-initialize all 
> variables and structs which contain a map to a dynamically-allocated 
> instance of that map type.
>
> However, I don't think the idea extends to pointers:
>
> 1. you are asking for all pointers to be pre-initialized to some 
> dynamically-generated object, which might need to be garbage-collected 
> immediately the pointer is changed to point to something else.  That would 
> be very wasteful.
>
> 2. there's the problem with self-referential pointers, e.g. A contains *B 
> and B contains *A.
>
> 3. you lose the "nil-ness" property of pointers: the ability of pointers 
> to point to nothing at all (such as the tree example I gave).  If you could 
> no longer point to nothing, how could you tell the difference between an 
> interior node and a leaf node of a tree?  You would have to change all code 
> to use, say, a slice of pointers (of size 0 or 1) instead of a pointer.
>
> Finally, what would you do about nil interface variables? You don't even 
> know what *type* the value should have.
>
>>

-- 
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/b32bd59b-d3ed-41ff-a804-f36d5a0bf5b0%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 11:10 AM Vincent Blanchon
 wrote:

> @Jan Thank you for the feedback. I will try with a higher number of 
> constants. By the way, my benchmark tries all the path:
>
> func BenchmarkStringerWithSwitch(b *testing.B) {
>for i := 0; i < b.N ; i++  {
>   p := Pill(i%20)
>   _ = p.String()
>}
> }

That's IMO a very good approach. However, there's one potential trap.
The `_ = f()` thing may, or may not, get optimized away completely,
depending on the particular compiler and its version, if the compiler
can prove the called function is side effects free. The usual
workaround is, for example, to actually assign the returned value to a
package level variable _and_ read it afterwards. Like in

foo = p.String()
..

and later, just before returning

if foo == "" { // Assuming none of the string represenations are ""
b.Fatal()
}

-- 
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/CAA40n-XYxgR_D8XAtFX6JEd4%2BLAiTQumYxPZxdzH3vcVd1wi%3DQ%40mail.gmail.com.

Re: [go-nuts] Re: stringer command and generated String() function

[pierre . curto]

> I did not add it since it was not the original question ^^
> But why can't we have the check and a switch?
>
>
Definitely can. Just didnt see it. My response was somewhat tangential to 
your question, sry. 

-- 
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/b3bebee1-8fd3-4c61-ba09-9150f51f6767%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Vincent Blanchon]

@Jan Thank you for the feedback. I will try with a higher number of 
constants. By the way, my benchmark tries all the path:

func BenchmarkStringerWithSwitch(b *testing.B) {
   for i := 0; i < b.N ; i++  {
  p := Pill(i%20)
  _ = p.String()
   }
}

 

> I can't find any compile time check in your code 

 
I did not add it since it was not the original question ^^
But why can't we have the check and a switch?

Here is the code:

package main

import "strconv"

func _() {
   // An "invalid array index" compiler error signifies that the constant 
values have changed.
   // Re-run the stringer command to generate them again.
   var x [1]struct{}
   _ = x[Placebo-0]
   _ = x[Aspirin-1]
   _ = x[Ibuprofen-2]
}

func (i Pill) String() string {
   switch i {
   case 0: return "Placebo"
   case 1: return "Aspirin"
   case 2: return "Ibuprofen"
   case 3: return "Paracetamol"
   default: return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
   }
}





Le mardi 18 février 2020 14:06:14 UTC+4, Jan Mercl a écrit :
>
> On Tue, Feb 18, 2020 at 10:37 AM Vincent Blanchon 
> > wrote: 
>
> > @Jan, yes definitely. By the way, here are some numbers from a benchmark 
> I made with 20 constants: 
> > 
> > name  time/op 
> > Stringer-4 4.16ns ± 2% 
> > 
> > StringerWithSwitch-4   3.81ns ± 1% 
> > 
> > StringerWithMap-4 28.60ns ± 2% 
>
> 20 is a small number. In general, measuring things where one iteration 
> is in single digit nanoseconds can be misleading as discussed earlier. 
> The probably most important thing is how a chosen implementation 
> scales. To measure that, I suggest to make the number of the constants 
> in hundreds, if not thousands and having the loop exercise all the 
> paths, so the branch predictor cannot learn a single, happy one. In 
> any case, it's much safer to shift the time/op to at least 
> microseconds, otherwise the overhead of the test per se becomes 
> comparable to the measured thing and it just adds noise at minimum. 
>
> > @Pierre, the compilation check can also be done if we do not have a 
> slice. In my example with the switch, I still kept the compilation check. 
>
> I can't find any compile time check in your code (the one using the 
> switch) that can detect a constant has changed its value since 
> stringer was run. 
>

-- 
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/ee65758b-274f-4e20-b6ef-7a449b55221b%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 10:37 AM Vincent Blanchon
 wrote:

> @Jan, yes definitely. By the way, here are some numbers from a benchmark I 
> made with 20 constants:
>
> name  time/op
> Stringer-4 4.16ns ± 2%
>
> StringerWithSwitch-4   3.81ns ± 1%
>
> StringerWithMap-4 28.60ns ± 2%

20 is a small number. In general, measuring things where one iteration
is in single digit nanoseconds can be misleading as discussed earlier.
The probably most important thing is how a chosen implementation
scales. To measure that, I suggest to make the number of the constants
in hundreds, if not thousands and having the loop exercise all the
paths, so the branch predictor cannot learn a single, happy one. In
any case, it's much safer to shift the time/op to at least
microseconds, otherwise the overhead of the test per se becomes
comparable to the measured thing and it just adds noise at minimum.

> @Pierre, the compilation check can also be done if we do not have a slice. In 
> my example with the switch, I still kept the compilation check.

I can't find any compile time check in your code (the one using the
switch) that can detect a constant has changed its value since
stringer was run.

-- 
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/CAA40n-WpoLbj9oeAH1nhNv%2BYROSFh1WGFN_5rBC41wnN%2B3aV6w%40mail.gmail.com.

[go-nuts] Re: stringer command and generated String() function

[Vincent Blanchon]

@Brian, this code is generated by the stringer command based on this 
code: https://play.golang.org/p/JNfRC5TZYlo
@Jan, yes definitely. By the way, here are some numbers from a benchmark I 
made with 20 constants:

name  time/op
Stringer-4 4.16ns ± 2%

StringerWithSwitch-4   3.81ns ± 1%

StringerWithMap-4 28.60ns ± 2%


Map is definitely the slowest one.

@Pierre, the compilation check can also be done if we do not have a slice. 
In my example with the switch, I still kept the compilation check. This 
check just use the constants, no relation with the "String()" function.


Le mardi 18 février 2020 13:20:01 UTC+4, pierr...@gmail.com a écrit :
>
> The const/slice implementation should be faster as Jan said.
>
> Note that there is also a blank function that fails at compile time if 
> items have been added or changed and stringer has not been rerun since.
> The const/slice implementation allows for that (useful!) check.
>
>
> Le mardi 18 février 2020 07:42:41 UTC+1, Vincent Blanchon a écrit :
>>
>> Hello,
>>
>> I was wondering why the stringer command has been implemented that way:
>>
>> const _Pill_name = "PlaceboAspirinIbuprofen"
>>
>> var _Pill_index = [...]uint8{0, 7, 14, 23}
>>
>> func (i Pill) String() string {
>>if i < 0 || i >= Pill(len(_Pill_index)-1) {
>>   return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>>}
>>return _Pill_name[_Pill_index[i]:_Pill_index[i+1]]
>> }
>>
>>
>>
>> When it could be simpler and faster with a simple enum:
>>
>> func (i Pill) String() string {
>>switch i {
>>case 0: return "Placebo"
>>case 1: return "Aspirin"
>>case 2: return "Ibuprofen"
>>case 3: return "Paracetamol"
>>default: return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>>}
>> }
>>
>>
>> After running a benchmark with a higher number of values (20), the enum 
>> is always faster. I also was surprised to see the binary is not bigger 
>> (maybe it will be with more values).
>>
>> Does someone know what advantages the current design brings?
>>
>

-- 
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/e99ed426-a5ff-4582-9e6a-89143812ee46%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Brian Candler]

On Tuesday, 18 February 2020 09:04:49 UTC, Jan Mercl wrote:
>
> > A simpler and faster way again would be to use a map. 
> > https://play.golang.org/p/ntjhesMsSA9 
>
> I don't see how could be map lookup possibly faster than slice 
> indexing. Have you some measurements to share? 
>
>
No, I didn't measure it - I'll let the OP do that.  I still say it is 
simpler though.

-- 
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/d81def72-cfec-4afb-9b0d-93a2c3614f03%40googlegroups.com.

[go-nuts] Re: stringer command and generated String() function

[pierre . curto]

The const/slice implementation should be faster as Jan said.

Note that there is also a blank function that fails at compile time if 
items have been added or changed and stringer has not been rerun since.
The const/slice implementation allows for that (useful!) check.


Le mardi 18 février 2020 07:42:41 UTC+1, Vincent Blanchon a écrit :
>
> Hello,
>
> I was wondering why the stringer command has been implemented that way:
>
> const _Pill_name = "PlaceboAspirinIbuprofen"
>
> var _Pill_index = [...]uint8{0, 7, 14, 23}
>
> func (i Pill) String() string {
>if i < 0 || i >= Pill(len(_Pill_index)-1) {
>   return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>}
>return _Pill_name[_Pill_index[i]:_Pill_index[i+1]]
> }
>
>
>
> When it could be simpler and faster with a simple enum:
>
> func (i Pill) String() string {
>switch i {
>case 0: return "Placebo"
>case 1: return "Aspirin"
>case 2: return "Ibuprofen"
>case 3: return "Paracetamol"
>default: return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>}
> }
>
>
> After running a benchmark with a higher number of values (20), the enum is 
> always faster. I also was surprised to see the binary is not bigger (maybe 
> it will be with more values).
>
> Does someone know what advantages the current design brings?
>

-- 
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/bff0982a-a80b-4153-b316-1576f65700c5%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 9:47 AM Brian Candler  wrote:
>
> Could you provide a link to where you found this code?  I imagine it was done 
> that way just for demonstrating some features of go, such as slicing and 
> array lookups.
>
> A simpler and faster way again would be to use a map.
> https://play.golang.org/p/ntjhesMsSA9

I don't see how could be map lookup possibly faster than slice
indexing. Have you some measurements to share?

Same applies to using the switch as suggested by Vincent.

In both cases, the branch predictor and or speculative execution in
modern CPUs, can completely mislead measuring small cases.

-- 
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/CAA40n-Uf5Xa_24SYU39mGr07fjufYTti5nCDRRakd4LAMhc8ZA%40mail.gmail.com.

[go-nuts] Re: stringer command and generated String() function

[Brian Candler]

Or, indeed, an array of strings.
https://play.golang.org/p/3Eg9va4Krqo

-- 
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/3aa5feee-9271-43d5-a5d2-7bcebadd4b06%40googlegroups.com.

[go-nuts] Re: stringer command and generated String() function

[Brian Candler]

Could you provide a link to where you found this code?  I imagine it was 
done that way just for demonstrating some features of go, such as slicing 
and array lookups.

A simpler and faster way again would be to use a map.
https://play.golang.org/p/ntjhesMsSA9

-- 
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/8baa9dde-1c05-407b-a19b-382b5470b52a%40googlegroups.com.

[go-nuts] Re: Updating golang.org/x/tools

[anderson . queiroz]

I'm no expert on it. However I'd try `GO111MODULE=on go install ...` 
outside a Go module. Anyway ensure you run `GO111MODULE=on go get  ...` 
outside a Go module to get packages to go to your gopath.

On Monday, 17 February 2020 00:59:16 UTC+1, Tong Sun wrote:
>
> Hi, 
>
> My present from golang.org/x/tools is too old to be functioning properly:
>
> $ present
> 2020/02/16 18:13:07 Failed to parse templates: template: slides.tmpl:65: 
> function "pagenum" not defined
>
>
> So I did `go get -v -u golang.org/x/tools` . 
> However, my present is not updated and still giving me above error. 
> (`type present` shows it is at $GOPATH/bin/present).
>
> Wouldn't `go get` will install those binaries automatically? Or, how can I 
> do that? (I had to build & cp manually to make my present working)
>
> Here is full log of my `go get`:
>
> $ go get -v -u golang.org/x/tools
> Fetching https://golang.org/x/tools?go-get=1
> Parsing meta tags from https://golang.org/x/tools?go-get=1 (status code 
> 200)
> get "golang.org/x/tools": found meta tag get.metaImport{Prefix:"
> golang.org/x/tools", VCS:"git", RepoRoot:"
> https://go.googlesource.com/tools"} at https://golang.org/x/tools?go-get=1
> go: finding golang.org/x/tools latest
> Fetching https://golang.org/x/net?go-get=1
> Fetching https://golang.org/x/mod?go-get=1
> Fetching https://golang.org/x/sync?go-get=1
> Fetching https://golang.org/x/xerrors?go-get=1
> Parsing meta tags from https://golang.org/x/net?go-get=1 (status code 200)
> get "golang.org/x/net": found meta tag get.metaImport{Prefix:"
> golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} 
> at https://golang.org/x/net?go-get=1
> Parsing meta tags from https://golang.org/x/mod?go-get=1 (status code 200)
> get "golang.org/x/mod": found meta tag get.metaImport{Prefix:"
> golang.org/x/mod", VCS:"git", RepoRoot:"https://go.googlesource.com/mod"} 
> at https://golang.org/x/mod?go-get=1
> Parsing meta tags from https://golang.org/x/xerrors?go-get=1 (status code 
> 200)
> get "golang.org/x/xerrors": found meta tag get.metaImport{Prefix:"
> golang.org/x/xerrors", VCS:"git", RepoRoot:"
> https://go.googlesource.com/xerrors"} at 
> https://golang.org/x/xerrors?go-get=1
> go: finding golang.org/x/net v0.0.0-20190620200207-3b0461eec859
> go: finding golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898
> Parsing meta tags from https://golang.org/x/sync?go-get=1 (status code 
> 200)
> get "golang.org/x/sync": found meta tag get.metaImport{Prefix:"
> golang.org/x/sync", VCS:"git", RepoRoot:"https://go.googlesource.com/sync"} 
> at https://golang.org/x/sync?go-get=1
> go: finding golang.org/x/sync v0.0.0-20190423024810-112230192c58
> go: finding golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee
> Fetching https://golang.org/x/crypto?go-get=1
> Fetching https://golang.org/x/text?go-get=1
> Fetching https://golang.org/x/sys?go-get=1
> Parsing meta tags from https://golang.org/x/text?go-get=1 (status code 
> 200)
> get "golang.org/x/text": found meta tag get.metaImport{Prefix:"
> golang.org/x/text", VCS:"git", RepoRoot:"https://go.googlesource.com/text"} 
> at https://golang.org/x/text?go-get=1
> Parsing meta tags from https://golang.org/x/sys?go-get=1 (status code 200)
> Parsing meta tags from https://golang.org/x/crypto?go-get=1 (status code 
> 200)
> get "golang.org/x/sys": found meta tag get.metaImport{Prefix:"
> golang.org/x/sys", VCS:"git", RepoRoot:"https://go.googlesource.com/sys"} 
> at https://golang.org/x/sys?go-get=1
> get "golang.org/x/crypto": found meta tag get.metaImport{Prefix:"
> golang.org/x/crypto", VCS:"git", RepoRoot:"
> https://go.googlesource.com/crypto"} at 
> https://golang.org/x/crypto?go-get=1
> go: finding golang.org/x/sync latest
> go: finding golang.org/x/xerrors latest
> go: finding golang.org/x/net latest
> go: finding golang.org/x/sys latest
> go: finding golang.org/x/crypto latest
> go: finding golang.org/x/mod v0.2.0
> go: finding golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550
> go: finding golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e
> go: finding golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7
> go: downloading golang.org/x/tools v0.0.0-20200216192241-b320d3a0f5a2
> go: extracting golang.org/x/tools v0.0.0-20200216192241-b320d3a0f5a2
> Fetching https://golang.org/x?go-get=1
> Parsing meta tags from https://golang.org/x?go-get=1 (status code 200)
> Fetching https://golang.org?go-get=1
> Parsing meta tags from https://golang.org?go-get=1 (status code 200)
>
>
> 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/99c605a3-2f45-4738-a7a0-cad5f113b60f%40googlegroups.com.

[go-nuts] Re: exec.Command() always returns error status of 1 when it was executed successfully

[Brian Candler]

On Tuesday, 18 February 2020 01:40:32 UTC, Dean Schulze wrote:
>
> I expected it to return 0 when executing successfully.  What am I missing?
>

Given your pipeline:

lspci | grep -i vga | grep -i nvidia

the exit status returned is the exit status of the last command (grep -i 
nvidia).  Then if you read "man grep" you'll see that grep exits with 
status 1 if no line matched the expression.

bash also has another mode you can use:

set -o pipefail; lspci | grep -i vga | grep -i nvidia

In this case, the exit status is the first non-zero exit status in the 
pipeline.  This is generally safer, as otherwise a failure earlier in the 
pipeline is masked by the success or failure of the final process.

-- 
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/b5a42920-e006-4285-af2c-badef3ebba15%40googlegroups.com.