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.
>
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
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
@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
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.
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
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
@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%
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
> 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
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)
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
>
> 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
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
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
>
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
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
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
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
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
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.
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
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
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
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.
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
>
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
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
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
>
?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:
> >
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
>
> 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
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
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
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
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
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
37 matches
Mail list logo
