[go-nuts] [ANN] CBOR Library - Small, safe, and easy CBOR encoding and decoding (for WebAuthn, etc.) in Go

[Faye Amacker]

Hello,

fxamacker/cbor  is my first open source 
project, after working exclusively on closed source.

It is MIT licensed and designed to be:

   - Easy -- idiomatic Go API (like encoding/json).
   - Safe and reliable -- no unsafe pkg, test coverage at ~90%, fuzz tested 
   , and uses RFC 7049 test vectors.
   - Standards-compliant -- supports RFC 7049 and canonical CBOR encodings 
   (both RFC 7049 and CTAP2). 
   - Small and self-contained -- pkg compiles to under 0.5 MB with no 
   external dependencies.
   
This library balances compiled size, safety (no unsafe pkg) and speed (
benchmarks 
). 

Program size comparison (linux_amd64, Go 1.12) doing the same CBOR encoding 
and decoding:

   - 2.7 MB program using fxamacker/cbor
   - 11.9 MB program using ugorji/go
   
Library size comparison (linux_amd64, Go 1.12):

   - 0.45 MB pkg -- fxamacker/cbor
   - 2.9 MB pkg -- ugorji/go without code generation (go install --tags 
   "notfastpath")
   - 5.7 MB pkg -- ugorji/go with code generation (default)
   
I'm using this library in a new WebAuthn library which I hope to announce 
later.

Any suggestions or feedback would be appreciated.

Thanks,

Faye

-- 
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/f413680f-63ed-4300-b615-3b81bbc6de8d%40googlegroups.com.

[go-nuts] How Gmail API refreshes token?

[Grigorii Tkachuk]

I'm looking into this example 
https://github.com/gsuitedevs/go-samples/blob/master/gmail/quickstart/quickstart.go
 and 
I do not understand why it refreshes "token.json". On line 45 we are 
passing token itself but not a path to token file. I went thru a 
documentation and source code but I do not understand how it works. My goal 
to put service which interacts with gmail api inside k8s cluster and I'm 
searching a way to pass and store token using k8s secrets but in the first 
of all I want to understand how it works with files. 

-- 
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/d3d55244-5d75-464a-86af-8ce5a4eaa09b%40googlegroups.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

['Axel Wagner' via golang-nuts]

On Sun, Sep 8, 2019, 17:14 changkun  wrote:

> Intuitively, the close statement should happens-before select statement
> that starts choosing which case
> should be executing, and select a closed channel with the highest priority
> to prevent another receive case being executed once more.
>

I don't really understand.ehat you mean by "intuitively" here. First: The
close *does* happen-before the case clause of the select for the closed
channel, as per the memory model. Second: If you actually establish an
ordering "close happens-before the select statement, which happens-before
the ticker firing", you should actually get the result you want, in that
only the close-case is deterministically chosen, AIUI. So we are only
talking about the case you tried to enforce, where you *don't* have that
ordering - that is, where the close happens concurrently with the ticker
firing and both happen concurrently to the select starting to execute.

Now, ISTM that the simplest intuitive interpretation of what "event A and B
happen concurrently" (defined abstractly as "are not ordered in the
happens-before partial order) is that the order that A and B happen in real
time in is unclear and could happen either way olin practice. And under
that intuitive understanding, I don't know how you conclude that the select
should prioritize either or not execute the ticker case at all. After all -
you can never know whether the ticker *has actually fired* at the concrete
real point in time the select executed.

Note, by the way, that the fact that you observe either result doesn't
actually say anything about the pseudo-randomness or lack thereof of the
select statement: You can't, from the output of the program, distinguish
between "both cases where ready to proceed and select flipped a coin coming
up close" from "only close was ready to proceed, because select executed in
between the closing/firing" (and the same for the timer firing). The
pseudo-randomness of select is irrelevant for your case, it's the fact that
these events are concurrent, both as specified and IMO as intuitively
obvious.


> My questions are:
> Does the Go team or anybody else think of this memory order before? What
> was the decision that didn't make it?
> If not, is it worth to be defined within the language? There are no
> language changes and only affects the runtime implementation.
>
>
>
> --
> 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/6992b605-ff10-4659-8016-dd96066d4588%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/CAEkBMfEFW0ZRs7HRvX4MNe7YYMmj%2BBYskoviQAhkZHMJf%3D0S2w%40mail.gmail.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[Robert Engels]

Heh, didn’t know that and independently came up with it in 30 secs - that has 
to be worth something ? (Although mine uses sampling of all event sources)

> On Sep 8, 2019, at 4:19 PM, burak serdar  wrote:
> 
>> On Sun, Sep 8, 2019 at 3:16 PM Robert Engels  wrote:
>> 
>> It’s hard to respond. I have done a lot of concurrent programming and 
>> haven’t heard the term “vector clock” so I am not sure what you
> 
> Lamport's timestamps, vector clocks,etc:
> https://en.wikipedia.org/wiki/Vector_clock
> 
> are referring to.  You can write a logical “clock cycle” by sampling
> both and choosing the higher priority event - but overall performance
> is going to suffer greatly.
>> 
>> There is not such thing as “priority” across multiple resources that are 
>> independent - by definition the order is undefined as nothing is 
>> instantaneous in practice. Happens before is going to be per channel - but 
>> in practice the memory flush is going to occur in either case (because of 
>> the backing locks) but it’s not guaranteed.
>> 
>> On Sep 8, 2019, at 10:53 AM, changkun  wrote:
>> 
>> Hi Kurtis,
>> 
>> I am aware that you are talking about the happen-before algorithm which is 
>> basically the vector clock.
>> 
>> However, this discussion aims for the discussion regarding this proposal:
>> 
>> "the close statement should happens-before select statement that starts 
>> choosing which case
>> should be executing, and select a closed channel with the highest priority 
>> to prevent another receive case being executed once more."
>> 
>> We are not entering write any code before we confirm that it is worthy.
>> 
>>> On Sunday, September 8, 2019 at 5:46:43 PM UTC+2, Kurtis Rader wrote:
>>> 
 On Sun, Sep 8, 2019 at 8:40 AM changkun  wrote:
 
 The provided code snipped on my machine can result in different outputs, 
 which basically shows that it could occur in any order.
>>> 
>>> 
>>> Yes
>>> 
 
 The randomization mechanism in select statement made the verification 
 hard. Logically, my argument is rigorous
>>> 
>>> 
>>> No, it isn't. You need to learn a lot more about concurrency and race 
>>> conditions.
>>> 
>>> --
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>> 
>> --
>> 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/d1c412e6-c775-49a6-8d1d-c417497dc9be%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/297D58C7-04D4-4F6C-A6F2-62131724B071%40ix.netcom.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/AC6427E8-84E6-4718-BCB1-E6BF75D9344C%40ix.netcom.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[burak serdar]

On Sun, Sep 8, 2019 at 3:16 PM Robert Engels  wrote:
>
> It’s hard to respond. I have done a lot of concurrent programming and haven’t 
> heard the term “vector clock” so I am not sure what you

Lamport's timestamps, vector clocks,etc:
https://en.wikipedia.org/wiki/Vector_clock

are referring to.  You can write a logical “clock cycle” by sampling
both and choosing the higher priority event - but overall performance
is going to suffer greatly.
>
> There is not such thing as “priority” across multiple resources that are 
> independent - by definition the order is undefined as nothing is 
> instantaneous in practice. Happens before is going to be per channel - but in 
> practice the memory flush is going to occur in either case (because of the 
> backing locks) but it’s not guaranteed.
>
> On Sep 8, 2019, at 10:53 AM, changkun  wrote:
>
> Hi Kurtis,
>
> I am aware that you are talking about the happen-before algorithm which is 
> basically the vector clock.
>
> However, this discussion aims for the discussion regarding this proposal:
>
> "the close statement should happens-before select statement that starts 
> choosing which case
> should be executing, and select a closed channel with the highest priority to 
> prevent another receive case being executed once more."
>
> We are not entering write any code before we confirm that it is worthy.
>
> On Sunday, September 8, 2019 at 5:46:43 PM UTC+2, Kurtis Rader wrote:
>>
>> On Sun, Sep 8, 2019 at 8:40 AM changkun  wrote:
>>>
>>> The provided code snipped on my machine can result in different outputs, 
>>> which basically shows that it could occur in any order.
>>
>>
>> Yes
>>
>>>
>>> The randomization mechanism in select statement made the verification hard. 
>>> Logically, my argument is rigorous
>>
>>
>> No, it isn't. You need to learn a lot more about concurrency and race 
>> conditions.
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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/d1c412e6-c775-49a6-8d1d-c417497dc9be%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/297D58C7-04D4-4F6C-A6F2-62131724B071%40ix.netcom.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/CAMV2Rqqkr_ey2x6buP1aisVarkV1Wve5Vvw1fH-oKV27%2BJu11w%40mail.gmail.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[Robert Engels]

It’s hard to respond. I have done a lot of concurrent programming and haven’t 
heard the term “vector clock” so I am not sure what you are referring to.  You 
can write a logical “clock cycle” by sampling both and choosing the higher 
priority event - but overall performance is going to suffer greatly. 

There is not such thing as “priority” across multiple resources that are 
independent - by definition the order is undefined as nothing is instantaneous 
in practice. Happens before is going to be per channel - but in practice the 
memory flush is going to occur in either case (because of the backing locks) 
but it’s not guaranteed. 

> On Sep 8, 2019, at 10:53 AM, changkun  wrote:
> 
> Hi Kurtis,
> 
> I am aware that you are talking about the happen-before algorithm which is 
> basically the vector clock.
> 
> However, this discussion aims for the discussion regarding this proposal:
> 
> "the close statement should happens-before select statement that starts 
> choosing which case 
> should be executing, and select a closed channel with the highest priority to 
> prevent another receive case being executed once more."
> 
> We are not entering write any code before we confirm that it is worthy.
> 
>> On Sunday, September 8, 2019 at 5:46:43 PM UTC+2, Kurtis Rader wrote:
>>> On Sun, Sep 8, 2019 at 8:40 AM changkun  wrote:
>> 
>>> The provided code snipped on my machine can result in different outputs, 
>>> which basically shows that it could occur in any order.
>> 
>> Yes
>>  
>>> The randomization mechanism in select statement made the verification hard. 
>>> Logically, my argument is rigorous
>> 
>> No, it isn't. You need to learn a lot more about concurrency and race 
>> conditions.
>> 
>> -- 
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
> 
> -- 
> 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/d1c412e6-c775-49a6-8d1d-c417497dc9be%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/297D58C7-04D4-4F6C-A6F2-62131724B071%40ix.netcom.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[changkun]

Hi Kurtis,

I am aware that you are talking about the happen-before algorithm which is 
basically the vector clock.

However, this discussion aims for the discussion regarding this proposal:

"the close statement should happens-before select statement that starts 
choosing which case 
should be executing, and select a closed channel with the highest priority 
to prevent another receive case being executed once more."

We are not entering write any code before we confirm that it is worthy.

On Sunday, September 8, 2019 at 5:46:43 PM UTC+2, Kurtis Rader wrote:
>
> On Sun, Sep 8, 2019 at 8:40 AM changkun > 
> wrote:
>
>> The provided code snipped on my machine can result in different outputs, 
>> which basically shows that it could occur in any order.
>>
>
> Yes
>  
>
>> The randomization mechanism in select statement made the verification 
>> hard. Logically, my argument is rigorous
>>
>
> No, it isn't. You need to learn a lot more about concurrency and race 
> conditions.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/d1c412e6-c775-49a6-8d1d-c417497dc9be%40googlegroups.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[Kurtis Rader]

On Sun, Sep 8, 2019 at 8:40 AM changkun  wrote:

> The provided code snipped on my machine can result in different outputs,
> which basically shows that it could occur in any order.
>

Yes


> The randomization mechanism in select statement made the verification
> hard. Logically, my argument is rigorous
>

No, it isn't. You need to learn a lot more about concurrency and race
conditions.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD8R%3DiTxgHOtDARv6CwptiSqj5VgON%3DC%2B0q4dVB-1n_VgQ%40mail.gmail.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[changkun]

Hi Robert,

The provided code snipped on my machine can result in different outputs, 
which basically shows that it could occur in any order.

The randomization mechanism in select statement made the verification hard. 
Logically, my argument is rigorous


On Sunday, September 8, 2019 at 5:31:49 PM UTC+2, robert engels wrote:
>
> You need to code it knowing that either can occur in any order.
>
> On Sep 8, 2019, at 10:14 AM, changkun > 
> wrote:
>
> Hi, golang nuts,
>
> Let's think about this snippet: https://play.golang.org/p/3cNGho3gWTG
>
> In the code snippet, a ticker is activating and another that that is 
> closing, it seems that they can happen concurrently and result 
> in two different outcomes: either ticker case being executed first or the 
> other way around.
> It is because of the pseudo-randomization of the select statement.
>
> Intuitively, the close statement should happens-before select statement 
> that starts choosing which case 
> should be executing, and select a closed channel with the highest priority 
> to prevent another receive case being executed once more.
>
> My questions are:
> Does the Go team or anybody else think of this memory order before? What 
> was the decision that didn't make it?
> If not, is it worth to be defined within the language? There are no 
> language changes and only affects the runtime implementation.
>
>
>
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/6992b605-ff10-4659-8016-dd96066d4588%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/5beab5a7-56c6-45bb-a8f7-2aaa9ba7ac5c%40googlegroups.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[robert engels]

You need to code it knowing that either can occur in any order.

> On Sep 8, 2019, at 10:14 AM, changkun  wrote:
> 
> Hi, golang nuts,
> 
> Let's think about this snippet: https://play.golang.org/p/3cNGho3gWTG
> 
> In the code snippet, a ticker is activating and another that that is closing, 
> it seems that they can happen concurrently and result 
> in two different outcomes: either ticker case being executed first or the 
> other way around.
> It is because of the pseudo-randomization of the select statement.
> 
> Intuitively, the close statement should happens-before select statement that 
> starts choosing which case 
> should be executing, and select a closed channel with the highest priority to 
> prevent another receive case being executed once more.
> 
> My questions are:
> Does the Go team or anybody else think of this memory order before? What was 
> the decision that didn't make it?
> If not, is it worth to be defined within the language? There are no language 
> changes and only affects the runtime implementation.
> 
> 
> 
> 
> -- 
> 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/6992b605-ff10-4659-8016-dd96066d4588%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/254CA3F1-CBFA-4766-88D8-E317007BB61B%40ix.netcom.com.

[go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[changkun]

Hi, golang nuts,

Let's think about this snippet: https://play.golang.org/p/3cNGho3gWTG

In the code snippet, a ticker is activating and another that that is 
closing, it seems that they can happen concurrently and result 
in two different outcomes: either ticker case being executed first or the 
other way around.
It is because of the pseudo-randomization of the select statement.

Intuitively, the close statement should happens-before select statement 
that starts choosing which case 
should be executing, and select a closed channel with the highest priority 
to prevent another receive case being executed once more.

My questions are:
Does the Go team or anybody else think of this memory order before? What 
was the decision that didn't make it?
If not, is it worth to be defined within the language? There are no 
language changes and only affects the runtime implementation.



-- 
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/6992b605-ff10-4659-8016-dd96066d4588%40googlegroups.com.

[go-nuts] Re: Go 1.13 is released

[stefan via golang-nuts]

Please release 1.13.1 to fix the "xerrors" breakage: 
https://github.com/golang/go/issues/32246

On Tuesday, September 3, 2019 at 9:16:53 PM UTC+2, Dmitri Shuralyov wrote:
>
> Hello gophers, 
>
> We just released Go 1.13. 
>
> You can read the announcement blog post here: 
> https://blog.golang.org/go1.13 
>
> You can download binary and source distributions from our download page: 
> https://golang.org/dl/ 
>
> To compile from source using a Git clone, update to the release with 
> "git checkout go1.13" and build as usual. 
>
> To find out what has changed in Go 1.13, read the release notes: 
> https://golang.org/doc/go1.13 
>
> Thanks to everyone who contributed to the release! 
>
> Cheers, 
> 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/2f47b65d-6c0b-49b3-b6e3-6b63551a2272%40googlegroups.com.