[go-nuts] Re: golang too many json unmarshal trigger gc frequency to many

[Erik Dubbelboer]

Try https://github.com/pquerna/ffjson to improve speed and reduce garbage 
generation. This in combination with sync.Pool will increase your 
throughput by A LOT.

On Thursday, October 27, 2016 at 10:29:01 AM UTC+8, 刘桂祥 wrote:
>
> 
>   In my server many requests need to handle a loop to unmarshal json 
> strings and I find gc is very frequency 
>
>
>
>

-- 
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: Stopping a server

[Peter Mogensen]

On 2016-10-27 22:50, Nick Patavalis wrote:

Yes, this would work, as demonstrated by your example, which is
correct. But this further complicates the semantics and the
interface. Now you also need a way to wait for the server to become
running. In effect, you need something like a WaitStart() method, in
addition to Serve()---if you want your interface to be used in a
race-free manner.


The point being that it's up to the user of the interface how to 
specific Server implementation should work.



I was arguing that: You need a Reset() method (or a WaitRun() like
above) otherwise your interface's semantics are inherently racy. This
is complicated to explain.

On the other hand, the user is already accustomed with the semantics
of cancelation through contexts, which are race-free.


... but in that case you need a global registry of contexts to hook them 
up against signalling.



So I guess my conclusion is: Contexts could be used to stop servers,
solving issues with racy semantics, but since, as it turns out, this

is not a customary practice, it may confuse the users.



As I said before... what they buy you is a way to provide the channel 
used for shutdown externally, so you know exactly which invocation of 
Server() you are cancelling.
But when the shutdown event is triggered externally, you need some extra 
code to provide the context for the current Serve() invocation.


You are correct that in my library some signals can get lost... if you 
send a SIGTERM quickly followed by a SIGINT it could be that the SIGINT 
is lost due to SIGTERM having but all Servers in a non-running state.

... or (and this is much worse)... maybe only some of them.
I'll probably have to look into that.

/Peter

--
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[prades . marq]

Sure you willfully participate on a forum often used for insults, character 
assassination, witch hunts and doxxing. This isn't the first time shit like 
this happens on /r/golang , and frankly it gives the whole Go community a 
bad name. Keep being embarrassed "on my behalf", Who the hell do you think 
you are ? I didn't show you disrespect, don't insult me.

Le vendredi 28 octobre 2016 05:00:40 UTC+2, ad...@garyshood.com a écrit :
>
> The golang subreddit is infinitely more useful and accessible than most 
> golang resource sites and this mailing list. Shutting it down should not be 
> considered (notice how nobody is responding postively to your idea? (that's 
> how you know it is bad)). I'm embarrassed on your behalf that you even 
> suggested this.
>
> On Thursday, October 27, 2016 at 7:41:42 AM UTC-7, prade...@gmail.com 
> wrote:
>>
>> Frankly /r/golang is so toxic I stopped posting there, it should be 
>> either shut down or officially excluded from any official go forum. 
>>
>> The code of conduct serves very little purpose 
>> given what happens there constantly, 
>>
>> People like to target projects, insult their author and call them thieves 
>> to destroy their reputation and then complain and play the victim when they 
>> are being called out when caught misbehaving ? 
>>
>> I say shut down /r/golang , there is very little moderation there to 
>> begin with.
>>
>> I'm sure Sarah Adams did the best she could to de-escalate the situation 
>> but frankly there is nothing that can really be done due to the nature of 
>> reddit.
>>
>> Le jeudi 27 octobre 2016 13:36:23 UTC+2, Aram Hăvărneanu a écrit :
>>>
>>> I have received a very insulting and distressing e-mail from Sarah
>>> Adams, who claims to represent the The Go Code of Conduct Team, an
>>> illicit bully organization who claims authority about what Go
>>> contributors think and say outside the Go mailing lists. I do not
>>> recognize this group's legitimacy in these matters.
>>>
>>> The e-mail says:
>>>
>>> We received a report about your comment on this thread
>>>
>>> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
>>> :
>>> "Their English was so bad I couldn't understand what was
>>> going on".
>>>
>>> This comment goes against our community Code of Conduct,
>>> https://golang.org/conduct. The comment is not respectful,
>>> and would have been more productive just as, "I couldn't
>>> understand what was going on".
>>>
>>> Please consider this a warning from the Code of Conduct
>>> working group.
>>>
>>> Some more context is necessary. There is someone in the Go community
>>> who literally steals other people's code, receives money for it,
>>> and actively tries to covers his tracks.
>>>
>>> A person named Florin Pățan provided an overview:
>>>
>>> [1] 
>>> http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html
>>>
>>> which has been discussed on reddit:
>>>
>>> [2] 
>>> https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
>>> .
>>>
>>> Reddit also discussed this thief's action in another thread:
>>>
>>> [3] 
>>> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/
>>>
>>> I have archived these documents here:
>>>
>>> [1] http://archive.is/9oN1A
>>> [2] http://archive.is/Q36G5
>>> [3] http://archive.is/aSFUg
>>>
>>> The comment in question refers to this GitHub issue, also archived:
>>>
>>> [4] https://github.com/avelino/awesome-go/pull/1137
>>> [4] http://archive.is/7xgc7
>>>
>>> Now take a look at what I said, and what Sarah Adams in her
>>> infinite arrogance suggests I should have said:
>>>
>>> Aram: Their English was so bad I couldn't understand what
>>>  was going on
>>>
>>> Sarah: I couldn't understand what was going on
>>>
>>> If you compare these two phrases: you can see that the problem Sarah
>>> Adams has is with "their English was so bad".
>>>
>>> In other words, Sarah's problem is with speaking the objective
>>> *TRUTH*.
>>>
>>> Whether someone speaks good or bad English is an objective fact
>>> easily determined by anyone who speaks English at some level of
>>> proficiency. I encourage all English speakers to take a look at [4]
>>> and do an individual assessment of the level of proficiency in English
>>> those sock puppets possess.
>>>
>>> I will not be policed around for telling the *TRUTH*. I will not
>>> be silenced into political compliance. I will not tolerate other
>>> people who tell me what is acceptable to say, especially when these
>>> people only want to hide the *OBJECTIVE TRUTH*.
>>>
>>> The comment is not respectful
>>>
>>> Damn right it wasn't. You or your organization has no authority
>>> mandating how respectful my speech is. What level of arrogance.
>>>
>>> However, it was not disrespectful. It was an objective assessment
>>> of an *infractor's* level of English competence.
>>>
>>> I owe nobody respect. Certainly not someone who breaks the law and
>>> steals o

Re: [go-nuts] Stalking people online for thought crimes! This is what the Go project has succumbed to!

[prades . marq]

>  The actions of the Iris author are, in my opinion, pretty awful. But the 
only people that can take action against them are the people whose code he 
stole.

This is completely irrelevant IMHO. Why are these witch hunts allowed in a 
go forum ? I'm not talking about the author of this thread who decided to 
make a private matter public when he didn't need to, thinking he was too 
good to be held to the same standards as others because he is a Go 
contributor, I'm talking about threads of /r/golang where doxxing, insults 
against individuals are the norm because this or that person is deemed a 
"thief" or this person use this API the wrong way or that person use 
dependency injection. There is a nasty mindset in the Go community and I 
didn't hear anybody within the Go team calling it out for what it is, 
bullying. The thread about Iris author should have been shut down because 
it was full of insults and disrespect. Iris author being a "so-called 
thief" doesn't justify this kind of behavior in the Go community. The same 
shit happened with Martini's author which left the Go community. Nobody 
stood up for him when he was mocked on /r/golang because he dared use 
dependency injection. You'd think an innovative language would reward 
innovation, no, it's more like if you dare do things the way an influent 
gopher doesn't approve it's "open season" and anything goes to take you 
down ... 

Le jeudi 27 octobre 2016 17:45:44 UTC+2, Andrew Gerrand a écrit :
>
> Hi Aram,
>
> I am sorry this has caused you such distress.
>
> As has been pointed out by others, your comment did not appear to be 
> directed at the Iris author, but rather at dlsniper, the author of the blog 
> post. He even replied to you apologizing for his English skills, and you 
> did nothing to correct him, so I don't think one would be remiss to assume 
> that he was the target of your comment. For this reason, I think it 
> unlikely that your comment was reported by the Iris author.
>
> The actions of the Iris author are, in my opinion, pretty awful. But the 
> only people that can take action against them are the people whose code he 
> stole.
>
> But the Iris issue is a distraction here. The CoC working group was formed 
> to help resolve conflict within official Go spaces, one of which is the 
> golang subreddit. Your comment was reported by someone in the community, 
> and so we contacted you about it.
>
> On "objective truth": As a thought experiment, is it productive to tell a 
> newbie "You're a terrible programmer"? It may be true, but it is obviously 
> mean and discouraging. To me, it seems disingenuous to insist that we have 
> a right to say whatever we want wherever we like, so long as it is true. 
> Civility requires a little more from us.
>
> The purpose of the message from the CoC group was to let you know that 
> your comment was interpreted as hostile, and to suggest that you could 
> have make the equivalent point without belittling anyone. I sincerely 
> encourage you to take it in the spirit in which it was intended.
>
> In Sarah's message to you, she concluded:
>
>   Please feel free to reach out if you have any questions or concerns.
>
>   Sincerely,
>   The Go Code of Conduct Team
>
> I wish you had taken us up on that offer instead of starting this public 
> thread. We are reasonable people that care deeply about all members of the 
> community, including you.
>
> Andrew
>
>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Reto Brunner]

At the CoC team,
You do realize that reddit is not actually yours to govern yes?
Reddit is being reddit... everywhere you can just post "anomalously"  the
atmosphere is rather more, well, outspoken than on a public mailing list.

Why don't you just deal with it and accept that there are other mentalities
than yours and let people have their personal life?

Aram, I find it very good that you chose a public mailing list instead of
contacting just the team. Like this there is the possibility to actually
have a discussion about when and where the code of conduct team should or
shouldn't issue "warnings" (or threads)

On Thu, 27 Oct 2016 at 22:32 Andrew Gerrand  wrote:

>
> On 28 October 2016 at 03:53, mjy  wrote:
>
> It's partly a cultural thing, I suppose. Some people consider the e-mail
> bland, others (like me) threatening. Someone should educate the CoC crew
> about these cultural, perhaps personality differences so they can improve
> their tone to avoid unnecessary escalation.
>
>
> We are definitely still learning, and I think it's clear that we missed
> the mark communicating with Aram here. It was not, and would never be, our
> intention to come across as threatening or harsh. I am dismayed by how this
> turned out. This will certainly inform our actions in the future.
>
> Andrew
>
> --
> 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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[admin]

The golang subreddit is infinitely more useful and accessible than most 
golang resource sites and this mailing list. Shutting it down should not be 
considered (notice how nobody is responding postively to your idea? (that's 
how you know it is bad)). I'm embarrassed on your behalf that you even 
suggested this.

On Thursday, October 27, 2016 at 7:41:42 AM UTC-7, prade...@gmail.com wrote:
>
> Frankly /r/golang is so toxic I stopped posting there, it should be either 
> shut down or officially excluded from any official go forum. 
>
> The code of conduct serves very little purpose 
> given what happens there constantly, 
>
> People like to target projects, insult their author and call them thieves 
> to destroy their reputation and then complain and play the victim when they 
> are being called out when caught misbehaving ? 
>
> I say shut down /r/golang , there is very little moderation there to begin 
> with.
>
> I'm sure Sarah Adams did the best she could to de-escalate the situation 
> but frankly there is nothing that can really be done due to the nature of 
> reddit.
>
> Le jeudi 27 octobre 2016 13:36:23 UTC+2, Aram Hăvărneanu a écrit :
>>
>> I have received a very insulting and distressing e-mail from Sarah
>> Adams, who claims to represent the The Go Code of Conduct Team, an
>> illicit bully organization who claims authority about what Go
>> contributors think and say outside the Go mailing lists. I do not
>> recognize this group's legitimacy in these matters.
>>
>> The e-mail says:
>>
>> We received a report about your comment on this thread
>>
>> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
>> :
>> "Their English was so bad I couldn't understand what was
>> going on".
>>
>> This comment goes against our community Code of Conduct,
>> https://golang.org/conduct. The comment is not respectful,
>> and would have been more productive just as, "I couldn't
>> understand what was going on".
>>
>> Please consider this a warning from the Code of Conduct
>> working group.
>>
>> Some more context is necessary. There is someone in the Go community
>> who literally steals other people's code, receives money for it,
>> and actively tries to covers his tracks.
>>
>> A person named Florin Pățan provided an overview:
>>
>> [1] 
>> http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html
>>
>> which has been discussed on reddit:
>>
>> [2] 
>> https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
>> .
>>
>> Reddit also discussed this thief's action in another thread:
>>
>> [3] 
>> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/
>>
>> I have archived these documents here:
>>
>> [1] http://archive.is/9oN1A
>> [2] http://archive.is/Q36G5
>> [3] http://archive.is/aSFUg
>>
>> The comment in question refers to this GitHub issue, also archived:
>>
>> [4] https://github.com/avelino/awesome-go/pull/1137
>> [4] http://archive.is/7xgc7
>>
>> Now take a look at what I said, and what Sarah Adams in her
>> infinite arrogance suggests I should have said:
>>
>> Aram: Their English was so bad I couldn't understand what
>>  was going on
>>
>> Sarah: I couldn't understand what was going on
>>
>> If you compare these two phrases: you can see that the problem Sarah
>> Adams has is with "their English was so bad".
>>
>> In other words, Sarah's problem is with speaking the objective
>> *TRUTH*.
>>
>> Whether someone speaks good or bad English is an objective fact
>> easily determined by anyone who speaks English at some level of
>> proficiency. I encourage all English speakers to take a look at [4]
>> and do an individual assessment of the level of proficiency in English
>> those sock puppets possess.
>>
>> I will not be policed around for telling the *TRUTH*. I will not
>> be silenced into political compliance. I will not tolerate other
>> people who tell me what is acceptable to say, especially when these
>> people only want to hide the *OBJECTIVE TRUTH*.
>>
>> The comment is not respectful
>>
>> Damn right it wasn't. You or your organization has no authority
>> mandating how respectful my speech is. What level of arrogance.
>>
>> However, it was not disrespectful. It was an objective assessment
>> of an *infractor's* level of English competence.
>>
>> I owe nobody respect. Certainly not someone who breaks the law and
>> steals other people's intellectual property. Respect is earned.
>>
>> and would have been more productive just as
>>
>> Ah, yes, here you can see in action the new-age practice of corporate
>> double speak applied to open source projects. This is not Google.
>> You are not fooling me or anyone else who still has a grain of
>> independent thought left.
>>
>> This is a pathetic and disgusting attempt of silencing independent
>> contributors who still refuse to kneel after your coup d'état in
>> which you managed to replace the Go technical governance with a
>> thought

[go-nuts] Re: How can I debug using GDB on IntelliJ IDEA.

[originuk]

I hate to say it, but debugging Golang sucks.   I've tried Delve and GDB 
with the IntelliJ Go plugin on a Mac... and I am truly disappointed.   I 
like Golang as a language - it ticks loads of boxes, yet it's frustrating 
to effectively debug / step through code at quick pace - the debugger goes 
AWOL and I have to rely on printing log lines for diagnostics.   I've only 
stuck with Golang because it's the preferred language where I work.  I've 
been programming for probably too long - 30 years, so I am VERY surprised 
that golang is as popular as it is without a proper debugger that 
integrates seamlessly and fault-free with any IDE.   

Come one guys, this is the 21st century! 

I wish with all my heart that debugging in Go will be responsive, 
straightforward and glitch free as it is with other well established 
languages... sadly there is some way to go before that's a reality.

Anyone who says debugging is all good needs to wake up and smell the 
coffee the Golang plugin for IntelliJ is buggy ( but great work guys 
for getting it this far - kudos earned  but it seems like they need help. 
 There are many open tickets around the debugger).   The Jetbrains suite of 
IDE's are the go-to IDEs for many modern languages, so the reality is far 
from rosy.   If I were a teenager again, with time on my hands, I'd be 
straight in there fixing stuff up.  Having a family means I have just 
enough time to moan, so sorry for the rant :-)



On Wednesday, November 4, 2015 at 6:34:47 AM UTC, Harry wrote:
>
> Hello everyone,
>
> I'm using IntelliJ IDEA 15 to develop golang projects. To debug golfing 
> project, I installed GDB. But I couldn't find GDB related setting on 
> IntelliJ IDEA. I'm trying it on macbook.
>
> How can I debug on that??
>
>
>
>

-- 
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: Go interface

[Henry]

Hi,

I usually use the following pattern when creating a type. In your case, it 
would be as follows:

interface Animal {
  Eat()
  Travel()
}

interface Mammal {
  Animal
  NoOfLegs() int
}

//Note this is unexported
struct mammalImpl {
  //implementation here
}

//Mammal constructor. This will not compile if mammalImpl does not satisfy 
Mammal.
func NewMammal() Mammal {
   return new(mammalImpl)
}

func (m mammalImpl) Eat() {
   //implementation here..
}

func (m mammalImpl) Travel() {
   //implementation here..
}

func (m mammalImpl) NoOfLegs() {
   ///implementation here..
}

What I like with the above pattern is that it forces the users of my API to 
rely upon abstraction, which allows me certain flexibility for code changes 
in the future. In addition, if I want to have an overview what Mammal does, 
all I need to do is to look at the Mammal interface, which is a lot shorter 
and easier to see than inspecting its actual implementation. If I need to 
change Mammal, I will just change the Mammal interface and the compiler 
will let me know what are its implementation that also need to be changed. 
So far, this pattern has been very helpful.

On Thursday, October 27, 2016 at 2:11:04 PM UTC+7, Arafath M wrote:

> Hi,
>
> Using interface is easy in Go. But, while studying an existing code base, 
> it is very difficult to find which types have implementation of a 
> particular interface. The situation will become worse, if there are many 
> interface functions inside an interface definition.
>
> In another languages, it is easy to just search for the class, which 
> implements a particular interface.
>
> For example in Java,
>
> interface Animal {
>public void eat();
>public void travel();
> }
>
> public class MammalInt implements Animal {
>
>public void eat() {
>   System.out.println("Mammal eats");
>}
>
>public void travel() {
>   System.out.println("Mammal travels");
>} 
>
>public int noOfLegs() {
>   return 0;
>}
>
>public static void main(String args[]) {
>   MammalInt m = new MammalInt();
>   m.eat();
>   m.travel();
>}
> }
>
> By seeing the above line "*public class MammalInt **implements Animal*" one 
> can easily understand that Animal interface is implemented in MammalInt 
>
> In Go, as far as I know, I need to search for all interface functions to 
> find whether a type implements a particular interface or not.
>
> Have anybody else experienced the same? If yes, what is the solution? 
>
> *Note:* Personally I like to write code in Go; all of my recent projects 
> are in Go. I prefer Go than Java.
>
> Sincerely,
> Arafath M
>

-- 
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: Float32 math and slice arithmetics using SIMD

[Erwin Driessens]

I'd love to see SIMD intrinsics in the Go compiler(s), even if it would 
mean separate packages for all the architectures. I'm not experienced 
enough to tell how far one could get with designing a cross-platform set of 
intrinsics instructions? Using the hardware when it is available, falling 
back on emulation when not?

-- 
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: Float32 math and slice arithmetics using SIMD

[Nigel Tao]

On Thu, Oct 27, 2016 at 9:24 AM, 'simon place' via golang-nuts
 wrote:
> the approach i took was to try to minimise the M/C, so;

Sorry for the ignorant question, but what does M/C stand for?

-- 
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: Float32 math and slice arithmetics using SIMD

[Nigel Tao]

On Fri, Oct 28, 2016 at 6:54 AM, 'simon place' via golang-nuts
 wrote:
> however, from looking at it, couldn’t find documentation, that code is
> specific to speeding up graphics overlays? maybe? (accumulate)

Yes, speeding up an accumulation step, described at
https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445#.qz8jram0o

The generated code are SIMD implementations of very simple Go functions.

For example, the fixedAccumulateOpSrcSIMD function in the generated
https://github.com/golang/image/blob/master/vector/acc_amd64.s file is
the SIMD equivalent of the fixedAccumulateOpSrc function in
https://github.com/golang/image/blob/master/vector/raster_fixed.go


> but it’s confusing me that its using templates, when there seems to only be
> one template.

There is only one template, instantiated 6 times. There are 2 types of
math (fixed point and floating point), and 3 types of composition
operator (draw over, draw src, and accumulate to mask).

Raph's original C prototype, using intrinsics, is at
https://github.com/google/font-rs/blob/master/src/accumulate.c but
that does only 1 of those 6: floating point and draw src. IIRC it does
assume that the input slice's length is a multiple of 4, unlike the Go
code, but the C code is a proof of concept, not a production quality
library.

-- 
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: iconvg: a compact, binary format for simple vector graphics

[Nigel Tao]

On Wed, Oct 26, 2016 at 4:38 PM, Nigel Tao  wrote:
> SVGZ is indeed smaller, and more expensive to decode, but I don't have
> numbers at hand.

Oh, I do have a size number. It's only one data point, but look for
"gzip" at https://godoc.org/golang.org/x/exp/shiny/iconvg

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Daniel Skinner]

The email was presumptuous, so as to describe "more productive", and
threatening with "consider this a warning". It also felt cold and
unwelcoming like a bot generated it.

I do not advocate this CoC at all, but at the very least the email could
have stuck to what was known to start a private conversation and left it at
that, "Hey, someone reached out to us because they felt threatened by your
comment here [...]" and show an interest in the details beyond a passing
glance at the allegedly offensive statement.

If genuine concern can't be established (doubly hard given this is all done
in text), then I imagine the "kangaroo court" calling will only get worse.

On Thu, Oct 27, 2016 at 3:32 PM Andrew Gerrand  wrote:

>
> On 28 October 2016 at 03:53, mjy  wrote:
>
> It's partly a cultural thing, I suppose. Some people consider the e-mail
> bland, others (like me) threatening. Someone should educate the CoC crew
> about these cultural, perhaps personality differences so they can improve
> their tone to avoid unnecessary escalation.
>
>
> We are definitely still learning, and I think it's clear that we missed
> the mark communicating with Aram here. It was not, and would never be, our
> intention to come across as threatening or harsh. I am dismayed by how this
> turned out. This will certainly inform our actions in the future.
>
> Andrew
>
> --
> 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] HTTP2 Runtime panic while Migrating an Application from Go 1.4.1 to 1.6.2

[Brad Fitzpatrick]

That isn't an http2 panic. That's just the http2 code recovering your
Handler's panic and printing it, the same as the http1 server does.

Your panic is actually somewhere in:

lib.setupC5Tab(0x7f6fbe169d20, 0xc8201b0d20, 0xc820436d98, 0x7f6fbe169d20,
0xc8201b0dc0, 0x7f6fbe16a2a8, 0xc820339e60, 0x7f6fbe16a5f8, 0xc8201b0e60,
0xc82047be20)
/home/sysop/go/src/lib/rhewocompstatus.go:1310 +0x3976
lib.BuildRhewoStatus.func4(0x7f6fbe117538, 0xc8205bc300)
/home/sysop/go/src/lib/rhewocompstatus.go:168 +0xc8
github.com/icza/gowut/gwu.handlerFuncWrapper.HandleEvent(0xc82040b5c0,
0x7f6fbe117538, 0xc8205bc300)
/home/sysop/go/src/github.com/icza/gowut/gwu/event.go:441 +0x3e
github.com/icza/gowut/gwu.(*compImpl).dispatchEvent(0xc820158770,
0x7f6fbe117538, 0xc8205bc300)
/home/sysop/go/src/github.com/icza/gowut/gwu/comp.go:307 +0x167
github.com/icza/gowut/gwu.(*timerImpl).dispatchEvent(0xc820158770,
0x7f6fbe117538, 0xc8205bc300)
:1302 +0x60
github.com/icza/gowut/gwu.(*serverImpl).handleEvent(0xc82019e900,
0x7f6fbe1172c0, 0xc8202fa7e0, 0x7f6fbe169998, 0xc8202b4ff0, 0x7f6fbe117170,
0xc82007c2a0, 0xc820148460)
/home/sysop/go/src/github.com/icza/gowut/gwu/server.go:815 +0x103e
github.com/icza/gowut/gwu.(*serverImpl).serveHTTP(0xc82019e900,
0x7f6fbe117170, 0xc82007c2a0, 0xc820148460)
/home/sysop/go/src/github.com/icza/gowut/gwu/server.go:683 +0x1544
github.com/icza/gowut/gwu.(*serverImpl).Start.func1(0x7f6fbe117170,
0xc82007c2a0, 0xc820148460)
/home/sysop/go/src/github.com/icza/gowut/gwu/server.go:483 +0x4c


On Thu, Oct 6, 2016 at 3:29 AM, Nigel Vickers  wrote:

> We are migrating an application from go 1.4.1 to 1.6.2. The application
> uses a modified Gowut 0.9 as the framework and initially moved without
> issue. The application server runs behind a tls sni
> proxy/loadbalancer(slt). While running slt at 1.4.1 and the server at 1.6.2
> no problems were encountered. We assume because 1.4.1 couldn’t http2. After
> moving the slt to 1.6.2 we are experiencing runtime panics with
> http2(protocol attached). Two questions:
>
> Is the statement that http2 should just run still applicable?
> And
> Are use cases that fail still of interest as issues?
>
> We have a “provisional trigger” .  A client xmlHttpRequest triggered by an
> attached javascript timer requests a component update and reload from the
> server. Currently at 10 second intervals.
> Irregularly, between the 90th and 99th request the server panics.
>
> We are bit stuck because we have no experience with http2. Any suggestions
> on how to proceed would be welcome.
>
> Nigel Vickers
>
>
> Rhewo Dev2016/10/05 14:14:24 serveHTTP Incoming: request Path
>  /mainAppWin/e
> Rhewo Dev2016/10/05 14:14:24 serveHTTP Incoming: request Body
>  &{0xc8205ba120 0xc8200f5180 false 0xc8204e8d00 false}
> SessionDump &{LUP_NiaDLsjBFLOpsSUKLa false {63611263456 268951715
> 0xf36ee0} {63611266464 12850383 0xf36ee0} map[mainAppWin:0xc8202b4ff0]
> map[groups:[free admin] module:Status Lang:de hiddenPan:0xc820476000
> ips:xx.xx.xx.xx user:fred2 auth:auth] 144000 0xc820303f20}
> Rhewo Dev2016/10/05 14:14:24 serveHTTP appName Parts   3 [ mainAppWin e]
> Rhewo Dev2016/10/05 14:14:24Event from comp: 932  event: 15
> 2016/10/05 14:14:24 http2: panic serving xxx.xxx.xxx.xxx:49337: runtime
> error: index out of range
> goroutine 2962 [running]:
> net/http.(*http2serverConn).runHandler.func1(0xc82053df3f, 0xc8200f5180,
> 0xc82007c2a0)
> /usr/local/go/src/net/http/h2_bundle.go:4050 +0xde
> panic(0xb24060, 0xc82000e0d0)
> /usr/local/go/src/runtime/panic.go:443 +0x521
> lib.setupC5Tab(0x7f6fbe169d20, 0xc8201b0d20, 0xc820436d98, 0x7f6fbe169d20,
> 0xc8201b0dc0, 0x7f6fbe16a2a8, 0xc820339e60, 0x7f6fbe16a5f8, 0xc8201b0e60,
> 0xc82047be20)
> /home/sysop/go/src/lib/rhewocompstatus.go:1310 +0x3976
> lib.BuildRhewoStatus.func4(0x7f6fbe117538, 0xc8205bc300)
> /home/sysop/go/src/lib/rhewocompstatus.go:168 +0xc8
> github.com/icza/gowut/gwu.handlerFuncWrapper.HandleEvent(0xc82040b5c0,
> 0x7f6fbe117538, 0xc8205bc300)
> /home/sysop/go/src/github.com/icza/gowut/gwu/event.go:441 +0x3e
> github.com/icza/gowut/gwu.(*compImpl).dispatchEvent(0xc820158770,
> 0x7f6fbe117538, 0xc8205bc300)
> /home/sysop/go/src/github.com/icza/gowut/gwu/comp.go:307 +0x167
> github.com/icza/gowut/gwu.(*timerImpl).dispatchEvent(0xc820158770,
> 0x7f6fbe117538, 0xc8205bc300)
> :1302 +0x60
> github.com/icza/gowut/gwu.(*serverImpl).handleEvent(0xc82019e900,
> 0x7f6fbe1172c0, 0xc8202fa7e0, 0x7f6fbe169998, 0xc8202b4ff0, 0x7f6fbe117170,
> 0xc82007c2a0, 0xc820148460)
> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:815 +0x103e
> github.com/icza/gowut/gwu.(*serverImpl).serveHTTP(0xc82019e900,
> 0x7f6fbe117170, 0xc82007c2a0, 0xc820148460)
> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:683 +0x1544
> github.com/icza/gowut/gwu.(*serverImpl).Start.func1(0x7f6fbe117170,
> 0xc82007c2a0, 0xc820148460)
>

Re: [go-nuts] Re: Stopping a server

[Nick Patavalis]

On Thu, Oct 27, 2016 at 11:11 PM, Peter Mogensen  wrote:
>
> The problem you seem to be trying to solve here is for the caller of
> Shutdown() to know when the Server has exited Serve().
> The way to do that under "my" semantics to implement a Server letting you
> wait for it to be ready to acknowlede Shutdown()
>
> A Serve() implementation could  be done in many ways (it doesn't have to
> drop Shutdown() ) ... to to extend the example it could easily once in
> running state send an event on a channel you could wait on (or use a
> CondVar)
>
> So ...
>
>  func (s *Server) Serve() {
> runmu.Lock()
> s.running = true
> runmu.Unlock()
>
> s.IsRunningChan <- true
> 
>  }
>
>  go func () {
> err := srv.Serve()
> srvEnd <- err
>  }
>
>  ... a short time after ...
>
>  <- srv.IsRunningChan
>
>  srv.Stop()
>
>   <- srvEnd
>

Yes, this would work, as demonstrated by your example, which is
correct. But this further complicates the semantics and the
interface. Now you also need a way to wait for the server to become
running. In effect, you need something like a WaitStart() method, in
addition to Serve()---if you want your interface to be used in a
race-free manner.

>> No problem. Under "my" semantics, once you call Shutdown() on a server
>> instance it cannot run again, unless you explicitly call Reset().
>
> Oh... I thought you argued against the 3rd method.
>

I was arguing that: You need a Reset() method (or a WaitRun() like
above) otherwise your interface's semantics are inherently racy. This
is complicated to explain.

On the other hand, the user is already accustomed with the semantics
of cancelation through contexts, which are race-free.

> since you cannot call CancelFunc() twice ... (closing a closed
> channel will panic).

You call the "cancel" function of a context as many times as you
want. But this is besides the point... Naturally, every time you stop
and re-start your server you must update your cancel func, most likely
under a lock.

So I guess my conclusion is: Contexts could be used to stop servers,
solving issues with racy semantics, but since, as it turns out, this

is not a customary practice, it may confuse the users.

/npat

-- 
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: HTTP2 Runtime panic while Migrating an Application from Go 1.4.1 to 1.6.2

[András Belicza]

Latest version of Gowut is 1.1.2. Is the problem persist with Gowut 1.1.2?

On Thursday, October 6, 2016 at 12:29:34 PM UTC+2, Nigel Vickers wrote:
>
> We are migrating an application from go 1.4.1 to 1.6.2. The application 
> uses a modified Gowut 0.9 as the framework and initially moved without 
> issue. The application server runs behind a tls sni 
> proxy/loadbalancer(slt). While running slt at 1.4.1 and the server at 1.6.2 
> no problems were encountered. We assume because 1.4.1 couldn’t http2. After 
> moving the slt to 1.6.2 we are experiencing runtime panics with 
> http2(protocol attached). Two questions:
>
> Is the statement that http2 should just run still applicable?
> And
> Are use cases that fail still of interest as issues?
>
> We have a “provisional trigger” .  A client xmlHttpRequest triggered by an 
> attached javascript timer requests a component update and reload from the 
> server. Currently at 10 second intervals.
> Irregularly, between the 90th and 99th request the server panics.
>
> We are bit stuck because we have no experience with http2. Any suggestions 
> on how to proceed would be welcome.
>
> Nigel Vickers
>
>   
> Rhewo Dev2016/10/05 14:14:24 serveHTTP Incoming: request Path 
>  /mainAppWin/e
> Rhewo Dev2016/10/05 14:14:24 serveHTTP Incoming: request Body 
>  &{0xc8205ba120 0xc8200f5180 false 0xc8204e8d00 false}
> SessionDump &{LUP_NiaDLsjBFLOpsSUKLa false {63611263456 268951715 
> 0xf36ee0} {63611266464 12850383 0xf36ee0} map[mainAppWin:0xc8202b4ff0] 
> map[groups:[free admin] module:Status Lang:de hiddenPan:0xc820476000 
> ips:xx.xx.xx.xx user:fred2 auth:auth] 144000 0xc820303f20}
> Rhewo Dev2016/10/05 14:14:24 serveHTTP appName Parts   3 [ mainAppWin e]
> Rhewo Dev2016/10/05 14:14:24Event from comp: 932  event: 15
> 2016/10/05 14:14:24 http2: panic serving xxx.xxx.xxx.xxx:49337: runtime 
> error: index out of range
> goroutine 2962 [running]:
> net/http.(*http2serverConn).runHandler.func1(0xc82053df3f, 0xc8200f5180, 
> 0xc82007c2a0)
> /usr/local/go/src/net/http/h2_bundle.go:4050 +0xde
> panic(0xb24060, 0xc82000e0d0)
> /usr/local/go/src/runtime/panic.go:443 +0x521
> lib.setupC5Tab(0x7f6fbe169d20, 0xc8201b0d20, 0xc820436d98, 0x7f6fbe169d20, 
> 0xc8201b0dc0, 0x7f6fbe16a2a8, 0xc820339e60, 0x7f6fbe16a5f8, 0xc8201b0e60, 
> 0xc82047be20)
> /home/sysop/go/src/lib/rhewocompstatus.go:1310 +0x3976
> lib.BuildRhewoStatus.func4(0x7f6fbe117538, 0xc8205bc300)
> /home/sysop/go/src/lib/rhewocompstatus.go:168 +0xc8
> github.com/icza/gowut/gwu.handlerFuncWrapper.HandleEvent(0xc82040b5c0, 
> 0x7f6fbe117538, 0xc8205bc300)
> /home/sysop/go/src/github.com/icza/gowut/gwu/event.go:441 +0x3e
> github.com/icza/gowut/gwu.(*compImpl).dispatchEvent(0xc820158770, 
> 0x7f6fbe117538, 0xc8205bc300)
> /home/sysop/go/src/github.com/icza/gowut/gwu/comp.go:307 +0x167
> github.com/icza/gowut/gwu.(*timerImpl).dispatchEvent(0xc820158770, 
> 0x7f6fbe117538, 0xc8205bc300)
> :1302 +0x60
> github.com/icza/gowut/gwu.(*serverImpl).handleEvent(0xc82019e900, 
> 0x7f6fbe1172c0, 0xc8202fa7e0, 0x7f6fbe169998, 0xc8202b4ff0, 0x7f6fbe117170, 
> 0xc82007c2a0, 0xc820148460)
> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:815 +0x103e
> github.com/icza/gowut/gwu.(*serverImpl).serveHTTP(0xc82019e900, 
> 0x7f6fbe117170, 0xc82007c2a0, 0xc820148460)
> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:683 +0x1544
> github.com/icza/gowut/gwu.(*serverImpl).Start.func1(0x7f6fbe117170, 
> 0xc82007c2a0, 0xc820148460)
> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:483 +0x4c
> net/http.HandlerFunc.ServeHTTP(0xc82006d450, 0x7f6fbe117170, 0xc82007c2a0, 
> 0xc820148460)
> /usr/local/go/src/net/http/server.go:1618 +0x48
> net/http.(*ServeMux).ServeHTTP(0xc820070b10, 0x7f6fbe117170, 0xc82007c2a0, 
> 0xc820148460)
> /usr/local/go/src/net/http/server.go:1910 +0x213
> net/http.serverHandler.ServeHTTP(0xc8200e4200, 0x7f6fbe117170, 
> 0xc82007c2a0, 0xc820148460)
> /usr/local/go/src/net/http/server.go:2081 +0x207
> net/http.initNPNRequest.ServeHTTP(0xc8201d4300, 0xc8200e4200, 
> 0x7f6fbe117170, 0xc82007c2a0, 0xc820148460)
> /usr/local/go/src/net/http/server.go:2489 +0x351
> net/http.(*initNPNRequest).ServeHTTP(0xc8201d8b20, 0x7f6fbe117170, 
> 0xc82007c2a0, 0xc820148460)
> :253 +0xdb
> net/http.(Handler).ServeHTTP-fm(0x7f6fbe117170, 0xc82007c2a0, 0xc820
> /usr/local/go/src/net/http/h2_bundle.go:3847 +0x5e
> net/http.(*http2serverConn).runHandler(0xc8200f5180, 0xc82007c2a0, 0
> /usr/local/go/src/net/http/h2_bundle.go:4060 +0xad
> created by net/http.(*http2serverConn).processHeaderBlockFragment
> /usr/local/go/src/net/http/h2_bundle.go:3853 +0x7c3
>
>

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

Re: [go-nuts] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Andrew Gerrand]

On 28 October 2016 at 03:53, mjy  wrote:

> It's partly a cultural thing, I suppose. Some people consider the e-mail
> bland, others (like me) threatening. Someone should educate the CoC crew
> about these cultural, perhaps personality differences so they can improve
> their tone to avoid unnecessary escalation.


We are definitely still learning, and I think it's clear that we missed the
mark communicating with Aram here. It was not, and would never be, our
intention to come across as threatening or harsh. I am dismayed by how this
turned out. This will certainly inform our actions in the future.

Andrew

-- 
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: Stopping a server

[Peter Mogensen]

On 2016-10-27 21:34, Nick Patavalis wrote:


These is no way to (positively) know when the server will enter the
"running state". Think of this sequence:

go func () {
err := srv.Serve() // or .Start()
srvEnd <- err
}

... a short time after ...

srv.Stop() // Serve() has been entered, but has not yet set
   // the "running" flag to true. Stop() is dropped.
 <- srvEnd // May wait forever!



The problem you seem to be trying to solve here is for the caller of 
Shutdown() to know when the Server has exited Serve().
The way to do that under "my" semantics to implement a Server letting 
you wait for it to be ready to acknowlede Shutdown()


A Serve() implementation could  be done in many ways (it doesn't have to 
drop Shutdown() ) ... to to extend the example it could easily once in 
running state send an event on a channel you could wait on (or use a 
CondVar)


So ...

 func (s *Server) Serve() {
runmu.Lock()
s.running = true
runmu.Unlock()

s.IsRunningChan <- true

 }

 go func () {
err := srv.Serve()
srvEnd <- err
 }

 ... a short time after ...

 <- srv.IsRunningChan

 srv.Stop()

  <- srvEnd



Yes... but what about multiple Shutdown() invokations?



No problem. Under "my" semantics, once you call Shutdown() on a server
instance it cannot run again, unless you explicitly call Reset().


Oh... I thought you argued against the 3rd method.


However... I can't really see that's the only valid semantics. Specifically
... if I want to tie the Shutdown() signal to an OS Signal (like SIGTERM)...
then how do I know which Serve() invocation to cancel?


If you want to cancel all of them, then the SIGTERM handler will have
to loop over and call the "cancel"s for all contexts. No ambiguity
there.



But how do you determine what is "all" contexts without a race condition?
You'll have to register every Serve() invocation with its context 
somewhere protected by a global mutex. ... and de-register on Exit 
(since you cannot call CancelFunc() twice ... (closing a closed channel 
will panic).


You semantics has it's use cases... if you want to know exactly which 
Serve() invocation you cancel ... but it seems to me that it complicates 
the os.Signal use case ... which has almost the async semantics I use.


/Peter

--
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: Float32 math and slice arithmetics using SIMD

['simon place' via golang-nuts]

> Something like that?

short answer, Yes.

however, from looking at it, couldn’t find documentation, that code is 
specific to speeding up graphics overlays? maybe? (accumulate)

but it’s confusing me that its using templates, when there seems to only be 
one template.

i was thinking of one, very simple, template per function, per h/w 
feature;  

so one each for;
Sqrt(X+k) [4]float32 on SSE4,
Sqrt(X+k) [4]float32 on NEON,
Sqrt(X+k) [4]float64 on AVX2
Sqrt(X+k) [8]float32 on AVX2
k1/Sqrt(X+k2) on SSE4
...

which leads to a big, but i think a maintainable, collection. 

maintainable because, used in linear combinations, without adding that much 
overhead, stops the number rising at a high ordered rate, only functions 
with an element that has parallel support in the CPU have any point in 
being added, and since this would be open source, contributions of 
functions someone's added themselves could be contributed back.

which is why i was wanting NEON support to begin with, so there could be a 
general outline onto which contributions could be made, most of the time it 
would just be a simple modification/extension of a basic pool.



 


-- 
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: Stopping a server

[Nick Patavalis]

Hi,

On Thu, Oct 27, 2016 at 9:34 PM, Peter Mogensen  wrote:
>
> Technically that depends on the Server implementation.
> But in the provided http.Server extension, the answer is "nothing":
>
> func (srv *Server) Shutdown() {
> srv.runlock.Lock()
> defer srv.runlock.Unlock()
> if !srv.running {
> return
> }
> <-srv.shutdown
> }
>
>> If the
>> answer is "nothing" then there is necessarily a small window of time,
>> after calling "Serve()" when shutdown calls will be ignored.
>
> Yes... but the semantics are clear. Shutdown() is an sync signal which will
> be ignored by servers not in a running state.
>

Yes and that's *exactly* my (only) concern with the semantics you
"propose" (otherwise I agree with you):

These is no way to (positively) know when the server will enter the
"running state". Think of this sequence:

go func () {
err := srv.Serve() // or .Start()
srvEnd <- err
}

... a short time after ...

srv.Stop() // Serve() has been entered, but has not yet set
   // the "running" flag to true. Stop() is dropped.
 <- srvEnd // May wait forever!

Of course the time window after calling Serve() / Start() and before
the server enters the "running state" is very short, and *practically*
an occurrence such as the above will be *very* unlike, but still, no
matter how unlike, *there is a race* and I see no way to avoid it.

> The only other well defined semantics I can see is that any Shutdown() on a
> Server will make any current and future Serve() exit.

Yes, these are the only semantics (I see) as been "race-free", and
that's why I wrote that it "has" to be so.

> But this would prevent a restart of the Server.

My point, unless you provide an additional method, like Reset().

>
> Yes... but what about multiple Shutdown() invokations?
>

No problem. Under "my" semantics, once you call Shutdown() on a server
instance it cannot run again, unless you explicitly call Reset().

>
> There is a 3rd method ... (namely Wait() ) ... but it's not used for that.
> It's used for Servers which can be restarted before they are completely
> cleaned up. ... like in the provided http.Server extension where the old
> connectionManager can keep on shutting down HTTP Keepalive connections while
> the server object is restarted.
>

Ok, such behavior is irrelevant in my case: That is, in my case, once
Serve() / Start() returns, there is nothing remaining running, related
to that server.

> The thing you get from Context is just a way to supply the channel used for
> signaling from the outside for every Serve(Context) call. So you know
> exactly which invocation of Serve() you are canceling.
>
> In that regard you are right.

Exactly.

> However... I can't really see that's the only valid semantics. Specifically
> ... if I want to tie the Shutdown() signal to an OS Signal (like SIGTERM)...
> then how do I know which Serve() invocation to cancel?

If you want to cancel all of them, then the SIGTERM handler will have
to loop over and call the "cancel"s for all contexts. No ambiguity
there.

/npat

-- 
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: Stopping a server

[Peter Mogensen]

On 2016-10-27 19:32, Nick Patavalis wrote:

type Server interface {
Serve() error // start serving and block until exit
Shutdown()// async req. to shutdown, must not block
}


The "subtle races" I was talking about:

What happens if you call "Shutdown()" before you call Serve()?


Technically that depends on the Server implementation.
But in the provided http.Server extension, the answer is "nothing":

func (srv *Server) Shutdown() {
srv.runlock.Lock()
defer srv.runlock.Unlock()
if !srv.running {
return
}
<-srv.shutdown
}



If the
answer is "nothing" then there is necessarily a small window of time,
after calling "Serve()" when shutdown calls will be ignored.


Yes... but the semantics are clear. Shutdown() is an sync signal which 
will be ignored by servers not in a running state.


The only other well defined semantics I can see is that any Shutdown() 
on a Server will make any current and future Serve() exit.

But this would prevent a restart of the Server.


So the
answer *has* to be: "the server will stop immediately after it's
started" (i.e. the server will "remember" the shutdown). Fine so far.


That's a nother way to define the semantics yes - but I don't see it as 
something which "has" to be.
Think of the Shutdown() signal as a datagram message. It might get lost 
if the server is not in a running state.


But you could easily implement a Server satisfying the same interface, 
behaving as you suggest - making the Server unable to Serve() also 
future invocations of Serve().



Now what happens if I want to re-start the same server after a
shutdown?


That's why it isn't done like that. If you by Shutdown() put also a 
non-running Server in disabled state, then you would have to invent some 
semantics of handling cases like:


Shutdown()
Shutdown()
Serve()
Serve()

Do you throw away the second Shutdown() event? If you do - then what's 
the difference? ... If you don't then will second Serve() also exit?


To me it's much simpler to just regard the Shutdown() as an async 
message with datagram semantics. You can always know if it was obeyed by 
waiting for Serve() to exit ... or use the ShutdownOK() bool function.



Since the server remembers the shutdown, then the newly
started server will immediately stop.


Yes... but what about multiple Shutdown() invokations?


If the server somehow "clears"
the shutdown, just before terminating, then there is again a small
window of time, before the server returns, when the shutdown will be
inadvertently set for the *next* server run.


Ah... no...
There's not "next" Server. You only have one object. Shutdown() asks to 
stop any running state it might have. If the same object is restarted, 
you still want it to stop by calling Shutdown().



In effect, you need a third method (something like: "Reset()"). Which
must be called after the server shuts-down and before it can be
re-started. And of-course this has to be documented so that user can
understand these subtle issues...


There is a 3rd method ... (namely Wait() ) ... but it's not used for that.
It's used for Servers which can be restarted before they are completely 
cleaned up. ... like in the provided http.Server extension where the old 
connectionManager can keep on shutting down HTTP Keepalive connections 
while the server object is restarted.



Alternatively, you can make it impossible for the same server
instance to be started, once it has been shutdown... Which is not
something I like very much.


The interface only defined Serve() and Shutdown() semantics (and 
Listen() and Wait() )

The docs does say that:
--
"Server is an server started by the master MultiServer, by calling 
Serve() which is expected to block

until the server is signaled to stop by an invocation of Shutdown()
Calling Shutdown() should start the shutdown process and return 
immediately, causing Serve() to exit. If the server implements Wait() 
its Serve() method can exit asynchronously before shutdown is fully 
completed. The master server will call Wait() before any restart of the 
server.


 If Serve() returns no error, the master server regards the server as 
fully finished and ready to (maybe) be restarted by another invocation 
of the master MultiServer Serve() method."

-

... it doesn't prevent you from implementing a broken server which will 
not obey that... However... that would be just as wrong as implementing 
a Serve() method which never exited.



On the other hand, using a context to handle termination avoids these
issues: A context is in-fact a termination token associated with a
single *RUN* of the server. This solves all these pesky problems.


Many shutdown schemes involves some channel to signal shutdown/cancel. 
In the http.Server mentioned above the channel is read by the Shutdown() 
... it could also be closed by Shutdown() ... there are pros and cons.
A Context use the

Re: [go-nuts] Re: Go interface

[Rob Pike]

Cleaner and a little more explicit, making it more obvious what's being
asserted (although a comment would be welcome):

var _ Animal = MammalInt(nil) // if pointer
var _ Animal = MammalInt{} // if just a struct


On Thu, Oct 27, 2016 at 10:08 AM, Tamás Gulácsi 
wrote:

> It's very easy to ensure sth implements an interface:
>
> ```
> var _ = Animal(MammalInt(nil)) // if pointer
> var _ = Animal(MammalInt{}) // if just a struct
> ```
>
> 2016. október 27., csütörtök 9:11:04 UTC+2 időpontban Arafath M a
> következőt írta:
>>
>> Hi,
>>
>> Using interface is easy in Go. But, while studying an existing code
>> base, it is very difficult to find which types have implementation of a
>> particular interface. The situation will become worse, if there are many
>> interface functions inside an interface definition.
>>
>> In another languages, it is easy to just search for the class, which
>> implements a particular interface.
>>
>> For example in Java,
>>
>> interface Animal {
>>public void eat();
>>public void travel();
>> }
>>
>> public class MammalInt implements Animal {
>>
>>public void eat() {
>>   System.out.println("Mammal eats");
>>}
>>
>>public void travel() {
>>   System.out.println("Mammal travels");
>>}
>>
>>public int noOfLegs() {
>>   return 0;
>>}
>>
>>public static void main(String args[]) {
>>   MammalInt m = new MammalInt();
>>   m.eat();
>>   m.travel();
>>}
>> }
>>
>> By seeing the above line "*public class MammalInt **implements Animal*" one
>> can easily understand that Animal interface is implemented in MammalInt
>>
>> In Go, as far as I know, I need to search for all interface functions to
>> find whether a type implements a particular interface or not.
>>
>> Have anybody else experienced the same? If yes, what is the solution?
>>
>> *Note:* Personally I like to write code in Go; all of my recent projects
>> are in Go. I prefer Go than Java.
>>
>> Sincerely,
>> Arafath M
>>
> --
> 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: [golang-dev] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Russ Cox]

+golang-nuts bcc golang-dev

On Thu, Oct 27, 2016 at 1:30 PM Ugorji  wrote:

> I understand the sentiment, and why someone might choose to report this.
> But I agree with Aram that the response was very heavy-handed and
> threatening, especially for what is a very minor and border-line subjective
> violation of the code of conduct. A response informing Aram of the concern
> of the reporter, and asking him to try and be conscious of XYZ should have
> been sufficient, without the "this is a violation ... you are hereby warned
> ... let us know if this is not clear" response.
>
> It's good that this was reported on golang-dev (not golang-nuts IMO), so
> we can have a discussion about it and fix it.
>
> Just my 2 cents!
>
> On Thursday, October 27, 2016 at 11:58:53 AM UTC-4, Aram Hăvărneanu wrote:
>
> On Thu, Oct 27, 2016 at 5:36 PM,   wrote:
> > I do want to emphasize the last line of the email we sent, which does
> not
> > appear in your post here:
> >
> >   Please feel free to reach out if you have any questions or concerns.
>
> Except that is not what it says: http://i.imgur.com/MoyPKpg.png
>
> Why did you add the word "please" now in here, where it wasn't in the
> original? Normally I wouldn't dream of caring about something as minor
> as this, but you are trying to create a narrative that doesn't exist.
> When my main complaint is about secret courts and lack of
> transparency, this does not fare well for your argument.
>
> --
> Aram Hăvărneanu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+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: Stopping a server

[Nick Patavalis]

On Thursday, October 27, 2016 at 6:35:40 PM UTC+3, Peter Mogensen wrote:
>
> It's a valid question whether Context is the concept to use for starting
> and stopping server instances. ... I'm not fully convinced. It seems to
> me it's more meaningfull for more transient things like Requests.

On Thu, Oct 27, 2016 at 8:21 PM, Diego Medina  wrote:
> As a user of a package, if I "start it" by calling Start(), I will most
> likely look for a "Stop()" function but calling cancel on the context
> wouldn't feel natural because I'm not canceling the server, I would be done
> with it and don't need it any more).
>

That was my thought too, BUT (and this is what's nagging me) it is a fact that
using a context saves you from some subtle race-conditions that are present in
the Serve() / Shutdown() interface you 're proposing, and has much cleaner
semantics.

> Servers are basically started by calling Serve() ... which blocks until
> someone, somewhere invokes Shutdown()
>
> The whole daemon process can manage any number of objects implementing:
>
> type Server interface {
> Serve() error // start serving and block until exit
> Shutdown()// async req. to shutdown, must not block
> }

The "subtle races" I was talking about:

What happens if you call "Shutdown()" before you call Serve()? If the
answer is "nothing" then there is necessarily a small window of time,
after calling "Serve()" when shutdown calls will be ignored. So the
answer *has* to be: "the server will stop immediately after it's
started" (i.e. the server will "remember" the shutdown). Fine so far.

Now what happens if I want to re-start the same server after a
shutdown? Since the server remembers the shutdown, then the newly
started server will immediately stop. If the server somehow "clears"
the shutdown, just before terminating, then there is again a small
window of time, before the server returns, when the shutdown will be
inadvertently set for the *next* server run.

In effect, you need a third method (something like: "Reset()"). Which
must be called after the server shuts-down and before it can be
re-started. And of-course this has to be documented so that user can
understand these subtle issues...

Alternatively, you can make it impossible for the same server
instance to be started, once it has been shutdown... Which is not
something I like very much.

On the other hand, using a context to handle termination avoids these
issues: A context is in-fact a termination token associated with a
single *RUN* of the server. This solves all these pesky problems.

Any thoughts on this would be greatly appreciated...

/npat

-- 
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] Suggestion: port golang.org/x/mobile/exp/audio/al to Windows

[faiface2202]

Hi there,

recently I posted a question in this group asking why 
golang.org/x/mobile/exp/audio/al doesn't support Windows. I've got one 
answer, saying something like: "it belongs to golang.org/x/mobile, so 
that's why".
However, *there is no single satisfying multiplatform audio library for Go*, 
out there!

Since golang.org/x/mobile/exp/audio/al looks quite solid + OpenAL is really 
multiplatform, *I strongly suggest someone ports it to Windows*. It already 
supports Mac OS X and Linux, so why not.

It could potentially be also moved to a different address after, because a 
completely multiplatform (Windows, Mac, Linux, Android, ...)  audio library 
doesn't really belong to a mobile suite.


*Porting this library to Windows would really shift multimedia development 
in Go forward.*
Thanks
Michal Štrba

-- 
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: Stopping a server

[Diego Medina]

As a user of a package, if I "start it" by calling Start(), I will most 
likely look for a "Stop()" function but calling cancel on the context 
wouldn't feel natural because I'm not canceling the server, I would be done 
with it and don't need it any more).

Regards,


On Thursday, October 27, 2016 at 10:11:34 AM UTC-4, Nick Patavalis wrote:
>
> Hi, 
>
> I'm writing a package that allows the user to create and start server 
> instances. A server instance is created like this: 
>
>   srv := pkg.NewServer( ... params ... ) 
>
> and started like this: 
>
>   err := srv.Start() 
>
> Start does not normally return (unless an unrecoverable error 
> occurs). The user code can invoke Start() in a goroutine in order to run 
> multiple servers (which is not uncommon). 
>
> I want to give the user-code the ability to stop servers when 
> required. One thought is to use "context.Context" for this purpose. That 
> is, the server could be started like this: 
>
>   ctx, cancel := context.WithCancel(context.Background()) 
>   ... 
>   err := srv.Start(ctx) 
>
> and stopped by calling the "cancel" function of the context. 
>
> I konw that, functionally, this will work. My question is: Does this 
> look like a "reasonable" / "idiomatic" use of contexts?  Or will it 
> look "alien" to the user? I'm asking since the documentation of 
> "context" mentions it being used for "request-scoped" stuff, and this 
> is not exactly the case here. 
>
> I can instead add a Stop() method to "srv" and roll-my-own stopping 
> logic. 
>
> Which would you choose? 
>
> /npat 
>

-- 
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] Tooling experience feedback

[Edward Muller]

We have so many Makefiles that encode $(go list ./... | grep -v vendor) in
one way or another it IS kind of funny. A `novendor` flag of some sort to
most tools that take package specs would be so so so so nice.

On Thu, Oct 27, 2016 at 8:56 AM Russ Cox  wrote:

> FWIW 'go help all' is essentially 'go doc go'.
>
> On Fri, Oct 21, 2016 at 9:46 AM Mathieu Lonjaret <
> mathieu.lonja...@gmail.com> wrote:
>
> As you said, sometimes one is not sure in which X for "go help X" one
> might find the information they're looking for. So one can end up
> trying several of them before finding the relevant info. I can think
> of one way that would alleviate that pain a bit: something like a "go
> help all" command that would print all the topics in one go. Makes it
> easier to pipe it to grep/less and search for specific things.
>
>
> On 18 October 2016 at 20:54, 'Jaana Burcu Dogan' via golang-nuts
>  wrote:
> > Hello gophers,
> >
> > I am going to spend some time on improving the not-documented or
> hard-to-use
> > parts of the Go tools. I will mainly focus on go build and go test. The
> work
> > will consist of reorganizing manuals, proposing new subcommands or flags
> to
> > support commonly used multi-step things and so on.
> >
> > To give you some concrete examples:
> >
> > I have been in cases where users cannot find the build flags because they
> > are hidden. E.g.
> >
> > $ go test -help
> > test [build/test flags] [packages] [build/test flags & test binary
> > flags]
> > ...
> >
> > requires you to know about where the build flags are. Some tools are
> > invisible for the newcomers.
> >
> > The other example is about test coverage. It is so tedious that I need an
> > alias.
> >
> > func gocover() {
> > go test -v -coverprofile=coverage.out && go tool cover
> > -html=coverage.out
> > }
> >
> > I want to learn more about your experience, aliases, etc to propose
> > improvements and work on the most commonly suggested items. I also am
> > planning to go through this mailing list, stack overflow and other
> channels
> > to see the common complaints.
> >
> > Feel free to reply to this thread or write to me privately.
> >
> > Thanks,
> > JBD
> >
> > --
> > 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.
>
> --
> 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] Is ROC part of 1.8?

[Chandru]

Is the request-oriented GC slated to be included in the 1.8 release?

--
Chandra Sekar.S

-- 
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: Go interface

[Tamás Gulácsi]

It's very easy to ensure sth implements an interface:

```
var _ = Animal(MammalInt(nil)) // if pointer
var _ = Animal(MammalInt{}) // if just a struct
```

2016. október 27., csütörtök 9:11:04 UTC+2 időpontban Arafath M a 
következőt írta:
>
> Hi,
>
> Using interface is easy in Go. But, while studying an existing code base, 
> it is very difficult to find which types have implementation of a 
> particular interface. The situation will become worse, if there are many 
> interface functions inside an interface definition.
>
> In another languages, it is easy to just search for the class, which 
> implements a particular interface.
>
> For example in Java,
>
> interface Animal {
>public void eat();
>public void travel();
> }
>
> public class MammalInt implements Animal {
>
>public void eat() {
>   System.out.println("Mammal eats");
>}
>
>public void travel() {
>   System.out.println("Mammal travels");
>} 
>
>public int noOfLegs() {
>   return 0;
>}
>
>public static void main(String args[]) {
>   MammalInt m = new MammalInt();
>   m.eat();
>   m.travel();
>}
> }
>
> By seeing the above line "*public class MammalInt **implements Animal*" one 
> can easily understand that Animal interface is implemented in MammalInt 
>
> In Go, as far as I know, I need to search for all interface functions to 
> find whether a type implements a particular interface or not.
>
> Have anybody else experienced the same? If yes, what is the solution? 
>
> *Note:* Personally I like to write code in Go; all of my recent projects 
> are in Go. I prefer Go than Java.
>
> Sincerely,
> Arafath M
>

-- 
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: golang too many json unmarshal trigger gc frequency to many

[Tamás Gulácsi]

If you can't avoid generating garbage, then at least try to reuse it!
That's what sync.Pool is for (don't make the map, reuse one).

Can't you read the Redis reply by chunks?

2016. október 27., csütörtök 4:29:01 UTC+2 időpontban 刘桂祥 a következőt írta:
>
> 
>   In my server many requests need to handle a loop to unmarshal json 
> strings and I find gc is very frequency 
>
>
>
>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[mjy]

Am Donnerstag, 27. Oktober 2016 18:11:16 UTC+2 schrieb Nate Finch:
>
> It seems like most of the problem with this whole situation comes from the 
> wording of the "warning"  
>
> Please consider this a warning from the Code of Conduct working group.
>>
>
>  "consider this a warning" can be interpreted as a threat (though the 
> "Please" in front should soften it somewhat).  I don't think it was 
> intended as such, but I think it's clear some people do read it that way. 
>  Perhaps just a rewording would prevent such a reaction in the future.
>

It's partly a cultural thing, I suppose. Some people consider the e-mail 
bland, others (like me) threatening. Someone should educate the CoC crew 
about these cultural, perhaps personality differences so they can improve 
their tone to avoid unnecessary escalation.


-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Henrik Johansson]

To me the wording with a warning in it sounds extremely harsh. Adding any
number of pleases only makes it worse. I still think this should not have
been acted upon at all. What sort of de facto empirical outcome has there
been previously? Are there any previous incidents that have not gone
public?

On Thu, Oct 27, 2016, 18:53 mjy  wrote:

> Am Donnerstag, 27. Oktober 2016 18:11:16 UTC+2 schrieb Nate Finch:
>
> It seems like most of the problem with this whole situation comes from the
> wording of the "warning"
>
> Please consider this a warning from the Code of Conduct working group.
>
>
>  "consider this a warning" can be interpreted as a threat (though the
> "Please" in front should soften it somewhat).  I don't think it was
> intended as such, but I think it's clear some people do read it that way.
> Perhaps just a rewording would prevent such a reaction in the future.
>
>
> It's partly a cultural thing, I suppose. Some people consider the e-mail
> bland, others (like me) threatening. Someone should educate the CoC crew
> about these cultural, perhaps personality differences so they can improve
> their tone to avoid unnecessary escalation.
>
>
> --
> 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: Why does a "concurrent" Go GC phase appear to be stop-the-world?

[Dave Cheney]

Thanks for confirming that CL 23540 has reduced STW delays.

On Friday, 28 October 2016 03:52:29 UTC+11, Will Sewell wrote:
>
> Are you referring to https://go-review.googlesource.com/#/c/23540/ or 
> https://github.com/golang/go/issues/16528? If it's the former, then yes I 
> have tried the benchmark with the HEAD version on master of the compiler, 
> and it did bring the pause down to ~7.7ms. I was under the impression the 
> latter issue has not been fixed yet, and is the reason the pause time was 
> not even lower.
>
> On Wednesday, 26 October 2016 21:45:59 UTC+1, Dave Cheney wrote:
>>
>> Will, the changes has been in master for a few months now, are you able 
>> to build master from source and see if this has addressed the issue? I'm 
>> sure Rick and Austin would appreciate the feedback.
>>
>> On Thursday, 27 October 2016 01:46:47 UTC+11, Will Sewell wrote:
>>>
>>> Thanks for the information. I think it could well be caused by that. 
>>> Below is the screenshot of one of the periods of time where the mutator is 
>>> blocked.
>>>
>>>
>>> 
>>>
>>>
>>> Note: pause times were as high as 15ms with the tracer enabled.
>>>
>>> Similar sizes occur every ~100ms.
>>>
>>> Let's hope this gets resolved in Go1.8 :)
>>>
>>> On Monday, 24 October 2016 17:06:59 UTC+1, rhys.h...@gmail.com wrote:

 Yes, this sounds like https://golang.org/issue/16528. During the 
 concurrent mark phase (the "27 [ms]" of "0.008+27+0.072 ms clock"), both 
 your code and the garbage collector are running. The program is allowed to 
 use four OS threads ("4 P"), which might be executing your code in your 
 goroutines, or might be running GC code in dedicated GC goroutines.

 There's plenty of work for the GC to do, so when a GC helper goroutine 
 is allowed to have some processing time it'll keep running until it has 
 used up all of its allowed time—ten milliseconds. If all four threads end 
 up running GC goroutines at the same time, your goroutine will need to 
 wait 
 until one of them has run for about 10ms before it can be scheduled again. 
 This can lead to individual goroutines being paused for up to 10ms.

 You might be able to see this with the execution tracer, but it's not 
 an easy tool to use. See package "runtime/trace" and the command "go tool 
 trace" for some hints. Issue 16528 includes some screenshots of the tool.

 On Thursday, October 20, 2016 at 6:36:27 AM UTC-7, Will Sewell wrote:
>
> Interesting, that does sound like it could be the cause.
>
> I just tried running the same benchmark on master 
> (692df217ca21b6df8e4dc65538fcc90733e8900e), and I get the following 
> results:
>
> gc 1 @0.004s 3%: 0.009+0.41+0.049 ms clock, 0.036+0.11/0.36/0.12+0.19 
> ms cpu, 4->4->3 MB, 5 MB goal, 4 P
> gc 2 @0.008s 4%: 0.008+0.80+0.035 ms clock, 0.034+0.097/0.67/0.16+0.14 
> ms cpu, 7->7->7 MB, 8 MB goal, 4 P
> gc 3 @0.016s 3%: 0.010+0.91+0.044 ms clock, 0.041+0/0.31/0.79+0.17 ms 
> cpu, 13->15->14 MB, 15 MB goal, 4 P
> gc 4 @0.032s 3%: 0.009+2.3+0.10 ms clock, 0.037+0.60/2.0/0.12+0.40 ms 
> cpu, 27->28->27 MB, 29 MB goal, 4 P
> gc 5 @0.070s 3%: 0.010+7.6+0.068 ms clock, 0.043+0.79/5.4/8.5+0.27 ms 
> cpu, 51->53->51 MB, 54 MB goal, 4 P
> gc 6 @0.149s 3%: 0.020+8.2+0.12 ms clock, 0.081+0.56/7.2/9.7+0.48 ms 
> cpu, 98->102->99 MB, 103 MB goal, 4 P
> gc 7 @0.282s 4%: 0.028+21+0.082 ms clock, 0.11+10/20/1.9+0.32 ms cpu, 
> 190->195->190 MB, 198 MB goal, 4 P
> gc 8 @0.568s 3%: 0.024+24+0.080 ms clock, 0.098+0/23/41+0.32 ms cpu, 
> 364->376->214 MB, 381 MB goal, 4 P
> gc 9 @0.816s 3%: 0.008+27+0.072 ms clock, 0.035+0/25/34+0.29 ms cpu, 
> 412->420->213 MB, 428 MB goal, 4 P
> gc 10 @1.064s 3%: 0.009+31+0.10 ms clock, 0.039+6.1/26/33+0.41 ms cpu, 
> 415->427->216 MB, 427 MB goal, 4 P
>
> My manually calculated worst time for a call to mkMessage is 7.73812ms, 
> which is much better than before. It's significantly faster than the 
> worst 
> wall clock time for the concurrent mark/scan phase, but it's also much 
> slower than the worst STW phase. Do you know why this might be?
>
> Best,
> Will
>
> On Wednesday, 19 October 2016 17:29:23 UTC+1, rhys.h...@gmail.com 
> wrote:
>>
>> Yes, this sounds a lot like https://golang.org/issue/16293, where 
>> goroutines that allocate memory while the garbage collector is running 
>> can 
>> end up stalled for nearly the entire GC cycle, in programs where a large 
>> amount of the memory is in a single allocation. For the program you've 
>> shared, that would be the "channel" map. The bug is present in Go 
>> 1.5–1.7, 
>> and is fixed in tip (via CL 23540).
>>
>> Do yo

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

[Will Sewell]

Are you referring to https://go-review.googlesource.com/#/c/23540/ 
or https://github.com/golang/go/issues/16528? If it's the former, then yes 
I have tried the benchmark with the HEAD version on master of the compiler, 
and it did bring the pause down to ~7.7ms. I was under the impression the 
latter issue has not been fixed yet, and is the reason the pause time was 
not even lower.

On Wednesday, 26 October 2016 21:45:59 UTC+1, Dave Cheney wrote:
>
> Will, the changes has been in master for a few months now, are you able to 
> build master from source and see if this has addressed the issue? I'm sure 
> Rick and Austin would appreciate the feedback.
>
> On Thursday, 27 October 2016 01:46:47 UTC+11, Will Sewell wrote:
>>
>> Thanks for the information. I think it could well be caused by that. 
>> Below is the screenshot of one of the periods of time where the mutator is 
>> blocked.
>>
>>
>> 
>>
>>
>> Note: pause times were as high as 15ms with the tracer enabled.
>>
>> Similar sizes occur every ~100ms.
>>
>> Let's hope this gets resolved in Go1.8 :)
>>
>> On Monday, 24 October 2016 17:06:59 UTC+1, rhys.h...@gmail.com wrote:
>>>
>>> Yes, this sounds like https://golang.org/issue/16528. During the 
>>> concurrent mark phase (the "27 [ms]" of "0.008+27+0.072 ms clock"), both 
>>> your code and the garbage collector are running. The program is allowed to 
>>> use four OS threads ("4 P"), which might be executing your code in your 
>>> goroutines, or might be running GC code in dedicated GC goroutines.
>>>
>>> There's plenty of work for the GC to do, so when a GC helper goroutine 
>>> is allowed to have some processing time it'll keep running until it has 
>>> used up all of its allowed time—ten milliseconds. If all four threads end 
>>> up running GC goroutines at the same time, your goroutine will need to wait 
>>> until one of them has run for about 10ms before it can be scheduled again. 
>>> This can lead to individual goroutines being paused for up to 10ms.
>>>
>>> You might be able to see this with the execution tracer, but it's not an 
>>> easy tool to use. See package "runtime/trace" and the command "go tool 
>>> trace" for some hints. Issue 16528 includes some screenshots of the tool.
>>>
>>> On Thursday, October 20, 2016 at 6:36:27 AM UTC-7, Will Sewell wrote:

 Interesting, that does sound like it could be the cause.

 I just tried running the same benchmark on master 
 (692df217ca21b6df8e4dc65538fcc90733e8900e), and I get the following 
 results:

 gc 1 @0.004s 3%: 0.009+0.41+0.049 ms clock, 0.036+0.11/0.36/0.12+0.19 
 ms cpu, 4->4->3 MB, 5 MB goal, 4 P
 gc 2 @0.008s 4%: 0.008+0.80+0.035 ms clock, 0.034+0.097/0.67/0.16+0.14 
 ms cpu, 7->7->7 MB, 8 MB goal, 4 P
 gc 3 @0.016s 3%: 0.010+0.91+0.044 ms clock, 0.041+0/0.31/0.79+0.17 ms 
 cpu, 13->15->14 MB, 15 MB goal, 4 P
 gc 4 @0.032s 3%: 0.009+2.3+0.10 ms clock, 0.037+0.60/2.0/0.12+0.40 ms 
 cpu, 27->28->27 MB, 29 MB goal, 4 P
 gc 5 @0.070s 3%: 0.010+7.6+0.068 ms clock, 0.043+0.79/5.4/8.5+0.27 ms 
 cpu, 51->53->51 MB, 54 MB goal, 4 P
 gc 6 @0.149s 3%: 0.020+8.2+0.12 ms clock, 0.081+0.56/7.2/9.7+0.48 ms 
 cpu, 98->102->99 MB, 103 MB goal, 4 P
 gc 7 @0.282s 4%: 0.028+21+0.082 ms clock, 0.11+10/20/1.9+0.32 ms cpu, 
 190->195->190 MB, 198 MB goal, 4 P
 gc 8 @0.568s 3%: 0.024+24+0.080 ms clock, 0.098+0/23/41+0.32 ms cpu, 
 364->376->214 MB, 381 MB goal, 4 P
 gc 9 @0.816s 3%: 0.008+27+0.072 ms clock, 0.035+0/25/34+0.29 ms cpu, 
 412->420->213 MB, 428 MB goal, 4 P
 gc 10 @1.064s 3%: 0.009+31+0.10 ms clock, 0.039+6.1/26/33+0.41 ms cpu, 
 415->427->216 MB, 427 MB goal, 4 P

 My manually calculated worst time for a call to mkMessage is 7.73812ms, 
 which is much better than before. It's significantly faster than the worst 
 wall clock time for the concurrent mark/scan phase, but it's also much 
 slower than the worst STW phase. Do you know why this might be?

 Best,
 Will

 On Wednesday, 19 October 2016 17:29:23 UTC+1, rhys.h...@gmail.com 
 wrote:
>
> Yes, this sounds a lot like https://golang.org/issue/16293, where 
> goroutines that allocate memory while the garbage collector is running 
> can 
> end up stalled for nearly the entire GC cycle, in programs where a large 
> amount of the memory is in a single allocation. For the program you've 
> shared, that would be the "channel" map. The bug is present in Go 
> 1.5–1.7, 
> and is fixed in tip (via CL 23540).
>
> Do you still see the problem if you run the program with the current 
> development version of Go?
>
> On Wednesday, October 19, 2016 at 6:10:23 AM UTC-7, r...@golang.org 
> wrote:
>>
>> This is likely 23540 

Re: [go-nuts] iconvg: a compact, binary format for simple vector graphics

[Pietro Gagliardi]

Ah, I see; that also explains the funny "Bogus doctype." message Firefox gives 
me in the view-source view.
> On Oct 27, 2016, at 12:35 PM, roger peppe  wrote:
> 
> The  URIs without which you can't know which elements and attributes are part of 
> the SVG spec.
> 
> 
> On 27 Oct 2016 17:51, "Pietro Gagliardi"  > wrote:
> What part of the document are you referring to?
> > On Oct 27, 2016, at 11:42 AM, roger peppe  > > wrote:
> >
> > On 26 October 2016 at 23:50, Nigel Tao  > > wrote:
> >> On Wed, Oct 26, 2016 at 7:20 PM, roger peppe  >> > wrote:
> >>> This cannot be understated. A well known tool generates SVGs that the
> >>> Go XML parser cannot parse because it uses XML directives to create XML
> >>> entities that contain XML elements when they're expanded.  This meant
> >>> we couldn't process them at all (we wanted to adjust the view
> >>> box parameter).
> >>
> >> Ooh, that's interesting. Can you share some more details?
> >
> > After some delving back into history, here's an example:
> >
> > https://api.jujucharms.com/charmstore/v5/~cf-charmers/trusty/cloudfoundry-205/archive/icon.svg
> >  
> > 
> >
> > --
> > 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] iconvg: a compact, binary format for simple vector graphics

[roger peppe]

The  wrote:

> What part of the document are you referring to?
> > On Oct 27, 2016, at 11:42 AM, roger peppe  wrote:
> >
> > On 26 October 2016 at 23:50, Nigel Tao  wrote:
> >> On Wed, Oct 26, 2016 at 7:20 PM, roger peppe 
> wrote:
> >>> This cannot be understated. A well known tool generates SVGs that the
> >>> Go XML parser cannot parse because it uses XML directives to create XML
> >>> entities that contain XML elements when they're expanded.  This meant
> >>> we couldn't process them at all (we wanted to adjust the view
> >>> box parameter).
> >>
> >> Ooh, that's interesting. Can you share some more details?
> >
> > After some delving back into history, here's an example:
> >
> > https://api.jujucharms.com/charmstore/v5/~cf-charmers/
> trusty/cloudfoundry-205/archive/icon.svg
> >
> > --
> > 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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Russ Cox]

On Thu, Oct 27, 2016 at 12:07 PM Pietro Gagliardi 
wrote:

> Did golang-dev stop sending emails? I haven't received anything since
> October 16. Or should I contact Google Groups support and/or my email
> provider?
>

golang-dev is still active. I'll look into your subscription and mail you
off list.

Russ

-- 
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: [golang-dev] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Sarah Adams]

You are right.
I typed that from memory. I should have double-checked the exact wording 
before posting.
  Feel free to reach out if you have any questions or concerns.
was the exact line.

On Thursday, October 27, 2016 at 9:05:21 AM UTC-7, Russ Cox wrote:
>
> +golang-nuts bcc golang-dev
>
> On Thu, Oct 27, 2016 at 11:58 AM Aram Hăvărneanu  > wrote:
>
>> On Thu, Oct 27, 2016 at 5:36 PM,  > 
>> wrote:
>> > I do want to emphasize the last line of the email we sent, which does 
>> not
>> > appear in your post here:
>> >
>> >   Please feel free to reach out if you have any questions or concerns.
>>
>> Except that is not what it says: http://i.imgur.com/MoyPKpg.png
>>
>> Why did you add the word "please" now in here, where it wasn't in the
>> original? Normally I wouldn't dream of caring about something as minor
>> as this, but you are trying to create a narrative that doesn't exist.
>> When my main complaint is about secret courts and lack of
>> transparency, this does not fare well for your argument.
>>
>> --
>> Aram Hăvărneanu
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-dev+...@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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Jordan Krage]

| I can vouch for this. It's especially embarrassing when you first mention 
it to them privately and resolve the issue, and then go ahead and mention 
it in the meeting anyway, or use it as an excuse for new policies set in 
that meeting. There is one particular space I left because of this, but I 
will not elaborate.

This analogy is not appropriate.

Consider if someone wrote something on a whiteboard, or hung something in 
their office, which violated the code of conduct.  Would you speak to them 
privately, but leave it up for everyone to see, without ever addressing it 
publicly?  To outside observers, that behavior would appear to be 
acceptable.  There is no way for them to understand that a violation 
occurred.

On Thursday, October 27, 2016 at 11:07:50 AM UTC-5, Pietro Gagliardi 
(andlabs) wrote:
>
>
> On Oct 27, 2016, at 11:49 AM, Andrew Gerrand  > wrote:
>
> I have done this before, and it has not gone well. People feel humiliated 
> when called out publicly. 
>
> Imagine this happened in a workplace. Do you bring it up at the team 
> meeting? Or take them aside and mention it to them in private?
>
> I can vouch for this. It's especially embarrassing when you first mention 
> it to them privately and resolve the issue, and then go ahead and mention 
> it in the meeting anyway, or use it as an excuse for new policies set in 
> that meeting. There is one particular space I left because of this, but I 
> will not elaborate.
>
>
> On Oct 27, 2016, at 11:44 AM, Nigel Vickers  > wrote:
>
> Hallo Aram, 
> I have checked both of the Projects and the issue lists and as far as I 
> can see you have not been involved in previous discussions or involved in 
> either of the projects involved. I have checked the previous reddit and 
> parts of the discussion which are indeed not intelligible. As such this was 
> a initial post in the matter by you , it constitutes a request for 
>  information with the reason why. Can you confirm my assesment?
>
> Nigel Vickers
>
> You seem to be confused about Aram's affiliations: he is not a worker on 
> Iris or any of the projects it stole from; he is a member of the Go team 
> itself (or if that is not true, then he is one of its top contributors), 
> and his most known contribution was the Solaris port.
>
>
> On Oct 27, 2016, at 11:52 AM, Russ Cox > 
> wrote:
>
> I am sending this message to golang-nuts bcc golang-dev in an attempt to 
> unify the two discussions into one discussion in one place. I picked 
> golang-nuts because that is roughly a superset of golang-dev.
>
> Did golang-dev stop sending emails? I haven't received anything since 
> October 16. Or should I contact Google Groups support and/or my email 
> provider?
>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Nate Finch]

It seems like most of the problem with this whole situation comes from the 
wording of the "warning"  

Please consider this a warning from the Code of Conduct working group.
>

 "consider this a warning" can be interpreted as a threat (though the 
"Please" in front should soften it somewhat).  I don't think it was 
intended as such, but I think it's clear some people do read it that way. 
 Perhaps just a rewording would prevent such a reaction in the future.

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Pietro Gagliardi]

> On Oct 27, 2016, at 11:49 AM, Andrew Gerrand  wrote:
> 
> I have done this before, and it has not gone well. People feel humiliated 
> when called out publicly. 
> 
> Imagine this happened in a workplace. Do you bring it up at the team meeting? 
> Or take them aside and mention it to them in private?
> 
I can vouch for this. It's especially embarrassing when you first mention it to 
them privately and resolve the issue, and then go ahead and mention it in the 
meeting anyway, or use it as an excuse for new policies set in that meeting. 
There is one particular space I left because of this, but I will not elaborate.


> On Oct 27, 2016, at 11:44 AM, Nigel Vickers  wrote:
> 
> Hallo Aram, 
> I have checked both of the Projects and the issue lists and as far as I can 
> see you have not been involved in previous discussions or involved in either 
> of the projects involved. I have checked the previous reddit and parts of the 
> discussion which are indeed not intelligible. As such this was a initial post 
> in the matter by you , it constitutes a request for  information with the 
> reason why. Can you confirm my assesment?
> 
> Nigel Vickers
You seem to be confused about Aram's affiliations: he is not a worker on Iris 
or any of the projects it stole from; he is a member of the Go team itself (or 
if that is not true, then he is one of its top contributors), and his most 
known contribution was the Solaris port.

> 
> On Oct 27, 2016, at 11:52 AM, Russ Cox  wrote:
> 
> I am sending this message to golang-nuts bcc golang-dev in an attempt to 
> unify the two discussions into one discussion in one place. I picked 
> golang-nuts because that is roughly a superset of golang-dev.
> 
Did golang-dev stop sending emails? I haven't received anything since October 
16. Or should I contact Google Groups support and/or my email provider?

-- 
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: [golang-dev] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Sarah Adams]

You are right.
I typed that from memory. I should have double-checked the exact wording
before posting.
  Feel free to reach out if you have any questions or concerns.
was the exact line.

On Thu, Oct 27, 2016 at 9:04 AM, Russ Cox  wrote:

> +golang-nuts bcc golang-dev
>
> On Thu, Oct 27, 2016 at 11:58 AM Aram Hăvărneanu  wrote:
>
>> On Thu, Oct 27, 2016 at 5:36 PM,   wrote:
>> > I do want to emphasize the last line of the email we sent, which does
>> not
>> > appear in your post here:
>> >
>> >   Please feel free to reach out if you have any questions or concerns.
>>
>> Except that is not what it says: http://i.imgur.com/MoyPKpg.png
>>
>> Why did you add the word "please" now in here, where it wasn't in the
>> original? Normally I wouldn't dream of caring about something as minor
>> as this, but you are trying to create a narrative that doesn't exist.
>> When my main complaint is about secret courts and lack of
>> transparency, this does not fare well for your argument.
>>
>> --
>> Aram Hăvărneanu
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-dev+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: [golang-dev] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Russ Cox]

+golang-nuts bcc golang-dev

On Thu, Oct 27, 2016 at 11:58 AM Aram Hăvărneanu  wrote:

> On Thu, Oct 27, 2016 at 5:36 PM,   wrote:
> > I do want to emphasize the last line of the email we sent, which does not
> > appear in your post here:
> >
> >   Please feel free to reach out if you have any questions or concerns.
>
> Except that is not what it says: http://i.imgur.com/MoyPKpg.png
>
> Why did you add the word "please" now in here, where it wasn't in the
> original? Normally I wouldn't dream of caring about something as minor
> as this, but you are trying to create a narrative that doesn't exist.
> When my main complaint is about secret courts and lack of
> transparency, this does not fare well for your argument.
>
> --
> Aram Hăvărneanu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+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] Slice of String in Postgres

[Kedarnag Mukanahallipatna]

Hello Everyone.

I am facing a situation, where I would like to store a slice of string that 
is coming from Request Body to be stored under 1 column.

Here is the Request -  {"start_location":"source", "routes": ["location1", 
"location2", "location3"], "end_location":"destination", "user_id":1}

I want to store ["location1", "location2", "location3"] under 1 column in 
PostgreSQL. I am also making use of gorm. 

PFA of the Struct and Method where I am trying to Create and at that point 
I am getting an error, also attached.

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Jordan Krage]

| People feel humiliated when called out publicly. 
The terminology 'called out' is a mischaracterization of what I am 
suggesting.

| Imagine this happened in a workplace. Do you bring it up at the team 
meeting? Or take them aside and mention it to them in private?
IMHO this is not an appropriate analogy.

On Thursday, October 27, 2016 at 10:49:46 AM UTC-5, Andrew Gerrand wrote:
>
>
>
> On 28 October 2016 at 02:24, Jordan Krage > 
> wrote:
>
>> Perhaps I was too broad in saying 'entirely public and transparent'.  I 
>> did not mean to suggest that *reporters* should be made public.
>>
>> That being said, I don't agree that a moderator post pointing out 
>> violations is a form of shaming (if that is what you meant).  Additionally, 
>> it communicates the point to everyone at once, rather than addressing 
>> individuals on a case by case basis.
>>
>
> I have done this before, and it has not gone well. People feel humiliated 
> when called out publicly. 
>
> Imagine this happened in a workplace. Do you bring it up at the team 
> meeting? Or take them aside and mention it to them in private?
>
> I think some discretion is a matter of courtesy and respect to all 
> involved.
>
> Andrew
>
>

-- 
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] Tooling experience feedback

[Russ Cox]

FWIW 'go help all' is essentially 'go doc go'.

On Fri, Oct 21, 2016 at 9:46 AM Mathieu Lonjaret 
wrote:

> As you said, sometimes one is not sure in which X for "go help X" one
> might find the information they're looking for. So one can end up
> trying several of them before finding the relevant info. I can think
> of one way that would alleviate that pain a bit: something like a "go
> help all" command that would print all the topics in one go. Makes it
> easier to pipe it to grep/less and search for specific things.
>
>
> On 18 October 2016 at 20:54, 'Jaana Burcu Dogan' via golang-nuts
>  wrote:
> > Hello gophers,
> >
> > I am going to spend some time on improving the not-documented or
> hard-to-use
> > parts of the Go tools. I will mainly focus on go build and go test. The
> work
> > will consist of reorganizing manuals, proposing new subcommands or flags
> to
> > support commonly used multi-step things and so on.
> >
> > To give you some concrete examples:
> >
> > I have been in cases where users cannot find the build flags because they
> > are hidden. E.g.
> >
> > $ go test -help
> > test [build/test flags] [packages] [build/test flags & test binary
> > flags]
> > ...
> >
> > requires you to know about where the build flags are. Some tools are
> > invisible for the newcomers.
> >
> > The other example is about test coverage. It is so tedious that I need an
> > alias.
> >
> > func gocover() {
> > go test -v -coverprofile=coverage.out && go tool cover
> > -html=coverage.out
> > }
> >
> > I want to learn more about your experience, aliases, etc to propose
> > improvements and work on the most commonly suggested items. I also am
> > planning to go through this mailing list, stack overflow and other
> channels
> > to see the common complaints.
> >
> > Feel free to reply to this thread or write to me privately.
> >
> > Thanks,
> > JBD
> >
> > --
> > 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.
>

-- 
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: [golang-dev] Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Russ Cox]

I didn't realize that Aram's original message was sent to both golang-dev
and golang-nuts. My reply earlier today (quoted below) only went to
golang-dev but is important to have on golang-nuts too.

I am sending this message to golang-nuts bcc golang-dev in an attempt to
unify the two discussions into one discussion in one place. I picked
golang-nuts because that is roughly a superset of golang-dev.

To everyone reading, please try to reply to golang-nuts only (not
golang-dev), so we can have a single conversation.

Thanks very much.
Russ

On Thu, Oct 27, 2016 at 9:58 AM Russ Cox  wrote:

> Hi Aram,
>
> I'm sorry you are insulted and distressed by this.
>
> As to the specifics, I would emphasize points already made by costinc and
> luzon83: (1) context and tone matters, not just truth, and (2) the code of
> conduct applies to the mailing lists but also to the golang subreddit (see
> https://golang.org/conduct for details).
>
> More generally, please remember that the goal of the code of conduct is to
> make the Go community as welcoming and inclusive as it can be. The code of
> conduct working group exists to put that into practice. If someone doesn't
> feel comfortable approaching you directly, they can approach the working
> group instead, and the working group reaches out to you. This is not a
> "extrajudicial court" handing down a "sentence", as you said. It is meant
> to be a helpful intermediary.
>
> As for "I suspect it's the thief himself who reported me", that's
> possible, but it's not the only possibility. It's equally possible that
> someone else, perhaps themselves a non-native English speaker, was made to
> feel unwelcome by your remark.
>
> If you feel the working group is wrong about something, I would suggest
> that a more productive way to raise that complaint would be to reply to
> them (cond...@golang.org) and have a direct discussion, instead of
> mailing golang-dev.
>
> Finally, I am not part of the code of conduct working group, though I
> certainly appreciate and support their work to make the Go community
> welcoming and inclusive. If after trying to resolve a problem with them you
> still aren't satisfied, you or anyone else is welcome to email me directly (
> r...@golang.org or r...@google.com).
>
> Thanks very much.
>
> Russ
>

-- 
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] iconvg: a compact, binary format for simple vector graphics

[Pietro Gagliardi]

What part of the document are you referring to?
> On Oct 27, 2016, at 11:42 AM, roger peppe  wrote:
> 
> On 26 October 2016 at 23:50, Nigel Tao  wrote:
>> On Wed, Oct 26, 2016 at 7:20 PM, roger peppe  wrote:
>>> This cannot be understated. A well known tool generates SVGs that the
>>> Go XML parser cannot parse because it uses XML directives to create XML
>>> entities that contain XML elements when they're expanded.  This meant
>>> we couldn't process them at all (we wanted to adjust the view
>>> box parameter).
>> 
>> Ooh, that's interesting. Can you share some more details?
> 
> After some delving back into history, here's an example:
> 
> https://api.jujucharms.com/charmstore/v5/~cf-charmers/trusty/cloudfoundry-205/archive/icon.svg
> 
> -- 
> 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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Andrew Gerrand]

On 28 October 2016 at 02:24, Jordan Krage  wrote:

> Perhaps I was too broad in saying 'entirely public and transparent'.  I
> did not mean to suggest that *reporters* should be made public.
>
> That being said, I don't agree that a moderator post pointing out
> violations is a form of shaming (if that is what you meant).  Additionally,
> it communicates the point to everyone at once, rather than addressing
> individuals on a case by case basis.
>

I have done this before, and it has not gone well. People feel humiliated
when called out publicly.

Imagine this happened in a workplace. Do you bring it up at the team
meeting? Or take them aside and mention it to them in private?

I think some discretion is a matter of courtesy and respect to all involved.

Andrew

-- 
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] Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Andrew Gerrand]

Hi Aram,

I am sorry this has caused you such distress.

As has been pointed out by others, your comment did not appear to be
directed at the Iris author, but rather at dlsniper, the author of the blog
post. He even replied to you apologizing for his English skills, and you
did nothing to correct him, so I don't think one would be remiss to assume
that he was the target of your comment. For this reason, I think it
unlikely that your comment was reported by the Iris author.

The actions of the Iris author are, in my opinion, pretty awful. But the
only people that can take action against them are the people whose code he
stole.

But the Iris issue is a distraction here. The CoC working group was formed
to help resolve conflict within official Go spaces, one of which is the
golang subreddit. Your comment was reported by someone in the community,
and so we contacted you about it.

On "objective truth": As a thought experiment, is it productive to tell a
newbie "You're a terrible programmer"? It may be true, but it is obviously
mean and discouraging. To me, it seems disingenuous to insist that we have
a right to say whatever we want wherever we like, so long as it is true.
Civility requires a little more from us.

The purpose of the message from the CoC group was to let you know that your
comment was interpreted as hostile, and to suggest that you could have make
the equivalent point without belittling anyone. I sincerely encourage you
to take it in the spirit in which it was intended.

In Sarah's message to you, she concluded:

  Please feel free to reach out if you have any questions or concerns.

  Sincerely,
  The Go Code of Conduct Team

I wish you had taken us up on that offer instead of starting this public
thread. We are reasonable people that care deeply about all members of the
community, including you.

Andrew

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Nigel Vickers]

Hallo Aram, 
I have checked both of the Projects and the issue lists and as far as I can 
see you have not been involved in previous discussions or involved in 
either of the projects involved. I have checked the previous reddit and 
parts of the discussion which are indeed not intelligible. As such this was 
a initial post in the matter by you , it constitutes a request for 
 information with the reason why. Can you confirm my assesment?

Nigel Vickers

On Thursday, 27 October 2016 15:19:56 UTC+2, Nigel Vickers wrote:
>
> Hallo Aram,
>
> If this did happen as you describe then you have every right to be very 
> angry. I also have grave reservations about "Codes of Conduct"  and the 
> "kangaroo Courts" that grow up around them.  I have tried to build a 
> picture of events using the links you have listed. I am not getting as far 
> as I would wish.  I need to ask a you few questions and would like the 
> answers to be to the list.  Would you be prepared to help me?
>
> Nigel Vickers
>
> On Thursday, 27 October 2016 13:36:23 UTC+2, Aram Hăvărneanu wrote:
>>
>> I have received a very insulting and distressing e-mail from Sarah
>> Adams, who claims to represent the The Go Code of Conduct Team, an
>> illicit bully organization who claims authority about what Go
>> contributors think and say outside the Go mailing lists. I do not
>> recognize this group's legitimacy in these matters.
>>
>>
>>

-- 
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: iconvg: a compact, binary format for simple vector graphics

[roger peppe]

On 26 October 2016 at 23:50, Nigel Tao  wrote:
> On Wed, Oct 26, 2016 at 7:20 PM, roger peppe  wrote:
>> This cannot be understated. A well known tool generates SVGs that the
>> Go XML parser cannot parse because it uses XML directives to create XML
>> entities that contain XML elements when they're expanded.  This meant
>> we couldn't process them at all (we wanted to adjust the view
>> box parameter).
>
> Ooh, that's interesting. Can you share some more details?

After some delving back into history, here's an example:

https://api.jujucharms.com/charmstore/v5/~cf-charmers/trusty/cloudfoundry-205/archive/icon.svg

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Sarah Adams]

I apologize for making you feel threatened or insulted in any way.
I do want to emphasize the last line of the email we sent, which does not 
appear in your post here:

  Please feel free to reach out if you have any questions or concerns.

We welcome pushback on any decision or response. We are open to having a 
dialogue about any issue.
I hope that in the future, you will feel comfortable enough to email us 
directly.

Sarah

On Thursday, October 27, 2016 at 4:36:23 AM UTC-7, Aram Hăvărneanu wrote:
>
> I have received a very insulting and distressing e-mail from Sarah
> Adams, who claims to represent the The Go Code of Conduct Team, an
> illicit bully organization who claims authority about what Go
> contributors think and say outside the Go mailing lists. I do not
> recognize this group's legitimacy in these matters.
>
> The e-mail says:
>
> We received a report about your comment on this thread
>
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
> :
> "Their English was so bad I couldn't understand what was
> going on".
>
> This comment goes against our community Code of Conduct,
> https://golang.org/conduct. The comment is not respectful,
> and would have been more productive just as, "I couldn't
> understand what was going on".
>
> Please consider this a warning from the Code of Conduct
> working group.
>
> Some more context is necessary. There is someone in the Go community
> who literally steals other people's code, receives money for it,
> and actively tries to covers his tracks.
>
> A person named Florin Pățan provided an overview:
>
> [1] 
> http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html
>
> which has been discussed on reddit:
>
> [2] 
> https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
> .
>
> Reddit also discussed this thief's action in another thread:
>
> [3] 
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/
>
> I have archived these documents here:
>
> [1] http://archive.is/9oN1A
> [2] http://archive.is/Q36G5
> [3] http://archive.is/aSFUg
>
> The comment in question refers to this GitHub issue, also archived:
>
> [4] https://github.com/avelino/awesome-go/pull/1137
> [4] http://archive.is/7xgc7
>
> Now take a look at what I said, and what Sarah Adams in her
> infinite arrogance suggests I should have said:
>
> Aram: Their English was so bad I couldn't understand what
>  was going on
>
> Sarah: I couldn't understand what was going on
>
> If you compare these two phrases: you can see that the problem Sarah
> Adams has is with "their English was so bad".
>
> In other words, Sarah's problem is with speaking the objective
> *TRUTH*.
>
> Whether someone speaks good or bad English is an objective fact
> easily determined by anyone who speaks English at some level of
> proficiency. I encourage all English speakers to take a look at [4]
> and do an individual assessment of the level of proficiency in English
> those sock puppets possess.
>
> I will not be policed around for telling the *TRUTH*. I will not
> be silenced into political compliance. I will not tolerate other
> people who tell me what is acceptable to say, especially when these
> people only want to hide the *OBJECTIVE TRUTH*.
>
> The comment is not respectful
>
> Damn right it wasn't. You or your organization has no authority
> mandating how respectful my speech is. What level of arrogance.
>
> However, it was not disrespectful. It was an objective assessment
> of an *infractor's* level of English competence.
>
> I owe nobody respect. Certainly not someone who breaks the law and
> steals other people's intellectual property. Respect is earned.
>
> and would have been more productive just as
>
> Ah, yes, here you can see in action the new-age practice of corporate
> double speak applied to open source projects. This is not Google.
> You are not fooling me or anyone else who still has a grain of
> independent thought left.
>
> This is a pathetic and disgusting attempt of silencing independent
> contributors who still refuse to kneel after your coup d'état in
> which you managed to replace the Go technical governance with a
> thought police political organization vassal to Google.
>
> In some sense, you have succeeded. I will never yield to you, you
> can never silence me, but you certainly made me realise that my
> association with the Go project is a mistake and a liability. I do
> not want to be associated with your organization, even accidentally.
> When I contribute to Go, I only make you people stronger. In fact,
> this is your modus operandi; you rely on people who do the actual
> technical work (either as part of the Go team, or as contributors)
> in order to gain more support for your cause. To gain legitimacy.
> To claim authority.
>
> I cannot remove the code I have contributed to the Go project over
> the years, but I can certainly stop contributing as an individu

Re: [go-nuts] Stopping a server

[Peter Mogensen]

On 2016-10-27 16:11, Nick Patavalis wrote:

I konw that, functionally, this will work. My question is: Does this
look like a "reasonable" / "idiomatic" use of contexts?  Or will it
look "alien" to the user? I'm asking since the documentation of
"context" mentions it being used for "request-scoped" stuff, and this
is not exactly the case here.

I can instead add a Stop() method to "srv" and roll-my-own stopping
logic.

Which would you choose?


It's a valid question whether Context is the concept to use for starting 
and stopping server instances. ... I'm not fully convinced. It seems to 
me it's more meaningfull for more transient things like Requests.


Anyway ... I know what I did in the similiar situation:

https://github.com/One-com/gone/blob/master/example.go

Servers are basically started by calling Serve() ... which blocks until 
someone, somewhere invokes Shutdown()


The whole daemon process can manage any number of objects implementing:

type Server interface {
Serve() error // start serving and block until exit
Shutdown()// async req. to shutdown, must not block
}

/Peter

--
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[charraster]

code of conduct workers should work on adding generics to compilers


-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Nigel Vickers]

Hallo Nate,

On Thursday, 27 October 2016 17:10:57 UTC+2, Nate Finch wrote:
>
> We should know what is a violation by reading the code of conduct.  Making 
> the process public would make it a way to shame people, and also might 
> discourage people from reporting for fear of reprisal.  The intent is to 
> inform people when they have said something that others find insulting or 
> unwelcoming, so that they may find nicer ways to express themselves.
>

Sorry, Secret processes have no place in an Open Source project.   

>
> On Thursday, October 27, 2016 at 10:29:47 AM UTC-4, Jordan Krage wrote:
>>
>> At the very least, this kind of CoC 'enforcement' should be entirely 
>> public and transparent.  How are others supposed to learn what is 
>> considered a violation, when violators are only contacted privately by 
>> email?
>>
>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Jordan Krage]

To expand on "it communicates the point to everyone at once": notice that 
the original reddit post in question is completely absent of any suggestion 
of CoC violation.  Nobody stumbling into that thread and reading that 
comment would be aware that it was considered a violation.
https://np.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd/

On Thursday, October 27, 2016 at 10:24:26 AM UTC-5, Jordan Krage wrote:
>
> Perhaps I was too broad in saying 'entirely public and transparent'.  I 
> did not mean to suggest that *reporters* should be made public.
>
> That being said, I don't agree that a moderator post pointing out 
> violations is a form of shaming (if that is what you meant).  Additionally, 
> it communicates the point to everyone at once, rather than addressing 
> individuals on a case by case basis.
>
> | We should know what is a violation by reading the code of conduct.
> *Should*? Ok. What about when we don't? It sounds like you are working 
> from an assumption that the CoC is infallible and completely unambiguous. 
>  I agree that is something to strive for.  We must be allowed to have 
> public discourse regarding it's interpretation. *Especially* when dealing 
> with non-native English speakers.
>
> On Thursday, October 27, 2016 at 10:10:57 AM UTC-5, Nate Finch wrote:
>>
>> We should know what is a violation by reading the code of conduct. 
>>  Making the process public would make it a way to shame people, and also 
>> might discourage people from reporting for fear of reprisal.  The intent is 
>> to inform people when they have said something that others find insulting 
>> or unwelcoming, so that they may find nicer ways to express themselves.
>>
>> On Thursday, October 27, 2016 at 10:29:47 AM UTC-4, Jordan Krage wrote:
>>>
>>> At the very least, this kind of CoC 'enforcement' should be entirely 
>>> public and transparent.  How are others supposed to learn what is 
>>> considered a violation, when violators are only contacted privately by 
>>> email?
>>>
>>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Henrik Johansson]

I actually read through the thread and unless everyone in that thread got
the same message then I Aram should not have gotten the note.

I recognize the potential value of the CoC but it always boils down to
opinions. Imho this was a bad call. Bad calls happen and we should be able
to get past it and move on.

On Thu, Oct 27, 2016, 17:11 Nate Finch  wrote:

> We should know what is a violation by reading the code of conduct.  Making
> the process public would make it a way to shame people, and also might
> discourage people from reporting for fear of reprisal.  The intent is to
> inform people when they have said something that others find insulting or
> unwelcoming, so that they may find nicer ways to express themselves.
>
>
> On Thursday, October 27, 2016 at 10:29:47 AM UTC-4, Jordan Krage wrote:
>
> At the very least, this kind of CoC 'enforcement' should be entirely
> public and transparent.  How are others supposed to learn what is
> considered a violation, when violators are only contacted privately by
> email?
>
> --
> 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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Jordan Krage]

Perhaps I was too broad in saying 'entirely public and transparent'.  I did 
not mean to suggest that *reporters* should be made public.

That being said, I don't agree that a moderator post pointing out 
violations is a form of shaming (if that is what you meant).  Additionally, 
it communicates the point to everyone at once, rather than addressing 
individuals on a case by case basis.

| We should know what is a violation by reading the code of conduct.
*Should*? Ok. What about when we don't? It sounds like you are working from 
an assumption that the CoC is infallible and completely unambiguous.  I 
agree that is something to strive for.  We must be allowed to have public 
discourse regarding it's interpretation. *Especially* when dealing with 
non-native English speakers.

On Thursday, October 27, 2016 at 10:10:57 AM UTC-5, Nate Finch wrote:
>
> We should know what is a violation by reading the code of conduct.  Making 
> the process public would make it a way to shame people, and also might 
> discourage people from reporting for fear of reprisal.  The intent is to 
> inform people when they have said something that others find insulting or 
> unwelcoming, so that they may find nicer ways to express themselves.
>
> On Thursday, October 27, 2016 at 10:29:47 AM UTC-4, Jordan Krage wrote:
>>
>> At the very least, this kind of CoC 'enforcement' should be entirely 
>> public and transparent.  How are others supposed to learn what is 
>> considered a violation, when violators are only contacted privately by 
>> email?
>>
>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Nate Finch]

We should know what is a violation by reading the code of conduct.  Making 
the process public would make it a way to shame people, and also might 
discourage people from reporting for fear of reprisal.  The intent is to 
inform people when they have said something that others find insulting or 
unwelcoming, so that they may find nicer ways to express themselves.

On Thursday, October 27, 2016 at 10:29:47 AM UTC-4, Jordan Krage wrote:
>
> At the very least, this kind of CoC 'enforcement' should be entirely 
> public and transparent.  How are others supposed to learn what is 
> considered a violation, when violators are only contacted privately by 
> email?
>

-- 
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: Golang should have a center packages index hosting like npm, rust crates

[atd...@gmail.com]

On Thursday, October 27, 2016 at 4:41:42 PM UTC+2, Michal Bohuslávek wrote:
>
> It's not much of a penalisation IMO. It doesn't have to be a large message 
> in red saying: "The author of this package doesn't use semantic versioning. 
> Be careful!". I mean the list of versions can only appear if there are some 
> versions. That way it wouldn't penalise a), although I can't come up with a 
> good reason not to tag versions apart from b).
>
> When it comes to b), there could be some rule for that case. Such authors 
> could for example put their stable API in a branch called "stable" or 
> something like that.
>

That wouldn't work with the way the language is structured (imports).
Just having a version tag is perhaps necessary, but, alas, not sufficient 
to deal with the entirety of dependency discovery/management.

We have some primitives (canonical imports etc...). Solving availability by 
redundancy(since part of the issue is about distributed systems) may also 
tie into import rewritting, or import aliasing.. which could be done a few 
different ways.

It's not a simple problem.
 

>
> Dne čtvrtek 27. října 2016 1:39:47 UTC+1 Axel Wagner napsal(a):
>>
>> So, the idea is to penalize people who a) have a different opinion about 
>> the usefulness of versioning or b) keep their APIs stable and don't see a 
>> need to version something that never changes?
>>
>> Needless to say, I consider that a bad idea (given, that I have strongly 
>> differing opinions about the usefulness of versioning). Why can't the idea 
>> not succeed based on it's own merit (or lack thereof)?
>>
>> But whatever. Set minds won't be swayed by arguments, I guess.
>>
>> I'll also point out (again) that this thread, originally, was about a 
>> central repository. Not about versioning.
>>
>> On Wed, Oct 26, 2016 at 10:53 PM, Edward Muller  
>> wrote:
>>
>>> Yes, use that proposal's format.
>>>
>>> Re: godoc. Great idea. if no one else is interested in doing the work 
>>> I'll be happy to take a look into it. I've been looking for an excuse to 
>>> work with gddo
>>>
>>> On Wed, Oct 26, 2016 at 1:42 PM Dave Cheney  wrote:
>>>
 Indeed. If only there was some standard we could use


 https://github.com/golang/proposal/blob/master/design/12302-release-proposal.md#tag-format

 On Thu, Oct 27, 2016 at 6:08 AM, Nate Finch  wrote:
 > Listing versions on godoc is an awesome idea.  Peer pressure goes a 
 long way
 > toward changing individual minds and eventually a community.  
 Something as
 > simple as sorting projects with tagged versions higher and displaying 
 them
 > prominently on the project's godoc page (with the ability to look at 
 godoc
 > for each version) would go a long way toward encouraging people to 
 tag their
 > releases.  I know it would get me off my butt to tag my projects.
 >
 > On Wednesday, October 26, 2016 at 11:37:54 AM UTC-4, 
 mbohu...@gmail.com
 > wrote:
 >>
 >> I was just wondering whether a simple list of available versions at 
 the
 >> top of a package's godoc.org page wouldn't somehow force package 
 authors to
 >> start tagging. There could be some kind of message if there are no 
 available
 >> versions.
 >> There would obviously have to be some benefit for those who tag, or 
 some
 >> restriction for those who don't, in order to change the current 
 situation.

 --
 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...@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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[prades . marq]

Frankly /r/golang is so toxic I stopped posting there, it should be either 
shut down or officially excluded from any official go forum. 

The code of conduct serves very little purpose 
given what happens there constantly, 

People like to target projects, insult their author and call them thieves 
to destroy their reputation and then complain and play the victim when they 
are being called out when caught misbehaving ? 

I say shut down /r/golang , there is very little moderation there to begin 
with.

I'm sure Sarah Adams did the best she could to de-escalate the situation 
but frankly there is nothing that can really be done due to the nature of 
reddit.

Le jeudi 27 octobre 2016 13:36:23 UTC+2, Aram Hăvărneanu a écrit :
>
> I have received a very insulting and distressing e-mail from Sarah
> Adams, who claims to represent the The Go Code of Conduct Team, an
> illicit bully organization who claims authority about what Go
> contributors think and say outside the Go mailing lists. I do not
> recognize this group's legitimacy in these matters.
>
> The e-mail says:
>
> We received a report about your comment on this thread
>
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
> :
> "Their English was so bad I couldn't understand what was
> going on".
>
> This comment goes against our community Code of Conduct,
> https://golang.org/conduct. The comment is not respectful,
> and would have been more productive just as, "I couldn't
> understand what was going on".
>
> Please consider this a warning from the Code of Conduct
> working group.
>
> Some more context is necessary. There is someone in the Go community
> who literally steals other people's code, receives money for it,
> and actively tries to covers his tracks.
>
> A person named Florin Pățan provided an overview:
>
> [1] 
> http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html
>
> which has been discussed on reddit:
>
> [2] 
> https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
> .
>
> Reddit also discussed this thief's action in another thread:
>
> [3] 
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/
>
> I have archived these documents here:
>
> [1] http://archive.is/9oN1A
> [2] http://archive.is/Q36G5
> [3] http://archive.is/aSFUg
>
> The comment in question refers to this GitHub issue, also archived:
>
> [4] https://github.com/avelino/awesome-go/pull/1137
> [4] http://archive.is/7xgc7
>
> Now take a look at what I said, and what Sarah Adams in her
> infinite arrogance suggests I should have said:
>
> Aram: Their English was so bad I couldn't understand what
>  was going on
>
> Sarah: I couldn't understand what was going on
>
> If you compare these two phrases: you can see that the problem Sarah
> Adams has is with "their English was so bad".
>
> In other words, Sarah's problem is with speaking the objective
> *TRUTH*.
>
> Whether someone speaks good or bad English is an objective fact
> easily determined by anyone who speaks English at some level of
> proficiency. I encourage all English speakers to take a look at [4]
> and do an individual assessment of the level of proficiency in English
> those sock puppets possess.
>
> I will not be policed around for telling the *TRUTH*. I will not
> be silenced into political compliance. I will not tolerate other
> people who tell me what is acceptable to say, especially when these
> people only want to hide the *OBJECTIVE TRUTH*.
>
> The comment is not respectful
>
> Damn right it wasn't. You or your organization has no authority
> mandating how respectful my speech is. What level of arrogance.
>
> However, it was not disrespectful. It was an objective assessment
> of an *infractor's* level of English competence.
>
> I owe nobody respect. Certainly not someone who breaks the law and
> steals other people's intellectual property. Respect is earned.
>
> and would have been more productive just as
>
> Ah, yes, here you can see in action the new-age practice of corporate
> double speak applied to open source projects. This is not Google.
> You are not fooling me or anyone else who still has a grain of
> independent thought left.
>
> This is a pathetic and disgusting attempt of silencing independent
> contributors who still refuse to kneel after your coup d'état in
> which you managed to replace the Go technical governance with a
> thought police political organization vassal to Google.
>
> In some sense, you have succeeded. I will never yield to you, you
> can never silence me, but you certainly made me realise that my
> association with the Go project is a mistake and a liability. I do
> not want to be associated with your organization, even accidentally.
> When I contribute to Go, I only make you people stronger. In fact,
> this is your modus operandi; you rely on people who do the actual
> technical work (either as part of the Go team, or as contributor

[go-nuts] Re: Cross-package CGO and static linking

[pat . sriram]

Hey Marvin,
Were you able to find any solutions to your problem?

I have a similar problem of LDFLAGS not bubbling up through packages -- 
Here I have 
pkg A statically links libA 
pkg B (which imports A) also uses libA. 

I get a linker error stating multiple definitions of the functions.

-Sriram


On Friday, November 7, 2014 at 1:46:31 AM UTC+5:30, Marvin Humphrey wrote:
>
> Greetings, 
>
> I'd like to use CGO to access C functionality linked statically into a 
> *different* Go package. 
>
> Here's a simplified demo: 
>
> src/foo/foo.go: 
>
> package foo 
> // int 
> // forty_two() { 
> //return 42; 
> // } 
> import "C" 
>
> try.go: 
>
> package main 
> import "fmt" 
> import "foo" 
> // extern int forty_two(); 
> // int 
> // forty_three() { 
> // return forty_two() + 1; 
> // } 
> import "C" 
> func main() { 
> fmt.Println(int(C.forty_three())) 
> } 
>
> Here's the output when I try to run `try.go` (after running `go install 
> foo`): 
>
> $ go run try.go 
> # command-line-arguments 
> Undefined symbols for architecture x86_64: 
>   "_forty_two", referenced from: 
>   __cgo_45ed811e7bcb_Cfunc_forty_two in try.cgo2.o 
>  (maybe you meant: __cgo_45ed811e7bcb_Cfunc_forty_two) 
> ld: symbol(s) not found for architecture x86_64 
> clang: error: linker command failed with exit code 1 (use 
>  -v to see invocation) 
>
> Examining the contents of the installed package file, it looks like 
> `_forty_two` ought to be available: 
>
> $ nm -g pkg/darwin_amd64/foo.a 
>
> pkg/darwin_amd64/foo.a(_all.o): 
>  T _forty_two 
>
> Suggestions? 
>
> Using CGO_LDFLAGS to supply a full path to the package archive file didn't 
> do the trick.  (Not that I expected it to, but the output is interesting.) 
>
> $ export CGO_LDFLAGS=$GOPATH/pkg/darwin_amd64/foo.a 
> $ go run try.go 
> # command-line-arguments 
> ld: warning: ignoring file ./pkg/darwin_amd64/foo.a, file was built 
> for archive which is not the architecture being linked 
> (x86_64): ./pkg/darwin_amd64/foo.a 
> [...] 
>
> Marvin Humphrey 
>

-- 
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] CGO: How to link static library across dependent packages?

[pat . sriram]

 

Folks,

Two of my packages have dependency on the same C library. I have linked 
them successfully using the LDFLAGS directives. 

But I'm facing a multiple definitions error when linking my project 
executable


Here is an overview of my project structure:

Pkg A -> depends on LIBA

Pkg B (imports Pkg A) -> and also depends on LIBA

Pkg Main imports B


Commands used to build: In Pkg Main directory: go build



Appreciate any thoughts on this issue


Thanks!

-- 
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: Golang should have a center packages index hosting like npm, rust crates

[Michal Bohuslávek]

It's not much of a penalisation IMO. It doesn't have to be a large message 
in red saying: "The author of this package doesn't use semantic versioning. 
Be careful!". I mean the list of versions can only appear if there are some 
versions. That way it wouldn't penalise a), although I can't come up with a 
good reason not to tag versions apart from b).

When it comes to b), there could be some rule for that case. Such authors 
could for example put their stable API in a branch called "stable" or 
something like that.

Dne čtvrtek 27. října 2016 1:39:47 UTC+1 Axel Wagner napsal(a):
>
> So, the idea is to penalize people who a) have a different opinion about 
> the usefulness of versioning or b) keep their APIs stable and don't see a 
> need to version something that never changes?
>
> Needless to say, I consider that a bad idea (given, that I have strongly 
> differing opinions about the usefulness of versioning). Why can't the idea 
> not succeed based on it's own merit (or lack thereof)?
>
> But whatever. Set minds won't be swayed by arguments, I guess.
>
> I'll also point out (again) that this thread, originally, was about a 
> central repository. Not about versioning.
>
> On Wed, Oct 26, 2016 at 10:53 PM, Edward Muller  > wrote:
>
>> Yes, use that proposal's format.
>>
>> Re: godoc. Great idea. if no one else is interested in doing the work 
>> I'll be happy to take a look into it. I've been looking for an excuse to 
>> work with gddo
>>
>> On Wed, Oct 26, 2016 at 1:42 PM Dave Cheney > > wrote:
>>
>>> Indeed. If only there was some standard we could use
>>>
>>>
>>> https://github.com/golang/proposal/blob/master/design/12302-release-proposal.md#tag-format
>>>
>>> On Thu, Oct 27, 2016 at 6:08 AM, Nate Finch >> > wrote:
>>> > Listing versions on godoc is an awesome idea.  Peer pressure goes a 
>>> long way
>>> > toward changing individual minds and eventually a community.  
>>> Something as
>>> > simple as sorting projects with tagged versions higher and displaying 
>>> them
>>> > prominently on the project's godoc page (with the ability to look at 
>>> godoc
>>> > for each version) would go a long way toward encouraging people to tag 
>>> their
>>> > releases.  I know it would get me off my butt to tag my projects.
>>> >
>>> > On Wednesday, October 26, 2016 at 11:37:54 AM UTC-4, 
>>> mbohu...@gmail.com
>>> > wrote:
>>> >>
>>> >> I was just wondering whether a simple list of available versions at 
>>> the
>>> >> top of a package's godoc.org page wouldn't somehow force package 
>>> authors to
>>> >> start tagging. There could be some kind of message if there are no 
>>> available
>>> >> versions.
>>> >> There would obviously have to be some benefit for those who tag, or 
>>> some
>>> >> restriction for those who don't, in order to change the current 
>>> situation.
>>>
>>> --
>>> 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...@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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Jordan Krage]

At the very least, this kind of CoC 'enforcement' should be entirely public 
and transparent.  How are others supposed to learn what is considered a 
violation, when violators are only contacted privately by email?

On Thursday, October 27, 2016 at 6:36:23 AM UTC-5, Aram Hăvărneanu wrote:
>
> I have received a very insulting and distressing e-mail from Sarah
> Adams, who claims to represent the The Go Code of Conduct Team, an
> illicit bully organization who claims authority about what Go
> contributors think and say outside the Go mailing lists. I do not
> recognize this group's legitimacy in these matters.
>
> The e-mail says:
>
> We received a report about your comment on this thread
>
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
> :
> "Their English was so bad I couldn't understand what was
> going on".
>
> This comment goes against our community Code of Conduct,
> https://golang.org/conduct. The comment is not respectful,
> and would have been more productive just as, "I couldn't
> understand what was going on".
>
> Please consider this a warning from the Code of Conduct
> working group.
>
> Some more context is necessary. There is someone in the Go community
> who literally steals other people's code, receives money for it,
> and actively tries to covers his tracks.
>
> A person named Florin Pățan provided an overview:
>
> [1] 
> http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html
>
> which has been discussed on reddit:
>
> [2] 
> https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
> .
>
> Reddit also discussed this thief's action in another thread:
>
> [3] 
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/
>
> I have archived these documents here:
>
> [1] http://archive.is/9oN1A
> [2] http://archive.is/Q36G5
> [3] http://archive.is/aSFUg
>
> The comment in question refers to this GitHub issue, also archived:
>
> [4] https://github.com/avelino/awesome-go/pull/1137
> [4] http://archive.is/7xgc7
>
> Now take a look at what I said, and what Sarah Adams in her
> infinite arrogance suggests I should have said:
>
> Aram: Their English was so bad I couldn't understand what
>  was going on
>
> Sarah: I couldn't understand what was going on
>
> If you compare these two phrases: you can see that the problem Sarah
> Adams has is with "their English was so bad".
>
> In other words, Sarah's problem is with speaking the objective
> *TRUTH*.
>
> Whether someone speaks good or bad English is an objective fact
> easily determined by anyone who speaks English at some level of
> proficiency. I encourage all English speakers to take a look at [4]
> and do an individual assessment of the level of proficiency in English
> those sock puppets possess.
>
> I will not be policed around for telling the *TRUTH*. I will not
> be silenced into political compliance. I will not tolerate other
> people who tell me what is acceptable to say, especially when these
> people only want to hide the *OBJECTIVE TRUTH*.
>
> The comment is not respectful
>
> Damn right it wasn't. You or your organization has no authority
> mandating how respectful my speech is. What level of arrogance.
>
> However, it was not disrespectful. It was an objective assessment
> of an *infractor's* level of English competence.
>
> I owe nobody respect. Certainly not someone who breaks the law and
> steals other people's intellectual property. Respect is earned.
>
> and would have been more productive just as
>
> Ah, yes, here you can see in action the new-age practice of corporate
> double speak applied to open source projects. This is not Google.
> You are not fooling me or anyone else who still has a grain of
> independent thought left.
>
> This is a pathetic and disgusting attempt of silencing independent
> contributors who still refuse to kneel after your coup d'état in
> which you managed to replace the Go technical governance with a
> thought police political organization vassal to Google.
>
> In some sense, you have succeeded. I will never yield to you, you
> can never silence me, but you certainly made me realise that my
> association with the Go project is a mistake and a liability. I do
> not want to be associated with your organization, even accidentally.
> When I contribute to Go, I only make you people stronger. In fact,
> this is your modus operandi; you rely on people who do the actual
> technical work (either as part of the Go team, or as contributors)
> in order to gain more support for your cause. To gain legitimacy.
> To claim authority.
>
> I cannot remove the code I have contributed to the Go project over
> the years, but I can certainly stop contributing as an individual
> in the future. I will make sure, best of my ability, that any
> competent individual or organization who is evaluating Go is made
> aware of who is actually pulling the strings here, and what they
> are getting 

[go-nuts] Stopping a server

[Nick Patavalis]

Hi,

I'm writing a package that allows the user to create and start server
instances. A server instance is created like this:

  srv := pkg.NewServer( ... params ... )

and started like this:

  err := srv.Start()

Start does not normally return (unless an unrecoverable error
occurs). The user code can invoke Start() in a goroutine in order to run
multiple servers (which is not uncommon).

I want to give the user-code the ability to stop servers when
required. One thought is to use "context.Context" for this purpose. That
is, the server could be started like this:

  ctx, cancel := context.WithCancel(context.Background())
  ...
  err := srv.Start(ctx)

and stopped by calling the "cancel" function of the context.

I konw that, functionally, this will work. My question is: Does this
look like a "reasonable" / "idiomatic" use of contexts?  Or will it
look "alien" to the user? I'm asking since the documentation of
"context" mentions it being used for "request-scoped" stuff, and this
is not exactly the case here.

I can instead add a Stop() method to "srv" and roll-my-own stopping
logic.

Which would you choose?

/npat

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[omarshariffdontlikeit]

In that case, I can see why it would apply there then.

(Thats not to say that I agree with the judgement made in this instance at 
all, in fact I find the whole idea of a Code of Conduct weird).


On Thursday, October 27, 2016 at 2:07:10 PM UTC+1, luz...@gmail.com wrote:
>
> It also applies to the golang subreddit created and moderated by the same 
> people as the mailing lists.
>
> On Thursday, October 27, 2016 at 2:55:03 PM UTC+2, omarsharif...@gmail.com 
> wrote:
>>
>> I must admit, I always assumed the Go Code of Conduct was something that 
>> was agreed to when participating on this mailing list, not something that 
>> applied outside of the mailing list.
>>
>  
>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[mjy]

Am Donnerstag, 27. Oktober 2016 14:55:03 UTC+2 schrieb 
omarsharif...@gmail.com:
>
> I must admit, I always assumed the Go Code of Conduct was something that 
> was agreed to when participating on this mailing list, not something that 
> applied outside of the mailing list. Is there really a team of people who's 
> job it is to police the community for infractions against this "code"?
>
>
Yes, and they're apparently doing a terrible job by confirming people's 
negative expectations.

I'm not sure I ever agreed to the CoC explicitly, it was just announced at 
some point (with plenty of disagreement about it).

It's not for me to judge anyway, I'm not important. Aram is, though. 

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Nigel Vickers]

Hallo Aram,

If this did happen as you describe then you have every right to be very 
angry. I also have grave reservations about "Codes of Conduct"  and the 
"kangaroo Courts" that grow up around them.  I have tried to build a 
picture of events using the links you have listed. I am not getting as far 
as I would wish.  I need to ask a you few questions and would like the 
answers to be to the list.  Would you be prepared to help me?

Nigel Vickers

On Thursday, 27 October 2016 13:36:23 UTC+2, Aram Hăvărneanu wrote:
>
> I have received a very insulting and distressing e-mail from Sarah
> Adams, who claims to represent the The Go Code of Conduct Team, an
> illicit bully organization who claims authority about what Go
> contributors think and say outside the Go mailing lists. I do not
> recognize this group's legitimacy in these matters.
>
>
>

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[luzon83]

It also applies to the golang subreddit created and moderated by the same 
people as the mailing lists.

On Thursday, October 27, 2016 at 2:55:03 PM UTC+2, omarsharif...@gmail.com 
wrote:
>
> I must admit, I always assumed the Go Code of Conduct was something that 
> was agreed to when participating on this mailing list, not something that 
> applied outside of the mailing list.
>
 

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[omarshariffdontlikeit]

I must admit, I always assumed the Go Code of Conduct was something that 
was agreed to when participating on this mailing list, not something that 
applied outside of the mailing list. Is there really a team of people who's 
job it is to police the community for infractions against this "code"?

Can anyone (Andrew?) shed some light on this?

On Thursday, October 27, 2016 at 12:36:23 PM UTC+1, Aram Hăvărneanu wrote:
>
> I have received a very insulting and distressing e-mail from Sarah
> Adams, who claims to represent the The Go Code of Conduct Team, an
> illicit bully organization who claims authority about what Go
> contributors think and say outside the Go mailing lists. I do not
> recognize this group's legitimacy in these matters.
>
> The e-mail says:
>
> We received a report about your comment on this thread
>
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
> :
> "Their English was so bad I couldn't understand what was
> going on".
>
> This comment goes against our community Code of Conduct,
> https://golang.org/conduct. The comment is not respectful,
> and would have been more productive just as, "I couldn't
> understand what was going on".
>
> Please consider this a warning from the Code of Conduct
> working group.
>
> Some more context is necessary. There is someone in the Go community
> who literally steals other people's code, receives money for it,
> and actively tries to covers his tracks.
>
> A person named Florin Pățan provided an overview:
>
> [1] 
> http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html
>
> which has been discussed on reddit:
>
> [2] 
> https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
> .
>
> Reddit also discussed this thief's action in another thread:
>
> [3] 
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/
>
> I have archived these documents here:
>
> [1] http://archive.is/9oN1A
> [2] http://archive.is/Q36G5
> [3] http://archive.is/aSFUg
>
> The comment in question refers to this GitHub issue, also archived:
>
> [4] https://github.com/avelino/awesome-go/pull/1137
> [4] http://archive.is/7xgc7
>
> Now take a look at what I said, and what Sarah Adams in her
> infinite arrogance suggests I should have said:
>
> Aram: Their English was so bad I couldn't understand what
>  was going on
>
> Sarah: I couldn't understand what was going on
>
> If you compare these two phrases: you can see that the problem Sarah
> Adams has is with "their English was so bad".
>
> In other words, Sarah's problem is with speaking the objective
> *TRUTH*.
>
> Whether someone speaks good or bad English is an objective fact
> easily determined by anyone who speaks English at some level of
> proficiency. I encourage all English speakers to take a look at [4]
> and do an individual assessment of the level of proficiency in English
> those sock puppets possess.
>
> I will not be policed around for telling the *TRUTH*. I will not
> be silenced into political compliance. I will not tolerate other
> people who tell me what is acceptable to say, especially when these
> people only want to hide the *OBJECTIVE TRUTH*.
>
> The comment is not respectful
>
> Damn right it wasn't. You or your organization has no authority
> mandating how respectful my speech is. What level of arrogance.
>
> However, it was not disrespectful. It was an objective assessment
> of an *infractor's* level of English competence.
>
> I owe nobody respect. Certainly not someone who breaks the law and
> steals other people's intellectual property. Respect is earned.
>
> and would have been more productive just as
>
> Ah, yes, here you can see in action the new-age practice of corporate
> double speak applied to open source projects. This is not Google.
> You are not fooling me or anyone else who still has a grain of
> independent thought left.
>
> This is a pathetic and disgusting attempt of silencing independent
> contributors who still refuse to kneel after your coup d'état in
> which you managed to replace the Go technical governance with a
> thought police political organization vassal to Google.
>
> In some sense, you have succeeded. I will never yield to you, you
> can never silence me, but you certainly made me realise that my
> association with the Go project is a mistake and a liability. I do
> not want to be associated with your organization, even accidentally.
> When I contribute to Go, I only make you people stronger. In fact,
> this is your modus operandi; you rely on people who do the actual
> technical work (either as part of the Go team, or as contributors)
> in order to gain more support for your cause. To gain legitimacy.
> To claim authority.
>
> I cannot remove the code I have contributed to the Go project over
> the years, but I can certainly stop contributing as an individual
> in the future. I will make sure, best of my ability, that any
> competent individ

[go-nuts] Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Aram Hăvărneanu]

I have received a very insulting and distressing e-mail from Sarah
Adams, who claims to represent the The Go Code of Conduct Team, an
illicit bully organization who claims authority about what Go
contributors think and say outside the Go mailing lists. I do not
recognize this group's legitimacy in these matters.

The e-mail says:

We received a report about your comment on this thread
https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
:
"Their English was so bad I couldn't understand what was
going on".

This comment goes against our community Code of Conduct,
https://golang.org/conduct. The comment is not respectful,
and would have been more productive just as, "I couldn't
understand what was going on".

Please consider this a warning from the Code of Conduct
working group.

Some more context is necessary. There is someone in the Go community
who literally steals other people's code, receives money for it,
and actively tries to covers his tracks.

A person named Florin Pățan provided an overview:

[1]
http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html

which has been discussed on reddit:

[2]
https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
.

Reddit also discussed this thief's action in another thread:

[3]
https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/

I have archived these documents here:

[1] http://archive.is/9oN1A
[2] http://archive.is/Q36G5
[3] http://archive.is/aSFUg

The comment in question refers to this GitHub issue, also archived:

[4] https://github.com/avelino/awesome-go/pull/1137
[4] http://archive.is/7xgc7

Now take a look at what I said, and what Sarah Adams in her
infinite arrogance suggests I should have said:

Aram: Their English was so bad I couldn't understand what
 was going on

Sarah: I couldn't understand what was going on

If you compare these two phrases: you can see that the problem Sarah
Adams has is with "their English was so bad".

In other words, Sarah's problem is with speaking the objective
*TRUTH*.

Whether someone speaks good or bad English is an objective fact
easily determined by anyone who speaks English at some level of
proficiency. I encourage all English speakers to take a look at [4]
and do an individual assessment of the level of proficiency in English
those sock puppets possess.

I will not be policed around for telling the *TRUTH*. I will not
be silenced into political compliance. I will not tolerate other
people who tell me what is acceptable to say, especially when these
people only want to hide the *OBJECTIVE TRUTH*.

The comment is not respectful

Damn right it wasn't. You or your organization has no authority
mandating how respectful my speech is. What level of arrogance.

However, it was not disrespectful. It was an objective assessment
of an *infractor's* level of English competence.

I owe nobody respect. Certainly not someone who breaks the law and
steals other people's intellectual property. Respect is earned.

and would have been more productive just as

Ah, yes, here you can see in action the new-age practice of corporate
double speak applied to open source projects. This is not Google.
You are not fooling me or anyone else who still has a grain of
independent thought left.

This is a pathetic and disgusting attempt of silencing independent
contributors who still refuse to kneel after your coup d'état in
which you managed to replace the Go technical governance with a
thought police political organization vassal to Google.

In some sense, you have succeeded. I will never yield to you, you
can never silence me, but you certainly made me realise that my
association with the Go project is a mistake and a liability. I do
not want to be associated with your organization, even accidentally.
When I contribute to Go, I only make you people stronger. In fact,
this is your modus operandi; you rely on people who do the actual
technical work (either as part of the Go team, or as contributors)
in order to gain more support for your cause. To gain legitimacy.
To claim authority.

I cannot remove the code I have contributed to the Go project over
the years, but I can certainly stop contributing as an individual
in the future. I will make sure, best of my ability, that any
competent individual or organization who is evaluating Go is made
aware of who is actually pulling the strings here, and what they
are getting into.

Stalking people online for thought crimes! This is what the Go
project has succumbed to! And newcomers need to be aware of that.

You are luring people with technical arguments and weed them with
political correctness. Your propaganda machine is strong, but not
infallible. Just like all good propaganda, you rely on a majority
of true facts to hide you agenda and falsehoods. Yes, your technical
preaching is truthful, and that is the best disguise for your dark
agenda of manipulation, contr

[go-nuts] LookupHost taking up to 5 seconds to resolve localhost

[Peter Waller]

Hi Nuts,

net.LookupHost is taking a long time (up to 5 seconds) to resolve
localhost, where I expect it to be instant. At other times it can take
anywhere from 1-100ms, but it seems to reliably return a result shortly
after 5 seconds.

The details:

* I'm doing local development inside a docker container (alpine linux:
`docker run alpine sh`). Outside of this environment I can't seem to easily
get the problem to manifest, but I haven't tried hard.

* The problem manifests as many things having an additional random amount
of latency of order 100ms-5s.

* Inside the container, various services are talking to each other through
URLs which read `http://localhost:...`

* Resolv.conf has `nameserver 8.8.8.8` which may or may not be unreachable
at different times. If it is unreachable, then it takes 5 seconds to
resolve localhost.

* I'm on a slow mobile network, so I hit this frequently.

* I experience 5 second timeouts even on fast networks where the resolver
should be reachable, though this could perhaps be explained by an
out-of-date resolv.conf inside the docker container.

* Tweaking GODEBUG=netdns= to either go or cgo seems to fix the problem.

* The presence or absense of an empty /etc/nsswitch.conf has no effect.

* An empty resolv.conf still selects "dns,files" but then returns a result
fast (in microseconds).

My test program:

func main() {
start := time.Now()
_, err := net.LookupHost("localhost")
if err != nil {
log.Fatal(err)
}
log.Printf("Took %v", time.Since(start))
}

This seems to be the fundamental problem:

# GODEBUG=netdns=2 ./tmp-1
go package net: dynamic selection of DNS resolver
go package net: hostLookupOrder(localhost) = dns,files
Took 351.143424ms

Why is go choosing "dns,files"? If I choose either cgo or go as my resolver
(see end of mail), it correctly chooses `files,dns` then everything goes
quickly, taking microseconds rather than hundreds of milliseconds.

On a Debian host, it seems to correctly select `files,dns`.

Am I missing something?

Also, in the interests of trimming latency, is there any reason the Go
resolver shouldn't just directly return 127.0.0.1 as a hard-coded result
for "localhost"? I understood it may be required by the RFC, but the
strongest language I could find was in RFC2606:


  The ".localhost" TLD has traditionally been statically defined in
  host DNS implementations as having an A record pointing to the
  loop back IP address and is reserved for such use.  Any other use
  would conflict with widely deployed code which assumes this use.


Thanks,

- Peter

Selecting either resolver has the correct behaviour, compared with that
shown above:

# GODEBUG=netdns=go+2 ./tmp-1
go package net: GODEBUG setting forcing use of Go's resolver
go package net: hostLookupOrder(localhost) = files,dns
Took 376.164µs

# GODEBUG=netdns=cgo+2 ./tmp-1
go package net: using cgo DNS resolver
go package net: hostLookupOrder(localhost) = cgo
Took 102.334µs

-- 
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: Float32 math and slice arithmetics using SIMD

[Seb Binet]

Something like that?

https://github.com/golang/image/blob/master/vector/gen.go

-s

sent from my droid

On Oct 27, 2016 12:24 AM, "'simon place' via golang-nuts" <
golang-nuts@googlegroups.com> wrote:

> i was playing with SIMD last year,
>
> the approach i took was to try to minimise the M/C, so;
>
> no attempt to support general formula, let people combine the, pre-made,
> most common/expensive functions, like SIMD designers did, only up the
> complexity of formula supported and make it x-platform.
> make each call work on just one SIMD instruction sized array, so no
> looping or conditions in the M/C.
>
> i only tried 4-way 32bit x86 SIMD, performance was as you might expect.
> ~5ns for 4 x Sqrt(n+1)
>
> i wanted to put up some code, but only with neon working as well, i could
> go back to this since i have the h/w to try it on now.
>
> example of 4 x Sqrt(n+1) using address of array.
>
> // func f40pc(i *[4]float32)
> TEXT ·f40pca+0(SB),$16-8
> MOVQi+0(FP),AX   // get 64 bit address from first parameter
> MOVAPS (AX),X0   // load 128bit, 4xfloat32,  from memory
> MOVSS   $(1.0),X1   // load single precision var, 1.0 , into lower 32
> bits
> SHUFPS  $0x00,X1,X1  // duplicate it 4 times across the register
> ADDPS   X1,X0// parallel add 1
> SQRTPS  X0,X0// parallel sqrt in-place
> MOVAPS   X0,(AX)  // put 128bit back to same address
> RET
>
>
> ideally you might be able to use 'generate' a support a more expansive
> range of functions, essentially making an extremely simple go compiler in
> go, i have the feeling you could get a large proportion of the possible
> performance increase with only a simple, template implementation.
>
> also support for SIMD is not signalled by architecture alone, you need to
> check with a CPU-instruction to find out what’s supported. see
> "math/floor_amd64.s" and "math/floor_asm.go" to see this happen in the
> std.lib.
>
> --
> 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: Go interface

[Arafath M]

Thanks Volker. It works fine. Below is the example I tried, after doing *go
get -u -v golang.org/x/tools/cmd/guru *

*Command:*
guru implements C:\Go\src\net\http\server.go:#2538

*Result:*
C:\Go\src\net\http\server.go:86:6: interface type ResponseWriter
C:\Go\src\net\http\h2_bundle.go:4474:6: is implemented by pointer
type *http2responseWriter
C:\Go\src\net\http\filetransport.go:69:6:   is implemented by pointer
type *populateResponse
C:\Go\src\net\http\server.go:365:6: is implemented by pointer type
*response
C:\Go\src\net\http\server.go:2560:6:is implemented by pointer type
*timeoutWriter
C:\Go\src\net\http\cookie_test.go:128:6:is implemented by map type
headerOnlyResponseWriter
C:\Go\src\io\io.go:90:6:implements io.Writer


Sincerely,
Arafath M

On Thu, Oct 27, 2016 at 12:50 PM, Volker Dobler 
wrote:

> There is guru (golang.org/x/tools/cmd/guru) which can answer this
> question if it really comes up (I rarely feel the need to know all
> type implementing flag.Getter).
>
> V.
>
>
> Am Donnerstag, 27. Oktober 2016 09:11:04 UTC+2 schrieb Arafath M:
>>
>> Hi,
>>
>> Using interface is easy in Go. But, while studying an existing code
>> base, it is very difficult to find which types have implementation of a
>> particular interface. The situation will become worse, if there are many
>> interface functions inside an interface definition.
>>
>> In another languages, it is easy to just search for the class, which
>> implements a particular interface.
>>
>> For example in Java,
>>
>> interface Animal {
>>public void eat();
>>public void travel();
>> }
>>
>> public class MammalInt implements Animal {
>>
>>public void eat() {
>>   System.out.println("Mammal eats");
>>}
>>
>>public void travel() {
>>   System.out.println("Mammal travels");
>>}
>>
>>public int noOfLegs() {
>>   return 0;
>>}
>>
>>public static void main(String args[]) {
>>   MammalInt m = new MammalInt();
>>   m.eat();
>>   m.travel();
>>}
>> }
>>
>> By seeing the above line "*public class MammalInt **implements Animal*" one
>> can easily understand that Animal interface is implemented in MammalInt
>>
>> In Go, as far as I know, I need to search for all interface functions to
>> find whether a type implements a particular interface or not.
>>
>> Have anybody else experienced the same? If yes, what is the solution?
>>
>> *Note:* Personally I like to write code in Go; all of my recent projects
>> are in Go. I prefer Go than Java.
>>
>> Sincerely,
>> Arafath M
>>
> --
> 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: Go interface

[Volker Dobler]

There is guru (golang.org/x/tools/cmd/guru) which can answer this
question if it really comes up (I rarely feel the need to know all
type implementing flag.Getter).

V.

Am Donnerstag, 27. Oktober 2016 09:11:04 UTC+2 schrieb Arafath M:
>
> Hi,
>
> Using interface is easy in Go. But, while studying an existing code base, 
> it is very difficult to find which types have implementation of a 
> particular interface. The situation will become worse, if there are many 
> interface functions inside an interface definition.
>
> In another languages, it is easy to just search for the class, which 
> implements a particular interface.
>
> For example in Java,
>
> interface Animal {
>public void eat();
>public void travel();
> }
>
> public class MammalInt implements Animal {
>
>public void eat() {
>   System.out.println("Mammal eats");
>}
>
>public void travel() {
>   System.out.println("Mammal travels");
>} 
>
>public int noOfLegs() {
>   return 0;
>}
>
>public static void main(String args[]) {
>   MammalInt m = new MammalInt();
>   m.eat();
>   m.travel();
>}
> }
>
> By seeing the above line "*public class MammalInt **implements Animal*" one 
> can easily understand that Animal interface is implemented in MammalInt 
>
> In Go, as far as I know, I need to search for all interface functions to 
> find whether a type implements a particular interface or not.
>
> Have anybody else experienced the same? If yes, what is the solution? 
>
> *Note:* Personally I like to write code in Go; all of my recent projects 
> are in Go. I prefer Go than Java.
>
> Sincerely,
> Arafath M
>

-- 
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] Go interface

[Arafath M]

Hi,

Using interface is easy in Go. But, while studying an existing code base,
it is very difficult to find which types have implementation of a
particular interface. The situation will become worse, if there are many
interface functions inside an interface definition.

In another languages, it is easy to just search for the class, which
implements a particular interface.

For example in Java,

interface Animal {
   public void eat();
   public void travel();
}

public class MammalInt implements Animal {

   public void eat() {
  System.out.println("Mammal eats");
   }

   public void travel() {
  System.out.println("Mammal travels");
   }

   public int noOfLegs() {
  return 0;
   }

   public static void main(String args[]) {
  MammalInt m = new MammalInt();
  m.eat();
  m.travel();
   }
}

By seeing the above line "*public class MammalInt **implements Animal*" one
can easily understand that Animal interface is implemented in MammalInt

In Go, as far as I know, I need to search for all interface functions to
find whether a type implements a particular interface or not.

Have anybody else experienced the same? If yes, what is the solution?

*Note:* Personally I like to write code in Go; all of my recent projects
are in Go. I prefer Go than Java.

Sincerely,
Arafath M

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