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

[Dan Kortschak]

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 this you've found a bug. Please report it.
> 
> > 
> > - it should allow for multiple versions of Go to be installed 
> > simultaneously (including 1.x.y vs 1.x.z versions) 
> > 
> Out of scope for this tool, though it can do it with passing along
> flag 
> arguments
> 
> > 
> > - it should change the PATH on all three OSes regardless of the
> > shell 
> > used, which is the hardest part I guess (as this is the part that
> > trips 
> > over most of the people, along with the GOPATH requirement)
> > 
> There's no such thing. ENV variables are shell specific. The PATH is 
> defined in the shell initialization script on *nix. It literally
> tells the 
> shell what directories to look in. On Windows it does this as the
> PATH is 
> set by an OS call directly. Unfortunately bash on Windows ignores
> it.  
> 
> > 
> > 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Twitter search go code

[Tong Sun]

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 there are people out there showing off by saying that they can 
do Google search, as if no one else knows it but he. 

, so impatient, judgmental and condescending. 
If you had paid a little more attention, it is not at all so broad as you 
think. Now read it again -- 
The keywords are: "*simple*" and "*search*". 
The monster tool that emphasizes on *re-tweeting* does NOT qualify as the 
answer. Period. 

Luckily, with a bit more patient, I'm able to find a *simple* go code that 
*can* *search* Twitter --
https://github.com/cathalgarvey/sqrape/blob/master/examples/tweetgrab.go

Nice one!

Going along that direction, I think the cascadia 
 the command line tool is even more 
simpler, in a sense of less dependency and less/no Go coding: 

$ cascadia -i 
'https://twitter.com/search?q=%22Gas%20Price%20Alert%22%20%23GTA%20from%3AGasBuddyDan=typd'
 -o -c 'div.stream div.original-tweet div.content' --piece Time='small.time' 
--piece Tweet='div.js-tweet-text-container > p'
TimeTweet

  Jul 31
Gas Price Alert #Toronto #GTA #Hamilton #Ottawa #LdnOnt #Barrie 
#Kitchener #Niagara #Windsor N/C Tues and to a 2ct/l HIKE gor Wednesday

  Jul 6
Gas Price Alert #Toronto #GTA #LdnOnt #Hamilton #Ottawa #Barrie #KW to 
see a 1 ct/l drop @ for Friday July 7

  May 30
Gas Price Alert #Toronto #GTA #Ottawa #LdnOnt #Hamilton #KW #Barrie 
#Windsor prices won't change Wednesday but will DROP 1 ct/l Thursday

  May 15
Gas Price Alert #Toronto #GTA #Barrie #Hamilton #LdnOnt #Ottawa #KW 
#Windsor NO CHANGE @  except gas bar shenanigans for Tues & Wednesday

  Mar 7
Gas Price Alert #Toronto #GTHA #LdnOnt #Ottawa #Barrie #KW #Windsor to 
see a 1 cent a litre HIKE Wed March 8 (to 107.9 in the #GTA)



Check out the details 
at https://github.com/suntong/cascadia#twitter-search, which I updated just 
now. 



-- 
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] Re: Go one-line installer

[Steve Francia]

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 
> .
> Possible quirk :
> $ go version 
> go: cannot find GOROOT directory: /usr/local/go
> $ go doc fmt
> go: cannot find GOROOT directory: /usr/local/go
> $ go get github.com/gorilla/mux
> go: cannot find GOROOT directory: /usr/local/go
>
> Note that I didn't try to sudo anything.
>
> Questions:
> - is it recommanded to set the GOPATH variable, even since 17262 
>  and go 1.8 seem to regard 
> ~/go as a cromulent default?
> - might it be possible to avoid to extra step "One more thing! ... ... ... 
> or open a new shell prompt", by sourcing everything needed? Something like
> curl -LO https://get.golang.org/$(uname)/go_installer_script && source 
> go_installer_script
>

We can't source the binary, but we may be able to source the shell 
initialization file.  

>
> This one-liner project will bring all of us command-line users a 
> super-nice developer UX, especially when frequently installing Go to new 
> machines :)
> Cheers
> Valentin
>
> On Tuesday, August 1, 2017 at 9:42:00 PM UTC+2, Steve Francia wrote:
>>
>> 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 and paths.
>> It will install the Go distribution (tools & stdlib) to "/.go" inside 
>> your home directory by default.
>> It will setup "$HOME/go" as your GOPATH. 
>>
>> If Go is already installed *via this installer* it will upgrade it to 
>> the latest version of Go.
>>
>> Currently supported systems:
>>   linux, darwin, windows / amd64, 386 / bash, zsh, powershell
>>
>>
>> *Usage*
>> Windows Powershell:
>> (New-Object System.Net.WebClient).DownloadFile('
>> https://get.golang.org/installer.exe', 'installer.exe'); Start-Process 
>> -Wait -NonewWindow installer.exe; Remove-Item installer.exe
>>
>> Shell (Linux/macOS/Windows):
>> curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x 
>> go_installer && ./go_installer && rm go_installer
>>
>>
>> As we discovered developing this, installers are really all edge cases. 
>> We're certain we've not found many of them. 
>> *Our goal is that this becomes the primary mechanism to install Go. *
>> *To do that, we need your help testing, improving and fixing it. *
>>
>> The source can be found at 
>> https://go.googlesource.com/tools/+/master/cmd/getgo/
>> If you find any issues please report them on Github 
>> https://github.com/golang/go/issues/new?title=tools/cmd/getgo:
>>
>> Thanks,
>> Steve
>>
>

-- 
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] Re: Go one-line installer

[Steve Francia]

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 be installed 
> simultaneously (including 1.x.y vs 1.x.z versions) 
>
Out of scope for this tool, though it can do it with passing along flag 
arguments

> - it should change the PATH on all three OSes regardless of the shell 
> used, which is the hardest part I guess (as this is the part that trips 
> over most of the people, along with the GOPATH requirement)
>
There's no such thing. ENV variables are shell specific. The PATH is 
defined in the shell initialization script on *nix. It literally tells the 
shell what directories to look in. On Windows it does this as the PATH is 
set by an OS call directly. Unfortunately bash on Windows ignores it.  

> 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Fino]

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 is to push 
> the boxes until they are all on top of the yellow pads.
> There are elevators that help you reach high places and move boxes up and 
> down.
> It was created using G3N  for the April-July 
> 2017 Gopher Game Jam .
>
>
> 
>
> Here's the Github repository: github.com/danaugrs/gokoban
>
> The last few levels can be quite challenging!
>
> I had a lot of fun writing it and getting my friends and family to play it.
> Let me know what you think!
>

-- 
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.

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

[Tyler Compton]

> 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 environment variables
and installing from tarballs. The era of executable installers has not died
on Windows or on Mac.

> If something is to be improved, perhaps the
> quality of packages for various distributions could be improved
> instead. That is what the users want anyway, to use their distro
> package manager.

Trying to improve every distro's Go version is a substantially more
difficult problem, and even worse, it's a bureaucratic one. I think it
would be a lot more productive to spend that time working on the technical
problem of security than giving up and tackling a much harder one.

On Tue, Aug 1, 2017 at 4:49 PM 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 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 the hardest part I guess (as this is the part that trips
> over most of the people, along with the GOPATH requirement)
>
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

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

[Ian Lance Taylor]

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 {
>   if err != nil {
> Info("Daemon got error when signal-ed by 0. err:(", err.Error(),
> ") BinaryId:", binaryId)
>   }
>  }
>
> Hi,
>
> I have a code snippet background. It will check if a given process is
> exited. But based on my test, the first line syscall.Kill will always return
> nil even if the child process is already done (e.g. In the test, I ran an
> 'echo' command first and sleep for a long time before calling the code
> snippet above).
> I use cmd.Start to start my child process.
> Anyone knows why?

That's how Unix works.  In between the time that a process exits and
the time that its parent calls wait, the process is a zombie (assuming
the parent process has not ignored SIGCHLD signals).   You can send a
signal to a zombie process, although nothing changes for the process
since it is no longer running.

Ian

-- 
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.

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

[Dan Kortschak]

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 of non-generic code behind the mat.Dense user-facing
implementation; we would need generic BLAS and generic LAPACK, with
appropriate testing.
Having said that, there is no reason not to implement a big.Rat-based
implementation of mat.Matrix for the methods that you need. It would
return reduced precision float64 values from the At method, but have a
RatAt method returning the exact value.

-- 
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] Need to call Process.Wait() before testing if the child process is exited

[yihao yang]

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:(", err.Error(),
") BinaryId:", binaryId)
  }
 }

Hi,

I have a code snippet background. It will check if a given process is 
exited. But based on my test, the first line syscall.Kill will always 
return nil even if the child process is already done (e.g. In the test, I 
ran an 'echo' command first and sleep for a long time before calling the 
code snippet above).
I use cmd.Start to start my child process.
Anyone knows why?

Thanks,
Yihao

 

-- 
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] Go one-line installer

[Florin Pățan]

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 the hardest part I guess (as this is the part that trips over most of 
the people, along with the GOPATH requirement)

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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Collier-Brown]

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 from it's predecessor, and
- there is a correctness-preserving transform.

When I was doing porting ("competitive migration"),
- we didn't have  sets of refactorings, which are defined as 
correctness-preserving, and
- we had a bit of a kludge for distinguishing dialects. The latter was 
"came from AIX 0.9, going to SunOS 5.2"


Now we have versioned dialects, and a class of useful refactorings, so 
some changes are possible.


Not trivial, but if they're mechanizable, hardness doesn't matter.

--dave

--
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] Re: Go one-line installer

[Val]

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: /usr/local/go
$ go get github.com/gorilla/mux
go: cannot find GOROOT directory: /usr/local/go

Note that I didn't try to sudo anything.

Questions:
- is it recommanded to set the GOPATH variable, even since 17262 
 and go 1.8 seem to regard ~/go 
as a cromulent default?
- might it be possible to avoid to extra step "One more thing! ... ... ... 
or open a new shell prompt", by sourcing everything needed? Something like
curl -LO https://get.golang.org/$(uname)/go_installer_script && source 
go_installer_script

This one-liner project will bring all of us command-line users a super-nice 
developer UX, especially when frequently installing Go to new machines :)
Cheers
Valentin

On Tuesday, August 1, 2017 at 9:42:00 PM UTC+2, Steve Francia wrote:
>
> 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 and paths.
> It will install the Go distribution (tools & stdlib) to "/.go" inside your 
> home directory by default.
> It will setup "$HOME/go" as your GOPATH. 
>
> If Go is already installed *via this installer* it will upgrade it to the 
> latest version of Go.
>
> Currently supported systems:
>   linux, darwin, windows / amd64, 386 / bash, zsh, powershell
>
>
> *Usage*
> Windows Powershell:
> (New-Object System.Net.WebClient).DownloadFile('
> https://get.golang.org/installer.exe', 'installer.exe'); Start-Process 
> -Wait -NonewWindow installer.exe; Remove-Item installer.exe
>
> Shell (Linux/macOS/Windows):
> curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x 
> go_installer && ./go_installer && rm go_installer
>
>
> As we discovered developing this, installers are really all edge cases. 
> We're certain we've not found many of them. 
> *Our goal is that this becomes the primary mechanism to install Go. *
> *To do that, we need your help testing, improving and fixing it. *
>
> The source can be found at 
> https://go.googlesource.com/tools/+/master/cmd/getgo/
> If you find any issues please report them on Github 
> https://github.com/golang/go/issues/new?title=tools/cmd/getgo:
>
> Thanks,
> Steve
>

-- 
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] Re: GO Vs D

[Doğan Kurt]

>
> 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 with the familiar syntax of C#, 
> Java, C++, etc helps a lot in making the transition.
>

Go's syntax is very familiar to C, i've never heard it was an issue. The 
only think you must get used to is declarations and i LOVE the Go way. I 
remember the days i was struggling with C's declaration model, the spiral 
rule etc. sure we use typedefs but it rather feels like a hack. 
I can write any declaration no matter how complex it is, with my eyes 
closed in Go. It's so great.

And genericity and polymorphism are invaluable tools when optimizing code 
> reuse without reducing execution speed.
>

I don't ever remember duplicating any code in C. I can't understand how 
people are unable to write reusable code with C, seriously.  Whenever i 
discuss this with a C++ programmer, they immediately share some generic Max 
function that works with int and double.  I admit i use macros in that 
case, but come on it's not even 1% of the serious programming you do in C. 

If you are a competent C programmer (structured programming in general), 
you know how to write reusable code. 

-- 
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] Re: GO Vs D

[ecstatic . coder]

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 transition.

And genericity and polymorphism are invaluable tools when optimizing code 
reuse without reducing execution speed.

I know that everything can be done with interfaces, but unfortunately they 
run slower (according to the Golang website) than direct calls to 
type-specific code, and most of the time even with interface you have to 
manually adapt the implementation anyway.

And copy/pasting then adapting manually the code is dumb and error proof. 
If you have always managed to avoid doing that for your Go applications, 
then I'm happy for you, this means you are much smarter than me.

On Tuesday, August 1, 2017 at 1:54:45 PM UTC+1, Doğan Kurt wrote:
>
> 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 :)*
>
>
> *- A language that doesn’t have everything is actually easier to program 
> in than some that do.  Dennis M. Ritchie*
>
>
> *- Do Less. Enable More. Russ Cox*
>

-- 
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] Re: GO Vs D

[ecstatic . coder]

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 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 :)*
>
>
> *- A language that doesn’t have everything is actually easier to program 
> in than some that do.  Dennis M. Ritchie*
>
>
> *- Do Less. Enable More. Russ Cox*
>

-- 
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.

Re: [go-nuts] Go Styleguide

[hallo]

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 August 2017 19:30:22 UTC+2, Chris Hines wrote:
>
> 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: 
> https://blog.golang.org/godoc-documenting-go-code) are for documenting a 
> package, not restricting where it can be imported from.
>
> On Tuesday, August 1, 2017 at 1:24:44 PM UTC-4, Peter Bourgon wrote:
>>
>> 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  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. 
>>
>

-- 
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] Re: Experience using Go for a student projet

[Juliusz Chroboczek]

> 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 explicitly.

I agree, the cancellation logic is a mess.  We'll see if we want to
rethink it

> * Idea: is it possible to construct a variant of the code where MCUpdates
> isn't even there. It looks as if it reads from a channel and fan-outs to a
> multicast group. But why isn't each connectionNode just running the fanout
> itself?

Yeah, that's what I referred to when I said that I had a lot of trouble
keeping the students from building an infrastructure.  They've been
brought up on Java, and taught that one must be modular and avoid copy-paste.

Thanks again,

-- Juliusz

-- 
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] Go one-line installer

[Steve Francia]

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 and paths.
It will install the Go distribution (tools & stdlib) to "/.go" inside your 
home directory by default.
It will setup "$HOME/go" as your GOPATH. 

If Go is already installed *via this installer* it will upgrade it to the 
latest version of Go.

Currently supported systems:
  linux, darwin, windows / amd64, 386 / bash, zsh, powershell


*Usage*
Windows Powershell:
(New-Object System.Net.WebClient).DownloadFile('
https://get.golang.org/installer.exe', 'installer.exe'); Start-Process 
-Wait -NonewWindow installer.exe; Remove-Item installer.exe

Shell (Linux/macOS/Windows):
curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x 
go_installer && ./go_installer && rm go_installer


As we discovered developing this, installers are really all edge cases. 
We're certain we've not found many of them. 
*Our goal is that this becomes the primary mechanism to install Go. *
*To do that, we need your help testing, improving and fixing it. *

The source can be found at 
https://go.googlesource.com/tools/+/master/cmd/getgo/
If you find any issues please report them on Github 
https://github.com/golang/go/issues/new?title=tools/cmd/getgo:

Thanks,
Steve

-- 
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] Function Failure Reporting: Error or OK bool

[Eyal Posener]

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 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] [ANN] aah web framework for Go, v0.7 Released

[Jeevanandam M.]

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 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.

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

[Josh Humphries]

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 
> 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
> >> > pointer types won't need heap allocation).
> >>
> >> As it happens, it's the other way round - the solution using Interface
> can
> >> make an allocation per element, but the solution using Value does not.
> >
> >
> > The solution using Value is calling reflect.New inside the loop. Why do
> you
> > say that it does not make an allocation per element?
>
> The code I posted doesn't call reflect.New inside the loop - perhaps
> you're looking at some different code? (for the record, I'm talking
> about line 45 of https://play.golang.org/p/Q0VHbfL7Ij)
>

Ah, I see. Thanks for the clarification. That makes sense to allocate just
one for the whole operation.


>
> > Also, I'm not sure I follow that using Interface makes an allocation per
> > element. My understanding is that the actual value can be stored in the
> > interface value if it is small enough (1 or 2 words?). So boxing
> primitives
> > and pointers should generally store the value in the interface tuple
> (which
> > itself is stack allocated) as opposed to allocating heap space for it and
> > storing a pointer.
>
> As I think was pointed out earlier in this thread, this has changed since
> Go 1. Only pointer values are stored in interface values now - non-pointer
> value (for example the ints in the example) will usually cause an
> allocation.
> There are some optimisations for some cases that avoid that: creation
> of an interface from a constant value, and creation of an interface from
> small numeric values.
>
>
Ugh. I did not realize that. I had not dug into it too much other than
reading a Go blog post and this article by Russ Cox
 (which suggest this memory
optimization is done).

I am guessing the conditional that decides between inline value vs.
pointer-chasing was too much runtime overhead?


> Try running the benchmark code that I posted. I think you'll find
> that the code that calls Interface is slower and allocates more,
> because it has to allocate a storage slot every time it creates
> an interface from an int, which the solution using Value does not,
> because it allocates the temporary only once for a given call to Reverse
> (even that could be amortised by using sync.Pool, but it's almost
> certainly not worth it).
>
>   cheers,
> rog.
>

-- 
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.

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

[roger peppe]

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 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).
>>
>> As it happens, it's the other way round - the solution using Interface can
>> make an allocation per element, but the solution using Value does not.
>
>
> The solution using Value is calling reflect.New inside the loop. Why do you
> say that it does not make an allocation per element?

The code I posted doesn't call reflect.New inside the loop - perhaps
you're looking at some different code? (for the record, I'm talking
about line 45 of https://play.golang.org/p/Q0VHbfL7Ij)

> Also, I'm not sure I follow that using Interface makes an allocation per
> element. My understanding is that the actual value can be stored in the
> interface value if it is small enough (1 or 2 words?). So boxing primitives
> and pointers should generally store the value in the interface tuple (which
> itself is stack allocated) as opposed to allocating heap space for it and
> storing a pointer.

As I think was pointed out earlier in this thread, this has changed since
Go 1. Only pointer values are stored in interface values now - non-pointer
value (for example the ints in the example) will usually cause an allocation.
There are some optimisations for some cases that avoid that: creation
of an interface from a constant value, and creation of an interface from
small numeric values.

Try running the benchmark code that I posted. I think you'll find
that the code that calls Interface is slower and allocates more,
because it has to allocate a storage slot every time it creates
an interface from an int, which the solution using Value does not,
because it allocates the temporary only once for a given call to Reverse
(even that could be amortised by using sync.Pool, but it's almost
certainly not worth it).

  cheers,
rog.

-- 
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.

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

[Josh Humphries]

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 of
> > heap-allocated if it fits without boxing (so most primitive types and
> > pointer types won't need heap allocation).
>
> As it happens, it's the other way round - the solution using Interface can
> make an allocation per element, but the solution using Value does not.
>

The solution using Value is calling reflect.New inside the loop. Why do you
say that it does not make an allocation per element?

Also, I'm not sure I follow that using Interface makes an allocation per
element. My understanding is that the actual value can be stored in the
interface value if it is small enough (1 or 2 words?). So boxing primitives
and pointers should generally store the value in the interface tuple (which
itself is stack allocated) as opposed to allocating heap space for it and
storing a pointer.

For larger types (e.g. structs beyond a certain size) it will indeed
allocate on the heap. I don't see any simple way around this. There may be
some clever tricks, possibly involving cgo or asm, to avoid it though
(maybe like how reflect.Swapper
 works, although it
also heap allocates for values >8 bytes).



>
> https://play.golang.org/p/Q0VHbfL7Ij
>
> Additionally, the solution using Interface can lose the type information
> in some cases and panic as a result.
>


A simple guard for the nil case is necessary to prevent the panic (since
the nil interface results in an invalid reflect.Value):

tmp := a.Interface()
var tmprv reflect.Value
if tmp == nil {
  tmprv = reflect.Zero(a.Type())
} else {
  tmprv = reflect.ValueOf(tmp)
}
a.Set(b)
b.Set(tmprv)


>
> https://play.golang.org/p/WocF9CaPoR
>
>   cheers,
> rog.
>
>
> >
> > 
> > Josh Humphries
> > jh...@bluegosling.com
> >
> > On Tue, Aug 1, 2017 at 7:29 AM, roger peppe  wrote:
> >>
> >> 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 underlying value,
> which
> >> > make
> >> > result not correct.
> >> >
> >> > Here is the code:
> >> >
> >> > package main
> >> >
> >> > import (
> >> > "fmt"
> >> > "reflect"
> >> > )
> >> >
> >> > func reverse(in []reflect.Value) (out []reflect.Value) {
> >> > inls := in[0]
> >> > inlslen := inls.Len()
> >> >
> >> > for i, j := 0, inlslen-1; i < j; i, j = i+1, j-1 {
> >> > a := inls.Index(i)
> >> > b := inls.Index(j)
> >> > // how to get underlying value of a and b ?
> >> > a.Set(b)
> >> > b.Set(a)
> >> > }
> >> > return in
> >> > }
> >> >
> >> > var intFlipper func([]int) []int
> >> >
> >> > func main() {
> >> > emptyFunc := reflect.ValueOf().Elem()
> >> > pseudoFunc := reflect.MakeFunc(emptyFunc.Type(), reverse)
> >> > emptyFunc.Set(pseudoFunc)
> >> > fmt.Printf("%v\n", intFlipper([]int{2, 3, 4, 5, 6, 7}))
> >> > }
> >> >
> >> > My code return [7 6 5 5 6 7], but excepting result is [7 6 5 4 3 2]
> >> >
> >> > --
> >> > 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.
> >>
> >> --
> >> 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.
> >
> >
>

-- 
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.

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

[roger peppe]

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:
> 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 os namespace is declared at the begining of file:
> http://schemas.xmlsoap.org/soap/envelope/;
> xmlns:os="os.xsd.v1">
>
>
> I looks like go have bug with Unmarshaling tags with namespaces. Bug exists
> at least 2 years, maybe more.
>
>
> W dniu wtorek, 1 sierpnia 2017 19:30:39 UTC+2 użytkownik rog napisał:
>>
>> 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 must have
>>the given name (and, optionally, name space) or else Unmarshal
>>returns an error.
>>
>>
>> On 1 August 2017 at 15:39, Marcin Jurczuk  wrote:
>> > 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 failing (sic!)
>> >
>> > Here is sample code that encodes struct and then tries decode the same
>> > struct
>> >
>> > https://play.golang.org/p/hE7vcXbymg
>> >
>> >
>> > It seems that Go have a lot of issues with XML jsut small portion:
>> > https://github.com/golang/go/issues/6800 (this one looks like my problem
>> > -
>> > not fixed since 2013 !)
>> > https://github.com/golang/go/issues/9775
>> > https://github.com/golang/go/issues/9519
>> >
>> >
>> > Please help me to diagnose is it my problem or one of Go bugs
>> >
>> >
>> > --
>> > 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...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.

-- 
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.

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

[Marcin Jurczuk]

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 os namespace is declared at the begining of file:
http://schemas.xmlsoap.org/soap/envelope/; 
xmlns:os="os.xsd.v1">


I looks like go have bug with Unmarshaling tags with namespaces. Bug exists 
at least 2 years, maybe more.


W dniu wtorek, 1 sierpnia 2017 19:30:39 UTC+2 użytkownik rog napisał:
>
> 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 must have 
>the given name (and, optionally, name space) or else Unmarshal 
>returns an error. 
>
>
> On 1 August 2017 at 15:39, Marcin Jurczuk  
> wrote: 
> > 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 failing (sic!) 
> > 
> > Here is sample code that encodes struct and then tries decode the same 
> > struct 
> > 
> > https://play.golang.org/p/hE7vcXbymg 
> > 
> > 
> > It seems that Go have a lot of issues with XML jsut small portion: 
> > https://github.com/golang/go/issues/6800 (this one looks like my 
> problem - 
> > not fixed since 2013 !) 
> > https://github.com/golang/go/issues/9775 
> > https://github.com/golang/go/issues/9519 
> > 
> > 
> > Please help me to diagnose is it my problem or one of Go bugs 
> > 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.

Re: [go-nuts] Go Styleguide

[roger peppe]

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
internal to itself, and if you've imported it from the wrong
place, they might be broken. If it *doesn't* contain local
imports, then there might be no way to tell what the canonical
import path is intended to be.

But having a package comment in every file seems redundant
and somewhat annoying. FWIW I have a tool that updates
them automatically.


On 1 August 2017 at 18:30, Chris Hines  wrote:
> 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:
> https://blog.golang.org/godoc-documenting-go-code) are for documenting a
> package, not restricting where it can be imported from.
>
> On Tuesday, August 1, 2017 at 1:24:44 PM UTC-4, Peter Bourgon wrote:
>>
>> 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  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.

-- 
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.

Re: [go-nuts] Go Styleguide

[Chris Hines]

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: https://blog.golang.org/godoc-documenting-go-code) are for 
documenting a package, not restricting where it can be imported from.

On Tuesday, August 1, 2017 at 1:24:44 PM UTC-4, Peter Bourgon wrote:
>
> 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  > 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. 
>

-- 
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.

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

[roger peppe]

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 must have
   the given name (and, optionally, name space) or else Unmarshal
   returns an error.


On 1 August 2017 at 15:39, Marcin Jurczuk  wrote:
> 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 failing (sic!)
>
> Here is sample code that encodes struct and then tries decode the same
> struct
>
> https://play.golang.org/p/hE7vcXbymg
>
>
> It seems that Go have a lot of issues with XML jsut small portion:
> https://github.com/golang/go/issues/6800 (this one looks like my problem -
> not fixed since 2013 !)
> https://github.com/golang/go/issues/9775
> https://github.com/golang/go/issues/9519
>
>
> Please help me to diagnose is it my problem or one of Go bugs
>
>
> --
> 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.

-- 
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.

Re: [go-nuts] Go Styleguide

[Peter Bourgon]

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  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.

-- 
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.

Re: [go-nuts] Go Styleguide

[roger peppe]

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.

-- 
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.

Re: [go-nuts] Go Styleguide

[Peter Bourgon]

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 think!
>
> --
> 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.

-- 
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.

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

[ecstatic . coder]

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:
>
> 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 programming language goes into production and invokes "backward 
> compatibility" it rarely improves by evolution. cf. Fortran, Java. 
> Invariably, 
> improvement in programming happens by new programming languages arriving 
> on 
> the scene and being picked up (or not). Each programming language that 
> gains 
> traction invariably goes into decline as new languages pop up to replace 
> it. 
>
> But remember COBOL, FORTRAN, Fortran, and C still have large codebases in 
> place even though very few people would consider writing new code in those 
> languages. Go, Rust, D, etc. will travel the same path after their period 
> of 
> being very popular. 
>
> > 
> -- 
> Russel. 
> = 
>
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russ...@ekiga.net 
>  
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk 
>  
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
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.

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

[roger peppe]

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
> pointer types won't need heap allocation).

As it happens, it's the other way round - the solution using Interface can
make an allocation per element, but the solution using Value does not.

https://play.golang.org/p/Q0VHbfL7Ij

Additionally, the solution using Interface can lose the type information
in some cases and panic as a result.

https://play.golang.org/p/WocF9CaPoR

  cheers,
rog.


>
> 
> Josh Humphries
> jh...@bluegosling.com
>
> On Tue, Aug 1, 2017 at 7:29 AM, roger peppe  wrote:
>>
>> 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 underlying value, which
>> > make
>> > result not correct.
>> >
>> > Here is the code:
>> >
>> > package main
>> >
>> > import (
>> > "fmt"
>> > "reflect"
>> > )
>> >
>> > func reverse(in []reflect.Value) (out []reflect.Value) {
>> > inls := in[0]
>> > inlslen := inls.Len()
>> >
>> > for i, j := 0, inlslen-1; i < j; i, j = i+1, j-1 {
>> > a := inls.Index(i)
>> > b := inls.Index(j)
>> > // how to get underlying value of a and b ?
>> > a.Set(b)
>> > b.Set(a)
>> > }
>> > return in
>> > }
>> >
>> > var intFlipper func([]int) []int
>> >
>> > func main() {
>> > emptyFunc := reflect.ValueOf().Elem()
>> > pseudoFunc := reflect.MakeFunc(emptyFunc.Type(), reverse)
>> > emptyFunc.Set(pseudoFunc)
>> > fmt.Printf("%v\n", intFlipper([]int{2, 3, 4, 5, 6, 7}))
>> > }
>> >
>> > My code return [7 6 5 5 6 7], but excepting result is [7 6 5 4 3 2]
>> >
>> > --
>> > 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.
>>
>> --
>> 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.
>
>

-- 
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] Re: Go Styleguide

[hallo]

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 
> 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 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 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] xml namespaces - encoding ok, decoding result not ok

[Marcin Jurczuk]

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 failing (sic!)

Here is sample code that encodes struct and then tries decode the same 
struct

https://play.golang.org/p/hE7vcXbymg


It seems that Go have a lot of issues with XML jsut small portion:
https://github.com/golang/go/issues/6800 (this one looks like my problem - 
not fixed since 2013 !)
https://github.com/golang/go/issues/9775
https://github.com/golang/go/issues/9519


Please help me to diagnose is it my problem or one of Go bugs


-- 
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] Re: Go Styleguide

[Chris Hines]

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 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 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.

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

[Konstantin Khomoutov]

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, C#/.NET and JS.
Go just happens to neatly solve web-related problems but it by no means
is a web-centric language.

-- 
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.

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

[Jan Mercl]

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 more.

-- 

-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 from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Josh Humphries]

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

On Tue, Aug 1, 2017 at 7:29 AM, roger peppe  wrote:

> 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 underlying value, which
> make
> > result not correct.
> >
> > Here is the code:
> >
> > package main
> >
> > import (
> > "fmt"
> > "reflect"
> > )
> >
> > func reverse(in []reflect.Value) (out []reflect.Value) {
> > inls := in[0]
> > inlslen := inls.Len()
> >
> > for i, j := 0, inlslen-1; i < j; i, j = i+1, j-1 {
> > a := inls.Index(i)
> > b := inls.Index(j)
> > // how to get underlying value of a and b ?
> > a.Set(b)
> > b.Set(a)
> > }
> > return in
> > }
> >
> > var intFlipper func([]int) []int
> >
> > func main() {
> > emptyFunc := reflect.ValueOf().Elem()
> > pseudoFunc := reflect.MakeFunc(emptyFunc.Type(), reverse)
> > emptyFunc.Set(pseudoFunc)
> > fmt.Printf("%v\n", intFlipper([]int{2, 3, 4, 5, 6, 7}))
> > }
> >
> > My code return [7 6 5 5 6 7], but excepting result is [7 6 5 4 3 2]
> >
> > --
> > 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.
>
> --
> 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.
>

-- 
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] Re: "fallthrough statement out of place" in `if` block inside `swicth` block

[kultigin . tsz]

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: 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 measure to solve this.
>
> 1. Use if-else instead of switch
> 2. Use goto (like this: https://play.golang.org/p/TILUCapta6) (I think 
> this should be avoided. I would confise LABEL expression with one case)
> 3. Other (please comment)
>
> 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GO Vs D

[kultigin . tsz]

>
> 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 :)*


*- A language that doesn’t have everything is actually easier to program in 
than some that do.  Dennis M. Ritchie*


*- Do Less. Enable More. Russ Cox*

-- 
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.

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

[Jan Mercl]

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 such a clause
.

> 3. Other (please comment)

https://play.golang.org/p/8rL0zqaLP3

-- 

-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 from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Styleguide

[18635789436zhjk]

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 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] "fallthrough statement out of place" in `if` block inside `swicth` block

[Fumi Takeuchi]

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 measure to solve this.

1. Use if-else instead of switch
2. Use goto (like this: https://play.golang.org/p/TILUCapta6) (I think this 
should be avoided. I would confise LABEL expression with one case)
3. Other (please comment)

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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GO Vs D

[ecstatic . coder]

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 a "much better C++".

I mean, like Go, D has also an incredibly fast compilation, a GC, and it 
provides very convenient maps, arrays, strings, slices, foreach, ranges, 
concurrency, etc, all at the language level.

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.

Moreover, with D you can really go low-level like in C if you need to. It 
*also* has C-like pointers, structs, inline assembly, etc, if you want to 
use C or C++ functions and data structures without wrapper code.

Finally, what's really nice is that D provides all these features through a 
very simple, classic and convenient syntax, which make it quite easy to 
port your code from C, C++, Java, C#, Go, etc.

Of course, Go, as a web-centric language, has obviously a much more 
complete standard library when it comes to web development. 

So if you want to interact with servers, databases and anything like that, 
Go may remain the best alternative.

But for your command line or desktop developments, I think D could be much 
more appropriate than Go...

On Friday, October 11, 2013 at 9:54:23 PM UTC+1, Rohit Yadav wrote:
>
> Hi,
>
> Since the last active message on this thread a lot of progress was 
> achieved by both the projects, would anyone like to share latest 
> comparisons between the two languages and the ecosystem around it (tooling, 
> usage, adoption, etc.)?
> We see that Go is nowadays used for not just writing servers but general 
> programs as well, how does D scale to that and if Andrei and others can 
> update us on D with respect to areas where Go excels such as ease of 
> writing concurrent software, tooling, ease of learning the language and its 
> hackability.
>
> Regards,
> Rohit
>
> On Saturday, 14 August 2010 06:09:36 UTC+5:30, Andrei Alexandrescu wrote:
>>
>> On Aug 13, 3:00 pm, Ian Lance Taylor  wrote: 
>> > Andrei Alexandrescu  writes: 
>> > >http://www.informit.com/articles/printerfriendly.aspx?p=1609144 
>> > 
>> > Thanks.  As you know, this approach is clearly different from the one 
>> in 
>> > Go, which is a transfer of ownership model, where the transfer of 
>> > ownership is enforced only by convention.  And, of course, Go doesn't 
>> > use the type system, which follows Go's general guideline of keeping 
>> the 
>> > type system light weight. 
>>
>> I understand. So what we have now is: 
>>
>> (1) Pass-by-bitblt through channels for value types (i.e. no 
>> indirections, which means dynamic arrays are unduly shared). There is 
>> no checking that a value type being passed actually does not have 
>> indirections. 
>>
>> (2) Pass of ownership by unchecked convention for data with 
>> indirections. 
>>
>> (3) Everything else is undefined. 
>>
>> If that's true, parts 1 and 2 are of limited expressiveness but it's 
>> part 3 that's really problematic, and I'm not sure a putative 
>> programmer understands the implications. Essentially that means even 
>> lock-based programming relies on implementation-level vagaries because 
>> without a memory model the compiler and the processor are relatively 
>> free to hoist data around rather freely. We're back to the reorderings 
>> hell often showcased as motivators of Java's and C++0x's memory 
>> models. 
>>
>> > >> You're quite right: Go does permit data races, and does currently 
>> rely 
>> > >> only on convention to avoid them.  Go's advantage over C++, and it 
>> is a 
>> > >> significant advantage, is that the rules for valid sharing are 
>> fairly 
>> > >> simple, and the language makes it much easier to do valid sharing. 
>> > 
>> > > How does Go simplify the rules for valid sharing? Far as I can tell 
>> it 
>> > > can only simplify if it renders undue aliasing undefined. Does Go 
>> have 
>> > > something equivalent to Java's volatile and C++0x's atomic? 
>> > 
>> > The rules for valid sharing are encapsulated in the slogan "don't 
>> > communicate by sharing memory; instead, share memory by communicating." 
>> > That is, always use channels to communicate between goroutines.  Always 
>> > ensure that a single goroutine owns shared data, and use an explicit 
>> > channel send to transfer ownership to a different goroutine. 
>> > 
>> > This approach can be used in other languages also, of course; the 
>> > advantage I see in Go is that the language makes it simple and easy. 
>>
>> A memory model may as well be the perfect example where simplicity is 
>> your enemy - not defining one is indeed simple, but has huge costs to 
>> the user in one or more of correctness, 

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

[roger peppe]

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 underlying value, which make
> result not correct.
>
> Here is the code:
>
> package main
>
> import (
> "fmt"
> "reflect"
> )
>
> func reverse(in []reflect.Value) (out []reflect.Value) {
> inls := in[0]
> inlslen := inls.Len()
>
> for i, j := 0, inlslen-1; i < j; i, j = i+1, j-1 {
> a := inls.Index(i)
> b := inls.Index(j)
> // how to get underlying value of a and b ?
> a.Set(b)
> b.Set(a)
> }
> return in
> }
>
> var intFlipper func([]int) []int
>
> func main() {
> emptyFunc := reflect.ValueOf().Elem()
> pseudoFunc := reflect.MakeFunc(emptyFunc.Type(), reverse)
> emptyFunc.Set(pseudoFunc)
> fmt.Printf("%v\n", intFlipper([]int{2, 3, 4, 5, 6, 7}))
> }
>
> My code return [7 6 5 5 6 7], but excepting result is [7 6 5 4 3 2]
>
> --
> 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.

-- 
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.

Re: [go-nuts] Go Styleguide

[hallo]

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 was removed due to irrelevance, thank you!
- The internal-packages section explicitly mentions to use this if building 
a cmd. This obviously makes less sense in libraries but I find it useful 
for cmds.
- The explicit go-bindata mention is gone, i still makes deployments easier 
since you could deploy a single static binary with everything in it. You'd 
need to gitignore the generated file and make sure it gets built before the 
binary (go:generate is often a good idea) - what confusion do you mean?


-- 
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.

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

[Russel Winder]

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 programming language goes into production and invokes "backward
compatibility" it rarely improves by evolution. cf. Fortran, Java. Invariably,
improvement in programming happens by new programming languages arriving on
the scene and being picked up (or not). Each programming language that gains
traction invariably goes into decline as new languages pop up to replace it.

But remember COBOL, FORTRAN, Fortran, and C still have large codebases in
place even though very few people would consider writing new code in those
languages. Go, Rust, D, etc. will travel the same path after their period of
being very popular.

> 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
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.


signature.asc
Description: This is a digitally signed message part

[go-nuts] Re: Go Styleguide

[hallo]

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

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

[roger peppe]

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 NewHorizontalPodAutoscalerInformer
>> looks
>> pretty much exactly like what you've got there, where
>> sharedUnderlyingCacheThing
>> is the result of cache.NewSharedIndexInformer as called currently in the
>> code. That is, that constructor inside the call to NewSharedIndexInformer
>> seems a lot like a constructor for sharedUnderlyingCacheThing to me.
>> I'm not entirely convinced that generics would make the code much
>> cleaner in this case.
>
>
> The duplication I'm thinking about is more the multiple packages, one for
> each type being informed on. If the top level informers package, or
> function, were templatable by the type being informed on, there would be no
> need for the per-type packages. As it stands there is little benefit from
> the godocs for each individual informer. The current docs are verbose well
> beyond the value they add.
>
>>
>>
>> You might want to experiment by refactoring some of that k8s code to use
>> generics (using whatever your preferred formulation might be) and see
>> what it might look like, and whether it looks significantly
>> nicer/simpler/cleaner
>> as a result
>
>
> I might look at something for the informers case, but it's worth pointing
> out that I was thinking generics could provide a difference API, rather than
> a cleaner implementation of the existing one.

It's that different API that I'd be interested in exploring - if you
had generics,
how would you redesign the API so that it's cleaner, simpler and smaller
than the existing API?

-- 
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.

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

[Sebastien Binet]

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 might be useful for us is in in place of
> generating float32 versions of float64 blas and lapack implementations.
>

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)


>
> Honestly, I've never really felt a lack.
>
the other time I felt an urge to reach for generics was when implementing
code for reading/writing various scientific data file formats (astro, HEP).
but I was surprised to realize generics weren't *that* necessary after some
aclimatation time. (I am coming from C++/python.)

-s


> On Mon, 2017-07-31 at 05:50 -0700, Mandolyte wrote:
> > It's been many years since I was involved in developing complex
> > systems
> > (C++ and Java). But I agree, it was mostly lists and sets with
> > searching
> > and sorting. But I also used them for algorithms a good bit. Thus I
> > would
> > guess that the maintainers of GONUM libraries might benefit (anyone
> > confirm?).
>
> --
> 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.
>

-- 
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.

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

[fazal]

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 shiny for review that maybe after some testing and 
> input from others will stand on its on merits, for such a proposal.
>
> Even as a side gig for people, I think shiny is pretty far along; but I 
> think shiny has reached a critical point where every decision may get 
> cemented and people want those decisions to be the best possible ones.
>
> It wouldn't be entirely difficult, just time-consuming, to pump out all 
> those widgets by cementing in a bunch of other decisions; but then we just 
> sort of have this Go version of every other GUI toolkit with the same 
> every-other problems. There's a good opportunity to research new ideas now.
>
> Shiny is already doing and demonstrating a lot of important things; but 
> event and configuration, and a single unified layout and animation step are 
> two things I think we could all be doing better.
>
> On Mon, Jul 31, 2017 at 8:44 PM Nigel Tao  > wrote:
>
>> On Tue, Aug 1, 2017 at 6:25 AM, fazal  
>> wrote:
>> > It was one of the things I was looking forward to, but I see almost no
>> > activity there, which makes me sad.
>>
>> It's certainly not very active right now. I work part time, for
>> uninteresting reasons, and shiny is unfortunately not my primary
>> project.
>>
>> I'd like to work on it again at some point, but I can't promise when
>> that will happen.
>>
>> FWIW, there was some recent discussions of a new, multi-person Go GUI
>> effort at 
>> https://groups.google.com/d/msg/golang-nuts/JyrN8cxWCrU/H6oZpv02BQAJ
>>
>> --
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.

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

[fazal]

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  
> wrote: 
> > It was one of the things I was looking forward to, but I see almost no 
> > activity there, which makes me sad. 
>
> It's certainly not very active right now. I work part time, for 
> uninteresting reasons, and shiny is unfortunately not my primary 
> project. 
>
> I'd like to work on it again at some point, but I can't promise when 
> that will happen. 
>
> FWIW, there was some recent discussions of a new, multi-person Go GUI 
> effort at 
> https://groups.google.com/d/msg/golang-nuts/JyrN8cxWCrU/H6oZpv02BQAJ 
>

-- 
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.