Re: [go-nuts] What does -fm mean as a suffix for a runtime function name?

To distinguish it from main.(*T).Bar, which is a different thing (the method without receiver already supplied). On Tue, Jul 5, 2016 at 9:04 PM Gregory Golberg wrote: > Yes, it is noted - I specifically made this example like so. But why? > > If I were to parse the Name()

Re: [go-nuts] What does -fm mean as a suffix for a runtime function name?

Yes, it is noted - I specifically made this example like so. But why? If I were to parse the Name() string I could still figure out that this is a method - because main.(*T).Bar-fm shows that it's on type T. So what's the point of the suffix? On Tue, Jul 5, 2016 at 8:20 PM, Matt Harden

Re: [go-nuts] What does -fm mean as a suffix for a runtime function name?

I'm not sure what it stands for (function from method?). But note that this is a Method Value https://golang.org/ref/spec#Method_values, so it's distinct from the method itself, which doesn't have a receiver already supplied. https://play.golang.org/p/P2TELvh1Ho On Tue, Jul 5, 2016 at 7:38 PM

Re: [go-nuts] liteide x30 released

DING our QT professional. BR fino -- 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

[go-nuts] Re: Importing a main package

One way to solve this is to send a pull request to the author of the tool that extracts functionality that you want to reuse into a package. This will benefit any future users that are in the same situation. There might be reasons that the author of the tool will be against such change though.

[go-nuts] liteide x30.1 released

Hi, all. LiteIDE X30.1 released!. add quick open symbol (ctrl+shift+o), add open editor windows, fix gotools vendor error. This version gotools and gocode build on Go1.7 beta2. Quick Open： Ctrl+P Quick Open Ctrl+Alt+P Quick Open Editor ~ Ctrl+Shift+O Quick Open Symbol @ Ctrl+L

Re: [go-nuts] Compiling very old version of Golang...

fascinating, thanks rob :) On Wednesday, July 6, 2016 at 1:02:50 AM UTC+10, Rob 'Commander' Pike wrote: > > There was very little code Go code in the early days. This was bootstrap > time. The path was, by hand: run the compiler, run the linker, run the > binary. Makefiles showed up when there

[go-nuts] Re: Go 1.7 beta1, linux/amd64: godoc command serves tour, no package documentation

I figured out (just a little too late) that there's a 1.7 beta2 out, and it's fixed 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

[go-nuts] Go 1.7 beta1, linux/amd64: godoc command serves tour, no package documentation

When I run godoc with Go 1.7 beta1, I can't find any way to view the documentation on packages installed on my local system. If I run godoc it automatically launches the tour in my browser, and all links within that page are links to parts of the tour. If I manually change the relative URL from

Re: [go-nuts] net/smtp Client.hello() returns a single error and drops the ehlo error entirely

Should I perhaps create a github issue to address this? On Friday, July 1, 2016 at 3:16:24 PM UTC-6, Ian Lance Taylor wrote: > > On Fri, Jul 1, 2016 at 1:17 PM, 'Matthew Altman' via golang-nuts > wrote: > >

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

Seems to me that not leaking API outside of the package it is being used is a must for a vendored package. -- 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] function with goroutine returned will kill its goroutine?

In addition to that, all goroutines exit when the main function exits. In your code, this happens when i == 5. This explains the output that you get. Both goroutines are able to produce five numbers until the main loop finishes and the main function exits. On Monday, July 4, 2016 at 5:13:39 PM

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

On Tue, Jul 5, 2016 at 1:52 PM, Peter Bourgon wrote: > Since you removed the vendor/ directory from jitsi/jap, everything is > working as expected, right? Yes, but the vendor dir was in the application code, not the library (eg. it was at jap/cmd/jap/vendor, not at

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

Since you removed the vendor/ directory from jitsi/jap, everything is working as expected, right? On Tue, Jul 5, 2016 at 8:46 PM, Sam Whited wrote: > On Tue, Jul 5, 2016 at 1:37 PM, Peter Bourgon wrote: >> As of today, if your binary vendors any other

[go-nuts] How to print a decrypted private RSA key?

Hello. I am trying to write code that takes the encrypted private half of an SSH key plus its password, and output the decrypted secret key. I think I am using crypto/x509 and encoding/pem correctly to decrypt the data – if I change the password, the expected error results – but I can't seem

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

On Tue, Jul 5, 2016 at 1:37 PM, Peter Bourgon wrote: > As of today, if your binary vendors any other package, you need to > ensure that package doesn't have a vendor/ directory anywhere in the > source tree. Library maintainers can be good citizens by ensuring > their libraries

[go-nuts] Sqlite linking error in windows

Hello guys, I am using github.com/xeodou/go-sqlcipher pkg But it is not compiling in windows any one have any idea How do i link to -lcrypto C:\Users\vijay\Desktop>go get github.com/xeodou/go-sqlcipher # github.com/xeodou/go-sqlcipher

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

On Tue, Jul 5, 2016 at 12:15 PM, Keith Rarick wrote: > You don't have to vendor anything from your own repo, but you do have to > vendor everything from outside your repo. (To be precise, the distinction is > between inside and outside the directory containing the vendor directory.)

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

You don't have to vendor anything from your own repo, but you do have to vendor everything from outside your repo. (To be precise, the distinction is between inside and outside the directory containing the vendor directory.) Aside from that, make sure that the dependency in question is being

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

On Tue, Jul 5, 2016 at 10:17 AM, Konstantin Khomoutov wrote: > AFAIK, vendoring explicitly implements an all-or-nothing approach: > you're supposed to resolve transitive dependencies yourself, and vendor > them all. That's my understanding too, but it seems

Re: [go-nuts] Vendored trace package causes panic because of implicit handlers

On Tue, 5 Jul 2016 10:05:27 -0500 Sam Whited wrote: > I'm running into a problem with the trace package; I'm trying to build > an application that has a vendored version of it, and one of the > modifications I've made imports a library that also uses the trace > package. > >

Re: [go-nuts] calling file.Write() concurrently

On Tue, 5 Jul 2016 05:46:17 -0700 (PDT) Pierre Durand wrote: [...] > My real question is: is there a problem in the *writeBuffer()* > function ? It is very simple, and it looks that it works. I'd not reinvent the wheel and use bufio.NewWriter() to wrap your file object

Re: [go-nuts] calling file.Write() concurrently

A better solution would be to compose a new Writer wrapping the existing one with a mutex. -- 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] calling file.Write() concurrently

@Dave Cheney: I want to avoid a *global* mutex, because my function can write to different files. @Konstantin Khomoutov: You are right, I could use a map of mutexes. As Alex Bligh said, I also need to add a mutex on this map, which is a bit complicated... I'm not using concurrency to write

Re: [go-nuts] calling file.Write() concurrently

> On 5 Jul 2016, at 10:38, Pierre Durand wrote: > > Hello! > > My code: https://play.golang.org/p/pg-p17UuEW > I'm trying to append lines to a file concurrently. > > My first write() function is buggy, because WriteString() are called by > several goroutines in

Re: [go-nuts] calling file.Write() concurrently

On Tue, 5 Jul 2016 02:38:28 -0700 (PDT) Pierre Durand wrote: > My code: https://play.golang.org/p/pg-p17UuEW > I'm trying to append lines to a file concurrently. > > My first write() function is buggy, because WriteString() are called > by several goroutines in

[go-nuts] calling file.Write() concurrently

Why do you want to avoid a mutex? -- 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

[go-nuts] Re: A proposal for generic in go

Lol, Doug Cheney. -- 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

[go-nuts] Re: A proposal for generic in go

On Saturday, July 2, 2016 at 9:12:54 AM UTC-4, Chad wrote: > > > > The appeal of generics is probably a false appeal. > > Then, if you accept the trilemma described at http://research.swtch.com/generic, that puts you in favor of "slow programmers"... just kidding. I went back to read all the

[go-nuts] calling file.Write() concurrently

Hello! My code: https://play.golang.org/p/pg-p17UuEW I'm trying to append lines to a file concurrently. My first write() function is buggy, because WriteString() are called by several goroutines in unexpected order. So, I've written writeMutex(), that uses a mutex. It works as expected, but in