Re: [go-nuts] shadowing of types by variables

[Gorka Guardiola]

Yes, I understood the idea from Brian's explanation. Makes adding new
predeclared names (types, literals...) a compatible change.

Thanks.

On Tue, Jan 17, 2023, 04:03 Ian Lance Taylor  wrote:

> On Mon, Jan 16, 2023 at 5:46 PM 'wagner riffel' via golang-nuts
>  wrote:
> >
> > On 1/13/23 07:20, Gorka Guardiola wrote:
> > > According to the spec it seems like it is legal to shadow a type with a
> > > variable, even a builtin type.
> > > Is there any specific rationale for this? I guess that it makes scoping
> > > checks easier and faster, but still.
> > >
> >
> > I don't think there is any special rationale behind it, in Go builtin
> > types are predefined identifiers, not keywords as usual in other
> > languages, thus those follow rules of identifiers, not keywords.
> > Although it feels astonishing that you can shadow even predefined
> > constants like "true := false", in my experience this haven't shown to
> > be an issue.
>
> There is a rationale: we can add new predeclared identifiers without
> breaking existing working code.
>
> For example, the Go 1.18 release added two new predeclared
> identifiers: `any` and `comparable`.  Because they were predeclared
> identifiers, not keywords, existing code that used them as variable
> names continued to work.
>
> 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/CACm3i_hbKDGq_WObfN1RHp2nC81%2B6QbsudASP7txpnsMT_UEEw%40mail.gmail.com.

[go-nuts] Wait before Add

[Богдан «bodqhrohro» Горбешко]

The documentation explicitly states that it shouldn't be done if the 
WaitGroup counter is zero. Though I have occasionally written a code which 
does it, and it worked for several years, but weirdly, seems like the 
parallel execution of the critical section happens sometimes.

The goroutine has a Wait -> Add(1) -> Done chain. That time I expected it 
won't be started twice simultaneously (it actually seems to be sometimes 
anyway), and if it does, the first call would stay between Add and Done, 
and thus the second call and any other calls would block on Wait until the 
first one reaches Done.

How does it work actually then, did the behaviour change between minor Go 
releases, and how should I have redone it properly if this behaviour is 
discouraged? Actually, I don't even remember why I didn't just use Mutex 
here, probably because I wanted to protect the whole critical section 
between Wait and Done, but only when the code between Add and Done is 
executed (executing the section between Wait and Add in parallel is fine 
and probably even needed sometimes).

-- 
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/a499b92e-2db6-4b02-adf6-e7e69383f28cn%40googlegroups.com.

Re: [go-nuts] shadowing of types by variables

[Ian Lance Taylor]

On Mon, Jan 16, 2023 at 5:46 PM 'wagner riffel' via golang-nuts
 wrote:
>
> On 1/13/23 07:20, Gorka Guardiola wrote:
> > According to the spec it seems like it is legal to shadow a type with a
> > variable, even a builtin type.
> > Is there any specific rationale for this? I guess that it makes scoping
> > checks easier and faster, but still.
> >
>
> I don't think there is any special rationale behind it, in Go builtin
> types are predefined identifiers, not keywords as usual in other
> languages, thus those follow rules of identifiers, not keywords.
> Although it feels astonishing that you can shadow even predefined
> constants like "true := false", in my experience this haven't shown to
> be an issue.

There is a rationale: we can add new predeclared identifiers without
breaking existing working code.

For example, the Go 1.18 release added two new predeclared
identifiers: `any` and `comparable`.  Because they were predeclared
identifiers, not keywords, existing code that used them as variable
names continued to work.

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/CAOyqgcXt%2BJ6_S_ndgGuxL3zqG1sZjnQ5ahvLd0hfPpWjAS_NLg%40mail.gmail.com.

Re: [go-nuts] shadowing of types by variables

['wagner riffel' via golang-nuts]

On 1/13/23 07:20, Gorka Guardiola wrote:
According to the spec it seems like it is legal to shadow a type with a 
variable, even a builtin type.
Is there any specific rationale for this? I guess that it makes scoping 
checks easier and faster, but still.




I don't think there is any special rationale behind it, in Go builtin 
types are predefined identifiers, not keywords as usual in other 
languages, thus those follow rules of identifiers, not keywords. 
Although it feels astonishing that you can shadow even predefined 
constants like "true := false", in my experience this haven't shown to 
be an issue.


-w

--
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/ff5efae5-937e-32dd-608a-8d8ac8d0417b%40104d.net.

Re: [go-nuts] How to understand runtime.gogo?

[Ian Lance Taylor]

On Mon, Jan 16, 2023 at 8:43 AM j2gg0s  wrote:
>
> As a newbie of golang's assembly, i cant understand why we MOVQ DX CX twice 
> in runtime.gogo. WHY?

I don't see any MOVQ DX, CX instructions here.  Can you clarify by
saying exactly which instructions you are asking about?

Note that MOVQ 0(DX), CX treats DX as a memory address, and moves the
8-byte value at that address into CX.  And MOVQ DX, g(CX) treats CX as
a memory address, and moves the value in DX into the address as "g"
bytes offset from the address in CX.

Ian


> Source code:
> ```
>255  // func gogo(buf *gobuf)
>256  // restore state from Gobuf; longjmp
>257  TEXT runtime·gogo(SB), NOSPLIT, $0-8
>258  MOVQbuf+0(FP), BX   // gobuf
>259  MOVQgobuf_g(BX), DX
>260  MOVQ0(DX), CX   // make sure g != nil
>261  JMP gogo<>(SB)
>262
>263  TEXT gogo<>(SB), NOSPLIT, $0
>264  get_tls(CX)
>265  MOVQDX, g(CX)
>266  MOVQDX, R14 // set the g register
>267  MOVQgobuf_sp(BX), SP// restore SP
>268  MOVQgobuf_ret(BX), AX
>269  MOVQgobuf_ctxt(BX), DX
>270  MOVQgobuf_bp(BX), BP
>271  MOVQ$0, gobuf_sp(BX)// clear to help garbage 
> collector
>272  MOVQ$0, gobuf_ret(BX)
>273  MOVQ$0, gobuf_ctxt(BX)
>274  MOVQ$0, gobuf_bp(BX)
>275  MOVQgobuf_pc(BX), BX
>276  JMP BX
> ```
>
> Link: https://github.com/golang/go/blob/go1.17.13/src/runtime/asm_amd64.s#L255
>
>
> --
> 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/5fafeb38-1bc7-4a96-b386-41e14c431273n%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/CAOyqgcXnxR_m0at6JLAMRrXMZH331EO12xM%3Dut9JzX7LF_eJew%40mail.gmail.com.

[go-nuts] How to understand runtime.gogo?

[j2gg0s]

As a newbie of golang's assembly, i cant understand why we MOVQ DX CX twice 
in runtime.gogo. WHY?

Source code:
```
   255  // func gogo(buf *gobuf)
   256  // restore state from Gobuf; longjmp
   257  TEXT runtime·gogo(SB), NOSPLIT, $0-8
   258  MOVQbuf+0(FP), BX   // gobuf
   259  MOVQgobuf_g(BX), DX
   260  MOVQ0(DX), CX   // make sure g != nil
   261  JMP gogo<>(SB)
   262
   263  TEXT gogo<>(SB), NOSPLIT, $0
   264  get_tls(CX)
   265  MOVQDX, g(CX)
   266  MOVQDX, R14 // set the g register
   267  MOVQgobuf_sp(BX), SP// restore SP
   268  MOVQgobuf_ret(BX), AX
   269  MOVQgobuf_ctxt(BX), DX
   270  MOVQgobuf_bp(BX), BP
   271  MOVQ$0, gobuf_sp(BX)// clear to help garbage 
collector
   272  MOVQ$0, gobuf_ret(BX)
   273  MOVQ$0, gobuf_ctxt(BX)
   274  MOVQ$0, gobuf_bp(BX)
   275  MOVQgobuf_pc(BX), BX
   276  JMP BX
```

Link: https://github.com/golang/go/blob/go1.17.13/src/runtime/asm_amd64.s#L255


-- 
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/5fafeb38-1bc7-4a96-b386-41e14c431273n%40googlegroups.com.

Re: [go-nuts] Guaranteeing deterministic execution of Golang code

['Axel Wagner' via golang-nuts]

On Mon, Jan 16, 2023 at 1:27 PM Bakul Shah  wrote:

> I would think the map iteration order is *arbitrary* but deterministic.
> That is, the same set of keys will be iterated the same way every time.
>

If you would think that, you'd be wrong. The iteration order of a map is
unspecified. But gc (the most prevalent Go implementation) explicitly
randomizes it.


> This is not the case with the select statement.
>

Well, that's why I chose that example. Because it makes it easier to talk
about "a definitely non-deterministic program" and "a program who's
determinism is not specified, but is randomized in practice, but you might
argue that in certain circumstances…".

But the point still stands: Thinking about where non-determinism comes
from, let you avoid it, where it matters. "Sorting keys of a map before
output" is just as much a strategy of that as "synchronizing the order of
operations" or "ordering the output". There are different strategies to
achieve deterministic output, with different tradeoffs. And they are worth
thinking about, to me.


>
> On Jan 16, 2023, at 1:34 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> I think the question of "when is a Go program deterministic" makes full
> sense, FWIW. Because being deterministic is a desirable property of many
> programs (compilers being one obvious example). So considering this
> question gives you insight into how to write such programs. For example,
> realizing that map iteration order is not defined to be deterministic leads
> you to sort keys of a map before output, if you want deterministic output.
>
>

-- 
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/CAEkBMfEXwe-eKc58DsMGrgpJy%2BLXq-dsRKLchkJdf5bVc7agZA%40mail.gmail.com.

Re: [go-nuts] Guaranteeing deterministic execution of Golang code

[Bakul Shah]

I would think the map iteration order is arbitrary but deterministic. That is, 
the same set of keys will be iterated the same way every time. This is not the 
case with the select statement.

> On Jan 16, 2023, at 1:34 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> I think the question of "when is a Go program deterministic" makes full 
> sense, FWIW. Because being deterministic is a desirable property of many 
> programs (compilers being one obvious example). So considering this question 
> gives you insight into how to write such programs. For example, realizing 
> that map iteration order is not defined to be deterministic leads you to sort 
> keys of a map before output, if you want deterministic output.

-- 
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/95F0F462-C4C5-4B59-9FC8-71EB6217862B%40iitbombay.org.

Re: [go-nuts] Guaranteeing deterministic execution of Golang code

['Axel Wagner' via golang-nuts]

On Mon, Jan 16, 2023 at 3:18 AM Robert Engels  wrote:

> This is a very strange discussion. I don’t understand the purpose.
> Malloc() isn’t even deterministic. Which means any arbitrary program can
> take the address to generate entropy regardless of having time, etc
> available.
>
> I didn’t look it up, but I’m pretty sure there is a “law” that if the
> language/system has any concurrency available then it is the correctness of
> the program that guarantees determinism - ie. same inputs generate same
> outputs.
>

FWIW this is definitely not true, at least not in the context of Go. This
function is correct, yet defined to be non-deterministic:

func F() string {
ch := make(chan int)
close(ch)
select {
case <-ch:
return "foo"
case <-ch:
return "bar"
}
}

I think the question of "when is a Go program deterministic" makes full
sense, FWIW. Because being deterministic is a desirable property of many
programs (compilers being one obvious example). So considering this
question gives you insight into how to write such programs. For example,
realizing that map iteration order is not defined to be deterministic leads
you to sort keys of a map before output, if you want deterministic output.

I don't think there's much more to be learned from it though - you quickly
find out, that it's essentially impossible (or is unreasonably restrictive
to the language) to guarantee a program's determinism against an adversary.
So there's no real reasonable "deterministic subset of Go" - all you can
do, is do your best to avoid the stuff you discovered.


>
>
>
> On Jan 15, 2023, at 5:59 PM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
>
>
> On Mon, Jan 16, 2023 at 12:38 AM Stan Srednyak 
> wrote:
>
>> hi Axel,
>>
>> thanks for sharing. Why did you mention webassembly specifically, why not
>> go or c?
>>
>
> I mentioned WebAssembly specifically because a) it has a well sandboxed,
> single-threaded VM and b) there are existing compilers for Go.
> I don't understand why you mention C. If you want control over the
> execution environment (i.e. if you want to isolate it to be deterministic)
> that is literally the worst choice.
>
>
>>
>> Stan
>>
>> On Sat, Jan 14, 2023 at 6:37 PM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> Oh, also, fmt: https://go.dev/play/p/xxOw3vqWR4u (probably need to run
>>> this offline)
>>>
>>> Honestly, I don't think there really is a practical way to prevent
>>> non-determinism without severly hampering the language. Your best bet is
>>> probably to compile a program to webassembly and then don't give the VM
>>> access to any source of entropy.
>>>
>>> On Sun, Jan 15, 2023 at 12:29 AM Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
 There's also maps, select and goroutines in general. Funnily enough I
 blogged about this some years ago, for fun
 
 .

 On Sat, Jan 14, 2023 at 11:52 PM Stan Srednyak 
 wrote:

> How much of Golang functionality must be excluded in order to
> guarantee deterministic execution on a fixed system?
>
> There are typical sources of nondeterminism
>
> 1. /dev/urandom
>
> 2. time
>
> We should include system variables here, but lets suppose we fix the
> system.
>
> One more source could be system files. Lets say we use chroot to jail
> the process. This should be done carefully: naive use does not exclude
> /dev/urandom , and as a result e.g. RSA key generation has access to
> randomness. But lets assume that we dealt with this issue.
>
>
> Also, the stack can be a source of randomness. In Golang, it is
> possible to get info about the stack. But lets say, we blocked these
> possibilities by forbidding the access to runtime.
>
> What else is there?
>
> At the moment it seems that to guarantee deterministic execution it is
> necessary to block access to modules:
> runtime
> syscall
> time
> crypto -- the parts that have to do with key generation
> os -- parts that get system variables and process information
> math/rand
>
> Which other standard modules can give rise to nondeterminism?
>
> It seems that modules
> -ioutil
> -bufio
> -most of os
> -strings
> -bytes
>
> are "nondeterminism safe".
>
> File info can be a source of nondeterminism - the last access time in
> nanoseconds.
>
>
>
> --
> 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
> 

[go-nuts] Re: Guaranteeing deterministic execution of Golang code

[Brian Candler]

Are you trying to find a pure functional subset of go?

In a "pure function", the return value(s) are calculated only from the 
arguments. The result is not affected by the state of the system, and the 
state of the system is not affected by the function.  That means you can't 
even do a print() inside a function.

Or are you trying to do some sandboxing of untrusted, user-submitted code, 
but allowing a larger scope than pure functional behaviour?  For example, 
do you need to allow access the filesystem, or send and receive messages on 
a channel or queue?  If so, does it have to be Go code that is sandboxed?

For some applications, an interpreter for a "safe" language may be what you 
want (e.g. jsonnet , cue 
, starlark 
).  Or you might be able 
to configure an interpreter for some other language - even an interpreter 
for Go - to have the restricted behaviour you require.

More generally: it's possible to write pure functional code which returns a 
value which is a "request" to do something.  Such requests are then very 
easy to filter, perform if safe, and then invoke the next function with the 
result.  This is the basic idea behind the IO Monad 

 in 
functional languages.

-- 
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/b672c94a-e8a0-4340-8ece-478ea28ffc0an%40googlegroups.com.

[go-nuts] Re: etcd, how to stop it ?

[alex-coder]

Brian, I can't thank you enough !
Sorry, button "Community" ofcourse.

понедельник, 16 января 2023 г. в 11:41:51 UTC+3, Brian Candler: 

> The homepage for etcd is here: https://etcd.io/  and there is a button 
> labelled "Community".
>
> You may also find this page useful: 
> http://www.catb.org/~esr/faqs/smart-questions.html#intro
>
> On Sunday, 15 January 2023 at 18:30:09 UTC alex-coder wrote:
>
>> Hi All !
>>
>> I do understand that my question is not quite in the right arrea,
>> but frankly, I'm totally lost.
>> I'm not able to find the answer for the looks like very simple question.
>> How to run - yes there is a sample, but how to stop it ?
>>
>> Thank you.
>>
>

-- 
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/d59c05df-4c98-472d-83ae-9fd47020f52dn%40googlegroups.com.

[go-nuts] Re: etcd, how to stop it ?

[Brian Candler]

The homepage for etcd is here: https://etcd.io/  and there is a button 
labelled "Community".

You may also find this page 
useful: http://www.catb.org/~esr/faqs/smart-questions.html#intro

On Sunday, 15 January 2023 at 18:30:09 UTC alex-coder wrote:

> Hi All !
>
> I do understand that my question is not quite in the right arrea,
> but frankly, I'm totally lost.
> I'm not able to find the answer for the looks like very simple question.
> How to run - yes there is a sample, but how to stop it ?
>
> Thank you.
>

-- 
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/ff95fea7-0b81-4f4f-951d-3da45730c05cn%40googlegroups.com.