[go-nuts] Re: Table Driven Test (TDT) and log only failed test case

[Jordan Krage]

Try using `t.Logf` instead of `fmt.Printf`.

On Saturday, January 27, 2018 at 6:03:13 AM UTC-6, Jérôme LAFORGE wrote:
>
> Of course, that was I already did. But I talk about the log into function 
> I want to test (in the example of playground:  func IsBuggyEven) .
> see: 
> https://play.golang.org/p/OWnEntLwfXa
>
>
> check 0 is even or odd, but I want see this log only for fail test case 
> (i.e when i == 5)
> check 2 is even or odd, but I want see this log only for fail test case 
> (i.e when i == 5)
> check 5 is even or odd, but I want see this log only for fail test case 
> (i.e when i == 5)
> --- FAIL: TestIsEven (0.00s)
> --- FAIL: TestIsEven/5_is_even (0.00s)
> /tmp/somewhere/mmoney_test.go:144: For 5, expected: false, actual: 
> true
> FAIL
> FAILcommon/utils0.044s
> Error: Tests failed.
>
>
> Le samedi 27 janvier 2018 10:30:27 UTC+1, Tamás Gulácsi a écrit :
>>
>> Use subtest (t.Run)
>
>

-- 
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: Badger Write Performance

[Jordan Krage]

Are you using 'SyncWrites=false'? (Or 'NoSync' with boltdb?)

It looks like the badger benchmarks from github.com/dgraph-io/badger-bench 
do not sync. 


On Thursday, January 18, 2018 at 1:33:02 PM UTC-6, dc0d wrote:
>
> Badger write performance is a bit worse than boltdb. And badger suggests 
> to batch writes. But so does boltdb.
>
> At the same time at badger's GitHub page it says it has higher write 
> performance compared to boltdb.
>
> Is there a sample of how to do high performance/throughput writes with 
> badger?
>

-- 
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: do {} for x, why or why not?

[Jordan Krage]

The spec  says 'keyword' are 
"reserved and may not be used as identifiers", so adding any new keyword 
would necessarily break existing programs which use that keyword as an 
identifier, regardless of restrictions on the keyword's use. Perhaps you 
mean a less restricted class of 'reserved word' (for example: like 'iota 
and 'nil')?  But 'for' is a keyword, so adding 'do' or 'while' as anything 
other than a keyword seems unappealing and suspect, even if technically 
possible.

On Sunday, March 5, 2017 at 1:07:35 AM UTC-6, Michael Jones wrote:

> Minor follow up along those lines: i think we *could* add a new keyword or 
> form (for any purpose), it just needs to be one that does not break 
> existing programs.
>
> as an example
>
> x := 12345.12345
> a := int(x)
>
> could be elaborated as
>
> x := 12345.12345 rounded 27 //bits of mantissa
>
> or 
>
> a := int(x, 27) // bits of mantissa
>
> which are changes that break nothing. They are also not  proposal...just 
> saying that a new keyword like 'rounded' that goes after a < value>> would not conflict (i think...just winging it here) and neither 
> would new additional arguments in a cast.
>
> So yes, new is not impossible. The alias mechanism found a way to inert 
> new meanings in a way that did not change existing valid programs.
>
> The "{...}for <>" is also an issue since either the loop can 
> have no local control variables or else the body of the "{...}" uses them 
> before they are defined at the bottom. This is not nice.
>
> Maybe for Go 2 we could lobby for:
>
> for <> {
><>
> } while <>
>
> which would compile as:
>
> {
>   <>
> TOP:
>   if !<> goto DONE
>   <>
>   if !<> goto DONE
>   <>
>   goto TOP
> DONE:
> }
>
>
>
>
> On Sat, Mar 4, 2017 at 10:32 AM, Axel Wagner  > wrote:
>
>> There would be a way to add them without adding a new keyword:
>>
>> {
>>// stuff
>> } for condition
>>
>> I'm not saying I want it, or that it's a good idea, just that "we can't 
>> add a new keyword" doesn't seem a good argument for not doing it. At least 
>> at a cursory glance I don't see why we'd need the do keyword.
>>
>> On Sat, Mar 4, 2017 at 1:21 AM, Michael Jones > > wrote:
>>
>>> I asked for this early...long before it was too late. (Existing valid 
>>> programs ma have variables named 'do' so it is a non starter in that form. 
>>>
>>> Rob's objection was wise and thoughtful. He wanted Go to be friendly to 
>>> program transformation and he felt that a single uniform iteration 
>>> construct would be "more better" for that than the workarounds you have 
>>> been shown would be "more bad" stylistically. 
>>>
>>> I did not get what I asked for, but I did get an education about careful 
>>> trade offs. 
>>>
>>> On Sat, Mar 4, 2017 at 12:06 AM  
>>> wrote:
>>>
 It's not really, it is just syntactic sugar. I just happen to think 
 that this kind of loop is common enough to have dedicated syntax. Not 
 necessarily the syntax I used in my example (that has its issues), but 
 something similar.

 Your example it is how I do it myself currently :)


 On Friday, March 3, 2017 at 6:00:46 PM UTC-5, peterGo wrote:
>
> milo,
>
> How is your loop different from this?
>
> for {
> // 
> if condition {
> break
> }
> }
>
> Peter
>
> On Friday, March 3, 2017 at 5:00:41 PM UTC-5, milo.chr...@gmail.com 
> wrote:
>>
>> I rather like Go's loops, they are simple and easy to remember, and 
>> the problem so many languages have with dozens of different loop 
>> keywords 
>> is neatly avoided. Too many loop types is simply a pain, but I think 
>> that 
>> one more wouldn't hurt...
>>
>> Basically the following would be helpful in some cases without being 
>> too "odd" compared to what is existing:
>>
>> do{
>>  // 
>> }for condition
>>
>> Is this a good idea? Why or why not? Anyone else have a better idea 
>> for the syntax? (depending on how you look at it either "do" or "for" is 
>> redundant, but removing "do" would probably require too much lookahead)
>>
> -- 
 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.

>>> -- 
>>> Michael T. Jones
>>> michae...@gmail.com 
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>
>
> 

[go-nuts] Re: Serve large files

[Jordan Krage]

Try using os.Open to get a *File (which implements io.Reader), and then 
io.Copy to the response from the file.

On Tuesday, February 28, 2017 at 5:13:20 AM UTC-6, Jeffrey Smith wrote:
>
> I'm trying to server up a file that can be very large so would like to try 
> and stream the content back.
>
> package main
>
> import (
> "bytes"
> "fmt"
> //"io"
> "io/ioutil"
> "log"
> "net/http"
> )
>
> func main() {
>
> http.HandleFunc("/", serverFile)
> if err := http.ListenAndServe(":8085", nil); err != nil {
> log.Fatal(err)
> }
>
> }
>
> func serverFile(w http.ResponseWriter, r *http.Request) {
>
> streamPDFbytes, err := ioutil.ReadFile("./large.txt")
> if err != nil {
> fmt.Println(err)
> return
> }
>
> b := bytes.NewBuffer(streamPDFbytes)
>
> w.Header().Set("Content-Disposition", 
> "attachment;filename=large.txt")
> //io.Copy(w, b)
> if _, err := b.WriteTo(w); err != nil {
> fmt.Fprintf(w, "%s", err)
> }
> }
>
> I tried using this but I believe ioutil.readFile actually calls 
> ioutil.readAll so sticks the whole content of the file into a byte array. 
> What am i doing wrong?
>

-- 
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: Too many field tags, how to split definitions ?

[Jordan Krage]

As of Go 1.8, this should be easy.  You can now convert between two structs 
which differ only in tags (1.8 release notes 
), so you can have a separate 
struct definition for each type (json, bson, gorm, strom, etc.).


On Tuesday, January 24, 2017 at 7:30:58 AM UTC-6, skat...@root.gg wrote:
>
> Hello,
> I'm looking for a way to split fields tags in multiple files.
>
> My application can work with different backends (mongodb / sql / storm) that 
> could persist the same objects. Add json for the Rest API and the fields 
> tags definitions start to be really ugly.
>
> type MyStruct struct {
>  ID string `json:"id" bson:"id" gorm:"column:id;primary_key" 
> storm:"unique"`
>  Creation int64 `json:"uploadDate" bson:"uploadDate" 
> gorm:"column:uploadDate" storm:"index"`
>  TTL int `json:"ttl" bson:"ttl" gorm:"column:ttl"`
>   ...
> }
>
> Backend code is splitted into modules and I'd like that each module define 
> tags it needs. 
> Does anyone sees a solution ?
>

-- 
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] JSON decode streaming : Go forward when format is not json

[Jordan Krage]

>
> Robustness brings complexity here.
>
Relevant: RFC7464 - JavaScript Object Notation (JSON) Text Sequences 


Given that format, it should be possible to parse record boundaries 
reliably, and then use the std lib to unmarshal them individually.

On Friday, January 20, 2017 at 3:54:21 AM UTC-6, Thomas Solignac wrote:
>
>
> Thank you both for your answers.
>
> It's true that there is a convention for JSON streaming in which one each 
> json message is followed by a '\n'.
>
> There is + and - for this convention.
>
> *+ :*
> -> I can detect bad JSON
>
> *- :*
> -> The most important : It's a little more painful for final user. It's 
> already rare to have a WS connection rather than HTTP, I'm not confortable 
> with the idea tu push forward the first impression of weirdness.
> -> Secondly, I can't use standard decoder package anymore for this. I need 
> an other package, or do it my self. But the parsing is not trivial, as I 
> can get '\n' or Json reserved character inside a string. Robustness brings 
> complexity here.
>
>
> However, such different answers let me get an accurate synthesis.
> This allows me to make a decision :
>
> I'm going to stay on the actual convention, with the standard decoder.
>
> I added a new error message, indicating that the JSON message is not valid.
> And I'm trying now to get that bad formatted message for more explicit 
> error. (Maybe read directly the socket ? Let's set)
>
>
> Thank you for this enlightening discussion !
>
>
>
>
> Le jeudi 19 janvier 2017 22:43:13 UTC+1, nost...@gmail.com a écrit :
>>
>> A partial stream must still be a valid stream. Once the stream is in an 
>> invalid state, the decoder doesn't know how to proceed. Since none of the 
>> value types that can be represented by JSON can begin with the letter "T", 
>> the stream can be considered invalid soon as the decoder encounters that 
>> character. 
>>
>> There are some methods for JSON communication that define a way to have 
>> separate chunks within a stream. A common one is a stream that has 
>> individual JSON values separated by new lines. If you were implementing 
>> such a stream, a valid response might be to continue reading until you 
>> reach the next new line, and then attempt to start a new decode from there. 
>
>

-- 
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] Binding receiver object to a method expression, to get a method value

[Jordan Krage]

Would a simple single method interface meet your needs?

type fooer interface {
foo() bool
}

func (a *A) foo() bool { ... } 

func bar(f fooer) {
if f.foo() {
...
}
}

func main() {
a := { ... }
bar(a)
}

On Wednesday, January 18, 2017 at 8:55:07 PM UTC-6, Bryan Chan wrote:
>
> On Wednesday, 18 January 2017 16:39:03 UTC-5, rog wrote:
>>
>> On 18 January 2017 at 18:45, Bryan Chan  wrote: 
>> > But I couldn't find a way to bind a receiver to a method expression, 
>> such 
>> > that the resulting method value can be invoked at a later time. Would 
>> this 
>> > be a useful addition to the language? Or did I miss something? 
>>
>> If a is an object with the method foo, a.foo will give you a function 
>> that 
>> will invoke the method at a later time. 
>>
>> See https://golang.org/ref/spec#Method_values 
>>
>  
> I understand what method values are. My original email already contained 
> an example. What I want to do is to store away a method expression, and 
> then over time, bind that expression with different receivers to form 
> different method values, so that those method values can be passed to other 
> parts of the program and invoked later.
>
> --
> Bryan
>

-- 
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: encoding/gob decode []byte to multi struct types

[Jordan Krage]

Actually, it looks like the int/int8 distinction doesn't matter for gob.

> There is no int8, int16 etc. discrimination in the gob format; there are 
> only signed and unsigned integers.
>
https://golang.org/pkg/encoding/gob/ 

On Wednesday, January 18, 2017 at 8:43:27 AM UTC-6, Jordan Krage wrote:
>
> How about a compromise with denser type info? (could consider an int8 as 
> well) 
>  
> type infoType int
>
> const (
> firstType infoType = iota
> secondType
> ...
> )
>
> type Info struct{
> infoType
> IData interface{}
> }
>
>
> On Wednesday, January 18, 2017 at 12:07:49 AM UTC-6, casp...@gmail.com 
> wrote:
>>
>> First thanks for you reply. 
>> Because in fact, I have about more than 10 different struct types (maybe 
>> more and more), your suggest is good, this is better
>> type Info struct{
>> typeStr string // store the type info to decode IData
>> IData interface{}
>> }
>>
>> But I don't like to send the typeInfo through rpc call（I'm using gob to 
>> do rpc call），maybe there's a better way to do it, just I haven't found it。
>>
>> 在 2017年1月18日星期三 UTC+8上午11:12:05，Felipe Spinolo写道：
>>>
>>> Why not just create a wrapper struct? Something like:
>>>
>>> type Mixed struct{
>>> A *A
>>> B *B
>>> }
>>>
>>> And then just encode/decode that?
>>>
>>> On Tuesday, January 17, 2017 at 1:16:37 PM UTC-8, casp...@gmail.com 
>>> wrote:
>>>>
>>>> I got two struct types encoded into bytes by gob, I want to decode the 
>>>> bytes into a specific struct, is it possible without try all struct 
>>>> types(maybe 3 or more struct types)?
>>>>
>>>>  I want to decode bytes without specify which elem in mixedBytes is 
>>>> struct A, and which is struct B.
>>>> This is the playground url:  https://play.golang.org/p/F0Wp5eWdGu
>>>>
>>>> Is is possible to implement it by a map or something like this?
>>>>
>>>> var typesMap = map[string]reflect.Value{
>>>> "A": reflect.ValueOf(A{}),
>>>> "B": reflect.ValueOf(B{}),
>>>> }
>>>>
>>>>
>>>>
>>>>

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

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 <jma...@gmail.com > 
> 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.

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

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

[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