On Wed, Feb 9, 2022 at 3:37 PM E Z wrote:
>
> I noticed a phenomenon while maintaining my golang application, the local
> timezone of the application always keep the value when it starts, the local
> timezone will not change even though I change the system timezone. It looks
> like the golang t
On Wed, 9 Feb 2022 at 23:36, E Z wrote:
> I noticed a phenomenon while maintaining my golang application, the local
> timezone of the application always keep the value when it starts, the local
> timezone will not change even though I change the system timezone. It looks
> like the golang time pa
I noticed a phenomenon while maintaining my golang application, the local
timezone of the application always keep the value when it starts, the local
timezone will not change even though I change the system timezone. It looks
like the golang time package has been caching the current timezone.
I
On Wed, Feb 9, 2022 at 9:23 AM Andy wrote:
> The DeepEqual function has the same judgment as the deepValueEqual
> function
>
> [image: 2022-02-09_232909.png]
>
Please send code as plain text, not as an image. Please text is much
easier to read. Thanks.
It's true that the test appears in both
OK, I checked in another CL to resolve this new issue. Give it a try again
please and let me know if you are able to build.
Thanks, Than
On Wed, Feb 9, 2022 at 2:35 PM Than McIntosh wrote:
> Thanks for the report. I'll take a look...
>
> Than
>
> On Wed, Feb 9, 2022 at 2:33 PM Zhen Huang
> wr
Thanks for the report. I'll take a look...
Than
On Wed, Feb 9, 2022 at 2:33 PM Zhen Huang wrote:
> Thank you for the prompt response! I checked out the updated code and the
> previous compilation error is gone. However, another compilation error came
> up:
>
> [183/1626] Building CXX object
> t
Thank you for the prompt response! I checked out the updated code and the
previous compilation error is gone. However, another compilation error came
up:
[183/1626] Building CXX object
tools/g...LVMCppGoPasses.dir/GoStatepoints.cpp.o
FAILED:
tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoSta
The DeepEqual function has the same judgment as the deepValueEqual
function
[image: 2022-02-09_232909.png]
--
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 gol
While I do agree that the race should be fixed (as I mentioned), I would
like to point out that with
https://github.com/golang/go/issues/50859
the program posted by OP would have a well-defined, correct outcome.
Specifically, the intent of that proposal is:
Reads and writes of values larger than a
I tried to reproduce the problem and indeed `go mod tidy` seems to ignore
the go.work file.
This seems to be a bug; a opened the issue #51106.
Manlio
On Wednesday, February 9, 2022 at 3:49:48 PM UTC+1 nikhil...@gmail.com
wrote:
> I did place them in go.work file only.
> I commented the packa
Since we are on the topic, may be interesting to someone:
https://dfava.github.io/papers/fava2020finding.pdf
https://dfava.github.io/thesis/dfava_thesis.pdf
I’m not so sure I agree with you saying “ whatever the current implementation
behavior is”
Daniel
> On Feb 9, 2022, at 3:45 PM, Robert E
I did place them in go.work file only.
I commented the package in go.mod file.
On Wed, Feb 9, 2022 at 7:07 PM Manlio Perillo
wrote:
> The `use` directive must be added in the go.work file, not in the go.mod
> file.
> Also, you can use `go work use` command, instead of manually editing the
> go.
See issue 5045
> On Feb 9, 2022, at 8:42 AM, Robert Engels wrote:
>
>
> The problem with this reasoning is that Go still does not have an explicit
> memory model with respect to happens before relationships - falling back on
> “whatever the current implementation behavior is”. This makes it
The problem with this reasoning is that Go still does not have an explicit
memory model with respect to happens before relationships - falling back on
“whatever the current implementation behavior is”. This makes it more likely
that any change in the compiler will need to continue to support the
Pelen Li,
Boehm covers your specific case: "there is no reason to believe that a
currently working program with “benign races” will continue to work when it
is recompiled. Perhaps most surprisingly, this includes even the case of
potentially concurrent writes of the same value by different threads
Pelen Li,
Always fix your data races. You should consider the results of data races
as undefined.
Dmitry Vyukov, who implemented the Go race detector, once wrote an
interesting article with the title: "Benign data races: what could possibly
go wrong?"
https://twitter.com/dvyukov/status/28885
On Tue, 8 Feb 2022 at 20:55, Manlio Perillo wrote:
> Note that a single repository can have multiple modules, so you can make
> cmd/golua-repls a separate module, adding github.com/arnodel/golua as a
> dependency.
> See https://go.dev/ref/mod#vcs-version.
That is good to know! My question was
The `use` directive must be added in the go.work file, not in the go.mod
file.
Also, you can use `go work use` command, instead of manually editing the
go.work file.
Manlio
On Wednesday, February 9, 2022 at 1:00:02 PM UTC+1 nikhil...@gmail.com
wrote:
> I updated the project.
> ran go work in
You can use taskset when starting the Go program to set the cpu affinity.
> On Feb 9, 2022, at 12:56 AM, Fadhil Kurnia wrote:
>
> Hi all,
>
> I am doing some latency measurement of a subprocess in Go. However I found
> that Go program is unstable, especially when there is delay/gap between
Agreed. Depending on your application, maybe using sync.Map would be a
drop-in replacement, especially if this is a sparse set.
On Wednesday, 9 February 2022 at 08:35:09 UTC axel.wa...@googlemail.com
wrote:
> I would fix it.
>
> One particular reason to do so is that, even if it works fine, it
I updated the project.
ran go work init cmd
then added
use ../go-bitswap
replace github.com/ipfs/go-bitswap v0.5.1 => ../go-bitswap`
and comment in my go.mod file.
But when I run go mod tidy it comes back in the go.mod file.
using go 1.18v
workspace : D:\test\workspace
hierarchy : workspace\src\
Renamed to Kita: https://github.com/zhuah/kita
On Wednesday, February 9, 2022 at 1:55:13 PM UTC+8 zhuah wrote:
> I'm sorry if the name confused you, the project is still under active
> development, it will have a new name when it get to be open sourced.
>
> On Wednesday, February 9, 2022 at 11:1
On Wednesday, February 9, 2022 at 9:42:49 AM UTC+1 nikhil...@gmail.com
wrote:
> I was trying to init the work file as instructed, but I have a package
>>> which still doesn't work in 1.18
>>>
>>> [image: image.png]
>>> So, is there any other alternative?
>>>
>>> Thank you
>>> Susarla Nikhilesh
>
> I was trying to init the work file as instructed, but I have a package
>> which still doesn't work in 1.18
>>
>> [image: image.png]
>> So, is there any other alternative?
>>
>> Thank you
>> Susarla Nikhilesh
>>
>
--
You received this message because you are subscribed to the Google Groups
"g
I would fix it.
One particular reason to do so is that, even if it works fine, it adds
noise to the race detector. If someone uses your package and they test
*their* code using the race detector, they will get spurious race detector
messages. The same goes, of course, for your own tests as well. I
I want to set a value with the index of the slice. I don't really care if
there are multiple goroutines cover the value with each other, because the
value is same.
Can i just ignore this DataRace Warning? I don't know if this will cause
panic.
*Here's my example:*
I defined a structure with sl
26 matches
Mail list logo
