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 r
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 waitStartTi
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:
> h
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
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) e
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 calle
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,
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
introspectiv
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 g
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 st
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 -
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
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 w
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 w
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 wr
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.
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
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 fil
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
19 matches
Mail list logo
