Re: [go-nuts] Re: time.Parse with millisecond separated by colon

[Diego Medina]

Thanks, for our case, it will be easy enough to just change : for . and 
move on from there.

Thanks

On Monday, October 30, 2017 at 4:55:03 PM UTC-4, Rob 'Commander' Pike wrote:
>
> Or you could change the : to a . and use time.Parse.
>
> -rob
>
>
> On Tue, Oct 31, 2017 at 4:47 AM, Jim Cote  > wrote:
>
>> See https://golang.org/src/time/format.go?s=23626:23672#L249.  The 
>> standard library is explicitly looking for the period.  Your easiest 
>> solution would be to just write your own parser.
>>
>>
>> On Monday, October 30, 2017 at 11:20:51 AM UTC-4, Diego Medina wrote:
>>>
>>> Hi,
>>>
>>> I need to parse datetime data given in a csv file, the format I get (I 
>>> get a lot of diff ones but the latest is):
>>>
>>> 20060102 15:04:05:000
>>>
>>> but if I use that with time.Parse, it doesn't parse the millisecond 
>>> part, tells me:
>>>
>>> parsing time "20170628 12:11:00:103" as "20060102 15:04:05:000": cannot 
>>> parse "103" as ":000"
>>>
>>>
>>>
>>> if I change the format, from :000 to .000 and then change my source 
>>> time, to be  12:11:00.103
>>>
>>> it does parse. Is there a way to avoid having to edit the source file, 
>>> so I can just take the datetime info as it is in the file?
>>>
>>> playground example:
>>>
>>> https://play.golang.org/p/cHTDxFYmrF
>>>
>>> Thanks
>>>
>>> Diego
>>>
>> -- 
>> 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] How to know if interface{} data is nil w/o reflecting?

[Jesse McNelis]

On Tue, Oct 31, 2017 at 2:25 AM,   wrote:
> I found this a little bit non sequitur - if I want to call interface
> function I have a perfect business to check if underlying object is not nil
> before call just to avoid panic on call. Besides underlying nil in interface
> may be used to signal condition for variety of types implementing this
> interface, and since there is no inheritance in Go - sometimes it's the only
> proper way to indicate such condition.

In Go you can call a method on nil without a panic, this means that
unless you know the type you don't know if a nil value of that type is
a valid value to call a method on or not. You would be making a big
assumption about the type contained within the interface{} if you
checked that value for nil.

Of course since you don't know the type of the value inside the
interface{} it might not even be a value comparable to nil, in which
case should the comparison return false or panic?

-- 
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: time.Parse with millisecond separated by colon

[Rob Pike]

Or you could change the : to a . and use time.Parse.

-rob


On Tue, Oct 31, 2017 at 4:47 AM, Jim Cote  wrote:

> See https://golang.org/src/time/format.go?s=23626:23672#L249.  The
> standard library is explicitly looking for the period.  Your easiest
> solution would be to just write your own parser.
>
>
> On Monday, October 30, 2017 at 11:20:51 AM UTC-4, Diego Medina wrote:
>>
>> Hi,
>>
>> I need to parse datetime data given in a csv file, the format I get (I
>> get a lot of diff ones but the latest is):
>>
>> 20060102 15:04:05:000
>>
>> but if I use that with time.Parse, it doesn't parse the millisecond part,
>> tells me:
>>
>> parsing time "20170628 12:11:00:103" as "20060102 15:04:05:000": cannot 
>> parse "103" as ":000"
>>
>>
>>
>> if I change the format, from :000 to .000 and then change my source time,
>> to be  12:11:00.103
>>
>> it does parse. Is there a way to avoid having to edit the source file, so
>> I can just take the datetime info as it is in the file?
>>
>> playground example:
>>
>> https://play.golang.org/p/cHTDxFYmrF
>>
>> Thanks
>>
>> Diego
>>
> --
> 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] http server request queue

[Jonathan Yu]

chi includes a middleware for this, see:
https://github.com/go-chi/chi/blob/master/middleware/throttle.go and some
examples here:
https://github.com/go-chi/chi/blob/master/_examples/limits/main.go

I haven't used it myself, but it seems to support having a fixed backlog as
well, which is important for backpressure, see:
https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/#backpressure

On Sat, Oct 28, 2017 at 6:23 AM, Keith Brown  wrote:

> Here is a scenario: a high traffic site which executes costly operations
> (database / filesystem / compute heavy operations). The web server is
> running standard go/http/server.
>
> I would like to handle at most 100 requests and the remainder to queue --
> all while the client (curl) is waiting. Are there tools to throttle the web
> server? And is there a way to view the queue of work?
>
>
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn ,
Twitter , GitHub ,
Facebook 
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options

 (HBR)

-- 
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: Why cmd/compile/internal/syntax is not using go/ast ?

[Dave Cheney]

The short version is the former was written before the Go compiler was 
ported to Go.

The longer story is laid out in this presentation from 
2014. https://www.youtube.com/watch?v=QIE5nV5fDwA

On Tuesday, 31 October 2017 04:30:06 UTC+11, Abyx wrote:
>
> Golang has two parsers. go/* for "go fmt", and cmd/compile/internal/syntax 
> for "go compile".
> Why is that?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] mutual exclusion algorithm of Dijkstra - strange behaviour

[Jan Mercl]

On Mon, Oct 30, 2017 at 6:29 PM  wrote:

> I noticed a very strange effect by translating the
> mutual exclusion algorithm of E. W. Dijkstra to Go.

For every combination of lines A/B present/not present, the program has
data races, so there's nothing to reason about.

You can try it by yourself by issuing $ go run -race main.go

-- 

-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: time.Parse with millisecond separated by colon

[Jim Cote]

See https://golang.org/src/time/format.go?s=23626:23672#L249.  The standard 
library is explicitly looking for the period.  Your easiest solution would 
be to just write your own parser.

On Monday, October 30, 2017 at 11:20:51 AM UTC-4, Diego Medina wrote:
>
> Hi,
>
> I need to parse datetime data given in a csv file, the format I get (I get 
> a lot of diff ones but the latest is):
>
> 20060102 15:04:05:000
>
> but if I use that with time.Parse, it doesn't parse the millisecond part, 
> tells me:
>
> parsing time "20170628 12:11:00:103" as "20060102 15:04:05:000": cannot parse 
> "103" as ":000"
>
>
>
> if I change the format, from :000 to .000 and then change my source time, 
> to be  12:11:00.103
>
> it does parse. Is there a way to avoid having to edit the source file, so 
> I can just take the datetime info as it is in the file?
>
> playground example:
>
> https://play.golang.org/p/cHTDxFYmrF
>
> Thanks
>
> Diego
>

-- 
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] mutual exclusion algorithm of Dijkstra - strange behaviour

[Henrik Johansson]

I think it's the non-preemptive scheduler that hits you.
Afaik it is a known behavior that I am not sure how to fix.
I did not at all look at the solution itself.

mån 30 okt. 2017 kl 18:29 skrev :

> Dear Go-community,
>
> I noticed a very strange effect by translating the
> mutual exclusion algorithm of E. W. Dijkstra to Go.
> Reference:
>   Cooperating Sequential Processes. Technical Report EWD-123,
>   Technological University Eindhoven (1965)
>   http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF)
>
> Inserting or omitting code lines A and B resp.
> changes the behaviour of this program very severely:
>
> With line A and without line B:
>   mutual exclusion is not guaranteed,
> with line B and without line A:
>   lock does not terminate and
> with both lines:
>   the program works as it should.
>
> --- 8< 
> package main
>
> import (
>   "math/rand"
>   "time"
> )
>
> const N = 10 // number of goroutines involved
>
> var (
>   turn int
>   b, c = make([]int, N+1), make([]int, N+1)
>   n= uint(0)
>   inCS = make([]bool, N+1)
>   s= make([]string, N+1)
>   done = make(chan int)
> )
>
> func chk(i int) {
>   for j := 1; j <= N; j++ {
> if j != i && inCS[j] {
>   panic("oops")
> }
>   }
> }
>
> func lock(i int) {
>   b[i] = 0
> L:
>   if turn != i {
> c[i] = 1
> if b[turn] == 1 {
>   turn = i
>   goto L
> }
>   }
>   time.Sleep(1) // A
>   c[i] = 0
>   time.Sleep(1) // B
>   for j := 1; j <= N; j++ {
> if j != i && c[j] == 0 {
>   goto L
> }
>   }
>   inCS[i] = true
>   chk(i)
> }
>
> func unlock(i int) {
>   inCS[i] = false
>   c[i], b[i] = 1, 1
>   //  turn = 0 // does not matter
> }
>
> func v() {
>   time.Sleep(time.Duration(1e7 + rand.Int63n(1e7)))
> }
>
> func count(i int) {
>   for k := 0; k < 100; k++ {
> lock(i)
> accu := n
> v()
> accu++
> v()
> n = accu
> v()
> println(s[i], n)
> unlock(i)
> v()
>   }
>   done <- 0
> }
>
> func main() {
>   s[1] = ""
>   for i := 2; i <= N; i++ {
> s[i] = s[i-1] + "   "
>   }
>   for i := 1; i <= N; i++ {
> go count(i)
>   }
>   for i := 1; i <= N; i++ {
> <-done
>   }
> }
> --- >8 
>
> The cause for the "freaking out" of the program without
> those compulsory breaks (of only 1 ns) is absolutely unclear.
>
> Any sort of help is welcome!
>
> Kind regards to everybody,
>
> Christian Maurer
>
> --
> 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] mutual exclusion algorithm of Dijkstra - strange behaviour

[dr . ch . maurer]

Dear Go-community,

I noticed a very strange effect by translating the
mutual exclusion algorithm of E. W. Dijkstra to Go.
Reference:
  Cooperating Sequential Processes. Technical Report EWD-123,
  Technological University Eindhoven (1965)
  http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF)

Inserting or omitting code lines A and B resp.
changes the behaviour of this program very severely:

With line A and without line B:
  mutual exclusion is not guaranteed,
with line B and without line A:
  lock does not terminate and
with both lines:
  the program works as it should.

--- 8< 
package main

import (
  "math/rand"
  "time"
)

const N = 10 // number of goroutines involved

var (
  turn int
  b, c = make([]int, N+1), make([]int, N+1)
  n= uint(0)
  inCS = make([]bool, N+1)
  s= make([]string, N+1)
  done = make(chan int)
)

func chk(i int) {
  for j := 1; j <= N; j++ {
if j != i && inCS[j] {
  panic("oops")
}
  }
}

func lock(i int) {
  b[i] = 0
L:
  if turn != i {
c[i] = 1
if b[turn] == 1 {
  turn = i
  goto L
}
  }
  time.Sleep(1) // A
  c[i] = 0
  time.Sleep(1) // B
  for j := 1; j <= N; j++ {
if j != i && c[j] == 0 {
  goto L
}
  }
  inCS[i] = true
  chk(i)
}

func unlock(i int) {
  inCS[i] = false
  c[i], b[i] = 1, 1
  //  turn = 0 // does not matter
}

func v() {
  time.Sleep(time.Duration(1e7 + rand.Int63n(1e7)))
}

func count(i int) {
  for k := 0; k < 100; k++ {
lock(i)
accu := n
v()
accu++
v()
n = accu
v()
println(s[i], n)
unlock(i)
v()
  }
  done <- 0
}

func main() {
  s[1] = ""
  for i := 2; i <= N; i++ {
s[i] = s[i-1] + "   "
  }
  for i := 1; i <= N; i++ {
go count(i)
  }
  for i := 1; i <= N; i++ {
<-done
  }
}
--- >8 

The cause for the "freaking out" of the program without
those compulsory breaks (of only 1 ns) is absolutely unclear.

Any sort of help is welcome!

Kind regards to everybody,

Christian Maurer

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


dijkstra.go
Description: Binary data

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

[tmpbox]

I found this a little bit non sequitur - if I want to call interface 
function I have a perfect business to check if underlying object is not nil 
before call just to avoid panic on call. Besides underlying nil in 
interface may be used to signal condition for variety of types implementing 
this interface, and since there is no inheritance in Go - sometimes it's 
the only proper way to indicate such condition.

On Monday, June 4, 2012 at 7:54:17 PM UTC-4, Jesse McNelis wrote:
>
> On Tue, Jun 5, 2012 at 8:50 AM, Jonathan Gold  > wrote: 
> > I'm a bit stumped and wondering if I'm overlooking some way, besides 
> reflection, 
> > to determine whether the data pointed at by an interface{} is actually a 
> nil 
> > pointer: 
>
> You just use a type assertion. If you don't know the type, then you 
> don't know if nil is a valid value for it and thus have no business 
> checking for it. 
>
>
> -- 
> = 
> http://jessta.id.au 
>

-- 
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] time.Parse with millisecond separated by colon

[Diego Medina]

Hi,

I need to parse datetime data given in a csv file, the format I get (I get 
a lot of diff ones but the latest is):

20060102 15:04:05:000

but if I use that with time.Parse, it doesn't parse the millisecond part, 
tells me:

parsing time "20170628 12:11:00:103" as "20060102 15:04:05:000": cannot parse 
"103" as ":000"



if I change the format, from :000 to .000 and then change my source time, 
to be  12:11:00.103

it does parse. Is there a way to avoid having to edit the source file, so I 
can just take the datetime info as it is in the file?

playground example:

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

Thanks

Diego

-- 
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] golang.org/x/net/websocket, getting hot CPU while reading

[Val]

Hello Vladimir, first you must check errors returned by all calls of Receive 
and Send. Better break the loop if error is not nil.

-- 
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] An efficient algorithm to write binary data

[roger peppe]

Something like this is a bit simpler, avoids the need for unsafe, and
may be a little faster too:
https://play.golang.org/p/4jayHwLroR
It may be quicker to use a type switch: https://play.golang.org/p/4uu2XeVM9m

It's a pity that about the need for a dynamic type conversion on every
field, but the best I could come up with for avoiding it was this,
which probably won't be any faster:
https://play.golang.org/p/3Ihgdm1Yjo

Or perhaps this (not recommended), which is horribly unsafe and again
probably won't be any faster: https://play.golang.org/p/uLdi7Sw3Ml

On 29 October 2017 at 23:20, DrGo  wrote:
> Thanks Michael,
> Here is the cleaner current version, thanks to  your suggestion:
>
> //writeData loops over the field vectors and write their binary
> representation to an io.Writer
> func (sf *File) writeData(w io.Writer) error {
> if sf.NoObs == 0 {
> return nil
> }
> if len(sf.fields) == 0 {
> return fmt.Errorf("No fields")
> }
> bs := make([]byte, sf.recordSize)
> for i := int32(0); i < sf.NoObs; i++ {
> offset := 0
> for _, f := range sf.fields {
> switch f.FieldType {
> case StataByte:
> v := f.data.([]int8)[i]
> bs[offset] = byte(v)
> offset++
> case StataInt:
> v := f.data.([]int16)[i]
> bs[offset] = byte(v)
> offset++ //incrementing the offset instead of using
> bs[offset+1] to avoid doing the addition twice
> bs[offset] = byte(v >> 8)
> offset++
> case StataLong:
> v := f.data.([]int32)[i]
> bs[offset] = byte(v)
> offset++
> bs[offset] = byte(v >> 8)
> offset++
> bs[offset] = byte(v >> 16)
> offset++
> bs[offset] = byte(v >> 24)
> offset++
> case StataFloat:
> base := *(*[4]byte)(unsafe.Pointer(([]float32)[i]))
> copy(bs[offset:], base[:])
> offset += 4
> case StataDouble:
> base := *(*[8]byte)(unsafe.Pointer(([]float64)[i]))
> copy(bs[offset:], base[:])
> offset += 8
> default:
> return fmt.Errorf("Field type [%d] not supported in field
> %s", f.FieldType, f.Name)
> }
> }
> if _, err := w.Write(bs); err != nil {
> return err
> }
> }
> return nil
> }
>
>
> On Saturday, October 28, 2017 at 9:38:19 AM UTC-5, Michael Jones wrote:
>>
>> you could do your unsafe cast to an appropriately-sized byte array and
>> write that as a single call or use it to access the bytes:
>>
>> base := *(*[8]byte)(unsafe.Pointer())
>> bs[offset+0]=base[0]
>> bs[offset+1]=base[1]
>> :
>> offset+=8
>>
>>
> --
> 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: Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

[dc0d]

Thanks!

Seems to be the best solution. I just wanted to check what should be done; 
in such situations which that extra signaling about closing channel is 
undesirable.

Actually since there is a timeout element too, here a method is used (func 
(p *Payload) WaitResult(timeout ...time.Duration) (*Result, error) {...}). 
And an explicit ErrTimeout is preferred here, instead of overloading the 
semantic of closing channel, with the concept of timeout. But since there 
can not be any other sort of errors (the Result has an error field itself) 
I wonder if I should use that.

On Monday, October 30, 2017 at 12:40:07 PM UTC+3:30, Dave Cheney wrote:
>
> I think you should use a channel. If the communication is between two 
> parities then there is no need to close the channel after sending the 
> result as the are not other parties to inform that they missed the message. 

-- 
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 version 1.9 - not able to build

[desaiabhijit]

Go it working..

MAC  installed "go 1.9" executable in /usr/local/bin which was overriding 
the /usr/local/go/bin "go" executable

Removed it and things works fine now

Thanks


On Monday, October 30, 2017 at 4:24:22 PM UTC+5:30, Abhijit Desai wrote:
>
> Thanks for the help Dave
>
> Let me check 
>
> Rgds
>
> Abhi
>
> On Monday, October 30, 2017 at 4:14:27 PM UTC+5:30, Dave Cheney wrote:
>>
>> Please unset GOROOT, that is the root of the problems with your 
>> installation. Then follow the instructions above.
>
>

-- 
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 version 1.9 - not able to build

[desaiabhijit]

still no luck... not sure where this coming from

go version

go version go1.9.2 darwin/amd64




On Monday, October 30, 2017 at 4:14:27 PM UTC+5:30, Dave Cheney wrote:
>
> Please unset GOROOT, that is the root of the problems with your 
> installation. Then follow the instructions above.

-- 
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 version 1.9 - not able to build

[desaiabhijit]

Thanks for the help Dave

Let me check 

Rgds

Abhi

On Monday, October 30, 2017 at 4:14:27 PM UTC+5:30, Dave Cheney wrote:
>
> Please unset GOROOT, that is the root of the problems with your 
> installation. Then follow the instructions above.

-- 
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 version 1.9 - not able to build

[Lucio]

That's not true. I frequently build, as below, a single executable from a 
choice of a few in the same directory. Works a treat.

Lucio.

On Monday, 30 October 2017 11:13:52 UTC+2, Volker Dobler wrote:
>
> $ go build a.go
>>
>
> go build works on packages (or paths, not on files).
>
> V.
>
>
>

-- 
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 version 1.9 - not able to build

[Dave Cheney]

Please unset GOROOT, that is the root of the problems with your installation. 
Then follow the instructions above.

-- 
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 version 1.9 - not able to build

[desaiabhijit]

$ which go

/usr/local/bin/go


$ sudo vi $HOME/.profile


export GOPATH=$HOME/work

export PATH=$PATH:/usr/local/go/bin

export GOROOT=/usr/local/go

export PATH="$HOME/.cargo/bin:$PATH"



On Monday, October 30, 2017 at 3:51:30 PM UTC+5:30, Dave Cheney wrote:
>
> Do you have GOROOT set? I set it 
>
> What does ‘which go’ return?

-- 
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 version 1.9 - not able to build

[Dave Cheney]

Do you have GOROOT set? I set it

What does ‘which go’ return?

-- 
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 version 1.9 - not able to build

[desaiabhijit]

Deleted usr/local/go and copied/extracted go1.7.4.darwin-amd64.tar.gz

usr/local/go/VERSION file shows go1.7.4

but go version still showing version 1.9.2

Don't know where it's coming from

Any idea?

go version

go version go1.9.2 darwin/amd64


$ go env

GOARCH="amd64"

GOBIN=""

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GOOS="darwin"

GOPATH="/Users/iwtx/work"

GORACE=""

GOROOT="/usr/local/go"

GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"

GCCGO="gccgo"

CC="clang"

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 -gno-record-gcc-switches -fno-common"

CXX="clang++"

CGO_ENABLED="1"

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

PKG_CONFIG="pkg-config"





On Monday, October 30, 2017 at 3:11:59 PM UTC+5:30, Dave Cheney wrote:
>
> It looks like your using OS X, which doesn’t ship with any version of Go 
> that I know of. Nevertheless the uninstall operation is simple, just delete 
> /usr/local/go and follow the installation instructions on the website.

-- 
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 version 1.9 - not able to build

[Dave Cheney]

It looks like your using OS X, which doesn’t ship with any version of Go that I 
know of. Nevertheless the uninstall operation is simple, just delete 
/usr/local/go and follow the installation instructions on the website.

-- 
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 version 1.9 - not able to build

[desaiabhijit]

Updated OS os... so I think it's auto installed 1.9 version over 1.7

How to remove it? or any solution?

Please help

Thanks,

Abhi

On Monday, October 30, 2017 at 2:37:45 PM UTC+5:30, Dave Cheney wrote:
>
> Errors like these are usually caused by either having multiple versions of 
> Go installed on your system, or overwriting one version of Go with another.
>
> how did you upgrade Go on this machine? How was the previous version 
> installed?
>

-- 
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 version 1.9 - not able to build

[Volker Dobler]

>
> $ go build a.go
>

go build works on packages (or paths, not on files).

V.


-- 
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] Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

[Dave Cheney]

I think you should use a channel. If the communication is between two parities 
then there is no need to close the channel after sending the result as the are 
not other parties to inform that they missed the message. 

-- 
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 version 1.9 - not able to build

[Dave Cheney]

Errors like these are usually caused by either having multiple versions of Go 
installed on your system, or overwriting one version of Go with another.

how did you upgrade Go on this machine? How was the previous version installed?

-- 
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 version 1.9 - not able to build

[desaiabhijit]

Mac is upgraded to 1.9.2 version and suddenly not able to build the simple 
program

package main


import (

"fmt"

)


func main() {

fmt.Printf("TEST")

}


Please help

$ go build a.go

# command-line-arguments

flag provided but not defined: -goversion

usage: compile [options] file.go...

  -% debug non-static initializers

  -+ compiling runtime

  -A for bootstrapping, allow 'any' type




go version go1.9.2 darwin/amd64


go env

GOARCH="amd64"

GOBIN=""

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GOOS="darwin"

GOPATH="/Users/iwtx/work"

GORACE=""

GOROOT="/usr/local/go"

GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"

GCCGO="gccgo"

CC="clang"

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 -gno-record-gcc-switches -fno-common"

CXX="clang++"

CGO_ENABLED="1"

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

PKG_CONFIG="pkg-config"

-- 
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: concurrency programing about go

[snmed]

Hi

There are several ways to solve it, here are two of them:

https://play.golang.org/p/wJwkI7HQwv
https://play.golang.org/p/nasUcgBeG4

I prefer the first one, because so I can decide if i want to wait for the 
end of twoprint or not.

Cheers

Am Montag, 30. Oktober 2017 06:43:45 UTC+1 schrieb 28911...@gmail.com:
>
> Yes, you're right.So how to solve it??
>
> 在 2017年10月30日星期一 UTC+8下午12:37:49，Dave Cheney写道：
>>
>> Hello. I’m guessing that your tried calling twoprint(), but you’ve 
>> probably found that nothing is printed to the screen before your program 
>> exits. 
>>
>> Is that correct?
>
>

-- 
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: Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

[dc0d]

BTW currently a private channel with length of 1 is being used and the 
other side must call a function to get the result (with a timeout). This 
way the second signal about closing the channel is not a problem. And we 
see this inside the standard library too, like in the time channel of a 
time.Ticker which will not get closed by the Stop() functions to prevent an 
incorrect notification.

On Monday, October 30, 2017 at 11:22:16 AM UTC+3:30, dc0d wrote:
>
> Problem: After the completion of some task, the task issuer should be 
> informed about the completion/failure of the task - like by using some 
> struct { Result Result, Err error }.
>
> Question: Which mechanism is preferred: using channels or callbacks?
>
> Why the question: IMHO channels are the answer but there is this problem 
> with channels that after sending the result to the channel, if we close it, 
> there would be another signal which notifies the other side about the 
> channel be closed (in _, ok := <-rsultChan; ok will be false).
>

-- 
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] Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

[dc0d]

Problem: After the completion of some task, the task issuer should be 
informed about the completion/failure of the task - like by using some 
struct { Result Result, Err error }.

Question: Which mechanism is preferred: using channels or callbacks?

Why the question: IMHO channels are the answer but there is this problem 
with channels that after sending the result to the channel, if we close it, 
there would be another signal which notifies the other side about the 
channel be closed (in _, ok := <-rsultChan; ok will be false).

-- 
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: select is still a little unfair if there are more than 4 cases?

[Sokolov Yura]

> it would be great to move to pcg.

Why? PCG isn't faster, isn't simpler and isn't better (though not worse either).

-- 
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: select is still a little unfair if there are more than 4 cases?

[Jérôme LAFORGE]

Thx Giovanni, it is clear 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] network programming about go

[2891132love]

I write this code in the follwings:
package main

import (
"fmt"
"net"
"os"
)

func main() {
service := ":5000"
tcpAddr, err := net.ResolveTCPAddr("tcp", service)
checkError(err)
listener, err := net.ListenTCP("tcp", tcpAddr)
checkError(err)
for i := 0; i < 10; i++ {
conn, err := listener.Accept()
if err != nil {
continue
}
handleClient(conn)
conn.Close()
}
}
func handleClient(conn net.Conn) {
var buf [512]byte
for {
n, err := conn.Read(buf[0:])
if err != nil {
return
}
rAddr := conn.RemoteAddr()
fmt.Println("receive from client", rAddr.String(), string(buf[0:n]))
_, err2 := conn.Write([]byte("welcome client!"))
if err2 != nil {
return
}
}
}
func checkError(err error) {
if err != nil {
fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
os.Exit(1)
}
}


I try to run it in Sublime Text3 but it has no reaction and I try to run it 
in running windows, it shows:
fatal error: lsiten tcp:5000:bind:Only one usage of each socket 
address(protocol/network address/port) is normally permitted.exit status 1

-- 
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] Is there a way or lib to read a binary into a sturct{len int32;data [len]int32}

[hui zhang]

type variastrt struct {
len int32
data []int32  //  data length = len   [len]int32
}

Is there a way or lib to read a binary into a this structure in one line 
code?

how about more complicate struct ?
type complicatestrt struct {
  len int32
  strData []variastrt
}

-- 
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: select is still a little unfair if there are more than 4 cases?

[Michael Jones]

it would be great to move to pcg. careful implementation here:

https://github.com/MichaelTJones/pcg

extensive use for quite a while

On Sun, Oct 29, 2017 at 10:11 AM,  wrote:

> Il giorno domenica 29 ottobre 2017 17:49:39 UTC+1, T L ha scritto:
>>
>>
>>
>> On Sunday, October 29, 2017 at 3:47:43 AM UTC-4, Sokolov Yura wrote:
>>>
>>> Why no one writes Go's version they've tested with?
>>>
>>> HEAD of master branch is uniform?
>>>
>>
>> 1.9.2 is a little unfair. Tip is fair.
>>
>
> Let me recap what happened.
>
> At some point during the 1.9 cycle, fastrandn() was changed to use a
> multiplication+shift for doing a reduction, which is much faster and has
> introduces zero bias compared to a modulus which is much slower and
> potentially adds a little bias.
>
> Unfortunately, the underlying generator used by fastrand (a LFSR) was very
> weak and had a lot of bias in the high bits. Low bits were "acceptable" so
> using modulus was kind of acceptable in fastrandn(), and select was "fair
> enough". After switching to multiplication, select became were unfair.
> After this was reported, the generator was changed on tip to use
> xorshift32+ with 64-bit state, which is much much stronger (passes
> SmallCrush, for instance), and thus fixes the unfairness in select for
> good, whatever reduction is used. To avoid regressions, the new generator
> wasn't backported to 1.9.2, but instead the fastrandn() multiplication
> change was reverted.
>
> So to recap:
>
> up to 1.8: LFSR+modulus => select is "fair enough"
> 1.9.0 / 1.9.1: LFSR+multiplication => select is very unfair
> 1.9.2: LFSR+modulus => select is "fair enough" (same as 1.8)
> tip: xorshift32+multiplication => select is fair
>
> Giovanni
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

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