Re: [go-nuts] what`s the intention of "heapGoal" around GC cycle

Wow~ let me check the code about "gc_trigger". Thanks a lot 在 2018年11月6日星期二 UTC+8上午11:50:19，Ian Lance Taylor写道： > > On Mon, Nov 5, 2018 at 6:47 PM, > > wrote: > > But why "intended to occur" is greater than live heap(heap_live)? > > If the heap goal were the size of the live heap, then it woul

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Steven Wiley (2018-11-05 22:12:40) >And let's face it. Templates, operator overloading, and talk of >generics has swirled around golang since its inception. Separating the >template/generic/operational overload step from the core language via a >pre-compile step� is one wa

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

The word "elegant" comes to mind... Comments below. On Monday, 5 November 2018 21:47:46 UTC+2, Andy Balholm wrote: > > The concept of using operators to implement methods cross-pollinated in my > mind with Patrick’s “Go Generics with Adaptors” thought experiment and > produced this: > https://g

Re: [go-nuts] what`s the intention of "heapGoal" around GC cycle

On Mon, Nov 5, 2018 at 6:47 PM, wrote: > But why "intended to occur" is greater than live heap(heap_live)? If the heap goal were the size of the live heap, then it would be time to do a garbage collection right now. Ian > 在 2018年11月6日星期二 UTC+8上午4:00:24，Ian Lance Taylor写道： >> >> On Mon, Nov 5,

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Hi all, There appear to be a lot of different paths to take as far as generics and templates go (pun intended). Many of you I am sure have more experience and have thought deeper about contracts and templates than I ever will. Also, I am sure all experienced users and programmers know the joys

[go-nuts] Windows Build Problem

Hi, I am having problems trying to build Go from source on my Windows 10 64-bit machine. If someone has done this, it would be great if you could show me how you set up your box (eg. which GCC version you are using, whether you are using MinGW vs TDM-GCC, etc.). Thanks. Henry -- You recei

Re: [go-nuts] what`s the intention of "heapGoal" around GC cycle

But why "intended to occur" is greater than live heap(heap_live)? 在 2018年11月6日星期二 UTC+8上午4:00:24，Ian Lance Taylor写道： > > On Mon, Nov 5, 2018 at 8:46 AM, > > wrote: > > > > I saw a variable "heapGoal" in gctrace printer. > > > > Why heapGoal is greater than heap_live? > > heapGoal is the si

Re: [go-nuts] Example of setting a struct field value via reflection requested

On Monday, November 5, 2018 at 6:18:27 PM UTC-5, kortschak wrote: > > https://play.golang.org/p/EtXlOCR1fDY > Thanks, I was able to adapt that into working code. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group a

Re: [go-nuts] Re: Large (binary or text) File transfers over rpc

https://grpc.io/docs/tutorials/basic/go.html#server-side-streaming-rpc Quoting Ricky (2018-11-05 18:02:38) >how do I make grpc return a stream? are you referring to google rpc >grpc library that is recommended by Golang folks to be used instead of >net/rpc lib which is a frozen package

Re: [go-nuts] Example of setting a struct field value via reflection requested

Note that SetField will panic unless the struct value is addressable, so you must obtain the reflect.Value from an addressable source (for example via a pointer as in Dan's example). On Mon, 5 Nov 2018 at 23:12, Eric Raymond wrote: > I need an equivalent of Python setattr() - that is, set a stru

Re: [go-nuts] Example of setting a struct field value via reflection requested

https://play.golang.org/p/EtXlOCR1fDY On Mon, 2018-11-05 at 15:12 -0800, Eric Raymond wrote: > I need an equivalent of Python setattr() - that is, set a struct > member by > string name - but the only example I've found on line (SetField > in oleiade/reflections on GitHub) panics and dies due to w

[go-nuts] Example of setting a struct field value via reflection requested

I need an equivalent of Python setattr() - that is, set a struct member by string name - but the only example I've found on line (SetField in oleiade/reflections on GitHub) panics and dies due to what looks like a spurious Elem() call. I thought I could see how to fix it, but the resulting cod

Re: [go-nuts] Re: Large (binary or text) File transfers over rpc

how do I make grpc return a stream? are you referring to google rpc grpc library that is recommended by Golang folks to be used instead of net/rpc lib which is a frozen package? Interesting ... I didn't know they had streams On Sun, Nov 4, 2018 at 12:20 PM Ian Denhardt wrote: > What is the f

Re: [go-nuts] what`s the intention of "heapGoal" around GC cycle

On Mon, Nov 5, 2018 at 8:46 AM, wrote: > > I saw a variable "heapGoal" in gctrace printer. > > Why heapGoal is greater than heap_live? heapGoal is the size of the heap when the next garbage collection is intended to occur. Ian -- You received this message because you are subscribed to the Goo

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

The concept of using operators to implement methods cross-pollinated in my mind with Patrick’s “Go Generics with Adaptors” thought experiment and produced this: https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890

[go-nuts] what`s the intention of "heapGoal" around GC cycle

I saw a variable "heapGoal" in gctrace printer. Why heapGoal is greater than heap_live? -- 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...@

Re: [go-nuts] Code generated by generics draft

On Mon, 5 Nov 2018 at 14:36, Jamie Clarkson wrote: > > Yes that does help, looks like a really good solution. In your opinion > would the resulting code be worthwhile (including all the dictionaries, > stubs etc.) when compared to the C++ code expansion method? I can see that > it would save fo

Re: [go-nuts] Re: Go 1.11.2 and Go 1.10.5 are released

I think if they were ordered by package it would be more useful. The package at least groups the functionality, the alpha sorting by name doesn’t provide any information. > On Nov 5, 2018, at 10:24 AM, Michel Casabianca > wrote: > > Hi Gophers, > > I updated my list of GO interfaces for the

Re: [go-nuts] Re: Go 1.11.2 and Go 1.10.5 are released

Hi Gophers, I updated my list of GO interfaces for these releases: http://sweetohm.net/html/gointerfaces.en.html Enjoy! Le ven. 2 nov. 2018 à 23:23, Nathan Kerr a écrit : > I updated my release related resources: > > >- Go Release Timeline

Re: [go-nuts] Code generated by generics draft

Yes that does help, looks like a really good solution. In your opinion would the resulting code be worthwhile (including all the dictionaries, stubs etc.) when compared to the C++ code expansion method? I can see that it would save for the basic types and types derived from them but once you

Re: [go-nuts] Code generated by generics draft

On Mon, 5 Nov 2018 at 13:19, Jamie Clarkson wrote: > I was more thinking about your Graph example which you posted where you're > using an item(type Node,Edge) struct {}, not accessing the members of the > Node and Edge types (which I agree is a dubious corner case) - looking at > it again though

Re: [go-nuts] Code generated by generics draft

I was more thinking about your Graph example which you posted where you're using an item(type Node,Edge) struct {}, not accessing the members of the Node and Edge types (which I agree is a dubious corner case) - looking at it again though it looks like you're boxing with interface{} in the gene

Re: [go-nuts] Code generated by generics draft

On Mon, 5 Nov 2018 at 11:38, Jamie Clarkson wrote: > Thanks Rog, yes that seems to be very similar to what I was converging on > - I see you're combining the dictionaries per-implied-type (as I suggested > above) into a single dictionary per generic function with one set of funcs > for each insta

Re: [go-nuts] Code generated by generics draft

Thanks Rog, yes that seems to be very similar to what I was converging on - I see you're combining the dictionaries per-implied-type (as I suggested above) into a single dictionary per generic function with one set of funcs for each instantiation. Makes sense. I've skimmed over your code but m

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Mon, 5 Nov 2018 at 10:21, Axel Wagner wrote: > Even though all we did was save some references to values, the code has >> radically changed (along with its runtime implications). >> > > you'd choose a suitable small subset based on the type-constructors used > in the signature. > For the reco

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

> > Even though all we did was save some references to values, the code has > radically changed (along with its runtime implications). > Because I am lazy and simply trying to illustrate how this can be done. I was trying to achieve consensus, not to implement generics and I never pretended that y

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Mon, 5 Nov 2018 at 02:35, Axel Wagner wrote: > On Sun, Nov 4, 2018 at 10:14 PM roger peppe wrote: > >> This code, for example: https://play.golang.org/p/eaLHBbUJT-d >> What might your generated code look like for that? >> > > A bit ad-hoc, but WAI: https://play.golang.org/p/vuCHY2RRxIR > > In