Re: [go-nuts] Re: No Allman-Style, No go!

[Ian Lance Taylor]

On Thu, Jul 27, 2017 at 6:35 PM, Hrobjartur Thorsteinsson
 wrote:
>
> Do you realize that the Go lang devs themselves are not actually in
> agreement about the original motivations for constraining the language in
> this way. Some quote some one true K style, while it is in fact this is
> not K style, other quote some dubious statistics on programmer habbits
> with code blocks, and yet other quote that it's just to help the Go-lang
> compiler meta-compile statement delimiters ";".  All this confusion and
> effort for nothing, and all the while ignoring some real bad programming
> habits, I guess in the name of liberty... or one day they will eventually
> arbitrate what is good and bad in those areas too.
>
> Could it be that Go lang devs created an inflexibility, a storm in a
> tea-cup, for no real good reason. Such things have happened in software
> before.

I doubt there is any significant disagreement among the core Go
developers about the gofmt choices for brace placements.  The reasons
are 1) it doesn't matter, gofmt just has to make a choice; 2) the
choice works well with lexical semicolon insertion.

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

Re: [go-nuts] Is there some way to set value for unexported nil ptr field of a struct using reflect?

[feilengcui008]

Ok, I got that, thanks for the clarification!

在 2017年7月28日星期五 UTC+8上午10:36:20，Matt Harden写道：
>
> Just to be clear, when using unsafe it's possible to do pretty much 
> anything; reflect by itself doesn't give you this ability. That's by design 
> AIUI.
>
> On Wed, Jul 26, 2017 at 6:53 PM feilengcui008  > wrote:
>
>> Thanks for your answer :), even though the original question has been 
>> deleted.
>>
>> I've used the reflect.NewAt to allocate a new memory at the same address 
>> of the unexported field's reflect.Value, it seems work.
>>
>> for unexported not nil field
>>
>> if !v.CanSet() {
>>v = reflect.NewAt(v.Type(), unsafe.Pointer(v.UnsafeAddr())).Elem()
>> }
>>
>>
>> for unexported nil field
>>
>> // since v is nil value, v.Elem() will be zero value
>> // and zero value is not addressable or settable, we
>> // need allocate a new settable v at the same address
>> v = reflect.NewAt(v.Type(), unsafe.Pointer(v.UnsafeAddr())).Elem()
>> newv := reflect.New(v.Type().Elem())
>> v.Set(newv)
>>
>>
>>
>>
>> 在 2017年7月26日星期三 UTC+8上午9:08:50，Ian Lance Taylor写道：
>>
>>> On Sun, Jul 23, 2017 at 12:46 AM, feilengcui008  
>>> wrote: 
>>> > Hi, all: 
>>> > I'm writing a little fuzz tool for struct using reflect package, 
>>> and 
>>> > came across the following case, but didn't find any way to solve it 
>>> > 
>>> > 
>>> > type TestStruct struct { 
>>> > a  *int   // unexported nil ptr field, how to modify it? 
>>> > b  int   // unexported not ptr field, can be modified using 
>>> > reflect.NewAt 
>>> > C  *int  // exported nil ptr field,  can be modified using 
>>> > reflect.New and value.Set 
>>> > } 
>>> > 
>>> > ts :=  {}  // a is nil ptr and not exported 
>>> > fieldA := reflect.ValueOf(ts).Elem().Field(0) 
>>> > // how to modify the value of a using the reflect value fieldA? 
>>>
>>> In general you can not use reflect to set unexported fields.  If that 
>>> were possible, then any package could use reflect to defeat the name 
>>> hiding used by any other package, which would make name hiding much 
>>> less useful. 
>>>
>>> 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...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is there some way to set value for unexported nil ptr field of a struct using reflect?

[Matt Harden]

Just to be clear, when using unsafe it's possible to do pretty much
anything; reflect by itself doesn't give you this ability. That's by design
AIUI.

On Wed, Jul 26, 2017 at 6:53 PM feilengcui008 
wrote:

> Thanks for your answer :), even though the original question has been
> deleted.
>
> I've used the reflect.NewAt to allocate a new memory at the same address
> of the unexported field's reflect.Value, it seems work.
>
> for unexported not nil field
>
> if !v.CanSet() {
>v = reflect.NewAt(v.Type(), unsafe.Pointer(v.UnsafeAddr())).Elem()
> }
>
>
> for unexported nil field
>
> // since v is nil value, v.Elem() will be zero value
> // and zero value is not addressable or settable, we
> // need allocate a new settable v at the same address
> v = reflect.NewAt(v.Type(), unsafe.Pointer(v.UnsafeAddr())).Elem()
> newv := reflect.New(v.Type().Elem())
> v.Set(newv)
>
>
>
>
> 在 2017年7月26日星期三 UTC+8上午9:08:50，Ian Lance Taylor写道：
>
>> On Sun, Jul 23, 2017 at 12:46 AM, feilengcui008 
>> wrote:
>> > Hi, all:
>> > I'm writing a little fuzz tool for struct using reflect package,
>> and
>> > came across the following case, but didn't find any way to solve it
>> >
>> >
>> > type TestStruct struct {
>> > a  *int   // unexported nil ptr field, how to modify it?
>> > b  int   // unexported not ptr field, can be modified using
>> > reflect.NewAt
>> > C  *int  // exported nil ptr field,  can be modified using
>> > reflect.New and value.Set
>> > }
>> >
>> > ts :=  {}  // a is nil ptr and not exported
>> > fieldA := reflect.ValueOf(ts).Elem().Field(0)
>> > // how to modify the value of a using the reflect value fieldA?
>>
>> In general you can not use reflect to set unexported fields.  If that
>> were possible, then any package could use reflect to defeat the name
>> hiding used by any other package, which would make name hiding much
>> less useful.
>>
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[Dan Kortschak]

Lovely post, Michael, as usual.

http://photobucket.com/gallery/user/Clayskater/media/bWVkaWFJZDoxNzA1MjQzMDM=/

I ran out of pop-corn for this thread some years ago. Does anyone know
where I can get some more? It must be butter soaked, cooked over coals
and served in a silver tureen, otherwise I won't touch it.

On Thu, 2017-07-27 at 13:38 -0700, Michael Jones wrote:
> Ecstatic, based on what you said here (*"some people will never be
> forced...

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

Re: [go-nuts] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

This suggestion the funniest I have seen in any language:

/*--*/

if x < 0 {
{
return sqrt(-x) + "i"
}}

/*-*/

Credit is "Neutrino" posted in 2014 on Stackoverflow. This is what I
was looking for!
Thank you Neutrino, both Go-style and Allman style fetished devs can
now live in harmony.


On Fri, Jul 28, 2017 at 2:06 AM, John Souvestre  wrote:

> Cognitive dissonance  J
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> *On Behalf Of *Michael Jones
> *Sent:* 2017 July 27, Thu 15:38
> *To:* Rob Pike
> *Cc:* Ecstatic Coder; golang-nuts
> *Subject:* Re: [go-nuts] Re: No Allman-Style, No go!
>
>
>
> Ecstatic, based on what you said here (*"some people will never be forced
> to change"* and *"because Google engineers have decided"*), I believe
> there are a few ideas you may profitably consider about the formatting
> topic--ideas that you probably have not yet considered and which may ease
> your concerns.
>
>
>
> FIRSTLY, there are probably people who would absolutely refuse to visit
> the United Kingdom because *"they will never be forced to drive on the
> wrong side of the road."* Or perhaps, they would visit, but would drive
> on *"the right side show those silly UK people see how we do it at home."* 
> Some,
> but not many, because most people understand that being in a society of
> people who drive on one side of the road is best embraced by sharing that
> same side. This has nothing to do with anyone's opinion about which side is
> truly and naturally the best and wisest side to drive on. It is instead
> about driving effectively as an ensemble rather than alone as an isolated
> individual.
>
>
>
> As surprising as it may be, this is a very similar to the situation with
> the style gofmt implements (*which side of the road*) and the reason that
> whatever style it is is considered important by other developers (*the
> other drivers*). Now, this is all in the context of more than one
> developer (one car/one driver). If you build a private road at your estate
> than you're surely welcome to drive on either side, down the middle, or
> even to weave back and forth in a sinusoidal pattern. Whatever makes you
> happy. Whatever you see as the "one true way." The idea of fitting in for
> the purpose of mutual survival or efficiency is not at play when you are
> alone.
>
>
>
> Maybe you program alone. Maybe nobody else sees your code. Maybe you do
> not wish to import and examine the code of others nor export code of your
> own. If so, this entire thread is not really meant for you. However...
>
>
>
> SECONDARIALY, one of the most important aspects of being a Google
> [software] engineer is the reality of working in a multi-hundred million
> line source code, with 10,000+ other programmers, and having every line of
> code reviewed by other developers before checkin. (Important, but not
> unique--same at IBM, Oracle, Microsoft, Apple, ...) In this kind of
> professional team development environment, the efficiency of code reuse, of
> quickly understanding the code of others, and of avoiding false source code
> deltas based in stylistic changes is paramount. Google started in a garage,
> but did not stay there. This attention to working as a team, grew with the
> company as it does in other large, effective software teams.
>
>
>
> To the extent that a "common style has been forced because Google
> engineers decided," it is actually the case that "Google engineers were
> forced by scale to accept a common format." Not that they are victims, just
> that like drivers and modern society, they grew weary of needless traffic
> jams, accidents, and injuries. I've travelled very long distances in India,
> for example, where there are often no lane markers on roads and people
> drive on whatever part they like. With such kind people it works well in
> the country, but in the cities where congestion reaches a critical mass, it
> seems to work spectacularly poorly.
>
>
>
> The rigidity that frustrates you is the price of society, of easy code
> review and understanding; it is not, as some presume, a declaration of a
> "best" way to indent. Rather it is an example of a "best way to collaborate
> at scale" which is just the kind of situation where Go intends to solve
> existing problems.
>
>
>
> My views, not Google's.
>
>
>
>
>
>
>
> On Thu, Jul 27, 2017 at 5:34 AM, Rob Pike  wrote:
>
> Very few, though. Very few.
>
>
>
> As the proverb says:
>
>
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
> 
>
>
>
> -rob
>
>
>
>
>
> On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder 
> wrote:
>
> Btw please don't take it personally. What I'm saying is that indeed some
> people (including me as you see) WILL NEVER agree to be forced to change
> their coding style because Google 

RE: [go-nuts] Re: No Allman-Style, No go!

[John Souvestre]

Cognitive dissonance  J

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Michael Jones
Sent: 2017 July 27, Thu 15:38
To: Rob Pike
Cc: Ecstatic Coder; golang-nuts
Subject: Re: [go-nuts] Re: No Allman-Style, No go!

 

Ecstatic, based on what you said here ("some people will never be forced to 
change" and "because Google engineers have decided"), I believe there are a few 
ideas you may profitably consider about the formatting topic--ideas that you 
probably have not yet considered and which may ease your concerns.

 

FIRSTLY, there are probably people who would absolutely refuse to visit the 
United Kingdom because "they will never be forced to drive on the wrong side of 
the road." Or perhaps, they would visit, but would drive on "the right side 
show those silly UK people see how we do it at home." Some, but not many, 
because most people understand that being in a society of people who drive on 
one side of the road is best embraced by sharing that same side. This has 
nothing to do with anyone's opinion about which side is truly and naturally the 
best and wisest side to drive on. It is instead about driving effectively as an 
ensemble rather than alone as an isolated individual.

 

As surprising as it may be, this is a very similar to the situation with the 
style gofmt implements (which side of the road) and the reason that whatever 
style it is is considered important by other developers (the other drivers). 
Now, this is all in the context of more than one developer (one car/one 
driver). If you build a private road at your estate than you're surely welcome 
to drive on either side, down the middle, or even to weave back and forth in a 
sinusoidal pattern. Whatever makes you happy. Whatever you see as the "one true 
way." The idea of fitting in for the purpose of mutual survival or efficiency 
is not at play when you are alone.

 

Maybe you program alone. Maybe nobody else sees your code. Maybe you do not 
wish to import and examine the code of others nor export code of your own. If 
so, this entire thread is not really meant for you. However...

 

SECONDARIALY, one of the most important aspects of being a Google [software] 
engineer is the reality of working in a multi-hundred million line source code, 
with 10,000+ other programmers, and having every line of code reviewed by other 
developers before checkin. (Important, but not unique--same at IBM, Oracle, 
Microsoft, Apple, ...) In this kind of professional team development 
environment, the efficiency of code reuse, of quickly understanding the code of 
others, and of avoiding false source code deltas based in stylistic changes is 
paramount. Google started in a garage, but did not stay there. This attention 
to working as a team, grew with the company as it does in other large, 
effective software teams.

 

To the extent that a "common style has been forced because Google engineers 
decided," it is actually the case that "Google engineers were forced by scale 
to accept a common format." Not that they are victims, just that like drivers 
and modern society, they grew weary of needless traffic jams, accidents, and 
injuries. I've travelled very long distances in India, for example, where there 
are often no lane markers on roads and people drive on whatever part they like. 
With such kind people it works well in the country, but in the cities where 
congestion reaches a critical mass, it seems to work spectacularly poorly.

 

The rigidity that frustrates you is the price of society, of easy code review 
and understanding; it is not, as some presume, a declaration of a "best" way to 
indent. Rather it is an example of a "best way to collaborate at scale" which 
is just the kind of situation where Go intends to solve existing problems.

 

My views, not Google's.

 

 

 

On Thu, Jul 27, 2017 at 5:34 AM, Rob Pike  wrote:

Very few, though. Very few.

 

As the proverb says:

 


  Gofmt's style is no 
one's favorite, yet gofmt is everyone's favorite.


 

-rob

 

 

On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder  
wrote:

Btw please don't take it personally. What I'm saying is that indeed some people 
(including me as you see) WILL NEVER agree to be forced to change their coding 
style because Google engineers have decided so, but that doesn't mean we should 
stay away from go just because of our mental incapacity to agree on that.

 

On Thu, Jul 27, 2017 at 9:32 AM,  wrote:

I don't know if you have read this post above :

"BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)"

Obviously, I don't like AT ALL the K style, to which I prefer the 

Re: [go-nuts] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

That's true, so it would be more useful in C than in Go.
However, please everybody stop calling it K style, because it is not.

On Fri, Jul 28, 2017 at 1:54 AM, John Souvestre  wrote:

> Ø  Btw here are the result of a small internet poll on indentation styles
> :
>
> - Allman : 7450 votes
> - K style : 5514 votes
>
> Ø  …
>
>
>
> I have to wonder if a person’s choice of style might depend on which
> language they are using.  For example, I might prefer Allman while working
> in C but K while working in Go.  The deciding factor being that Go always
> uses a block for if’s, while C (if memory serves) uses either a single
> statement or a block.  Thus, when scanning the code quickly, seeing the
> opening brace doesn’t add any info to my understanding of what takes place
> in Go while it would in C.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> *On Behalf Of *ecstatic.co...@gmail.com
> *Sent:* 2017 July 27, Thu 03:33
> *To:* golang-nuts
> *Cc:* yout...@z505.com
> *Subject:* Re: [go-nuts] Re: No Allman-Style, No go!
>
>
>
> I don't know if you have read this post above :
>
> "BTW, I've just released Genesis, an open source generic preprocessor
> which automatically converts Allman style code into K and allows
> genericity by parametric instantiation.
>
> https://github.com/senselogic/GENESIS
>
> Better late than never... ;)"
>
> Obviously, I don't like AT ALL the K style, to which I prefer the Allman
> style, for not only personal but also OBJECTIVE reasons.
>
> And yet I've learned Go and enjoy a lot to use this language, despite this
> implies using an external tool to add genericity and fix the code
> indentation.
>
> Btw here are the result of a small internet poll on indentation styles :
>
> - Allman : 7450 votes
> - K style : 5514 votes
> - Whitesmith : 455
> - GNU : 422
> - Horstman : 131
> - Pico : 93
> - Banner : 243
>
> (http://www.terminally-incoherent.com/blog/2009/04/
> 10/the-only-correct-indent-style)
>
> Even if these 14000 votes are obviously not enough to reflect the whole
> development community, at least you can see here that many developers
> prefer the Allman style to the K style.
>
> So sorry, but I completely disagree with your advice to stay away from Go
> if you don't like its forced indentation style policy.
>
> It's not only too radical, but also not needed, as there are already tools
> to fix that issue.
>
> On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>
> I propose a new rule for our Code of Conduct: Before posting to the "No
> Allman-Style, No go!" thread, you shall read and understand all previous
> posts in the aforementioned thread.
>
>
>
> Justo to be clear: Go indentation style is a time saver. It was carefuly
> crafted to piss some people off.  As you can see, it works wonders. If
> someone can't handle a simple change in indentation style, then she has no
> business trying to learn Go, so she quits, thus saving time.
>
> --
> 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.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

RE: [go-nuts] Re: No Allman-Style, No go!

[John Souvestre]

Ø  Btw here are the result of a small internet poll on indentation styles :

- Allman : 7450 votes
- K style : 5514 votes

Ø  …

 

I have to wonder if a person’s choice of style might depend on which language 
they are using.  For example, I might prefer Allman while working in C but K 
while working in Go.  The deciding factor being that Go always uses a block for 
if’s, while C (if memory serves) uses either a single statement or a block.  
Thus, when scanning the code quickly, seeing the opening brace doesn’t add any 
info to my understanding of what takes place in Go while it would in C.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of ecstatic.co...@gmail.com
Sent: 2017 July 27, Thu 03:33
To: golang-nuts
Cc: yout...@z505.com
Subject: Re: [go-nuts] Re: No Allman-Style, No go!

 

I don't know if you have read this post above :

"BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)"

Obviously, I don't like AT ALL the K style, to which I prefer the Allman 
style, for not only personal but also OBJECTIVE reasons.

And yet I've learned Go and enjoy a lot to use this language, despite this 
implies using an external tool to add genericity and fix the code indentation.

Btw here are the result of a small internet poll on indentation styles :

- Allman : 7450 votes
- K style : 5514 votes
- Whitesmith : 455
- GNU : 422
- Horstman : 131
- Pico : 93
- Banner : 243

(http://www.terminally-incoherent.com/blog/2009/04/10/the-only-correct-indent-style)

Even if these 14000 votes are obviously not enough to reflect the whole 
development community, at least you can see here that many developers prefer 
the Allman style to the K style.

So sorry, but I completely disagree with your advice to stay away from Go if 
you don't like its forced indentation style policy.

It's not only too radical, but also not needed, as there are already tools to 
fix that issue.

On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:

I propose a new rule for our Code of Conduct: Before posting to the "No 
Allman-Style, No go!" thread, you shall read and understand all previous posts 
in the aforementioned thread.

 

Justo to be clear: Go indentation style is a time saver. It was carefuly 
crafted to piss some people off.  As you can see, it works wonders. If someone 
can't handle a simple change in indentation style, then she has no business 
trying to learn Go, so she quits, thus saving time.

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

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

Re: [go-nuts] No Allman-Style, No go!

[Bakul Shah]

I have to disagree somewhat with me(!). Programming is much more an engineering 
discipline than a creative process. A case in point: the earlier thread today 
about 10x latency spike. If the latency spikes don't meet user expectation (or 
a formal requirement), the program is not "done". Replacing map[int]slice with 
map[int](base, limit) is a tradeoff (one among many). Making such tradeoffs is 
just part of the engineering process.

If your program has to handle a certain level of load, it should be tested with 
such load (or scaled down load that can be extrapolated to full scale) and make 
the changes necessary to achieve that. If it has to have 99.95% uptime, you 
will need redundancy. If it has to quickly recover from a crash without loss of 
data, that may require using atomic transactions. Add security as well! All 
these requirements will change your "beautiful" masterpiece into something 
potentially ugly and boring.

A high level language makes this engineering process easier but you, the 
programmer (team), still have to design, build, test and tweak a solution until 
it meets your requirements; you can't expect the compiler to do all the heavy 
lifting (which is almost always specific to a problem).

You can still employ your skill and creativity in fit & finish and design & 
clarity of your code and occasionally coming up with a brilliant new algorithm. 
None of that will be stifled just because you can't format your Go code in your 
favorite C style!

> On Jul 27, 2017, at 3:40 PM, me  wrote:
> 
> As for comparing programming to driving on the road: Okay but programming is 
> and extremely creative effort, sort of like writing a novel with mathematics 
> in it. The argument is that you take away people's creativity, with tools 
> like GoFmt, in the same way forcing a super creative person to write a poem a 
> certain way, or forcing someone to use a certain style of mathematics in a 
> paper (which, could be a good thing depending on the case - but if it is a 
> really creative looney mathematician, you will want him to write like a wild 
> stallion, free as can be and let him create his masterpiece) 

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

Re: [go-nuts] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

but, I have to say, wow,
I never realized that curly bracket placement was that important and solved
so many of the problems for Google!

Do you realize that the Go lang devs themselves are not actually in
agreement about the original motivations for constraining the language in
this way. Some quote some one true K style, while it is in fact this is
not K style, other quote some dubious statistics on programmer habbits
with code blocks, and yet other quote that it's just to help the Go-lang
compiler meta-compile statement delimiters ";".  All this confusion and
effort for nothing, and all the while ignoring some real bad programming
habits, I guess in the name of liberty... or one day they will eventually
arbitrate what is good and bad in those areas too.

Could it be that Go lang devs created an inflexibility, a storm in a
tea-cup, for no real good reason. Such things have happened in software
before.

On Fri, Jul 28, 2017 at 12:19 AM, Matt Harden  wrote:

> "me": regarding purely functional programs, they can exist, but they can't
> actually "do" anything, since by definition, "doing" means altering some
> state in the outside world. But reasoning as much as possible in a
> functional way, and expressing your programs in this way (again as much as
> possible), turns out to be very effective, because reasoning about a
> virtually limitless amount of shared state is extraordinarily difficult,
> especially in a concurrent program.
>
> Your argument about the super creative programmer may be valid when you're
> talking about a single programmer. Good luck getting that programmer to
> operate as part of a team, especially if you expect everyone else on the
> team to behave the same way, *especially* if it is a large team. Even if
> they create their masterpiece in solitude, they're certain to tire of it
> later and leave it to someone else to maintain. Luckily we have gofmt, so
> we can reformat it when the team takes over, and they can effectively
> cooperate to maintain and improve the code. The maestro will gnash his
> teeth at this, but they will have more important things to work on by that
> point.
>
> Even the best, most creative architects must operate within bounds -
> buildings need to be safe; they need to satisfy government regulations;
> they need to be made using existing materials.
>
> Anyway, style has nothing to do with the actual program *content*. We're
> talking about elements that don't affect the behavior of the program. As
> has been pointed out, your super-creative programmer can write their own
> tool (in whatever style or language they want!) to translate programs from
> gofmt-formatted to their preferred style. Nobody even needs to know!
>
> On Thu, Jul 27, 2017 at 3:40 PM me  wrote:
>
>>
>> On Thursday, July 27, 2017 at 3:08:08 PM UTC-6, Jan Mercl wrote:
>>>
>>>
>>> Isn't it strange, that we, programmers, well used to model the problem
>>> once in term of CPU registers and raw memory, then in a pure functional
>>> style
>>>
>>
>> I don't know that purely functional actually exists: I have been trying
>> to crack this problem for ages: what exactly is pure functional?
>> As soon as a functional program has state (a println/print/puts statement
>> is the first warning), it is no longer purely functional IMO..
>>
>> But, it's a little off topic for this list... still, some functional
>> programming techniques exist in all programming languages, so still on
>> topic to some extent.
>>
>> As for comparing programming to driving on the road: Okay but programming
>> is and extremely creative effort, sort of like writing a novel with
>> mathematics in it. The argument is that you take away people's creativity,
>> with tools like GoFmt, in the same way forcing a super creative person to
>> write a poem a certain way, or forcing someone to use a certain style of
>> mathematics in a paper (which, could be a good thing depending on the case
>> - but if it is a really creative looney mathematician, you will want him to
>> write like a wild stallion, free as can be and let him create his
>> masterpiece)
>>
>> Still I like GoFmt - always provide a contrarian position
>>
>> --
>> 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.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 

Re: [go-nuts] Re: No Allman-Style, No go!

[Matt Harden]

"me": regarding purely functional programs, they can exist, but they can't
actually "do" anything, since by definition, "doing" means altering some
state in the outside world. But reasoning as much as possible in a
functional way, and expressing your programs in this way (again as much as
possible), turns out to be very effective, because reasoning about a
virtually limitless amount of shared state is extraordinarily difficult,
especially in a concurrent program.

Your argument about the super creative programmer may be valid when you're
talking about a single programmer. Good luck getting that programmer to
operate as part of a team, especially if you expect everyone else on the
team to behave the same way, *especially* if it is a large team. Even if
they create their masterpiece in solitude, they're certain to tire of it
later and leave it to someone else to maintain. Luckily we have gofmt, so
we can reformat it when the team takes over, and they can effectively
cooperate to maintain and improve the code. The maestro will gnash his
teeth at this, but they will have more important things to work on by that
point.

Even the best, most creative architects must operate within bounds -
buildings need to be safe; they need to satisfy government regulations;
they need to be made using existing materials.

Anyway, style has nothing to do with the actual program *content*. We're
talking about elements that don't affect the behavior of the program. As
has been pointed out, your super-creative programmer can write their own
tool (in whatever style or language they want!) to translate programs from
gofmt-formatted to their preferred style. Nobody even needs to know!

On Thu, Jul 27, 2017 at 3:40 PM me  wrote:

>
> On Thursday, July 27, 2017 at 3:08:08 PM UTC-6, Jan Mercl wrote:
>>
>>
>> Isn't it strange, that we, programmers, well used to model the problem
>> once in term of CPU registers and raw memory, then in a pure functional
>> style
>>
>
> I don't know that purely functional actually exists: I have been trying to
> crack this problem for ages: what exactly is pure functional?
> As soon as a functional program has state (a println/print/puts statement
> is the first warning), it is no longer purely functional IMO..
>
> But, it's a little off topic for this list... still, some functional
> programming techniques exist in all programming languages, so still on
> topic to some extent.
>
> As for comparing programming to driving on the road: Okay but programming
> is and extremely creative effort, sort of like writing a novel with
> mathematics in it. The argument is that you take away people's creativity,
> with tools like GoFmt, in the same way forcing a super creative person to
> write a poem a certain way, or forcing someone to use a certain style of
> mathematics in a paper (which, could be a good thing depending on the case
> - but if it is a really creative looney mathematician, you will want him to
> write like a wild stallion, free as can be and let him create his
> masterpiece)
>
> Still I like GoFmt - always provide a contrarian position
>
> --
> 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.
>

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

Re: [go-nuts] Re: No Allman-Style, No go!

[me]

On Thursday, July 27, 2017 at 3:08:08 PM UTC-6, Jan Mercl wrote:
>
>
> Isn't it strange, that we, programmers, well used to model the problem 
> once in term of CPU registers and raw memory, then in a pure functional 
> style 
>

I don't know that purely functional actually exists: I have been trying to 
crack this problem for ages: what exactly is pure functional?
As soon as a functional program has state (a println/print/puts statement 
is the first warning), it is no longer purely functional IMO..

But, it's a little off topic for this list... still, some functional 
programming techniques exist in all programming languages, so still on 
topic to some extent.

As for comparing programming to driving on the road: Okay but programming 
is and extremely creative effort, sort of like writing a novel with 
mathematics in it. The argument is that you take away people's creativity, 
with tools like GoFmt, in the same way forcing a super creative person to 
write a poem a certain way, or forcing someone to use a certain style of 
mathematics in a paper (which, could be a good thing depending on the case 
- but if it is a really creative looney mathematician, you will want him to 
write like a wild stallion, free as can be and let him create his 
masterpiece) 

Still I like GoFmt - always provide a contrarian position 

-- 
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] gopacket, libpcap timestamp precison

[Chun Zhang]

Hi, All,

I am trying to write a small program to sniff packets off the wire. These 
packets are most TCP flows, so I'd expect SYN arrives earlier than SYN-ACK, 
ACK etc. 

I used gopacket and basically followed the official guide to get the packet 
and then read its metadata for timing. But to my surprise, there were a few 
SYN-ACKs arrived before the SYNs, which did not make any sense. I used only 
one goroutine, and locked it to os thread. 

Then I tried tcpdump and checked the pcap, same thing happened, even though 
much less abnormalities showed up. 

As far as my understanding goes, the packet is timestamped when it is read 
off the wire, so, when the following line is executed, the packet is 
already timestamped and decoded

packet, err := packetSource.NextPacket()



That seems to suggest that libpcap is ultimately the one that is 
responsible for the stamping. If things go wrong, then most likely it is 
libpcap or something between libdpi and the above line. But given that 
tcpdump also has the same issue, I feel that libpcap is more suspicious. 

The only other suspect is that I enabled lazy and NoCopy option for the 
packetSource, not sure whether that plays a role here.

So, the question is anybody has encountered this issue? If so, have you 
tried to improve its timing accuracy? Is there anything else that I can do 
to remedy the issue? Even though the host machine is multi-core, 
muti-thread, but I have locked the reading goroutine to one particular 
os.thread, so technically, that should not be a factor anymore, correct?

PS: I have used IXIA to capture the packets, and there were no out-of-order 
SYN and SYN-ACK. So the device is reliably sending these packets up. 

Thanks,
Chun

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

Re: [go-nuts] Re: No Allman-Style, No go!

[ojucie]

Ecstatic Coder, I won't take it personally, of course. Feel free to say 
anything you want to.

Michael, great post, as always. The driver illustration is perfect.

On Thursday, July 27, 2017 at 5:50:05 AM UTC-3, Ecstatic Coder wrote:
>
> Btw please don't take it personally. 
>

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

Re: [go-nuts] Re: No Allman-Style, No go!

[Jan Mercl]

On Thu, Jul 27, 2017 at 10:39 PM Michael Jones 
wrote:

> Ecstatic, ...

Excellent post!

Isn't it strange, that we, programmers, well used to model the problem once
in term of CPU registers and raw memory, then in a pure functional style
and then again in some imperative PL, to name just a few cases, can
sometime become so inflexible when it comes to such a minor detail as
indentation style? Even just the different grammars of different languages
are in orders of magnitude more complex to switch between - but we are
nearly universally able to do that almost instantly.


-- 

-j

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

Re: [go-nuts] Re: No Allman-Style, No go!

[Michael Jones]

Ecstatic, based on what you said here (*"some people will never be forced
to change"* and *"because Google engineers have decided"*), I believe there
are a few ideas you may profitably consider about the formatting
topic--ideas that you probably have not yet considered and which may ease
your concerns.

FIRSTLY, there are probably people who would absolutely refuse to visit the
United Kingdom because *"they will never be forced to drive on the wrong
side of the road."* Or perhaps, they would visit, but would drive on *"the
right side show those silly UK people see how we do it at home."* Some, but
not many, because most people understand that being in a society of people
who drive on one side of the road is best embraced by sharing that same
side. This has nothing to do with anyone's opinion about which side is
truly and naturally the best and wisest side to drive on. It is instead
about driving effectively as an ensemble rather than alone as an isolated
individual.

As surprising as it may be, this is a very similar to the situation with
the style gofmt implements (*which side of the road*) and the reason that
whatever style it is is considered important by other developers (*the
other drivers*). Now, this is all in the context of more than one developer
(one car/one driver). If you build a private road at your estate than
you're surely welcome to drive on either side, down the middle, or even to
weave back and forth in a sinusoidal pattern. Whatever makes you happy.
Whatever you see as the "one true way." The idea of fitting in for the
purpose of mutual survival or efficiency is not at play when you are alone.

Maybe you program alone. Maybe nobody else sees your code. Maybe you do not
wish to import and examine the code of others nor export code of your own.
If so, this entire thread is not really meant for you. However...

SECONDARIALY, one of the most important aspects of being a Google
[software] engineer is the reality of working in a multi-hundred million
line source code, with 10,000+ other programmers, and having every line of
code reviewed by other developers before checkin. (Important, but not
unique--same at IBM, Oracle, Microsoft, Apple, ...) In this kind of
professional team development environment, the efficiency of code reuse, of
quickly understanding the code of others, and of avoiding false source code
deltas based in stylistic changes is paramount. Google started in a garage,
but did not stay there. This attention to working as a team, grew with the
company as it does in other large, effective software teams.

To the extent that a "common style has been forced because Google engineers
decided," it is actually the case that "Google engineers were forced by
scale to accept a common format." Not that they are victims, just that like
drivers and modern society, they grew weary of needless traffic jams,
accidents, and injuries. I've travelled very long distances in India, for
example, where there are often no lane markers on roads and people drive on
whatever part they like. With such kind people it works well in the
country, but in the cities where congestion reaches a critical mass, it
seems to work spectacularly poorly.

The rigidity that frustrates you is the price of society, of easy code
review and understanding; it is not, as some presume, a declaration of a
"best" way to indent. Rather it is an example of a "best way to collaborate
at scale" which is just the kind of situation where Go intends to solve
existing problems.

My views, not Google's.



On Thu, Jul 27, 2017 at 5:34 AM, Rob Pike  wrote:

> Very few, though. Very few.
>
> As the proverb says:
>
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
> 
>
> -rob
>
>
> On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder 
> wrote:
>
>> Btw please don't take it personally. What I'm saying is that indeed some
>> people (including me as you see) WILL NEVER agree to be forced to change
>> their coding style because Google engineers have decided so, but that
>> doesn't mean we should stay away from go just because of our mental
>> incapacity to agree on that.
>>
>> On Thu, Jul 27, 2017 at 9:32 AM,  wrote:
>>
>>> I don't know if you have read this post above :
>>>
>>> "BTW, I've just released Genesis, an open source generic preprocessor
>>> which automatically converts Allman style code into K and allows
>>> genericity by parametric instantiation.
>>>
>>> https://github.com/senselogic/GENESIS
>>>
>>> Better late than never... ;)"
>>>
>>> Obviously, I don't like AT ALL the K style, to which I prefer the
>>> Allman style, for not only personal but also OBJECTIVE reasons.
>>>
>>> And yet I've learned Go and enjoy a lot to use this language, despite
>>> this implies using an external tool to add genericity and fix the code
>>> indentation.
>>>
>>> Btw here are the result of a small internet poll on 

Re: [go-nuts] 10x latency spikes during GC alloc assist phase

[Joe Taber]

True. With my suggestion the mark phase would still scan the whole map, but 
the sweep phase would become trivial.

It seems there has been some discussion in the past about this specific 
issue (storing millions of slice-like objects in maps). These are old 
threads (2014-15) so the conclusions might not be 100% applicable, but they 
seem to support your thought that a custom map would be best.

[closed] runtime: Large maps cause significant GC pauses [1]
GC pauses with large map[string]string [2]

[1]: https://github.com/golang/go/issues/9477
[2]: 
https://groups.google.com/forum/#!msg/golang-nuts/baU4PZFyBQQ/fCzQelfmbNYJ

Anyway, it looks like the discussion has moved to the github issue, so I'll 
leave it for now.

On Thursday, July 27, 2017 at 1:13:34 PM UTC-5, Bakul Shah wrote:
>
> It would still need to examine all those 50 million slices even if they 
> are all pointing to the same array.
>
> On Jul 27, 2017, at 10:20 AM, Joe Taber  
> wrote:
>
> Bakul,
>
> You wouldn't even need to change the slicing semantics like that.
>
> Just concatenate all slices in the map into one master slice, then take 
> capacity-slices[1] of it with the right offsets to rebuild the whole map. 
> This wouldn't change the semantics of accessing or changing the map at all: 
> trimming a slice in one map entry would just skip some elements in the 
> master slice, and appending elements would use up that unused space until 
> it ran into the next slice boundary at which point it would create a new 
> allocation for that map entry. Then like you said do a custom "gc" step to 
> rebuild that map into a single big allocation every once in a while.
>
> Again, this could only work if the map and map entries grow infrequently, 
> which sounds plausible based on Steve's description of their use.
>
> [1]: 
> https://docs.google.com/document/d/1GKKdiGYAghXRxC2BFrSEbHBZZgAGKQ-yXK-hRKBo0Kk/pub
>
> Joe
>
> On Thursday, July 27, 2017 at 11:39:41 AM UTC-5, Bakul Shah wrote:
>>
>> You're storing millions of slices. A slice is implemented as (ptr, 
>> length, capacity). If your maps are mostly static, may be you can use one 
>> giant array for each value type and just store (offset, length) or (base, 
>> limit) in your maps and in effect do your own slicing? Now to access a 
>> slice, you'd have to replace e.g. myoldmap[key] with mynewmap.Get(key) that 
>> converts offset, length into a slice. If values do get added or deleted 
>> once in a while, you can do an occasional background GC by creating a new 
>> map indexing into a new array, copying active contents from the old array 
>> into new and then atomically switch the map. If values change, things can 
>> get a bit trickier but you can convert a "change" into add new slice+delete 
>> old slice.
>>
>> On Jul 24, 2017, at 4:45 PM, stb...@laserlike.com wrote:
>>
>> Hi,
>>
>> We are experiencing a problem that I believe may be related to issue 
>> 14812  but I wanted to ask 
>> here before adding to that case or filing a new issue. Of course, we’d also 
>> greatly appreciate any advice about how to make our program performant.
>>
>> Here is what we observe: at Laserlike one of our core user-facing 
>> services (the “leaf”) typically responds to a particular rpc in <400ms. 
>>  During GC we see spikes in latency to >5s on some simple requests.  The 
>> stop the world periods are short, so the GC spikes appear to happen at 
>> other times.
>>
>> We have been unable to replicate this in a simple program, but we did run 
>> our code in a test mode that repros it.  In our test environment the server 
>> loads ~10 GB of persistent data (never deleted so doesn’t really need to be 
>> GCed), and we ask for 8 processors.  We are running go version 1.8.3 on 
>> kubernetes on GCP machine of type n1-highmem-64.  To create the problem we 
>> send the server a single request with >500 tasks..
>>
>>
>> This google drive folder has leaf-logs-full.redacted.txt as well as other 
>> performance tooling files 
>> .
>>  
>>  A snippet from that log here shows normal query responses and timing:
>>
>> I0719 22:50:22.467367 leaf.go:363] Worker #5 done search for 
>> '[redacted]', took 0.013 seconds
>>
>> I0719 22:50:22.467406 leaf.go:225] Worker #5 starting search for 
>> '[redacted]'
>>
>> I0719 22:50:22.467486 leaf.go:363] Worker #6 done search for 
>> '[redacted]', took 0.001 seconds
>>
>> I0719 22:50:22.467520 leaf.go:225] Worker #6 starting search for 
>> '[redacted]'
>>
>> I0719 22:50:22.468050 leaf.go:363] Worker #9 done search for 
>> '[redacted]', took 0.005 seconds
>>
>>
>> We have observed that if a GC cycle happens to start while serving 
>> traffic (which is often) AND there is a large amount of time spent in 
>> assist, then our serving latency skyrockets by 10x.  In the log the 
>> slowdown commences roughly when pacer assist starts at I0719 
>> 

Re: [go-nuts] 10x latency spikes during GC alloc assist phase

[Bakul Shah]

It would still need to examine all those 50 million slices even if they are all 
pointing to the same array.

> On Jul 27, 2017, at 10:20 AM, Joe Taber  wrote:
> 
> Bakul,
> 
> You wouldn't even need to change the slicing semantics like that.
> 
> Just concatenate all slices in the map into one master slice, then take 
> capacity-slices[1] of it with the right offsets to rebuild the whole map. 
> This wouldn't change the semantics of accessing or changing the map at all: 
> trimming a slice in one map entry would just skip some elements in the master 
> slice, and appending elements would use up that unused space until it ran 
> into the next slice boundary at which point it would create a new allocation 
> for that map entry. Then like you said do a custom "gc" step to rebuild that 
> map into a single big allocation every once in a while.
> 
> Again, this could only work if the map and map entries grow infrequently, 
> which sounds plausible based on Steve's description of their use.
> 
> [1]: 
> https://docs.google.com/document/d/1GKKdiGYAghXRxC2BFrSEbHBZZgAGKQ-yXK-hRKBo0Kk/pub
> 
> Joe
> 
>> On Thursday, July 27, 2017 at 11:39:41 AM UTC-5, Bakul Shah wrote:
>> You're storing millions of slices. A slice is implemented as (ptr, length, 
>> capacity). If your maps are mostly static, may be you can use one giant 
>> array for each value type and just store (offset, length) or (base, limit) 
>> in your maps and in effect do your own slicing? Now to access a slice, you'd 
>> have to replace e.g. myoldmap[key] with mynewmap.Get(key) that converts 
>> offset, length into a slice. If values do get added or deleted once in a 
>> while, you can do an occasional background GC by creating a new map indexing 
>> into a new array, copying active contents from the old array into new and 
>> then atomically switch the map. If values change, things can get a bit 
>> trickier but you can convert a "change" into add new slice+delete old slice.
>> 
>>> On Jul 24, 2017, at 4:45 PM, stb...@laserlike.com wrote:
>>> 
>>> Hi,
>>> We are experiencing a problem that I believe may be related to issue 14812 
>>> but I wanted to ask here before adding to that case or filing a new issue. 
>>> Of course, we’d also greatly appreciate any advice about how to make our 
>>> program performant.
>>> 
>>> Here is what we observe: at Laserlike one of our core user-facing services 
>>> (the “leaf”) typically responds to a particular rpc in <400ms.  During GC 
>>> we see spikes in latency to >5s on some simple requests.  The stop the 
>>> world periods are short, so the GC spikes appear to happen at other times.
>>> 
>>> We have been unable to replicate this in a simple program, but we did run 
>>> our code in a test mode that repros it.  In our test environment the server 
>>> loads ~10 GB of persistent data (never deleted so doesn’t really need to be 
>>> GCed), and we ask for 8 processors.  We are running go version 1.8.3 on 
>>> kubernetes on GCP machine of type n1-highmem-64.  To create the problem we 
>>> send the server a single request with >500 tasks..
>>> 
>>> 
>>> This google drive folder has leaf-logs-full.redacted.txt as well as other 
>>> performance tooling files.  A snippet from that log here shows normal query 
>>> responses and timing:
>>> 
>>> I0719 22:50:22.467367 leaf.go:363] Worker #5 done search for '[redacted]', 
>>> took 0.013 seconds
>>> I0719 22:50:22.467406 leaf.go:225] Worker #5 starting search for 
>>> '[redacted]'
>>> I0719 22:50:22.467486 leaf.go:363] Worker #6 done search for '[redacted]', 
>>> took 0.001 seconds
>>> I0719 22:50:22.467520 leaf.go:225] Worker #6 starting search for 
>>> '[redacted]'
>>> I0719 22:50:22.468050 leaf.go:363] Worker #9 done search for '[redacted]', 
>>> took 0.005 seconds
>>> 
>>> 
>>> We have observed that if a GC cycle happens to start while serving traffic 
>>> (which is often) AND there is a large amount of time spent in assist, then 
>>> our serving latency skyrockets by 10x.  In the log the slowdown commences 
>>> roughly when pacer assist starts at I0719 22:50:31.079283 and then reverts 
>>> to normal latencies shortly after the gc cycle completes at I0719 
>>> 22:50:36.806085.
>>> 
>>> Below I copy parts of the log where we see latencies of up to 729ms on 
>>> tasks.  I also bold the line that shows 32929ms spent on alloc gc assist.
>>> 
>>> We have captured an attached cpu profile during this time which seems to 
>>> confirm a large amount of time spent in runtime.gcAssistAlloc.func1.
>>> 
>>> 
>>> Pardon our ignorance about GC in golang, but our hypothesis about what may 
>>> be going wrong is that our large in-memory data structures are causing gc 
>>> to often go into assist mode, and that for reasons we don’t understand 
>>> malloc becomes expensive in that mode.  Since we also create ~100k new data 
>>> objects when processing user requests, we are guessing those allocs become 
>>> very slow.  Another piece of evidence for this hypothesis is that we 

Re: [go-nuts] Alternative to reflect.DeepEqual that considers "shape" of cycles?

[Julian Andres Klode]

On Thu, Jul 27, 2017 at 09:36:31AM -0700, howardcs...@gmail.com wrote:
> https://golang.org/pkg/reflect/#DeepEqual
> 
> "Pointer values are deeply equal if they are equal using Go's == operator 
> or if they point to deeply equal values."
> 
> By the rules described here, the fact that both pointers have the same 
> value means it does not even NEED to check what they point to, so I don't 
> think it ever even sees the cycle.

You are right about that, but that's a vastly simplified example
to show the basic idea of what I'm talking about. In reality, there
are no common components.

> 
> So yeah, you would have to write your own implementation, or find one.

It's actually easy to do: You simply number the nodes, or well, the
memory locations being pointed to:

type state struct {
lhsm, rhsm map[interface{}] int
lhsc, rhsc int
}

Algorithm for comparing two pointers.

if lhsm[left side pointer] == 0 {
lhsc++  // First counter is 1.
lhsm[left side pointer] = lhsc
}
... same for right ...
return lhsm[left side ptr] == rhsm[right side ptr]

Obviously you still have to do the recursion.

I guess I should try to write that.
-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] 10x latency spikes during GC alloc assist phase

[Joe Taber]

Bakul,

You wouldn't even need to change the slicing semantics like that.

Just concatenate all slices in the map into one master slice, then take 
capacity-slices[1] of it with the right offsets to rebuild the whole map. 
This wouldn't change the semantics of accessing or changing the map at all: 
trimming a slice in one map entry would just skip some elements in the 
master slice, and appending elements would use up that unused space until 
it ran into the next slice boundary at which point it would create a new 
allocation for that map entry. Then like you said do a custom "gc" step to 
rebuild that map into a single big allocation every once in a while.

Again, this could only work if the map and map entries grow infrequently, 
which sounds plausible based on Steve's description of their use.

[1]: 
https://docs.google.com/document/d/1GKKdiGYAghXRxC2BFrSEbHBZZgAGKQ-yXK-hRKBo0Kk/pub

Joe

On Thursday, July 27, 2017 at 11:39:41 AM UTC-5, Bakul Shah wrote:
>
> You're storing millions of slices. A slice is implemented as (ptr, length, 
> capacity). If your maps are mostly static, may be you can use one giant 
> array for each value type and just store (offset, length) or (base, limit) 
> in your maps and in effect do your own slicing? Now to access a slice, 
> you'd have to replace e.g. myoldmap[key] with mynewmap.Get(key) that 
> converts offset, length into a slice. If values do get added or deleted 
> once in a while, you can do an occasional background GC by creating a new 
> map indexing into a new array, copying active contents from the old array 
> into new and then atomically switch the map. If values change, things can 
> get a bit trickier but you can convert a "change" into add new slice+delete 
> old slice.
>
> On Jul 24, 2017, at 4:45 PM, stb...@laserlike.com  wrote:
>
> Hi,
>
> We are experiencing a problem that I believe may be related to issue 14812 
>  but I wanted to ask here 
> before adding to that case or filing a new issue. Of course, we’d also 
> greatly appreciate any advice about how to make our program performant.
>
> Here is what we observe: at Laserlike one of our core user-facing services 
> (the “leaf”) typically responds to a particular rpc in <400ms.  During GC 
> we see spikes in latency to >5s on some simple requests.  The stop the 
> world periods are short, so the GC spikes appear to happen at other times.
>
> We have been unable to replicate this in a simple program, but we did run 
> our code in a test mode that repros it.  In our test environment the server 
> loads ~10 GB of persistent data (never deleted so doesn’t really need to be 
> GCed), and we ask for 8 processors.  We are running go version 1.8.3 on 
> kubernetes on GCP machine of type n1-highmem-64.  To create the problem we 
> send the server a single request with >500 tasks..
>
>
> This google drive folder has leaf-logs-full.redacted.txt as well as other 
> performance tooling files 
> .
>  
>  A snippet from that log here shows normal query responses and timing:
>
> I0719 22:50:22.467367 leaf.go:363] Worker #5 done search for '[redacted]', 
> took 0.013 seconds
>
> I0719 22:50:22.467406 leaf.go:225] Worker #5 starting search for 
> '[redacted]'
>
> I0719 22:50:22.467486 leaf.go:363] Worker #6 done search for '[redacted]', 
> took 0.001 seconds
>
> I0719 22:50:22.467520 leaf.go:225] Worker #6 starting search for 
> '[redacted]'
>
> I0719 22:50:22.468050 leaf.go:363] Worker #9 done search for '[redacted]', 
> took 0.005 seconds
>
>
> We have observed that if a GC cycle happens to start while serving traffic 
> (which is often) AND there is a large amount of time spent in assist, then 
> our serving latency skyrockets by 10x.  In the log the slowdown commences 
> roughly when pacer assist starts at I0719 22:50:31.079283 and then reverts 
> to normal latencies shortly after the gc cycle completes at I0719 
> 22:50:36.806085.
>
> Below I copy parts of the log where we see latencies of up to 729ms on 
> tasks.  I also bold the line that shows 32929ms spent on alloc gc assist.
>
> We have captured an attached cpu profile during this time which seems to 
> confirm a large amount of time spent in runtime.gcAssistAlloc.func1.
>
>
> Pardon our ignorance about GC in golang, but our hypothesis about what may 
> be going wrong is that our large in-memory data structures are causing gc 
> to often go into assist mode, and that for reasons we don’t understand 
> malloc becomes expensive in that mode.  Since we also create ~100k new data 
> objects when processing user requests, we are guessing those allocs become 
> very slow.  Another piece of evidence for this hypothesis is that we have 
> another (prototype) implementation of this kind of service that makes more 
> use of object pools and doesn’t seem to have as much of slowdown during GC.
>
> Note on large in-memory data-structures:
>
> The 

Re: [go-nuts] 10x latency spikes during GC alloc assist phase

[Bakul Shah]

You're storing millions of slices. A slice is implemented as (ptr, length, 
capacity). If your maps are mostly static, may be you can use one giant array 
for each value type and just store (offset, length) or (base, limit) in your 
maps and in effect do your own slicing? Now to access a slice, you'd have to 
replace e.g. myoldmap[key] with mynewmap.Get(key) that converts offset, length 
into a slice. If values do get added or deleted once in a while, you can do an 
occasional background GC by creating a new map indexing into a new array, 
copying active contents from the old array into new and then atomically switch 
the map. If values change, things can get a bit trickier but you can convert a 
"change" into add new slice+delete old slice.

> On Jul 24, 2017, at 4:45 PM, stba...@laserlike.com wrote:
> 
> Hi,
> We are experiencing a problem that I believe may be related to issue 14812 
> but I wanted to ask here before adding to that case or filing a new issue. Of 
> course, we’d also greatly appreciate any advice about how to make our program 
> performant.
> 
> Here is what we observe: at Laserlike one of our core user-facing services 
> (the “leaf”) typically responds to a particular rpc in <400ms.  During GC we 
> see spikes in latency to >5s on some simple requests.  The stop the world 
> periods are short, so the GC spikes appear to happen at other times.
> 
> We have been unable to replicate this in a simple program, but we did run our 
> code in a test mode that repros it.  In our test environment the server loads 
> ~10 GB of persistent data (never deleted so doesn’t really need to be GCed), 
> and we ask for 8 processors.  We are running go version 1.8.3 on kubernetes 
> on GCP machine of type n1-highmem-64.  To create the problem we send the 
> server a single request with >500 tasks..
> 
> 
> This google drive folder has leaf-logs-full.redacted.txt as well as other 
> performance tooling files.  A snippet from that log here shows normal query 
> responses and timing:
> 
> I0719 22:50:22.467367 leaf.go:363] Worker #5 done search for '[redacted]', 
> took 0.013 seconds
> I0719 22:50:22.467406 leaf.go:225] Worker #5 starting search for '[redacted]'
> I0719 22:50:22.467486 leaf.go:363] Worker #6 done search for '[redacted]', 
> took 0.001 seconds
> I0719 22:50:22.467520 leaf.go:225] Worker #6 starting search for '[redacted]'
> I0719 22:50:22.468050 leaf.go:363] Worker #9 done search for '[redacted]', 
> took 0.005 seconds
> 
> 
> We have observed that if a GC cycle happens to start while serving traffic 
> (which is often) AND there is a large amount of time spent in assist, then 
> our serving latency skyrockets by 10x.  In the log the slowdown commences 
> roughly when pacer assist starts at I0719 22:50:31.079283 and then reverts to 
> normal latencies shortly after the gc cycle completes at I0719 
> 22:50:36.806085.
> 
> Below I copy parts of the log where we see latencies of up to 729ms on tasks. 
>  I also bold the line that shows 32929ms spent on alloc gc assist.
> 
> We have captured an attached cpu profile during this time which seems to 
> confirm a large amount of time spent in runtime.gcAssistAlloc.func1.
> 
> 
> Pardon our ignorance about GC in golang, but our hypothesis about what may be 
> going wrong is that our large in-memory data structures are causing gc to 
> often go into assist mode, and that for reasons we don’t understand malloc 
> becomes expensive in that mode.  Since we also create ~100k new data objects 
> when processing user requests, we are guessing those allocs become very slow. 
>  Another piece of evidence for this hypothesis is that we have another 
> (prototype) implementation of this kind of service that makes more use of 
> object pools and doesn’t seem to have as much of slowdown during GC.
> 
> Note on large in-memory data-structures:
> The principal data structures can be thought of as:
> Map[uint64][]byte (about 10M map entries, the slice lengths between 5K to 
> 50K) (around ~10G total memory usage) 
> Map[uint64][]uint64 (about 50M map entries, the slice lengths vary between 10 
> and 100K, in a zipfian distribution, about 3G total memory usage)
> These data structures mostly stay as is over the life of the program.
> 
> We are trying to figure out how to solve this so would appreciate any advice. 
> An engineer on our team wrote up the following ideas, none of which are that 
> great:
> Figure out a simple way to prevent our goroutines slowing down during GC.  I 
> had some hopes LockOSThread() could be made to work, but it didn't seem to 
> help in my experiments.  I'm not ruling this solution out entirely, but if 
> it's the write barriers that are the main problem, I don't have much hope.
> Run at least 2 replicas of all our servers.  Manage their GC cycles 
> ourselves, synchronized so that at most one replica is in GC at any given 
> time.  The clients should either send all requests to both replicas (and 
> cancel when one replies), or use some 

Re: [go-nuts] Alternative to reflect.DeepEqual that considers "shape" of cycles?

[howardcshaw]

https://golang.org/pkg/reflect/#DeepEqual

"Pointer values are deeply equal if they are equal using Go's == operator 
or if they point to deeply equal values."

By the rules described here, the fact that both pointers have the same 
value means it does not even NEED to check what they point to, so I don't 
think it ever even sees the cycle.

So yeah, you would have to write your own implementation, or find one.

https://github.com/google/go-cmp is an example of a custom DeepEqual 
implementation that allows overriding of the comparison basis by 
implementing an interface (it was designed for equality testing in tests).

>From a programmatic perspective, there are two basic ways of comparing two 
objects for equality - you either walk both objects, returning false the 
first time you find a mismatch; or you render both objects into a more 
directly comparable form, and then compare those.

For objects that contain directed or cyclic graphs, going the latter route 
(which *must* include cycle-breaking to avoid infinite loops) provides the 
opportunity of applying a 'canonicalization' pass on the intermediate form 
before the comparison. As an example, if you had two List pointers of the 
sort you used in your example, that *did* have the same structure, they 
would be unequal under DeepEqual (if they carried any comparable, non-equal 
information *aside* from the next pointer), but if canonicalized in a 
consistent manner that rotated each cycle to have the same starting point 
in a resulting acyclic graph subsequent to cycle-breaking, could then be 
compared equal. This requires general graph manipulations, though, and 
could greatly increase the cost to compare on complicated objects. (After 
all, it is effectively the same as asking whether two mathematical objects 
share the same topology, and that is the sort of question that can provide 
someone a PHD thesis!) But while a *general* solution may be quite 
expensive, for a specific case where you have control over the objects, it 
could be as simple as always walking a list until you find the node marked 
with a head flag before comparing them.

-- 
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: 10x latency spikes during GC alloc assist phase

[m.kevac via golang-nuts]

Hi. We have made a simple one line patch to Go that turns off GC assist. 
Unfortunately, it was the only way. I feel your pain.

$ git diff
diff --git a/src/runtime/malloc.go b/src/runtime/malloc.go
index 8850659748..a2c8697bf5 100644
--- a/src/runtime/malloc.go
+++ b/src/runtime/malloc.go
@@ -602,7 +602,7 @@ func mallocgc(size uintptr, typ *_type, needzero bool) 
unsafe.Pointer {
}
// Charge the allocation against the G. We'll account
// for internal fragmentation at the end of mallocgc.
-   assistG.gcAssistBytes -= int64(size)
+   assistG.gcAssistBytes = 1024
 
if assistG.gcAssistBytes < 0 {
// This G is in debt. Assist the GC to correct


Our CPU usage went down 
6x: https://twitter.com/mkevac/status/882289083132903424
Latency is now 
negligible: https://twitter.com/mkevac/status/882289349328596992 
https://twitter.com/mkevac/status/882289514437332992
And memory usage increase is not so 
big: https://twitter.com/mkevac/status/882289742901018625

On Tuesday, July 25, 2017 at 3:44:10 AM UTC+3, stb...@laserlike.com wrote:
>
> Hi,
>
> We are experiencing a problem that I believe may be related to issue 14812 
>  but I wanted to ask here 
> before adding to that case or filing a new issue. Of course, we’d also 
> greatly appreciate any advice about how to make our program performant.
>
> Here is what we observe: at Laserlike one of our core user-facing services 
> (the “leaf”) typically responds to a particular rpc in <400ms.  During GC 
> we see spikes in latency to >5s on some simple requests.  The stop the 
> world periods are short, so the GC spikes appear to happen at other times.
>
> We have been unable to replicate this in a simple program, but we did run 
> our code in a test mode that repros it.  In our test environment the server 
> loads ~10 GB of persistent data (never deleted so doesn’t really need to be 
> GCed), and we ask for 8 processors.  We are running go version 1.8.3 on 
> kubernetes on GCP machine of type n1-highmem-64.  To create the problem we 
> send the server a single request with >500 tasks..
>
>
> This google drive folder has leaf-logs-full.redacted.txt as well as other 
> performance tooling files 
> .
>  
>  A snippet from that log here shows normal query responses and timing:
>
> I0719 22:50:22.467367 leaf.go:363] Worker #5 done search for '[redacted]', 
> took 0.013 seconds
>
> I0719 22:50:22.467406 leaf.go:225] Worker #5 starting search for 
> '[redacted]'
>
> I0719 22:50:22.467486 leaf.go:363] Worker #6 done search for '[redacted]', 
> took 0.001 seconds
>
> I0719 22:50:22.467520 leaf.go:225] Worker #6 starting search for 
> '[redacted]'
>
> I0719 22:50:22.468050 leaf.go:363] Worker #9 done search for '[redacted]', 
> took 0.005 seconds
>
>
> We have observed that if a GC cycle happens to start while serving traffic 
> (which is often) AND there is a large amount of time spent in assist, then 
> our serving latency skyrockets by 10x.  In the log the slowdown commences 
> roughly when pacer assist starts at I0719 22:50:31.079283 and then reverts 
> to normal latencies shortly after the gc cycle completes at I0719 
> 22:50:36.806085.
>
> Below I copy parts of the log where we see latencies of up to 729ms on 
> tasks.  I also bold the line that shows 32929ms spent on alloc gc assist.
>
> We have captured an attached cpu profile during this time which seems to 
> confirm a large amount of time spent in runtime.gcAssistAlloc.func1.
>
>
> Pardon our ignorance about GC in golang, but our hypothesis about what may 
> be going wrong is that our large in-memory data structures are causing gc 
> to often go into assist mode, and that for reasons we don’t understand 
> malloc becomes expensive in that mode.  Since we also create ~100k new data 
> objects when processing user requests, we are guessing those allocs become 
> very slow.  Another piece of evidence for this hypothesis is that we have 
> another (prototype) implementation of this kind of service that makes more 
> use of object pools and doesn’t seem to have as much of slowdown during GC.
>
> Note on large in-memory data-structures:
>
> The principal data structures can be thought of as:
>
> Map[uint64][]byte (about 10M map entries, the slice lengths between 5K to 
> 50K) (around ~10G total memory usage) 
>
> Map[uint64][]uint64 (about 50M map entries, the slice lengths vary between 
> 10 and 100K, in a zipfian distribution, about 3G total memory usage)
>
> These data structures mostly stay as is over the life of the program.
>
> We are trying to figure out how to solve this so would appreciate any 
> advice. An engineer on our team wrote up the following ideas, none of which 
> are that great:
>
>1. 
>
>Figure out a simple way to prevent our goroutines slowing down during 
>

Re: [go-nuts] Re: No Allman-Style, No go!

[Rob Pike]

Very few, though. Very few.

As the proverb says:

Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.


-rob


On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder 
wrote:

> Btw please don't take it personally. What I'm saying is that indeed some
> people (including me as you see) WILL NEVER agree to be forced to change
> their coding style because Google engineers have decided so, but that
> doesn't mean we should stay away from go just because of our mental
> incapacity to agree on that.
>
> On Thu, Jul 27, 2017 at 9:32 AM,  wrote:
>
>> I don't know if you have read this post above :
>>
>> "BTW, I've just released Genesis, an open source generic preprocessor
>> which automatically converts Allman style code into K and allows
>> genericity by parametric instantiation.
>>
>> https://github.com/senselogic/GENESIS
>>
>> Better late than never... ;)"
>>
>> Obviously, I don't like AT ALL the K style, to which I prefer the
>> Allman style, for not only personal but also OBJECTIVE reasons.
>>
>> And yet I've learned Go and enjoy a lot to use this language, despite
>> this implies using an external tool to add genericity and fix the code
>> indentation.
>>
>> Btw here are the result of a small internet poll on indentation styles :
>>
>> - Allman : 7450 votes
>> - K style : 5514 votes
>> - Whitesmith : 455
>> - GNU : 422
>> - Horstman : 131
>> - Pico : 93
>> - Banner : 243
>>
>> (http://www.terminally-incoherent.com/blog/2009/04/10/the-
>> only-correct-indent-style)
>>
>> Even if these 14000 votes are obviously not enough to reflect the whole
>> development community, at least you can see here that many developers
>> prefer the Allman style to the K style.
>>
>> So sorry, but I completely disagree with your advice to stay away from Go
>> if you don't like its forced indentation style policy.
>>
>> It's not only too radical, but also not needed, as there are already
>> tools to fix that issue.
>>
>>
>> On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>>>
>>> I propose a new rule for our Code of Conduct: Before posting to the "No
>>> Allman-Style, No go!" thread, you shall read and understand all previous
>>> posts in the aforementioned thread.
>>>
>>> Justo to be clear: Go indentation style is a time saver. It was carefuly
>>> crafted to piss some people off.  As you can see, it works wonders. If
>>> someone can't handle a simple change in indentation style, then she has no
>>> business trying to learn Go, so she quits, thus saving time.
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/rzLzp_Z74ik/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[ojucie]

3702, I think you need to learn some fundamental concepts to better 
understand the problem at hand.


Processors have more than one core. That means we have several threads 
running simultaneously. To let more than one thread access the same memory 
region is a bad idea. If your program simply crashes consider yourself a 
lucky guy. There are other subtle problems that can be dangerous and 
difficult to spot.


So, the programmer must find a way to avoid those simultaneous access. A 
popular way is by using some synchronization object, i.e. a mutex. Before 
any access to the shared state, a thread must lock the mutex, releasing it 
when the access is done. For small programs, it works. However, as your 
program grows, that approach can get complicated in insidious ways. 


Go offers mutex, as several other languages do, but it offers a much better 
device: channels. There are dozens of ways to use channels, but I will give 
you just an example.


Divide your program so that only one goroutine can access the memory area. 
Let’s call this goroutine the “data owner”. That way you eliminate the 
shared state problem at once, because there will be no shared state, at all.


When some other goroutine needs to read or change that state, it ASKs the 
data owner to do the access on its behalf. How? By sending a request thru a 
channel, that’s how. The data owner process those requests, performing the 
required actions.


Learn to use channels, 3702. After a little practice, your programs will 
run fast and safely. As an additional benefit the architecture will be 
solid, easy to change when the need arises.

On Thursday, July 27, 2017 at 7:28:39 AM UTC-3, 3702...@qq.com wrote:
>
> o yea,thanks.it's a good way to improve the performance of my program.but 
> will it solve the problem,crashing?
>
> 在 2017年7月27日星期四 UTC+8上午12:26:36，JuciÊ Andrade写道：
>>
>> I mean bytes.Buffer.
>>
>> On Wednesday, July 26, 2017 at 8:08:13 AM UTC-3, JuciÊ Andrade wrote:
>>>
>>> Dear friend 3702, while you are at it, please change that string 
>>> appending strategy. Use a bufio.Buffer instead. It's way faster.
>>>
>>>

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

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

[Christoph Berger]

That’s actually what I meant to indicate in the last paragraph (emphasis added 
by me):

> The code in the Reddit post takes advantage of the fact that the last 
> increment of the C-style loop can be observed outside the loop,

But thanks for providing a clarification. I see now it has not been clear to 
everyone.

> On Wed, Jul 26, 2017 at 08:44:46AM -0700, Christoph Berger wrote:
> 
>>> someone shared [this question](
>>> https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/)
>>>  
>>> on reddit. I must say, that I'm surprised by the behavior myself. I would 
>>> have expected
>>> for i = range v
>>> to be semantically equivalent to
>>> for i = 0; i < len(v); i++
>>> and don't really understand the reasoning behind choosing different 
>>> semantics. Note, that the difference only exists, if i is declared outside 
>>> of the loop, that is, this is solely about the behavior after exiting the 
>>> loop-body.
>>> 
>>> I'd greatly appreciate some explanation :)
>> An attempt to explain this by looking at the C-style loop only:
>> 
>> The classic C-style for loop
>> 
>> for i:=0; i> 
>> is equivalent to
>> 
>> for i:=0; i>// do something with i
>>i++ // This is always the very last statement in the loop body
>> }
>> 
>> The loop body runs from 0 to len(v)-1 only, because the last increment of i 
>> to len(v) stops the loop, and no further iteration occurs. The code in the 
>> loop body never sees i being set to len(v). 
>> 
>> And that's the same behavior as with the range operator. 
>> 
>> The code in the Reddit post takes advantage of the fact that the last 
>> increment of the C-style loop can be observed outside the loop, for 
>> detecting if the loop stopped early. This is a neat side effect that is not 
>> possible with the range operator.
> 
> I would point out that both Axel and you are off a tiny bit from what
> actually happens ;-)
> 
> In a for loop which uses a short variable declaration, that variable's
> scope is confined to the for *statement* itself, and is also visible in
> the loop's body because its scope is defined to be nested in that of the
> loop statement.  This means in a loop like
> 
>  for i := 0; i < len(s); i++ {
>  }
> 
> the variable "i" is not accessible after the closing brace.
> 
> The actual "problem" stated in that Reddit post is different: it uses a
> variable defined outside the "for" loop:
> 
>  var i int
>  for i = 0; i < len(v); i++ {
>  }
> 
> As you can see, the loop merely uses that variable; it existed before
> the loop and continued to live on after it finished executing.
> 
> To recap what others have already written, since the for loop's post
> statement is defined to be executed after each execution of the body
> (unless it was exited by means of executing `break` or `return`), that
> 
>  i++
> 
> statement gets executed, the condition evaluates to false, and the loop
> exits -- with the variable "i" having the value equal to len(v).
> 
> One could do
> 
>  var x int
> 
>  for i := 0; i < len(v); i, x = i+1, x*2 {
>  }
> 
> and get even more interesting effect on the variable "x" after the loop
> finishes executing ;-)
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/Xi6W3H5mlto/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[370265036]

o yea,thanks.it's a good way to improve the performance of my program.but 
will it solve the problem,crashing?

在 2017年7月27日星期四 UTC+8上午12:26:36，JuciÊ Andrade写道：
>
> I mean bytes.Buffer.
>
> On Wednesday, July 26, 2017 at 8:08:13 AM UTC-3, JuciÊ Andrade wrote:
>>
>> Dear friend 3702, while you are at it, please change that string 
>> appending strategy. Use a bufio.Buffer instead. It's way faster.
>>
>>

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

Re: [go-nuts] Re: No Allman-Style, No go!

[Ecstatic Coder]

Btw please don't take it personally. What I'm saying is that indeed some
people (including me as you see) WILL NEVER agree to be forced to change
their coding style because Google engineers have decided so, but that
doesn't mean we should stay away from go just because of our mental
incapacity to agree on that.

On Thu, Jul 27, 2017 at 9:32 AM,  wrote:

> I don't know if you have read this post above :
>
> "BTW, I've just released Genesis, an open source generic preprocessor
> which automatically converts Allman style code into K and allows
> genericity by parametric instantiation.
>
> https://github.com/senselogic/GENESIS
>
> Better late than never... ;)"
>
> Obviously, I don't like AT ALL the K style, to which I prefer the Allman
> style, for not only personal but also OBJECTIVE reasons.
>
> And yet I've learned Go and enjoy a lot to use this language, despite this
> implies using an external tool to add genericity and fix the code
> indentation.
>
> Btw here are the result of a small internet poll on indentation styles :
>
> - Allman : 7450 votes
> - K style : 5514 votes
> - Whitesmith : 455
> - GNU : 422
> - Horstman : 131
> - Pico : 93
> - Banner : 243
>
> (http://www.terminally-incoherent.com/blog/2009/04/
> 10/the-only-correct-indent-style)
>
> Even if these 14000 votes are obviously not enough to reflect the whole
> development community, at least you can see here that many developers
> prefer the Allman style to the K style.
>
> So sorry, but I completely disagree with your advice to stay away from Go
> if you don't like its forced indentation style policy.
>
> It's not only too radical, but also not needed, as there are already tools
> to fix that issue.
>
>
> On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>>
>> I propose a new rule for our Code of Conduct: Before posting to the "No
>> Allman-Style, No go!" thread, you shall read and understand all previous
>> posts in the aforementioned thread.
>>
>> Justo to be clear: Go indentation style is a time saver. It was carefuly
>> crafted to piss some people off.  As you can see, it works wonders. If
>> someone can't handle a simple change in indentation style, then she has no
>> business trying to learn Go, so she quits, thus saving time.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

I don't know if you have read this post above :

"BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)"

Obviously, I don't like AT ALL the K style, to which I prefer the Allman 
style, for not only personal but also OBJECTIVE reasons.

And yet I've learned Go and enjoy a lot to use this language, despite this 
implies using an external tool to add genericity and fix the code 
indentation.

Btw here are the result of a small internet poll on indentation styles :

- Allman : 7450 votes
- K style : 5514 votes
- Whitesmith : 455
- GNU : 422
- Horstman : 131
- Pico : 93
- Banner : 243

(http://www.terminally-incoherent.com/blog/2009/04/10/the-only-correct-indent-style)

Even if these 14000 votes are obviously not enough to reflect the whole 
development community, at least you can see here that many developers 
prefer the Allman style to the K style.

So sorry, but I completely disagree with your advice to stay away from Go 
if you don't like its forced indentation style policy.

It's not only too radical, but also not needed, as there are already tools 
to fix that issue.

On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>
> I propose a new rule for our Code of Conduct: Before posting to the "No 
> Allman-Style, No go!" thread, you shall read and understand all previous 
> posts in the aforementioned thread.
>
> Justo to be clear: Go indentation style is a time saver. It was carefuly 
> crafted to piss some people off.  As you can see, it works wonders. If 
> someone can't handle a simple change in indentation style, then she has no 
> business trying to learn Go, so she quits, thus saving time.
>

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

Re: [go-nuts] Re: Reasoning behind behavior of range, when index is maintained

[Konstantin Khomoutov]

On Wed, Jul 26, 2017 at 08:44:46AM -0700, Christoph Berger wrote:

> > someone shared [this question](
> > https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/)
> >  
> > on reddit. I must say, that I'm surprised by the behavior myself. I would 
> > have expected
> > for i = range v
> > to be semantically equivalent to
> > for i = 0; i < len(v); i++
> > and don't really understand the reasoning behind choosing different 
> > semantics. Note, that the difference only exists, if i is declared outside 
> > of the loop, that is, this is solely about the behavior after exiting the 
> > loop-body.
> >
> > I'd greatly appreciate some explanation :)
> An attempt to explain this by looking at the C-style loop only:
> 
> The classic C-style for loop
> 
> for i:=0; i 
> is equivalent to
> 
> for i:=0; i // do something with i
> i++ // This is always the very last statement in the loop body
> }
> 
> The loop body runs from 0 to len(v)-1 only, because the last increment of i 
> to len(v) stops the loop, and no further iteration occurs. The code in the 
> loop body never sees i being set to len(v). 
> 
> And that's the same behavior as with the range operator. 
> 
> The code in the Reddit post takes advantage of the fact that the last 
> increment of the C-style loop can be observed outside the loop, for 
> detecting if the loop stopped early. This is a neat side effect that is not 
> possible with the range operator.

I would point out that both Axel and you are off a tiny bit from what
actually happens ;-)

In a for loop which uses a short variable declaration, that variable's
scope is confined to the for *statement* itself, and is also visible in
the loop's body because its scope is defined to be nested in that of the
loop statement.  This means in a loop like

  for i := 0; i < len(s); i++ {
  }

the variable "i" is not accessible after the closing brace.

The actual "problem" stated in that Reddit post is different: it uses a
variable defined outside the "for" loop:

  var i int
  for i = 0; i < len(v); i++ {
  }

As you can see, the loop merely uses that variable; it existed before
the loop and continued to live on after it finished executing.

To recap what others have already written, since the for loop's post
statement is defined to be executed after each execution of the body
(unless it was exited by means of executing `break` or `return`), that

  i++

statement gets executed, the condition evaluates to false, and the loop
exits -- with the variable "i" having the value equal to len(v).

One could do

  var x int

  for i := 0; i < len(v); i, x = i+1, x*2 {
  }

and get even more interesting effect on the variable "x" after the loop
finishes executing ;-)

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