[go-nuts] GOPROXY="https://proxy.golang.org,direct" behaviour

2019-07-04 Thread Lei Ni
Hi all, I am a little bit confused at what is the expected behaviour for GOPROXY="https://proxy.golang.org,direct";. On my system when using Go 1.13 beta 1, go env reports that GOPROXY="https://proxy.golang.org,direct";. When `go build .` tries to access a package hosted on github.com, proxy.

Re: [go-nuts] Announcing gg ("gigi") your new friend

2019-07-04 Thread Wojciech S. Czarnecki
On Thu, 4 Jul 2019 09:10:09 -0700 Michael Jones wrote: Great work, thank you :) > Recently I shared my Survey > program, saying that it was a sidestep from what I was working on but > interesting and hopefully useful to others. Here is the real thing, na

[go-nuts] try? how about try {} curious if anyone thinks this might be better.

2019-07-04 Thread Chris Holland
Problems with try: 1 - hiding the return 2 - error decoration The motivation behind this "issue" seems somewhat suspect. I get the consensus the idea that people think the current state of the art `if err != nil { .. }` its verbose. I'd argue that isn't the issue with it. If we want to

Re: [go-nuts] Announcing gg ("gigi") your new friend

2019-07-04 Thread Michael Jones
Interesting. I will look. the issue is the level of the smartness. gg is basic (tokens) and below a full parse (syntax). The higher you go, the different the search questions can be. If you downloaded, please update and rebuild. I had mail about a performance problem and found an error of configur

[go-nuts] readonly []byte required

2019-07-04 Thread Ally Dale
[]byte is mutable in Go, but string is readonly, so []byte(string) in Go is actually allocate&memcopy, and this operation is costly. Sometimes, we need a readonly []byte parameter but we have string only, and we have no choice but allocate&memcopy to make a new []byte variable from string. Eg: n

Re: [go-nuts] Announcing gg ("gigi") your new friend

2019-07-04 Thread Andy Balholm
I recently ran across https://github.com/mvdan/gogrep . It does some of that. Andy > On Jul 4, 2019, at 5:30 PM, Bakul Shah wrote: > > Very nice! > > A natural great extension[1] would be language aware grep/sed/awk: > - return an enclosing parse construct aft

Re: [go-nuts] Announcing gg ("gigi") your new friend

2019-07-04 Thread Bakul Shah
Very nice! A natural great extension[1] would be language aware grep/sed/awk: - return an enclosing parse construct after matching something - match on a construct with some pieces wildcarded - replace one structure with another (but based on the match) Possible uses: - when you change an API of

Re: [go-nuts] Re: Announcing gg ("gigi") your new friend

2019-07-04 Thread Michael Jones
Niko, good question. You have your answer already but i’ll add installation advice in the readme or an install guide. Should be trivial anywhere Go is, “go get path && go install gg” On Thu, Jul 4, 2019 at 10:23 AM 'Niko Schwarz' via golang-nuts < golang-nuts@googlegroups.com> wrote: > What's you

[go-nuts] Simple `onErr` macro for common case error handling.

2019-07-04 Thread Wojciech S. Czarnecki
Robert Griesemer suggested[1] that `try` is just a macro. So I dare to propose a macro too, based on an 'invisible semicolons' precedence and with a straightforward implementation. ## `onErr` simple macro for common case error handling. A #32437 counter-proposal. To be read at https://gi

[go-nuts] Re: General thoughts about new proposals

2019-07-04 Thread Michael Ellis
Well said, Slawomir. Your sentiments put me in mind of a favorite quote about writing prose. *Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no u

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

2019-07-04 Thread robert engels
Sorry, they were posted in another similar thread: https://groups.google.com/d/msg/golang-nuts/_sE6BxUDVBw/Rk02duq6CQAJ https://groups.google.com/d/msg/golang-nuts/_sE6BxUDVBw/37-RUc-7CQAJ > On Jul 4, 2019, at 3:45 PM, mh cbon wrote: > > yes the zero value test seems akward from here also. > >

[go-nuts] Re: `on err` alternative to `try()` has traction...?

2019-07-04 Thread mh cbon
yes the zero value test seems akward from here also. It appears to me the proposal is sub optimal because, to put it clear, the operator is dumb. Its a disguised if with a one lin block statement. I believe it would gain a ton more usability by being smarter to allow for more useful predefined/e

Re: [go-nuts] Re: A counter proposal to the try proposal - catch

2019-07-04 Thread mh cbon
sorry, i cant find your posts by asking my friend google, not reading your signature. would you be kinder than me to post their urls so i can figure out how you consider few cases ? thank you. On Wednesday, July 3, 2019 at 4:14:19 PM UTC+2, Robert Engels wrote: > > The two posts I made regardin

Re: [go-nuts] Re: Announcing gg ("gigi") your new friend

2019-07-04 Thread Jan Mercl
$ go get ... On Thu, Jul 4, 2019, 19:23 'Niko Schwarz' via golang-nuts < golang-nuts@googlegroups.com> wrote: > What's your recommended strategy for installing it on linux? I guess it'll > take a few years before distributions have easy-to-install packages just > listed in their indices. > > On T

[go-nuts] Re: Announcing gg ("gigi") your new friend

2019-07-04 Thread 'Niko Schwarz' via golang-nuts
What's your recommended strategy for installing it on linux? I guess it'll take a few years before distributions have easy-to-install packages just listed in their indices. On Thursday, July 4, 2019 at 6:11:47 PM UTC+2, Michael Jones wrote: > > Recently I shared my Survey

[go-nuts] Announcing gg ("gigi") your new friend

2019-07-04 Thread Michael Jones
Recently I shared my Survey program, saying that it was a sidestep from what I was working on but interesting and hopefully useful to others. Here is the real thing, named gg, that Survey was a test for. GG combines lexical analysis and Go-native pattern ma

[go-nuts] wireguard-go seeking love & maintainership

2019-07-04 Thread Jason A. Donenfeld
Hi, The WireGuard project is seeking a technically capable maintainer for wireguard-go: https://git.zx2c4.com/wireguard-go/ The project is currently maintained, and it will continue to be maintained in the future. There's no shortage of man power, and we aren't facing any imminent or foreseeable

[go-nuts] Re: `on err` alternative to `try()` has traction...?

2019-07-04 Thread Michael Ellis
As noted by Aston, Jones, et al, the proposal is combining two ideas that are separable: 1. Allowing one-liners. I like the idea of leaving that to gofmt. I'd be ok with requiring braces and allowing gofmt to make the decision to format in one line or three using some reasonable crite

[go-nuts] gc: have Unwrap() wrapper, want Unwrap()

2019-07-04 Thread Gert
Does somebody have some time please to explain what I am forgetting to change in the go compiler. Why my added wrapper type is reconiest as instead of wrapper, thanks :) When you do ./all.bash you get errorString does not implement error (wrong type for Unwrap method) have Unwr

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

2019-07-04 Thread Slawomir Pryczek
It seems I'm hearing that a lot. If C++/Java is so great and go is so "primitive"... well what all these people are still doing in here? ;) And i'd take "primitive" if err!=nil over exceptions any time of the day, at least code is streamlined, ordered and easy maintainable this way. Then i can

[go-nuts] General thoughts about new proposals

2019-07-04 Thread Slawomir Pryczek
Following this group for couple years and I think that from some time the community is in some kind of crisis, because it seems that go1 is so good that there's a lack of some feature which will distinct go1 from go2, so everyone's trying to invent some code breaking change which will "distinct"

[go-nuts] Re: `on err` alternative to `try()` has traction...?

2019-07-04 Thread Slawomir Pryczek
On one side, it's 1000x better than the other error handling specs, at least it isn't going to turn code into unreadable, fragmented mess. On the other, Aston seems to have a point, it's just replacing one-liner... and it's not that great at all because with "if" you know what it's doing withou