Re: [go-nuts] Understanding some gotchas with linking slices together via indexing

[Brian, son of Bob]

Thanks!  This has been super informative!

On Thursday, November 3, 2022 at 1:48:49 AM UTC+8 Marvin Renich wrote:

> * Brian, son of Bob  [221102 00:49]:
> > Can anyone explain these gotchas (demo <
> https://go.dev/play/p/g40KMK-zsNk>)? 
> > I've tried reading articles on this [one <
> https://go.dev/blog/slices-intro>, 
> > two 
> > <
> https://codeburst.io/a-comprehensive-guide-to-slices-in-golang-bacebfe46669>] 
>
> > but they don't go into enough detail.
>
> Burak gave a very good, succinct answer to your question. I will give a
> more verbose explanation.
>
> [Short summary at bottom.]
>
> Go does not have a concept of "linked" slices, and does not use that
> terminology. Instead, slices have an _underlying array_, sometimes also
> called a slice's _backing array_. More than one slice can have the same
> backing array, so that changing an element of one slice might change an
> element of another slice.
>
> However, the underlying array for a slice can be changed at any time by
> assignment to the slice, as opposed to assignment to a slice element;
> and this does _not_ change the underlying array for other slices that
> currently use the original underlying array from the first slice. This
> is the primary difference between your concept of "linked slices" and
> the actual behavior of Go.
>
> If you think of a slice as a "view" into its (always fixed-size)
> underlying array, rather than a "variable sized array" you will probably
> have an easier time understanding its behavior. That is, the underlying
> array cannot change size, but the view into it can.
>
> var a = [10]int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9} // an array
> var s = a[1:5:7] // a slice with backing array a
> var t = a[3:6] // another slice with the same backing array
> var u = s[2:5] // like t, but limited by the capacity of s
>
> +---+---+---+---+---+---+---+---+---+---+
> a | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
> +---+---+---+---+---+---+---+---+---+---+
> ^ ^ ^
> s first last cap
> ^ ^ ^
> t first last cap
> ^ ^ ^
> u first last cap
>
> s[2] = 13 // now t[0] is 13
>
> Assuming x is a slice that has length 5 and capacity 10, the results of
> the following expressions all have the same backing array:
>
> x
> x[:]
> x[0:]
> x[:len(x)]
> x[1:]
> x[:4]
> x[2:4]
> x[3:8]
> x[3:5:7]
>
> The playground link https://go.dev/play/p/tbm97ueCSdP demonstrates that
> all these have the same backing array by creating all the slices as
> named variables, then modifying one element of one of the slices, and
> showing that all the slices have had that corresponding element changed.
>
> In fact, all Slice Expressions as defined at
> https://go.dev/ref/spec#Slice_expressions in the Go Language
> Specification return a slice with the same underlying array as the
> original slice.
>
> There are only a small number of ways to create a slice:
>
> 1. A slice literal.
> 2. The built-in make function.
> 3. A slice expression (as defined in the language spec) applied to a
> slice, array, or pointer to array.
> 4. Assignment or argument passing or returning a result.
> 5. The built-in append function.
>
> Each of these (at least conceptually; the compiler can optimize away
> unnecessary allocations) creates a new slice value (i.e. internal
> structure containing pointer into underlying array, length, and
> capacity). For 1 and 2, a new underlying array is always created. For
> 3 and 4, the underlying array does not change.
>
> The tricky case is 5, where the append function can return a new slice
> with the same underlying array as its first argument, or it may create a
> new underlying array.
>
> This is where capacity comes in. If the original slice has enough
> capacity to hold all the appended elements, the backing array elements
> are modified and the result is a slice with the same backing array. If
> the original slice does not have enough capacity, a new backing array is
> created, and the old slice elements followed by the new slice elements
> (the remaining arguments to append) are copied into it.
>
> Note well that the expression «x = append(x, 9, 8, 7)» is not the same
> as a conceptual «x.append(9, 8, 7)»; that is, it is not appending to the
> variable named x, it is creating a new slice using the value of x and
> then assigning that new slice to x. Whether the new slice has the same
> underlying array as the original depends on the capacity of the
> original.
>
> In your original message, you say that x[0:] and x[:len(x)] are not
> "linked" to x. You are basing that on whether or not append(y, 4)
> modifies x. However, these do share the same backing array as x, but
> append(x[:len(x)], 4) does not (if len(x) == cap(x)). What you are
> seeing is that when len(x) == 3 and cap(x) == 3, and you assign y =
> x[:len(x)-1], then len(y) == 2, but cap(y) == 3, so y has enough
> capacity to append one element, but not two.
>
> The condensed takeaway:
>
> Go does not have any concept that remotely resembles what you are
> thinking of as "linked" slices.
>
> 

[go-nuts] Re: How to run telnet command?

[Brian Candler]

I think what you really want is not to use telnet, but to connect to a 
mailserver on port 25.  To establish a TCP connection in Go, you should use 
net.Dial. See: https://pkg.go.dev/net

If you actually want to send mail, there are higher level approaches which 
will take care of a lot of the details for you, for 
example: https://pkg.go.dev/net/smtp

On Wednesday, 2 November 2022 at 17:37:28 UTC Postgres Hero wrote:

> Hi All,
>
> I am naive in Golang :), so please forgive me if my question seems silly.
>
> I am trying to achieve the following telnet command in Go, but in vain. 
>
> "*telnet mx mydomain.com  25*"
>
> I found a package here – github.com/reiver/go-telnet. However, I could 
> not find a way to execute the aforementioned command.
>
> Could someone shed some light on this? 
>
> Thanks in advance.
>

-- 
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/86622fe1-237e-4075-b463-e7371062542fn%40googlegroups.com.

Re: [go-nuts] How does the go compiler treat initialized string variables?

[jake...@gmail.com]

Just to add a tidbit to what Jan said. The key here is that strings (type 
string) in Go are immutable, whereas strings ("char *"  based types) in C 
are not. That is why the same string can be used again and again without 
ever needing to be copied, and why they can live in the text segment.

On Tuesday, November 1, 2022 at 3:47:47 PM UTC-4 Jan Mercl wrote:

>
>
> On Tue, Nov 1, 2022, 20:36 Frank Jüdes  wrote:
>
>> I have to write a program that should verify the content of 
>> configuration-servers. It will need a lot of pre-initialized data to verify 
>> the actual content of a server, so it has to initialize many strings. What 
>> i know from other C-style languages is, that code like 
>>
>> var MyString *string = 'Hello World!'; 
>>
>> Will result in having two identical copies of the string »Hello World!« 
>> in the memory: The first one within the program-code itself and a second 
>> copy somewhere in the heap-memory.
>>
>
> I think the string backing array will be in the text segment as in C. The 
> string header will end in the data segment, provided it's a package scoped 
> variable, but the header has no direct equivalent in C.
>
> How will the go-compiler handle something like this: 
>>
>> package main 
>>   import ("fmt") 
>>   type MyStruct struct { 
>> Text string 
>> Count int32 
>>   } 
>>   func main() { 
>> MyVar := MyStruct{Text: "Hello World!", Count: 20 } 
>> fmt.Printf("%#v\n",MyVar) } 
>>
>> Will there be two copies of the string »Hello World!" in the memory or 
>> just one? 
>>
>
> The backing string  array will exist only once, again in the text segment, 
> I believe, because there's no reason for making any copies of it in this 
> case.
>
>>
> Not tested/verified 
>
>>
>>

-- 
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/c44f9c26-f4fe-4e5b-9c33-562b6b490ab8n%40googlegroups.com.

Re: [go-nuts] Understanding some gotchas with linking slices together via indexing

[Marvin Renich]

* Brian, son of Bob  [221102 00:49]:
> Can anyone explain these gotchas (demo )?  
> I've tried reading articles on this [one , 
> two 
> ]
>  
> but they don't go into enough detail.

Burak gave a very good, succinct answer to your question.  I will give a
more verbose explanation.

[Short summary at bottom.]

Go does not have a concept of "linked" slices, and does not use that
terminology.  Instead, slices have an _underlying array_, sometimes also
called a slice's _backing array_.  More than one slice can have the same
backing array, so that changing an element of one slice might change an
element of another slice.

However, the underlying array for a slice can be changed at any time by
assignment to the slice, as opposed to assignment to a slice element;
and this does _not_ change the underlying array for other slices that
currently use the original underlying array from the first slice.  This
is the primary difference between your concept of "linked slices" and
the actual behavior of Go.

If you think of a slice as a "view" into its (always fixed-size)
underlying array, rather than a "variable sized array" you will probably
have an easier time understanding its behavior.  That is, the underlying
array cannot change size, but the view into it can.

var a = [10]int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9} // an array
var s = a[1:5:7] // a slice with backing array a
var t = a[3:6] // another slice with the same backing array
var u = s[2:5] // like t, but limited by the capacity of s

 +---+---+---+---+---+---+---+---+---+---+
  a  | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
 +---+---+---+---+---+---+---+---+---+---+
   ^   ^   ^
  s  first   last cap
   ^   ^   ^
  t  first   last cap
   ^   ^   ^
  u  first   last cap

s[2] = 13 // now t[0] is 13

Assuming x is a slice that has length 5 and capacity 10, the results of
the following expressions all have the same backing array:

x
x[:]
x[0:]
x[:len(x)]
x[1:]
x[:4]
x[2:4]
x[3:8]
x[3:5:7]

The playground link https://go.dev/play/p/tbm97ueCSdP demonstrates that
all these have the same backing array by creating all the slices as
named variables, then modifying one element of one of the slices, and
showing that all the slices have had that corresponding element changed.

In fact, all Slice Expressions as defined at
https://go.dev/ref/spec#Slice_expressions in the Go Language
Specification return a slice with the same underlying array as the
original slice.

There are only a small number of ways to create a slice:

  1.  A slice literal.
  2.  The built-in make function.
  3.  A slice expression (as defined in the language spec) applied to a
  slice, array, or pointer to array.
  4.  Assignment or argument passing or returning a result.
  5.  The built-in append function.

Each of these (at least conceptually; the compiler can optimize away
unnecessary allocations) creates a new slice value (i.e. internal
structure containing pointer into underlying array, length, and
capacity).  For 1 and 2, a new underlying array is always created.  For
3 and 4, the underlying array does not change.

The tricky case is 5, where the append function can return a new slice
with the same underlying array as its first argument, or it may create a
new underlying array.

This is where capacity comes in.  If the original slice has enough
capacity to hold all the appended elements, the backing array elements
are modified and the result is a slice with the same backing array.  If
the original slice does not have enough capacity, a new backing array is
created, and the old slice elements followed by the new slice elements
(the remaining arguments to append) are copied into it.

Note well that the expression «x = append(x, 9, 8, 7)» is not the same
as a conceptual «x.append(9, 8, 7)»; that is, it is not appending to the
variable named x, it is creating a new slice using the value of x and
then assigning that new slice to x.  Whether the new slice has the same
underlying array as the original depends on the capacity of the
original.

In your original message, you say that x[0:] and x[:len(x)] are not
"linked" to x.  You are basing that on whether or not append(y, 4)
modifies x.  However, these do share the same backing array as x, but
append(x[:len(x)], 4) does not (if len(x) == cap(x)).  What you are
seeing is that when len(x) == 3 and cap(x) == 3, and you assign y =
x[:len(x)-1], then len(y) == 2, but cap(y) == 3, so y has enough
capacity to append one element, but not two.

The condensed takeaway:

Go does not have any concept that remotely resembles what you are
thinking of as "linked" slices.

Slices are "views" into a fixed-size array.

Different slices may be views 

[go-nuts] How to run telnet command?

[Postgres Hero]

Hi All,

I am naive in Golang :), so please forgive me if my question seems silly.

I am trying to achieve the following telnet command in Go, but in vain. 

"*telnet mx mydomain.com 25*"

I found a package here – github.com/reiver/go-telnet. However, I could not 
find a way to execute the aforementioned command.

Could someone shed some light on this? 

Thanks in advance.

-- 
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/0960a77d-7d73-4347-b72a-176998d15f72n%40googlegroups.com.

[go-nuts] Re: [security] Go 1.19.3 and Go 1.18.8 are released

[Wojciech Kaczmarek]

Thank you Heschi, it worked.

W.

wtorek, 1 listopada 2022 o 19:03:46 UTC+1 Heschi Kreinick napisał(a):

> Thanks, good catch. We accidentally signed the installer twice, uploaded 
> the first one, and posted the checksum for the second one. We'll correct 
> the checksum.
>
> On Tuesday, November 1, 2022 at 1:28:49 PM UTC-4 Wojciech Kaczmarek wrote:
>
>> I think it's important to report that  go1.18.8.windows-amd64.msi 
>>  doesn't match the 
>> published sha256 checksum. 
>>
>>
>> wtorek, 1 listopada 2022 o 18:01:35 UTC+1 anno...@golang.org napisał(a):
>>
>>> Hello gophers,
>>>
>>> We have just released Go versions 1.19.3 and 1.18.8, minor point 
>>> releases.
>>>
>>> These minor releases include 1 security fixes following the security 
>>> policy :
>>>
>>>- 
>>>
>>>syscall, os/exec: unsanitized NUL in environment variables
>>>
>>>On Windows, syscall.StartProcess and os/exec.Cmd did not properly 
>>>check for invalid environment variable values. A malicious environment 
>>>variable value could exploit this behavior to set a value for a 
>>> different 
>>>environment variable. For example, the environment variable string 
>>>"A=B\x00C=D" set the variables "A=B" and "C=D".
>>>
>>>Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this 
>>>issue.
>>>
>>>This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.
>>>
>>> View the release notes for more information:
>>> https://go.dev/doc/devel/release#go1.19.3
>>>
>>> You can download binary and source distributions from the Go website:
>>> https://go.dev/dl/
>>>
>>> To compile from source using a Git clone, update to the release with
>>> git checkout go1.19.3 and build as usual.
>>>
>>> Thanks to everyone who contributed to the releases.
>>>
>>> Cheers,
>>> Matthew and Heschi 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/965bbe27-06b2-44d6-86bf-9b076625ccban%40googlegroups.com.

Re: [go-nuts] Re: [security] Go 1.19.3 and Go 1.18.8 are released

[Caleb Spare]

Hmm, I do see a matching checksum
(6d38668862bf9772c0c1c1e0f26aa5dedea9825b33f763b81ccc4aa63df2cef9) for
go1.18.8.windows-amd64.msi.

On Tue, Nov 1, 2022 at 10:28 AM Wojciech Kaczmarek  wrote:
>
> I think it's important to report that  go1.18.8.windows-amd64.msi doesn't 
> match the published sha256 checksum.
>
>
> wtorek, 1 listopada 2022 o 18:01:35 UTC+1 anno...@golang.org napisał(a):
>>
>> Hello gophers,
>>
>> We have just released Go versions 1.19.3 and 1.18.8, minor point releases.
>>
>> These minor releases include 1 security fixes following the security policy:
>>
>> syscall, os/exec: unsanitized NUL in environment variables
>>
>> On Windows, syscall.StartProcess and os/exec.Cmd did not properly check for 
>> invalid environment variable values. A malicious environment variable value 
>> could exploit this behavior to set a value for a different environment 
>> variable. For example, the environment variable string "A=B\x00C=D" set the 
>> variables "A=B" and "C=D".
>>
>> Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this issue.
>>
>> This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.
>>
>> View the release notes for more information:
>> https://go.dev/doc/devel/release#go1.19.3
>>
>> You can download binary and source distributions from the Go website:
>> https://go.dev/dl/
>>
>> To compile from source using a Git clone, update to the release with
>> git checkout go1.19.3 and build as usual.
>>
>> Thanks to everyone who contributed to the releases.
>>
>> Cheers,
>> Matthew and Heschi 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/b3a092a1-38a2-452b-9451-ceda7ab0cdcdn%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/CAGeFq%2Bk4pq%3DThKCq%3DUgd21vQ7NWn8p_GnTaApyyK6GLzpTekbQ%40mail.gmail.com.

Fwd: Re: [go-nuts] There is a passage in book that is difficult to understand, can anyone help explain it?

[Jan Mercl]

Please do not post to this _mailing list_ from an email address that
bot-spams my inbox when I reply. I have asked you to fix this at least
one time before.

Perhaps configuring your email to drop anything from my address would
resolve the problem?

-- Forwarded message -
From: 
Date: Wed, Nov 2, 2022 at 6:10 PM
Subject: Re: Re: [go-nuts] There is a passage in book  that is difficult to understand, can anyone help
explain it?
To: Jan Mercl <0xj...@gmail.com>


I apologize for this automatic reply to your email.

To control spam, I now allow incoming messages only from senders I
have approved beforehand.

If you would like to be added to my list of approved senders, please
fill out the short request form (see link below). Once I approve you,
I will receive your original message in my inbox. You do not need to
resend your message. I apologize for this one-time inconvenience.

Click the link below to fill out the request:

https://webmail1.earthlink.net/newaddme?a=reng...@ix.netcom.com=11ed-5ad1-39c53164-82e1-00144ffbff76

-- 
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-VRGGdCJYFQTtb-M80Ukhqr0M2K5foOt-dmS_M%2BwMFsTA%40mail.gmail.com.

Re: [go-nuts] There is a passage in book that is difficult to understand, can anyone help explain it?

[Eli Lindsey]

A’ would then be susceptible to the original “reasoning difficulties” without any locking. I think it shows that any complex function, especially those with recursion, have the same difficulties. Due to sequential consistency, A’ must be correct, since a non-reentrant lock forces a single thread of execution - making A’ and A equivalent. A holding the lock for the length of A’ communicates that A’ is inside the critical section and must be careful to preserve invariants. A’ internally locking a reentrant lock is ambiguous with respect to invariant expectations.The practical implications are as important as the theoretical. There’s inherent complexity in both - non reentrant locks tends to surface complexity and make the behaviors/assumptions more obvious. Very, very occasionally reentrant locks are worth the ambiguity they introduce, but primarily in callback heavy code (which Go doesn’t encourage as much as other languages/APIs).-eliOn Nov 2, 2022, at 7:49 AM, Eli Lindsey  wrote:Reentrant locks make any given critical section harder to understand because you must also understand the calling pattern that led there to know which invariants have been upheld and which may have been violated due to a still-in-progress critical section higher up the call chain.For example, Average.Value() in the example is making the assumption that sum and count have been appropriately updated in lockstep. But if the lock is reentrant, this may not be true. Average is small enough that it’s trivial to check if this is a problem (ie. that Value is not called from Add while sum/count mismatch); more complex code is not, especially when it encounters future maintainers.-eliOn Nov 2, 2022, at 7:43 AM, Robert Engels  wrote:I am curious though for an example that shows how a reentrant lock could violate this?On Nov 2, 2022, at 2:38 AM, peterGo  wrote:Guanyun,I tried to think of a simple example.type Average struct {    sum   float64    count int64    mx    sync.Mutex}https://go.dev/play/p/4SLCLuqG2461. An invariant represents a condition that does not change while the process progresses - Niklaus Wirth.2. The additional invariant--Average = sum / count--is specific to the data structure that the mutex mx guards.3. The shared variables sum and count are part of an invariant.4. The Add method temporarily violates the invariant by updating sum but restores the invariant by updating count.PeterOn Wednesday, November 2, 2022 at 12:49:41 AM UTC-4 name@gmail.com wrote:Hello,This is a passage in book :There is a good reason Go’s mutexes are not re-entrant.The purpose of a mutex is to ensure that certain invariants of the shared variables aremaintained at critical points during program execution.One of the invariants is "no goroutine is accessing the shared variables", but there may be additional invariants specific to the data structures that the mutex guards.When a goroutine acquires a mutex lock, it may assume that the invariants hold. While it holds the lock, it may update the shared variables so that the invariants are temporarily violated.However, when it releases the lock, it must guarantee that order has been restoredand the invariants hold once again.Although a re-entrant mutex would ensure that no other goroutines are accessing the shared variables, it cannot protect the additional invariants of those variables. This passage is difficult for me to understand:1. How to understand invariants "invariants"?2. What kind of scenarios does “additional invariants” refer to?3. What is the relationship between "shared variables" and "invariants"?4. What does "...guarantee that order has been restored..." mean?Thanks,Guanyun

-- 
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/c2b53c11-4552-4b9a-a528-fc179ba0f513n%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/6F217FB7-077E-4CBE-B46E-4ADB7D7461A3%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/9875F919-83A9-43E4-88EC-81D6C447ED9A%40siliconsprawl.com.




-- 
You 

Re: [go-nuts] There is a passage in book that is difficult to understand, can anyone help explain it?

[Jan Mercl]

On Wed, Nov 2, 2022 at 5:35 PM Robert Engels  wrote:

> I think this can be disproven.
>
> Given a function A with a reentrant lock, it can be rewritten as A with 
> non-reentrant lock and A’ without a lock where A’ is the original A function 
> body.
>
> A’ would then be susceptible to the original “reasoning difficulties” without 
> any locking. I think it shows that any complex function, especially those 
> with recursion, have the same difficulties.

I think up to this point the reasoning is correct - even though it IMO
demonstrates the opposite: If A' handles the invariants incorrectly
then a reentrant lock guarding the A will not help to fix the problem.

IOW, not using a reentrant lock is better because a deadlock/crash is
safer than corrupting data/state.

> Due to sequential consistency, A’ must be correct, since a non-reentrant lock 
> forces a single thread of execution - making A’ and A equivalent.

I think this holds differently: Iff A' is correct then A' and A are
equivalent [in the first approximation ignoring the locking]. So
again, in all cases where the correctness of A' cannot be proven,
avoid "fixing" it by a reentrant lock.

-- 
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-UG%3DpNx7Xkt5UHduS5F5DtiCE1gcK3fL7t-HMjWDtAK1w%40mail.gmail.com.

[go-nuts] There is a passage in book that is difficult to understand, can anyone help explain it?

[Robert Engels]



I think this can be disproven. 

Given a function A with a reentrant lock, it can be rewritten as A with 
non-reentrant lock and A’ without a lock where A’ is the original A function 
body. 

A’ would then be susceptible to the original “reasoning difficulties” without 
any locking. I think it shows that any complex function, especially those with 
recursion, have the same difficulties. 

Due to sequential consistency, A’ must be correct, since a non-reentrant lock 
forces a single thread of execution - making A’ and A equivalent. 

Trivial functions are easy to reason about  no matter the locking strategy. 

> On Nov 2, 2022, at 7:49 AM, Eli Lindsey  wrote:
> Reentrant locks make any given critical section harder to understand because 
> you must also understand the calling pattern that led there to know which 
> invariants have been upheld and which may have been violated due to a 
> still-in-progress critical section higher up the call chain.
> 
> For example, Average.Value() in the example is making the assumption that sum 
> and count have been appropriately updated in lockstep. But if the lock is 
> reentrant, this may not be true. Average is small enough that it’s trivial to 
> check if this is a problem (ie. that Value is not called from Add while 
> sum/count mismatch); more complex code is not, especially when it encounters 
> future maintainers.
> 
> -eli
> 
>> On Nov 2, 2022, at 7:43 AM, Robert Engels  wrote:
>> 
>> I am curious though for an example that shows how a reentrant lock could 
>> violate this?
>> 
>>> On Nov 2, 2022, at 2:38 AM, peterGo  wrote:
>>> 
>>> Guanyun,
>>> 
>>> I tried to think of a simple example.
>>> 
>>> type Average struct {
>>> sum   float64
>>> count int64
>>> mxsync.Mutex
>>> }
>>> 
>>> https://go.dev/play/p/4SLCLuqG246
>>> 
>>> 1. An invariant represents a condition that does not change while the 
>>> process progresses - Niklaus Wirth.
>>> 
>>> 2. The additional invariant--Average = sum / count--is specific to the data 
>>> structure that the mutex mx guards.
>>> 
>>> 3. The shared variables sum and count are part of an invariant.
>>> 
>>> 4. The Add method temporarily violates the invariant by updating sum but 
>>> restores the invariant by updating count.
>>> 
>>> Peter
>>> 
>>> On Wednesday, November 2, 2022 at 12:49:41 AM UTC-4 name@gmail.com 
>>> wrote:
 Hello,
 
 This is a passage in book :
 
 There is a good reason Go’s mutexes are not re-entrant.
 
 The purpose of a mutex is to ensure that certain invariants of the shared 
 variables are
 maintained at critical points during program execution.
 
 One of the invariants is "no goroutine is accessing the shared variables", 
 but there may be additional invariants specific to the data structures 
 that the mutex guards.
 
 When a goroutine acquires a mutex lock, it may assume that the invariants 
 hold. While it holds the lock, it may update the shared variables so that 
 the invariants are temporarily violated.
 
 However, when it releases the lock, it must guarantee that order has been 
 restored
 and the invariants hold once again.
 
 Although a re-entrant mutex would ensure that no other goroutines are 
 accessing the shared variables, it cannot protect the additional 
 invariants of those variables.
  
 
 
 This passage is difficult for me to understand:
 1. How to understand invariants "invariants"?
 2. What kind of scenarios does “additional invariants” refer to?
 3. What is the relationship between "shared variables" and "invariants"?
 4. What does "...guarantee that order has been restored..." mean?
 
 Thanks,
 Guanyun
>>> 
>>> 
>>> -- 
>>> 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/c2b53c11-4552-4b9a-a528-fc179ba0f513n%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/6F217FB7-077E-4CBE-B46E-4ADB7D7461A3%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 

Re: [go-nuts] There is a passage in book that is difficult to understand, can anyone help explain it?

[Eli Lindsey]

Reentrant locks make any given critical section harder to understand because 
you must also understand the calling pattern that led there to know which 
invariants have been upheld and which may have been violated due to a 
still-in-progress critical section higher up the call chain.

For example, Average.Value() in the example is making the assumption that sum 
and count have been appropriately updated in lockstep. But if the lock is 
reentrant, this may not be true. Average is small enough that it’s trivial to 
check if this is a problem (ie. that Value is not called from Add while 
sum/count mismatch); more complex code is not, especially when it encounters 
future maintainers.

-eli

> On Nov 2, 2022, at 7:43 AM, Robert Engels  wrote:
> 
> I am curious though for an example that shows how a reentrant lock could 
> violate this?
> 
>> On Nov 2, 2022, at 2:38 AM, peterGo  wrote:
>> 
>> 
>> Guanyun,
>> 
>> I tried to think of a simple example.
>> 
>> type Average struct {
>> sum   float64
>> count int64
>> mxsync.Mutex
>> }
>> 
>> https://go.dev/play/p/4SLCLuqG246
>> 
>> 1. An invariant represents a condition that does not change while the 
>> process progresses - Niklaus Wirth.
>> 
>> 2. The additional invariant--Average = sum / count--is specific to the data 
>> structure that the mutex mx guards.
>> 
>> 3. The shared variables sum and count are part of an invariant.
>> 
>> 4. The Add method temporarily violates the invariant by updating sum but 
>> restores the invariant by updating count.
>> 
>> Peter
>> 
>> On Wednesday, November 2, 2022 at 12:49:41 AM UTC-4 name@gmail.com wrote:
>>> Hello,
>>> 
>>> This is a passage in book :
>>> 
>>> There is a good reason Go’s mutexes are not re-entrant.
>>> 
>>> The purpose of a mutex is to ensure that certain invariants of the shared 
>>> variables are
>>> maintained at critical points during program execution.
>>> 
>>> One of the invariants is "no goroutine is accessing the shared variables", 
>>> but there may be additional invariants specific to the data structures that 
>>> the mutex guards.
>>> 
>>> When a goroutine acquires a mutex lock, it may assume that the invariants 
>>> hold. While it holds the lock, it may update the shared variables so that 
>>> the invariants are temporarily violated.
>>> 
>>> However, when it releases the lock, it must guarantee that order has been 
>>> restored
>>> and the invariants hold once again.
>>> 
>>> Although a re-entrant mutex would ensure that no other goroutines are 
>>> accessing the shared variables, it cannot protect the additional invariants 
>>> of those variables.
>>>  
>>> 
>>> 
>>> This passage is difficult for me to understand:
>>> 1. How to understand invariants "invariants"?
>>> 2. What kind of scenarios does “additional invariants” refer to?
>>> 3. What is the relationship between "shared variables" and "invariants"?
>>> 4. What does "...guarantee that order has been restored..." mean?
>>> 
>>> Thanks,
>>> Guanyun
>> 
>> 
>> -- 
>> 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/c2b53c11-4552-4b9a-a528-fc179ba0f513n%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/6F217FB7-077E-4CBE-B46E-4ADB7D7461A3%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/9875F919-83A9-43E4-88EC-81D6C447ED9A%40siliconsprawl.com.

[go-nuts] Re: Trying to create a test app for a library package [solved]

[Brian Candler]

> Given that I have a local pkg, mylib, whose module name is 
github.com/me/mylib, how can I create a local Go application that uses 
mylib from the local folder it is in rather than actually downloading it 
from github

FYI, what I've just shown doesn't download anything from github.  It works 
even with a random module name like "github.com/me/mylib" which doesn't 
match any real repository in github.

It walks up the tree to find go.mod, realises it already has 
github.com/me/mylib available locally, and uses that.

-- 
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/ba61f77b-fa47-4929-8dd8-eeb5ef554de7n%40googlegroups.com.

[go-nuts] Re: Trying to create a test app for a library package [solved]

[Brian Candler]

> tester.go:8:2: package github/me/mylib is not in GOROOT

That looks like a typo: "github" instead of "github.com"

You definitely don't need a second go.mod, nor do you need any "replace" 
statements.  The following works (literally "github.com/me/mylib" is fine 
too)

-- mylib/go.mod --
module github.com/me/mylib

go 1.18

-- mylib/mylib.go --
package mylib

import "fmt"

func Flurble() {
fmt.Println("Flurble")
}

-- mylib/tester/tester.go --
package main

import (
"github.com/me/mylib"
)

func main() {
mylib.Flurble()
}


$ cd tester/
$ go run .
Flurble
$ 


On Wednesday, 2 November 2022 at 11:50:54 UTC Mark wrote:

> I solved this problem by adding an extra go.mod file:
> ```
> mylib/
> mylib/go.mod # module github.com/me/mylib
> mylib/mylib.go
> mylib/mylib_test.go
> mylib/tester/tester.go
> mylib/tester/go.mod
> ```
> This allowed me to change the import in tester.go to `import "mylib"`.
> The text of tester/go.mod is:
> ```
> module tester
> go 1.19
> require mylib v0.3.0
> replace mylib v0.3.0 => ../../mylib
> ```
>
> On Wednesday, November 2, 2022 at 9:38:01 AM UTC Mark wrote:
>
>> I suppose what I'm really asking is this:
>>
>> Given that I have a local pkg, mylib, whose module name is 
>> github.com/me/mylib, how can I create a local Go application that uses 
>> mylib from the local folder it is in rather than actually downloading it 
>> from github. (I do do the latter, but for quick testing & development 
>> that's too slow; I need to save an edit to mylib in one window & run myapp 
>> using the just edited mylib in another).
>>
>> On Wednesday, November 2, 2022 at 9:34:31 AM UTC Mark wrote:
>>
>>> That doesn't work either (obviously I used my real github a/c name)
>>> tester.go:8:2: package github/me/mylib is not in GOROOT
>>>
>>> On Wednesday, November 2, 2022 at 9:26:35 AM UTC Brian Candler wrote:
>>>
 In mylib/tester/tester.go:

 import (
 "fmt
 "github.com/me/mylib"
 )

 On Wednesday, 2 November 2022 at 08:41:24 UTC Mark wrote:

> I have this layout:
> ```
> mylib/
> mylib/go.mod # module github.com/me/mylib
> mylib/mylib.go
> mylib/mylib_test.go
> ```
> All this works fine, with both .go files being in the same pkg: mylib.
>
> However, there are some tests that I can't really do using the test 
> module because they write to stdout. So I want to create an exe for 
> regression testing.
>
> In particular I want the regression tester to be in package main (just 
> like an app that uses mylib).
>
> I've tried this layout:
> ```
> mylib/
> mylib/go.mod # module github.com/me/mylib
> mylib/mylib.go
> mylib/mylib_test.go
> mylib/tester/tester.go
> ```
> But I can't get the import to work:
> ```go
> package main
>
> import (
> "fmt"
> "mylib"
> )
>
> func main() {
> parser := mylib.Parser()
> fmt.Println(parser.AppName(), parser.Version())
> }
> ```
> The error I get is `tester/tester.go:8:2: package garg is not in 
> GOROOT`, which is perfectly correct.
> So then I tried to change the import to `../mylib`, but that also 
> produces an error, `tester/tester.go:8:2: "../mylib" is relative, but 
> relative import paths are not supported in module mode`
>
> Is what I'm trying to do possible? If so, how? If not, what d'you 
> recommend?
>
>

-- 
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/db872007-dd11-4e16-9324-b9fb4d8e4b42n%40googlegroups.com.

Re: [go-nuts] Re: There is a passage in book that is difficult to understand, can anyone help explain it?

[Robert Engels]

I am curious though for an example that shows how a reentrant lock could 
violate this?

> On Nov 2, 2022, at 2:38 AM, peterGo  wrote:
> 
> 
> Guanyun,
> 
> I tried to think of a simple example.
> 
> type Average struct {
> sum   float64
> count int64
> mxsync.Mutex
> }
> 
> https://go.dev/play/p/4SLCLuqG246
> 
> 1. An invariant represents a condition that does not change while the process 
> progresses - Niklaus Wirth.
> 
> 2. The additional invariant--Average = sum / count--is specific to the data 
> structure that the mutex mx guards.
> 
> 3. The shared variables sum and count are part of an invariant.
> 
> 4. The Add method temporarily violates the invariant by updating sum but 
> restores the invariant by updating count.
> 
> Peter
> 
>> On Wednesday, November 2, 2022 at 12:49:41 AM UTC-4 name@gmail.com wrote:
>> Hello,
>> 
>> This is a passage in book :
>> 
>> There is a good reason Go’s mutexes are not re-entrant.
>> 
>> The purpose of a mutex is to ensure that certain invariants of the shared 
>> variables are
>> maintained at critical points during program execution.
>> 
>> One of the invariants is "no goroutine is accessing the shared variables", 
>> but there may be additional invariants specific to the data structures that 
>> the mutex guards.
>> 
>> When a goroutine acquires a mutex lock, it may assume that the invariants 
>> hold. While it holds the lock, it may update the shared variables so that 
>> the invariants are temporarily violated.
>> 
>> However, when it releases the lock, it must guarantee that order has been 
>> restored
>> and the invariants hold once again.
>> 
>> Although a re-entrant mutex would ensure that no other goroutines are 
>> accessing the shared variables, it cannot protect the additional invariants 
>> of those variables.
>>  
>> 
>> 
>> This passage is difficult for me to understand:
>> 1. How to understand invariants "invariants"?
>> 2. What kind of scenarios does “additional invariants” refer to?
>> 3. What is the relationship between "shared variables" and "invariants"?
>> 4. What does "...guarantee that order has been restored..." mean?
>> 
>> Thanks,
>> Guanyun
> 
> -- 
> 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/c2b53c11-4552-4b9a-a528-fc179ba0f513n%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/6F217FB7-077E-4CBE-B46E-4ADB7D7461A3%40ix.netcom.com.

Re: [go-nuts] How do I set a pkg's version?

[Chris Burkert]

We used the traditional way for a long time. But with the embed package we
stopped this. This is a good blog post on the topic:
https://levelup.gitconnected.com/a-better-way-than-ldflags-to-add-a-build-version-to-your-go-binaries-2258ce419d2d
.

Am Mi., 2. Nov. 2022 um 09:54 Uhr schrieb Jakob Borg :

> On 2 Nov 2022, at 09:47, 'Mark' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>
> Oh, except that debug.BuildInfo (unsurprisingly) is only available in
> debug not release builds. So I guess the answer is that there isn't any
> nice way to do it.
>
>
> What do you mean by debug vs release builds? I don't think Go makes that
> distinction.
>
> That said, the build info will not contain information about your tags and
> such. The traditional way to add that is to have a build script inject that
> using `-ldflags -X ...` to set the value of some variables in the program.
>
> //jb
>
> --
> 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/885E5726-E0CD-46B2-B572-900A2E87AE07%40kastelo.net
> 
> .
>

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

[go-nuts] Re: Trying to create a test app for a library package

[Brian Candler]

In mylib/tester/tester.go:

import (
"fmt
"github.com/me/mylib"
)

On Wednesday, 2 November 2022 at 08:41:24 UTC Mark wrote:

> I have this layout:
> ```
> mylib/
> mylib/go.mod # module github.com/me/mylib
> mylib/mylib.go
> mylib/mylib_test.go
> ```
> All this works fine, with both .go files being in the same pkg: mylib.
>
> However, there are some tests that I can't really do using the test module 
> because they write to stdout. So I want to create an exe for regression 
> testing.
>
> In particular I want the regression tester to be in package main (just 
> like an app that uses mylib).
>
> I've tried this layout:
> ```
> mylib/
> mylib/go.mod # module github.com/me/mylib
> mylib/mylib.go
> mylib/mylib_test.go
> mylib/tester/tester.go
> ```
> But I can't get the import to work:
> ```go
> package main
>
> import (
> "fmt"
> "mylib"
> )
>
> func main() {
> parser := mylib.Parser()
> fmt.Println(parser.AppName(), parser.Version())
> }
> ```
> The error I get is `tester/tester.go:8:2: package garg is not in GOROOT`, 
> which is perfectly correct.
> So then I tried to change the import to `../mylib`, but that also produces 
> an error, `tester/tester.go:8:2: "../mylib" is relative, but relative 
> import paths are not supported in module mode`
>
> Is what I'm trying to do possible? If so, how? If not, what d'you 
> recommend?
>
>

-- 
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/f52ebcfd-11c1-4624-baf6-b6a80d12e108n%40googlegroups.com.

[go-nuts] about upstream?

[xie cui]

there are two micro service writen in go, let's call them A and B. A will 
call B. In this scene we will call B is the upstream of A. or A is the 
upstream of B? which one is correct way?

-- 
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/b76e3c7d-5d8c-4998-a743-ea93535b96bfn%40googlegroups.com.

Re: [go-nuts] How do I set a pkg's version?

[Jakob Borg]

On 2 Nov 2022, at 09:47, 'Mark' via golang-nuts  
wrote:

Oh, except that debug.BuildInfo (unsurprisingly) is only available in debug not 
release builds. So I guess the answer is that there isn't any nice way to do it.

What do you mean by debug vs release builds? I don't think Go makes that 
distinction.

That said, the build info will not contain information about your tags and 
such. The traditional way to add that is to have a build script inject that 
using `-ldflags -X ...` to set the value of some variables in the program.

//jb

-- 
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/885E5726-E0CD-46B2-B572-900A2E87AE07%40kastelo.net.

Re: [go-nuts] How do I set a pkg's version?

['Mark' via golang-nuts]

Oh, except that debug.BuildInfo (unsurprisingly) is only available in debug 
not release builds. So I guess the answer is that there isn't any nice way 
to do it.

On Wednesday, November 2, 2022 at 8:31:29 AM UTC Mark wrote:

> I hadn't realised about debug.BuildInfo - thanks!
>
> On Tuesday, November 1, 2022 at 9:15:02 PM UTC axel.wa...@googlemail.com 
> wrote:
>
>> It feels like an oversight not to mention debug.BuildInfo 
>>  here. No CI/CD or 
>> manual build steps required.
>>
>> On Tue, Nov 1, 2022 at 9:55 PM Chris Burkert  wrote:
>>
>>> During CI/CD we create a json file with a few details (git tag, branch, 
>>> hash, date, time). Afterwards we compile Go Code which embeds this file 
>>> into the binary. During runtime flags like --version print the json.
>>>
>>> Note that this is about the version of some binary - not the version of 
>>> a package. However, you could embed go.mod. But there may be better ways.
>>>
>>> Hope this helps.
>>>
>>> 'Mark' via golang-nuts  schrieb am Di. 1. 
>>> Nov. 2022 um 16:34:
>>>
 I am creating a pkg.
 It has a `go.mod` file:
 ```
 module github.com/.../mypkg

 go 1.19
 ```
 And code files with functions in .go files all in the mypkg pkg.

 How do I specify which version the mypkg pkg is? I know about using `$ 
 git tag vX.Y.Z` and `$ git push origin vX.Y.Z`, but is there any way I can 
 have this version in a file that can be accessed at build time or runtime?

 -- 
 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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/0a16b738-59e5-4885-90c8-cd168e308623n%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...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CALWqRZov4r%2BN2FiZug5mmwUwhYcvf08922UQU%3DMqfJKLFT8dBg%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/09ab0bb7-3c1e-48da-a5c1-79c0d3f1968dn%40googlegroups.com.

[go-nuts] Trying to create a test app for a library package

['Mark' via golang-nuts]

I have this layout:
```
mylib/
mylib/go.mod # module github.com/me/mylib
mylib/mylib.go
mylib/mylib_test.go
```
All this works fine, with both .go files being in the same pkg: mylib.

However, there are some tests that I can't really do using the test module 
because they write to stdout. So I want to create an exe for regression 
testing.

In particular I want the regression tester to be in package main (just like 
an app that uses mylib).

I've tried this layout:
```
mylib/
mylib/go.mod # module github.com/me/mylib
mylib/mylib.go
mylib/mylib_test.go
mylib/tester/tester.go
```
But I can't get the import to work:
```go
package main

import (
"fmt"
"mylib"
)

func main() {
parser := mylib.Parser()
fmt.Println(parser.AppName(), parser.Version())
}
```
The error I get is `tester/tester.go:8:2: package garg is not in GOROOT`, 
which is perfectly correct.
So then I tried to change the import to `../mylib`, but that also produces 
an error, `tester/tester.go:8:2: "../mylib" is relative, but relative 
import paths are not supported in module mode`

Is what I'm trying to do possible? If so, how? If not, what d'you recommend?

-- 
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/b9511da6-2e48-44ec-a16a-7985614632f7n%40googlegroups.com.

Re: [go-nuts] How do I set a pkg's version?

['Mark' via golang-nuts]

I hadn't realised about debug.BuildInfo - thanks!

On Tuesday, November 1, 2022 at 9:15:02 PM UTC axel.wa...@googlemail.com 
wrote:

> It feels like an oversight not to mention debug.BuildInfo 
>  here. No CI/CD or 
> manual build steps required.
>
> On Tue, Nov 1, 2022 at 9:55 PM Chris Burkert  wrote:
>
>> During CI/CD we create a json file with a few details (git tag, branch, 
>> hash, date, time). Afterwards we compile Go Code which embeds this file 
>> into the binary. During runtime flags like --version print the json.
>>
>> Note that this is about the version of some binary - not the version of a 
>> package. However, you could embed go.mod. But there may be better ways.
>>
>> Hope this helps.
>>
>> 'Mark' via golang-nuts  schrieb am Di. 1. 
>> Nov. 2022 um 16:34:
>>
>>> I am creating a pkg.
>>> It has a `go.mod` file:
>>> ```
>>> module github.com/.../mypkg
>>>
>>> go 1.19
>>> ```
>>> And code files with functions in .go files all in the mypkg pkg.
>>>
>>> How do I specify which version the mypkg pkg is? I know about using `$ 
>>> git tag vX.Y.Z` and `$ git push origin vX.Y.Z`, but is there any way I can 
>>> have this version in a file that can be accessed at build time or runtime?
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/0a16b738-59e5-4885-90c8-cd168e308623n%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CALWqRZov4r%2BN2FiZug5mmwUwhYcvf08922UQU%3DMqfJKLFT8dBg%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/ac35d44d-5795-45d3-9b46-5bfd643d2a34n%40googlegroups.com.

[go-nuts] Re: There is a passage in book that is difficult to understand, can anyone help explain it?

[peterGo]

Guanyun,

I tried to think of a simple example.

type Average struct {
sum   float64
count int64
mxsync.Mutex
}

https://go.dev/play/p/4SLCLuqG246

1. An invariant represents a condition that does not change while the 
process progresses - Niklaus Wirth.

2. The additional invariant--Average = sum / count--is specific to the data 
structure that the mutex mx guards.

3. The shared variables sum and count are part of an invariant.

4. The Add method temporarily violates the invariant by updating sum but 
restores the invariant by updating count.

Peter

On Wednesday, November 2, 2022 at 12:49:41 AM UTC-4 name@gmail.com 
wrote:

> Hello,
>
> This is a passage in book :
>
> 
> There is a good reason Go’s mutexes are not re-entrant.
>
> The purpose of a mutex is to ensure that certain invariants of the shared 
> variables are
> maintained at critical points during program execution.
>
> One of the invariants is "no goroutine is accessing the shared variables", 
> but there may be additional invariants specific to the data structures that 
> the mutex guards.
>
> When a goroutine acquires a mutex lock, it may assume that the invariants 
> hold. While it holds the lock, it may update the shared variables so that 
> the invariants are temporarily violated.
>
> However, when it releases the lock, it must guarantee that order has been 
> restored
> and the invariants hold once again.
>
> Although a re-entrant mutex would ensure that no other goroutines are 
> accessing the shared variables, it cannot protect the additional invariants 
> of those variables.
>
>  
> 
>
> This passage is difficult for me to understand:
> 1. How to understand invariants "invariants"?
> 2. What kind of scenarios does “additional invariants” refer to?
> 3. What is the relationship between "shared variables" and "invariants"?
> 4. What does "...guarantee that order has been restored..." mean?
>
> Thanks,
> Guanyun
>

-- 
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/c2b53c11-4552-4b9a-a528-fc179ba0f513n%40googlegroups.com.

Re: [go-nuts] Understanding some gotchas with linking slices together via indexing

[burak serdar]

On Tue, Nov 1, 2022 at 10:49 PM Brian, son of Bob 
wrote:

> Can anyone explain these gotchas (demo )?
> I've tried reading articles on this [one
> , two
> ]
> but they don't go into enough detail.
>
>
> *Slight gotcha #1: arr[:N] only creates a linked slice when N < len(arr)
> and arr[N:] only creates a linked slice when N>0.*
> E.g. `y` is linked here:
> y := x[:len(x) - 1]
> and here:
> y := x[1:]
>
> But not here
> y := x[:len(x)]
> or here:
> y := x[0:]
>

There is no "linked" slice. A slice is simply three values: pointer to an
array, length, and capacity. If x is a slice, then

y:=x[j:k]

means

y.array = [j]
y.cap=x.cap-j
y.len=k-j

So x[0:] is simply equal to x, and x[1:] is a slice that doesn't have the
first element of x.



>
> Also AFAICT, it's impossible create a link to an empty/nil slice unless
> you use pointers.  And I'm not sure if it's possible to create a linked
> slice that looks at all of the elements in the original without using a
> pointer.
>
> I kind of understand where the Go designers were coming from since it is
> probably more efficient to avoid copying all the time.  Though by that
> logic, I'd still think x[0:] would create a linked slice.
>

This is not about efficiency. An array is a fixed-length data structure,
and if you pass arrays around, you'll get copies of it. A slice is a view
of an array.


>
>
> *Gotcha #2: Appending to a linked slice affects the original slice but not
> the other way around*
> E.g. if `y` is linked to `x` via `y :=  x[1:], then:
> - appending to `y` *might* affect x (see Gotcha #3!)
> - appending to `x` won't affect `y`
> If there is a link, why does it not work both ways?
>

Appending to a slice will append the element to the underlying array if the
slice has capacity. Otherwise, it will allocate a larger array, copy the
old one into the new array, and append to the new array. Because of this,
if you do:

x:=append(y,elem)

If y has enough capacity, then both x and y will point to the same array
that will contain elem. If not, a new array will be allocated, elem will be
appended to it, and x will point to that new array while y will continue to
point to the old array.



>
>
> *Gotcha #3: Using variadic args to append to a linked slice doesn't affect
> the other one*
> If `y` is linked to `x` via `y :=  x[:len(x) - 1], then
> - append(y, 1) affects x
> - append(y, 1, 2) doesn't affect x
> I really don't get this one.
>

This is same as the above case.


>
>
>
> Thanks for any insights!
>
> --
> 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/7e2b82cc-f5f4-4fe4-ba73-0ff4dead66f7n%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/CAMV2Rqr8oJUnO7chga32VK83rP3XQduEfTJnm%3DjwZCno1nFdpw%40mail.gmail.com.