RE: [go-nuts] Re: [Newbie] Why this code is so slow?

Changing just the mod operation to int32 made the whole program run about 2.5 times faster for me. Wow! I had no idea that there would be that much difference. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com

[go-nuts] Re: [Newbie] Why this code is so slow?

int type in Go is 64 bit on 64 bit system . Most likely you are using 32 bit integers in other languages (e.g. int in Java). 64 bit division is slower than 32 bit. Try changing your Go program to use int32 instead and see if it becomes faster. -- You received this message because you are

Re: [go-nuts] cmd.Exec over TCP

On Sunday, 26 February 2017 16:54:25 UTC+11, Oleg Puchinin wrote: > > Hello ! > What is wrong and how to do it ? > What did you expect to happen? What happened instead? > > func handleconnection(tcp net.Conn) { > cmd := exec.Command("/bin/bash") > cmd.Stdin = tcp > cmd.Stdout =

[go-nuts] cmd.Exec over TCP

Hello ! What is wrong and how to do it ? func handleconnection(tcp net.Conn) { cmd := exec.Command("/bin/bash") cmd.Stdin = tcp cmd.Stdout = tcp cmd.Run() } go handle connection Thanks ! Oleg. -- You received this message because you are subscribed to the Google Groups

[go-nuts] Is there functionality in golang.org/x/crypto/ssh to close a SSH connection server-side after N number of (password) tries?

Provide a proper PasswordCallback to your server, as in the NewServerConn example (https://godoc.org/golang.org/x/crypto/ssh#NewServerConn). Thats your function, you can program any algorithm you wish. -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] Please help my (exec.Command)

On Sun, Feb 26, 2017 at 12:03 AM, Oleg Puchinin wrote: > I stupid :( > Work fine, thank you. > > > You're welcome. And anyone who chooses Go isn't stupid. ^_^ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Please help my (exec.Command)

I stupid :( Work fine, thank you. Oleg. 2017-02-26 10:59 GMT+06:00 Shawn Milochik : > Try: > > > cmd := exec.Command(spl...) > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and

Re: [go-nuts] Please help my (exec.Command)

Try: cmd := exec.Command(spl...) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit

[go-nuts] Please help my (exec.Command)

How to do it without errors ? spl := strings.Split(scmd, ' ') cmd := exec.Command(spl[0], spl[1:]) Thank you ! Oleg. -- 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

[go-nuts] Re: [Newbie] Why this code is so slow?

Using pprof to profile your code we get this: (pprof) top5 30.01s of 30.02s total ( 100%) Dropped 4 nodes (cum <= 0.15s) flat flat% sum%cum cum% 30s 99.93% 99.93%30s 99.93% main.sommeDiviseursPropres 0.01s 0.033% 100% 30.01s 100% main.main

Re: [go-nuts] Is uint(v) when v is minus because a huge number supposed behavior?

yes. https://en.wikipedia.org/wiki/Two's_complement On Sat, Feb 25, 2017 at 10:21 PM, Felix Sun wrote: > https://play.golang.org/p/TmxMmltHGH > > package main > > import ( > "fmt" > ) > > func main() { > var f int = -1 > fmt.Println("become huge number:", uint(f)) >

[go-nuts] Is uint(v) when v is minus because a huge number supposed behavior?

https://play.golang.org/p/TmxMmltHGH package main import ( "fmt" ) func main() { var f int = -1 fmt.Println("become huge number:", uint(f)) fmt.Println("this panic", uint(-1)) } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

[go-nuts] Is there functionality in golang.org/x/crypto/ssh to close a SSH connection server-side after N number of (password) tries?

Hey all, The client ssh library of golang.org/x/crypto/ssh has the maxTries variable in the RetryableAuthMethod: func RetryableAuthMethod(auth AuthMethod , maxTries int ) AuthMethod

Re: [go-nuts] http: do not recover a panic

Already filed on https://github.com/golang/go/issues/16542 and the proposal have declined Since there is a workaround (https://github.com/golang/go/issues/16542#issuecomment-246549902) and it's difficult to implement without breaking the backward compatibility. Please check the issue if you wanna

Re: [go-nuts] http: do not recover a panic

This was proposed and rejected. See the proposal for the details and how to get the behavior you desire: https://github.com/golang/go/issues/16542 On Saturday, February 25, 2017 at 11:44:54 AM UTC-8, Manlio Perillo wrote: > > Well, what's wrong with something like a RecoverPanic bool field in

[go-nuts] Where to find internships related to go-lang in India

I'm an Indian student, I need an internship where major programming language is go , so is there any company which was interested, and any link to find one would be thankful. Even if it's remote work, I don't have any problem. Unable to find any other place to post such, so excuse me, Thank

[go-nuts] [Newbie] Why this code is so slow?

Hi, I'm just trying to learn Go and, as i do with other languages, i first try to code some trivial algorithms. Here, i want to implement a program which displays the amical numbers couples given a limit. I'm using the very same algorithm i'm using in Python, Java, Haskell, Scala, Nim, etc.)

Re: [go-nuts] http: do not recover a panic

The proposal in issue #16542 is no good, because it proposes a change that breaks compatibility. What I'm proposing is: 1) To add a new field to the Server struct and not a new global variable 2) The default value of RecoverPanic is false to retain backward compatibility Isn't it possible to

Re: [go-nuts] http: do not recover a panic

Well, what's wrong with something like a RecoverPanic bool field in the Server struct? Manlio Il giorno sabato 25 febbraio 2017 20:36:34 UTC+1, Matt Harden ha scritto: > > I believe it's already been admitted to have been a mistake, and I don't > know why we haven't created an option to turn

Re: [go-nuts] http: do not recover a panic

I believe it's already been admitted to have been a mistake, and I don't know why we haven't created an option to turn it off (maybe because "Options Are Bad™"). On Sat, Feb 25, 2017 at 11:02 AM Manlio Perillo wrote: > I'm starting to use Go for the development of my

[go-nuts] http: do not recover a panic

I'm starting to use Go for the development of my web applications, but I can not help but feel anxious about the fact that the HTTP server recovers from a panic. I run my applications behind Systemd (and behind Nginx) so I prefer the application to terminate instead of continuing in a possible

Re: [go-nuts] Passing Already Accepted Connection to http.Serve()

Matt: Thank you so much for pointing this point. You are totally correct. As a newly minted Go programmer I failed to see that. I have the code working now… Your help is very much appreciated. HFC From: Matt Harden Date: Saturday, February 25, 2017 at 12:01 PM To: Henry Camacho,

Re: [go-nuts] Re: is it a waste of time to study old synchronization algorithms?

...and it is also always the question of your intent--do you want to be good in a computer programming job or do you want to be a good computer scientist? If the latter, then every step of the way from Babylonian computation through Egyptian knot-tying ("trigonometry") the EDVAC and Konrad Zuse

Re: [go-nuts] Passing Already Accepted Connection to http.Serve()

You're not waiting for the server to finish handling the connection before returning from main, which abruptly ends your program. Try importing context and using this at the end of main() (note that Shutdown was recently added): ctx := context.TODO()

[go-nuts] Custom serializer issue

I bet that the recursivity cause the problem. You decode in a different order than you encode. Separate your encoded chunks (refs, strings, sons, and the nodes) with indistinguishable blobs holding only a type info. I.e. 16 bytes of "REFSREFSREFSREFS..." only to ease debugging and allow

Re: [go-nuts] Goroutine in a for loop: Closure versus direct

On Sat, Feb 25, 2017 at 9:58 PM, Ayan George wrote: > > > On 02/25/2017 03:48 AM, Amit Saha wrote: >> >> I think both these approaches are fine, but just wanted to check. >> > > tl;dr: I think the second example is the way to go. > > I'm somewhat new to Golang so please someone

Re: [go-nuts] Goroutine in a for loop: Closure versus direct

On 02/25/2017 03:48 AM, Amit Saha wrote: > > I think both these approaches are fine, but just wanted to check. > tl;dr: I think the second example is the way to go. I'm somewhat new to Golang so please someone correct me if I'm wrong. Neither of your examples are closures and, AFAIK,

Re: [go-nuts] Goroutine in a for loop: Closure versus direct

On Sat, Feb 25, 2017 at 8:03 PM, Jan Mercl <0xj...@gmail.com> wrote: >> I think both these approaches are fine, but just wanted to check. > > They're not, #2 has a data race. Thanks, can you please explain how or point me to a doc/post explaining it? > > -- > > -j -- http://echorand.me --

Re: [go-nuts] Goroutine in a for loop: Closure versus direct

> I think both these approaches are fine, but just wanted to check. They're not, #2 has a data race. -- -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

[go-nuts] Goroutine in a for loop: Closure versus direct

Hello, When spawning goroutines in a for loop - is there any reason to prefer approach #1 below versus #2 or vice-versa? Approach #1: Using a closure func printme(val int) { // Do something with val } func main() { slice := []int{1, 23, 100, 101} for _, val := range slice { go

[go-nuts] Re: is it a waste of time to study old synchronization algorithms?

On Saturday, 25 February 2017 08:37:31 UTC+2, Marwan abdel moneim wrote: > > Algorithms like Peterson’s algorithm > and others > , >