[go-nuts] why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

is there any logic here? Or just a hard rule? -- 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 ht

Re: [go-nuts] why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

On Sat, Jul 16, 2016 at 9:42 AM T L wrote: > is there any logic here? Or just a hard rule? https://play.golang.org/p/4YVDq2XLln -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

Re: [go-nuts] why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

On Saturday, July 16, 2016 at 4:20:36 PM UTC+8, Jan Mercl wrote: > > > On Sat, Jul 16, 2016 at 9:42 AM T L > > wrote: > > > is there any logic here? Or just a hard rule? > > https://play.golang.org/p/4YVDq2XLln > I know this result, but I just need the reason, not the result. > > > > -- > >

[go-nuts] Re: Strange results from append

On Saturday, July 16, 2016 at 1:28:32 AM UTC+8, Evan Digby wrote: > > I can't reproduce this in go playground (yet), but under what > circumstances would/could/should: > > nss := []namespace.Namespace{ > append(ns, g2message.NamespaceWin...), > append(ns, g2message.NamespaceSpend...), > } > > Ac

Re: [go-nuts] What dependency management tool do you use?

On 16/07/16 01:43, Florin Pățan wrote: > I feel this is a controversial statement. >Godep can do this just as well, in fact any vendoring tool can do this, > as long as you commit your dependencies. That is not true. Dave Cheney explained it very well at GDG Berlin Golang DevFest: https://www.yout

Re: [go-nuts] why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

On Sat, Jul 16, 2016 at 10:39 AM T L wrote: > I know this result, but I just need the reason, not the result. The method set distinction of T vs *T allows to forbid calling methods intended to mutate the receiver (ie. receiver is *T) on the wrong receiver type (T). The later case would mutate th

Re: [go-nuts] What dependency management tool do you use?

I know that talk very well since I'm the one Dave called a "compiler" at ~5:14. All the arguments about what's reproducible or not get muted when using vendoring. However, in order for that to be more effective, releases for various packages should be versioned and that controlled via the depen

[go-nuts] Re: TCP Server

On Thursday, 14 July 2016 17:41:32 UTC+3, EdgarAlejandro Vintimilla wrote: > > Thanks, basically is a GPS that sends data to the server. It's for a fit > traker. > > What is the best way to put into producción this server? There are probably few important things to consider: 1. use encryption (

Re: [go-nuts] What dependency management tool do you use?

I don't really know much about the other tools but afaik the difference is more in the fact that Gb is more similar to other build systems in other languages. It focuses on making the current thing you are working on easy and simple to build rather than being a tool to work around the strangeness t

Re: [go-nuts] What dependency management tool do you use?

On 16/07/16 11:44, Florin Pățan wrote: > I appreciate you like gb, it's an interesting tool, but you cannot > explain why it's different compared to other solutions when it comes to > those two particular problems mentioned by you so I'd kindly suggest > reading more about it. You are way too emo

[go-nuts] [ANN] goimports-update-ignore makes goimports faster, maintains .goimportsignore

With , goimports now supports a mechanism for ignoring non-go-code directories. For cluttered source directories, this makes goimports quite a lot faster. The problem is, if you want to get the most benefit of this you may need to make and maintain a big

[go-nuts] Re: why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

Hallöchen! Jan Mercl writes: > On Sat, Jul 16, 2016 at 10:39 AM T L wrote: > >> I know this result, but I just need the reason, not the result. > > The method set distinction of T vs *T allows to forbid calling > methods intended to mutate the receiver (ie. receiver is *T) on > the wrong receive

Re: [go-nuts] What dependency management tool do you use?

On Saturday, July 16, 2016 at 11:34:12 AM UTC+1, Mauro Toffanin wrote: > > On 16/07/16 11:44, Florin Pățan wrote: > > I appreciate you like gb, it's an interesting tool, but you cannot > > explain why it's different compared to other solutions when it comes to > > those two particular problems

Re: [go-nuts] What dependency management tool do you use?

For repeatable builds there are many ways and tools that work fine, Gb is not unique in this respect. I don't get why this should be a controversial topic however. It seems to be an issue only in the go community. In all the other languages (newer more modern anyway) it is considered a solved prob

Re: [go-nuts] Re: why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

On Sat, Jul 16, 2016 at 1:51 PM Torsten Bronger < bron...@physik.rwth-aachen.de> wrote: > There still is a subtle asymmetry: a.b() is implicitly converted to (&a).b() if necessary. Why isn't f(v) implicitly converted to f(&v) if necessary? Go does not do implicit conversions of types of run time

Re: [go-nuts] What dependency management tool do you use?

On 2016-07-16 11:22, Mauro Toffanin wrote: On 16/07/16 01:43, Florin Pățan wrote: I feel this is a controversial statement. Godep can do this just as well, in fact any vendoring tool can do this, as long as you commit your dependencies. That is not true. Dave Cheney explained it very well at

Re: [go-nuts] why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

On Saturday, 16 July 2016 05:31:41 UTC-4, Jan Mercl wrote: > > On Sat, Jul 16, 2016 at 10:39 AM T L > > wrote: > > > I know this result, but I just need the reason, not the result. > > The method set distinction of T vs *T allows to forbid calling methods > intended to mutate the receiver (ie. re

Re: [go-nuts] why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

On Saturday, July 16, 2016 at 10:13:51 PM UTC+8, adon...@google.com wrote: > > On Saturday, 16 July 2016 05:31:41 UTC-4, Jan Mercl wrote: >> >> On Sat, Jul 16, 2016 at 10:39 AM T L wrote: >> >> > I know this result, but I just need the reason, not the result. >> >> The method set distinction of

Re: [go-nuts] What dependency management tool do you use?

On 16/07/16 13:51, Florin Pățan wrote: > Thank you for bringing up my condition, I'll make sure I treat it, it > sounds like something dangerous (nice insult by the way). This is ridiculous. Now you're even making things up: the DKE is not a mental/health condition or a disease, but it's just a sp

[go-nuts] Re: why the method set of *T is the superset of the method of T even if values of both *T and T can call both methods of *T and T?

This is a syntatic sugar: v.Func() on non-pointer receiver is equivalent to (&v).Func() суббота, 16 июля 2016 г., 10:42:22 UTC+3 пользователь T L написал: > > is there any logic here? Or just a hard rule? > -- You received this message because you are subscribed to the Google Groups "golang-nu

[go-nuts] [ANN] UniDoc PDF Toolkit for golang

Hi all. Today we are releasing UniDoc version 1.0, a comprehensive open source PDF toolkit written in Go. Please see our release post http://unidoc.io/news/launching-unidoc. We have big plans for this library documented on our website. The current feature set is: - Merge PDF - Split PDF - P

[go-nuts] Linking C dynamic library non-standard location

Hi, Can anyone tell me what I'm doing wrong when building a go program that uses the ImageMagick library that has been installed to a non-standard location. What I think I'm seeing is that the program builds, but a flag telling the program to look in the non-standard location for the dynamic

[go-nuts] Re: [ANN] UniDoc PDF Toolkit for golang

I would recommend you clarify your public / commercial licensing and make it more prominent in advertising and home page. I would also note that AGPL is probably unusable in most Go programs (statically linked and all). -Daniel On Saturday, July 16, 2016 at 8:22:00 AM UTC-7, ah...@owlglobal.io

Re: [go-nuts] What dependency management tool do you use?

On 16/07/16 15:16, Peter Mogensen wrote: > * Use gvt for vendoring everything into /vendor You would be surprised to know that gvt uses gb internally, and both the projects exchange pieces of code and ideas ;) > But wrt. to the talk above: Didn't Dave Cheney dismiss the diamond > problem a littl

[go-nuts] Did you try 1.7RC1 ?

1.7 is a significant improvement over previous versions, not only feature wise, but performance wise. In my current job, for a batch processing task, I coded two versions of the same program, one in Go and other in C++, both single threaded. I tried hard to use the same algorithm and data str

[go-nuts] Re: OS X Installer: Why modify $PATH instead of adding symbolic links to /usr/local/bin?

> > Can someone please explain the thinking behind this design decision? Is it > more common on Linux to have a lot of path additions instead of symbolic > links to executables? Was this something that was discussed and decided > upon by the core team or just an arbitrary decision? > I'd love

RE: [go-nuts] What dependency management tool do you use?

> You would be surprised to know that gvt uses gb internally, > and both the projects exchange pieces of code and ideas ;) That's not the impression I get. I might be wrong, but I believe that gvt does not share most of gb's philosophy: 1) It is based on just gb-vendor, not the rest of gb.

Re: [go-nuts] Re: OS X Installer: Why modify $PATH instead of adding symbolic links to /usr/local/bin?

If it isn't the right way of doing things, it might be something we can change (for 1.8, probably). What's an installer meant to do if there's an existing binary or symlink at that location? On Jul 16, 2016 9:41 AM, "Dmitri Shuralyov" wrote: Can someone please explain the thinking behind this de

Re: [go-nuts] Re: OS X Installer: Why modify $PATH instead of adding symbolic links to /usr/local/bin?

> > I'd love to get a better understanding of why this choice. I have never > seen another software take this approach. As I mentioned before, I'm not familiar with the original thinking, but here are some ideas on the advantages of this approach that I can see: 1. it avoids symlinks (I don't

[go-nuts] Re: goimports has been updated

> > hey brad, is it possible to have a ```goimports version``` so that we know > what versions we currently have? I suggest using the command: go get -u -v golang.org/x/tools/cmd/goimports The -v flag will print packages that are rebuilt. If the output is empty, that means you already had th

RE: [go-nuts] What dependency management tool do you use?

> Gb puts emphasis on reliable and reproducible builds; none of the other package managers have such feature, ... None? Isn't that the main purpose of a package manager. I see many which seem to do this in addition to gb, for example: godep, glide, govendor, and gvt. Perhaps you weren’t awar

Re: [go-nuts] Linking C dynamic library non-standard location

On Sat, Jul 16, 2016 at 6:20 AM, wrote: > > Can anyone tell me what I'm doing wrong when building a go program that uses > the ImageMagick library that has been installed to a non-standard location. > > What I think I'm seeing is that the program builds, but a flag telling the > program to look i

Re: [go-nuts] What dependency management tool do you use?

On Sat, Jul 16, 2016 at 5:29 AM, Henrik Johansson wrote: > For repeatable builds there are many ways and tools that work fine, Gb is > not unique in this respect. > > I don't get why this should be a controversial topic however. It seems to be > an issue only in the go community. > In all the othe

Re: [go-nuts] What dependency management tool do you use?

On 16/07/16 18:43, John Souvestre wrote: > [...] I might be wrong, but I believe that gvt > does not share most of gb's philosophy: Actually, I didn't write that gvt shares any of Gb's philosophies in the first place. I wrote that the two PM shares SOME ideas and pieces of code. Nothing else. >

Re: [go-nuts] How likely is a data race to allow arbitrary code execution?

On Fri, 2016-07-15 at 22:19 -0700, Ian Lance Taylor wrote: > On Fri, Jul 15, 2016 at 9:21 PM,   wrote: > > > > I know that in Go a data race is undefined behavior. > > > > How likely is the undefined behavior likely to result in an > > exploitable > > security bug, where "exploitable" means more

Re: [go-nuts] Linking C dynamic library non-standard location

Hi Ian, On Saturday, 16 July 2016 18:08:59 UTC+1, Ian Lance Taylor wrote: > My guess is that you need to either pass -R /temp/imagemagick-temp/lib > to the linker, which you can do by setting CGO_LDFLAGS, > I get the same result when using CGO_CFLAGS and CGO_LDFLAGS rather than pkg-config. B

Re: [go-nuts] Linking C dynamic library non-standard location

On Sat, Jul 16, 2016 at 11:40 AM, wrote: > > On Saturday, 16 July 2016 18:08:59 UTC+1, Ian Lance Taylor wrote: > >> >> My guess is that you need to either pass -R /temp/imagemagick-temp/lib >> to the linker, which you can do by setting CGO_LDFLAGS, > > > I get the same result when using CGO_CFLAG

Re: [go-nuts] How likely is a data race to allow arbitrary code execution?

On Sat, Jul 16, 2016 at 11:36 AM, Demi Obenour wrote: > > One more question: is racing on a map likely to crash due to out-of- > bounds reads, as opposed to out-of-bounds writes? Either is possible. I don't see a reason why one would be more probably than the other. Ian -- You received this m

[go-nuts] How can I convert ASCII to HEX?

I want to convert ascii character to hex -- 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 https:/

[go-nuts] Re: Did you try 1.7RC1 ?

It is better to compare Go to C's performance, not to C++: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees c++ ((Ubuntu 5.3.1-14ubuntu2.1) 5.3.1 20160413): real 0m3.092s user 0m2.772s sys 0m0.316s c ((Ubuntu 5.3.1-14ubuntu2.1) 5.3.1 20160413): real 0m2.048s user 0m5.

Re: [go-nuts] How likely is a data race to allow arbitrary code execution?

On Sat, 2016-07-16 at 12:06 -0700, Ian Lance Taylor wrote: > On Sat, Jul 16, 2016 at 11:36 AM, Demi Obenour > wrote: > > > > > > One more question: is racing on a map likely to crash due to out- > > of- > > bounds reads, as opposed to out-of-bounds writes? > > Either is possible.  I don't see a

Re: [go-nuts] How likely is a data race to allow arbitrary code execution?

On Jul 16, 2016 12:35 PM, "Demi Obenour" wrote: > > On Sat, 2016-07-16 at 12:06 -0700, Ian Lance Taylor wrote: > > On Sat, Jul 16, 2016 at 11:36 AM, Demi Obenour > > wrote: > > > > > > > > > One more question: is racing on a map likely to crash due to out- > > > of- > > > bounds reads, as opposed

Re: [go-nuts] How can I convert ASCII to HEX?

Lots of ways... https://play.golang.org/p/D54ZRdLX_A On Sat, Jul 16, 2016 at 8:14 PM, EdgarAlejandro Vintimilla < eavi...@gmail.com> wrote: > I want to convert ascii character to hex > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To uns

[go-nuts] Re: Did you try 1.7RC1 ?

Why is that? -- 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 https://groups.google.com/d/optout.

[go-nuts] why treat int and []int differently here?

> package main > > func fi(i int) {} > func fis(is []int) {} > > type TI int > type TIS []int > > func main() { > var ti TI > fi(ti) // cannot use ti (type TI) as type int in argument to fi > > var tis TIS > fis(tis) // no problems! > } > > -- You received this message bec

Re: [go-nuts] What dependency management tool do you use?

On 2016-07-16 17:59, Mauro Toffanin wrote: But wrt. to the talk above: Didn't Dave Cheney dismiss the diamond problem a little too fast? Sure you "cannot" do that, but you can still end up in a situation where you depend on 2 different libraries, each which depends on different specific version

Re: [go-nuts] Linking C dynamic library non-standard location

Hi Ian, On Saturday, 16 July 2016 20:05:26 UTC+1, Ian Lance Taylor wrote: > > > I'm suggesting that you need an additional option: -R > /temp/imagemagick-temp/lib. You need to set the runtime library > search path to point to the right directory. > > Thanks Ian, The command: go build -ldfla

Re: [go-nuts] why treat int and []int differently here?

You've run into the distinction between named types and unnamed types: https://golang.org/ref/spec#Properties_of_types_and_values int, TI, and TIS are named types. []int is an unnamed type. The rules for assignability say: > A value x is assignable to a variable of type T ("x is assignable to T")

Re: [go-nuts] why treat int and []int differently here?

This is actually a really good question. To the spec-mobile! https://golang.org/ref/spec#Calls Except for one special case, arguments must be single-valued expressions > assignable to the parameter types of F and are evaluated before the > function is called. Okay, so the arguments must be assi

Re: [go-nuts] why treat int and []int differently here?

I had written a response, but was beaten to the punch by Steven and Alex by seconds. I'll just add to what they've said. A surprising fact is that `int` is actually not an unnamed type, it's a pre-declared identifier: https://golang.org/ref/spec#Predeclared_identifiers Here's the (seemingly taut

Re: [go-nuts] What dependency management tool do you use?

Well they have issues too of course. The most recent left-pad debacle is most striking. In general they do have support for versions all of them. Not all are SemVer, the older seems more fluid on the interpretation of what is a valid version but they have it. There are often many or at least a cou

Re: [go-nuts] Linking C dynamic library non-standard location

On Sat, Jul 16, 2016 at 02:10:38PM -0700, dan...@basereality.com wrote: > Do you know if it's possible to set this option in an environment variable, > so that it isn't needed to be passed on each command line operation? Ian mentioned another way to achieve your goal: add the directory to the lis

Re: [go-nuts] Linking C dynamic library non-standard location

On Jul 16, 2016 2:10 PM, wrote: > > Hi Ian, > > On Saturday, 16 July 2016 20:05:26 UTC+1, Ian Lance Taylor wrote: >> >> >> I'm suggesting that you need an additional option: -R >> /temp/imagemagick-temp/lib. You need to set the runtime library >> search path to point to the right directory. >> >

Re: [go-nuts] What dependency management tool do you use?

FWIW, go build in versions >= 1.6* is basically equivalent to what GB buys us just with a different structure for the vendor directory (i.e /vendor vs /vendor/src in GB). The gb-vendor plugin is a jewel in its simplicity and makes fetching/managing vendored packages very easy, which is what I love

[go-nuts] Re: why treat int and []int differently here?

`type` is not `typedef` in Go. `type` introduces completely new type. Fortunately, Go can cast these types to base type silently, i.e. explicict cast int(valueOfTI) is unnecessary. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

[go-nuts] [ANN] Nexer 1.1.1 code name: Billy

Hi all! I'm happy to announce a new release of nexer, available in github. https://github.com/diegohce/nexer/releases/latest What's new?: - Added new tunnel *apt-experimental* to apt service (debian packages system) hoping to be faster and more reliable than the plain *apt* tunnel See

[go-nuts] TLSUnique in tls.ConnectionState

Hello, I noticed the TLSUnique field of tls.ConnectionState. https://golang.org/pkg/crypto/tls/#ConnectionState I tried to read RFC 5056 and 5929 but I still do not understand its purpose. What exactly does it accomplish? Why would we want to use it? -- You received this message because you

[go-nuts] Re: log: why print prefix before the timestamp?

I agree with Jacek and Matt. Write an own logger? Isn't log package purpose NOT to write just another logger library? On Tuesday, June 17, 2014 at 6:24:21 PM UTC-3, Jacek Masiulaniec wrote: > > Hi Nuts, > > The below code: > > log.SetPrefix("debug: ") > log.Print("foo bar ...") > > produces

Re: [go-nuts] What dependency management tool do you use?

Really? Does it flatten dependencies or will I still have potentially more than one context package for example? On Sun, Jul 17, 2016, 00:11 William Madison wrote: > FWIW, go build in versions >= 1.6* is basically equivalent to what GB buys > us just with a different structure for the vendor dir

Re: [go-nuts] Re: why treat int and []int differently here?

On Sat, 2016-07-16 at 15:36 -0700, pi wrote: > `type` is not `typedef` in Go. `type` introduces completely new type. > Fortunately, Go can cast these types to base type silently, i.e. > explicict > cast int(valueOfTI) is unnecessary. This is not true; a named concrete type is never silently conv

Re: [go-nuts] Re: why treat int and []int differently here?

On Sun, Jul 17, 2016 at 1:52 AM, Dan Kortschak < dan.kortsc...@adelaide.edu.au> wrote: > On Sat, 2016-07-16 at 15:36 -0700, pi wrote: > > `type` is not `typedef` in Go. `type` introduces completely new type. > > Fortunately, Go can cast these types to base type silently, i.e. > > explicict > > cas

Re: [go-nuts] Re: why treat int and []int differently here?

Sorry my bad. Forget to add "in many cases" to last sentence. https://play.golang.org/p/7MtoscXiFo воскресенье, 17 июля 2016 г., 2:53:15 UTC+3 пользователь kortschak написал: > > On Sat, 2016-07-16 at 15:36 -0700, pi wrote: > > `type` is not `typedef` in Go. `type` introduces completely new type

Re: [go-nuts] Re: why treat int and []int differently here?

In that code, there is no silent conversion. In AddOne, the constant 1 is inferred to be of type Int (not int), and so you're just adding Int to Int to get another Int. On Sat, Jul 16, 2016 at 5:35 PM pi wrote: > Sorry my bad. Forget to add "in many cases" to last sentence. > https://play.golang

[go-nuts] Re: How do I load a x509 certificate?

Hello, this is 2016 and I am walking on this path now.. In the rootCA function and elsewhere, you have this line: derBytes, err := x509.CreateCertificate(rand.Reader, &rcat, &rcat, &rpriv.PublicKey, rpriv) However, the last two parameters to this function, according to the golang refs (https:/

[go-nuts] Re: goimports has been updated

I just noticed that import paths that start with an uppercase letter don't get imported automatically after the update. Looking at the code and https://github.com/golang/tools/blob/master/imports/fix.go#L651, I tried to change the behavior, using strings.ToLower on `lastTwoComponents` like: f

Re: [go-nuts] Re: goimports has been updated

Please file a bug. I lose emails. On Sat, Jul 16, 2016 at 1:29 PM, Vince Prignano wrote: > I just noticed that import paths that start with an uppercase letter don't > get imported automatically after the update. > > Looking at the code and > https://github.com/golang/tools/blob/master/imports/

[go-nuts] Re: why treat int and []int differently here?

@all, thanks for the explanation! Golang is a simple language full of details. On Sunday, July 17, 2016 at 4:15:12 AM UTC+8, T L wrote: > > > package main >> >> func fi(i int) {} >> func fis(is []int) {} >> >> type TI int >> type TIS []int >> >> func main() { >> var ti TI >> fi(ti) // can

Re: [go-nuts] Re: why treat int and []int differently here?

> @all, thanks for the explanation! in my view, all the "details" come from reasoning about Go through the sieve of other programming languages. nothing wrong in doing that, as long as the original intention is understood. for me, Go will always be looked through the sieve of C, in particular the