[go-nuts] Re: Dave Cheney's "Practical Go" book

Don't know, hope @Dave Cheney will be able to answer that. On Monday, September 4, 2017 at 6:03:18 PM UTC-7, chou wrote: > > I want to buy one, is it released out? > > 在 2017年9月5日星期二 UTC+8上午7:41:36，st ov写道： >> >> Any information on the contents and a release date? >> >> Couldn't find any details

[go-nuts] Re: One way - Unexported json field

Make a method that creates a copy of the Player with erasing the relevant fields: type Player struct { Id bson.ObjectId `json:"id,omitempty" bson:"_id,omitempty"` CustomField string`json:"customField,omitempty" bson:"customField,omitempty"` } func (player Player) Front

Re: [go-nuts] A question about evaluation of channel’s send statement

On Wed, Sep 6, 2017 at 2:26 AM, T L wrote: > > I mean it can be viewed as a bug for inconsistency. > But from the memory model view, it can also not be viewed as a bug. > It's not a bug. The code is clearly expecting some ordering between internal operations within two goroutines, this is an inco

Re: [go-nuts] error handling needs syntactical sugar

In the C world one can do things like int foo(char *infile, *outfile) { int n = -1, in, out = -1; ... if ((in = open(infile, O_RDONLY)) < 0 || (out = creat(outfile, 0666)) < 0 || (n = read(infile, buf, sizeof buf)) <= 0) goto err; ... return 0; err: close(in); if (out

Re: [go-nuts] Re: error handling needs syntactical sugar

Hi Michael, I fully agree with handling each single error ("health issue") as they are discovered. The idea of "watch" is NOT to replace this procedure. It's just a "syntactic sugar" to do what you are doing already. Cheers. Dorival -- You received this message because you are subscribed to

Re: [go-nuts] Re: What are test binaries?

Thanks! On Tuesday, September 5, 2017 at 2:14:07 AM UTC-7, Peter Waller wrote: > > On 5 September 2017 at 06:35, Volker Dobler > wrote: > >> A "test binary" is a normal binary compiled by go test including the test >> function >> from the *_test.go files which executes the tests when run.. >> >

Re: [go-nuts] Re: error handling needs syntactical sugar

...Go is not perfect. But there is subtle magic in this error business. Developers should look closely at errors. Imagine handling them as if you were a doctor and the error was a child's symptom or a test result. Choices: 1. Ask them how they feel, ignore it. Do a test, ignore it. Effectively you

[go-nuts] Re: error handling needs syntactical sugar

Since *defer* "is the last thing to happen", I think this code is all right: func something() (x int, err error) { watch err != nil { return } res, err = acquireResource() defer func() { if err == nil { err = res.Close() } }() err = abc1(

Re: [go-nuts] Re: Splitting CamelCaseWords in Go

Like this? https://play.golang.org/p/OIE8jdWVGB On Tue, Sep 5, 2017 at 12:33 PM, Tong Sun wrote: > > I'll be religiously avoiding "*unicode.IsUpper*()" as something mystery > happened in the past: > https://groups.google.com/d/msg/golang-nuts/714WQs85H3w/KEqKgmAqAAAJ > > BTW, *for my case*, I d

[go-nuts] Re: error handling needs syntactical sugar

Hi, yes we need the check condition you had before in defer. That seems fine. But there may be some other problems I haven't thought of. Cheers -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving em

[go-nuts] One way - Unexported json field

Hi guys, I would like to have fields in a custom type that : - are not exported when I mashall them (to send to front) - are imported when I decode them (from the from) This is the type : type Player struct { Id bson.ObjectId `json:"id,omitempty" bson:"_id,omitempty"` CustomField stri

[go-nuts] Re: error handling needs syntactical sugar

What about? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return straightway (because we

[go-nuts] Re: error handling needs syntactical sugar

What about the following? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return straightw

[go-nuts] Using dep tool behind proxy with mix of internal/external deps

I asked this on a relevant dep tool issue but I haven't heard a reply and wanted to see if anyone here has some insight... I've just started trying out dep in an internal project that is currently using glide. Similar to glide, I really can't use the "ini

[go-nuts] Re: error handling needs syntactical sugar

What about the following? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return straightw

Re: [go-nuts] Check if a file is executable

Er, the expression mode & 0111 evaluates whether a file mode is executable by authorized users. mode | 0111 would always yield a file mode with all executable bits enabled. On Tuesday, June 12, 2012 at 4:52:27 PM UTC-5, Kyle Lemons wrote: > > From http://golang.org/pkg/os/#FileMode > "The nine l

Re: [go-nuts] Re: Splitting CamelCaseWords in Go

I'll be religiously avoiding "*unicode.IsUpper*()" as something mystery happened in the past: https://groups.google.com/d/msg/golang-nuts/714WQs85H3w/KEqKgmAqAAAJ BTW, *for my case*, I do need the string, "FooBarBaz GNU PYTHON Standard" to be split exactly to be "Foo Bar Baz GNU PYTHON Standard

[go-nuts] Go-kit middlewares

In case of error, return error, don't call the next endpoint. Only context is given but you can give anything to the function which creates the middleware, so anything can be included in the closure. -- You received this message because you are subscribed to the Google Groups "golang-nuts" grou

[go-nuts] [ANN] Gogland EAP 13 has been released

As a heads up, EAP 14 has been released to solve a critical issue in EAP 13: https://twitter.com/GoglandIDE/status/905046993034203136 If you've had any issues with the IDE, please try the latest release. Thank you and apologies for any issues you may have encountered. -- You received this mess

Re: [go-nuts] Re: Splitting CamelCaseWords in Go

I've just joined the group and had to get activated, that's why my answer took so long. Should have waited until then. Thank you for the notice! I fixed it in the playground: https://play.golang.org/p/kuk6FxesDq. Although I wrote a benchmark (https://play.golang.org/p/YpnI257SHD), I didn't writ

[go-nuts] Re: 『Q』How to make hugepagesize work with Go?

What is the issue you are facing? You do not need to do anything special to enable Hugepages for Go. Huge page size is a kernel property usually set at Kernel compilation time or set by your Linux Distribution. Go does not care about what the underlying page size is, the page size is transparen

Re: [go-nuts] A question about evaluation of channel’s send statement

On Tuesday, September 5, 2017 at 12:20:02 PM UTC-4, T L wrote: > > IMO, I think this is a bug. > I mean it can be viewed as a bug for inconsistency. But from the memory model view, it can also not be viewed as a bug. > > On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote: >> >> BTW

Re: [go-nuts] A question about evaluation of channel’s send statement

IMO, I think this is a bug. On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote: > > BTW, the following one also prints 10. > > package main > > import ( > "fmt" > "time" > ) > > func main() { > var num = 10 > var p = &num > > c := make(chan int) > > go func() { >

Re: [go-nuts] A question about evaluation of channel’s send statement

BTW, the following one also prints 10. package main import ( "fmt" "time" ) func main() { var num = 10 var p = &num c := make(chan int) go func() { c <- *p * 1 // with this line we will get 11 from channel c //c <- num // with this line we will get 10 fr

Re: [go-nuts] A question about evaluation of channel’s send statement

The program is really racy, but the result is also really some counter-intuitive. The following program also print 10, which means evaluation of pointer dereference is some different to evaluation of other expressions in flow. package main import ( "fmt" "time" ) func main() { var

[go-nuts] Re: golang preempt schedule how work ?

For example, package main import ( "runtime" "time" ) var sum1 int64 func add1() { for i := 0; i < 1; i++ { runtime.Gosched() for j := 0; j < 1; j++ { sum1++ } } } func bar() { for { add1() } } func main() { runti

[go-nuts] Go-kit middlewares

Hello!I would like to understand how middleware works in go-kit. I want to write a middleware auth processor but do not understand how to describe the logic of the process. That is, I need to take the cookie values ​​from the context and perform the rights check? After all, in middleware com

[go-nuts] Re: error handling needs syntactical sugar

I've been doing something like this for long chains where "handle error" is the same: func something() (x int, err error) { defer func() { if err != nil { // handle error } }() res, err = acquireResource() if err == nil { defer func() {

Re: [go-nuts] error handling needs syntactical sugar

I think Rob is really on to something here and I have seen it evolve in my own programming. I tend to make simple things "flatter" and model things around cores that don't error out and just at the boundaries evaluate and possibly produce an error. Is that "monadic"? Anyway it gets easier if you tr

Re: [go-nuts] error handling needs syntactical sugar

Wojciech, you're right: It'll effectively work as a "catch" (or "recover"); e.g. something like: defer func() { if err := recover(); err != nil { fmt.Printf("ERROR: %v\n", err) } }() The only difference is that we wouldn't have to "throw" or "panic". The compiler would just "wat

Re: [go-nuts] error handling needs syntactical sugar

On Tue, 5 Sep 2017 00:20:09 -0700 (PDT) Dorival Pedroso wrote: > I realised I've written 569 "if err != nil": > And I've written 231 error messages > And I have a feeling that I've done only 20% of the error messages... Factor 2,46 so far. It directly *proves* that any 'watch' construct would g

Re: [go-nuts] error handling needs syntactical sugar

On Tue, 5 Sep 2017 00:11:02 -0700 (PDT) martin.r...@programmfabrik.de wrote: Ooops, bad paste to playground ['fail' logic leaked into https://play.golang.org/p/ig-KOi92Ku] Fixed is at: https://play.golang.org/p/dHE2wlwgIL -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this mes

Re: [go-nuts] error handling needs syntactical sugar

On Tue, 5 Sep 2017 00:11:02 -0700 (PDT) martin.r...@programmfabrik.de wrote: >- Make it easier to read and follow As a former "inventor" of the "watch construct" I may say that I was wrong. It is NOT easier to read and it is much harder to follow. I was then, as you are now, I was angry abou

Re: [go-nuts] Re: error handling needs syntactical sugar

Or you know, just panic ... errors as value are a convention, not a language construct. panic/defer ARE a language construct. I personally give the choice in my API, Must prefixed methods that panic or regular methods that return an error. The obvious advantage of panics is that the developer a

Re: [go-nuts] Re: error handling needs syntactical sugar

Thanks again, Rob. The blog post (https://blog.golang.org/errors-are-values) does shed some light. One of the ideas is to hold the *err* variable in a structure. I will definitively use this more often (I do have many structures and never thought of doing this!)---Thanks! The other idea is to

Re: [go-nuts] Re: What are test binaries?

On 5 September 2017 at 06:35, Volker Dobler wrote: > A "test binary" is a normal binary compiled by go test including the test > function > from the *_test.go files which executes the tests when run.. > It's worth nothing that this binary is ordinarily hidden if you just run `go test`. ... and

Re: [go-nuts] Re: error handling needs syntactical sugar

Exactly: a good amount of "if err != nil" appears in my tests (334 out of 569). I'll try to re-think the other cases... (e.g. https://github.com/cpmech/gosl/blob/master/la/blas2.go) No complaints here, by the way! Just enjoying this marvellous language! I'll read the blog post. Cheers. On Tues

Re: [go-nuts] Re: error handling needs syntactical sugar

If you find that lines like if err != nil are a significant fraction of non-test code, your code probably needs a better error handling strategy, not a language change. I have done measurements in the past and although people complain a lot about the presence of that statement, it shows up much les

[go-nuts] Re: error handling needs syntactical sugar

Fair enough. This would be perfect. Cheers On Tuesday, September 5, 2017 at 5:42:26 PM UTC+10, marti...@programmfabrik.de wrote: > > Dorival, > > I think we can celebrate already if we achieve anything with this > discussion. Let's not ask for too much, plus let's not make it too > complicated.

[go-nuts] Re: error handling needs syntactical sugar

Dorival, I think we can celebrate already if we achieve anything with this discussion. Let's not ask for too much, plus let's not make it too complicated. I think your proposed "watch err", hides too much and does too little. You can simply write (the inline code editor is broken, BTW) func .

Re: [go-nuts] error handling needs syntactical sugar

Martin, Certainly! I have (in https://github.com/cpmech/gosl): Total number of files = 430 Total number of lines = 73470 (NOTE: there are Go (30%), C (30%), C++ (16%), and Fortran (8%), plus Python and R files in there...) On Tuesday, September 5, 2017 at 5:24:28 PM UTC+10, marti...@programmfabr

[go-nuts] Re: error handling needs syntactical sugar

Hi Martin; What about two commands "*watch*" and "*watchif*"? The first works as the "*var*" command and the second as the "*if*" command. "*watch*" does: 1. In a function with *error* as an output (anywhere): returns in case the *err* declared with *watch err* (or *watch myerror*) becom

Re: [go-nuts] error handling needs syntactical sugar

Dorival, thanks for counting your error calls, but without any other number showing the size of your project they cannot really put in perspective ;-) And I think *watch* should not only be function bound, but bound to the current scope, same as *var*. Martin On Tuesday, September 5, 2017 at

Re: [go-nuts] error handling needs syntactical sugar

And I've written 231 error messages (I use a function called chk.Err() to do so): find . -iname "*.go" -exec grep -inH "chk.Err" {} \; | wc -l 231 See the messages here: https://gist.github.com/cpmech/d2e36dcbe277cd72605f3732d79c798b And I have a feeling that I've done only 20% of the error me

Re: [go-nuts] error handling needs syntactical sugar

I'm working on a Go project right now and I realised I've written 569 "if err != nil": find . -iname "*.go" -exec grep -inH "if err != nil" {} \; | wc -l 569 On Tuesday, September 5, 2017 at 4:57:45 PM UTC+10, Axel Wagner wrote: > > > > On Tue, Sep 5, 2017 at 8:49 AM, > > wrote: > >> Axel, >>

Re: [go-nuts] error handling needs syntactical sugar

Hi Axel, thanks for your input. I think Martin's proposal is all right. We'll certainly keep suggesting all good practices to handle errors (I myself have tons of error messages + handling..). Go is perfect in doing this. We can even mimic "try" + "catch" with "panic" + "recover" (although I r

Re: [go-nuts] error handling needs syntactical sugar

> > > You don't. But it's a bad idea. And "I want to make writing bad code > easier" isn't a very convincing argument for a language-change. > Ok, than I want to - Make it easier to read and follow - Make it possible to handle errors in one place instead of 10 I see you point, and yes, I