Re: [go-nuts] Re: Want to know differance between two code snippets defined here

[Manish Champaneri]

Link to complete project :
https://github.com/mchampaneri/go-multihost

File that contains this code
https://github.com/mchampaneri/go-multihost/blob/master/proxy.go 
Json file containing site details 
https://github.com/mchampaneri/go-multihost/blob/master/server.json 

On Friday, June 7, 2019 at 9:07:05 AM UTC+5:30, Burak Serdar wrote:
>
> On Thu, Jun 6, 2019 at 9:28 PM Sam Mortimer  > wrote: 
> > 
> > I suspect it's the classic that I think everyone does at least once - in 
> the second code block the for loop reuses the same storage on each 
> iteration for the variable site.  Try adding: 
> > site := site 
> > ..just before your append to verify this. 
>
> The loop only uses site.Incoming and site.Forward, though. Copying 
> site isn't necessary there. 
>
> Unless of course, the real code is something else, and what is pasted 
> here is a modified version of it. 
>
> > 
> > Cheers, 
> > -Sam. 
> > 
> > 
> > On Thursday, June 6, 2019 at 6:49:00 AM UTC-7, Manish Champaneri wrote: 
> >> 
> >> 
> >> I am try to add routes to mux read from json using for loop 
> >> 
> >> In one code i am directly appending route to mux 
> >> In other code I am calling a function which appends route to mux ( mux 
> is pass by pointer) 
> >> 
> >> Though both are doing same thing ( As I guess ) output is different. I 
> am curious why this is happening , 
> >> 
> >> This code is working 
> >> 
> >> func main() { 
> >> 
> >> configLoader() 
> >> 
> >> dispatchMux := http.NewServeMux() 
> >> 
> >> for _, site := range ServerConfigData.Sites { 
> >> 
> >> //Previously code of append function 
> >> parsedURL, _ := url.Parse(site.Forward) 
> >> fmt.Println(site.Incomming) 
> >> dispatchMux.Handle(site.Incomming, 
> httputil.NewSingleHostReverseProxy(parsedURL)) 
> >> 
> >> } 
> >> // Start the server 
> >> color.Green("Server Spinned Up on 2096") 
> >> http.ListenAndServe(":80", dispatchMux) 
> >> } 
> >> 
> >> 
> >> This code is not working 
> >> 
> >> func main() { 
> >> 
> >> configLoader() 
> >> 
> >> dispatchMux := http.NewServeMux() 
> >> 
> >> for _, site := range ServerConfigData.Sites { 
> >> append(dispatchMux, site.Incomming, site.Forward) 
> >> } 
> >> 
> >> // Start the server 
> >> 
> >> color.Green("Server Spinned Up on 2096") 
> >> http.ListenAndServe(":2096", dispatchMux) 
> >> } 
> >> 
> >>  // Route Appender 
> >>  func append(mux *http.ServeMux, incomming, forward string) { 
> >> color.Yellow("Starting ", incomming, " on ", forward, "\n") 
> >> parsedURL, _ := url.Parse(forward) 
> >> mux.Handle(incomming, 
> httputil.NewSingleHostReverseProxy(parsedURL)) 
> >> } 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a455e9e4-34ef-409b-9973-2b4d50759be1%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1527c584-103e-469a-822f-f6ef655f7db5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Want to know differance between two code snippets defined here

[Burak Serdar]

On Thu, Jun 6, 2019 at 9:28 PM Sam Mortimer  wrote:
>
> I suspect it's the classic that I think everyone does at least once - in the 
> second code block the for loop reuses the same storage on each iteration for 
> the variable site.  Try adding:
> site := site
> ..just before your append to verify this.

The loop only uses site.Incoming and site.Forward, though. Copying
site isn't necessary there.

Unless of course, the real code is something else, and what is pasted
here is a modified version of it.

>
> Cheers,
> -Sam.
>
>
> On Thursday, June 6, 2019 at 6:49:00 AM UTC-7, Manish Champaneri wrote:
>>
>>
>> I am try to add routes to mux read from json using for loop
>>
>> In one code i am directly appending route to mux
>> In other code I am calling a function which appends route to mux ( mux is 
>> pass by pointer)
>>
>> Though both are doing same thing ( As I guess ) output is different. I am 
>> curious why this is happening ,
>>
>> This code is working
>>
>> func main() {
>>
>> configLoader()
>>
>> dispatchMux := http.NewServeMux()
>>
>> for _, site := range ServerConfigData.Sites {
>>
>> //Previously code of append function
>> parsedURL, _ := url.Parse(site.Forward)
>> fmt.Println(site.Incomming)
>> dispatchMux.Handle(site.Incomming, 
>> httputil.NewSingleHostReverseProxy(parsedURL))
>>
>> }
>> // Start the server
>> color.Green("Server Spinned Up on 2096")
>> http.ListenAndServe(":80", dispatchMux)
>> }
>>
>>
>> This code is not working
>>
>> func main() {
>>
>> configLoader()
>>
>> dispatchMux := http.NewServeMux()
>>
>> for _, site := range ServerConfigData.Sites {
>> append(dispatchMux, site.Incomming, site.Forward)
>> }
>>
>> // Start the server
>>
>> color.Green("Server Spinned Up on 2096")
>> http.ListenAndServe(":2096", dispatchMux)
>> }
>>
>>  // Route Appender
>>  func append(mux *http.ServeMux, incomming, forward string) {
>> color.Yellow("Starting ", incomming, " on ", forward, "\n")
>> parsedURL, _ := url.Parse(forward)
>> mux.Handle(incomming, httputil.NewSingleHostReverseProxy(parsedURL))
>> }
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a455e9e4-34ef-409b-9973-2b4d50759be1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrL1C46rp3bqULfsKf5EtsVOWJ%3D65uSRUA0-5iLfBx%3D%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Want to know differance between two code snippets defined here

[Sam Mortimer]

I suspect it's the classic that I think everyone does at least once - in 
the second code block the for loop reuses the same storage on each 
iteration for the variable site.  Try adding:
site := site
..just before your append to verify this.

Cheers,
-Sam.


On Thursday, June 6, 2019 at 6:49:00 AM UTC-7, Manish Champaneri wrote:
>
>
> I am try to add routes to mux read from json using for loop
>
> In one code i am directly appending route to mux
> In other code I am calling a function which appends route to mux ( mux is 
> pass by pointer)
>
> Though both are doing same thing ( As I guess ) output is different.* I 
> am curious why this is happening ,*
>
> *This code is working*
>
> func main() {
>
> configLoader()
>
> dispatchMux := http.NewServeMux()
>
> for _, site := range ServerConfigData.Sites {
>
> //Previously code of append function
> parsedURL, _ := url.Parse(site.Forward)
> fmt.Println(site.Incomming)
> dispatchMux.Handle(site.Incomming, 
> httputil.NewSingleHostReverseProxy(parsedURL))
>
> }
> // Start the server
> color.Green("Server Spinned Up on 2096")
> http.ListenAndServe(":80", dispatchMux)}
>
>
> *This code is not working*
>
> func main() {
>
> configLoader()
>
> dispatchMux := http.NewServeMux()
>
> for _, site := range ServerConfigData.Sites {
> append(dispatchMux, site.Incomming, site.Forward)
> }
>
> // Start the server
>
> color.Green("Server Spinned Up on 2096")
> http.ListenAndServe(":2096", dispatchMux)}
>
>  // Route Appender
>  func append(mux *http.ServeMux, incomming, forward string) {
> color.Yellow("Starting ", incomming, " on ", forward, "\n")
> parsedURL, _ := url.Parse(forward)
> mux.Handle(incomming, httputil.NewSingleHostReverseProxy(parsedURL))}
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a455e9e4-34ef-409b-9973-2b4d50759be1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Want to know differance between two code snippets defined here

[Burak Serdar]

On Thu, Jun 6, 2019 at 8:09 PM Manish Champaneri
 wrote:
>
> Hi Burak,
>
> In working code, every route get attached to mux.
>
> In non working code, only last route of the loop  get retain while earlier 
> all gets vanished.


Try fmt,Printf("%v",dispatchMux) for both programs and see if there's
anything different between the two.

>
> Thanks & Regards,
> Manish champaneri
>
>
> On Thu, Jun 6, 2019, 20:17 Burak Serdar  wrote:
>>
>> On Thu, Jun 6, 2019 at 7:48 AM Manish Champaneri
>>  wrote:
>> >
>> >
>> > I am try to add routes to mux read from json using for loop
>> >
>> > In one code i am directly appending route to mux
>> > In other code I am calling a function which appends route to mux ( mux is 
>> > pass by pointer)
>> >
>> > Though both are doing same thing ( As I guess ) output is different. I am 
>> > curious why this is happening ,
>>
>> What is not working? Does the server start but not handle the correct
>> paths? Does it not start at all? Do the two for loops work with the
>> same values? Your problem, whatever it is, does not seem to be related
>> to the mux being passed to a function.
>>
>> >
>> > This code is working
>> >
>> > func main() {
>> >
>> > configLoader()
>> >
>> > dispatchMux := http.NewServeMux()
>> >
>> > for _, site := range ServerConfigData.Sites {
>> >
>> > //Previously code of append function
>> > parsedURL, _ := url.Parse(site.Forward)
>> > fmt.Println(site.Incomming)
>> > dispatchMux.Handle(site.Incomming, 
>> > httputil.NewSingleHostReverseProxy(parsedURL))
>> >
>> > }
>> > // Start the server
>> > color.Green("Server Spinned Up on 2096")
>> > http.ListenAndServe(":80", dispatchMux)
>> > }
>> >
>> >
>> > This code is not working
>> >
>> > func main() {
>> >
>> > configLoader()
>> >
>> > dispatchMux := http.NewServeMux()
>> >
>> > for _, site := range ServerConfigData.Sites {
>> > append(dispatchMux, site.Incomming, site.Forward)
>> > }
>> >
>> > // Start the server
>> >
>> > color.Green("Server Spinned Up on 2096")
>> > http.ListenAndServe(":2096", dispatchMux)
>> > }
>> >
>> >  // Route Appender
>> >  func append(mux *http.ServeMux, incomming, forward string) {
>> > color.Yellow("Starting ", incomming, " on ", forward, "\n")
>> > parsedURL, _ := url.Parse(forward)
>> > mux.Handle(incomming, 
>> > httputil.NewSingleHostReverseProxy(parsedURL))
>> > }
>> >
>> > --
>> > 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.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/450d1c76-826e-4210-9b27-77e81a03e146%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqq6RAoUVHWz_Yhwnk-8-6A4rQxLJSKCzLbrcEfpZP09wA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] In-Method declaration of array of struct literals vs global var?

[Steven Blenkinsop]

= is always required when you're assigning a value to the var. the
confusion might be that you can also have a declaration like

var bar []struct{a, b, c string}

where you don't assign a value to bar (meaning it will be null).

Really, the syntax is

var variableName Type = value

You can leave off either the "Type" or the "= value" but not both.

var bar = []struct{a, b, c string} {
  { "really", "long", "row"},
  { "many", "many", "rows"},
  ...
}

is just a special case where you've left off the "Type", and "value"
happens to be a composite literal expression. It could also be written as

var bar []struct{a, b, c string} = []struct{a, b, c string} {
  { "really", "long", "row"},
  { "many", "many", "rows"},
  ...
}

On Thu, Jun 6, 2019 at 2:47 PM 'Aaron Spangler' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thank you!  You are correct.  That was exactly my problem.  Adding the
> equals sign (=) solved it.
>
> I guess I need to be more aware that sometimes an equals statement is
> required on a 'var' line and other times it is not.  (perhaps only when it
> has a literal)
>
> Thanks again!
>
> On Thu, Jun 6, 2019 at 11:05 AM Ian Lance Taylor  wrote:
>
>> On Thu, Jun 6, 2019 at 10:56 AM ajs via golang-nuts
>>  wrote:
>> >
>> > I can declare literal bar inside a function like this:
>> >
>> > func foo() {
>> >   bar := []struct{a, b, c string} {
>> > { "really", "long", "row"},
>> > { "many", "many", "rows"},
>> > ...
>> >   }
>> > }
>> >
>> > But I really want it anchored (for code generation reason) outside of a
>> function like this:
>> >
>> > func foo() {
>> >   ...
>> > }
>> >
>> > var bar []struct{a, b, c string} {
>> >   { "really", "long", "row"},
>> >   { "many", "many", "rows"},
>> >   ...
>> > }
>> >
>> > The problem is it gets upset on the last character of the 'var bar ...'
>> line.  Is there a better way to write this?
>> > Note for reasons outside of this discussion, I really want to avoid
>> writing it by repeating the discrete field names:
>> >
>> > var bar []struct{a, b, c string} {
>> >   {a: "really",b: "long",c: "row"},  // Don't want to do this
>> >   {a: "many", b: "many", c: "rows"}, // Don't want to do this
>> >   ...
>> > }
>> >
>> > Any thoughts?  What am I missing?
>>
>> An important tip: when asking a question, please tell us precisely
>> what you did and precisely what happened.  You can see what happened,
>> but when you write "it gets upset" we have to guess.  And it's easy
>> for us to guess wrong.
>>
>> When I look at
>>
>> var bar []struct{a, b, c string} {
>>   { "really", "long", "row"},
>>   { "many", "many", "rows"},
>>   ...
>> }
>>
>> what I think is that it should say
>>
>> var bar = []struct{...
>>
>> That is, you are missing the "=".  But I don't know if that was a typo
>> in the e-mail message.  So if that doesn't help tell us exactly what
>> you did and exactly what happened.
>>
>> Ian
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAHP%2Bjq4-wp5EgvmK-POEHmDNa8-T9WUJqzAYJA9jRsuuo6%2Boaw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANjmGJsibJ5qVZ%3DTMW6FOU6VJtVKHP4uFjkN6wyf-sU8QOWrTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Michal Strba]

I really can’t promise to ever fully evaluate all generics proposals.

Perfectly understandable. I’ll show the benefits without you needing to
fully evaluate the proposal then :)

it’s still unusual in Go for a name that appears in a list to become in
scope for the rest of the list and for the following body.

Okay, so here is the main benefit of the scoping.

Let’s take this simple function that returns a static array with all
elements filled with some provided value.

Here’s how the signature would look in my proposal:

func Filled(gen n, x gen T) [n]T

And here’s how it would look if we had to list the generic arguments in a
separate list (feel free to supply gen with any other word):

func Filled(gen n, T)(x T) [n]T

Now, in this latter version, it’s not really clear how and where the
generic type gets inferred. Do I need to specify it manually? Under what
circumstances? When is the compiler able to infer it for me? Answers to
these questions are not clear.

On the other hand, in my proposal, the answers are very clear: unnamed
arguments get specified, everything else gets inferred.

func Filled(gen n, x gen T) [n]T//   ^^//
specified  inferred

Furthermore, there is never a choice between specifying and inferring a
generic type. The signature tells exactly which one the user must do.

One more minor benefit of this syntax is that it eliminates any extra
parentheses, keeping the clutter down and parsing easy.

I’ll respond to one more of your concerns.

There is also integer, signed integer, unsigned integer, comparable,
ordered, float, complex. One can even think of addable (includes string)
and indexable and sliceable.

Sure, we can imagine many ways of dividing types into groups. But just
because we can imagine that does not mean we need to.

I would argue that the “number contract” is far more useful than “addable”,
“indexable”, or anything else you can imagine.

The “number contract” would include all the number types (int*, uint*,
float*, complex*). Arithmetic and logic operations common to these types
would be available. This is a rich set of operations: +, -, *, /, <, >, and
so on. Also, all of these types allow using untyped integer constants as
their values.

Sure, you wouldn’t be able to put strings in Sum function with this
proposal, but do you really need to do that? I don’t think so.

št 6. 6. 2019 o 1:08 Ian Lance Taylor  napísal(a):

> On Wed, Jun 5, 2019 at 3:02 PM Michal Strba  wrote:
> >
> > Ian, have you had the time to evaluate the improvements to my proposal
> (the original one in this thread)? I'd love to hear if it has some more
> significat shortcomings and know what to think about. Or, if it has no
> perspective, I'd love to hear why.
> >
> > I know you're busy, so responding with "I haven't had the time yet" is
> completely understandable.
>
> I really can't promise to ever fully evaluate all generics proposals.
> There are simply too many of them.  All I can honestly do is throw out
> some quick comments, as I've done already.  If you want detailed
> feedback, I encourage you to seek it from other people.
>
> As I said in my reply to Randall earlier " relying on a general
> construct like "number" is problematic in Go.  There are many
> different ways to slice up Go's types.  "number" is just one of them.
> There is also integer, signed integer, unsigned integer, comparable,
> ordered, float, complex. One can even think of addable (includes
> string) and indexable and sliceable."
>
> I'm also still concerned about scoping.  You added some text, but it's
> still unusual in Go for a name that appears in a list to become in
> scope for the rest of the list and for the following body.
>
> Ian
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAO6k0us4gdyXcq%2Bu4iXEs_xNhH2GV%2BT5Rtem6ZFXbnf_sRTE6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: A good indicator of code quality

[andrey mirtchovski]

"does it look like the go standard library?"

that style is desirable, yet inimitable

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK4xykXwho1GeeJ883kPzCtOPXSNpPamLw6qAcBzQQgOLm8xYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Burak Serdar]

On Wed, Jun 5, 2019 at 10:31 PM Randall O'Reilly  wrote:
>
> On Jun 5, 2019, at 8:36 PM, Burak Serdar  wrote:
> >
> > On Wed, Jun 5, 2019 at 11:47 AM Randall O'Reilly  
> > wrote:
> >>
> >> It’s great to see that so many people share my considerable enthusiasm for 
> >> this proposal!  Seriously, nobody is willing to take a look and provide 
> >> any feedback?
> >
> > This reminds me of a proposal I wrote some months ago that uses
> > existing types as contracts with a new "like" keyword for primitives.
> > Your proposal takes that idea further and gets rid of contracts
> > completely. Even though the syntax is cleaner, I think you lost some
> > of the expressive power of contracts.  For instance:
> >
> > Edges []Edge : does this mean that Edges is an array where each
> > element is a type that satisfies Edge (and thus each element can have
> > a different type), or that it is an array where each element is the
> > same concrete type of Edge?
> >
> > The motivation behind contracts was to ensure generic types can be
> > compiled before instantiation. This proposal seems to give up on that.
>
> Just to be clear, the proposal is definitely NOT to get rid of contracts at 
> all!  The point is actually very similar to your proposal (as you noted) — 
> here’s the link for reference: 
> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
>
> Specifically any contract specified using like(), e.g., your SignedNumber 
> example (which becomes simply `signed` as the builtin generic type in my 
> proposal) should be essentially identical from the compiler’s perspective, 
> right?  They specify the same exact contract, just using a different syntax.
>
> Likewise, any use of a generic native “slice” or “map” type definitely 
> specifies a very concrete “contract” — it is just not an *arbitrary* contract 
> — it is just the familiar existing contract that we all know and love..
>
> I’m not sure about the claim that some of the examples in your proposal could 
> actually be compiled effectively in advance of instantiation.  For example, 
> anything involving a struct with specific fields (which is achieved using the 
> struct interface syntax in my proposal, but is essentially functionally the 
> same as the corresponding structs in your proposal and the draft proposal, 
> again just with a different simpler syntax that avoids explicit type 
> parameters), would presumably benefit considerably by knowing the concrete 
> types involved to know about field offsets and specific types used in 
> operations etc.  If you don’t know the concrete type(s), then you’re stuck 
> using virtualized “boxing” kinds of approaches for everything in the code, 
> right?  If you wait until you have the concrete type, the compiler can decide 
> the best way to optimize the various costs associated with boxing vs. code 
> bloat etc.

You don't need boxing with contracts specified as a list of possible
types. If you have a contract that lists types T1, T2, ... as possible
types, then you can compile the types and functions using that
contract once for each minimal concrete type that implements T1,
T2, A minimal concrete type that implements T1, T2,.. can be
obtained from the contract definition by creating a struct/interface
containing the list of fields/methods contract type has.


>
> Anyway, just to reiterate, the core idea is definitely *not* to abandon 
> contracts — just to use existing native contracts, which constitute a 
> well-known, well-tested finite “basis set” of contracts.  By using this very 
> limited space of contracts, we can use builtin keywords and a much simpler 
> syntax, and the compiler should actually have an *easier* time compiling 
> generic code compared to supporting arbitrary contracts.  I think it really 
> is the same basic idea from your like() proposal, so I “like” it :)
>
> - Randy
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqqDs1qu%3Dxgkupr-LVP-_DA8VHZvs4g%3DLKAr1S85sh7btQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Carl]

This proposal makes sense to me. 

Disclaimer: 
I don't know enough about language design to provide feedback on how it may 
be refined. This is just my perspective as a potential future user.

   1. It is one of the simplest proposals I've read so far (but I have not 
   read them all - there are too many to keep up with)
   2. It is easy to understand and visualise where it would be used
   3. It is orthogonal - it does not tread on the capabilities of other 
   keywords, but complements them nicely
   4. In conjunction with the "gen eq" and "gen num" keywords, it would be 
   sufficient for all the work I've needed to do



On Friday, May 31, 2019 at 4:29:03 AM UTC+12, Michal Strba wrote:
>
> Hi Gophers! :)
>
> I've been thinking about generics in Go 2 ever since the original 
> contracts proposal and few days ago, ideas finally clicked. One of the main 
> things about this proposal is that it deliberately omits the ability to 
> restrict the set of types a function can work with. This is a limitation, 
> but I hope to convince you that we can still do a vast majority of the 
> things we were missing, when we were missing generics. 
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal. 
> 
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
> new function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.
>
> Thanks,
> faiface
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/291fced4-873d-454f-9a23-49375cd5be6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: A good indicator of code quality

[Robert Johnstone]

You can look at https://goreportcard.com/ to get a look at some common 
metrics.  There are also quite a few different linters (golint, revive, 
staticcheck, plus others).

Robert

On Thursday, 6 June 2019 15:58:19 UTC-4, Carl wrote:
>
> I'd like to know what people are using to measure the quality of their Go 
> code bases and why. Specifically, I'm asking if:
>
>1. There is a way to score a code base on quality that works with 
>idiomatic Go
>2. Use this metric in a CI system and fail the build if the quality 
>falls
>3. Use this metric in a team to detect trends over time and hot spots 
>where technical debt tends to accumulate
>
> It strikes me that Go is quite different to the usual set of popular 
> languages and that even the most basic measures (cyclomatic complexity for 
> example) may not be a good fit. 
>
> For example:
>
>1. Adding proper error handling increases measured complexity, but is 
>actually preferable to not handling errors
>2. A switch case where a case statement contains one or more commas is 
>actually more maintainable, but would probably have the same score as 
>individual case statements on separate lines
>
> There are already a lot of tools that analyse Go code in several different 
> ways - but which ones really work in the long term? 
>
> I'd like to ask the community which ones you've had good experiences with 
> - a test of a good tool could be that a better score results in more 
> idiomatic, maintainable code.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0825d556-a988-4035-816a-4250dd424bbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] A good indicator of code quality

[Carl]

I'd like to know what people are using to measure the quality of their Go 
code bases and why. Specifically, I'm asking if:

   1. There is a way to score a code base on quality that works with 
   idiomatic Go
   2. Use this metric in a CI system and fail the build if the quality falls
   3. Use this metric in a team to detect trends over time and hot spots 
   where technical debt tends to accumulate

It strikes me that Go is quite different to the usual set of popular 
languages and that even the most basic measures (cyclomatic complexity for 
example) may not be a good fit. 

For example:

   1. Adding proper error handling increases measured complexity, but is 
   actually preferable to not handling errors
   2. A switch case where a case statement contains one or more commas is 
   actually more maintainable, but would probably have the same score as 
   individual case statements on separate lines

There are already a lot of tools that analyse Go code in several different 
ways - but which ones really work in the long term? 

I'd like to ask the community which ones you've had good experiences with - 
a test of a good tool could be that a better score results in more 
idiomatic, maintainable code.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/510f2a19-7dc8-4d01-ad1e-65155ca85355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] global var available in different files (same package)

[Natxo Asenjo]

hi,

I'd like to define a couple of global variables in a small cli app. The app 
has a few files but it's not large.

What I'd like is to use cli flags to define options, and those options 
should be available for all the functions. I quite like the fact that the 
content of the variables is checked for correctnes.

Code (using kingpin):

==kinpingtest.go=
package main

import (
"gopkg.in/alecthomas/kingpin.v2"
"os"
)

var (
app= kingpin.New("shittytest", "shitty kingpin test")
url= app.Flag("url", "url for app").Required().Short('u').URL()
domain = app.Flag("domain", "domain for 
app").Short('d').Required().String()
)

func main() {
kingpin.MustParse(app.Parse(os.Args[1:]))

whatever()
}

end kingpintest.go
and second file:

=otherfile.go
package main

import (
"fmt"
)

func whatever() {
u := *url
fmt.Println(u.String() + "/that")
fmt.Println(*domain)
}

===endotherfile.go===

And quit unsurprisingly, running it:

$ go run *.go --url http://this.com --domain kk.kk
http://this.com/that
kk.kk

The 'problem' I have is that I cannot use the variables directly and have 
to convert them to strings first, and as far as I can see I cannot do that 
globally because the kingpin arguments get parsed in main(). 

I see one possible solution, and that is to convert the vars to strings in 
main() and pass those as arguments to funcs called from main().

Are there better options for what I want to achieve (certainly must be, I 
am just a go newbie)?

Thanks in advance.

Regards,
Natxo

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/795cfc24-ace3-4c31-b898-f0f75ed25a60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] In-Method declaration of array of struct literals vs global var?

['Aaron Spangler' via golang-nuts]

Thank you!  You are correct.  That was exactly my problem.  Adding the
equals sign (=) solved it.

I guess I need to be more aware that sometimes an equals statement is
required on a 'var' line and other times it is not.  (perhaps only when it
has a literal)

Thanks again!

On Thu, Jun 6, 2019 at 11:05 AM Ian Lance Taylor  wrote:

> On Thu, Jun 6, 2019 at 10:56 AM ajs via golang-nuts
>  wrote:
> >
> > I can declare literal bar inside a function like this:
> >
> > func foo() {
> >   bar := []struct{a, b, c string} {
> > { "really", "long", "row"},
> > { "many", "many", "rows"},
> > ...
> >   }
> > }
> >
> > But I really want it anchored (for code generation reason) outside of a
> function like this:
> >
> > func foo() {
> >   ...
> > }
> >
> > var bar []struct{a, b, c string} {
> >   { "really", "long", "row"},
> >   { "many", "many", "rows"},
> >   ...
> > }
> >
> > The problem is it gets upset on the last character of the 'var bar ...'
> line.  Is there a better way to write this?
> > Note for reasons outside of this discussion, I really want to avoid
> writing it by repeating the discrete field names:
> >
> > var bar []struct{a, b, c string} {
> >   {a: "really",b: "long",c: "row"},  // Don't want to do this
> >   {a: "many", b: "many", c: "rows"}, // Don't want to do this
> >   ...
> > }
> >
> > Any thoughts?  What am I missing?
>
> An important tip: when asking a question, please tell us precisely
> what you did and precisely what happened.  You can see what happened,
> but when you write "it gets upset" we have to guess.  And it's easy
> for us to guess wrong.
>
> When I look at
>
> var bar []struct{a, b, c string} {
>   { "really", "long", "row"},
>   { "many", "many", "rows"},
>   ...
> }
>
> what I think is that it should say
>
> var bar = []struct{...
>
> That is, you are missing the "=".  But I don't know if that was a typo
> in the e-mail message.  So if that doesn't help tell us exactly what
> you did and exactly what happened.
>
> Ian
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHP%2Bjq4-wp5EgvmK-POEHmDNa8-T9WUJqzAYJA9jRsuuo6%2Boaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] In-Method declaration of array of struct literals vs global var?

[Ian Lance Taylor]

On Thu, Jun 6, 2019 at 10:56 AM ajs via golang-nuts
 wrote:
>
> I can declare literal bar inside a function like this:
>
> func foo() {
>   bar := []struct{a, b, c string} {
> { "really", "long", "row"},
> { "many", "many", "rows"},
> ...
>   }
> }
>
> But I really want it anchored (for code generation reason) outside of a 
> function like this:
>
> func foo() {
>   ...
> }
>
> var bar []struct{a, b, c string} {
>   { "really", "long", "row"},
>   { "many", "many", "rows"},
>   ...
> }
>
> The problem is it gets upset on the last character of the 'var bar ...' line. 
>  Is there a better way to write this?
> Note for reasons outside of this discussion, I really want to avoid writing 
> it by repeating the discrete field names:
>
> var bar []struct{a, b, c string} {
>   {a: "really",b: "long",c: "row"},  // Don't want to do this
>   {a: "many", b: "many", c: "rows"}, // Don't want to do this
>   ...
> }
>
> Any thoughts?  What am I missing?

An important tip: when asking a question, please tell us precisely
what you did and precisely what happened.  You can see what happened,
but when you write "it gets upset" we have to guess.  And it's easy
for us to guess wrong.

When I look at

var bar []struct{a, b, c string} {
  { "really", "long", "row"},
  { "many", "many", "rows"},
  ...
}

what I think is that it should say

var bar = []struct{...

That is, you are missing the "=".  But I don't know if that was a typo
in the e-mail message.  So if that doesn't help tell us exactly what
you did and exactly what happened.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUrcaDVSCEt-MeeZQ8CqZbp4vpDZ35jLu8Pu%2BmDjcwupw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] In-Method declaration of array of struct literals vs global var?

[ajs via golang-nuts]

I can declare literal bar inside a function like this:

func foo() {
  bar := []struct{a, b, c string} {
{ "really", "long", "row"},
{ "many", "many", "rows"},
...
  }
}

But I really want it anchored (for code generation reason) outside of a 
function like this:

func foo() {
  ...
}

var bar []struct{a, b, c string} {
  { "really", "long", "row"},
  { "many", "many", "rows"},
  ...
}

The problem is it gets upset on the last character of the 'var bar ...' 
line.  Is there a better way to write this?
Note for reasons outside of this discussion, I really want to avoid writing 
it by repeating the discrete field names:

var bar []struct{a, b, c string} {
  {a: "really",b: "long",c: "row"},  // Don't want to do this
  {a: "many", b: "many", c: "rows"}, // Don't want to do this
  ...
}

Any thoughts?  What am I missing?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/94da4a1c-2eb9-4b28-b9b7-9b0d44b237f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [48]byte should be make to empty

[Michel Levieux]

Hi,

It is not quite clear what you are trying to do, but if I understand it
well:

var array = [48]byte{}

should initialize your array with zero values.

Le jeu. 6 juin 2019 à 15:48, sasikala tholisam  a
écrit :

> test [48]byte make to empty..
> How to do 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f5a26feb-8946-415c-9eb3-f80e8da73d3c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANgi3351W50DbJ%3DoZrnw0-vCG-kx7y1PA-1yXR-EgbTef2grhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] make an empty slice

[Marvin Renich]

* sasikala tholisam  [190606 09:49]:
> 
> test []Exam
> 
> type Exam struct{
> Time uint32
> LogType uint32
> Data [32]byte
> }
> 
> test is a slice of []Exam..It should be an empty slice...how to make test 
> as empty?

After changing the first line to

var test []Exam

your code will produce an empty slice for test.  You can check its
length with len(test) and it will be 0.  Here's the code on the
playground:  https://play.golang.org/p/UtZ-YhNXojk

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190606145528.ufocsb6tfi5i6pah%40basil.wdw.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Want to know differance between two code snippets defined here

[Burak Serdar]

On Thu, Jun 6, 2019 at 7:48 AM Manish Champaneri
 wrote:
>
>
> I am try to add routes to mux read from json using for loop
>
> In one code i am directly appending route to mux
> In other code I am calling a function which appends route to mux ( mux is 
> pass by pointer)
>
> Though both are doing same thing ( As I guess ) output is different. I am 
> curious why this is happening ,

What is not working? Does the server start but not handle the correct
paths? Does it not start at all? Do the two for loops work with the
same values? Your problem, whatever it is, does not seem to be related
to the mux being passed to a function.

>
> This code is working
>
> func main() {
>
> configLoader()
>
> dispatchMux := http.NewServeMux()
>
> for _, site := range ServerConfigData.Sites {
>
> //Previously code of append function
> parsedURL, _ := url.Parse(site.Forward)
> fmt.Println(site.Incomming)
> dispatchMux.Handle(site.Incomming, 
> httputil.NewSingleHostReverseProxy(parsedURL))
>
> }
> // Start the server
> color.Green("Server Spinned Up on 2096")
> http.ListenAndServe(":80", dispatchMux)
> }
>
>
> This code is not working
>
> func main() {
>
> configLoader()
>
> dispatchMux := http.NewServeMux()
>
> for _, site := range ServerConfigData.Sites {
> append(dispatchMux, site.Incomming, site.Forward)
> }
>
> // Start the server
>
> color.Green("Server Spinned Up on 2096")
> http.ListenAndServe(":2096", dispatchMux)
> }
>
>  // Route Appender
>  func append(mux *http.ServeMux, incomming, forward string) {
> color.Yellow("Starting ", incomming, " on ", forward, "\n")
> parsedURL, _ := url.Parse(forward)
> mux.Handle(incomming, httputil.NewSingleHostReverseProxy(parsedURL))
> }
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/450d1c76-826e-4210-9b27-77e81a03e146%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrKNRy0jZNfXO2H%2BchE85DewUbHwZF%3DiesuRCeBBQpT%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interate over an interface

[Burak Serdar]

On Thu, Jun 6, 2019 at 7:48 AM Iago Santos  wrote:
>
> Hi,
>
> I have the following code: https://pastebin.com/hAbnPV3C
>
> What I am trying to do in the line 347 is to get the first item of an 
> interface map[string]map[string]string, in any case I as not able to get it.
> The result of the line 345 is : Searching in loopQueue the volume:  
> {map[pvc18aa0:map[pvcGroupID:adc2fde0 pvcNamespace:cephfs]]}

How do you get it? And what happens when you do?

If the type is correct, you should be able to:

mm:=vv.(map[string]map[string]string)
for k,v:=range mm {
   // Here k should be pvc18aa0 and v should be
map[pvcGroupID:adc2fde0 pvcNamespace:cephfs]
}

>
> And I would like to get the results "pvc18aa0" "pvcGroupID:adc2fde0" and 
> "cephfs"
>
> The summary of this code is the following: I am watching persistentVolumes in 
> openshift, when I get the new persistenVolume I want to store it in a job 
> queue to do something with it, and that is why I need those values.
>
> Any help is appreciate it.
> Thank you.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/176c964d-c58e-422a-bd4a-a8af348d9ca0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqpo51pxOzeuLAAPxn-NF62w7bYZUCj26LXk-zZFjS3MLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] make an empty slice

[Mark Bauermeister]

You mean a slice that is not of type Exam?

test []int

Should work.
Your slice does need to adhere to some type.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fba31d31-7797-45b0-9473-1b1ba88ad937%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: modules: available GOPROXY instances or implementations?

[盛傲飞]

Hi,

I just created Goproxy  three days ago, 
which is currently the most dead simple way to build a Go module proxy, I 
guess. BTW, the https://goproxy.cn you mentioned is based on Goproxy.

Note that Goproxy will be production-ready very soon, after I have written 
the unit tests. :-)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7cbbcf6c-bfb5-4c82-a329-d7bcabd72079%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] You may not need to use Athens, but instead use Goproxy

[盛傲飞]

The Go module proxy should be a *very small thing*. At least from the 
protocol  it should 
be. But the Athens  seems to 
over-interpret this feature. I tried to read its code. To be honest, no 
offense, I was lost in its file ocean from the beginning. It has quite a 
lot of directories, quite a lot of files, quite a lot of structs, and quite 
a lot of interfaces. Of course, it may be because my personal understanding 
is limited.

After all, in order to make it easier for everyone to build their own Go 
module proxy, I created Goproxy .

Now you can build your own Go module proxy in this way:

package main


import (
 "net/http"


 "github.com/goproxy/goproxy"
)


func main() {
 http.ListenAndServe("localhost:8080", goproxy.New())
}

This is the dead simple way we are talking about, isn't it?

In addition, Goproxy now supports multiple storage methods:

* Disk: cachers.Disk 

* MinIO: cachers.MinIO 

* Google Cloud Storage: cachers.GCS 

* Amazon Simple Storage Service: cachers.S3 

* Qiniu Cloud Kodo: cachers.Kodo 

* More coming soon...

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9d45fdcc-8826-488c-be5a-b7a7acb70944%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Want to know differance between two code snippets defined here

[Manish Champaneri]

I am try to add routes to mux read from json using for loop

In one code i am directly appending route to mux
In other code I am calling a function which appends route to mux ( mux is 
pass by pointer)

Though both are doing same thing ( As I guess ) output is different.* I am 
curious why this is happening ,*

*This code is working*

func main() {

configLoader()

dispatchMux := http.NewServeMux()

for _, site := range ServerConfigData.Sites {

//Previously code of append function
parsedURL, _ := url.Parse(site.Forward)
fmt.Println(site.Incomming)
dispatchMux.Handle(site.Incomming, 
httputil.NewSingleHostReverseProxy(parsedURL))

}
// Start the server
color.Green("Server Spinned Up on 2096")
http.ListenAndServe(":80", dispatchMux)}


*This code is not working*

func main() {

configLoader()

dispatchMux := http.NewServeMux()

for _, site := range ServerConfigData.Sites {
append(dispatchMux, site.Incomming, site.Forward)
}

// Start the server

color.Green("Server Spinned Up on 2096")
http.ListenAndServe(":2096", dispatchMux)}

 // Route Appender
 func append(mux *http.ServeMux, incomming, forward string) {
color.Yellow("Starting ", incomming, " on ", forward, "\n")
parsedURL, _ := url.Parse(forward)
mux.Handle(incomming, httputil.NewSingleHostReverseProxy(parsedURL))}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/450d1c76-826e-4210-9b27-77e81a03e146%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] make an empty slice

[sasikala tholisam]

test []Exam

type Exam struct{

Time uint32

LogType uint32

Data [32]byte

}

test is a slice of []Exam..It should be an empty slice...how to make test 
as empty?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9354700e-0441-4626-a65e-13eb31171a3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [48]byte should be make to empty

[sasikala tholisam]

test [48]byte make to empty..
How to do 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f5a26feb-8946-415c-9eb3-f80e8da73d3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Memory allocation question

[Conrado P . L . Gouvêa]

The garbage collector won't necessarily run between the functions.

If you add "runtime.GC()" between functions you'll see that the Array
Implementation won't use the heap very much.

There is still some differences, though:

https://play.golang.org/p/aYZAzoCzUM4

Map Implementation

Latency: 0s
Checksum: 4950
Heap: 20.578125 MB
Stack: 0.1875 MB

Array Implementation

Latency: 0s
Checksum: 4950
Heap: 0.1640625 MB
Stack: 8.15625 MB

Preallocated Slice Implementation

Latency: 0s
Checksum: 4950
Heap: 3.9765625 MB
Stack: 4.15625 MB

Slice Implementation

Latency: 0s
Checksum: 4950
Heap: 4.6015625 MB
Stack: 0.1875 MB

Conrado


On Thu, Jun 6, 2019 at 7:48 AM Mark Bauermeister 
wrote:

> Sorry in advance for the somewhat messy code, but this is something I've
> been trying to understand all day and can't quite come up with an
> explanation for.
> Basically, I wrote the below code to experiment with different data types
> and their impact on performance and memory efficiency.
>
> The code itself creates a map, an array, an empty slice and a slice
> already preallocated with the 1,000,000 required integers.
>
> Each data type is being filled with numbers ranging from 0 to 999,999,
> then I output the execution time ("latency") and the memory usage ("Heap"
> and "Stack").
>
> Now here is what I don't quite understand: Why would an array occupy more
> space on the heap and stack than a slice?
>
> Is there an issue in my code or the way I measure heap/stack allocation?
>
>
>
> [image: experiment.png]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> package main
>
> import (
> "fmt"
> "sync"
> "time"
>
> "runtime"
>
> "github.com/fatih/color"
> )
>
> var mu sync.Mutex
> var mem runtime.MemStats
>
> func main() {
> imap()
> iarray()
> ipreSlice()
> islice()
> }
>
> func _green(text string) {
> fmt.Fprintf(color.Output, color.GreenString(text))
> fmt.Println()
> }
>
> func imap() {
> _green("Map Implementation")
> cache := make(map[int]int, 100)
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func iarray() {
> _green("Array Implementation")
> cache := [100]int{}
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func ipreSlice() {
> _green("Preallocated Slice Implementation")
> cache := make([]int, 100)
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func islice() {
> _green("Slice Implementation")
> cache := []int{}
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache = append(cache, i)
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func printHeap() {
> runtime.ReadMemStats()
> fmt.Printf("Heap: %v MB", float64(mem.HeapInuse)/1024/1024)
> fmt.Println()
> }
>
> func printStack() {
> runtime.ReadMemStats()
> fmt.Printf("Stack: %v MB", float64(mem.StackInuse)/1024/1024)
> fmt.Println()
> fmt.Println()
> }
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/07bc3bd3-8c9d-48d9-8a36-7e9e42d79637%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view 

Re: [go-nuts] why need "assist garbage collection" at a GC cycle? (runtime Code)

[fgergo]

Maybe the detail you are looking for is something like this:
https://blog.golang.org/ismmkeynote


On 6/6/19, ding liu  wrote:
> I cann`t find any infomation about "assist garbage collection" with google,
>
> so what`s the purpose of "assist garbage collection"?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9f648a2f-33a2-4097-b503-35ba558f728e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BctqrpMZfBwiYxsHt5E_vFyj2s2yXO32CEdQvMdJN7-LDaHBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Memory allocation question

[fgergo]

To share code please use Share on play.golang.org.
For the rest, please no screenshots, plain text is best.

On 6/6/19, Mark Bauermeister  wrote:
> Sorry in advance for the somewhat messy code, but this is something I've
> been trying to understand all day and can't quite come up with an
> explanation for.
> Basically, I wrote the below code to experiment with different data types
> and their impact on performance and memory efficiency.
>
> The code itself creates a map, an array, an empty slice and a slice already
>
> preallocated with the 1,000,000 required integers.
>
> Each data type is being filled with numbers ranging from 0 to 999,999, then
>
> I output the execution time ("latency") and the memory usage ("Heap" and
> "Stack").
>
> Now here is what I don't quite understand: Why would an array occupy more
> space on the heap and stack than a slice?
>
> Is there an issue in my code or the way I measure heap/stack allocation?
>
>
>
> [image: experiment.png] 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> package main
>
> import (
> "fmt"
> "sync"
> "time"
>
> "runtime"
>
> "github.com/fatih/color"
> )
>
> var mu sync.Mutex
> var mem runtime.MemStats
>
> func main() {
> imap()
> iarray()
> ipreSlice()
> islice()
> }
>
> func _green(text string) {
> fmt.Fprintf(color.Output, color.GreenString(text))
> fmt.Println()
> }
>
> func imap() {
> _green("Map Implementation")
> cache := make(map[int]int, 100)
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func iarray() {
> _green("Array Implementation")
> cache := [100]int{}
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func ipreSlice() {
> _green("Preallocated Slice Implementation")
> cache := make([]int, 100)
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func islice() {
> _green("Slice Implementation")
> cache := []int{}
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache = append(cache, i)
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func printHeap() {
> runtime.ReadMemStats()
> fmt.Printf("Heap: %v MB", float64(mem.HeapInuse)/1024/1024)
> fmt.Println()
> }
>
> func printStack() {
> runtime.ReadMemStats()
> fmt.Printf("Stack: %v MB", float64(mem.StackInuse)/1024/1024)
> fmt.Println()
> fmt.Println()
> }
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/07bc3bd3-8c9d-48d9-8a36-7e9e42d79637%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bctqro8sjMZDMKqiFuq3mRjRG%2BPC%2BtW2iGoLFJ%3DaFz68sGgcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] why need "assist garbage collection" at a GC cycle? (runtime Code)

[ding liu]

I cann`t find any infomation about "assist garbage collection" with google, 
so what`s the purpose of "assist garbage collection"?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9f648a2f-33a2-4097-b503-35ba558f728e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Memory allocation question

[Mark Bauermeister]

Sorry in advance for the somewhat messy code, but this is something I've 
been trying to understand all day and can't quite come up with an 
explanation for.
Basically, I wrote the below code to experiment with different data types 
and their impact on performance and memory efficiency.

The code itself creates a map, an array, an empty slice and a slice already 
preallocated with the 1,000,000 required integers.

Each data type is being filled with numbers ranging from 0 to 999,999, then 
I output the execution time ("latency") and the memory usage ("Heap" and 
"Stack").

Now here is what I don't quite understand: Why would an array occupy more 
space on the heap and stack than a slice?

Is there an issue in my code or the way I measure heap/stack allocation?



[image: experiment.png] 
























package main

import (
"fmt"
"sync"
"time"

"runtime"

"github.com/fatih/color"
)

var mu sync.Mutex
var mem runtime.MemStats

func main() {
imap()
iarray()
ipreSlice()
islice()
}

func _green(text string) {
fmt.Fprintf(color.Output, color.GreenString(text))
fmt.Println()
}

func imap() {
_green("Map Implementation")
cache := make(map[int]int, 100)
start := time.Now()

for i := 0; i < 100; i++ {
mu.Lock()
cache[i] = i
mu.Unlock()
}
end := time.Since(start)
fmt.Printf("Latency: %v \n", end)

var sum int64
for _, v := range cache {
sum += int64(v)
}

fmt.Printf("Checksum: %v \n", sum)
printHeap()
printStack()
}

func iarray() {
_green("Array Implementation")
cache := [100]int{}
start := time.Now()

for i := 0; i < 100; i++ {
mu.Lock()
cache[i] = i
mu.Unlock()
}
end := time.Since(start)
fmt.Printf("Latency: %v \n", end)

var sum int64
for _, v := range cache {
sum += int64(v)
}

fmt.Printf("Checksum: %v \n", sum)
printHeap()
printStack()
}

func ipreSlice() {
_green("Preallocated Slice Implementation")
cache := make([]int, 100)
start := time.Now()

for i := 0; i < 100; i++ {
mu.Lock()
cache[i] = i
mu.Unlock()
}
end := time.Since(start)
fmt.Printf("Latency: %v \n", end)

var sum int64
for _, v := range cache {
sum += int64(v)
}

fmt.Printf("Checksum: %v \n", sum)
printHeap()
printStack()
}

func islice() {
_green("Slice Implementation")
cache := []int{}
start := time.Now()

for i := 0; i < 100; i++ {
mu.Lock()
cache = append(cache, i)
mu.Unlock()
}
end := time.Since(start)
fmt.Printf("Latency: %v \n", end)

var sum int64
for _, v := range cache {
sum += int64(v)
}

fmt.Printf("Checksum: %v \n", sum)
printHeap()
printStack()
}

func printHeap() {
runtime.ReadMemStats()
fmt.Printf("Heap: %v MB", float64(mem.HeapInuse)/1024/1024)
fmt.Println()
}

func printStack() {
runtime.ReadMemStats()
fmt.Printf("Stack: %v MB", float64(mem.StackInuse)/1024/1024)
fmt.Println()
fmt.Println()
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/07bc3bd3-8c9d-48d9-8a36-7e9e42d79637%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

[Elias Naur]

On Thursday, 6 June 2019 00:43:22 UTC+2, dol...@gmail.com wrote:
>
> Him
>
> Source Hut actually requires me to create an account to read the mailing 
> list. Hmph.
>

That's surprising. I went to https://lists.sr.ht/~eliasnaur/gio-dev with a 
private browser session and it showed up fine. The "new post" link also 
worked fine (it's just a mailto: URL).
 

> Anyway, I tried to run it on android and web (don't have wayland), and 
> they work!
> It's just weird to interact within a canvas on the web and not get all the 
> niceties of the classic html controls.
>

Indeed. The webassembly/webgl port is intended for easy porting of an 
existing native app, not as a competitor to the web native controls.
 

> And on android, I can delete characters, but not input any (Samsung Galaxy 
> S8, Android 9)
>
>
Thanks for bringing it up, I've added it to the issue tracker: 
https://todo.sr.ht/~eliasnaur/gio/7. It's not entirely unexpected; I have 
only implemented the very basic parts of the Android and iOS text input 
interfaces.

 - elias

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/96a191b0-bc60-4637-a464-c24ba5cc62ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.