Re: [go-nuts] Re: Go one-line installer

Thanks. On Tue, 2017-08-01 at 19:14 -0700, Steve Francia wrote: > > On Tuesday, August 1, 2017 at 7:49:32 PM UTC-4, Florin Pățan wrote: > > > > > > Hi, > > > > The idea is good but: > > - it needs to modify the path to add GOROOT/bin and GOPATH/bin to > > it > > > It does. If it didn't do

Re: [go-nuts] Twitter search go code

On Wednesday, July 26, 2017 at 2:07:30 PM UTC-4, Shawn Milochik wrote: > > On Wed, Jul 26, 2017 at 11:47 AM, Tong Sun wrote: > >> Any simple go code out there that can search Twitter? Thx. >> > > With a question this broad, you'd get much better and faster results by > using Google. > Funny

[go-nuts] Re: Go one-line installer

Please file an issue with this information and as much details as you can. On Tuesday, August 1, 2017 at 5:38:24 PM UTC-4, Val wrote: > > Hello Steve, that looks very promising, thank you so much! > > I just tried on GCE, here is a gist >

[go-nuts] Re: Go one-line installer

On Tuesday, August 1, 2017 at 7:49:32 PM UTC-4, Florin Pățan wrote: > > Hi, > > The idea is good but: > - it needs to modify the path to add GOROOT/bin and GOPATH/bin to it > It does. If it didn't do this you've found a bug. Please report it. > - it should allow for multiple versions of Go to

[go-nuts] Re: [ANN] Gokoban - 3D Puzzle Game written in Go!

Cool~ I am learning 3D graphic as beginner! BR fino 在 2017年8月1日星期二 UTC+8上午10:23:22，Daniel Salvadori写道： > > Hi everyone, > > I made an open-source 3D puzzle game with Go. It's called Gokoban > ! > You control the Go gopher, and your objective in each level

Re: [go-nuts] Go one-line installer

> I was quite happy that the era of executable "installers" died once we > got package managers. This seems to come from a purely Linux perspective. I suspect that people who use Linux are quite a bit less likely to benefit from this solution anyway, because most Linux users are used to setting

Re: [go-nuts] Need to call Process.Wait() before testing if the child process is exited

On Tue, Aug 1, 2017 at 5:03 PM, yihao yang wrote: > err := syscall.Kill(int(dmInfo.Pid), syscall.Signal(0)) > if err == syscall.ESRCH { > Warning("Daemon stopped for unknown reason. BinaryId:", binaryId) > } else { >

Re: [go-nuts] Re: Generics are overrated.

On Tue, 2017-08-01 at 09:21 +0200, Sebastien Binet wrote: > the other place I had (very recently) felt they could have been > useful: >  - having a mat.Dense of math/big.Rat (in lieu of a mat.Dense of > float64) I think that would be very hard. The reasons behind this claim are that there is lot

[go-nuts] Need to call Process.Wait() before testing if the child process is exited

err := syscall.Kill(int(dmInfo.Pid), syscall.Signal(0)) if err == syscall.ESRCH { Warning("Daemon stopped for unknown reason. BinaryId:", binaryId) } else { if err != nil { Info("Daemon got error when signal-ed by 0. err:(",

[go-nuts] Go one-line installer

Hi, The idea is good but: - it needs to modify the path to add GOROOT/bin and GOPATH/bin to it - it should allow for multiple versions of Go to be installed simultaneously (including 1.x.y vs 1.x.z versions) - it should change the PATH on all three OSes regardless of the shell used, which is

Re: [go-nuts] Language muration (was: No Allman-Style, No go)

On Tuesday, August 1, 2017 at 10:18:21 AM UTC+1, Russel Winder wrote Once a programming language goes into production and invokes "backward compatibility" it rarely improves by evolution. cf. Fortran, Java. In principle, a language can improve, if the replacement is - distinguishable

[go-nuts] Re: Go one-line installer

Hello Steve, that looks very promising, thank you so much! I just tried on GCE, here is a gist . Possible quirk : $ go version go: cannot find GOROOT directory: /usr/local/go $ go doc fmt go: cannot find GOROOT directory:

[go-nuts] Re: GO Vs D

> > But from my personal experience, D is *at least* as easy to learn than Go, > if not easier. I seriously doubt, no offense. Go is so small and so intuitive, one can argue that there are people out there who knows most of the Go unknowingly :) Just the fact that it doesn't break much

[go-nuts] Re: GO Vs D

Indeed a language that offer much less tools is much easier to learn, and also to master. But from my personal experience, D is *at least* as easy to learn than Go, if not easier. Just the fact that it doesn't break much with the familiar syntax of C#, Java, C++, etc helps a lot in making the

[go-nuts] Re: GO Vs D

I've written only what I know for sure, i.e. that Go is used a lot for server side applications. I didn't know it was also used a lot on the client side for mobile and desktop GUI applications, sorry for my ignorance. On Tuesday, August 1, 2017 at 1:54:45 PM UTC+1, Doğan Kurt wrote: > > But D

Re: [go-nuts] Go Styleguide

Thank you Chris, I will update the styleguide to reflect the correct naming. @rog: I think it doesn't hurt and provides context, especially when digging through code on GitHub. E.g. when having a package at pkg/some-folder you always need to know that there is a pkg folder. On Tuesday, 1

[go-nuts] Re: Experience using Go for a student projet

> suggests you should move the wg.Add(1) out of the Goroutine from here: [...] > to there Thanks, that's an actual bug. > * Do you happen to know about the context package? It seems like a lot of > the closedown can happen if you recast part of the system as contexts and > cancel those

[go-nuts] Go one-line installer

Greetings Gophers, I've been working on a "one line installer" for Go with Jess Frazelle and Chris Broadfoot and we think it's ready to share a bit more broadly. The installer is designed to both install Go as well as do the initial configuration of setting up the right environment variables

[go-nuts] Function Failure Reporting: Error or OK bool

An article about the different Go conventions of function failure reporting https://gist.github.com/posener/a303becac35835ad7bf5e15fe061893e Enjoy! :-) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] [ANN] aah web framework for Go, v0.7 Released

Website: https://aahframework.org Documentation: https://docs.aahframework.org Release Notes: v0.7 https://docs.aahframework.org/release-notes.html Please give it a try aah web framework and share your inputs. Your feedback is very valuable. Thanks. Cheers, Jeeva -- You received this message

Re: [go-nuts] Get a copy of reflect.Value's underlying value

On Tue, Aug 1, 2017 at 2:43 PM, roger peppe wrote: > On 1 August 2017 at 19:33, Josh Humphries wrote: > > On Tue, Aug 1, 2017 at 11:44 AM, roger peppe wrote: > >> > >> On 1 August 2017 at 13:57, Josh Humphries

Re: [go-nuts] Get a copy of reflect.Value's underlying value

On 1 August 2017 at 19:33, Josh Humphries wrote: > On Tue, Aug 1, 2017 at 11:44 AM, roger peppe wrote: >> >> On 1 August 2017 at 13:57, Josh Humphries wrote: >> > Although that solution creates a heap-allocated tmp for every

Re: [go-nuts] Get a copy of reflect.Value's underlying value

On Tue, Aug 1, 2017 at 11:44 AM, roger peppe wrote: > On 1 August 2017 at 13:57, Josh Humphries wrote: > > Although that solution creates a heap-allocated tmp for every element in > the > > slice. Using an interface, the value will be inlined instead

Re: [go-nuts] xml namespaces - encoding ok, decoding result not ok

The sample XML in your code doesn't appear to be valid - it doesn't actually define the namespace that the os namespace prefix refers to. I am fully aware that encoding/xml has bugs, but I'm not sure that this is one of them. On 1 August 2017 at 18:48, Marcin Jurczuk wrote:

Re: [go-nuts] xml namespaces - encoding ok, decoding result not ok

Your example is returning xml that is wrong from system I'm talking to. My SOAP service requires tags in few different namespaces. My code returns: * * Your code returns: ** etc. Such syntax is not ok. My Service is returning error. With my syntax - I'm getting responses. Of course

Re: [go-nuts] Go Styleguide

Ah yes, my fault, I didn't look at the style guide before replying - I assumed the nomenclature used by Chris. As for canonical import path comments, I have mixed feelings. They are useful because even if a repository exists in your filesystem, it may contain imports that are intended are

Re: [go-nuts] Go Styleguide

This discussion points out another nomenclature problem in the list. What the list refers to as a "Package comment" is actually a "Canonical import path" comment. See https://golang.org/doc/go1.4#canonicalimports Package comments (as defined in this blog post:

Re: [go-nuts] xml namespaces - encoding ok, decoding result not ok

Namespaces are space-separated from tag names in the struct tags. Changing that seems to make your example work OK: https://play.golang.org/p/GBvhcWLew_ >From the encoding/xml docs: If the XMLName field has an associated tag of the form "name" or "namespace-URL name", the XML element

Re: [go-nuts] Go Styleguide

I think it's cost without much benefit. By definition, if a package exists on your filesystem, you know where it came from: you put it there, and you can inspect the path. On Tue, Aug 1, 2017 at 7:19 PM, roger peppe wrote: > On 1 August 2017 at 18:04, Peter Bourgon

Re: [go-nuts] Go Styleguide

On 1 August 2017 at 18:04, Peter Bourgon wrote: > Generally nice list. I find these items controversial i.e. shorthand > for I don't agree with them ;) [...] > - Use package comment This puzzles me. Why don't you think that having a package comment is a good idea? rog. --

Re: [go-nuts] Go Styleguide

Generally nice list. I find these items controversial i.e. shorthand for I don't agree with them ;) - Use assert-libraries - Don't under-package - Use package comment On Mon, Jul 31, 2017 at 1:39 PM, wrote: > Hey, I just released a Go Styleguide, please let me know what you

Re: [go-nuts] Re: No Allman-Style, No go!

D being rather unpopular (#23 at the TIOBE index of July 2017) at the moment compared to Google's Go, which is impressively climbing the charts at high speed, then I think we shouldn't worry too much about D's decline... ;) On Tuesday, August 1, 2017 at 10:18:21 AM UTC+1, Russel Winder wrote:

Re: [go-nuts] Get a copy of reflect.Value's underlying value

On 1 August 2017 at 13:57, Josh Humphries wrote: > Although that solution creates a heap-allocated tmp for every element in the > slice. Using an interface, the value will be inlined instead of > heap-allocated if it fits without boxing (so most primitive types and >

[go-nuts] Re: Go Styleguide

You're right, decorator pattern would wrap around. Will update, thank you! On Tuesday, 1 August 2017 16:25:59 UTC+2, Chris Hines wrote: > > The code shown for "User decorator pattern" is more properly known as the > "Functional options" pattern. I think this talk demonstrates the decorator >

[go-nuts] xml namespaces - encoding ok, decoding result not ok

Hi gophers, I stuck with something that supposed to be easy - XML decoding. Encoding works perfeclty. I'm trying for past two days to find working code for parsing SOAP message. I have structures that are encoded correctly but decoding responses (same structure, just filled with values) is

[go-nuts] Re: Go Styleguide

The code shown for "User decorator pattern" is more properly known as the "Functional options" pattern. I think this talk demonstrates the decorator pattern more correctly: https://www.youtube.com/watch?v=xyDkyFjzFVc On Monday, July 31, 2017 at 12:15:18 PM UTC-4, ha...@arne.me wrote: > > Hey, I

Re: [go-nuts] Re: GO Vs D

On Tue, Aug 01, 2017 at 05:04:24AM -0700, ecstatic.co...@gmail.com wrote: [...] > Go, as a web-centric language, has [...] Mildly put, this is a bold but unfounded statement. Web development is indeed booming, but it's booming on most contemporary programming languages -- be them PHP, Python,

Re: [go-nuts] Get a copy of reflect.Value's underlying value

On Tue, Aug 1, 2017 at 2:58 PM Josh Humphries wrote: > Using an interface, the value will be inlined instead of heap-allocated if it fits without boxing (so most primitive types and pointer types won't need heap allocation). This was true some years ago, but it is no

Re: [go-nuts] Get a copy of reflect.Value's underlying value

Although that solution creates a heap-allocated tmp for every element in the slice. Using an interface, the value will be inlined instead of heap-allocated if it fits without boxing (so most primitive types and pointer types won't need heap allocation). *Josh Humphries* jh...@bluegosling.com

[go-nuts] Re: "fallthrough statement out of place" in `if` block inside `swicth` block

i believe you should avoid fallthrough statement except for auto-generated code. it's obscure what you are trying to accomplish with that piece of code, but surely you can do it in a better way. On Tuesday, August 1, 2017 at 2:35:00 PM UTC+2, Fumi Takeuchi wrote: > > Example code:

[go-nuts] Re: GO Vs D

> > But D also gives you reference classes, genericity, function polymorphism, > conditional compilation, design by contract assertions, compile-time meta > programming, and many other features that are severely lacking in Go. > That's the biggest reason i love Go, *except maybe ken thompson

Re: [go-nuts] "fallthrough statement out of place" in `if` block inside `swicth` block

On Tue, Aug 1, 2017 at 2:34 PM Fumi Takeuchi wrote: > Example code: https://play.golang.org/p/dVtPVt3oKt > > Maybe `fallthrough` statement cannot be used in `if` block even if it's put inside `swicth` block) True: It may be used only as the final non-empty statement in

[go-nuts] Re: Go Styleguide

great work ! 在 2017年8月1日星期二 UTC+8上午12:15:18，ha...@arne.me写道： > > Hey, I just released a Go Styleguide > , please let me know what you > think! > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] "fallthrough statement out of place" in `if` block inside `swicth` block

Example code: https://play.golang.org/p/dVtPVt3oKt --- I thought this code will work fine, but didn't, because of "fallthrough statement out of place" error. Maybe `fallthrough` statement cannot be used in `if` block even if it's put inside `swicth` block) So, my question is, which is better

[go-nuts] Re: GO Vs D

I come back to this forum I read a long time ago, because after having used Go for several projects, I've recently switched to D, and I wanted to share my opinion on it. First, if I can make a caricatural comparison, i'd like to say that to me, Go is just a "much better C", while D is instead

Re: [go-nuts] Get a copy of reflect.Value's underlying value

FWIW, you don't have to use Interface to do the swap: https://play.golang.org/p/O8lGJGGOXP On 31 July 2017 at 15:18, eZio Pan wrote: > Hello, > I want to build a "universal slice reverser" with reflect.MakeFunc. But I > don't know how to get a copy of reflect.Value's

Re: [go-nuts] Go Styleguide

I now had time to review your points extensively: - I agree about the non-stdlib packages and removed direct mention of them while still using them for examples to give a starting point. - Re under-package: I added a comment to clarify to split packages if you're unsure. - The Makefile section

Re: [go-nuts] Re: No Allman-Style, No go!

On Mon, 2017-07-31 at 12:21 -0500, John McKown wrote: > […] > An excellent approach to all languages. If someone doesn't like "go", > then use a different language. Or be like some people and invent your own > to address the perceived problems with all the other languages in existence. > Once a

[go-nuts] Re: Go Styleguide

Will do that, looks great. -- 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

Re: [go-nuts] Re: Generics are overrated.

On 31 July 2017 at 19:35, Tristan Colgate wrote: > > > On Mon, 31 Jul 2017, 18:21 roger peppe, wrote: >> >> >> > import hpaInformer informer >> > >> > myInformer := hpaInformer.New(sharedUnderlyingCacheThing) >> >> So... to me, the implementation of

Re: [go-nuts] Re: Generics are overrated.

On Tue, Aug 1, 2017 at 2:06 AM, Dan Kortschak wrote: > We use sets in the graph packages, but the number of set types is > pretty limited (sets of nodes and sets of either int or int64) and > map[T] works for that level of use. > > The only other place where it

Re: [go-nuts] Is x/exp/shiny dead?

This sounds great. So it is not entirely dead. On Tuesday, August 1, 2017 at 8:24:43 AM UTC+5, Daniel Skinner wrote: > > As one of the persons reached out to for that effort (and I'm not a shiny > contributor), my current unpublished work will eventually serve as a basis > for some proposals to

Re: [go-nuts] Is x/exp/shiny dead?

Thanks for the great work on exp/shiny. Where does shiny need most attention/contributions? I think a status report of some sort would help others pickup where it's left off now. On Tuesday, August 1, 2017 at 7:44:42 AM UTC+5, Nigel Tao wrote: > > On Tue, Aug 1, 2017 at 6:25 AM, fazal