Re: [go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

[eric...@arm.com]

Why is it not safe to read here? The real write operation is done through 
CAS, assuming the read value is out of date, then the CAS operation will 
fail.

在2022年4月2日星期六 UTC+8 11:41:00 写道：

> On Fri, Apr 1, 2022 at 8:31 PM 机智的小小帅  wrote:
> >
> > Hi,all. I'm reading the source code of sync package recently.
> >
> > Here is a code snippet in sync/mutex.go.
> >
> > // src/sync/mutex.go
> > type Mutex struct {
> > state int32
> > sema uint32
> > }
> >
> > func (m *Mutex) lockSlow() {
> > var waitStartTime int64
> > starving := false
> > awoke := false
> > iter := 0
> > old := m.state // Here!!! not use atomic.LoadInt32()
> > for {
> > // Don't spin in starvation mode, ownership is handed off to waiters
> > // so we won't be able to acquire the mutex anyway.
> > if old&(mutexLocked|mutexStarving) == mutexLocked && 
> runtime_canSpin(iter) {
> > // Active spinning makes sense.
> > // Try to set mutexWoken flag to inform Unlock
> > // to not wake other blocked goroutines.
> > if !awoke && old == 0 && old>>mutexWaiterShift != 0 &&
> > atomic.CompareAndSwapInt32(, old, old|mutexWoken) {
> > awoke = true
> > }
> > // ...
> > old = m.state // And here!!! not use atomic.LoadInt32()
> > continue
> > }
> > // ...
> > }
> > // ...
> > }
> >
> >
> > You can see full context in link1 and link2
> >
> > I have read The Go Memory Model, It says "Reads and writes of values 
> larger than a single machine word behave as multiple machine-word-sized 
> operations in an unspecified order."
> >
> > Althought it is usually 32 or 64 bits on modern machine,I think if you 
> want a operator is atomic,you should use atomic.LoadXXX() explicitly.
> >
> > I think a ordinary read operator like old := m.state in concurrent 
> environment is not safe,it may read a unexpected value.
> >
> > I wonder whether the oridinary read operation is right? Could you help 
> me? Thanks in advance.
> >
> > I'm very sorry to disturb you...
>
> When reading or writing a value that is the size of a memory word or
> smaller and is aligned such that the value does not cross a word
> boundary in memory Go assumes that the entire value will always be
> read or written as a unit. This is true of all processors that Go
> currently supports.
>
> The purpose of an atomic operation is different: it is about when the
> value is visible to other cores on the same system.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fe33644e-45c3-43ac-8d60-1053fb40a6bdn%40googlegroups.com.

Re: [go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

[Ian Lance Taylor]

On Fri, Apr 1, 2022 at 8:31 PM 机智的小小帅  wrote:
>
> Hi,all. I'm reading the source code of sync package recently.
>
> Here is a code snippet in sync/mutex.go.
>
> // src/sync/mutex.go
> type Mutex struct {
> state int32
> sema  uint32
> }
>
> func (m *Mutex) lockSlow() {
> var waitStartTime int64
> starving := false
> awoke := false
> iter := 0
> old := m.state // Here!!! not use atomic.LoadInt32()
> for {
> // Don't spin in starvation mode, ownership is handed off to waiters
> // so we won't be able to acquire the mutex anyway.
> if old&(mutexLocked|mutexStarving) == mutexLocked && 
> runtime_canSpin(iter) {
> // Active spinning makes sense.
> // Try to set mutexWoken flag to inform Unlock
> // to not wake other blocked goroutines.
> if !awoke && old == 0 && old>>mutexWaiterShift != 0 &&
> atomic.CompareAndSwapInt32(, old, old|mutexWoken) {
> awoke = true
> }
> // ...
> old = m.state // And here!!! not use atomic.LoadInt32()
> continue
> }
> // ...
>   }
>   // ...
> }
>
>
> You can see full context in link1 and link2
>
> I have read The Go Memory Model, It says "Reads and writes of values larger 
> than a single machine word behave as multiple machine-word-sized operations 
> in an unspecified order."
>
> Althought it is usually 32 or 64 bits on modern machine,I think if you want a 
> operator is atomic,you should use atomic.LoadXXX() explicitly.
>
> I think a ordinary read operator like old := m.state in concurrent 
> environment is not safe,it may read a unexpected value.
>
> I wonder whether the oridinary read operation is right? Could you help me? 
> Thanks in advance.
>
> I'm very sorry to disturb you...

When reading or writing a value that is the size of a memory word or
smaller and is aligned such that the value does not cross a word
boundary in memory Go assumes that the entire value will always be
read or written as a unit.  This is true of all processors that Go
currently supports.

The purpose of an atomic operation is different: it is about when the
value is visible to other cores on the same system.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXBFNtB8JWww3K7vKACq-mF7Lr0hquwaBWGy2S%3DgS2g5g%40mail.gmail.com.

[go-nuts] Re: Tacit Golang?

[Henry]

Something like this? https://play.golang.com/p/rhu9PX9GSbp

On Saturday, April 2, 2022 at 5:41:52 AM UTC+7 sam.a@gmail.com wrote:

> Point-free programming, or "tacit programming",  is a convention that 
> highlights the intent without syntactic noise. 
>
> For those unfamiliar, wikipedia: 
> https://en.wikipedia.org/wiki/Tacit_programming
>
> I want better function composition. "Write a helper function to route 
> values out to values in, like a normal person." Sure, but who needs Go when 
> you have C, eh? A tacit sugaring merely provides a lexically distinctive 
> means to indicate the intent that function f0 should be called with the 
> return value of f1, and f1 of f2, and so on, with reduced syntax.
>
> There are a couple layers here, there's an easy win, a possible next step, 
> and well, madness.
>
> A. Go uses a thin-arrow, "<" + "-", as a receive/send operator and to 
> signify directionality of a channel. This same operator could be used like 
> so, "c := a <- b()" to assert the following:
> 1. Token "a" resolves to a function pointer
> 2. Token "b" returns none, one, or many values, such that "a(b())" is 
> legal.
> 3. Token "c" can legally be assigned the value of the desugared 
> expression.
> This suggestion imposes ambiguity between the meaning of "(chan 
> int)(x)<-y(z)" and "(func(int)int)(x)<-y(z)", and I have chaotic intuitions 
> about the meaning of "(func(int)int)(x) <- (chan int)(y)", or even 
> "(func(int)int)(x) <- (chan int)(y) <- z", but x(<-y) is clearly 
> (func[T](T)T)(x)(<-(chan[T] T)(y)). A minimally disruptive solution, then, 
> is to assert that the tip of such a tacit chain must be a full-syntax 
> invokation, e.g. for "f0 <-...f <- ?", only "f(...)" is valid. This 
> means expressions like "c0 <- f0 <- f1(f2 <-f3(<-c1))" are unambiguous 
> without a mountain of ellipses.
>
> B. At cost of introducing a new concept for Go entirely, it would be 
> convenient to declare a function as "f0 := f1 <- f2 <- f3", resolving as 
> suggested by the statement: "reflect.TypeOf(f0) == 
> reflect.FuncOf([]reflect.Type{reflect.TypeOf(f3).In(0), ..}, 
> []reflect.Type{reflect.TypeOf(f1).Out(0), ...})". The straightforward 
> path to implementation would resolve that naively, as suggested by the 
> following: "f0 := func[T handWaving.inT, U handWaving.outT](a... T) (...U) 
> {return f1(f2(f3(a...)))}". A statement like "go f0 <- f1 <-f2 <- f3", 
> assuming "go func[T handWaving.inT](a...T) {f0(f3(a...));}" is legal, would 
> be an attractive pattern.
>
> C. Naively, point B suggests that the functions thus concatenated could be 
> assembled as to preallocate the stack for the entire concatenation, 
> omitting the allocations and moves/copies between function calls, and 
> rather writing the return values to the stack for the predecessor function, 
> by analogy, like a reverse closure or a heterogenous recursion. For the 
> example "f0 := f1 <- f2 <- f3", because I expect that statement to only be 
> legal if "f1(f2(f3(..args..)))" is legal, the out-signature of f3 is 
> assignment-compatible with the in-signature of f2, and f2 to f1. Concerns 
> such as an element in the concatenation being recursive, blocking, or 
> corrupting only apply to the function at stack-head; pre-allocating even a 
> potentially large stack exposes only risk shared with allocating the same 
> stack progressively, but with lower instructional segmentation. A possible 
> but unlikely edge-case, if for some reason, a generic function cannot be 
> appropriately stenciled, the optimization being suggested might only 
> partially be applied, or else not applied at all. 
>
> Ellipses are basically universal for "I give you control, but I expect it 
> back". Loops don't give up control, rather push it on a swing like a child. 
> Go-func commissions an agent, expecting no control. Point A would change 
> the expression somewhat, but by requiring the head of a concatenation to be 
> an execution, the language of "I give, but I expect" is kept, but uses the 
> existing language of sending on channels,  "B to A, your turn A", and is 
> suggested as unambiguously extending the "I give, I expect" agreement 
> backwards towards the tail. The symbols suggested are certainly not sacred, 
> either.
>
> Point B and C are harder to recommend unequivocally, but could be potently 
> powerful tools for communicating very long but uncomplicated calls. Point B 
> has very few downsides, but represents introduction of a case where a human 
> might understand an expression differently than a parser, while Point C 
> introduces a layer of complexity to serve a use case that, for better or 
> worse, could serve to push a new idiom onto the Gopher community. 
>
> These three points present no risk to the Go 1 compatibility promise, but 
> I will admit before anyone else that I haven't proven that Point C is worth 
> the investment, and I expect some difficult questions about Point B.
>

-- 
You received this message because 

[go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

[机智的小小帅]

Hi,all. I'm reading the source code of sync package recently.

Here is a code snippet in sync/mutex.go.

// src/sync/mutex.go
type Mutex struct {
state int32
sema  uint32
}

func (m *Mutex) lockSlow() {
var waitStartTime int64
starving := false
awoke := false
iter := 0
old := m.state // Here!!! not use atomic.LoadInt32()
for {
// Don't spin in starvation mode, ownership is handed off to waiters
// so we won't be able to acquire the mutex anyway.
if old&(mutexLocked|mutexStarving) == mutexLocked && 
runtime_canSpin(iter) {
// Active spinning makes sense.
// Try to set mutexWoken flag to inform Unlock
// to not wake other blocked goroutines.
if !awoke && old == 0 && old>>mutexWaiterShift != 0 
&&
atomic.CompareAndSwapInt32(, old, old|mutexWoken) {
awoke = true
}
// ...
old = m.state // And here!!! not use atomic.LoadInt32()
continue
}
// ...
  }
  // ...
}


You can see full context in link1 
 and link2 


I have read The Go Memory Model , It says "Reads 
and writes of values larger than a single machine word behave as multiple 
machine-word-sized operations in an unspecified order."

Althought it is usually 32 or 64 bits on modern machine,I think if you want 
a operator is atomic,you should use atomic.LoadXXX() explicitly.

I think a ordinary read operator like old := m.state in concurrent 
environment is not safe,it may read a unexpected value.

I wonder whether the oridinary read operation is right? Could you help me? 
Thanks in advance.

I'm very sorry to disturb you...

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/31c5c265-a125-48ad-bbdc-5cb5f0fd7a8en%40googlegroups.com.

[go-nuts] Seeing loadinternal: cannot find runtime/cgo with -buildmode=pie when cross-compiling

[Kirill Kolyshkin]

I am seeing the following error when cross-compiling go source on ARM with 
-buildmode=pie. Despite the error (or is it a warning?), the compilation 
succeeds
(i.e. go build exits with 0 and the binary is created). Adding CGO_ENABLED=1
(since this is cross-compilation, cgo is disabled by default) eliminates 
the warning.

Please see a complete repro below. This happens on the following linux 
platforms:
 - armel aka arm v6;
 - armhf aka arm v7;
 - riscv64;
 - s390x.

It does NOT happen
 - natively (linux/amd64);
 - on arm64.
- on ppc64le.

I haven't tried anything else (e.g. mips or 386), nor have I checked that 
the resulting binaries work.

My questions are:
1. If "loadinternal: cannot find runtime/cgo" is an error, why go build 
creates the binary and exits with code of 0? This looks like a bug.
2. Does -buildmode=pie require enabling cgo?

Here's a repro using docker or podman (I guess you can do the same without 
Docker on a Debian machine).


mkdir hello
cd hello
# Create the Dockerfile.
cat << _EOF_ > Dockerfile
FROMgolang:1.18.0-bullseye
RUNapt-get -qq update \
&& apt-get -qq -y install gcc-arm-linux-gnueabi libc-dev-armel-cross
ENVHOST=arm-linux-gnueabi GOARCH=arm GOARM=6 CC=arm-linux-gnueabi-gcc
EOF

# Create the source.
cat << _EOF_ > hello.go
package main

func main() {
println("hello")
}
_EOF_

# Create go.mod.
go mod init hello && go mod tidy

# Build a docker image.
docker build --tag hello .


Now, this is what I see when building normally:

$ docker run -it --rm -v .:/hello hello
root@42d4fe21de73:/go# cd /hello
root@42d4fe21de73:/hello# go build .
root@42d4fe21de73:/hello# echo $?
0
root@42d4fe21de73:/hello# ls -l hello
-rwxr-xr-x. 1 root root 1218776 Apr  1 20:25 hello

Now let's add -buildmode=pie:

root@42d4fe21de73:/hello# rm hello  
root@42d4fe21de73:/hello# go build -buildmode=pie .
# hello
loadinternal: cannot find runtime/cgo
root@42d4fe21de73:/hello# echo $?
0
root@42d4fe21de73:/hello# ls -l hello
-rwxr-xr-x. 1 root root 1121328 Apr  1 20:26 hello

Now, let's enable CGO (since it's disabled by default when cross-compiling):

root@42d4fe21de73:/hello# CGO_ENABLED=1 go build -buildmode=pie .
root@42d4fe21de73:/hello# ls -l hello
-rwxr-xr-x. 1 root root 1143380 Apr  1 20:27 hello

System info:

root@42d4fe21de73:/hello# env
HOSTNAME=42d4fe21de73
PWD=/hello
GOARCH=arm
container=podman
GOARM=6
HOME=/root
GOLANG_VERSION=1.18
TERM=xterm
HOST=arm-linux-gnueabi
SHLVL=1
PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
CC=arm-linux-gnueabi-gcc
OLDPWD=/go
GOPATH=/go
_=/usr/bin/env
root@42d4fe21de73:/hello# go env
GO111MODULE=""
GOARCH="arm"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct;
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOARM="6"
AR="ar"
CC="arm-linux-gnueabi-gcc"
CXX="g++"
CGO_ENABLED="0"
GOMOD="/hello/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -marm -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build3607723978=/tmp/go-build 
-gno-record-gcc-switches"
root@42d4fe21de73:/hello# $CC --version
arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@42d4fe21de73:/hello# go version
go version go1.18 linux/amd64
root@42d4fe21de73:/hello# 

-- 
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/58608533-0196-41e8-bb45-369402194943n%40googlegroups.com.

[go-nuts] Re: RFC: function or interface?

[Adam Pritchard]

Thank you both for your responses.

I’m going to switch to returning structs that implement an unexported 
interface. I don’t have a super convincing justification, but here are the 
reasons…

1: It’s unexported because it’s not expected to be implemented externally 
and passed in. But if a caller wants to implement their own (and still use 
Must 

 
or ChainStategies 
,
 
for example), then they can define the interface themselves — I’ll have 
comment indicating this. (This unexported interface thing is used by 
pkg/errors 

 
and I’ve read reference to it elsewhere, but I can’t find where now.)

2: Why I’m concerned with implementing a particular interface or function 
signature at all, when I could just return any old thing: I would like to 
think that some users of the library would make the strategy a runtime 
decision based on configuration. So it would be nice if their code paths 
don’t care which strategy it is.

3: If the caller wants just a function, they can easily get with a bound 
method. Something like:

getClientIP := realclientip.NewSingleIPHeaderStrategy("X-Real-IP").ClientIP

Not lovely, but it works the same.

4: As Martin said, an interface means I could “potentially add other 
methods to it in future without breaking compatibility”. Now, I really, 
specifically want this to be very simple, slim library (I really do want it 
to be reimplemented in other languages), but I can imagine, say, collecting 
stats on calls and failures (empty string returns). Then adding a String() 
method that prints those stats and/or the strategy type and configuration 
(I like logging such things). (Yes, the library user could also just add a 
wrapper that does that.)

I haven’t start making the changes yet, so it could all feel like garbage — 
we’ll see. I’m also not yet settled on the names of things — I’ll pay more 
attention to the verb-iness/noun-iness.

Thanks again.

Adam
​

-- 
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/c83a2c98-f11d-4341-9fcf-d0b35d59ad06n%40googlegroups.com.

[go-nuts] Tacit Golang?

[Sam Hughes]

Point-free programming, or "tacit programming",  is a convention that 
highlights the intent without syntactic noise. 

For those unfamiliar, 
wikipedia: https://en.wikipedia.org/wiki/Tacit_programming

I want better function composition. "Write a helper function to route 
values out to values in, like a normal person." Sure, but who needs Go when 
you have C, eh? A tacit sugaring merely provides a lexically distinctive 
means to indicate the intent that function f0 should be called with the 
return value of f1, and f1 of f2, and so on, with reduced syntax.

There are a couple layers here, there's an easy win, a possible next step, 
and well, madness.

A. Go uses a thin-arrow, "<" + "-", as a receive/send operator and to 
signify directionality of a channel. This same operator could be used like 
so, "c := a <- b()" to assert the following:
1. Token "a" resolves to a function pointer
2. Token "b" returns none, one, or many values, such that "a(b())" is 
legal.
3. Token "c" can legally be assigned the value of the desugared 
expression.
This suggestion imposes ambiguity between the meaning of "(chan 
int)(x)<-y(z)" and "(func(int)int)(x)<-y(z)", and I have chaotic intuitions 
about the meaning of "(func(int)int)(x) <- (chan int)(y)", or even 
"(func(int)int)(x) <- (chan int)(y) <- z", but x(<-y) is clearly 
(func[T](T)T)(x)(<-(chan[T] T)(y)). A minimally disruptive solution, then, 
is to assert that the tip of such a tacit chain must be a full-syntax 
invokation, e.g. for "f0 <-...f <- ?", only "f(...)" is valid. This 
means expressions like "c0 <- f0 <- f1(f2 <-f3(<-c1))" are unambiguous 
without a mountain of ellipses.

B. At cost of introducing a new concept for Go entirely, it would be 
convenient to declare a function as "f0 := f1 <- f2 <- f3", resolving as 
suggested by the statement: "reflect.TypeOf(f0) == 
reflect.FuncOf([]reflect.Type{reflect.TypeOf(f3).In(0), ..}, 
[]reflect.Type{reflect.TypeOf(f1).Out(0), ...})". The straightforward 
path to implementation would resolve that naively, as suggested by the 
following: "f0 := func[T handWaving.inT, U handWaving.outT](a... T) (...U) 
{return f1(f2(f3(a...)))}". A statement like "go f0 <- f1 <-f2 <- f3", 
assuming "go func[T handWaving.inT](a...T) {f0(f3(a...));}" is legal, would 
be an attractive pattern.

C. Naively, point B suggests that the functions thus concatenated could be 
assembled as to preallocate the stack for the entire concatenation, 
omitting the allocations and moves/copies between function calls, and 
rather writing the return values to the stack for the predecessor function, 
by analogy, like a reverse closure or a heterogenous recursion. For the 
example "f0 := f1 <- f2 <- f3", because I expect that statement to only be 
legal if "f1(f2(f3(..args..)))" is legal, the out-signature of f3 is 
assignment-compatible with the in-signature of f2, and f2 to f1. Concerns 
such as an element in the concatenation being recursive, blocking, or 
corrupting only apply to the function at stack-head; pre-allocating even a 
potentially large stack exposes only risk shared with allocating the same 
stack progressively, but with lower instructional segmentation. A possible 
but unlikely edge-case, if for some reason, a generic function cannot be 
appropriately stenciled, the optimization being suggested might only 
partially be applied, or else not applied at all. 

Ellipses are basically universal for "I give you control, but I expect it 
back". Loops don't give up control, rather push it on a swing like a child. 
Go-func commissions an agent, expecting no control. Point A would change 
the expression somewhat, but by requiring the head of a concatenation to be 
an execution, the language of "I give, but I expect" is kept, but uses the 
existing language of sending on channels,  "B to A, your turn A", and is 
suggested as unambiguously extending the "I give, I expect" agreement 
backwards towards the tail. The symbols suggested are certainly not sacred, 
either.

Point B and C are harder to recommend unequivocally, but could be potently 
powerful tools for communicating very long but uncomplicated calls. Point B 
has very few downsides, but represents introduction of a case where a human 
might understand an expression differently than a parser, while Point C 
introduces a layer of complexity to serve a use case that, for better or 
worse, could serve to push a new idiom onto the Gopher community. 

These three points present no risk to the Go 1 compatibility promise, but I 
will admit before anyone else that I haven't proven that Point C is worth 
the investment, and I expect some difficult questions about Point B.

-- 
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 

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

[Sam Hughes]

Thanks for clarifying that, @Brian. Yeah. It took a bit to warm up to that 
approach, but the github.com/jackc/pgtypes convinced me that the results 
were worth it. The benefits:  A, package interpretation methods with a 
piece of data, B, lazily valuate data when needed, and C, gain 
introspective capability specific to the type and not using reflect
On Friday, April 1, 2022 at 4:47:32 AM UTC-5 Brian Candler wrote:

> That wasn't literal code with anglebrackets - you're supposed to fill that 
> in yourself.  I think he meant something like:
>
> type fooString struct{ string }
>
> https://go.dev/play/p/4Q94xMZDciV
>
> What this is doing is *embedding* a string value into a struct; if you 
> have not come across type embedding before then Google for the details.
>
> You still cannot use one of these types transparently as a string, but you 
> can use
> x.string
> instead of
> string(x)
> to extract the value.
>
> On Friday, 1 April 2022 at 06:48:04 UTC+1 yan.z...@gmail.com wrote:
>
>> Hi Sam! Your solution does not seem to work:
>>
>> package main
>>
>> import(
>> "fmt"
>> "strconv"
>> )
>>
>> type  String struct{string}
>>
>> func (s String) print(){
>> fmt.Println(s)
>> }
>>
>> func main() {
>>var a String ="hello, world\n"
>>
>>a.print()
>>
>>fmt.Println(strconv.ParseInt("78",10, 64))
>>
>>var x String ="452"
>>
>>n, _ := strconv.ParseInt(x, 10, 64)
>> }
>>
>> 在2022年3月26日星期六 UTC+8 06:41:15 写道：
>>
>>>
>>> My workaround like is something like `type String 
>>> struct{string}. It can be reasonably treated as a string for most cases in 
>>> which as string is needed, and it lets you convert back conveniently from 
>>> any scope in which it's reasonable for your program to know the difference.
>>> On Friday, March 18, 2022 at 12:46:34 AM UTC-5 Henry wrote:
>>>
 My own preference is to have a small number of methods and put the 
 general functionalities into functions. By putting the general 
 functionalities into functions, you allow code reuse. In object-oriented 
 programming, you normally attach as many functionalities as possible to 
 their corresponding types and achieve code reuse via inheritance. Since Go 
 does not have inheritance, you can achieve a similar effect with 
 standalone 
 functions. 

 On Friday, March 18, 2022 at 11:26:51 AM UTC+7 Ian Lance Taylor wrote:

> On Thu, Mar 17, 2022 at 7:17 PM Zhaoxun Yan  
> wrote: 
> > 
> > I just came across this taboo in golang - new methods cannot be 
> added to an existing type: 
>
> Yes. If we didn't have this prohibition, then the set of interfaces 
> satisfied by a type would depend on which package was using the type. 
>
> See the discussion at https://go.dev/issue/21401. 
>
> Ian 
>


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/18613c1d-adf6-4a35-bf00-005b3df798den%40googlegroups.com.

Re: [go-nuts] Type Hints for Golang

[Jan Mercl]

On Fri, Apr 1, 2022 at 5:08 PM Amnon  wrote:

> Python has had Type Hints since 2014 (see PEP 484).

60 seconds!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X8WTaA-FSVMVDjcSHD6jUbGmUA21tfbXHnBNw5ZGKXXA%40mail.gmail.com.

[go-nuts] Type Hints for Golang

[Amnon]

Python has had Type Hints since 2014 (see PEP 484).

Isn't it time the Golang Language caught up?

I mean, it is 2022
 - or to be more precise April 1st 2022...

-- 
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/785ce28b-0bdd-46e0-adfd-94d9c8156ba4n%40googlegroups.com.

[go-nuts] Re: go mod tidy doesn't rewrite go.mod file (shows go: warning "all" matched no packages)

[vaastav...@gmail.com]

There is definitely source code in that folder. There is a main.go file as 
well as 3 other packages. 
So, go.mod should not be removing all the entries from the go.mod file.

On Friday, 1 April 2022 at 15:43:30 UTC+2 Brian Candler wrote:

> I just updated to 1.18 (from 1.17.6) - on macOS 12.3.1 - and indeed:
> - with just go.mod, I get the warning and go.mod is cleaned up
> - with go.mod plus main.go, I get no warning and go.mod is cleaned up
>
> This looks to me like a bug fix.  If there is no source code, then by 
> definition go.mod should not have any dependent modules.
>
> On Friday, 1 April 2022 at 13:30:40 UTC+1 vaastav...@gmail.com wrote:
>
>> Ok, I just tested this. I only see this behaviour with go 1.18. I tried 
>> using go mod tidy with go1.17 and it worked as expected.
>>
>> On Friday, 1 April 2022 at 14:15:14 UTC+2 vaastav...@gmail.com wrote:
>>
>>> I see this behaviour even in the presence of a main.go file in the same 
>>> directory. This is why I am baffled as to why I am seeing this warning even 
>>> if the source code is present.
>>> It was working fine until I upgraded from go1.17 to go1.18
>>>
>>> On Friday, 1 April 2022 at 11:36:04 UTC+2 Brian Candler wrote:
>>>
 Interesting.  If I put that go.mod file in an empty directory, then I 
 see the warning:

 $ go mod tidy

 go: warning: "all" matched no packages
 $ go mod tidy

 go: warning: "all" matched no packages
 > But when I run `go mod tidy`, it simply prints out the aforementioned 
 warning and the new go.mod file looks like this

 I see the same behaviour if I create a main.go file.  Then the warning 
 vanishes and the go.mod file is tidied:

 $ mv main.go.x main.go
 $ cat main.go
 package main

 func main() {
 }
 $ go mod tidy
 $ cat go.mod
 module module_name_obfuscated

 go 1.17
 $ 

 This of course is expected behaviour: it's the job of go mod tidy to 
 update the go.mod file so that it matches the source code in the module. 
 See "go help mod tidy":




 *"Tidy makes sure go.mod matches the source code in the module.It adds 
 any missing modules necessary to build the current module'spackages and 
 dependencies, and it removes unused modules thatdon't provide any relevant 
 packages."*

 So I presume the warning you see is only when go mod tidy can't find 
 any source code in the current directory.

 On Thursday, 31 March 2022 at 20:18:52 UTC+1 vaastav...@gmail.com 
 wrote:

> Here are the contents of the go.mod file
>
> ```
> module module_name_obfuscated
>
> go 1.18
>
> require (
> github.com/bradfitz/gomemcache v0.0.0-20190913173617-a41fca850d0b
> github.com/go-redis/redis/v8 v8.11.4
> github.com/go-sql-driver/mysql v1.6.0
> github.com/otiai10/copy v1.7.0
> github.com/rabbitmq/amqp091-go v1.3.0
> github.com/tracingplane/tracingplane-go 
> v0.0.0-20171025152126-8c4e6f79b148
> gitlab.mpi-sws.org/cld/tracing/tracing-framework-go 
> v0.0.0-20211206181151-6edc754a9f2a
> go.mongodb.org/mongo-driver v1.7.4
> go.opentelemetry.io/otel/exporters/jaeger v1.2.0
> go.opentelemetry.io/otel/exporters/zipkin v1.6.0
> go.opentelemetry.io/otel/sdk v1.6.0
> go.opentelemetry.io/otel/trace v1.6.0
> golang.org/x/mod v0.5.1
> )
>
> require (
> github.com/cespare/xxhash/v2 v2.1.2 // indirect
> github.com/dgryski/go-rendezvous 
> v0.0.0-20200823014737-9f7001d12a5f // indirect
> github.com/go-logr/logr v1.2.3 // indirect
> github.com/go-logr/stdr v1.2.2 // indirect
> github.com/go-stack/stack v1.8.0 // indirect
> github.com/golang/protobuf v1.5.2 // indirect
> github.com/golang/snappy v0.0.4 // indirect
> github.com/klauspost/compress v1.13.6 // indirect
> github.com/openzipkin/zipkin-go v0.4.0 // indirect
> github.com/pkg/errors v0.9.1 // indirect
> github.com/xdg-go/pbkdf2 v1.0.0 // indirect
> github.com/xdg-go/scram v1.0.2 // indirect
> github.com/xdg-go/stringprep v1.0.2 // indirect
> github.com/youmark/pkcs8 v0.0.0-20181117223130-1be2e3e5546d // 
> indirect
> go.opentelemetry.io/otel v1.6.0 // indirect
> golang.org/x/crypto v0.0.0-20210920023735-84f357641f63 // indirect
> golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9 // indirect
> golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1 // indirect
> golang.org/x/text v0.3.7 // indirect
> golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // 
> indirect
> google.golang.org/protobuf v1.27.1 // indirect
> )
> ```
>
> But when I run `go mod tidy`, it simply prints out the aforementioned 
> warning and the new go.mod file looks like this:
>
> ```
> 

[go-nuts] Re: go mod tidy doesn't rewrite go.mod file (shows go: warning "all" matched no packages)

[Brian Candler]

I just updated to 1.18 (from 1.17.6) - on macOS 12.3.1 - and indeed:
- with just go.mod, I get the warning and go.mod is cleaned up
- with go.mod plus main.go, I get no warning and go.mod is cleaned up

This looks to me like a bug fix.  If there is no source code, then by 
definition go.mod should not have any dependent modules.

On Friday, 1 April 2022 at 13:30:40 UTC+1 vaastav...@gmail.com wrote:

> Ok, I just tested this. I only see this behaviour with go 1.18. I tried 
> using go mod tidy with go1.17 and it worked as expected.
>
> On Friday, 1 April 2022 at 14:15:14 UTC+2 vaastav...@gmail.com wrote:
>
>> I see this behaviour even in the presence of a main.go file in the same 
>> directory. This is why I am baffled as to why I am seeing this warning even 
>> if the source code is present.
>> It was working fine until I upgraded from go1.17 to go1.18
>>
>> On Friday, 1 April 2022 at 11:36:04 UTC+2 Brian Candler wrote:
>>
>>> Interesting.  If I put that go.mod file in an empty directory, then I 
>>> see the warning:
>>>
>>> $ go mod tidy
>>>
>>> go: warning: "all" matched no packages
>>> $ go mod tidy
>>>
>>> go: warning: "all" matched no packages
>>> > But when I run `go mod tidy`, it simply prints out the aforementioned 
>>> warning and the new go.mod file looks like this
>>>
>>> I see the same behaviour if I create a main.go file.  Then the warning 
>>> vanishes and the go.mod file is tidied:
>>>
>>> $ mv main.go.x main.go
>>> $ cat main.go
>>> package main
>>>
>>> func main() {
>>> }
>>> $ go mod tidy
>>> $ cat go.mod
>>> module module_name_obfuscated
>>>
>>> go 1.17
>>> $ 
>>>
>>> This of course is expected behaviour: it's the job of go mod tidy to 
>>> update the go.mod file so that it matches the source code in the module. 
>>> See "go help mod tidy":
>>>
>>>
>>>
>>>
>>> *"Tidy makes sure go.mod matches the source code in the module.It adds 
>>> any missing modules necessary to build the current module'spackages and 
>>> dependencies, and it removes unused modules thatdon't provide any relevant 
>>> packages."*
>>>
>>> So I presume the warning you see is only when go mod tidy can't find any 
>>> source code in the current directory.
>>>
>>> On Thursday, 31 March 2022 at 20:18:52 UTC+1 vaastav...@gmail.com wrote:
>>>
 Here are the contents of the go.mod file

 ```
 module module_name_obfuscated

 go 1.18

 require (
 github.com/bradfitz/gomemcache v0.0.0-20190913173617-a41fca850d0b
 github.com/go-redis/redis/v8 v8.11.4
 github.com/go-sql-driver/mysql v1.6.0
 github.com/otiai10/copy v1.7.0
 github.com/rabbitmq/amqp091-go v1.3.0
 github.com/tracingplane/tracingplane-go 
 v0.0.0-20171025152126-8c4e6f79b148
 gitlab.mpi-sws.org/cld/tracing/tracing-framework-go 
 v0.0.0-20211206181151-6edc754a9f2a
 go.mongodb.org/mongo-driver v1.7.4
 go.opentelemetry.io/otel/exporters/jaeger v1.2.0
 go.opentelemetry.io/otel/exporters/zipkin v1.6.0
 go.opentelemetry.io/otel/sdk v1.6.0
 go.opentelemetry.io/otel/trace v1.6.0
 golang.org/x/mod v0.5.1
 )

 require (
 github.com/cespare/xxhash/v2 v2.1.2 // indirect
 github.com/dgryski/go-rendezvous 
 v0.0.0-20200823014737-9f7001d12a5f // indirect
 github.com/go-logr/logr v1.2.3 // indirect
 github.com/go-logr/stdr v1.2.2 // indirect
 github.com/go-stack/stack v1.8.0 // indirect
 github.com/golang/protobuf v1.5.2 // indirect
 github.com/golang/snappy v0.0.4 // indirect
 github.com/klauspost/compress v1.13.6 // indirect
 github.com/openzipkin/zipkin-go v0.4.0 // indirect
 github.com/pkg/errors v0.9.1 // indirect
 github.com/xdg-go/pbkdf2 v1.0.0 // indirect
 github.com/xdg-go/scram v1.0.2 // indirect
 github.com/xdg-go/stringprep v1.0.2 // indirect
 github.com/youmark/pkcs8 v0.0.0-20181117223130-1be2e3e5546d // 
 indirect
 go.opentelemetry.io/otel v1.6.0 // indirect
 golang.org/x/crypto v0.0.0-20210920023735-84f357641f63 // indirect
 golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9 // indirect
 golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1 // indirect
 golang.org/x/text v0.3.7 // indirect
 golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
 google.golang.org/protobuf v1.27.1 // indirect
 )
 ```

 But when I run `go mod tidy`, it simply prints out the aforementioned 
 warning and the new go.mod file looks like this:

 ```
 module module_name_obfuscated

 go 1.18
 ```
 On Thursday, 31 March 2022 at 18:30:13 UTC+2 Brian Candler wrote:

> Can you show the contents of the go.mod file in the directory where 
> you run "go mod tidy"?
>
> > I get this error when I run `go list all` as well.
>
> Try "go list" rather than "go list all" (because in that context, 

[go-nuts] Re: Is it possible to change the existing printline dynamically in golang?

[Amnon]

Yes, this is the murky world of ANSI escape codes.
Fortunately there are a whole load of libraries which do this for you...
Try https://github.com/cheggaaa/pb
or https://github.com/schollz/progressbar
or github.com/vardius/progress-go


On Friday, 1 April 2022 at 13:12:11 UTC+1 yan.z...@gmail.com wrote:

> Got it:
>
> package main
>
> import(
> "fmt"
> "time"
> )
>
> func main() {
>   fmt.Printf("Hello")
>   time.Sleep(time.Second)
>   time.Sleep(time.Second)
>   fmt.Printf("\r")
>   fmt.Printf("World\n")
> }
>
> 在2022年4月1日星期五 UTC+8 15:34:08 写道：
>
>> You can use the ansi escape code if the target terminal supports it. 
>> Alternatively, you can use the carriage return '\r' and reprint the line. 
>> Note you may need to overwrite with empty space to delete the line before 
>> rewriting it.
>>
>> On Friday, April 1, 2022 at 12:38:37 PM UTC+7 yan.z...@gmail.com wrote:
>>
>>> I just noticed how python pip upgraded from printing numerous process 
>>> bars like this:
>>> ■■■   30% completed
>>>  40% completed
>>> ■■60% completed
>>>    80% completed
>>> ■■  100% completed
>>>
>>> to a single line of a growing bar and changing declaration.
>>>
>>> It is definitely a functionality that  prompts of both Linux and Windows 
>>> allows -
>>> To change the previous print line.
>>> Is it possible to realize this in golang?
>>>
>>>   Zhaoxun
>>>
>>

-- 
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/47ad2497-6a3a-4aae-9559-5f3fd0bac808n%40googlegroups.com.

[go-nuts] Re: go mod tidy doesn't rewrite go.mod file (shows go: warning "all" matched no packages)

[vaastav...@gmail.com]

Ok, I just tested this. I only see this behaviour with go 1.18. I tried 
using go mod tidy with go1.17 and it worked as expected.

On Friday, 1 April 2022 at 14:15:14 UTC+2 vaastav...@gmail.com wrote:

> I see this behaviour even in the presence of a main.go file in the same 
> directory. This is why I am baffled as to why I am seeing this warning even 
> if the source code is present.
> It was working fine until I upgraded from go1.17 to go1.18
>
> On Friday, 1 April 2022 at 11:36:04 UTC+2 Brian Candler wrote:
>
>> Interesting.  If I put that go.mod file in an empty directory, then I see 
>> the warning:
>>
>> $ go mod tidy
>>
>> go: warning: "all" matched no packages
>> $ go mod tidy
>>
>> go: warning: "all" matched no packages
>> > But when I run `go mod tidy`, it simply prints out the aforementioned 
>> warning and the new go.mod file looks like this
>>
>> I see the same behaviour if I create a main.go file.  Then the warning 
>> vanishes and the go.mod file is tidied:
>>
>> $ mv main.go.x main.go
>> $ cat main.go
>> package main
>>
>> func main() {
>> }
>> $ go mod tidy
>> $ cat go.mod
>> module module_name_obfuscated
>>
>> go 1.17
>> $ 
>>
>> This of course is expected behaviour: it's the job of go mod tidy to 
>> update the go.mod file so that it matches the source code in the module. 
>> See "go help mod tidy":
>>
>>
>>
>>
>> *"Tidy makes sure go.mod matches the source code in the module.It adds 
>> any missing modules necessary to build the current module'spackages and 
>> dependencies, and it removes unused modules thatdon't provide any relevant 
>> packages."*
>>
>> So I presume the warning you see is only when go mod tidy can't find any 
>> source code in the current directory.
>>
>> On Thursday, 31 March 2022 at 20:18:52 UTC+1 vaastav...@gmail.com wrote:
>>
>>> Here are the contents of the go.mod file
>>>
>>> ```
>>> module module_name_obfuscated
>>>
>>> go 1.18
>>>
>>> require (
>>> github.com/bradfitz/gomemcache v0.0.0-20190913173617-a41fca850d0b
>>> github.com/go-redis/redis/v8 v8.11.4
>>> github.com/go-sql-driver/mysql v1.6.0
>>> github.com/otiai10/copy v1.7.0
>>> github.com/rabbitmq/amqp091-go v1.3.0
>>> github.com/tracingplane/tracingplane-go 
>>> v0.0.0-20171025152126-8c4e6f79b148
>>> gitlab.mpi-sws.org/cld/tracing/tracing-framework-go 
>>> v0.0.0-20211206181151-6edc754a9f2a
>>> go.mongodb.org/mongo-driver v1.7.4
>>> go.opentelemetry.io/otel/exporters/jaeger v1.2.0
>>> go.opentelemetry.io/otel/exporters/zipkin v1.6.0
>>> go.opentelemetry.io/otel/sdk v1.6.0
>>> go.opentelemetry.io/otel/trace v1.6.0
>>> golang.org/x/mod v0.5.1
>>> )
>>>
>>> require (
>>> github.com/cespare/xxhash/v2 v2.1.2 // indirect
>>> github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f 
>>> // indirect
>>> github.com/go-logr/logr v1.2.3 // indirect
>>> github.com/go-logr/stdr v1.2.2 // indirect
>>> github.com/go-stack/stack v1.8.0 // indirect
>>> github.com/golang/protobuf v1.5.2 // indirect
>>> github.com/golang/snappy v0.0.4 // indirect
>>> github.com/klauspost/compress v1.13.6 // indirect
>>> github.com/openzipkin/zipkin-go v0.4.0 // indirect
>>> github.com/pkg/errors v0.9.1 // indirect
>>> github.com/xdg-go/pbkdf2 v1.0.0 // indirect
>>> github.com/xdg-go/scram v1.0.2 // indirect
>>> github.com/xdg-go/stringprep v1.0.2 // indirect
>>> github.com/youmark/pkcs8 v0.0.0-20181117223130-1be2e3e5546d // 
>>> indirect
>>> go.opentelemetry.io/otel v1.6.0 // indirect
>>> golang.org/x/crypto v0.0.0-20210920023735-84f357641f63 // indirect
>>> golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9 // indirect
>>> golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1 // indirect
>>> golang.org/x/text v0.3.7 // indirect
>>> golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
>>> google.golang.org/protobuf v1.27.1 // indirect
>>> )
>>> ```
>>>
>>> But when I run `go mod tidy`, it simply prints out the aforementioned 
>>> warning and the new go.mod file looks like this:
>>>
>>> ```
>>> module module_name_obfuscated
>>>
>>> go 1.18
>>> ```
>>> On Thursday, 31 March 2022 at 18:30:13 UTC+2 Brian Candler wrote:
>>>
 Can you show the contents of the go.mod file in the directory where you 
 run "go mod tidy"?

 > I get this error when I run `go list all` as well.

 Try "go list" rather than "go list all" (because in that context, "all" 
 is interpreted as the name of a package)

 On Thursday, 31 March 2022 at 16:12:24 UTC+1 vaastav...@gmail.com 
 wrote:

> Hi all,
> I am encountering this problem where when I run `go mod tidy`, it 
> simply returns `go: warning: "all" matched no packages`. I get this error 
> when I run `go list all` as well. 
> I was hoping someone could help me as to why this is happening since I 
> haven't been able to find an explanation for this.
>
> Kind Regards
> Vaastav

[go-nuts] Re: go mod tidy doesn't rewrite go.mod file (shows go: warning "all" matched no packages)

[vaastav...@gmail.com]

I see this behaviour even in the presence of a main.go file in the same 
directory. This is why I am baffled as to why I am seeing this warning even 
if the source code is present.
It was working fine until I upgraded from go1.17 to go1.18

On Friday, 1 April 2022 at 11:36:04 UTC+2 Brian Candler wrote:

> Interesting.  If I put that go.mod file in an empty directory, then I see 
> the warning:
>
> $ go mod tidy
>
> go: warning: "all" matched no packages
> $ go mod tidy
>
> go: warning: "all" matched no packages
> > But when I run `go mod tidy`, it simply prints out the aforementioned 
> warning and the new go.mod file looks like this
>
> I see the same behaviour if I create a main.go file.  Then the warning 
> vanishes and the go.mod file is tidied:
>
> $ mv main.go.x main.go
> $ cat main.go
> package main
>
> func main() {
> }
> $ go mod tidy
> $ cat go.mod
> module module_name_obfuscated
>
> go 1.17
> $ 
>
> This of course is expected behaviour: it's the job of go mod tidy to 
> update the go.mod file so that it matches the source code in the module. 
> See "go help mod tidy":
>
>
>
>
> *"Tidy makes sure go.mod matches the source code in the module.It adds any 
> missing modules necessary to build the current module'spackages and 
> dependencies, and it removes unused modules thatdon't provide any relevant 
> packages."*
>
> So I presume the warning you see is only when go mod tidy can't find any 
> source code in the current directory.
>
> On Thursday, 31 March 2022 at 20:18:52 UTC+1 vaastav...@gmail.com wrote:
>
>> Here are the contents of the go.mod file
>>
>> ```
>> module module_name_obfuscated
>>
>> go 1.18
>>
>> require (
>> github.com/bradfitz/gomemcache v0.0.0-20190913173617-a41fca850d0b
>> github.com/go-redis/redis/v8 v8.11.4
>> github.com/go-sql-driver/mysql v1.6.0
>> github.com/otiai10/copy v1.7.0
>> github.com/rabbitmq/amqp091-go v1.3.0
>> github.com/tracingplane/tracingplane-go 
>> v0.0.0-20171025152126-8c4e6f79b148
>> gitlab.mpi-sws.org/cld/tracing/tracing-framework-go 
>> v0.0.0-20211206181151-6edc754a9f2a
>> go.mongodb.org/mongo-driver v1.7.4
>> go.opentelemetry.io/otel/exporters/jaeger v1.2.0
>> go.opentelemetry.io/otel/exporters/zipkin v1.6.0
>> go.opentelemetry.io/otel/sdk v1.6.0
>> go.opentelemetry.io/otel/trace v1.6.0
>> golang.org/x/mod v0.5.1
>> )
>>
>> require (
>> github.com/cespare/xxhash/v2 v2.1.2 // indirect
>> github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f 
>> // indirect
>> github.com/go-logr/logr v1.2.3 // indirect
>> github.com/go-logr/stdr v1.2.2 // indirect
>> github.com/go-stack/stack v1.8.0 // indirect
>> github.com/golang/protobuf v1.5.2 // indirect
>> github.com/golang/snappy v0.0.4 // indirect
>> github.com/klauspost/compress v1.13.6 // indirect
>> github.com/openzipkin/zipkin-go v0.4.0 // indirect
>> github.com/pkg/errors v0.9.1 // indirect
>> github.com/xdg-go/pbkdf2 v1.0.0 // indirect
>> github.com/xdg-go/scram v1.0.2 // indirect
>> github.com/xdg-go/stringprep v1.0.2 // indirect
>> github.com/youmark/pkcs8 v0.0.0-20181117223130-1be2e3e5546d // 
>> indirect
>> go.opentelemetry.io/otel v1.6.0 // indirect
>> golang.org/x/crypto v0.0.0-20210920023735-84f357641f63 // indirect
>> golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9 // indirect
>> golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1 // indirect
>> golang.org/x/text v0.3.7 // indirect
>> golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
>> google.golang.org/protobuf v1.27.1 // indirect
>> )
>> ```
>>
>> But when I run `go mod tidy`, it simply prints out the aforementioned 
>> warning and the new go.mod file looks like this:
>>
>> ```
>> module module_name_obfuscated
>>
>> go 1.18
>> ```
>> On Thursday, 31 March 2022 at 18:30:13 UTC+2 Brian Candler wrote:
>>
>>> Can you show the contents of the go.mod file in the directory where you 
>>> run "go mod tidy"?
>>>
>>> > I get this error when I run `go list all` as well.
>>>
>>> Try "go list" rather than "go list all" (because in that context, "all" 
>>> is interpreted as the name of a package)
>>>
>>> On Thursday, 31 March 2022 at 16:12:24 UTC+1 vaastav...@gmail.com wrote:
>>>
 Hi all,
 I am encountering this problem where when I run `go mod tidy`, it 
 simply returns `go: warning: "all" matched no packages`. I get this error 
 when I run `go list all` as well. 
 I was hoping someone could help me as to why this is happening since I 
 haven't been able to find an explanation for this.

 Kind Regards
 Vaastav

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

[go-nuts] Re: Is it possible to change the existing printline dynamically in golang?

[Zhaoxun Yan]

Got it:

package main

import(
"fmt"
"time"
)

func main() {
  fmt.Printf("Hello")
  time.Sleep(time.Second)
  time.Sleep(time.Second)
  fmt.Printf("\r")
  fmt.Printf("World\n")
}

在2022年4月1日星期五 UTC+8 15:34:08 写道：

> You can use the ansi escape code if the target terminal supports it. 
> Alternatively, you can use the carriage return '\r' and reprint the line. 
> Note you may need to overwrite with empty space to delete the line before 
> rewriting it.
>
> On Friday, April 1, 2022 at 12:38:37 PM UTC+7 yan.z...@gmail.com wrote:
>
>> I just noticed how python pip upgraded from printing numerous process 
>> bars like this:
>> ■■■   30% completed
>>  40% completed
>> ■■60% completed
>>    80% completed
>> ■■  100% completed
>>
>> to a single line of a growing bar and changing declaration.
>>
>> It is definitely a functionality that  prompts of both Linux and Windows 
>> allows -
>> To change the previous print line.
>> Is it possible to realize this in golang?
>>
>>   Zhaoxun
>>
>

-- 
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/702dad6d-006f-47b5-94d5-ca231b0245fcn%40googlegroups.com.

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

[Brian Candler]

That wasn't literal code with anglebrackets - you're supposed to fill that 
in yourself.  I think he meant something like:

type fooString struct{ string }

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

What this is doing is *embedding* a string value into a struct; if you have 
not come across type embedding before then Google for the details.

You still cannot use one of these types transparently as a string, but you 
can use
x.string
instead of
string(x)
to extract the value.

On Friday, 1 April 2022 at 06:48:04 UTC+1 yan.z...@gmail.com wrote:

> Hi Sam! Your solution does not seem to work:
>
> package main
>
> import(
> "fmt"
> "strconv"
> )
>
> type  String struct{string}
>
> func (s String) print(){
> fmt.Println(s)
> }
>
> func main() {
>var a String ="hello, world\n"
>
>a.print()
>
>fmt.Println(strconv.ParseInt("78",10, 64))
>
>var x String ="452"
>
>n, _ := strconv.ParseInt(x, 10, 64)
> }
>
> 在2022年3月26日星期六 UTC+8 06:41:15 写道：
>
>>
>> My workaround like is something like `type String 
>> struct{string}. It can be reasonably treated as a string for most cases in 
>> which as string is needed, and it lets you convert back conveniently from 
>> any scope in which it's reasonable for your program to know the difference.
>> On Friday, March 18, 2022 at 12:46:34 AM UTC-5 Henry wrote:
>>
>>> My own preference is to have a small number of methods and put the 
>>> general functionalities into functions. By putting the general 
>>> functionalities into functions, you allow code reuse. In object-oriented 
>>> programming, you normally attach as many functionalities as possible to 
>>> their corresponding types and achieve code reuse via inheritance. Since Go 
>>> does not have inheritance, you can achieve a similar effect with standalone 
>>> functions. 
>>>
>>> On Friday, March 18, 2022 at 11:26:51 AM UTC+7 Ian Lance Taylor wrote:
>>>
 On Thu, Mar 17, 2022 at 7:17 PM Zhaoxun Yan  
 wrote: 
 > 
 > I just came across this taboo in golang - new methods cannot be added 
 to an existing type: 

 Yes. If we didn't have this prohibition, then the set of interfaces 
 satisfied by a type would depend on which package was using the type. 

 See the discussion at https://go.dev/issue/21401. 

 Ian 

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f5ce43c5-f120-47b2-8955-7005432416ban%40googlegroups.com.

[go-nuts] Re: go mod tidy doesn't rewrite go.mod file (shows go: warning "all" matched no packages)

[Brian Candler]

Interesting.  If I put that go.mod file in an empty directory, then I see 
the warning:

$ go mod tidy
go: warning: "all" matched no packages
$ go mod tidy
go: warning: "all" matched no packages

> But when I run `go mod tidy`, it simply prints out the aforementioned 
warning and the new go.mod file looks like this

I see the same behaviour if I create a main.go file.  Then the warning 
vanishes and the go.mod file is tidied:

$ mv main.go.x main.go
$ cat main.go
package main

func main() {
}
$ go mod tidy
$ cat go.mod
module module_name_obfuscated

go 1.17
$ 

This of course is expected behaviour: it's the job of go mod tidy to update 
the go.mod file so that it matches the source code in the module. See "go 
help mod tidy":




*"Tidy makes sure go.mod matches the source code in the module.It adds any 
missing modules necessary to build the current module'spackages and 
dependencies, and it removes unused modules thatdon't provide any relevant 
packages."*

So I presume the warning you see is only when go mod tidy can't find any 
source code in the current directory.

On Thursday, 31 March 2022 at 20:18:52 UTC+1 vaastav...@gmail.com wrote:

> Here are the contents of the go.mod file
>
> ```
> module module_name_obfuscated
>
> go 1.18
>
> require (
> github.com/bradfitz/gomemcache v0.0.0-20190913173617-a41fca850d0b
> github.com/go-redis/redis/v8 v8.11.4
> github.com/go-sql-driver/mysql v1.6.0
> github.com/otiai10/copy v1.7.0
> github.com/rabbitmq/amqp091-go v1.3.0
> github.com/tracingplane/tracingplane-go 
> v0.0.0-20171025152126-8c4e6f79b148
> gitlab.mpi-sws.org/cld/tracing/tracing-framework-go 
> v0.0.0-20211206181151-6edc754a9f2a
> go.mongodb.org/mongo-driver v1.7.4
> go.opentelemetry.io/otel/exporters/jaeger v1.2.0
> go.opentelemetry.io/otel/exporters/zipkin v1.6.0
> go.opentelemetry.io/otel/sdk v1.6.0
> go.opentelemetry.io/otel/trace v1.6.0
> golang.org/x/mod v0.5.1
> )
>
> require (
> github.com/cespare/xxhash/v2 v2.1.2 // indirect
> github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f 
> // indirect
> github.com/go-logr/logr v1.2.3 // indirect
> github.com/go-logr/stdr v1.2.2 // indirect
> github.com/go-stack/stack v1.8.0 // indirect
> github.com/golang/protobuf v1.5.2 // indirect
> github.com/golang/snappy v0.0.4 // indirect
> github.com/klauspost/compress v1.13.6 // indirect
> github.com/openzipkin/zipkin-go v0.4.0 // indirect
> github.com/pkg/errors v0.9.1 // indirect
> github.com/xdg-go/pbkdf2 v1.0.0 // indirect
> github.com/xdg-go/scram v1.0.2 // indirect
> github.com/xdg-go/stringprep v1.0.2 // indirect
> github.com/youmark/pkcs8 v0.0.0-20181117223130-1be2e3e5546d // 
> indirect
> go.opentelemetry.io/otel v1.6.0 // indirect
> golang.org/x/crypto v0.0.0-20210920023735-84f357641f63 // indirect
> golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9 // indirect
> golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1 // indirect
> golang.org/x/text v0.3.7 // indirect
> golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
> google.golang.org/protobuf v1.27.1 // indirect
> )
> ```
>
> But when I run `go mod tidy`, it simply prints out the aforementioned 
> warning and the new go.mod file looks like this:
>
> ```
> module module_name_obfuscated
>
> go 1.18
> ```
> On Thursday, 31 March 2022 at 18:30:13 UTC+2 Brian Candler wrote:
>
>> Can you show the contents of the go.mod file in the directory where you 
>> run "go mod tidy"?
>>
>> > I get this error when I run `go list all` as well.
>>
>> Try "go list" rather than "go list all" (because in that context, "all" 
>> is interpreted as the name of a package)
>>
>> On Thursday, 31 March 2022 at 16:12:24 UTC+1 vaastav...@gmail.com wrote:
>>
>>> Hi all,
>>> I am encountering this problem where when I run `go mod tidy`, it simply 
>>> returns `go: warning: "all" matched no packages`. I get this error when I 
>>> run `go list all` as well. 
>>> I was hoping someone could help me as to why this is happening since I 
>>> haven't been able to find an explanation for this.
>>>
>>> Kind Regards
>>> Vaastav
>>>
>>

-- 
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/67b7ff8d-a19f-44fb-b846-7b0bc10f1726n%40googlegroups.com.

[go-nuts] Re: Is it possible to change the existing printline dynamically in golang?

[Henry]

You can use the ansi escape code if the target terminal supports it. 
Alternatively, you can use the carriage return '\r' and reprint the line. 
Note you may need to overwrite with empty space to delete the line before 
rewriting it.

On Friday, April 1, 2022 at 12:38:37 PM UTC+7 yan.z...@gmail.com wrote:

> I just noticed how python pip upgraded from printing numerous process bars 
> like this:
> ■■■   30% completed
>  40% completed
> ■■60% completed
>    80% completed
> ■■  100% completed
>
> to a single line of a growing bar and changing declaration.
>
> It is definitely a functionality that  prompts of both Linux and Windows 
> allows -
> To change the previous print line.
> Is it possible to realize this in golang?
>
>   Zhaoxun
>

-- 
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/80dd0cbc-7bbb-4453-8e23-e8dc6f37bb4bn%40googlegroups.com.