Thank you all for the discussion, it was very helpful!
在2024年12月31日星期二 UTC+8 10:10:12 写道：
> On Tuesday, December 31, 2024 at 9:42:50 AM UTC+8 tapi...@gmail.com wrote:
>
> On Monday, December 30, 2024 at 6:12:10 AM UTC+8 Axel Wagner wrote:
>
> Why don't I use the sequence versions more frequently?
Since the x/exp/maps era, I have used maps.Keys and maps.Values
extensively. They are very useful and avoid users from doing loop
iterations.
I remember that they were added to the standard library, but I used
maps.Keys in the latest go version and was surprised that it could not
compile.
test.go -run=! -bench=. -benchmem
> BenchmarkTest1-12 1738662465.79 ns/op 192 B/op 1 allocs/op
> BenchmarkTest2-12 1860346362.30 ns/op 192 B/op 1 allocs/op
> BenchmarkTest3-12 2374163457.76 ns/op 160 B/op 1 allocs/op
> BenchmarkTest4-12 10 1.157 ns/
Why does BenchmarkTest3 in go 1.22 still have memory allocation? My local
test doesn’t have it
--
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+unsubs
Thank you so much!
在2023年11月28日星期二 UTC+8 15:08:30 写道：
> See https://github.com/golang/go/issues/2205
> The tip compiler is able to detect some simple string->[]byte cases in
> which duplication is not needed.
>
> On Monday, November 27, 2023 at 8:12:54 PM UTC+8 fliter wrote:
Thanks！
在2023年11月27日星期一 UTC+8 22:36:56 写道：
> Ah, and one more:
>
> On Monday, 27 November 2023 at 13:12:54 UTC+1 fliter wrote:
>
> BenchmarkTest1-83572733433.51 ns/op 192
> B/op 1 allocs/op
> BenchmarkTest2-8147172425
It seems that go 1.22 has optimized the implementation of string to byte
slicing and no longer requires memory allocation.
But why not optimize byte slicing to string conversion together?
```go
package main
import (
"reflect"
"testing"
"unsafe"
)
func BenchmarkString(b *testing.B) {
byteSli
ime | sed -e 's/.*: //' | sed -e 's/
> /,/g'`
>
> From inside the program it should be fairly easy too…
>
> HTH,
> gt
>
> Il giorno 20 nov 2023, alle ore 12:50, fliter ha
> scritto:
>
> On the arm64 architecture m1, go1.21.4.darwin-amd64.pkg
Thanks. It does seem to be related to Rosetta
在2023年11月20日星期一 UTC+8 20:22:31 写道：
> This is Rosetta 2. It is not Go, it is MacOS.
>
> -Bruno
>
> On Mon, Nov 20, 2023, 6:51 AM fliter wrote:
>
>> On the arm64 architecture m1, go1.21.4.darwin-amd64.pkg can be
>>
On the arm64 architecture m1, go1.21.4.darwin-amd64.pkg can be successfully
installed, and it seems to run normallyI am very shocked.
Is this because of any adaptations made by Go? Going one step further, is
it possible to not distinguish the CPU architecture during future
installations and
Because cgo is used, setting CGO_ENABLED=0 will cause problems, and may not
compile successfully
在2023年8月11日星期五 UTC+8 16:11:53 写道：
> Did you try:
>
> export CGO_ENABLED=0
> go build
>
> ?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
T
pls don't judge my Dockerfile skills, it's a learning experience ;) )
>
> On Thursday, 10 August 2023 at 11:12:23 UTC+1 fliter wrote:
>
>> I have a project that uses CGO. After compiling on an ubuntu 20.04
>> compilation machine, it is distributed to other machines for
I have a project that uses CGO. After compiling on an ubuntu 20.04
compilation machine, it is distributed to other machines for execution, but
many of these machines have very low ubuntu versions, which may be ubuntu
16.04 or ubuntu 18.04.
In this way, when executing the binary file, an error s
Thanks everyone！
在2023年6月14日星期三 UTC+8 20:03:46 写道：
> a2800276 schrieb am Di. 13. Juni 2023 um 11:59:
>
>> 180 degrees in respect to what? ;)
>>
>
> In respect to a flame. ;-)
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscrib
Why is the reason that the flame graph in go pprof rotated 180 degrees?
The reason I can think of is that it seems that this conforms to the func
calling order from top to bottom.
Thanks for anyone's discussion and replies
--
You received this message because you are subscribed to the Google
I didn't realize that it was already implicitly sorted by time. Thanks for
answering
在2023年6月6日星期二 UTC+8 00:27:51 写道：
> On Mon, Jun 5, 2023 at 5:08 AM fliter wrote:
> >
> > Thanks for your answer. But I wonder if the elements behind the queue
> may wait for a very long
AM fliter wrote:
> >
> >
> > In sync/mutex.go, there is a comment like the following:
> >
> > ```go
> > // Mutex fairness.
> > //
> > // Mutex can be in 2 modes of operations: normal and starvation.
> > // In normal mode waiters are queued in
In sync/mutex.go, there is a comment like the following:
```go
// Mutex fairness.
//
// Mutex can be in 2 modes of operations: normal and starvation.
// In normal mode waiters are queued in FIFO order, but a woken up waiter
// does not own the mutex and competes with new arriving goroutines over
Thank you for your perfect answer
在2023年6月2日星期五 UTC+8 23:47:14 写道：
> On Fri, Jun 2, 2023 at 4:59 AM fliter wrote:
> >
> > Map and slice are also concurrency-unsafe data structures. Why is map
> designed to throw a fatal that cannot be recovered when there is a
> conc
al allocated memory.
>
> The race detector is helpful to identify any unsafe concurrent operations,
> to variables of any type.
>
> On Friday, 2 June 2023 at 12:59:07 UTC+1 fliter wrote:
>
>> Map and slice are also concurrency-unsafe data structures. Why is map
>&
Map and slice are also concurrency-unsafe data structures. Why is map
designed to throw a fatal that cannot be recovered when there is a
concurrency conflict, but slice does not have any prompt? Are there any
design considerations?
Thanks！
--
You received this message because you are subscrib
Thanks
在2023年4月5日星期三 UTC+8 03:38:21 写道：
> On Tue, Apr 4, 2023 at 12:05 PM fliter wrote:
> >
> > There are many private methods with identical code in several different
> packages, which is clearly not elegant; But adding a public method that can
> be accessed by other
4#internalpackages
> 2 -
> https://dave.cheney.net/2019/10/06/use-internal-packages-to-reduce-your-public-api-surface
> 3 - https://github.com/golang/go/tree/master/src/internal
> On Tuesday, April 4, 2023 at 3:05:38 PM UTC-4 fliter wrote:
>
>> There are many private methods with ide
There are many private methods with identical code in several different
packages, which is clearly not elegant; But adding a public method that can
be accessed by other packages (a proposal needs to be made) does not seem
very necessary. Is there a better solution?
--
You received this message
as you live in a 12h clock
> country, at least. So "3:04 PM".
>
> On Fri, Sep 23, 2022 at 11:22 AM fliter wrote:
>
>> Is it because it is time to go to the kitchen to cook? It seems that 3:04
>> PM is too early
>>
>> --
>> You received this mes
Thanks for your answer
在2022年9月23日星期五 UTC+8 17:30:12 写道：
> Hi!
>
> On Fri, 23 Sep 2022, fliter wrote:
> > Is it because it is time to go to the kitchen to cook? It seems that
> 3:04
> > PM is too early
>
> My best guess: it's the most common way kitchen ti
Is it because it is time to go to the kitchen to cook? It seems that 3:04
PM is too early
--
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...
I need to add comments to json, but now json version does not support it
--
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.
28 matches
Mail list logo
