Re: [go-nuts] Equality of interface of an empty struct - why?

[Marvin Renich]

* Kurtis Rader  [240227 03:10]:
> On Mon, Feb 26, 2024 at 11:52 PM tapi...@gmail.com 
> wrote:
> 
> > On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote:
> >
> > On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com 
> > wrote:
> >
> > > From common sense, this is an obvious bug. But the spec is indeed not
> > clear enough.
> > > It doesn't state whether or not comparisons of pointers to two distinct
> > zero-size variables should be consistent in a run session.
> > > Though, from common sense, it should.
> >
> > "Pointers to distinct zero-size variables may or may not be equal."
> >
> > The outcome is specified to be not predictable. Expecting consistency
> > means the outcome should be, or eventually become, predictable. That's
> > the opposite of what the specs say.
> >
> >
> > Then I would argue that the spec never guarantee (x != y) == ! (x == y).
> > for values of any types (including non-zero-size types). :D
> >
> 
> The spec is reasonably clear that guarantee does apply to pointers to
> non-zero size variables (e.g., non-empty structs). The issue in this
> discussion thread is limited to the handling of pointers to zero size
> variables.

I interpreted this thread as being about the inconsistency between the
way pointers to zero-size variables were compared vs. non-zero-size
variables.  His comment looks perfectly on-topic to me.

> Precisely because of optimizations the compiler may, or may not,
> perform regarding the value of such pointers. I would prefer a stronger
> guarantee regarding pointers to zero size variables, and it looks like a
> lot of Go users agree with you and me, but that doesn't mean the current
> behavior is ipso facto broken or useless. Pointers to zero size variables
> (e.g., empty structs) are a special-case that the Go designers decided to
> leave ambiguous for now.

I have to agree with tapir.  Prior to generics, the type of the
arguments to == were easily known to the programmer, and so it was
obvious when this "undefined" exception would raise its ugly head, and
you just didn't use it for empty struct types.  But now, with generics,
this can only be classified as a glaring BUG in the spec.  How can a
programmer count on x == y having any meaning at all in code like this:

func IsEqual[T comparable](x, y T) bool {
return x == y
}

if the definition of == for empty structs is undefined?  And especially
if the result is different depending on whether or not code outside this
function has called  for z passed as an argument?
https://gotipplay.golang.org/p/ymhsDmJWv8l

If we can at least agree that this ambiguity is no longer desirable,
let's consider the two possible definitions:

1. Pointers to distinct zero-size variables are equal:

This allows the compiler to easily optimize virtual address usage, but
is inconsistent with the non-zero-size definition.

2. Pointers to distinct zero-size variables are not equal:

This is consistent with the non-zero-size definition, but the
implementation would likely require distinct virtual addresses for
distinct variables.  Whether this would require committed memory
corresponding to those virtual addresses is unclear to me.

Definition 1 removes the distinction between empty struct values and
empty struct instances, and the only way for the programmer to get that
distinction back is by using a non-empty struct.

On the other hand, definition 2 preserves the distinction.  If a
programmer wants to have instances compare as equal, it is often very
easy to use instances of the empty type rather than instances of a
pointer to the empty type.  Implement the methods on the type with value
receivers rather than pointer receivers.

...Marvin

-- 
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/Zd41i3rHLskqBuef%40basil.wdw.

Re: [go-nuts] When i try to input name from keyboard it is not taking the input

[Marvin Renich]

* Marvin Renich  [240220 10:52]:
> * Sagar Byahatti  [240220 08:22]:
> >  package main
> > 
> > import "fmt"
> > 
> > func main() {
> > 
> > var projectName = "APY"
> > var sub = 50
> > 
> > fmt.Println("Welcome to", projectName, " the number of subscriber is ", 
> > sub)
> > fmt.Println("Enter your name: ")
> > var userName string
> > 
> > fmt.Scan()
> > 
> > fmt.Printf("%v, your PRAN Number is", userName)
> > 
> > }
> 
> fmt.Scan is probably not what you want, though if I run your program and
> type a single word (no spaces) and then a newline, I get the result that
> I think you are expecting.
> 
> You probably want to look at the bufio package, and specifically the
> Reader.ReadString method.  Something like (untested)
> 
> var input = bufio.NewReader(os.Stdin)
> var userName, err = input.ReadString('\n')

Then use strings.TrimSpace on userName to get rid of the trailing '\n'
and any other leading or trailing blanks:

userName = strings.TrimSpace(userName)

Don't forget to check err for non-nil and handle the error accordingly.

...Marvin

-- 
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/ZdTPThtHUdDnioHq%40basil.wdw.

Re: [go-nuts] When i try to input name from keyboard it is not taking the input

[Marvin Renich]

* Sagar Byahatti  [240220 08:22]:
>  package main
> 
> import "fmt"
> 
> func main() {
> 
> var projectName = "APY"
> var sub = 50
> 
> fmt.Println("Welcome to", projectName, " the number of subscriber is ", 
> sub)
> fmt.Println("Enter your name: ")
> var userName string
> 
> fmt.Scan()
> 
> fmt.Printf("%v, your PRAN Number is", userName)
> 
> }

fmt.Scan is probably not what you want, though if I run your program and
type a single word (no spaces) and then a newline, I get the result that
I think you are expecting.

You probably want to look at the bufio package, and specifically the
Reader.ReadString method.  Something like (untested)

var input = bufio.NewReader(os.Stdin)
var userName, err = input.ReadString('\n')

...Marvin

-- 
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/ZdTKkauBRy02Hh7w%40basil.wdw.

Re: [go-nuts] "yield" is backwards

[Marvin Renich]

* mspre...@gmail.com  [240207 10:43]:
> The go language is getting better and better for functional programming, 
> and I am here for it. I have enjoyed using APL, Scheme, Python. I was 
> excited to see https://go.dev/wiki/RangefuncExperiment . However, I am 
> puzzled by the choice to name the function parameter that _receives_ a 
> Seq's values "yield". That func does the _complement_ to "yield", it 
> _receives_ the value. Compare with Python's "yield" statement, which 
> _provides_ the value. Couldn't we call the func parameter that receives a 
> Seq's values something like "receive" or "consume"?

In addition to what Axel said, note that "yield" is just an arbitrary
function argument name; you may name it anything you choose.  Try
changing "yield" to "abc" and it will still work.

...Marvin

-- 
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/ZcPJPw2X8IbABwpu%40basil.wdw.

Re: [go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?

[Marvin Renich]

* Robert Engels  [231115 12:29]:
> What I’m suggesting is that imagine a dev changes that code and has
> version() access the request property…

Okay, that makes sense.

> This is why if you are sharing data in a concurrent way you need to be
> very careful of all usages. 

Absolutely.

> The safest solution is to use immutable objects - of which the non
> pointer are. 

Perhaps, but it is not appropriate in many cases.

> So saying - just use pointer receivers - woefully underestimates the
> work to do shared concurrent code correctly. 

True.

I don't think there should be a default answer to "Which kind of
receiver should be used by default?"  Each type deserves a deliberate
choice.

The thought process should include questions like:

  Must the object be mutable?
  Is the object large enough and will it be passed around enough that
copying it is likely to be a performance issue?
  Will the type be assigned to an interface?  How will its receiver type
affect its usage there?

When an object of a particular type is to be used concurrently, the
design of the type and its methods deserve careful thought, and no
"default answer" for any part of the design is going to do that thought
for you, whether it is receiver type, access control, or
synchronization.

...Marvin

-- 
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/ZVURLIhbhoweVWSo%40basil.wdw.

Re: [go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?

[Marvin Renich]

* Robert Engels  [231114 21:55]:
>Switching to pointer receivers everywhere actually makes this worse. Any
>access is potentially a data race. 
>It stills seems like this is a compiler issue. There needs to be a way to
>synchronize the pointer to value copy in conjunction with other
>synchronization. 
>The only way to do this would be to write your own pointer to value
>conversion methods that have synchronization. 

I don't understand what you are saying.  Are you saying that if you take
the code from Dave Cheney's article, and change the receiver for the
version method from value to pointer:

  func (*RPC) version() int {

that there is still a race in his code?  Or are you saying that with
that change you could add code where the act of calling a method is
inherently a race?  If the latter, can you give an example?

...Marvin

-- 
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/ZVTyykWUgiwPLH9n%40basil.wdw.

Re: [go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?

[Marvin Renich]

* burak serdar  [231114 19:09]:
> I do not agree that this is because how the compiler works. A value
> receiver is equivalent to pass-by-value argument, that is:
> 
> rcp.version()
> 
> is equivalent to:
> 
> RPC.version(rpc)
> 
> thus, creating the copy of the rpc variable. So, the compiler may
> choose to avoid the race by not copying it, or by inlining the version
> function, but according to the spec, it is passed by value, i.e., it
> is copied.

I was going to say that the compiler must not optimize away the copy
because it changes behavior, but thinking it through, it may optimize
away the copy if it can determine that doing so will not change the
behavior of a program that does not violate the language spec (or memory
model).

On a more esoteric note, while this is definitely a race and there are
no "benign" data races, I am unaware of any current, commodity computer
architectures on which the race in Dave Cheney's article will create any
output other than what was expected.

This is based on the assumption that current mass-marketed computers
have the property that a read-during-concurrent-write will never end up
with non-deterministic values anywhere but the result of the read.  I.e.
if memory location A is being copied to memory location B, while
concurrently value Y is being written to A, then when the two concurrent
operations are finished, A will have value Y, B will have a
non-deterministic value, and no other memory locations will be affected.

If there are CPU/architectures that do not conform to this, that are
currently being produced, and to which Go has been ported, I would be
interested to hear about them (even if they are not mass-marketed
computers).

What makes a data race _never_ benign is portability.  Compiler writers
must obey both the language spec and the CPU/architecture spec.  A data
race (according to the language spec) that is thought to be benign adds
a third spec that the compiler writers _do not_ need to obey:  the
specific behavior of the hardware architecture when code written in that
language does not obey the language spec (or memory model).  The race
may be benign on specific combinations of compiler version and hardware
architecture version, but both hardware designers and compiler writers
are free to build new versions that do not conform to the spec that the
programmer implicitly created when writing the "benign" data race.

...Marvin

-- 
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/ZVTvQzxn2KQglaq8%40basil.wdw.

Re: [go-nuts] no way to pause `Listen` on net connections

[Marvin Renich]

* David N  [230724 01:11]:
> I've posted this question on stackoverflow
> ,
> discussed it with some members of the golang community, and I was
> encouraged to post here.
> 
> Problem: I have a secure application and I want to pause/resume accepting
> network connections, calling `l.Accept()` blocks the thread, thus you can't
> pause in a single-thread program. You can use goroutines but that still
> isn't ideal, as the routine would still accept the connection first and
> only then can close it if you're in "pause" mode.
> 
> This could be solved by:
> - having a non-blocking, async, `l.Accept()`
> - returning a handle to (accepting) goroutine and killing/re-creating it
> from main thread
> - accepting connections in a separate process and communicating over a
> socket
> 
> The 1st one doesn't exist, the 2nd one is not accepted by the language
> designers, and the 3rd one is unnecessarily complex and prone to break.
> 
> This looks like a shortcoming of golang, is it worth discussing further
> with lang designers?

I think a much more robust solution, which doesn't require any of the
tricks mentioned so far in this thread, would be to have a goroutine
that loops waiting for a signal (e.g. from a chan) and then uses
ListenConfig to create a Listener with a Context.  When you want to
pause, simply use the Context to cancel the Listener.  When you want to
resume, send the signal.

...Marvin

-- 
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/ZL5/6qpQNHsfHTvz%40basil.wdw.

Re: [go-nuts] Re: Gorilla toolkit - mux with http.FileServer returning 404

[Marvin Renich]

* zhiwei dong  [230322 00:47]:
> The 127.0.0.1:8084/apidoc/  return a 404
> 
> Demo
> package main
> 
> import (
>   "fmt"
>   "github.com/gorilla/mux"
>   "net/http"
> )
> 
> func main() {
>   router := mux.NewRouter()
>   router.PathPrefix("/apidoc/").Handler(http.StripPrefix("/apidoc/", 
> http.FileServer(http.Dir("api-swagger"

I think you are missing

http.Handle("/", router)

>   if err := http.ListenAndServe(":8084", nil); err != nil {
> fmt.Println(err)
>   }
> }

...Marvin

-- 
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/ZBrtrVrwEFxt9lH3%40basil.wdw.

Re: [go-nuts] How to fix an awful marshal reflection hack

[Marvin Renich]

* 'Mark' via golang-nuts  [221201 05:17]:
> I tried that and it works in the playground, and I added more types and it 
> still works in the playground .
> But in my program it still doesn't work:-( 
> The actual code is here tdb-go  
> in the file marshal.go from line 133 function marshalTableMetaData().
> If you run: go test it all works; but if you replace the call to hack() and 
> use nullable as you did in the playground, some of the tests fail.

You don't show the code that doesn't work (i.e. with nullable).  Did you
make a typo like you did in your code below?

> On Thursday, December 1, 2022 at 9:45:48 AM UTC kortschak wrote:
> 
> > On Thu, 2022-12-01 at 00:33 -0800, 'Mark' via golang-nuts wrote:
> > > Thanks. I've now tried that as follows:
> > >
> > > fmt.Printf("@@: %T %v\n", field, field)
> > > kind = field.Type().Elem().Kind()
> > > fmt.Printf("##: %T %v\n", field, field)

Note that in both Printf statements, you are using field rather than
kind.  If the two Printf's gave different results, I would consider it a
compiler bug (a really egregious one!).

> > > In every case the output for kind before and after was identical.
> > > (Naturally, I tried without the print statements too.) And, of course
> > > the tests fail. So I'm _still_ using the awful hack!
> > >
> >
> > Doesn't this do what you want?
> >
> > https://go.dev/play/p/7jUw_iW8B_8

...Marvin

-- 
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/Y4ingqhI/Ecydypd%40basil.wdw.

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 

Re: [go-nuts] filepath.walk in Go 1.19

[Marvin Renich]

* Robert Solomon  [221028 07:36]:
> On ubuntu 22.04, I would like the walk function to NOT follow symlinks to 
> other filesystems.  The find command uses the -xdev switch to achieve this.
> 
> How can I get walk to behave like the -xdev switch to find?

On Linux:

 getdevid_linux.go

package main

import (
"io/fs"
"syscall"
)

type DevId uint64

// GetDevice returns the Device ID on which the given file resides.
func GetDevice(path string, fi fs.FileInfo) DevId {
var stat = fi.Sys().(*syscall.Stat_t)
return DevId(stat.Dev)
}



Then before calling filepath.Walk, filepath.WalkDir (more efficient), or
fs.WalkDir, obtain the device ID of the root.  In the call to WalkDir,
pass this device ID to your walk function:

err = filepath.WalkDir(root, func(path string, d fs.DirEntry, err
error) error { return MyWalkFn(devId, path, d, err) })

In MyWalkFn, use d to obtain the device ID of the current path, and
return fs.SkipDir if the device IDs do not match.

...Marvin

-- 
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/Y1vHqjKVfQqM3gZy%40basil.wdw.

Re: [go-nuts] what is the origin of Go's reference time system?

[Marvin Renich]

* Ayan George  [221026 13:51]:
> 
> I'm really impressed by the simplicity of Go's time formatting and parsing 
> mechanisms -- particularly when compared with strftim().

I have to disagree.  This is the most egregious design flaw of the
standard library, and the second worst design flaw of the language.

First, every single programmer who has used any other C-like language
knows %y %m %d %H %M %S.  For English speakers (native or as a second
language), these have mnemonic associations with the values they
represent.  When writing a strftime format, there is no reason to look
at the man page for common usage.

For Go's Time.Format, it is almost always necessary to refer to the
documentation to get the correct numbers, or to at least think
"month/day hour:minute:second" and then apply numbers to them.  When
formatting a date, I almost always want a year; where is that in the
order?  Before month (where it should be)?  No!  Between day and hour as
in typical US formatting?  Sorry, wrong again.  This is significantly
more cognitive load than using the mnemonics.

And this is just writing code; the cognitive load is even worse when
reading someone else's code, especially when doing a code review and
trying to make sure the other programmer did it correctly.

Second, Go's fmt.Printf uses % escapes for substitutions, but it uses a
completely different syntax for time formatting substitutions.
Really???  For a language that tries to be as simple and consistent as
possible, this doesn't make any sense, especially when there is already
a well-known %-escape model to start with.

Third, and worst of all, there is no way to escape literal digits in the
format string.  How do you write the Go equivalent of C's "%A, 4 minutes
after %H:%M"?  You either have to call Format twice and combine three
strings, or you have to do string substitution after calling Format.

The picture-style format string is a "cool" idea, but impractical for
real programming and a serious design flaw.  I have always wished that I
were able to convince the Go devs to add a new Time.FormatDoneRight that
used %-style formatting.  I would not copy C's "lots of letters for
different styles of the same value"; I would use modifiers like "%0m"
for two-digit month.  And I would give day-of-year its own letter (why
does day-of-year use the same number as day-of-month?)

...Marvin

-- 
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/Y1qAZwYwTlgXYIRp%40basil.wdw.

Re: [go-nuts] Re: behavior of %f

[Marvin Renich]

* Dante Castagnoli  [221010 18:01]:
> Thanks!
> 
> It's not lost, though.  It shows up with the %g form.
> 
> Knowing about %g, my issue is not extant, but others might hit it.  I'm 
> relatively new to floating point issues, and I saw numbers showing up as 
> integers, and it took a while to sort out what was going on, is all.
> 
> As the behavior matches "c", I would suggest at minimum making the 
> documentation clearer.
> 
> https://go.dev/play/p/WBlf3jltimr

Your comparison is flawed.  Take your original playground code (the one
with just %0.3f) and change the "f" to "g" without removing the "0.3"
and run it again.  You will see the same rounding behavior as with "f".

The documentation says:

  The default precision ... for %g ... is the smallest number of digits
  necessary to identify the value uniquely.

So without explicitly specifying the precision, %g will print as many
digits as necessary (i.e. enough precision is used to prevent rounding).

What representation, using only the precision specified, most closely
represents the value being formatted?  That is how you should think of
the floating point formatting behavior, rather than thinking of it as
rounding.

...Marvin

-- 
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/Y0VX94m6RoYs5X8i%40basil.wdw.

Re: [go-nuts] How to implement LogonUserA function (winbase.h)?

[Marvin Renich]

* Chandan Kumar  [220901 07:29]:
> Hi,
> 
> I am trying to implement a program in which I need the function *LogonUserA 
> function (winbase.h) *from windows API and this function is not available 
> in the package *golang.org/x/sys/windows* so any advice would be helpful.

First, you need to determine in which DLL the function is.  Suppose it
is in kernel32.dll:

import (
"golang.org/x/sys/windows"
"syscall"
"unsafe"
)

var (
modKernel32 = windows.NewLazySystemDLL("kernel32.dll")
procLogonUser = modKernel32.NewProc("LogonUserA")
)

func LogonUser(«arguments») («results», err error) {
var r1, ..., e1 = syscall.Syscall(procLogonUser.Addr(), «converted 
arguments», «fill with 0»)
// Convert results and error and return them.
}

I didn't bother to look up what the real arguments are to LogonUser, but
hopefully this gives you enough info to figure it out.  Pointers will
need to be converted like this:  uintptr(unsafe.Pointer(userName))  when
passing them to Syscall.

If you need more help, post the function signature for LogonUser.

...Marvin

-- 
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/YxCgeCaOs8nRIof6%40basil.wdw.

Re: [go-nuts] Testing custom error type (error type in struct)

[Marvin Renich]

* Bagas Sanjaya  [220901 06:04]:
> 
> ```
> package tester
> 
> import (
>   "testing"
> )
> 
> type Tests struct {
>   err error
> }
> 
> func TestErr (t *testing.T) {
>   cases := Tests{eTest,}
   ^
This is at least one of the problems.  You must create an instance of
eTest:

cases := Tests{{"what?"}}

This will compile, but the test will fail because actual points to a
different instance of eTest than the one in Tests.

> 
>   t.Run("now testing", func (t *testing.T) {
>   actual := Err()

Depending on what you intend, you can fix this one of two ways.  You can
compare the output of the Error methods:

if actual.Error() != cases.err.Error() {

or you can create a global  eWhat = {"what?"}  and then use eWhat
both in the definition of Err above and in the initializer for Tests.

>   if actual != cases.err {
>   t.Errorf("eh")
>   }
>   })
> }
> ```
> 
> But when I `go test`, I got build error:
> 
> ```
> # test-error [test-error.test]
> ./test-error_test.go:12:17: eTest (type) is not an expression
> ```
> 
> What was wrong above?

There is also a third way:  don't use a pointer receiver on

func (e eTest) Error() string {...}.

How to fix it will depend on how you intend to use eTest in your real
(non-testing) code.  Personally, if my error type needed only the
string, and not any additional fields that you have not shown because
you were simplifying your example, I would not use a struct, but a
string:

type eTest string

func (e eTest) Error() string {
return fmt.Sprintf("e? %s", e)
}

...Marvin

-- 
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/YxCbTehAyvzOuhRc%40basil.wdw.

Re: [go-nuts] Re: Do I need a reentrant locks?

[Marvin Renich]

* atd...@gmail.com  [220705 10:03]:
> :) That's what the asterisked note was for in the original question. I 
> don't think I can do that in the real code because the real code is much 
> more complex. Each node actually triggers a callback that may modify 
> another node. That callback is user-created, not framework created so I 
> have no way of knowing if the lock has already been taken.
> 
> And I wouldn't want for library users to have to make that distinction 
> themselves.

Have the Set method always take some type of context, which is a pointer
type.  If the context is nil, assume a top-level call to Set, otherwise
use the context to decide what to do.  All the callbacks will be
required to accept a context and pass it to the Set method.

If you have multiple goroutines that can be making top-level Set calls,
I see no way around using something to distinguish top-level calls from
Set within callbacks.

...Marvin

> On Tuesday, July 5, 2022 at 3:48:16 PM UTC+2 Brian Candler wrote:
> 
> > Have a public Set() that does the lock and then calls a private internal 
> > function, which assumes it's already running under the lock.
> > https://go.dev/play/p/M1XuC8bxCxL
> >
> > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote:
> >
> >> Hi,
> >>
> >> I have a tree datastructure where mutating some nodes *may *trigger a 
> >> mutation on some other tree nodes.
> >>
> >> This tree should be accessible by multiple goroutines but mutated by only 
> >> one at a time.
> >>
> >> As such, I wanted to have a global lock on the tree such that mutatiing 
> >> node methods should acquire this lock beforehand.
> >>
> >> But it seems to require for the mutex to be reentrant? 
> >>
> >> I have tried to create a very simplified*** model to illustrate 
> >> https://go.dev/play/p/v37cbYQ1jSY
> >>
> >> (***) I know people might want to suggest for the Set method to use a 
> >> lockless variant when iterating over the linked nodes but in the real 
> >> code, 
> >> it iterates over user created callbacks instead and I don't think I can 
> >> expect callbacks writers to juggle between the two kind of methods to 
> >> avoid 
> >> deadlocks.
> >>
> >> Any suggestion?
> >>
> >>

-- 
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/YsRLSsBPXIbN0Nob%40basil.wdw.

Re: [go-nuts] Re: Do I need a reentrant locks?

[Marvin Renich]

* Brian Candler  [220705 09:48]:
> Have a public Set() that does the lock and then calls a private internal 
> function, which assumes it's already running under the lock.
> https://go.dev/play/p/M1XuC8bxCxL
> 
> On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote:
> 
> > Hi,
> >
> > I have a tree datastructure where mutating some nodes *may *trigger a 
> > mutation on some other tree nodes.
> >
> > This tree should be accessible by multiple goroutines but mutated by only 
> > one at a time.
> >
> > As such, I wanted to have a global lock on the tree such that mutatiing 
> > node methods should acquire this lock beforehand.
> >
> > But it seems to require for the mutex to be reentrant? 
> >
> > I have tried to create a very simplified*** model to illustrate 
> > https://go.dev/play/p/v37cbYQ1jSY
> >
> > (***) I know people might want to suggest for the Set method to use a 
> > lockless variant when iterating over the linked nodes but in the real code, 
> > it iterates over user created callbacks instead and I don't think I can 
> > expect callbacks writers to juggle between the two kind of methods to avoid 
> > deadlocks.
> >
> > Any suggestion?
> >
> >

Note also that for referencing a Node to be safe, you must do one of two
things:  either use sync/atomic for all reads and writes of Num
(assuming the data in the tree is of a type that can be handled by
sync/atomic), or use sync.RWMutex instead of sync.Mutex, and use RLock
on reads and Lock on writes.

If Node has more than one data field, e.g. {Name string; Age int; ...},
you will have to go with the RWMutex option.

...Marvin

-- 
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/YsRGy7EdSxvtPoj3%40basil.wdw.

Re: [go-nuts] Re: Ignore stale read errors from the race detector

[Marvin Renich]

* Jeff Learman  [220610 13:23]:
> Unlike C, Go has no `volatile` keyword.  Therefore, the compiler is allowed 
> to cache a value that is never updated in the scope that it sees, and 
> there's no way for us to tell it not to do that.

Actually, sync/atomic does essentially the same thing that volatile does
in C.  Volatile ensures that the variable is not register-optimized,
that reads and writes to it are not optimized away when local code can
be proven to not observe those actions, and that reads and writes of
properly aligned values whose size is the machine word size happen
atomically (it also ensures proper alignment).  sync/atomic does just
that.

For Microsoft C/C++, for architectures other than arm, volatile, by
default, also prevents reordering of reads and writes to non-volatile
variables around a read or write to a volatile variable.  The ISO
definition of volatile explicitly does not require this, favoring the
std::atomic as the mechanism to effect this.

There was discussion a number of years back (8 or more?) about whether
the Go Memory Model explicitly specified, implicitly specified, or did
not specify that sync/atomic provided a guarantee about not reordering
non-atomic reads and writes around atomic operations.  The current
version of the memory models says under "Advice" near the beginning of
the document:

To serialize access, protect the data with channel operations or
other synchronization primitives such as those in the sync and
sync/atomic packages.

This sounds to me like an explicit declaration.

> Issues like this aren't 
> really data races, but they are caught by the race detector.

Yes, they are.  While amd64 and arm64 architectures will ensure, at the
CPU level, that a single instruction read or write to properly aligned
memory will always read or write the whole value atomically, not all
architectures do (especially many RISC architectures).  Also, without
explicit memory barrier instructions, the amd64 (and I think arm64)
instructions will not guarantee observability to other cores.

You really should read the link Nigel gave below.

The OP said "I do not want to use atomic operations or locking to remove
this race condition for performance reasons."  I believe the OP should
try sync/atomic.  It should not give any statistically significant
performance difference from using the volatile keyword in C, as I would
expect C to use a memory barrier for volatile accesses so that other
cores and other hardware on the bus can observe them.

...Marvin

> On Wednesday, June 7, 2017 at 8:47:02 AM UTC-4 Fuxin Hao wrote:
> 
> > "there is no guarantee that the write to done will ever 
> > be observed by main", i am wondering why the write to done will ever 
> > be observed by main in detail?
> >
> >
> > On Thursday, February 25, 2016 at 8:07:29 AM UTC+8, Nigel Tao wrote:
> >>
> >> On Tue, Feb 23, 2016 at 7:46 AM, Damian Gryski  wrote: 
> >> > On Monday, February 22, 2016 at 8:29:59 PM UTC+1, mikew...@gmail.com 
> >> > wrote: 
> >> >> I've been trying to find a way to ignore errors from the golang
> >> >> race detector. In particular I have a stats loop that does stale
> >> >> reads from for a variable that is updated constantly. In this
> >> >> case I do not care if the value of the read is stale and I do
> >> >> not want to use atomic operations or locking to remove this race
> >> >> condition for performance reasons. Does anyone know if there is
> >> >> a way to add something to the lines of code that read this value
> >> >> to tell the race detector to ignore errors coming from a
> >> >> specific line of code? 
> >> > 
> >> > You might be interested in 
> >> > 
> >> https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
> >>  
> >>
> >> See also the "an aggressive compiler might delete the entire go 
> >> statement" and "there is no guarantee that the write to done will ever 
> >> be observed by main" examples at https://golang.org/ref/mem 
> >>

-- 
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/YqTL5qnxLnGvNVzO%40basil.wdw.

Re: [go-nuts] Re: Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it?

[Marvin Renich]

* Amnon  [220510 12:52]:
> > I'm not sure why w.Write would freeze; is your process starting to swap
> > and it is not really frozen but just taking a long time? Is it being
> > killed by the kernel's out-of-memory monitor?
> 
> In the OP's code, w.Write was writing a large amount of data to a pipe, 
> while nothing was reading from the other end.
> This was the reason for the deadlock.

That makes sense.  Ah, now, looking through
https://groups.google.com/g/golang-nuts (I normally use email), I see a
different thread to which I had not paid attention.

...Marvin

-- 
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/Ynqfy11tpIEiLsHv%40basil.wdw.

Re: [go-nuts] Re: Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it?

[Marvin Renich]

* Const V  [220508 17:20]:
> Using r.ReadLine repeatedly I was able to read the full line in memory. It 
> is working very fast.
> 
> for isPrefix && err == nil {
> line, isPrefix, err = r.ReadLine()
> ln = append(ln, line...)
> }
> 
> if strings.Contains(s, "error") {
> 
> finds the substring very fast
> 
> Now is coming the last step - writing 100MB string to STDOUT
> w io.Writer
> w.Write([]byte(s))
> 
> It is too big and freezes with large string.

I'm not sure why w.Write would freeze; is your process starting to swap
and it is not really frozen but just taking a long time?  Is it being
killed by the kernel's out-of-memory monitor?

However, you shouldn't convert the []byte to string and then back to
[]byte again.  You are doing two huge allocations unnecessarily.  Also,
your code using ReadLine is doing essentially the same thing as
ReadBytes, and the documentation for ReadLine suggests using ReadBytes
instead.

Does https://go.dev/play/p/mSZ-Ft6C8pZ do what you want?

Note that if you are trying to be _really_ efficient, you should look at
the "Why Is Grep So Fast" article mentioned previously in this thread.
I would allocate a slice of large (1M? 10M?) byte slices, using them as
a ring buffer, adding one []byte to the ring at a time as needed.  Then
implement Boyer-Moore or Rabin-Karp in a way that handles the boundaries
between []byte buffers properly.  The total size of the ring buffer will
max out at the longest line, which is necessary anyway, and you will
minimize allocations and copying of data.

...Marvin

-- 
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/Ynp49ktp2CHKjucs%40basil.wdw.

Re: [go-nuts] go fails to detect a point-time race condition

[Marvin Renich]

* Zhaoxun Yan  [220430 02:29]:
> Hi Dan! 
> 
> I did as you told, but go build -race still not functions:

No, Dan said you must build with -race and then execute the output from
the build:

$ go build race race2
$ ./race2

What Dan was saying is that «go build -race» does _not_ detect races
during the build process, but produces an executable that contains the
race detector built-in, so that when you invoke the executable, any
races will be detected.

> zxun@zxun-virtual:~/src/race2$ go build 
> zxun@zxun-virtual:~/src/race2$ ls
> race2  race.go
> zxun@zxun-virtual:~/src/race2$ go build -race race2
> zxun@zxun-virtual:~/src/race2$ go run -race race.go
> ==
> WARNING: DATA RACE
[snip]
> Found 1 data race(s)
> exit status 66
> 
> 在2022年4月30日星期六 UTC+8 14:22:26 写道：
> 
> > On Fri, 2022-04-29 at 23:18 -0700, Zhaoxun Yan wrote:
> > > And then in that folder you run:
> > > # go build -race
> > > Nothing happens, at least in my go1.15
> >
> > The race detector needs to run to detect data races; it's not a static
> > analysis tool.
> >
> > So if you execute the binary that you built with `go build -race` you
> > should see the race report.
> >
> > Dan

-- 
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/Ym1hKW0D2hogcsGb%40basil.wdw.

Re: [go-nuts] evaluation of range expression in for-range loop

[Marvin Renich]

[Sorry, I accidentally set the Reply-To incorrectly in my previous msg;
corrected here.  I don't need a CC in responses.]

* Jan Mercl <0xj...@gmail.com> [220318 12:04]:
> On Fri, Mar 18, 2022 at 4:53 PM 'Axel Wagner' via golang-nuts
>  wrote:
> > I don't really know the answer to your question. I can't think of
> > anything which would break. That being said, I also don't think it's
> > something that really needs "fixing", as it seems a pretty uncommon
> > concern.
> 
> I don't think there's anything ambiguous here. The very first sentence
> here: https://go.dev/ref/spec#Constant_expressions says
> 
> 
> Constant expressions may contain only constant operands and are
> evaluated at compile time.
> 
> 
> f() does not fill that requirement for sure, it's not a constant
> operand and it cannot be evaluated at compile time (in the first
> approximation).
> 
> TBH, I thought that it was all clear from my first answer in this
> thread. The compiler error confirms the specs.

If you had included the above quote in your original response, I would
have agreed with you.  However, your other msg only contained a
playground link that demonstrated that the compiler believed the
expression to be non-constant without giving any explanation of why that
was correct according to the spec.

Axel's original response clearly explained why the spec mandated the
behavior that the OP was questioning.

On the other hand, Axel's response left me wondering why the part of the
spec he quoted was written the way it was, while your quote above at
least superficially justifies the parts of the spec Axel quoted which I
was questioning; thanks.

My question stems from the fact that

  var a = [3]{1, 2, f()}
  const x = len(a)

compiles with the obvious results, but

  const x = len([3]{1, 2, f()})

does not compile.  I.e. the value obtained from evaluating a composite
literal expression of array type has a constant length, so why is taking
the len() of that value different from assigning that value to a
variable and then taking the len() of the variable?

I was really looking for the language designers to chime in with a
justification, but I guess I can accept "we don't want constant
expressions to be allowed to have side effects" as the answer.

...Marvin

-- 
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/YjS9iaoKXSy4pQ0X%40basil.wdw.

Re: [go-nuts] evaluation of range expression in for-range loop

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [220318 08:04]:
> https://go.dev/ref/spec#Length_and_capacity says:
> 
> > The expression len(s) is constant if s is a string constant. The
> > expressions len(s) and cap(s) are constants if the type of s is an array or
> > pointer to an array and the expression s does not contain channel receives
> > or (non-constant) function calls; in this case s is not evaluated.
> > Otherwise, invocations of len and cap are not constant and s is evaluated.
> 
> So, in your case, the array contains a function call, so `len(…)` is not
> constant.

Is the intent of that paragraph in the spec to ensure that side effects
occur?  Clearly the length of [3]int{...} is constant, regardless of any
channel receives or non-constant function calls.

Why was the spec not written as:

    The expressions len(s) and cap(s) are constants if the type of s
  is an array or pointer to an array.  If the expression s does not
  contain channel receives or (non-constant) function calls, then s is
  not evaluated.  

And then in the documentation for the range clause, say something like:

  ...:  if at most one iteration variable is present, the range
  expression x is only evaluated if it would be evaluated by len(x).

This would allow

  const x = len([3]int{1, 2, f()})

to compile with the obvious side effects, but still result in x being a
constant.

Is there some other reason to force len([3]int{«non-constant
initializer»}) to be non-constant?

...Marvin

-- 
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/YjSm83cOcG1cACFP%40basil.wdw.

Re: [go-nuts] Inconsistency between calls to "os.Chtimes()" and "stat.Sys().(syscall.Stat_t).Mtimespec"

[Marvin Renich]

* Marvin Renich  [211015 08:04]:
> Also note that different filesystems on the same running host can have
> different resolutions.  FAT filesystems (e.g. USB memory sticks) have
> only 2-second resolution, while ext2 is, I think, 1 millisecond, and
> ext4 is 1 nanosecond.

According to [1], it appears ext2 and ext3 have only 1 sec resolution.

...Marvin

[1] http://softpanorama.org/Internals/Unix_filesystems/linux_ext2_ext3.shtml

-- 
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/YWlxG9gszPBxYIq6%40basil.wdw.

Re: [go-nuts] Inconsistency between calls to "os.Chtimes()" and "stat.Sys().(syscall.Stat_t).Mtimespec"

[Marvin Renich]

* Kurtis Rader  [211014 13:22]:
> Note that file timestamp resolution depends on the system: both hardware
> and OS. Even when using the same OS (e.g., Linux) on the same hardware the
> resolution might be different due to how the OS kernel was built. I'm not
> aware of any system that provides nanosecond resolution.

Also note that different filesystems on the same running host can have
different resolutions.  FAT filesystems (e.g. USB memory sticks) have
only 2-second resolution, while ext2 is, I think, 1 millisecond, and
ext4 is 1 nanosecond.

...Marvin

-- 
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/YWluC3ykzQjLsfD7%40basil.wdw.

Re: [go-nuts] What's going on while using "append" in memory?

[Marvin Renich]

* Henry  [210810 01:26]:
> Just sharing some tips.
> 
> When working with slices, it is often a good idea to lend a helping hand to 
> the compiler. 
> 
> Don't declare something like this, unless you have no other choices.
> ```
> var slice []int
> ```

I believe this is bad advice.

First, if «slice» is to be used to hold a view into a backing array
generated elsewhere, e.g. the result of another function, attempting to
pre-allocate a backing array that will never be used is wasteful.

If you are using «slice» to build a result, and you have a good idea
what the final size of the result will be, preallocating something a bit
larger than the typical result indeed can be a good idea.

If you know for sure exactly what the initial size is going to be, than
preallocating with make() won't hurt, but doesn't do any better than
letting the first append do the allocation.

However, trying to _guess_ the initial size is often a waste of an
allocation.

  var slice []int

allocates the three-word slice header, but does not allocate any backing
array.  The first append will allocate a backing array of the correct
size.

Suppose you have a good idea that the initial size will be 5, so you
write

  var slice = make([]int, 0, 5)

But than it turns out that the initial size is really 6:

  slice = append(slice, data[i:j]...)

where j-i is 6, now the initial allocation of 5 elements was wasted.

If you are appending single elements in a loop, as in your simple
examples, than your advice is somewhat more sound.  In those cases, the
"initial" size is always 1, but the "final" size is its size at the end
of the loop, so making an initial estimate makes a lot more sense.

The take-away is that slice variables are used in many different ways,
and your advice holds in specific use cases, such as building a result
by appending one element at a time.  It does not hold in many real, more
sophisticated, use cases.

...Marvin

-- 
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/YRJrRpCVoXiS8c73%40basil.wdw.

Re: [go-nuts] Re: How to implement this in golang?

[Marvin Renich]

[Please do not send images of text; copy and paste as text into the
message or into text attachments.]

* LetGo  [210629 11:25]:
> Thanks for the answer! (:
> In python it was straightforward to implement and it works like a charm. It 
> sends small packets with delay between each other without even care if it 
> is UDP or TCP:
> 
> [image: prooff.png]
> [image: proof2.png]

[snip]

> Il giorno martedě 29 giugno 2021 alle 14:22:32 UTC+2 Brian Candler ha 
> scritto:
> 
> > What sort of socket - TCP or UDP?  TCP is an infinite stream, and there is 
> > no reliable way to divide it into "chunks" (except possibly using the URG 
> > pointer, which is very rarely used).  There is no guarantee that waiting 
> > 1.6 seconds between sends will actually send in separate segments being 
> > sent, nor that the receiver will be able to determine that these were 
> > separate segments - they may well be merged.
> >
> > To do it reliably, you'd want to add your own framing, e.g. send an 4-byte 
> > length followed by that number of bytes.

What Brian is saying is that TCP, by definition, is not required to use
the same packets across the wire that you send out.  Packets in a TCP
stream _may_ be regrouped, both by being split into smaller packets and
by being joined into larger packets.  They are reassembled at the
receiving end of the TCP stream as a stream, not as individual packets.

It is very feasible for the receiving end to see packets with exactly
the contents of the individual "send" function calls when under normal
load, but see something completely different when CPU, network, or
memory pressure is applied to the sending system.

...Marvin

-- 
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/YNtNDRa837lmx5lz%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* Robert Engels  [210608 18:30]:
> I think the playground code I supplied is essentially a test case -
> and it works in the absence of concurrency or other held references
> (like putting it in a map). 

But it is one simple test case, not an appropriate set of tests.  Saying
that code passes one test says very little about its correctness.  It is
often very easy to intentionally (or inadvertently) write a single test
that passes, even though the code being tested is broken.

> I guess the bottom line for me is that faq says do not mix receiver
> types. There is either a valid reason for this or it should be
> removed. I think it is the former as it makes more usage patterns
> resilient to hard to track bugs. 

I think your MyEventRecorder is good anecdotal evidence that it is
usually better to not mix receiver types.  I don't think anyone is
saying that the FAQ is wrong, just that it is not an absolute.  I don't
think Axel was suggesting that this should be removed, he was just
giving an aside that he sometimes does not follow that advice, but he
knows why he does and accepts the responsibility for any mistakes as a
result.

> I must be very dense but I still don’t see the rationale behind not
> stating : use value receivers for immutable types and pointer
> receivers otherwise. There may be some fringe cases where this doesn’t
> hold - but if you can write the entire stdlib with this pattern it
> seems fairly stable. 

The way I read it, that is the primary advice in the
https://golang.org/doc/faq#methods_on_values_or_pointers section.  It
also gives some other considerations that may mitigate that advice.

...Marvin

-- 
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/YMAjJjDGsZfUpO7x%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [210608 02:54]:
> On Tue, Jun 8, 2021 at 6:36 AM Marvin Renich  wrote:
> 
> > You say that test cases of Log work fine, but they are only fine in a
> > non-concurrent environment.  The instant you test Log (without
> > interfaces) in a concurrent program it fails in an obvious manner.
> >
> 
> nit: I don't think concurrency has anything to do with it either. The
> failure mode is making a copy and expecting the copy and the original to
> share memory.

I agree.

> FWIW I agree with Robert that it's relatively easy to write a test for this
> that never copies the value (though even then, if you think about using
> atomics you definitely should think about writing a concurrent test and
> running it with `-race` enabled, which should show the problem).

Sure.

> I disagree with him, however, that interfaces make it more likely to run
> into the problem when *using* the code. Any even remotely realistic usage
> of that code is broken. Even if you failed to write tests which surface
> that breakage.

Right.  This is just one of many aspects of programming that require
careful consideration to get right.  As you keep saying, "this is
suboptimal" applies, but "the most inconsistent and obtuse aspect of the
Go language" is way too extreme of an assertion.

...Marvin

-- 
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/20210608151806.ebqigtzmdopb5qdq%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* Robert Engels  [210607 21:18]:
> (I think you pasted the wrong link - that is my code). 

subsequent correction acknowledged; assuming the following discussion is
about https://play.golang.org/p/-f73t_Pm7ur

> It is not about being unwilling to admit it. Your
> explanation/reasoning has not convinced me. 
> 
> Imagine some library declares the EventLogger interface as shown.
> Acceptable. Someone writes the RecordEvents() method taking an
> EventLogger. Acceptable. 
> 
> Now, I have a struct I want to use with as an EventLogger (badly named
> - really EventSource). The code I wrote works fine. Test cases (of
> Log()) work fine. It fails when used as a source to RecordEvents()
> (and similar held reference patterns). 

I have to agree with Axel.  This code is not fine, and it is easy to at
least notice that it is suspect, even if it requires more careful
examination to determine that it is wrong.  The fact that the Log method
has a value receiver and the Inc method has a pointer receiver is a very
obvious clue that this code needs careful review.  Next, Log takes a
value receiver, but is using synchronization (whether it is atomic or
mutex doesn't matter); this should be where the programmer realizes that
the code is broken.  And, as Axel keeps saying, it has nothing to do
with interfaces; the method on the struct is broken without any
interface being involved.

You say that test cases of Log work fine, but they are only fine in a
non-concurrent environment.  The instant you test Log (without
interfaces) in a concurrent program it fails in an obvious manner.

Interfaces, and their ability to potentially be satisfied by either a
non-pointer type or a pointer type, depending on the type, is not the
problem here.

...Marvin

-- 
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/20210608043609.gguu3t3hqbsziema%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [210607 19:06]:
> Well, it seems a bad idea to say that interfaces are implicitly pointers
> then. That seems to indicate that Rob's original phrasing is indeed an
> important clarification - the language behaves as if the value contained in
> them is copied when the interface value is copied.

I agree with most of what you are saying to Robert Engels, but I
disagree with this.  The FAQ needs to make it clear that making a copy
of the value happens when assigning a concrete value to an interface and
when extracting a concrete value from an interface, but that the
interface passed around does _not_ require the allocation overhead of
copying the concrete value every time the interface is copied (even if
it behaves, whenever the interface is used, as if a copy is made).

It is clear from this thread that this is a confusing topic, and also
that programmers new to Go are reading this FAQ entry and believing,
incorrectly, that to optimize memory allocations they should use
pointers when it is not necessary to do so.

In other words, there are two distinct aspects that both need to be
expounded in the FAQ:  the external behavior and the performance-related
consequences.  People are jumping to the wrong conclusion because the
FAQ says "copying the interface value makes a copy of the struct".  This
is simply untrue, and not necessary according to the language spec.

The correct statement is that "copying the interface value behaves as if
the struct is copied without actually needing to make a new copy of the
struct".  That second part is important.

...Marvin

-- 
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/20210608004229.3s3ftgrdy47guhic%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [210607 10:19]:
> FWIW I do tend to mix value and pointer receivers occasionally.
> Sometimes a type needs a pointer receiver in one method, but a different
> method doesn't and it's more convenient to have a copy available for
> temporary operations.

Axel, I believe you already understand this, but for others following
along who want to understand when it might be appropriate to do this, I
would like to point out that for a type T with method Foo that has a
value receiver and method Goo that has a pointer receiver, and interface
I with methods matching Foo and Goo, T does not satisfy I, but *T does.
This is just something to keep in mind when weighing the possibilities.

...Marvin

-- 
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/20210607184622.x6fqx3f5i6et4jbn%40basil.wdw.

Re: [go-nuts] Re: Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* Joshua  [210606 16:52]:
> > In most cases (or most cases in actual practice?) an interface can be 
> > thought of as a pointer, 
> 
> This is however, an implementation detail specific to the compiler you use 
> though, correct?

Well, sort of, but really no.  Whether the compiler wastefully makes
multiple copies of large concrete values when interfaces are copied (or
passed as arguments) is an implementation detail.  It is never necessary
to do so to conform to the spec, I would not expect any compiler to do
so, and the compiler you get from golang.org does not (as evidenced by
https://play.golang.org/p/q1729cX09BQ posted by Dan Kortschak).

I strongly suspect that the compiler writers got this right by clearly
thinking it through and realizing that it was never necessary, not by
applying an optimization for certain specific cases.

> And similarly, the wording of the FAQ is "fine", given that it's talking 
> about the behaviour as the specification describes it (which makes no claim 
> as to how an interface should be represented internally as far as I can 
> tell).

And no, it is not fine; it is completely false.

See my recent reply to another msg in this thread.

...Marvin

-- 
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/20210606214011.miw7kddhwzvdfj26%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* 'Dan Kortschak' via golang-nuts  [210606 06:43]:
> On Sun, 2021-06-06 at 03:17 -0700, Brian Candler wrote:
> > When you assign a regular (non-pointer) value to an interface
> > variable, it does take a copy of that value:
> > https://play.golang.org/p/XyBREDL4BGw
> 
> It depends on whether it's safe to leave uncopied or not. You can see
> this here https://play.golang.org/p/q1729cX09BQ

"Copying an interface value makes a copy of the thing stored in the
interface value. If the interface value holds a struct, copying the
interface value makes a copy of the struct."

I believe this is patently false.  It is neither conceptually required
by the language, nor is it true in practice, irregardless of any
optimizations.

1.  It is required (as pointed out earlier in this thread) that
_assignment to_ an interface from a concrete value requires (at
least conceptually) copying the value (obviously, if the value is a
pointer type, the pointer, not the referent is copied).

2.  It is also required (conceptually) that invoking a method on the
interface value, where the method on the concrete value has a
non-pointer receiver, makes a copy of the value to be used as the
receiver.

3.  Furthermore, the complement of the first point is that when using
type assertion to obtain the concrete value from an interface, the
value (pointer if it is of pointer type) must be copied.

These three points, along with the fact that you cannot directly access
the concrete value without type assertion, are sufficient to make it
safe to copy an interface without making a copy of the concrete value
held by the interface, regardless of the implementation.

The statement in question should be removed from the FAQ because it is
just plain wrong, as well as because it is confusing and leads new Go
programmers to adopt bad programming practices.

I would replace it, and the subsequent statement about an interface
holding a pointer type, with a statement that says something along the
lines of

"Assigning a concrete value to an interface requires copying the
value (if the value is a pointer type, only the pointer is copied),
but copying an interface value never requires making another copy of
the concrete value, even if it is not a pointer type."

As an optimization (I don't know what the current compiler does), using
type assertion from one interface type to another interface type does
not require making a copy of the concrete value.  Also, type assertion
to a concrete type can use the value from the interface directly if the
compiler can prove that it is not modified and doesn't escape.

...Marvin

-- 
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/20210606211250.s5tv5jcsk75ex2hu%40basil.wdw.

Re: [go-nuts] extract Last 2 characters in go template

[Marvin Renich]

* Pawan Kumar  [210530 08:03]:
> Many thanks Marvin , really appreciate it.

I intended, but forgot, to hint that your FuncMap could include a
function that was more specific to your problem than the sub function.

...Marvin

-- 
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/20210530121100.7m2dv54moqxo32iv%40basil.wdw.

Re: [go-nuts] extract Last 2 characters in go template

[Marvin Renich]

* Pawan Kumar  [210528 12:43]:
> Hi Team,
> 
> I was using slice function to extract last 2 characters in go template but 
> not able to do ,as -ve range is not supported by slice function .
> 
> For example -  My cluster name is   turbo-ab-03 , i can extract if i know 
> exact length of cluster name. 
> 
> {{ slice (index .ServiceMeta "cluster_name") 9 11}}
> Results -03 
> 
> But it fails , if i use negative range ( Want to extract last 2 characters)
> 
> {{ slice (index .ServiceMeta "cluster_name") -1 2}}
> 
> kindly help.
> 
> thanks 

Neither the slice expression in the Go language, nor the slice function
in the text/template and html/template packages allow negative slice
indexes.  Also, the template language does not allow arbitrary
arithmetic expressions directly.  However, you can define your own
functions for the template and use them.  In this playground example,
«https://play.golang.org/p/yvFRYVe2Bu5», I defined a function "sub" that
I use to calculate the correct arguments to the slice function.

You can also use variables to avoid repeating long expressions:

{{$c := index .ServiceMeta "cluster_name"}}
{{slice $c (sub (len $c) 2) (len $c)}}

...Marvin

-- 
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/20210528185109.7hsu7m6kn5a5koar%40basil.wdw.

Re: [go-nuts] time.Format with "Month Year" format incorrectly displayed

[Marvin Renich]

* Kurtis Rader  [210505 23:35]:
> On Wed, May 5, 2021 at 8:23 PM Bagas Sanjaya  wrote:
> 
> > On 06/05/21 04.37, Ian Lance Taylor wrote:
> >   > You wrote 2009 where you need to write 2006.
> >
> > Wouldn't it possible to define arbitrary reference time and format it
> > according to what it would like?
> >
> 
> If arbitrary literals for the various components were allowed it is certain
> to create ambiguities. Especially, when you allow for locale specific
> spellings and formatting of the date components.. The Go approach is easier
> to understand if you read/speak English but suggests you can replace exact
> literals (e.g., "2006") with what seems like an equivalent literal (e.g.,
> "2009") rather than the opaque POSIX `%Y`. This is the reason I am not a
> fan of the Go approach compared to the POSIX strftime approach (see
> https://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html)

The fact that this sort of confusion over the layout for Time.Format
occurs frequently is a good indication that the approach taken is not as
programmer-friendly as it ought to be.  However, Time.Format has what I
consider to be a much more egregious design flaw; one that should have
ruled it out as the design for the standard library:  the notation
cannot unambiguously represent any desired format containing literals.
If you want literal digits in the output, you are unlikely to be able
use a single call to Time.Format without additional string manipulation
afterward.

Try to code the Go equivalent of the Linux command «date +"%Y 4 %d"».
You either need two calls to Time.Format with string concatenation, or
you must manipulate the string result of Time.Format to insert the
literal "4".

The %x notation is used in Go's fmt package, so this syntax must already
be clearly understood by a Go programmer.  This notation allows any
literal to be unambiguously contained within the format string.  Why add
the cognitive overload of a completely different notation for time
formatting that many programmers struggle to understand?  Also, I would
be very surprised if there were many Go programmers who never have to
look up which reference digit to use for day and which for seconds; the
order is arbitrary and not logical.  It doesn't take much to remember
that %H %M %S is hours, minutes, and seconds, while %y %m %d is year,
month, and day.

I would be willing to bet that if a Time.Printf were added to the time
package, it would very quickly become the overwhelming favorite over
Time.Format.  This would be a compatible change that could easily be
added without violating the Compatibility Promise.

If I were designing this, however, I would not just copy the Linux date
format.  I would use format modifiers similar to the fmt package.  E.g.
instead of %y for two-digit year and %Y for four-digit year, year would
always be %y with a way to indicate how it should be formatted.

...Marvin

-- 
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/20210506125722.uye4s7ls4na6rie4%40basil.wdw.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

[Marvin Renich]

* Jan Mercl <0xj...@gmail.com> [210317 06:27]:
> On Wed, Mar 17, 2021 at 10:57 AM mortdeus  wrote:
> 
> I'm probably giving up any hopes to work for Google in the future by
> writing this: +1. I find the banner deeply offensive, divisive and
> excluding for people with dissenting views, regardless of the
> omnipresent inclusiveness narrative. I cannot stand it, so I need
> Adblock to use the site.

When this topic first came up, I tried very hard to convince the Go team
that the banner was wrong, not because of anyone's opinion for or
against the BLM campaign, but because the Go forums are an inappropriate
place for a controversial topic that is completely orthogonal to the
development of the Go language.  The banner blatantly violates the Go
team's own Code of Conduct:

  • Avoid destructive behavior:
◦ Discussing potentially offensive or sensitive issues; this all too
  often leads to unnecessary conflict.

The banner is in clear violation of this part of the COC.  With all of
the conflict this banner has caused and is still causing, months later,
how can the Go team justify leaving the banner in place?

...Marvin

-- 
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/20210317122853.bhfbzsdithvgyf7j%40basil.wdw.

Re: [go-nuts] Re: Compiler treatment of infinite loops

[Marvin Renich]

* Brian Candler  [210305 10:21]:
> There is a flip side to that: if you add the return statements, then 
> ForLoop1() gives an error due to unreachable code!
> https://play.golang.org/p/0bajnJWTz7U
> 
> So you can't win either way.  I think this implies that if the behaviour 
> were changed now, it would break the go compatibility promise.

The Go compatibility promise does not apply to fixing bugs where the
compiler does not behave according to the language spec.

>From https://golang.org/doc/go1compat#expectations:

  Bugs. If a compiler or library has a bug that violates the
  specification, a program that depends on the buggy behavior may break
  if the bug is fixed. We reserve the right to fix such bugs. 

I would consider this a good candidate for invoking this clause.  Bugs
where the compiler incorrectly flags code as being reachable or
unreachable and fails to compile the code because of such a bug are
important to fix, IMO.

Would someone who has a github account please file an issue for this?

Thanks...Marvin

-- 
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/20210305155245.kvg3u6fclxde7ttr%40basil.wdw.

Re: [go-nuts] package is not in goroot

[Marvin Renich]

* Jan Mercl <0xj...@gmail.com> [210120 15:27]:
> On Wed, Jan 20, 2021 at 9:03 PM Marvin Renich  wrote:
> 
> > I still cannot find any mention of reserved import paths in any
> > documentation (go help modules/importpath/gopath).  It's just an issue
> > on the tracker.
> 
> When an important part of the implementation is undocumented then it's
> a documentation bug, hence the issue.

Absolutely.  I note the bug has been open for more than 18 months.

> Import path is not an URL. The Go build system in GOPATH does not
> interpret import paths as URLs. It's only the go get command that uses
> a well defined function for going from import path to URL to
> download/update repositories.
> 
> From the POV of the build system, Import paths refer to file system
> locations, again using a well defined function for that.

Agreed.  However, what I seem to be hearing about module mode is
different.  Perhaps I am misunderstanding.

> > Changing this for GOPATH
> > mode would, in my mind, be a major breaking change.
> 
> IMO it's a security issue that needs to be fixed. If anything puts a
> replacement of some stdlib package in your $GOPATH then you may have a
> problem.
> 
> Even on an uncompromised system, using the reserved path may in future
> clash with a new package of the same name added to stdlib, producing a
> log of confusion about why this bunch of packages build just fine and
> the rest does not.

GOPATH build mode searches GOROOT first, so no security issue.  Name
clash with future stdlib package is an issue, but much easier to deal
with.  Public discussion about reserving an import namespace is still
important.  If we had had this discussion prior to Go 1, I would have
suggested using one, well-known name for the first component of standard
library packages; perhaps "_stdlib".  Too late for that now.

> > I have never seen any mention of this issue on golang-nuts, though I
> > certainly could have missed it.  Perhaps some discussion took place on
> > golang-dev.  For a change this important, I would expect it to be
> > publicized much better.  If this is only going to affect module mode,
> > that is a different matter.
> 
> I don't recall where I became aware of the linked issue. It's too long ago.

I did not intend for this to sound like a complaint directed at you.  I
appreciate your pointing it out to me.  If the developers working on
this intend to make GOPATH mode fail for a large number of existing
local packages, I would appreciate it if they would say something on
golang-nuts.  This is somewhat different from deprecating the use of
first-level, non-dot names, but still allowing them if they don't clash
with stdlib packages.

...Marvin

-- 
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/20210120215112.f6hzzkpwhrjrqzep%40basil.wdw.

Re: [go-nuts] package is not in goroot

[Marvin Renich]

* Jan Mercl <0xj...@gmail.com> [210120 10:46]:
> On Wed, Jan 20, 2021 at 3:57 PM Marvin Renich  wrote:
> 
> > I don't understand what you are saying.  What is a "reserved import
> > path" and where is it defined?
> 
> See https://github.com/golang/go/issues/32819

???

Thanks for pointing this out!

My first paragraph was written when I thought the OP was using GOPATH
mode, not modules (and that the error message he received was from that
mode), and so my suggestion would have been correct and more clear.  In
fact, if using go build in GOPATH mode, it does, indeed give that
information and even more, enumerating the elements of GOPATH that it
searched.

I still cannot find any mention of reserved import paths in any
documentation (go help modules/importpath/gopath).  It's just an issue
on the tracker.

Import paths without a dot in the first component (which is how I read
what this issue is trying to claim as "reserved") have been part and
parcel of the GOPATH way of building user packages since the beginning
of the go tool, and this still works perfectly.  Not everyone wants or
needs to put their go source code in a web-accessible location, or even
in a version control system, for that matter.  Changing this for GOPATH
mode would, in my mind, be a major breaking change.

I have never seen any mention of this issue on golang-nuts, though I
certainly could have missed it.  Perhaps some discussion took place on
golang-dev.  For a change this important, I would expect it to be
publicized much better.  If this is only going to affect module mode,
that is a different matter.

...Marvin

-- 
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/20210120200316.ip773ss7ufnwmc4y%40basil.wdw.

Re: [go-nuts] package is not in goroot

[Marvin Renich]

* Marvin Renich  [210120 09:58]:
> * Jan Mercl <0xj...@gmail.com> [210120 09:32]:
> > On Wed, Jan 20, 2021 at 2:58 PM Marvin Renich  wrote:
> > 
> > > The error message is really incomplete, and therefore confusing.  It
> > > should be "package ... is not in GOROOT or any element of GOPATH".
> > 
> > _That_ would be incorrect and confusing. Reserved import paths are
> > never searched for in GOPATH.

Perhaps you missed my third paragraph.  The first paragraph was written
when I was still thinking the OP was using GOPATH, not modules.

I still don't know what you mean by "reserved import path".

...Marvin

-- 
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/20210120150540.qnfkvgnj33pvubmd%40basil.wdw.

Re: [go-nuts] package is not in goroot

[Marvin Renich]

* Jan Mercl <0xj...@gmail.com> [210120 09:32]:
> On Wed, Jan 20, 2021 at 2:58 PM Marvin Renich  wrote:
> 
> > The error message is really incomplete, and therefore confusing.  It
> > should be "package ... is not in GOROOT or any element of GOPATH".
> 
> _That_ would be incorrect and confusing. Reserved import paths are
> never searched for in GOPATH.

I don't understand what you are saying.  What is a "reserved import
path" and where is it defined?

When using GOPATH (not modules), when the go toolchain encounters

  import "path/to/package"

it first looks for a directory obtained from (roughly)
filepath.Join(GOROOT, "src", "path/to/package"), if it does not find the
package there, it does the same thing, replacing GOROOT with,
successively, each element of GOPATH.  So, if it cannot find the given
import path, then the package is not in GOROOT, nor is it in any element
of GOPATH.  What is confusing about that?

...Marvin

-- 
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/20210120145736.32uiaivzhtlo6dn4%40basil.wdw.

Re: [go-nuts] package is not in goroot

[Marvin Renich]

* Alexander Mills  [210119 16:54]:
> i am getting this weird error message:
> 
>  package twitch/go-scripts/dynamo-creators-to-s3/lib is not in GOROOT 
> (/usr/local/Cellar/go/1.15.6/libexec/src/twitch/go-scripts/dynamo-creators-to-s3/lib)
> 
> my GOPATH=$PWD/scripts/go
> 
> so there is only 1 GOPATH
> 
> [image: Screen Shot 2021-01-19 at 1.52.30 PM.png]

The error message is really incomplete, and therefore confusing.  It
should be "package ... is not in GOROOT or any element of GOPATH".

I had written an answer based on an environment using GOPATH before
carefully looking at your screenshot (please paste text rather than
using screenshots).  It seems you have a go.mod file, so GOPATH is not
relevant.

If using modules rather than GOPATH, the error message is probably
correct, as GOPATH is not used except as a place to cache downloaded
modules under the "$GOPATH/pkg" directory.

As best as I can tell (and I am still using GOPATH, so I may be
completely wrong), a Go program in a module can only use web-aware
import paths (except for standard library packages).  Perhaps someone
else can clarify that, and how to set up your directory structure.  I
think there was recent thread with a similar problem, but I did not pay
much attention to it.

Personally, I think that requiring (as opposed to allowing) web-aware
import paths is a terrible (no, I mean really, really terrible) design.

On the other hand, if you were intending to use GOPATH, but it was
incorrectly set and so the go tool kindly (???) created a go.mod file
for you, I can probably help you figure out your problem.  First, erase
go.mod.  Then, ensure GOPATH is what you expect (use "go env GOPATH",
rather than "echo $GOPATH").  If that doesn't lead you to an answer,
post the output from go env and the go command you are using that gives
the error (go build, go test, etc.).

...Marvin

-- 
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/20210120135843.rtxdxzbql5hkx3gn%40basil.wdw.

Re: [go-nuts] In Go the type size of 1 byte can reach 1 kilobyte, even 1 terabyte or much more.

[Marvin Renich]

* Christian Maurer  [201210 07:37]:
> 
> // Proof: Set n to a number >= 39 in the following program:
> 
> func main() {
>   const (
> b = byte(0xc0)
> n = 9
>   )
>   s := []string{string(b)}
>   for i := 0; i < n; i++ {
> s = append(s, []string{""}...)
>   }
>   for i := 0; i < n; i++ {
> for j := 0; j < len(s[i]); j++ {
>   s[i+1] += string(s[i][j])
> }
>   }
>   println(len(s[n]), len(s[n]) == 1<<(n+1))
> }

Did you try adding

  fmt.Printf("s[0] = %q len(s[0]) = %d\n", s[0], len(s[0]))

after the initial assignment to s?  Strings are treated as UTF-8, and
string(byte(0xc0)) converts the rune (Unicode code point) '\u00c0' to
its UTF-8 representation as a string "\xc3\x80".

See https://golang.org/ref/spec#Conversions and scroll down to
"Conversions to and from a string type".

...Marvin

-- 
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/20201210132104.2v2dsgno647tr3fa%40basil.wdw.

Re: [go-nuts] Trying to call powershell script from Go

[Marvin Renich]

* Uzair Ally  [201027 14:19]:
> Hi Jake,
> 
> The code I posted is the runnable go program just missing the powershell 
> script which is a separate file. Maybe I'm miss understanding? Is there 
> something else I can provide to help you understand further?

Based on the your original message and the description you gave later, I
believe my second message will do what you want; i.e.

out, err := exec.Command(cmdName, "script.ps1").Output()

without quotes around cmdName (a variable containing the string
"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe") and
with quotes around "script.ps1" (the name of the script to run as a
string, not a variable containing a string).

> On Tuesday, October 27, 2020 at 1:26:53 PM UTC-4 mua...@gmail.com wrote:
>> If I add script.ps1 in double quotes and try to run, it tells me cmdName 
>> declared but no used.
>> Yes, the script is named script.ps1. The script is not a variable.

In your original code, the compiler recognizes that script is an
identifier that has not been declared and tells you so.  At that point,
it has not yet done the analysis to determine if all declared variables
are being used; that analysis happens at a later step in the
compilation, which never occurs if errors are found in prior compilation
steps.

Once you fix the errors in the prior compilation steps (in this case
changing script.ps1 from an undeclared identifier to a string), now the
compiler can perform its "unused variable" analysis, and finds cmdName
declared, but not used.  This is because where you intended to use it,
you put it in quotes, making it a string rather than a variable
reference.

...Marvin

-- 
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/20201027183736.nv6vc2kd3nt2vv6t%40basil.wdw.

Re: [go-nuts] Trying to call powershell script from Go

[Marvin Renich]

* Uzair Ally  [201027 13:27]:
> Hi Marvin,
> 
> If I add script.ps1 in double quotes and try to run, it tells me cmdName 
> declared but no used.
> Yes, the script is named script.ps1. The script is not a variable.

I should have recognized that "cmdName" should be cmdName without the
quotes:

  out, err := exec.Command(cmdName, "script.ps1").Output()

I was just answering too fast.

> On Tuesday, October 27, 2020 at 8:22:14 PM UTC+3 Marvin Renich wrote:
> 
> > * Uzair Ally  [201027 12:25]:
> > > Hi,
> > > 
> > > I am getting the following error when I try to call a powershell script 
> > > from go.
> > > 
> > > undefined: script
> > > 
> > > Here is the code:
> > > 
> > > cmdName := 
> > "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
> > > out, err := exec.Command("cmdName", script.ps1).Output()
> >
> > Perhaps you what you intended was:
> > out, err := exec.Command("cmdName", "script.ps1").Output()
> >
> > Is your script named script.ps1 or is script a variable with a field
> > named ps1 containing the name of the script?
> >
> > > if err != nil {
> > > fmt.Fprintln(os.Stderr, "Error creating StdoutPipe for Cmd", err)
> > > 
> > > 
> > > It looks like go doesn't recognize the powershell script. How do I 
> > resolve 
> > > this error? Any help or guidance will be appreciated. 
> >
> > ...Marvin

-- 
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/20201027173838.fzic2nbnskibw2iu%40basil.wdw.

Re: [go-nuts] Trying to call powershell script from Go

[Marvin Renich]

* Uzair Ally  [201027 12:25]:
> Hi,
> 
> I am getting the following error when I try to call a powershell script 
> from go.
> 
> undefined: script
> 
> Here is the code:
> 
> cmdName := "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
> out, err := exec.Command("cmdName", script.ps1).Output()

Perhaps you what you intended was:
  out, err := exec.Command("cmdName", "script.ps1").Output()

Is your script named script.ps1 or is script a variable with a field
named ps1 containing the name of the script?

> if err != nil {
> fmt.Fprintln(os.Stderr, "Error creating StdoutPipe for Cmd", err)
> 
> 
> It looks like go doesn't recognize the powershell script. How do I resolve 
> this error? Any help or guidance will be appreciated. 

...Marvin

-- 
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/20201027172059.4ncghsled5eo4tjz%40basil.wdw.

Re: [go-nuts] Should the program print true or false?

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [200917 12:05]:
> I think you might've intended this, which does indeed print true:
>  type S []S
> var a, b S
> a, b = S{0: b}, S{0: a}
> fmt.Println(reflect.DeepEqual(a, b))

I was guessing he meant:

type S []S
var a, b S
a = S{0: b}
b = S{0: a}
a[0] = b
fmt.Println(reflect.DeepEqual(a, b))

which also returns true, but for a slightly different reason; check out
the following for each of the two cases:

fmt.Printf("a[0] == nil: %t, b[0] == nil: %t\n", a[0] == nil, b[0] == nil)

...Marvin

-- 
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/20200917175916.dl4mifoq5stwhk6t%40basil.wdw.

Re: [go-nuts] Re: While implement ssh client using golang, record keyboard input

[Marvin Renich]

* sc3983...@gmail.com  [200915 11:41]:
> Hi Everyone:
> 
>   I have the same problem, How do I get user input command, with *SSH 
> client with a Interactive Shell*
> 
> 在 2018年10月23日星期二 UTC+8上午4:57:50，Sun Frank写道：
> >
> > Hi Everyone:
> >
> > I came across a problem which puzzled me for couple of days. I am trying 
> > to write a* SSH client with a Interactive Shell *using golang, but i also 
> > need to record the command(or keystroke history) of the user typed, like 
> > the history feature, here's my working code: 
> >
[snip]
> >
> > session.Stdout = os.Stdout
> > session.Stderr = os.Stderr
> > session.Stdin = os.Stdin

Instead of using os.Stdin, create an io.Pipe, and use the returned
*PipeReader for session.Stdin.  Then, read os.Stdin yourself, log or
otherwise process the user's input, and write the processed input to the
*PipeWriter.

The same technique can be used to log Stdout and Stderr.

...Marvin

-- 
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/20200915162707.o4zssrpgikspxomc%40basil.wdw.

Re: [go-nuts] Definition of Method sets

[Marvin Renich]

* Yuu LongXue  [200904 05:31]:
> Hi all,
> 
>   I’m confused by the "method set" defined in go
>   specification，any one can help explain?
> 
>   The Go Programming Language Specification says that :
>   ```
>   The method set of any other type T consists of all methods
>   declared with receiver type T. The method set of the
>   corresponding pointer type *T is the set of all methods declared
>   with receiver *T or T (that is, it also contains the method set
>   of T).
>   ```
>   but actually, the type T can use the method with receiver *T ,
>   which is described as bellow. 

In addition to Brian's answer, the method set definition is specifically
about which types satisfy a particular interface.  While the part of the
spec that Brian quoted describes a convenience shorthand, it does not
mean that a method declared with receiver *T is in the method set of
type T.  This is a subtle point that can be confusing.

The playground link https://play.golang.org/p/N5IvMNvEsxi illustrates
this point.  Note that you can call car.String() (line 38), but you
cannot assign car to a variable of type Stringer (line 43 produces a
compiler error).  If you insert an '&' in front of car on line 43, it
compiles and runs.

This point is worth understanding.

...Marvin

-- 
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/20200904141109.rp6cqmlidpczj37n%40basil.wdw.

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

[Marvin Renich]

* targe...@gmail.com  [200827 05:40]:
> On Thursday, August 27, 2020 at 12:20:59 PM UTC+3 axel.wa...@googlemail.com 
> wrote:
>> I'm saying the current situation is less confusing than what you
>> describe, yes.
>>
>> AIUI, with what you describe, if I have a variable `x` of type `*T`
>> and an interface variable `y`, then `y = x` and `y = (*T)(x)` have
>> different semantics. I think it is strange to have a conversion of
>> `x` *to its own type* have any sort of semantic implication. It
>> should be a no-op.
> 
> It may be expressed in some different way. To me, if `x == nil` and then `y 
> != nil` after `y = x` is much more confusing. If you ask my opinion, I 
> would make interfaces compare to nil on just data pointer. If one wanted 
> interface which doesn't require data, he could've easily created one with 
> static stub variable. No additional checks, no "semi-nil" fat pointers, 
> everything simple and consistent.

I agree with Axel.  The `y = x` operation is a conversion, not just an
assignment.  You cannot assume that the transitive property of equality
holds where conversions are used.  Note also that both y == nil and x ==
nil involve implicit conversion, because nil is the _untyped_ zero
value, so the value being compared to y is nil converted to the
interface type, and the value being compared to x is nil converted to
the concrete type; these are _different_ zero values.

I think there are two incorrect generalizations that lead to Go
programmers having the confusion being discussed.  The first is that nil
is the "universal" zero value, which leads to the false idea that nil
of one type is the same as nil of another type.  I think when a
programmer stops to think about this, they will get the correct answer,
but often this level of detail is not brought to a high enough level of
conciousness when actually writing code.  The correct thinking is that
nil is the _untyped_ (rather than universal) zero value.  Note that you
cannot even evaluate nil == nil!

The second is thinking of an interface value containing a concrete value
as being the same thing as the concrete value.  I'm not sure why this is
such a sticking point for some, but it clearly is.  It may be for some
that they think of interfaces as a "partial generic" language feature,
such that declaring a variable of an interface type is a way to directly
use any of the types that implement that interface.  This is the wrong
way to think of it, as the interface value cannot be used in Go code in
the same was as the concrete value, except in the very specific case
where you are invoking a method on the interface value that is defined
_by the interface_.  In particular, the interface value has its own,
distinct, zero value from the zero value of the contained concrete type.

Consider the code:

type Fooer interface {
Foo()
}

type X int

func (i X) Foo() {
}

func main() {
var i X
var f Fooer = i
fmt.Println(f == 0)
}

You would not (at least you should not) expect this to compile, much
less give you the "obvious"(?) answer.  Yet, when you change

type X int
func (i X) Foo() {
...
var i X
...
fmt.Println(f == 0)

  to

type X struct{}
func (i *X) Foo() {
...
var i *X
...
fmt.Println(f == nil)

you expect that the nil is being compared to the concrete value
contained by f rather than the value of f.

If you had to explicitly convert nil to the proper type before
comparison, the problem would be much more obvious.

If you think of an interface value as a container for a concrete value,
rather than the concrete value itself, then the interface value might be
empty (nil, no concrete value) or it might contain a concrete value (not
nil, but the concrete value might be its own zero value).

As Axel said, you just have to learn that interface_value == nil
determines whether interface_value has been assigned a concrete value,
not whether the concrete value is its own zero value (which might
coincide with nil converted to the concrete type).

...Marvin

-- 
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/20200827160217.mw7tg6ef224htgxe%40basil.wdw.

Re: [go-nuts] Re: module confusion

[Marvin Renich]

* fge...@gmail.com  [200815 03:44]:
> On 8/15/20, Marvin Renich  wrote:
> > * Volker Dobler  [200814 14:53]:
> >> On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
> >> > Isn't this the default location?  I just untarred the distribution...
> >>
> >> No. There is a reason https://golang.org/doc/install#install
> >> states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> >
> 
> > It also might be productive to mention that many (Linux?) distributions
> > (e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
> > Go, and that using the distribution's package manager may be easier,
> > provide better security support, and integrate better than manually
> > installing the official Go binary distribution.
> 
> Could you please give an example to "better security support" in a
> distribution's package manager?

The user can let the package manager automatically update packages with
security fixes (at least in Debian) so the user doesn't have to stay on
top of when a security update is available and manually reinstall the
updated version of Go.  (Think of trying to do this individually for
every piece of software installed on your system.)

Perhaps "simpler" would have been a better word than "better".  One of
the big reasons to use packages from a distribution rather than
installing each one from source or from upstream's binary packages is to
simplify system maintenance.

...Marvin

-- 
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/20200815202206.6b7qbvc6kg4lzjh4%40basil.wdw.

Re: [go-nuts] Re: module confusion

[Marvin Renich]

* Volker Dobler  [200814 14:53]:
> On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
> > Isn't this the default location?  I just untarred the distribution... 
> 
> No. There is a reason https://golang.org/doc/install#install
> states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz

While (I believe) the majority of individuals (rather than sysadmins)
installing on Linux, MacOS, and FreeBSD will be the primary (essentially
sole) user on such systems, and will be able to use /usr/local (usually
requiring su or sudo or modifying permissions on /usr/local, which is
not mentioned in the above referenced instructions), this is not a
universal condition.  Especially, students at universities using an
account on a university machine will generally not have access to
/usr/local.  I think this is a significant enough use case to warrant a
mention in the installation instructions, e.g.

  If you do not have access to /usr/local, or do not wish to install
  there, you may install to another directory, such as $HOME/goroot.
  The directory $HOME should not be used, as this would make $GOROOT the
  same as the default $GOPATH ($HOME/go), which is not allowed.

Anything along these lines would help alleviate the confusion that the
OP had.

It also might be productive to mention that many (Linux?) distributions
(e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
Go, and that using the distribution's package manager may be easier,
provide better security support, and integrate better than manually
installing the official Go binary distribution.

...Marvin

-- 
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/20200814233137.dujkksays2luoqyt%40basil.wdw.

Re: [go-nuts] my package not include in go modules

[Marvin Renich]

* Ali Hassan  [200725 01:04]:
> I want to import libraries in module file but modules add all other 
> libraries except those packages which I had created, DB is one of them. How 
> to import? 
> Error , please help me 
> to resolve 

Also note that any go command that needs to download the package must
download the whole repo.  Downloading happens for go get and for a
number of go commands, such as go build and go test, when the package
has not already been downloaded and cached.  Using one repo = one module
= one package means that downloads and disk space for cached repos can
be smaller.

However, if several packages are closely related and will typically be
used together, putting them in the same module (and repo) makes sense.

...Marvin

-- 
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/20200729132217.nelg2pttvyzp6i7q%40basil.wdw.

Re: [go-nuts] Expanding variables and fmt.Printf() issue

[Marvin Renich]

[pedantic correction]

* Marvin Renich  [200629 14:10]:
> The final argument to Printf is []interface{}, while you are trying to
  ^
  ...interface{}

...Marvin

-- 
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/20200629182020.aqgs6y2u4qufxbrj%40basil.wdw.

Re: [go-nuts] Expanding variables and fmt.Printf() issue

[Marvin Renich]

* yves baumes  [200629 03:22]:
> Hello,
> 
> considering this code
> 
> ```
> package main
> 
> import (
> "fmt"
> )
> 
> func main() {
> host := []string{"127", "0", "0", "1"}
> 
> fmt.Printf("%v.%v.%v.%v\n", host[0], host[1], host[2], host[3])
> fmt.Printf("%v.%v.%v.%v\n", host[0:4]...)
> }
> ```
> 
> The first Printf works and prints the host value.
> While the second one does not compile : "./args.go:11:34: cannot use 
> host[0:4] (type []string) as type []interface {} in argument to fmt.Printf"
> 
> If I use append() instead of Printf(), this expanding of the host variables 
> just works out. Is this a compiler bug in the case of the fmt.Printf() ?

>From the language spec at
https://golang.org/ref/spec#Passing_arguments_to_..._parameters:

If the final argument is assignable to a slice type []T, it is
passed unchanged as the value for a ...T parameter if the argument
is followed by  In this case no new slice is created.

The final argument to Printf is []interface{}, while you are trying to
pass []string.  In order for this to work, []string would have to be
assignable to []interface{}, which it isn't.

This is related to a FAQ at
https://golang.org/doc/faq#convert_slice_of_interface.

If, after reading the above links and the definition of assignability at
https://golang.org/ref/spec#Assignability, you are still unclear why it
is not compiling, ask on the list for more help.

...Marvin

-- 
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/20200629181003.attbsi36qwc6rrtv%40basil.wdw.

Re: [go-nuts] Re: accessibility of module version information in executable

[Marvin Renich]

* seank...@gmail.com  [200626 12:31]:
> go version -m $binary
> 
> runtime/debug.BuildInfo

Thanks much!  I looked through runtime, but did not think to look at
runtime/debug.  I was completely unaware of the -m option to go version.

...Marvin

-- 
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/20200626165309.t33llcl6h5klz2e7%40basil.wdw.

[go-nuts] accessibility of module version information in executable

[Marvin Renich]

When building a command with go build that imports modules, does the
resulting executable contain information about which modules are
included as well as their versions?

If so, is there a tool available to extract that information from the
executable?  Can the information be retrieved from within the program
(e.g. through the runtime package)?

If not, would a request for this be received favorably?

...Marvin

-- 
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/20200626161324.epfevcf53q76ix4d%40basil.wdw.

Re: [go-nuts] Re: political fundraising on golang.org!

[Marvin Renich]

* Marvin Renich  [200619 11:17]:
> You post a banner within the Go community that is off topic and is
  ^

Just to be clear, the "you" in this paragraph is not you, Ian,
personally.  I am referring collectively to the maintainers of the web
sites and mailing lists in their official capacities.

...Marvin

-- 
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/20200619152314.soyqdeibsjpeyzgm%40basil.wdw.

Re: [go-nuts] Re: political fundraising on golang.org!

[Marvin Renich]

* Ian Lance Taylor  [200619 00:20]:
> It's an important discussion, but having it on golang-nuts is not working.
> 
> It can continue off-list.

You post a banner within the Go community that is off topic and is
highly controversial (this thread is clear evidence of that).  You then
squelch discussion of the banner itself and the topic of the banner by
other members of the community, while leaving the banner in place.

I claim that the presence of the banner is in clear violation of the
posted Go Community Code of Conduct, and repeat my request for the
removal of the banner.  To quote from the Code of Conduct page:

  Be friendly and welcoming
  Avoid destructive behavior:
Discussing potentially offensive or sensitive issues; this all too
often leads to unnecessary conflict.

And from the Pledge:

  ...we as contributors and maintainers pledge to making participation
  in our project and our community a harassment-free experience for
  everyone, regardless of...[long list of attributes snipped].

The banner is welcoming to some, but clearly unwelcoming to others.
Enough members of this community have expressed that they disagree that
the banner is appropriate in this venue and are offended by its
presence.  The banner has caused, and is still causing, harm to the
community by dividing the community over a topic that is orthogonal to
why this community exists.

I strongly agree that this is an important discussion and also that
having it on golang-nuts is not working.  However, as long as the banner
is posted within the Go community, it is unreasonable to expect the
discussion to not happen within public community spaces.

...Marvin

-- 
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/20200619151707.ovmzhm75pqohhu7x%40basil.wdw.

Re: [go-nuts] political fundraising on golang.org!

[Marvin Renich]

[Note To and CC]

Please consider this a formal request for the Go Project Stewards to
review the website banners being discussed in this thread and to make a
determination that these banners are causing divisiveness in the Go
Community and have offended some, and that the banners' content is
inappropriate in this context.

...Marvin

-- 
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/20200615142640.2p37xxlnammendrr%40basil.wdw.

Re: [go-nuts] political fundraising on golang.org!

[Marvin Renich]

* Sam Whited  [200615 09:34]:
> This is an important issue about the Go Community and who feels welcomed
> here, which is also covered by this mailing list.

This is _so_ wrong.  The evidence that this banner has caused
substantial divisiveness and offended many members of the Go community
is obvious in this thread.

In what way does not having the banner affect how welcome people feel on
the Go lists and websites?  As long as the discussions on these lists
and websites remain technical, everyone should feel welcome.  When you
start discussing unrelated social issues, you are certain to offend some
people.

...Marvin

-- 
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/20200615140539.fbkomsctrios5reu%40basil.wdw.

Re: [go-nuts] political fundraising on golang.org!

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [200614 20:15]:
> No, what you said is, that objecting to the banner may not be *political*.
> You didn't mention parties and neither did I. And I stand by my statement,
> that objecting to the banner *is* inherently a political act. And that
> claiming to object on the grounds that you don't want politics in the Go
> project is thus paradoxical.

My opinion, and the way I interpreted Peter's original post, is that
this banner is extremely inappropriate, independent of its social or
political views, because it is completely off-topic for the discussion
of the Go language and introduces a highly controversial non-technical
issue into places where people go to discuss a specific technical topic.

I find it even more offensive that it is not just a banner promoting
awareness of a social issue, but contains a request and link soliciting
money.

My alignment for or against any social issue has absolutely no bearing
on my opinion that this type of banner is inappropriate in this context.
I also believe that the people who run these websites have the right to
place banners of this nature if they wish, but they also have a
responsibility to _not_ do so.

...Marvin

-- 
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/20200615134345.dk5qyei5iwob75vt%40basil.wdw.

Re: [go-nuts] Re: help understanding weird Benchmark results

[Marvin Renich]

* Warren Bare  [200519 13:53]:
> OK, I added a sum of the rand to the demo code and the results are the 
> same.  Since it is displaying the sum, it seems clear that the code is not 
> optimized away.
> 
> Again, I am NOT trying to time each iteration of the loop.  This is a 
> minimal demonstration of a weirdness I was seeing in my own benchmarks.  
> Just pretend the loop is one chunk of code that takes time and is not 
> optimized away.
> 
> Any other ideas?
> 
> func BenchmarkMarshalSample(b *testing.B) {
> var sum int64
> start := time.Now()
> for i := 0; i < 10_000_000; i++ {
> sum += rand.Int63n(0x)
> }
> b.Logf("Sum %e Duration %v", float64(sum), time.Now().Sub(start))
> }

You do not clearly understand how benchmarking in the testing package
works.  In order to get meaningful results, your benchmark function
_must_ iterate b.N times.  The benchmark framework is going to run your
function several times, with different values of b.N until it can get a
meaningful time, and then it does the math to give you "per iteration"
times.  Read carefully the section "Benchmarks" under
https://golang.org/pkg/testing/.

For the above case (given that you are not trying to time one
invocation of rand.Int63n, but a fixed number) you would write your code
like this:

func BenchmarkMarshalSample(b *testing.B) {
var sum int64
start := time.Now()
for j := 0; j < b.N; j++ {
for i := 0; i < 10_000_000; i++ {
sum += rand.Int63n(0x)
}
}
b.Logf("Sum %e Duration %v", float64(sum), time.Now().Sub(start))
}

The benchmark results will give the time for _one_ iteration of the
_outer_ loop, so the "op" in "ns/op" will be 10_000_000 iterations of
the inner loop.

...Marvin

-- 
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/20200519181906.5xvifyyrowbnfzrs%40basil.wdw.

Re: [go-nuts] Type Assertion on File type

[Marvin Renich]

* André kouamé  [200507 12:57]:
> I want to check, if the value return by my function has the type *os.File
> This my code :
> func createFile(filename string) (*os.File, error) {
> f, err := os.OpenFile(filename, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
> return f, err
> 
> }
> //Test code
> filename := "testfile"
> f, _ := createFile(filename)
> c := (*os.File)
> fmt.Println(c)
> Error return : 
> invalid type assertion: f.(*os.File) (non-interface type *os.File on left) 
> Process exiting with code: 1

The value being coerced must be an interface type.  «f» above is of type
«*os.File», which is a concrete type.  This playground link shows an
example of what I think you want:

  https://play.golang.org/p/AILqjXUK0zx

Note that «rdr» is of type «io.Reader», which is an interface that
«*os.File» implements.

...Marvin

-- 
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/20200507174509.bgqwrkx674gsnfvn%40basil.wdw.

Re: [go-nuts] keyword func

[Marvin Renich]

* レミリア・スカーレット  [200427 12:46]:
> Why you need to write a "func sum(a, b int) int {...}", not "sum(a, b int) 
> int {...}"?
> It seems to me that one could do without func keyword.

I believe another reason is that the Go language designers decided that
every top-level syntax element begins with a keyword:  package, import,
type, const, var, func.  Perhaps this is just for convenience of
parsing, but it greatly simplifies human parsing (readability) as well.

...Marvin

-- 
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/20200427191520.j5oscp5o6osuc2zv%40basil.wdw.

Re: [go-nuts] Go Tour ok?

[Marvin Renich]

* Anssi Porttikivi  [200421 08:57]:
> I had to run the Go Tour locally, because the web version gives me odd 
> "timed out" and "build failed" (with no reason) errors 
> indeterministically... Is it just me?

I was having the same trouble earlier today.  The build (or run) was
timing out, and the tour seemed to be caching that result so that simply
retrying came back immediately with "timed out", whereas the first time
took a few seconds.  Changing the code (adding an innocuous comment)
allowed it to run.

Note that this was the play window reporting that the build or run timed
out, it was not an HTTP timeout.

...Marvin

-- 
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/20200421180719.pehcgkm6tanw6bpj%40basil.wdw.

Re: [go-nuts] Re: "Go build failed." in Go tour requires explicit Kill

[Marvin Renich]

* Brian Candler  [200416 12:20]:
> I've noticed this too.  This is with the tour, rather than play.golang.org.
> 
> To reproduce (I'm using Chrome 80 under macOS 10.14):
> 
> * Go to a tour page which doesn't compile, e.g. 
> https://tour.golang.org/methods/25
> * Click Run
> * At this point it shows an error - but the Run button has become Kill
> * Now you have to click Kill.  The line "Program exited: killed" is added.
> * Now you can edit and re-run
> 
> The "Kill" step appears to be superfluous, as noted by the OP.

This is exactly what I am seeing, on any tour page when the build fails.
Go to the "Hello, 世界" page (https://tour.golang.org/welcome/1) and
edit the code to produce an error.

...Marvin

-- 
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/20200416170100.h6fdaiyvphifjpfu%40basil.wdw.

Re: [go-nuts] Re: wording in Go tour, methods/19

[Marvin Renich]

* Volker Dobler  [200416 02:28]:
> On Wednesday, 15 April 2020 17:58:11 UTC+2, Marvin Renich wrote:
> >
> > In the Go tour at https://tour.golang.org/methods/19 it says 
> >
> >   The error type is a built-in interface similar to fmt.Stringer: 
> 
> I agree that this might be misunderstood in the sense of fmt.Stringer
> being built-in too, but if this is commonly misunderstood it probably
> is not a long-lasting, problematic confusion (for most purposes it
> simply doesn't matter wether fmt.String is a predeclared built-in or
> declared in the stdlib).

Whether the confusion is long lasting or not, it requires re-reading the
statement and possibly looking up the definition of fmt.Stringer to
understand what is being said.  Making the statement clearer on initial
read is definitely better.

> > A much better wording would be 
> >
> >   The error type is a built-in interface; its definition is similar to 
> >   fmt.Stringer: 
> 
> I think I disagree here. The similarity of error and fmt.Stringer is
> both being a one-method interface and this method has the same
> signature for both (no arguments, string return) but their _actual_
> "definition" is pretty different as one is built-in, the other isn't.

Okay, then what is the point of saying the two are "similar"?  I am
simply advocating that the fact that error is built-in be separated from
any comparison to fmt.Stringer, for whatever comparison you would like
to make.  Would you like this better (I don't particularly, but it is
better than what is there now)?

  The error type is an interface similar to fmt.Stringer, but it is
  built-in:

Making written communication easier to understand is always an important
goal, even if it means being somewhat more verbose.  This is especially
true in a tutorial such as the Go tour.

...Marvin

-- 
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/20200416115637.kmi7fn5muxzwibe6%40basil.wdw.

[go-nuts] "Go build failed." in Go tour requires explicit Kill

[Marvin Renich]

In the Go tour, what is the purpose of requiring the user to explicitly
press the "Kill" button when the build fails?  This seems completely
unnecessary to me.

If this is just a natural consequence of the internal implementation, it
would, in my opinion, be well worth the effort to make a failed build
exit without requiring the user to press "Kill".

...Marvin

-- 
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/20200415170159.k57ltq44otwmwfqz%40basil.wdw.

[go-nuts] wording in Go tour, methods/19

[Marvin Renich]

In the Go tour at https://tour.golang.org/methods/19 it says

  The error type is a built-in interface similar to fmt.Stringer:

The words closest to "similar to" are "built-in interface", implying
that the way error is similar to fmt.Stringer is that it is a built-in
interface, which it clearly isn't.  I would be surprised if this is not
a source of confusion to a significant number of programmers who are new
to go and using the tour to get acquainted.

A much better wording would be

  The error type is a built-in interface; its definition is similar to
  fmt.Stringer:

I don't have a github account, so I can't send feedback using the
feedback button on the page.

...Marvin

-- 
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/20200415155719.ushmx5idhyid4vnw%40basil.wdw.

Re: [go-nuts] go run requires internet connection?

[Marvin Renich]

* Tanmay Das  [200408 12:17]:
> Hey Gophers,
> My very first post here.
> 
> Today I faced an unexpected power outage and I wanted to tinker with Go a 
> little bit. I wrote a simple hello world program and ran 
> go run helloworld.go
> 
> Strangely the code didn't run. In fact, the terminal prompt never exited. I 
> kept running the same command over and over again but no luck. I checked 
> all my configurations, my env vars, etc. and everything was ok. After 
> ruling out all the possibilities it suddenly hit me: what if Go actually 
> requires an internet connection to run a program for no apparent reason? I 
> waited for the electricity to come back and as soon as I was connected to 
> the internet I ran `go run` command again and voilą! 
> 
> Is this behavior expected? If it is, why did the go authors make such a 
> decision? I mean making the internet connectivity a dependency for the 
> execution of a program sounds counter-productive to me, honestly. :(

You didn't post any code, so it is really difficult to help you.  No, Go
does not require an internet connection unless you write your program to
do so.

The best way to get help here is to go to https://play.golang.org/ and
paste your code there (replacing what is there).  Then click on the
"Share" button, and you will get a link that you can copy and paste into
a message to this group.

This will allow us to see the code and help you unravel your problem.

...Marvin

-- 
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/20200408162915.wrf244fu6l5czlng%40basil.wdw.

Re: [go-nuts] Should it panic when set a channel to nil concurrently

[Marvin Renich]

* Yuan Ting  [200301 23:50]:
> I write a simple program likes below and it triggers a data race alarm with 
> -race flag. But no matter how I run, this program will not panic. I know it 
> is legal to receive messages from nil channels, but I don't quite 
> understand why this program does not panic in the presence of data races.
> 
> ch := make(chan struct{})
> go func() {
> ch = nil
> }()
> go func() {
> <-ch
> }()

I think the other responses missed the obvious here (or at least chose
more elaborate, though correct, explanations).  This is a variable
assignment in one goroutine concurrent with a variable reference in
another.  It is exactly the same (from the point of view of whether it
is a race or not) as this:

var a = 17

go func() {
  a = 987654
}()

go func() {
  fmt.Println(a)
}

In the second goroutine, the variable a might have the value 17, it
might have the value 987654, and it might have garbage that is neither
of these.  This is a race condition, and it is also true of the channel
code above.

One of the other responses very correctly said that a race does not
imply that the code could panic.  The integer code above will never
panic, even on architectures where a write of an integer to memory
concurrent with a read from that memory can possibly allow the read to
return partially written data.  However, the above code is clearly a
race condition.

...Marvin

-- 
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/20200302133637.3iolxy54426rppgv%40basil.wdw.

Re: [go-nuts] doubt about reflect.Type.String and empty interface

[Marvin Renich]

* Manlio Perillo  [200106 18:57]:
> I wrote another test https://play.golang.org/p/hoTAnijCfg1.
> Now it is clear why the first entry can only print nil for the type
> and  for the value.
> 
> However printf %v verb prints nil for both an empty interface and an
> interface with a dynamic value of nil:
> https://play.golang.org/p/m_WfR2SPWQ3
> Can this cause confusion?

Yes, it definitely can (and probably does).  However, if you change "%v"
to "%#v", it helps to clarify things:

https://play.golang.org/p/K4nPb27Btok

...Marvin

-- 
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/20200107120900.krld2ci3dvdadcqn%40basil.wdw.

Re: [go-nuts] Re: bufio.Reader.Buffered returns 0

[Marvin Renich]

* Ian Lance Taylor  [191215 23:05]:
> The Buffered method [snip] tells you how
> many bytes you can Read without causing a call to the underlying
> Reader.

I think this would be a significant improvement over the current
ambiguous documentation.  It should adequately dispel any unrealistic
expectations on the part of programmers who are reading the
documentation.

...Marvin

-- 
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/20191216122707.4nx3gueuibk4dpua%40basil.wdw.

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

* burak serdar  [191112 12:45]:
> Is there a guarantee that the compiler will not reorganize
> instructions around an atomic read/write? That is:
> 
> i++
> k:=atomic.AddInt32(,1)
> 
> Is there a guarantee that the compiler won't rewrite this as:
> 
> k:=atomic.AddInt32(,1)
> i++

First, from one of the issues to which Robert Engels pointed, it appears
that the language designers are in agreement that if atomics are not
covered by the Go Memory Model, they should be.  From this, it seems
safe to me to treat them as if they provide a
does-not-happen-concurrently promise.

>From that (and, independently, from the fact that atomics would
otherwise lose all their documented usefulness) it follows that you have
the same guarantee about reordering that you would have if you replaced
the atomic access with a mutex or channel operation.  Everybody seems to
agree that the compiler can only reorder if such reordering not only
does not affect the behavior of the goroutine being reordered, but also
does not affect the behavior observed by other goroutines _where a
happens-before relationship between those goroutines_ promises such
behavior.

Unfortunately, I cannot find any wording in the GMM that prevents
reordering one goroutine when such reordering breaks a transitive
happens-before relationship with an operation in another goroutine.

The permission to reorder one goroutine is given before the term
"happens before" is defined.  The GMM makes specific guarantees about
the non-transitive happens-before relationships between goroutines, and
gives examples that clearly demonstrate transitive intent, but that
transitive property is never explicitly stated.

In other words, the permission to reorder within one goroutine is never
limited to reordering happens-before operations that do not involve
other goroutines.

I believe this is a much more egregious omission in the GMM than not
mentioning atomics.  It is clearly intended, otherwise the whole GMM is
completely useless.

...Marvin

-- 
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/20191113162815.pjh4mrgvaae64xhq%40basil.wdw.

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

* Robert Engels  [191112 12:59]:
> The bug I referenced discusses the current problem with the MM
> specification. You are making assumptions that are not supported by
> the current MM, but as the bug points out, that is the current
> behavior.

I can see that point of view, and I don't think it is incorrect, just
not the only possible POV.

> Btw, there is no such thing as "concurrent access". There is a concept
> of "sharing" and the visibility of operations, and the resulting
> "memory consistency".

I never used the term "concurrent access".  The Go MM never uses the
terms "visibility" or "memory consistency".  Are we talking about the
same document?  I am talking about «https://golang.org/ref/mem».

The MM defines "happens before" and "happens concurrently".  I might
have made a mistake in the terminology that I used, but I do not see it,
and you have not given me enough information to determine what mistake
you believe I have made.

> The current MM is very specific about which operations create a
> "happens before" relationship (an important property of memory
> consistency), atomic operations are not listed.

(same as my first paragraph above)

If the writers of the MM intended it to enumerate all possible language
and standard library features that implement a happens before
relationship, as opposed to defining the terminology and allowing the
language spec and std lib docn to specify that such-and-such a feature
establishes a happens-before relationship, then I agree that something
needs to be added to the MM to cover atomics.

...Marvin

-- 
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/20191112192453.x6nuefkdppfshla5%40basil.wdw.

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

* Robert Engels  [191112 13:44]:
> Sorry, at work so I need to use the 'web mail' interface and it
> doesn't appear to be including them when I reply.

Understood.  I'll just try to follow the threading as best as I can.

...Marvin

-- 
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/20191112184729.bvvaenhww6dqp45g%40basil.wdw.

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

[You keep sending replies that are not connected to the message to which
you are replying.  RFC 822 (and subsequent RFCs) defines the In-Reply-To
header, which has been in use for more than 30 years.  Most MUAs will
add this automatically.  Failure to add the header really messes up MUAs
that display messages from the same thread together.  Does your MUA not
add this header???]

* Robert Engels  [191112 13:00]:
> This is not the issue I am referring to, I am referring to 
> https://github.com/golang/go/issues/5045
> 
> -Original Message-----
> >From: Marvin Renich 
> >Sent: Nov 12, 2019 11:30 AM
> >To: golang-nuts 
> >Subject: Re: [go-nuts] What is the correct way to access/modify slice 
> >elements concurrently
> >
> >[I almost missed this post because you did not reply to the thread.]
> >
> >* Robert Engels  [191108 11:41]:
> >> See https://github.com/golang/go/issues/10958 for using atomics in 
> >> tight/busy-wait loops.
> >
> >This doesn't have anything to do with atomics.  Atomic operations are
> >just one of many, many things you can do in a busy loop.  There is
> >nothing about atomics that is any more relevant to this issue than the
> >increment statement, i++.
> >
> >...Marvin

Hmm.  I am really confused.  You sent the link I quoted in reply to this
message:

>From: burak serdar 
>Sent: Nov 8, 2019 9:19 AM
>To: golang-nuts 
>Subject: Re: [go-nuts] What is the correct way to access/modify slice elements 
>concurrently

which has

Message-ID: 

What were you trying to say with your link to issue 10958?

...Marvin

-- 
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/20191112184159.2yep4f66wutu776l%40basil.wdw.

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

[I almost missed this post because you did not reply to the thread.]

* Robert Engels  [191108 11:41]:
> See https://github.com/golang/go/issues/10958 for using atomics in 
> tight/busy-wait loops.

This doesn't have anything to do with atomics.  Atomic operations are
just one of many, many things you can do in a busy loop.  There is
nothing about atomics that is any more relevant to this issue than the
increment statement, i++.

...Marvin

-- 
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/20191112173043.6mfa7iejihhkasos%40basil.wdw.

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

There are two different viewpoints you can take.  Either the Go Memory
Model must stand alone, and any concurrency claims made by the language
and standard library must be based on the limited set of operations
defined in the GMM, or the GMM provides the definitions and provides a
substantial, but not complete, list of operations satisfying that
definition, and a standard library package (or language feature) may
claim to satisfy the GMM definitions by some unspecified internal means.

If you accept the second, than I believe the documentation of the
sync/atomic package is enough to allow atomic operations to be used to
establish a happens-before relationship.

* burak serdar  [19 21:03]:
> You cannot define a "happens-before" relationship using only atomics
  ^ Accepting the atomic documentation, I disagree with this.
> with the current memory model. The happens-before relationship, the
 ^ Either way, I completely disagree
   with this.
> way it is written, relies on one goroutine blocking until the other
> comes to a point where "things happen" before the block is released.
> There is no blocking with atomics, hence there is no point in time
  ^ I (sort of) agree with this, ^ but not this.

Sort of, because any blocking that occurs takes place at the hardware
level (CPU and memory controller working out any cache and memory bus
contention).

> where one goroutine can be sure of things happened in the other
> goroutine.
> 
> The only guarantee with atomics is that when one goroutine reads a
> value, it will read the last written value. There are no guarantees on
> other values. According to the mm, things that happened before that
> final write may not be observable to other goroutines.

The memory model is not defined in terms of blocking; in fact the only
mention of blocking is in the explanatory, non-normative text for
sync.Once.  Blocking is a consequence of some operations in order to
obey the memory model; it is not the cause.

The memory model is defined in terms of happens-before relationships,
and says that certain operations create such a relationship.

My claim is that the GMM gives exactly three mutually exclusive choices:

  Also, if e1 does not happen before e2 and does not happen after e2,
  then we say that e1 and e2 happen concurrently.

There is no fourth choice, so if e1 and e2 do not happen concurrently,
then they have one of the happens-before relationships.

Most of the synchronization operations (e.g. channel reads and writes)
define that a happens-before relationship exists in a specific
direction.

The atomic package is different in that it specifies that two atomic
operations to the same memory location do not happen concurrently.  By
logical inference, rather than explicit statement, there must be a
happens-before relationship, but the direction of that relationship is
not specified.  You must use "pure logic" (in the mathematical sense),
if possible, to determine the direction.

I would be perfectly happy to have the memory model specify:

  If an atomic read r [in one goroutine] can be proven to have observed
  a specific atomic write w [from another goroutine], than the w
  happens-before the r.

I like this even better:

  Two atomic operations to the same variable v do not happen
  concurrently, and thus a happens-before relationship exists between
  them in an unspecified direction.  Sometimes logic may be used to
  prove the direction of the relationship.

If you adhere to the first viewpoint at the top of this message, than I
would say something like the above would be a mandatory addition to the
GMM document.  However, I am perfectly happy with the viewpoint that the
GMM provides the definitions, and the list of operations satisfying
those definitions can be specified in the Language Specification and the
standard library documentation.

...Marvin

-- 
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/20191112172034.nkhmoaqjjrawc7wx%40basil.wdw.

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

* burak serdar  [191108 08:42]:
> I was thinking about this. In general, it should be safe to replace
> 
> Lock()
> read/write one value
> Unlock()
> 
> with
> 
> AtomicRead/Write
> 
> Is that correct? The go memory model does not say anything about this.

Yes.

While others have argued that the GMM is not specific enough about this
case, I disagree.  The atomic package says it is "useful for
implementing synchronization algorithms".  This wording is, in my
opinion, sufficient to make two guarantees:

  1.  Values read and written with the atomic package will read and
  write whole values without corruption.
  2.  If a memory write from one goroutine is observed by another
  goroutine, this establishes a "happens before" relationship.

If these are not true, than the documentation in the atomic package is a
blatant lie.  Thus, the memory model does not need any additional
verbiage to clarify this.

And while the next paragraph in the atomic documentation discourages
using it for synchronization, I think the doc'n is overly pessimistic.
Certainly for the simple case of avoiding races due to concurrent
write/read of a single value, the atomic operations are a very good
solution.  If you can guarantee that all writes to a particular value
are done on a single goroutine, and all reads and writes are done using
the atomic package, than it is safe to have many other goroutines
reading that value, and using a mutex is overkill.

I do agree that channels and the sync package should be preferred over
implementing something similar with atomic, but don't shy away from
atomic for the simple cases that it does well.

...Marvin

-- 
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/20191108145435.3tdii3v3zgx3jv22%40basil.wdw.

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

* Kasun Vithanage  [191107 23:47]:
> type Foo struct {
>   Alive bool
> }
> 
> type Bar struct {
>   Foos []*Foo
> }
> 
> func (b *Bar) CheckFoosAlive()  {
>   for i := 0; i < len(b.Foos); i++ {
> if b.Foos[i].Alive {
>   fmt.Println("Alive")
> }
>   }
> }
> 
> func (b* Bar) MarkFooStatus(index int, status bool){
>   // after bound checking
>   b.Foos[index].Alive = status
> }

Volker's answer is very good, but for the simple case where Alive is (or
can be) a type that is handled by the atomic package, that is almost
certainly the best approach.

If the Foo struct is complicated, and you have lots of non-overlapping
access to b.Foos (with the occasional overlapping access), I strongly
suspect that putting a mutex in Foo and using that will give you the
best results.

As Volker said, try several different approaches, and measure with loads
approximating your real-world scenario.  Alternatively, implement the
approach that you think is easiest to maintain (from a source code POV),
and test to see if the performance is acceptable under load.  If it is,
don't bother trying to optimize.

...Marvin

-- 
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/20191108132521.bkrbxj2lv7wpinuo%40basil.wdw.

Re: [go-nuts] Need advice on AST formatting

[Marvin Renich]

* roger peppe  [191028 04:49]:
> On Sun, 27 Oct 2019, 02:52 Marvin Renich,  wrote:
> > I strongly encourage you to use
> >
> >   var fset = token.NewFileSet()
> >
> > rather than
> >
> >   fset := token.NewFileSet()
> >
> 
> Those two alternatives do exactly the same thing AFAIK. How is the latter
> vulnerable to shadowing bugs where the former isn't?

In this case they are identical.  It is the multi-variable "perhaps"
redefinition that is the problem.  Making a habit of using "var"
whenever possible allows the compiler to call out where you have
unintentionally shadowed one of several variables.

With the multi-variable short declaration, you cannot tell which
variables are being declared and which variables are "along for the
ride" without _careful_ examination of the code all the way back to the
beginning of the block.  If you use "var", it is explicit at that
statement.

  blk, msg, err := widget.Frabulate(arg)

Which of blk, msg, and err are being newly declared here?  You cannot
tell.

  var blk Thingle
  var msg string
  blk, msg, err = widget.Frabulate(arg)

Absolutely no question here; no need to examine earlier code.  And if
msg had been used earlier in this block, you would be told.  This also
has the distinct advantage that now the types of blk and msg are
explicit.  In the first case, someone reading the code would first have
to determine what widget is (package or var) and then find the
declaration of Frabulate to determine the types.

I assert that in a large codebase, the second form is significantly
easier to maintain than the first.

Furthermore, := only saves three characters over using var if you are
not mixing new declarations with simple assignment.  This is
insignificant.  And var has significantly less cognitive load for those
of us who have used many languages over the years, where := does not
have a universally accepted meaning across languages.

And, yes, I am aware that there are cases where you must use ":=".  I
wish that the design of the multi-variable short declaration had not
only provided for but required that the variables that the programmer
intended to declare were explicitly identified.  Perhaps Go2 will
address this.

...Marvin

-- 
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/20191028130952.mgfqdksai26atas2%40basil.wdw.

Re: [go-nuts] Need advice on AST formatting

[Marvin Renich]

* Denis Cheremisov  [191026 06:09]:
> The answer was simple: 
> 
> var fset token.FileSet – wrong
> 
> fset := token.NewFileSet() – right

I believe I am in the minority here, but I am not a singleton minority.
There are at least several of us who agree that «var» should be used
over «:=» whenever possible, and when you do use «:=», you should be
very careful, because it is frequently the cause of hidden shadowing
bugs.  This is especially true when declaring multiple variables.

I strongly encourage you to use

  var fset = token.NewFileSet()

rather than

  fset := token.NewFileSet()

...Marvin

-- 
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/20191027025214.uqkd4rtu6gbrbt5b%40basil.wdw.

Re: [go-nuts] Re: Static methods

[Marvin Renich]

First, let me apologize for writing in a way that you took to be
aggressive.  That was definitely not my intention.  My state of mind
when I wrote it was conversational, not antagonistic, and I did not
realize you would interpret it any other way.

* gera...@cloudoki.com  [191018 11:08]:
> hey, Marvin,
> 
> Actually I haven't noticed it was a 8 year old thread, neither had I 
> noticed that there should be any kind of preface in such cases (well, it 
> was just a comment and the group rules are not that clear, afterall).

There is no such formal rule in this group.  However, if you consider
how a mailing list or online discussion group works, you have many (in
this case presumably thousands of) readers who are reading the posts
chronologically as they are posted.  They have, typically, shorter
memory for details and longer memory for general trends.  When you post
a reply to a thread that died years ago, it is helpful to give these
thousands of readers a clue that they will have to go back to the
archives to figure out what the thread was about.

My intent was to be instructional, not critical.  Again, if you felt I
was criticizing you, please accept my apologies.

> My 
> comment was about a rather *usual feature in OOP languages and that people 
> with experience in such languages might wonder what's the idiomatic was to 
> express the same concept in GO*, that's why the comment was made with this 
> a caveat about its idiomaticity.

Fair enough.  On the other hand, Go is not intended to be an OO
language.  When people new to Go post on this list with OO
preconceptions about writing code in Go, they are frequently given the
suggestion to rethink the structure of their program using Go concepts,
rather than trying to shoe-horn the Go language to OO concepts.

> About *the subject*: I agree with you that the convention T/NewT is 
> sufficient, but in some contexts (like packages with many structs and many 
> functions that should me modelled as static methods in other languages) it 
> might clog the package namespace. That might lead programmers unexperienced 
> to GO into modelling *packages-as-classes*, which, I might be wrong, but I 
> believe it is not intention designed for them.

If I understand correctly what you are saying, I think you are right
that trying to use Go packages as OO classes will generally lead to less
robust and less idiomatic Go code.  I'm not sure I understand which side
you are on about NewT vs. T.New, but even in large packages with many
types, I don't think that using NewT will clog the namespace any more
than T.New will.

> About *your message*: I believe that most people might disagree with static 
> methods in GO (*maybe me included*), some might not, but anyways I believe 
> you're not entitled to speak in the name of everyone on this group, are 
> you?

I was not trying to speak for them.  I specifically said I "suspect" (my
opinion based on experience) "many" (not all) will disagree.  This
opinion was based on what has been written by others on this list over
the many years that I have read and participated in discussions here.

> And, moreover, I do not think the aggressive tone on your message is 
> consistent with a *discussion* group.

Again, I apologize if I sounded aggressive.  In a written medium, it is
difficult to convey tone.  If you were to take a heated verbal technical
discussion between two close colleagues and transcribe it, a third party
reading it my very well get the impression that the two were bitter
enemies.

...Marvin

-- 
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/20191018183019.epivtdb6w4ggauly%40basil.wdw.

Re: [go-nuts] Re: Static methods

[Marvin Renich]

* gera...@cloudoki.com  [191016 11:03]:
> I'm not sure about its *idiomacity*, but namespacing should be a nice thing.
> 
> On Tuesday, March 1, 2011 at 8:48:52 PM UTC, yiyus wrote:
   

Do you realize you are responding to an eight-year-old thread?  If you
really feel a need to reopen an old thread, please preface your message
appropriately, so that it's obvious.

In this case, I suspect many people on this list will disagree with your
reasoning.  There will only be one type T in the package, and therefore
func NewT() will already be unique in the package namespace.

...Marvin

-- 
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/20191016190857.7wbcnoojpvjavblp%40basil.wdw.

Re: [go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Marvin Renich]

* thatipelli santhosh  [191015 08:07]:
> Hi Marvin,
> 
> I am curious to know if we approx 10 ( we don't know exact amount of
> slice entries)  add to slice.  Slice will grow based on our size of data
> and underlying array size but doing this create multiple underlying arrays
> (more memory resource utilization, processing). In such case,  what is the
> optimum solution?

The built-in append function does not simply allocate a new backing
array with the exact size needed for the new slice; it allocates a slice
with extra capacity.  It uses some heuristics to give a reasonable
speed/memory-usage trade-off for "typical" cases.  The current algorithm
can be found in src/runtime/slice.go in the function growslice.  Note
that the specific algorithm is not covered by the Go compatibility
guarantee.

If you are trying to be practical, you should start by implementing the
obvious and straight-forward algorithm first (i.e. use append as it was
intended), and then profile your code (the whole application, not just
the code that grows the slice) to determine where optimization will be
useful.  It is very unlikely that the calls to append will be worth
spending time improving.

If this is an academic question, start the same way, but how you decide
where to spend time analyzing the results may be different.

In an application that is only going to have a slice of about 100,000
integers, the cost of append is unlikely to be of any concern at all on
any real production machine.

If it turns out that the append is a bottleneck (memory or speed), you
can write your own Append function by starting with the AppendByte
function from the go-slices-usage-and-internals blog that I linked to in
my previous message.  Do the obvious fix-ups for byte to int (or
whatever your data type is), and modify the algorithm that determines
the capacity of the new slice (the (n+1)*2 in that function).  Then use
your Append function instead of the built-in append.  (Again, note that
this simple (n+1)*2 is _not_ what the built-in append function uses.)

A very simple first optimization (without resorting to your own Append
function) is to initially create the slice using make([]int, 0,
initialCapacity) where you choose initialCapacity to be larger than the
expected maximum size by some arbitrary percentage (e.g. 25%).

This playground link «https://play.golang.org/p/qtfHaoK-6Hy» shows
exactly where the allocations will occur.  It took exactly 28
allocations to reach 100,000 elements.  To show how insignificant that
is, on my laptop it took only 11ms to run that program.  Is that 11ms
really significant in your program?

...Marvin

-- 
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/20191015141236.rldnk7dscbio6pfs%40basil.wdw.

Re: [go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Marvin Renich]

P.S. If you are still having trouble after reading the responses to your
query, use the go playground (https://play.golang.org/) to create a
simple program that demonstrates what you are trying, and post the link
you get from clicking the "Share" button, and explain what you would
like the output to be.  People can then modify your playground entry to
help you.

Note that when passing slices to other functions that might modify the
slice, you either need to return the modified slice or pass a pointer to
the slice.  This is why the append function is the way it is.

...Marvin

-- 
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/20191015120406.532esrartpryiw6k%40basil.wdw.

Re: [go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Marvin Renich]

[When you are replying to someone else's message, reply to that message,
not your original message.  Your reply lost the context of the message
to which you were replying (Jan Mercl's).]

* Stuart Davies  [191015 07:24]:
> My goal is to contain a list of integers that may extend to possibly a 
> couple of thousand entries. Initial size is 100. Extensions add 50 entries 
> at a time.
> 
> I declared the array initially with:
> 
> make([]int64, 100).
> 
> I tried using the Append function but could not Append past the 100 
> entries. The 101 entry threw a panic so I detirmined to extend the array 
> myself. 
> 
> I would have thought Append should extend if required but it did not (or am 
> I using it incorrectly). I looked at some other code examples but could not 
> find a solution.
> 
> In C there is an array copy function that is implemented by the processor 
> directly, it's been a long time since I used C and assembler but I rememer 
> there were non overlapping mem copy instructions that would make an array 
> copy very fast. 
> 
> Is there somthing similar in GO.
> 
> This is a general question, it is not really specific to my application. I 
> just want to know the best practices for 'extending' an array of arbitrary 
> type.

The append function should do exactly what you want, but you must use it
properly.  There is a good explanation of slices on the Go blog at
«https://blog.golang.org/go-slices-usage-and-internals».  The builtin
append function will append to the existing backing array if there is
enough capacity, but will allocate a new backing array if necessary.
Because of this, it always returns the new slice, and you must use the
returned slice, rather than the original.  Here is a playground link
demonstrating the use of append:
«https://play.golang.org/p/5Pl16hN-T5u».

...Marvin

-- 
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/20191015115219.dca3mjcdj54qxslq%40basil.wdw.

[go-nuts] WAIT_TIMEOUT inconsistency in golang.org/x/sys/windows

[Marvin Renich]

In golang.org/x/sys/windows, the WAIT_* return codes from
WaitForSingleObject and WaitForMultipleObjects are defined as untyped
integer constants except for WAIT_TIMEOUT, which is a syscall.Errno.

All the other syscall.Errno values less than 1700 (the first RPC_ error)
begin with ERROR_.

The WaitFor* functions above return WAIT_TIMEOUT as a uint32, not as an
error.  WAIT_TIMEOUT being an Errno makes using these functions slightly
more complicated.

I think the syscall.Errno should have been named ERROR_WAIT_TIMEOUT and
WAIT_TIMEOUT should have been an untyped constant.

The worst part about this situation is not that a type conversion is
required on the WAIT_TIMEOUT constant to make it useful, but the
cognitive load required to arrive at that solution.  Whether you realize
when first writing the code that WAIT_TIMEOUT is differently typed than
WAIT_OBJECT_0 and WAIT_ABANDONED or you find out the first time you
compile, you must then realize that windows.Errno is a type alias for
syscall.Errno, which is a uintptr, and the value for WAIT_TIMEOUT is
small enough to be safely converted to uint32 to match the return type
of the WaitFor* functions.

Even if you are already familiar with Errno, this is a moderate and
completely unnecessary cognitive load.  If you are not familiar, you
must read documentation or source code for both x/sys/windows and
syscall to resolve the issue.

To make things worse, syscall got it right!  syscall.WAIT_TIMEOUT is an
untyped integer constant.

Are there any other Windows API functions other than WaitFor*Object*
that use or return WAIT_TIMEOUT?  As far as I can tell, WAIT_TIMEOUT is
only used in a context where WAIT_OBJECT_0 and WAIT_ABANDONED are also
used.

Normally, I would hesitate to encourage changing this, but golang.org/x
is explicitly excluded from the compatibility guarantee to allow
incompatible changes that improve its usefulness, which I think this
change would do.  Anyone currently using WAIT_TIMEOUT would have the
choice of using gofmt (or their favorite editor) to rename it to
ERROR_WAIT_TIMEOUT or vendoring golang.org/x/sys.

I suspect many current uses of WAIT_TIMEOUT are in a switch statement as
uint32(windows.WAIT_TIMEOUT), which would compile just fine with the
change.

Thoughts?

...Marvin

-- 
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/20190926152241.pmhewuprsol465rk%40basil.wdw.

Re: [go-nuts] Regarding strings replace functions issues

[Marvin Renich]

* Durga Someswararao G  [190827 14:07]:
> Hi,
> 
> Can anyone help me in this case.
> 
> I was reading byte data(array of bytes) from another process and converted 
> that data to string. Now I am trying to replace escape sequences \n with 
> strings.Replace function but golang not detecting it.
> 
> Even I tried with bytes.Replace function but no use.
> 
> Also observed even strings.Contains function also not detecting \n.
> 
> Eg:
> 
> strings.Replace("String1\nString2", "\n", "golang",-1 )

This playground link does what I think you are trying to do, based on
your example: https://play.golang.org/p/VqNgO-P10oi

package main

import (
"fmt"
"strings"
)

func main() {
var s = "Hello,\nplayground"
fmt.Println(s)
s = strings.Replace(s, "\n", " *** ", -1)
fmt.Println(s)
}

If you use the playground to share a simple example of how you are
currently using this and what you want the result to be, we will be able
to help you better.

...Marvin

-- 
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/20190827182543.f5rlnnbbmzgciqmt%40basil.wdw.

Re: [go-nuts] Split a empty string will get a one element array?

[Marvin Renich]

* Kurtis Rader  [190807 18:43]:
> Please don't respond to threads that are seven years old. Having said that
> the behavior is reasonable and the behavior you and the O.P. expect is not
> reasonable. Consider the following examples:
> 
> result := strings.Split("abc", "")
> result := strings.Split("ab", "b")
> result := strings.Split("", "")
> 
> The first statement yields a slice of three elements. The second a slice of
> two elements with the second being an empty string. What should the second
> statement yield? A slice of one element (the empty string) or an empty
> slice? The former is consistent with all the other cases while the latter
> is inconsistent.

You are mixing apples and oranges.  The rule is different if the
separator is "" than if it is not empty.  This playground link
https://play.golang.org/p/6nbTIW50i2g shows the difference.  The OP was
asking about " " (non-empty) as the separator.  The documentation for
Split is very specific about both these cases.

...Marvin

-- 
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/20190808103604.pfbeaj7tg6gwwyyy%40basil.wdw.

Re: [go-nuts] Testing using mock functionality

[Marvin Renich]

* wylderke...@gmail.com  [190722 01:11]:
> I'm new to go (and new to unit testing) and have a question about how to 
> test my code. I have a package that uses a library, with a kinda big 
> interface , let's 
> call it A. I don't use all the functions in A, but I want to mock the 
> functionality that I do use from this interface for my unit tests. So I 
> made my own interface that is a subset of the big interface, let's call it B
> .
> 
> The problem is that I would also like to test the construction of the 
> interface. So I made a constructor type that returns B. But I cannot pass 
> the real A constructor function into my package in place of the mock B 
> constructor!
> 
> package main
> 
> // A is an interface that does X, Y and Z
> type A interface {
>   X()
>   Y()
>   Z()
> }
> 
> // B is a strict subset of A.
> type B interface {
>   X()
>   Y()
> }
> 
> // AConstructor claims to build an interface that does A
> func AConstructor() A {
>   return nil
> }
> 
> // BConstructorType is a type of function that returns a B interface
> type BConstructorType func() B
> 
> // Initialize creates a B and calls the methods in the interface. (I want 
> to be able to mock A and test this function)
> func Initialize(constructor BConstructorType) {
>   b := constructor()
>   b.X()
>   b.Y()
> }
> 
> func main() {
>   // cannot use AConstructor (type func() A) as type BConstructorType in 
> argument to Initialize Initialize(AConstructor)
>   Initialize(AConstructor)
> }
> 
> Why is AConstructor not of type BConstructorType? It seems like the type 
> system is interpreting it's definition quite literally. Would this change 
> the current compiler implementation a lot to support this kind of smart 
> type checking?
> 

A and B are different types.  B is a subset of A (and they are both
interfaces), therefore a value of type A implements B, so a value of
type A can be assigned (see Assignability[1]) to a variable of type B
without any explicit conversion (see Conversions[2]) (i.e. the
conversion is performed implicitly).

However, a function returning A is not assignable to a variable of type
function returning B, even if A is assignable to B.  The functions have
different types (see Function types[3]).  The rules of assignability are
applied neither individually nor recursively to each argument and result
of the function; the function types as a whole must satisfy the rules of
assignability.

So, yes, the type system is intentionally very literal in its
definition.  Consider a slightly different example (using types A and B
above):

var z []A = ... // an expression yielding a value of the proper type
var x []B = z

According to expectations from the design of the language, the second
assignment should not cause an allocation of a new underlying array.
But for this assignment to work, such an allocation would be necessary.
So, the language designers decided that satisfying the expectations was
more important than doing something that hides a potentially large
allocation.  (Just to be explicit, the above assignment will not
compile.)

In your case, however, a simple function literal will solve your
problem:

  Initialize(func() B { return B(AConstructor()) })

In fact, the explicit conversion B(...) in the return statement is
unnecessary, but I think it makes it more clear that this is an
intentional conversion.  It also makes it clear why the function literal
is necessary in the first place.

...Marvin

[1] https://golang.org/ref/spec#Assignability
[2] https://golang.org/ref/spec#Conversions
[3] https://golang.org/ref/spec#Function_types

-- 
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/20190722113227.f4dhgcltq6psfxz7%40basil.wdw.

Re: [go-nuts] Let's play

[Marvin Renich]

* Ali Hassan  [190712 12:56]:
> 
> If you curious about check out the link below 
> https://koohinoorgo.blogspot.com/2019/07/methods-bind-to-special-type-of-receiver.html

The only thing about this message that does not look like a phishing or
Trojan attack is the end of the URL.  The subject and the "If curious,
click link" as the only text of the message looks exactly like a
nefarious message.

Please don't send "teaser" messages to a technical mailing list; this is
generally considered very rude.  This is a moderately high volume
mailing list, with a large reader base.  Please be polite and include
enough information in your mailing list post to allow the many readers
to quickly and easily decide if they are interested in following the
link to read more.

Thank you...Marvin

-- 
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/20190712173928.l7nnjupii5rf2nad%40basil.wdw.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [cgo ] Export go function to C - illegal character

[Marvin Renich]

* nicolas_boiteux via golang-nuts  [190626 13:19]:
> /*
> #include 
> #include 
> #include 
> extern void __stdcall RVExtension(char *output, int outputSize, const char 
> *function);
> */
> 
> //export RVExtensionVersion
> func RVExtensionVersion(output *C.char, outputsize C.size_t) {
> result := C.CString("Version 1.0")
> defer C.free(unsafe.Pointer(result))
> var size = C.strlen(result) + 1
> if size > outputsize {
> size = outputsize
> }
> C.memmove(unsafe.Pointer(output), unsafe.Pointer(result), size)
> }
> 
> 
> with this code ? it compiled but the entry point is not visible via dumpbin

Does the declaration of RVExtension in the .c file match the cgo
declaration above (i.e. with extern and __stdcall)?

...Marvin

-- 
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/20190626181033.4atnukcbsv6vwvdy%40basil.wdw.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [cgo ] Export go function to C - illegal character

[Marvin Renich]

* nicolas_boiteux via golang-nuts  [190626 12:15]:
> i have some news.
> 
> With this kind of declaration
> extern void __fastcall RVExtension(char *output, int outputSize, const char 
> *function){
> goRVExtension(output, outputSize, function);
> }; 

> as you can see in error message this time the entry point is correctly 
> identified as* @RVExtension@12* (but without underscore) , but i don't 
> succeed to resolv the bug :(

My original message (and the link I included) identified leading
underscore and trailing @ and number as being __stdcall, not __fastcall.
Try using __stdcall instead of __fastcall.

Note that the @RVExtension@12 above has a leading @ instead of _.

...Marvin

-- 
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/20190626165007.4vssb3ttwj2s3dgn%40basil.wdw.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [cgo ] Export go function to C - illegal character

[Marvin Renich]

* nicolas_boiteux via golang-nuts  [190623 15:33]:
> Precisly, i don't know what is this @12, and nobody can explain this :( 
> It's for a windows build and the dll is load by arma game.

The leading '_' and trailing '@' followed by a number is the __stdcall
decoration for a C name in the produced object symbol table.  I do not
know what calling conventions cgo recognizes or how to tell cgo what
calling convention to use.  Hopefully someone else can help with that.

See 
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019

...Marvin

-- 
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/20190623205435.cza4lzydo4ftr73n%40basil.wdw.
For more options, visit https://groups.google.com/d/optout.