Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

That won't work if you want to create the name dynamically. It's also not very useful if you're in a debugger and want to navigate to a different goroutine. I'm actually thinking about writing an RFC for a SetGoroutineName function to allow to customize the name. It will be strictly accessible

[go-nuts] Re: Simple Go http daemon under systemd

Check this repository https://github.com/fmpwizard/mrwilson * It runs a very simple https service * Gets certificates using Let's Encrypt * Has ansible playbook to run the app under systemd feel free to ask any questions. Diego On Thursday, November 22, 2018 at 10:14:52 PM UTC-5, Tong Sun

[go-nuts] help with openpgp error: tag byte does not have MSB set

Hi, At work we get pgp encrypted files from different vendors, when our app tries to decrypt the file from one of them, I get: openpgp: invalid data: tag byte does not have MSB set But if I use the gpg command line, I'm able to decrypt it. Part of the verbose output from gpg when it decrypts

Re: [go-nuts] Re: GoAWK: an AWK interpreter written in Go

and always: https://www.cs.princeton.edu/~bwk/btl.mirror/awkc++.pdf On Thu, Nov 22, 2018 at 8:24 PM Tong Sun wrote: > > > On Tuesday, August 28, 2018 at 9:06:22 AM UTC-4, Ben Hoyt wrote: >> >> Once you have some proper benchmarks, it might be fun to compare GoAWK's >>> performance to that of my

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

It is possible and easy to create named functions and launch them. a := func(stuff){morestuff} go a(args) On Thu, Nov 22, 2018 at 7:38 PM Russtopia wrote: > Perhaps this is actually supported in Go v1 and I'm just missing something > simple, but it appears one can do > > func A() { > go

Re: [go-nuts] Re: GoAWK: an AWK interpreter written in Go

On Tuesday, August 28, 2018 at 9:06:22 AM UTC-4, Ben Hoyt wrote: > > Once you have some proper benchmarks, it might be fun to compare GoAWK's >> performance to that of my awk package . >> > > Nice -- will do! > Please post back when you've done that. I'm

[go-nuts] Re: go language sensitive editor?

Nice added features Serge. Any plan to PR them back, or you'd rather keep your fork to your self? Thx. On Wednesday, November 21, 2018 at 4:57:05 PM UTC-5, Serge Voilokov wrote: > > I am using micro editor: https://github.com/zyedidia/micro . It is > terminal-based, supports mouse, uses

[go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

Perhaps this is actually supported in Go v1 and I'm just missing something simple, but it appears one can do func A() { go func() { ... }() } but not func A() { go func B() { ... }() } or even func A() { func B() { .. } go B() } Does the syntax just not allow

Re: [go-nuts] does struct pointer *a == *b make sense?

On Fri, Nov 23, 2018 at 2:06 PM Youqi yu wrote: > > type T { > Name string > } > a := {Name:"test"} > b :={Name:"test"} > *a == *b > Hi, all, I am beginner at golang, I have a question that when compare struct > equality, I was told to use reflect.DeepEqual or make my own function. but > the

[go-nuts] Simple Go http daemon under systemd

Hi, I want to write a simple Go http daemon that return a static string regardless what the request is, like this one: https://github.com/suntong/dbab/blob/master/src/bin/dbab-svr#L20 and it needs to be working under systemd. *What is the best example that I can start with?* (They both, Go

Re: [go-nuts] does struct pointer *a == *b make sense?

Yes. They are equal. According to the go language spec: - Struct values are comparable if all their fields are comparable. Two struct values are equal if their corresponding non-blank fields are equal. You can go through that part of the

[go-nuts] does struct pointer *a == *b make sense?

type T { Name string } a := {Name:"test"} b :={Name:"test"} *a == *b Hi, all, I am beginner at golang, I have a question that when compare struct equality, I was told to use reflect.DeepEqual or make my own function. but the result of above code is true. Does it mean struct a equals struct b?

Re: [go-nuts] Re: go language sensitive editor?

And 15 years later, so one hopes for an improvement. The thing people ignore, or perhaps just don't know, about ed was that it was a breath of fresh air compared to all the commercial editors available at time. People judge it by the standards of today; by the standards of the time it was

Re: [go-nuts] Re: go language sensitive editor?

But sam is a pretty solid improvement over ed. On Tue, Nov 20, 2018 at 6:04 PM Rob Pike wrote: > > Ed is the standard text editor. > > -rob > > > On Wed, Nov 21, 2018 at 8:15 AM wrote: >> >> >> Another vote for VS Code. I'm a hobbyist and have tried lots of editors. >> >> On Tuesday, November

Re: [go-nuts] Re: go language sensitive editor?

http://man.cat-v.org/unix-6th/1/ed On Fri, Nov 23, 2018 at 12:48 AM Anirudh Vyas wrote: > Could never get this one - Ed is the standard editor, is there a > historical context of this? Did people say this a lot back when there were > vim emacs and Ed only as choices of editors? > On Nov 22,

[go-nuts] Distributed MapReduce in Go, is it possible?

Hi how are you can you help me I need distributed mapreduce code for golan Thank you -- 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] Pulling golang/go causes a merge conflict. Is it just me :(

On Thu, Nov 22, 2018 at 7:34 PM Muhammad Falak R Wani wrote: See https://groups.google.com/d/msg/golang-dev/8JmYrD3DWY0/oNVcA29FBgAJ -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Re: go modules and vendor: redundant features?

Vendoring MUST stay. Athens is another piece of software that has to be set up and keep update. Venoring solves this porblem and ols the one when dependencies go missing. On Saturday, November 17, 2018 at 5:33:55 AM UTC+1, Henry wrote: > > Hi, > > It seems to me that go modules and vendor

[go-nuts] Pulling golang/go causes a merge conflict. Is it just me :(

I am pretty sure I did not touch anything on my local master. Any fixes -mfrw -- 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: Distributed MapReduce in Go, is it possible?

در شنبه 25 مهٔ 2013، ساعت 0:14:52 (UTC+4:30)، Ziad Hatahet نوشته: > > On Fri, May 24, 2013 at 9:55 AM, Sanjay > > wrote: > >> >> As for Spark, as with LINQ, that kind of terse functional method-calling >> in Go is, AFAIK, impossible. But, again, look at Storm's API for doing >> realtime

Re: [go-nuts] recommend that error and panic auto coverting

A predefined handler which produces a panic appears in item (L) of Requirements to Consider for Go 2 Error Handling ...which is a comprehensive survey of error-related issues, most of which aren't mentioned in the draft

Re: [go-nuts] go language sensitive editor?

On Thu, Nov 22, 2018 at 8:54 AM Bakul Shah wrote: > What would be helpful is if 'go doc' had an -n option to show > filename:linenumer next to the go definitions its shows so that I > can right click on it and see the source file with cursor on the > right line! I subscribe to that idea. --

Re: [go-nuts] Re: go language sensitive editor?

https://www.gnu.org/fun/jokes/ed-msg.html On Thursday, 22 November 2018 13:49:09 UTC, Anirudh Vyas wrote: > > Could never get this one - Ed is the standard editor, is there a > historical context of this? Did people say this a lot back when there were > vim emacs and Ed only as choices of

Re: [go-nuts] Re: go language sensitive editor?

Could never get this one - Ed is the standard editor, is there a historical context of this? Did people say this a lot back when there were vim emacs and Ed only as choices of editors? On Nov 22, 2018, 05:28 -0800, Volker Dobler , wrote: > As emacs has not been recommended yet: Emacs! > > V. > >

[go-nuts] Re: go language sensitive editor?

As emacs has not been recommended yet: Emacs! V. On Tuesday, 20 November 2018 21:52:11 UTC+1, Pat Farrell wrote: > > I know, this is both a FAQ and an unanswerable question. I'm an old > programmer who has used nearly every editor known to man. I am not a fan of > whole-universe IDEs, but can

Re: [go-nuts] net/http/httputil.ReverseProxy Expect: 100-continue broken?

I suspect this has to do with the fact that you're doing a roundtrip for its side effects, but not reading the response body or closing it. If I fix that, everything seems to work as expected. Try configuring the TLS client with t.TLSClientConfig = {InsecureSkipVerify: true} On Mon, 19 Nov 2018

Re: [go-nuts] recommend that error and panic auto coverting

I will agree with your point. Even currently, when other ways exist, it highly not recommended to use recover. The only time I've had to use it was in systems that needed to be highly available and that could not break at all, even on bugs or implementation failures. This is a particularly rare

Re: [go-nuts] recommend that error and panic auto coverting

You're right, there is none. IMHO, making recovering from panics easier should be a none-goal. Panics should be reserved for irrecoverable violations of invariants (i.e. bugs) and not recovered, in the general case. The main reason panic/recover is useful today is that it allows to elide some

Re: [go-nuts] recommend that error and panic auto coverting

Sure it is, I think it's part of the same problem, but (mainly for the second example) it's more complementary than it is redundant. I haven't seen a possibility for "quick recovering" in go2 draft design concerning error handling. If there is one, could anyone point it out? Le jeu. 22 nov. 2018

Re: [go-nuts] recommend that error and panic auto coverting

This seems very similar (almost identical, safe for the choice of words maybe) to the Go 2 error handling draft design . On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux wrote: > I do like the idea, but

Re: [go-nuts] recommend that error and panic auto coverting

I do like the idea, but the form looks strange IMO. I'd rather make the "Must" convention a new keyword for the first example, and another one for the second (though I don't see a clear keyword for that). For a panic on error you'd write : data := must error_func() Maybe the "try" keyword would

[go-nuts] recommend that error and panic auto coverting

For an error function: data, err := error_func(…..) can be changed to panic style: data := panic error_func(……) And for a panic function: data := panic_func(……) can be changed to error style: data, err := error panic_func(…...) -- You received this message because you are subscribed to

Re: [go-nuts] Using git-codereview with GitHub

On Wed, 21 Nov 2018 14:48:20 + Paul Jolly wrote: > > There is hub [1]. If you have not heard it, its work by > > repo-branch-commits, > > Thanks, but as I understand it, this tool is branch-based. > > I want to make my workflow oriented around single commits (on a local > branch). > I

Re: [go-nuts] Re: go modules and vendor: redundant features?

The main issue tracking vendoring-related discussion is https://github.com/golang/go/issues/27227 On Thu, 22 Nov 2018 at 09:08, wrote: > > Vendor must be kept for when dependencies are no longer available online. > > On Saturday, 17 November 2018 04:33:55 UTC, Henry wrote: >> >> Hi, >> >> It

[go-nuts] Re: go modules and vendor: redundant features?

Vendor must be kept for when dependencies are no longer available online. On Saturday, 17 November 2018 04:33:55 UTC, Henry wrote: > > Hi, > > It seems to me that go modules and vendor attempt to solve the same > problem. I wonder whether we should just choose one and scrap the other, or >

[go-nuts] Re: go language sensitive editor?

LiteIDE here. https://github.com/visualfc/liteide On Wednesday, November 21, 2018 at 12:52:11 AM UTC+4, Pat Farrell wrote: > > I know, this is both a FAQ and an unanswerable question. I'm an old > programmer who has used nearly every editor known to man. I am not a fan of > whole-universe IDEs,