Re: [go-nuts] Is it weird?

If T{} is like 42, why “({})" is legal? -- 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. For more options, visit

[go-nuts] Is it weird?

package main type T struct{} func (t *T) f() {} func main() { t := T{} ().f() // ok t.f() // ok ({}).f() // ok T{}.f() // cannot call pointer method on T literal // cannot take the address of T literal } -- You received this

[go-nuts] const values of any types can't be compared to interface{} values?

ex: package main > > func main() { > // error: illegal constant expression: *int == interface {} > _ = (*int)(nil) == interface{}(nil) > } > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Is it weird?

Then why T{...} can't be a syntactic sugar for tmp := T{...} tmp and tmp is an okay receiver. :P -- 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

[go-nuts] Will the real value allocated on heap copied when assigning an interface value to another?

By reading Ross Cox's article: http://research.swtch.com/interfaces I got an interface value is represented by a struct as the following: > type interfaceStruct struct { > value *_value > inter *struct { > typ _type > mhdr []imethod > } > } > where value is

[go-nuts] Why does Golang disallow compare two interface values if their interface types are not in the superset/subset relation?

Is it essential? -- 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. For more options, visit

Re: [go-nuts] Is it weird?

It doesn't work. The receiver should be a pointer in function definition. https://play.golang.org/p/fQbbeDhB9O -- 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

Re: [go-nuts] Is it weird?

@Matt Harden, the recursive reason listens quite reasonable. @all, thanks for paticipating this discussion. -- 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

[go-nuts] Re: Will compiler do optimization here?

but I can't make sure. > > > On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote: >> >> >> I know a string value can be used as []byte if the first parameter if the >> builtin copy/append function is a []byte value: >> >>> var bs []byte = make([]byte, 1

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

ssibly safe you, is writing the actual loop and > in general go doesn't really do this kind of tradeoff (saving small amounts > of trivial work by complicating the language and -implementation). > so the copy buitlin function is not essential? > > On Wed, Aug 3, 2016 at

[go-nuts] Will compiler do optimization here?

I know a string value can be used as []byte if the first parameter if the builtin copy/append function is a []byte value: > var bs []byte = make([]byte, 10) > copy(bs, "abcde") but if do explicit conversion anyway on the second string value > var bs []byte = make([]byte, 10) > copy(bs,

[go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

Often, I need converting a []T to []interface{} to use the []interface as a variable length parameter. But converting a []T for []interface{} in a for loop is neither clean nor efficient. So is there a function in standard lib to convert []T to a []interface{}? -- You received this message

[go-nuts] Why doesn't std lib use the method in this article to make err variables constant?

http://dave.cheney.net/2016/04/07/constant-errors -- 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. For more options,

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

On Thursday, August 4, 2016 at 12:16:37 AM UTC+8, Ian Lance Taylor wrote: > > On Wed, Aug 3, 2016 at 9:12 AM, T L <tapi...@gmail.com > > wrote: > > > > On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote: > >> > >> True, but it w

[go-nuts] Re: Will compiler do optimization here?

I surely will use the first version in practice. I just want to make things clear, :) On Thursday, August 4, 2016 at 3:23:11 AM UTC+8, Hotei wrote: > > If you create the source as a byte array by converting it ([]byte("abcde") > then the compiler can NOT optimize it away. However - I don't

[go-nuts] Re: Will compiler do optimization here?

> On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote: >> >> >> I know a string value can be used as []byte if the first parameter if the >> builtin copy/append function is a []byte value: >> >>> var bs []byte = make([]byte, 10) >>> copy(bs,

[go-nuts] Re: why treat int and []int differently here?

@all, thanks for the explanation! Golang is a simple language full of details. On Sunday, July 17, 2016 at 4:15:12 AM UTC+8, T L wrote: > > > package main >> >> func fi(i int) {} >> func fis(is []int) {} >> >> type TI int >> type TIS []int >

[go-nuts] Re: Strange results from append

On Saturday, July 16, 2016 at 1:28:32 AM UTC+8, Evan Digby wrote: > > I can't reproduce this in go playground (yet), but under what > circumstances would/could/should: > > nss := []namespace.Namespace{ > append(ns, g2message.NamespaceWin...), > append(ns, g2message.NamespaceSpend...), > } > >

[go-nuts] why treat int and []int differently here?

> package main > > func fi(i int) {} > func fis(is []int) {} > > type TI int > type TIS []int > > func main() { > var ti TI > fi(ti) // cannot use ti (type TI) as type int in argument to fi > > var tis TIS > fis(tis) // no problems! > } > > -- You received this message

[go-nuts] I just read an article. In my understanding, it states single word reads/writes in go are atomic, is it right?

http://research.swtch.com/gorace > ... > The race is fundamentally caused by being able to observe partial updates > to Go's multiword values (slices, interfaces, and strings): the updates are > not atomic. > > The fix is to make the updates atomic. In Go, the easiest way to do that > is

Re: [go-nuts] I just read an article. In my understanding, it states single word reads/writes in go are atomic, is it right?

t;https://godoc.org/sync/atomic> (and I don't understand why questions > about which accesses are atomic keep coming up on golang-nuts and /r/golang > and the like, when there exists a method that *gives* you atomic accesses > in the best way possible for any given architecture). > >

[go-nuts] Why can't interface value be constant?

For an interface value, its internal values will never change. Are there any problems if golang supports constant interface values? -- 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,

Re: [go-nuts] Re: Why doesn't std lib use the method in this article to make err variables constant?

On Friday, August 5, 2016 at 2:21:53 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Aug 4, 2016 at 11:19 AM, Manlio Perillo > wrote: > > Il giorno giovedì 4 agosto 2016 17:54:33 UTC+2, Dave Cheney ha scritto: > >> > >> Fwiw, io.EOf can be converted to a constant, all

Re: [go-nuts] Re: Why doesn't std lib use the method in this article to make err variables constant?

On Thursday, August 4, 2016 at 11:54:33 PM UTC+8, Dave Cheney wrote: > > Fwiw, io.EOf can be converted to a constant, all the tests pass. But that > would change the type of an exported symbol, so it's not possible. sorry, I still don't get it. The type of io.EOF is error. After changing it

Re: [go-nuts] Why can't interface value be constant?

Is it possible to make an interface constant if its concrete value type is bool/number/string? On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor wrote: > > On Fri, Aug 5, 2016 at 11:21 AM, T L <tapi...@gmail.com > > wrote: > > > > For an interface

Re: [go-nuts] Why can't interface value be constant?

d lib become constant. > > > > On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote: >> >> Is it possible to make an interface constant if its concrete value type >> is bool/number/string? >> >> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor wrote:

Re: [go-nuts] Why can't interface value be constant?

On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote: > > It is not possible. Constants only exist at compile time. yes, but why constant interface values can't exist at compile time? -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] Why can't interface value be constant?

On Saturday, August 6, 2016 at 6:04:00 PM UTC+8, atd...@gmail.com wrote: > > > > On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote: >> >> >> >> On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote: >>> >>>

Re: [go-nuts] Why can't interface value be constant?

piler thinks it is constant, then it is constant. > > On Saturday, 6 August 2016 19:14:26 UTC+10, T L wrote: >> >> >> >> On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote: >>> >>> It is not possible. Constants only exist at compile

Re: [go-nuts] Why can't interface value be constant?

> On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote: >> >> Is it possible to make an interface constant if its concrete value type >> is bool/number/string? >> >> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor wrot

Re: [go-nuts] Why can't interface value be constant?

ecial case, what would you use it for? sync.Pools > ? > > If it's just for error variables to be constants, maybe it is not worth > it. What problem does it solve ? > for safety. > > On Saturday, August 6, 2016 at 11:11:24 AM UTC+2, T L wrote: >> >> >> >&

[go-nuts] Re: Is there a standard lib function which will return the count of characters in a string?

ial one) that says character != rune. And it provides an example, character é is made up of two runes, three bytes. > > On Saturday, July 23, 2016 at 7:52:29 AM UTC-7, T L wrote: >> >> len(str) will get the count of bytes. >> >> utf8.RuneCountInString(str) w

[go-nuts] Is there a standard lib function which will return the count of characters in a string?

len(str) will get the count of bytes. utf8.RuneCountInString(str) will get the count of runes. but how to get the count of characters? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

[go-nuts] Re: Is there a standard lib function which will return the count of characters in a string?

Thanks for the information! On Saturday, July 23, 2016 at 11:55:42 PM UTC+8, Manlio Perillo wrote: > > Il giorno sabato 23 luglio 2016 16:52:29 UTC+2, T L ha scritto: >> >> len(str) will get the count of bytes. >> >> utf8.RuneCountInString(str) will get the count

[go-nuts] Will go compiler do optimization here if "bytes" is a global variable?

http://go-talks.appspot.com/github.com/davecheney/presentations/writing-high-performance-go.slide#30 the above slide says "the conversion of the byte slice to a string" in the following case will no copy the underlining byte array. > var m = map[string]string{} > v, ok := m[string(bytes)] > >

[go-nuts] Will too many cases in a select block affect program efficiency much?

I haven't read golang src on how to implement select, but I feel it would be much complicated. Is there many push-into-queue and leave-queue actions? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] Re: is it possible to speed up type assertion?

On Thursday, February 2, 2017 at 4:25:05 PM UTC+8, T L wrote: > > > > On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote: >> >> Go's type assertion seems quite slow. The added cost is too much if it >> has to be in a tight loop. Here a

[go-nuts] Re: is it possible to speed up type assertion?

On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote: > > Go's type assertion seems quite slow. The added cost is too much if it has > to be in a tight loop. Here are the time taken on my laptop for the > following code. > > https://play.golang.org/p/cA96miTkx_ > > > chris$ time

Re: [go-nuts] Re: is it possible to speed up type assertion?

On Thursday, February 2, 2017 at 5:20:01 PM UTC+8, T L wrote: > > > > On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote: >> >> Hi, >> >> I can not really reproduce your results. I rewrote your code to use the >> builtin benchmarkin

[go-nuts] Re: is it possible to speed up type assertion?

On Thursday, February 2, 2017 at 6:01:19 PM UTC+8, T L wrote: > > I found that it is much faster if the dynamic values are pointers instead > of non-pointer. > By looking the code of function assertE2T in runtime/iface.go, ot looks memmove(to, from unsafe.Pointer, n uintptr) is slo

[go-nuts] Re: is it possible to speed up type assertion?

, 2017 at 4:25:05 PM UTC+8, T L wrote: > > > > On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote: >> >> Go's type assertion seems quite slow. The added cost is too much if it >> has to be in a tight loop. Here are the time taken on my laptop for the

[go-nuts] Re: is it possible to speed up type assertion?

I found that it is much faster if the dynamic values are pointers instead of non-pointer. package main import ( "testing" ) func AssertInt(c *int, d interface{}) { *c += d.(int) } func BenchmarkAssertionInt(b *testing.B) { count := 0 var t int = 1 d := (interface{})(t)

[go-nuts] Re: is it possible to speed up type assertion?

On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote: > > Go's type assertion seems quite slow. The added cost is too much if it has > to be in a tight loop. Here are the time taken on my laptop for the > following code. > > https://play.golang.org/p/cA96miTkx_ > > > chris$ time

Re: [go-nuts] Re: is it possible to speed up type assertion?

On Thursday, February 2, 2017 at 5:28:26 PM UTC+8, Ian Davis wrote: > > > On Thu, 2 Feb 2017, at 09:20 AM, T L wrote: > > > > On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote: > > Hi, > > I can not really reproduce your results. I rewrot

Re: [go-nuts] Re: is it possible to speed up type assertion?

-4 20 3.93 ns/op BenchmarkIface-4 186.7 ns/op BenchmarkReflect-4 5000015.6 ns/op > > On Thu, Feb 2, 2017 at 9:40 AM, T L <tapi...@gmail.com > > wrote: > >> Type assertion is even

[go-nuts] Is there a "strings.Clone(string) string" alike function?

Sometimes, I want to create a new string which will not share the underlying bytes with other strings. For example, to avoid the substring memory leak problem. newStr := string([]byte(oldStr)) is simple but will make two memory allocations, and one of them is a waste. There are two solutions

[go-nuts] Re: About "Declaring Empty Slices" of CodeReviewComments

On Tuesday, January 31, 2017 at 1:15:40 PM UTC+8, Keiji Yoshida wrote: > > Hi, > > "Declaring Empty Slices" of CodeReviewComments ( > https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices > ) says as below: > > ``` > When declaring a slice, use > > var t []string > >

[go-nuts] Re: About "Declaring Empty Slices" of CodeReviewComments

On Tuesday, January 31, 2017 at 1:15:40 PM UTC+8, Keiji Yoshida wrote: > > Hi, > > "Declaring Empty Slices" of CodeReviewComments ( > https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices > ) says as below: > > ``` > When declaring a slice, use > > var t []string > >

Re: [go-nuts] Is there a "strings.Clone(string) string" alike function?

On Wednesday, February 1, 2017 at 5:22:51 PM UTC+8, Jan Mercl wrote: > > On Wed, Feb 1, 2017 at 10:19 AM T L <tapi...@gmail.com > > wrote: > > > newStr := string([]byte(oldStr)) is simple but will make two memory > allocations, and one of them is a waste. > > I

Re: [go-nuts] Is there a "strings.Clone(string) string" alike function?

On Wednesday, February 1, 2017 at 5:22:51 PM UTC+8, Jan Mercl wrote: > > On Wed, Feb 1, 2017 at 10:19 AM T L <tapi...@gmail.com > > wrote: > > > newStr := string([]byte(oldStr)) is simple but will make two memory > allocations, and one of them is a waste. > > I

[go-nuts] Re: Is there a "strings.Clone(string) string" alike function?

Is it a good idea to make the builtin copy function support one parameter? So that we can use it to deep copy string and interface values. On Wednesday, February 1, 2017 at 5:18:56 PM UTC+8, T L wrote: > > Sometimes, I want to create a new string which will not share the > underly

Re: [go-nuts] About 64bits alignment

On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote: > > > > On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: >> >> On Sun, Feb 5, 2017 at 10:52 AM, T L <tapi...@gmail.com> wrote: >> > Ian, thanks for the answers. >>

Re: [go-nuts] About 64bits alignment

On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: > > On Sun, Feb 5, 2017 at 10:52 AM, T L <tapi...@gmail.com > > wrote: > > Ian, thanks for the answers. > > > > But I still not very confirm on many points. > > >

Re: [go-nuts] About 64bits alignment

On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote: > > > > On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote: >> >> >> >> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: >>> >>> On Sun, Feb 5, 2017

Re: [go-nuts] Is there a "strings.Clone(string) string" alike function?

trings with length <= 32 https://play.golang.org/p/TfdahRKVr3 > On 1 February 2017 at 09:18, T L <tapi...@gmail.com > wrote: > > Sometimes, I want to create a new string which will not share the > underlying > > bytes with other strings. > > For example, to

Re: [go-nuts] About 64bits alignment

On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: > > On Sun, Feb 5, 2017 at 10:52 AM, T L <tapi...@gmail.com > > wrote: > > Ian, thanks for the answers. > > > > But I still not very confirm on many points. > > >

Re: [go-nuts] About 64bits alignment

contradict the sync/atomic statement "The >> first word in a global variable or in an allocated struct or slice can be >> relied upon to be 64-bit aligned."? >> >> On Fri, Feb 3, 2017 at 6:44 AM Ian Lance Taylor <ia...@golang.org >> > wrote: >>

Re: [go-nuts] About 64bits alignment

On Saturday, February 4, 2017 at 5:40:25 PM UTC+8, T L wrote: > > > > On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote: >> >> On Fri, Feb 3, 2017 at 5:38 AM, T L <tapi...@gmail.com> wrote: >> > Why does WaitGroup.state method check

Re: [go-nuts] About 64bits alignment

On Saturday, February 4, 2017 at 2:51:53 PM UTC+8, Axel Wagner wrote: > > On Sat, Feb 4, 2017 at 5:49 AM, T L <tapi...@gmail.com > > wrote: > >> On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote: >>> >>> Never mind; I just re

Re: [go-nuts] About 64bits alignment

On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Feb 3, 2017 at 5:38 AM, T L <tapi...@gmail.com > > wrote: > > Why does WaitGroup.state method check 64-bit alignment at run time? > > Why not make the state field as the fir

Re: [go-nuts] About 64bits alignment

On Saturday, February 4, 2017 at 5:56:30 PM UTC+8, T L wrote: > > > > On Saturday, February 4, 2017 at 5:40:25 PM UTC+8, T L wrote: >> >> >> >> On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote: >>> >>> On Fri,

Re: [go-nuts] About 64bits alignment

uaranteed to be 64-bit aligned. The same would be true if we > substituted a WaitGroup for int64 in that example. > The go source shown in my last comment doesn't think so. > > On Fri, Feb 3, 2017 at 8:49 PM T L <tapi...@gmail.com > > wrote: > >> >> >&

Re: [go-nuts] About 64bits alignment

t; aligned. > Yes, there are 6 4-byte fields before the two 8-byte fields. Ok, then another question, is it safe to embed expvar.Float type in 32bit OSes? https://golang.org/src/expvar/expvar.go?s=1577:1608#L55 > > On Sat, Feb 4, 2017 at 11:12 AM, T L <tapi...@gmail.com > > w

Re: [go-nuts] About 64bits alignment

On Monday, February 6, 2017 at 3:55:35 AM UTC+8, T L wrote: > > > > On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: >> >> On Sun, Feb 5, 2017 at 10:52 AM, T L <tapi...@gmail.com> wrote: >> > Ian, thanks for the answers. >>

Re: [go-nuts] About 64bits alignment

On Monday, February 6, 2017 at 12:44:38 PM UTC+8, Ian Lance Taylor wrote: > > On Sun, Feb 5, 2017 at 8:15 PM, T L <tapi...@gmail.com > > wrote: > > > > In fact, I still have another question needs to be clarify: what does > the > > "word

Re: [go-nuts] About 64bits alignment

*WaitGroup) state() *uint64 { if uintptr(unsafe.Pointer())%8 == 0 { return (*uint64)(unsafe.Pointer()) } else { return (*uint64)(unsafe.Pointer([4])) } } On Thursday, February 2, 2017 at 2:18:33 AM UTC+8, T L wrote: > > > >

Re: [go-nuts] About 64bits alignment

On Thursday, February 2, 2017 at 12:11:39 AM UTC+8, Jan Mercl wrote: > > On Wed, Feb 1, 2017 at 5:04 PM T L <tapi...@gmail.com > > wrote: > > > But what does an allocated struct or slice means? A struct or slice > allocated on heap, not stack? > > There

[go-nuts] more cases for a operation means less possibility to get selected?

package main import "fmt" func main() { c0, c1 := make(chan int, 10), make(chan int, 10) go func() { for { c0 <- 0 } }() go func() { for { c1 <- 1 } }() var n0, n1 int f0 := func() {

[go-nuts] Re: Priority cases in select?

On Thursday, January 26, 2017 at 6:29:54 PM UTC+8, dja...@gmail.com wrote: > > > > On Wednesday, January 25, 2017 at 3:14:27 PM UTC+2, T L wrote: >> >> sometimes, I do want one case on a select block get selected even if >> there are multiple unblocked cases

[go-nuts] Re: Priority cases in select?

On Thursday, January 26, 2017 at 8:08:28 PM UTC+8, Volker Dobler wrote: > > [...] Fewer select-block usages means more efficient code. >> > > What if the priority-enabled-select is much complexer and > massively less efficient than two all-equal-selects? > It might be less lines of code but not

Re: [go-nuts] GolangRT Docs?

On Wednesday, January 25, 2017 at 5:16:07 AM UTC+8, Ian Lance Taylor wrote: > > On Tue, Jan 24, 2017 at 12:46 PM, josvazg > wrote: > > > > Golang runtime has been fully translated to Go for a while now. I know I > > could just read the source code directly but... > > >

Re: [go-nuts] more cases for a operation means less possibility to get selected?

es the starvation is still a mystery. > [0] of course, the whole truth is here: > https://golang.org/ref/spec#Select_statements > > On Thu, Jan 26, 2017 at 1:06 PM T L <tapi...@gmail.com > > wrote: > >> >> package main >> >> import "fmt&q

Re: [go-nuts] more cases for a operation means less possibility to get selected?

4865659/5134341=0.95 > 1 > pass one: 50361915/49638085=1.01 > pass two: 54589075/45410925=1.20 > pass three: 47290086/52709914=0.90 > The result for 10 is the same as 30 on my machine. It looks the reason is starvation (see my last comment). > >

Re: [go-nuts] GolangRT Docs?

On Friday, January 27, 2017 at 2:05:02 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Jan 26, 2017 at 9:18 AM, T L <tapi...@gmail.com > > wrote: > > > > On Wednesday, January 25, 2017 at 5:16:07 AM UTC+8, Ian Lance Taylor > wrote: > > > >

Re: [go-nuts] GolangRT Docs?

On Friday, January 27, 2017 at 4:05:03 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Jan 26, 2017 at 11:10 AM, T L <tapi...@gmail.com > > wrote: > > > > I still don't understand what are implicit memory allocations, could you > > make an explanation? >

[go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?

On Saturday, January 28, 2017 at 10:33:08 PM UTC+8, Dave Cheney wrote: > > > > On Sunday, 29 January 2017 01:25:20 UTC+11, T L wrote: >> >> >> >> On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote: >>> >>> From the d

[go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?

t1 := new(int) t2 := new(int) runtime.SetFinalizer(t1, func(*int) {println(1)}) runtime.SetFinalizer(t2, func(*int) {println(2)}) runtime.GC() time.Sleep(time.Second * 20) } > > > On Saturday, January 28, 2017 at 6:17:37 AM UTC-7, T L wrote: >> >>

[go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?

t1 := new(int) t2 := new(int) runtime.SetFinalizer(t1, func(*int) {println(1)}) runtime.SetFinalizer(t2, func(*int) {println(2)}) runtime.GC() time.Sleep(time.Second * 20) } > > > On Saturday, January 28, 2017 at 6:17:37 AM UTC-7, T L wrote: >> >>

[go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?

On Saturday, January 28, 2017 at 10:46:50 PM UTC+8, Dave Cheney wrote: > > > > On Sunday, 29 January 2017 01:42:08 UTC+11, T L wrote: >> >> >> >> On Saturday, January 28, 2017 at 10:33:08 PM UTC+8, Dave Cheney wrote: >>> >>> >>

[go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?

On Saturday, January 28, 2017 at 10:25:20 PM UTC+8, T L wrote: > > > > On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote: >> >> From the doc: "The finalizer for obj is scheduled to run at some >> arbitrary time after obj becomes

[go-nuts] I know finalizers are not promised to be called, but is it too not promised?

package main import "time" import "runtime" type T1 struct{ i int } type T2 struct{ i int } func main() { t1 := new(T1) t2 := new(T2) runtime.SetFinalizer(t1, func(*T1) {println(1)}) runtime.SetFinalizer(t2, func(*T2) {println(2)}) runtime.GC()

Re: [go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?

On Sunday, January 29, 2017 at 1:04:35 AM UTC+8, Axel Wagner wrote: > > On Sat, Jan 28, 2017 at 4:05 PM, T L <tapi...@gmail.com > > wrote: > >> >> >> On Saturday, January 28, 2017 at 10:46:50 PM UTC+8, Dave Cheney wrote: >>> >>> >>

Re: [go-nuts] Priority cases in select?

On Wednesday, January 25, 2017 at 10:14:49 PM UTC+8, Jan Mercl wrote: > > On Wed, Jan 25, 2017 at 2:14 PM T L <tapi...@gmail.com > > wrote: > > > sometimes, I do want one case on a select block get selected even if > there are multiple unblocked cases. > > For

[go-nuts] Priority cases in select?

sometimes, I do want one case on a select block get selected even if there are multiple unblocked cases. For example, I don't want the dataCh case is selected if the stopCh and the timer channel are unblocked: select { case <- stopCh: return case value := <-dataCh: } select { case <-

Re: [go-nuts] GolangRT Docs?

lagged by -m, > and presumably forbidden by -+. > so new(T) is just a sugar of the following one? var t T; > > //jb > > > On 26 Jan 2017, at 20:10, T L <tapi...@gmail.com > wrote: > > > > It looks a call to new will not be reported by -m either. > &g

[go-nuts] Is Go too strict for nesting function callings?

package main import "fmt" func f() (int, bool) {return 1, false} func g1(int, bool) {} func g2(string, int, bool) {} func main() { fmt.Println(f()) // 1 false fmt.Println("a", f()) // multiple-value f() in single-value context g1(f()) // ok g2("a", f()) // multiple-value

[go-nuts] Re: Does Go spec assure that a substring shares the underlying bytes with the original string?

On Tuesday, February 21, 2017 at 1:12:37 AM UTC+8, T L wrote: > > I know gc assures this, but I don't know if it is compiler specified or a > spec rule. > > It looks that the function "Index(s, sep string) int" in strings package > has not a fromIndex parameter. >

[go-nuts] Does Go spec assure that a substring shares the underlying bytes with the original string?

I know gc assures this, but I don't know if it is compiler specified or a spec rule. It looks that the function "Index(s, sep string) int" in strings package has not a fromIndex parameter. So I must use strings.Index(s[fromIndex:], sep) to search a substr from a specified index. This implies

[go-nuts] Re: Unsafe string/slice conversions

On Wednesday, February 22, 2017 at 6:53:53 AM UTC+8, Caleb Spare wrote: > > I have a program that uses unsafe in order to coerce some slices to > strings for use as map keys. (Avoiding these allocations ends up being > an important performance optimization to this program.) > > Here's some

Re: [go-nuts] Does Go spec assure that a substring shares the underlying bytes with the original string?

On Tuesday, February 21, 2017 at 1:30:24 AM UTC+8, Ian Lance Taylor wrote: > > On Mon, Feb 20, 2017 at 9:12 AM, T L <tapi...@gmail.com > > wrote: > > > > I know gc assures this, but I don't know if it is compiler specified or > a > > spec rule. &g

[go-nuts] about the memclr optimization

https://github.com/golang/go/issues/5373 I made a test package main import ( "testing" ) const N = 1024 * 100 var a [N]int func BenchmarkArrayPtr(b *testing.B) { for i := 0; i < b.N; i++ { for i := range { a[i] = 0 } } } func BenchmarkArray(b

Re: [go-nuts] about the memclr optimization

On Saturday, February 11, 2017 at 4:23:07 PM UTC+8, Axel Wagner wrote: > > To expand on Dave's point: Your function has a data race (reads/writes > concurrent with writes in different goroutines) and thus its behavior is > not defined. Run with the benchmark with -race to confirm. The compiler

[go-nuts] Re: about the memclr optimization

On Saturday, February 11, 2017 at 1:49:58 PM UTC+8, T L wrote: > > https://github.com/golang/go/issues/5373 > btw, does this optimization imply that the zero value of any type is composed by zero bytes? At least for all current supported ARCHes. > > > I made a tes

[go-nuts] Weired or not?

package main type S1 struct { } func (*S1) f() {} type S2 struct { S1 } // var _ = S1.f // S1.f undefined (type S1 has no method f) // var _ = S2.f // S2.f undefined (type S2 has no method f) var _ = (*S2).f // ok! func main() {} -- You received this message because you are subscribed to

[go-nuts] Re: Understanding go routine heap

On Saturday, August 20, 2016 at 2:29:41 PM UTC+8, Yulrizka wrote: > > Dear gophers > > I have discussion with my colleague about this code > > > func process() *foo { > var result *foo > > var wg sync.WaitGroup > wg.Add(1) > go func() { > defer wg.Done() > result

[go-nuts] Re: Why a **T value can't call methods of *T and T if a *T value can call methods of T?

And why value of *I can't call methods of I? where I is an interface type. Looks there are many inconsistencies in golang. On Monday, August 22, 2016 at 10:04:31 PM UTC+8, T L wrote: > > . > -- You received this message because you are subscribed to the Google Groups "gola

[go-nuts] Bounds check elimination cases. Intended or compiler not clever enough

just made some tests to check the new SSA BCE feature. It is cool by removing many unnecessary bounds checks. But I still found some cases where I think BCE should also be applied but not. I don't know if they are intended or not. // example4.go package main import "math/rand" func fa2() {

[go-nuts] Why a **T value can't call methods of *T and T if a *T value can call methods of T?

. -- 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. For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Understanding go routine heap

On Monday, August 22, 2016 at 9:47:03 PM UTC+8, Joubin Houshyar wrote: > > > > On Saturday, August 20, 2016 at 2:29:41 AM UTC-4, Yulrizka wrote: >> >> Dear gophers >> >> I have discussion with my colleague about this code >> >> >> func process() *foo { >> var result *foo >> >> var wg

[go-nuts] when an interface type embeds two other interface types, why the other two interface types can't have non-zero intersection?

package main type I1 interface { f1() fa() } type I2 interface { f1() fb() } type I interface { I1 I2 } // error: duplicate method f1 func main() { } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

  1   2   3   4   5   6   >