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

The solution to Close returning an error, is to defer Close() and then have a second Close() with error checking in the happy path. I just wish the io.Closer contract would require, that this has to be safe (= not panic). Luckily it is, for the vast majority of Closers at least. On Fri, Sep 8,

[go-nuts] Re: [ANN]: A Text Editor based on Acme in Go

>Which cross platform UI are you using? The short answer is none. Except for Shiny, It's all done from scratch, but here's the more-accurate answer: - Event pipe and Screen rendering: exp/shiny - Windows and tiling: Done from scratch - Text management: Uses my amalgamated port

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

Thanks a lot! 在 2017年9月8日星期五 UTC+8下午8:23:39，Ian Lance Taylor写道： > > On Mon, Sep 4, 2017 at 10:02 PM, 刘桂祥 > wrote: > > > > I have a question about golang preempt schedule, here is my example > code; > > > > I doubt why the bar groutine don't happen preempt schedule?

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

> > P.S. someone else proposed wrapper with error handling in defer. > IMO it is as bad as watch - spooky, at distance, clunky. > That was me. My background is many years of C++ and it feels natural to me (RAII). I follow the pattern: there must be defer Close immediately after acquire

[go-nuts] Story: writing scripts in Go

Hi, I wrote a story about my experience in trying to write scripts in Go . Would love your opinion about it! Please comment in the gist itself, and not here. Cheers, Eyal -- You received this message because you are subscribed to

Re: [go-nuts] Tools for 80 column split for golang

(there's also an argument in there that "handlers.LoggingHandler" should actually be called at most "handlers.Logging", but probably even "handlers.Log". And that the other names are also not great… but that's a different argument) On Fri, Sep 8, 2017 at 8:21 PM, Axel Wagner

Re: [go-nuts] Tools for 80 column split for golang

I think people are focusing on the wrong part of Jakob's reply. Focus on the "if your line is too long, it's probably a symptom of a too complicated expression" part, not the "line-length limit doesn't matter" part. I am very rarely exceeding 80 columns. For example: var h http.Handler h =

Re: [go-nuts] Tools for 80 column split for golang

I haven't edited on a true text mode terminal since 1992, but a column limit is still useful. This and the other Go standards for relatively fixed formatting are not its strong suit. On Wednesday, September 6, 2017 at 11:36:04 PM UTC-7, Jakob Borg wrote: > > On 7 Sep 2017, at 06:10, Sankar

[go-nuts] goreturns doesn't add missing returns

I'm trying to get goreturns to work on Windows 10 64bit with go 1.9. If I run goreturns with -p parameter it displays following errors main.go:4:2: could not import errors (Config.Importer not installed) main.go: typechecking failed (continuing without type info) package main import (

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

Sure! I'm happy to listen to the experience of you all and to keep working using the existent approach. Thanks, everyone. Dorival On Friday, September 8, 2017 at 10:29:02 PM UTC+10, Marvin Renich wrote: > > * Dorival Pedroso [170908 02:08]: > > The "watch" strategy would, of

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

* Dorival Pedroso [170908 02:08]: > The "watch" strategy would, of course, allow us to do the important steps > you've mentioned (e.g. clean up and so on). > > For instance: > watch err != nil { > // do the important things > return err > } Except that "do the

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

On Mon, Sep 4, 2017 at 10:02 PM, 刘桂祥 wrote: > > I have a question about golang preempt schedule, here is my example code; > > I doubt why the bar groutine don't happen preempt schedule? (I build with > -gcflags “-N -l” to stop func inline) > > More if my server with one

[go-nuts] Re: [ANN]: A Text Editor based on Acme in Go

Hello, wow looks promising. Which cross platform UI are you using? Regards, Lino -- 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

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

On Thu, 7 Sep 2017 17:03:06 -0700 (PDT) Dorival Pedroso wrote: > Wouldn't be great to have a "syntactical sugar" to make things (at least a > little bit) simpler in our beloved Go language? No. Proposed (*also by past me*) "watch" construct is bad for anyone reading code,

Re: [go-nuts] const struct

On Fri, Sep 8, 2017 at 2:52 PM, DrGo wrote: > Sorry if this was asked before, but I could not find any relevant posts. > > Any reason why this struct literal (made up of fields that can be declared > const) is not allowed? https://golang.org/ref/spec#Constants describes

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

please replace: "will return immediately to the [...]" with "will jump immediately to the [...]" (sorry) On Friday, September 8, 2017 at 4:07:35 PM UTC+10, Dorival Pedroso wrote: > > Hi Dave, > > The "watch" strategy would, of course, allow us to do the important steps > you've mentioned (e.g.

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

Hi Dave, The "watch" strategy would, of course, allow us to do the important steps you've mentioned (e.g. clean up and so on). For instance: watch err != nil { // do the important things return err } The watch basically "groups common tasks". For example, If we have so many tasks, we