[go-nuts] Re: Allocating lots (e.g. a million) objects on the heap

Try a naive solution, and see if it is good enough, before optimising. On Monday, 20 July 2020 18:35:14 UTC+1, netconn...@gmail.com wrote: > > I have an application where I will be allocating millions of data > structures, all of the same size. My program will need to run continuously > and be

[go-nuts] Re: module questions

GOPRIVATE is your friend. https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules On Monday, 20 July 2020 20:40:19 UTC+1, K Richard Pixley wrote: > > I'm think I understand the go-1.14 downloadable module workflow. But I'm > not getting how to use modules in an enterprise syst

[go-nuts] Re: [Generics] Simplified syntax to sidestep the bracket arguments

I have tried to propose something like this in https://groups.google.com/forum/#!topic/golang-nuts/W3fSnH0w1G0 (and earlier I was dancing around that idea in https://groups.google.com/forum/#!topic/golang-nuts/Rp3yUUy2nS8 ), but somehow it did not get any serious attention. I still think that

Re: [go-nuts] [generics] question regarding package level generic type declarations

On Tue, Jul 21, 2020 at 5:53 AM Manlio Perillo wrote: > > What about: > > package example(T1, T2) > > This declares T1 and T2 as package level types. > > import "example"(int, float) > > This imports the example package with T1 as int and T2 as float. > > The limitation is that you need to

Re: [go-nuts] Re: Allocating lots (e.g. a million) objects on the heap

sync.Pool is not useful for long lived objects - which the op implies to me > On Jul 21, 2020, at 9:11 PM, tokers wrote: > > And maybe the reuse mechanism (e.g. sync.Pool) is good for you. >> On Tuesday, July 21, 2020 at 1:35:14 AM UTC+8 netconn...@gmail.com wrote: >> I have an application wher

[go-nuts] Re: Allocating lots (e.g. a million) objects on the heap

And maybe the reuse mechanism (e.g. sync.Pool) is good for you. On Tuesday, July 21, 2020 at 1:35:14 AM UTC+8 netconn...@gmail.com wrote: > I have an application where I will be allocating millions of data > structures, all of the same size. My program will need to run continuously > and be pret

[go-nuts] Re: What's the basic block layout algorithm ?

Thanks Keith, then I will just read the code directly. Fortunately, the code does not seem to be a lot. I think branch is a bit too much in some cases, such as the math.IsInf function, so I want to see if I can optimize it somewhere. 在2020年7月22日星期三 UTC+8 上午9:05:46 写道： > It's not a fancy algori

[go-nuts] Re: What's the basic block layout algorithm ?

It's not a fancy algorithm. It tries to layout blocks connected by high-likelihood edges together. It also tries to keep panic paths at the end. I don't know of any documentation for it, other than the code. There's nothing particularly important in the layout pass to help with register allocat

Re: [go-nuts] [generics] generic function definition all in one parameter list

For constraints they also could be after type name: func IndexOf(slice []type T comparable, find T) int or maybe this is clearer: func IndexOf(slice []type comparable T, find T) int This generic type information could be added on leftmost first use of the type in the parameter list or return, an

Re: [go-nuts] [Generics] Simplified syntax to sidestep the bracket arguments

I think this has merit. “Feels” Go-Like to me and is very easy to read. > On Jul 21, 2020, at 10:56 AM, Kh Af wrote: > > Forgive me for making a new thread, I felt the older ones had run their > course, and I had trouble deciding who to reply to. > > I would like to propose a simpler syntax wh

Re: [go-nuts] [generics] generic function definition all in one parameter list

On Tue, Jul 21, 2020 at 3:37 PM Tor Langballe wrote: > > This might have been discussed, but can't find anything about so easy, joined > late... > > Could generic function definitions be done all in one paramter list using the > type keyword? > > func IndexOf(slice []type T, find type T) int > >

Re: [go-nuts] [Generics] Simplified syntax to sidestep the bracket arguments

On Tue, Jul 21, 2020 at 9:51 AM Kh Af wrote: > > Forgive me for making a new thread, I felt the older ones had run their > course, and I had trouble deciding who to reply to. > > I would like to propose a simpler syntax which looks a bit more Go-like (to > me) > is more terse, has no ambiguity a

[go-nuts] [generics] generic function definition all in one parameter list

This might have been discussed, but can't find anything about so easy, joined late... Could generic function definitions be done all in one paramter list using the type keyword? func IndexOf(slice []type T, find type T) int or func IndexOf(slice []type T, find T) int instead of func IndexO

Re: [go-nuts] Generics and parentheses

On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba wrote: > I'd say a dot is necessary when instantiating a function call but > unnecessary when instantiating a type because it's always syntactically > clear when a type is required. > That's not true in Go. Conversions look like function calls:

Re: [go-nuts] Re: Generics and parentheses

Thanks for the feedback Ian! I was drawing the idea mostly from Rust, which already does the same thing, but uses "::" instead of a dot and it works fine there, but sure, it has its drawbacks. st 22. 7. 2020 o 0:05 Ian Lance Taylor napísal(a): > On Tue, Jul 21, 2020 at 8:49 AM wrote: > > > > I

Re: [go-nuts] Re: Generics and parentheses

On Tue, Jul 21, 2020 at 8:49 AM wrote: > > I feel like you guys missed my suggestion earlier. I will repeat it because I > think it can be good. What about a dot to separate type parameters in > specialization? > > func zero() T { > var x T > return x > } > > func mai

[go-nuts] Hiding Go HTTP Client Behind a Proxy or Tor

Say you’re a DevOps or a security manager and you want to make sure some or maybe all of your pods use *Tor* or some other proxy as an egress gateway. Here's a short tutorial showing how to do it using #golang #docker and #kubernetes https://medium.com/@tufin/how-to-use-a-proxy-with-go-http-clien

[go-nuts] template

Hi All, I am running a website for which we use templates. While I see the benefit of templates, I also notice that it has gotten ugly over time. So, here are my questions: - Are templates popular? Or do you avoid using it? - Any do's and don'ts? Any best practices? - Any suggestions on formatt

Re: [go-nuts] Generics and parentheses

I'd say a dot is necessary when instantiating a function call but unnecessary when instantiating a type because it's always syntactically clear when a type is required. ut 21. 7. 2020 o 18:51 napísal(a): > Using angle brackets is not a must for supporting generics, but it is the > common syntax

Re: [go-nuts] Calling methods from inside a function in same package

I think I'm very likely misunderstanding your question. Would you mind providing more detail? You can definitely call methods within a function, even if they're defined in the same package. In this example, I call a method from the type "myInt" in the main function: https://play.golang.org/p/AAjVZ

[go-nuts] Calling methods from inside a function in same package

Hi, One can call global function of same package from inside a function, But I am curious if I can call a method from inside a function? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails fro

[go-nuts] re2c now supports Go

Hello Go community! I am glad to announce the release of re2c-2.0 , a lexer generator tool that now supports Go. It is an old project: the first release was in 1993. It has been used in the C world for many years, but the Go backend has been added

Re: [go-nuts] Generics and parentheses

like java？i like it 在 2020年7月15日星期三 UTC+8上午6:31:55，Harald Weidner写道： > > Hello, > > > A typical computer keyboard provides four easily accessible pairs of > > single-character symmetrical "brackets": parentheses ( and ), square > > brackets [ and ], curly braces { and }, and angle brackets < an

[go-nuts] [Generics] Simplified syntax to sidestep the bracket arguments

Forgive me for making a new thread, I felt the older ones had run their course, and I had trouble deciding who to reply to. I would like to propose a simpler syntax which looks a bit more Go-like (to me) is more terse, has no ambiguity and does not require any new bracket types. Here it goes:

Re: [go-nuts] Generics and parentheses

Using angle brackets is not a must for supporting generics, but it is the common syntax of generics in programming languages that support generics, the same way as square brackets are the common syntax for indexing in programming languages. If I understand correctly, the ambiguity problem with

Re: [go-nuts] [generics]The ability to allow different length arrays and slices

Clearly that's a workaround though. Like how you can copy a slice of bytes without calling copy by casting it to a string and then back to []bytes. It gets the job done, but it's weird and not obvious. On Wednesday, July 15, 2020 at 12:14:19 PM UTC-7, Axel Wagner wrote: > > Why not just accept

[go-nuts] Re: Allocating lots (e.g. a million) objects on the heap

Do the data structures contain pointers? If not, I seem to strongly recall that the GC does not have to scan slices when the objects contain no pointers. Perhaps someone with in-depth knowledge of the GC can confirm or refute that. If that is the case, then large slices should not be a burden o

[go-nuts] Re: Generics and parentheses

I feel like you guys missed my suggestion earlier. I will repeat it because I think it can be good. What about a dot to separate type parameters in specialization? func zero() T { var x T return x } func main() { fmt.Println(zero.()) // . required here }

[go-nuts] draft designs for file system interfaces & file embedding

Hi all, I've posted two draft designs: one introducing general-purpose file system interfaces, with Rob Pike; and one for embedding files into Go programs, with Brad Fitzpatrick. These are draft designs we're circulating for feedback, not official proposals. (We certainly hope they will be well re

Re: [go-nuts] [generics] question regarding package level generic type declarations

What about: package example(T1, T2) This declares T1 and T2 as package level types. import "example"(int, float) This imports the example package with T1 as int and T2 as float. The limitation is that you need to import the same package multiple times for different T1 and T2. Manlio

Re: [go-nuts] [generics] Type embedding in generic types

I suggest we move the discussion about Axel's post to reddit . Let's keep this exclusively on the the topic of embeding + generics. For anyone joining here, the main arguments are in the 4th post here

Re: [go-nuts] [generics] Type embedding in generic types

The Context problem is more easily solved using package namespaces for keys with conventions rather than type embedding. Otherwise you end up with a brittle multiple inheritance problem. Or you need language support for typed TLS and remove Context entirely. > On Jul 21, 2020, at 6:24 AM, 'A

Re: [go-nuts] [generics] Type embedding in generic types

On Tue, Jul 21, 2020 at 10:54 AM 'Javier Zunzunegui' via golang-nuts < golang-nuts@googlegroups.com> wrote: > It's not A(B,C,D) vs A(B(C(D))), both are supported with & without > embedding. My issue is with a linked list that requires a new type for each > additional node. It is potentially an exp

[go-nuts] What's the basic block layout algorithm ?

Hi, I was looking at the layout pass recently, but I didn't find any documents about it. I would like to ask what algorithm is used for this pass? There is not much code for this pass, but if there is some documentation, it will be more convenient to understand it. The layout pass has something

Re: [go-nuts] [generics] Type embedding in generic types

It's not A(B,C,D) vs A(B(C(D))), both are supported with & without embedding. My issue is with a linked list that requires a new type for each additional node. It is potentially an explosion of types, an imho an abuse of the type system. > At the end of the day, though, my main point was "there

Re: [go-nuts] [generics] Type embedding in generic types

Why do you feel that a type A(B, C, D, E) should be supported, but A(B(C(D(E))) shouldn't? They are equivalent in expressiveness. And to be clear, I'd also prefer A(B, C, D, E) for this use, but ISTM this isn't possible without variadic type-parameters (i.e. I'd need a way to express "this function

Re: [go-nuts] [generics] Type embedding in generic types

Thanks for sharing Axel. I would place your post firmly in the category "doing something wild and can't use generics for it". Philosophical issues around context aside, it implements the chain of contexts directly via the type system, e.g.the TYPE after N wraps is `FooContext(BarContext(... N