Thank you very much.
在 2018年3月15日星期四 UTC+8上午7:27:40，Subbu M写道：
>
> Hi,
>
> First Lock - starts the Lock and executes the following statements until
> next Mutex functions are called.
> Here Sync.Mutex I is gloabal, called Unlock in function f().
> As said second lock starts after function f() is
since the lack of generics i am trying to avoid interface{} as much as
possible.
On Thursday, March 15, 2018 at 1:03:14 AM UTC+2, matthe...@gmail.com wrote:
>
> Hi Sotirios,
>
> Why not something like this?
>
> // Stops and returns if any error is encountered by a work function,
> otherwise retu
Hey folks,
I'm trying to figure out how to cancel reading from stdin programmatically.
Basically the same way that ctrl+d works on OSX.
I would have thought this would work, but this program will just run
forever:
package main
import (
"io/ioutil"
"os"
"time"
)
func main() {
go func()
Hi,
I am looking to create a gofix for one of my projects. I thought of
importing the code in
https://github.com/golang/go/tree/master/src/cmd/fix so that I could
simply write a plugin, build a binary and give it to people who import
my code.
However, I do not see any exported symbols in this cod
The philosophy of Go (in my interpretation) is that exported and unexported
identifiers are only used to describe the public interface of a package and
to guard against certain programming errors; they are not intended to be a
security measure or hide or protect any information. In fact, it's po
If it helps, you can set deadlines on *os.File now, as of Go 1.10:
https://play.golang.org/p/h3Pg9Ql0CMB
I don't see a way to cancel without deciding the deadline in advance though.
On 15 March 2018 at 08:40, Matt Mueller wrote:
> Hey folks,
>
> I'm trying to figure out how to cancel reading
You might be interested to look at
https://godoc.org/github.com/juju/utils/parallel#Run, a slightly
simpler approach to the same issue, and just about as general, I
think.
On 15 March 2018 at 08:19, Sotirios Mantziaris wrote:
> since the lack of generics i am trying to avoid interface{} as much a
interesting, but it does not do the same as parwork.
parwork set's up a fork-join pipeline which processes the work of channels.
Run does limit functions run in parallel.
On Thursday, March 15, 2018 at 2:53:36 PM UTC+2, rog wrote:
>
> You might be interested to look at
> https://godoc.org/github.
On Monday, February 6, 2017 at 7:43:33 AM UTC-5, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote:
>>
>>
>>
>> On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote:
>>>
>>>
>>>
>>> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
On Thursday, March 15, 2018 at 10:09:36 AM UTC-4, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 7:43:33 AM UTC-5, T L wrote:
>>
>>
>>
>> On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote:
>>>
>>>
>>>
>>> On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote:
O
when evacuate oldbucket, go will migrate the data to a new position.
and i found it used X and Y as two bucket where Xi equal the old index in
h.oldbuckets and Yi equal Xi plus newbit
suppose the length of oldbuckets is 8 ， and the hash of a key is 13 (just a
example), then it will be put in t
On Thu, Mar 15, 2018 at 3:29 PM T L wrote:
> I mean "always makes 64-bit words 64-bit aligned on i386 OSes."
AFAIK, that's not the case, ie. not always.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group an
As it turns out, repeatability of "random" experiments is very important,
especially during development.
On Wed, Mar 14, 2018 at 11:35 PM, Andrea Alessandrini
wrote:
>
>
> Il giorno mercoledì 14 marzo 2018 18:38:51 UTC+1, Burak Serdar ha scritto:
>>
>> It is explained here:
>>
>> https://golang.
crypto/rand is another option.
I use the math/rand repeatability to be able to regenerate a picture made
of random elements, where I modify the seed until I’m happy with the result
but later I may need to re-render at different dimensions or with other
parameters.
Matt
On Thursday, March 15,
On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote:
>
>
> On Thu, Mar 15, 2018 at 3:29 PM T L >
> wrote:
>
> > I mean "always makes 64-bit words 64-bit aligned on i386 OSes."
>
> AFAIK, that's not the case, ie. not always.
>
> --
>
> -j
>
But it looks the results from Go playgro
On Thursday, March 15, 2018 at 3:37:51 AM UTC+8, Ian Lance Taylor wrote:
>
>
> Even for TCP, that's an interesting point. I wonder if we should have
> a way to specify a number of bytes to read such that we only allocate
> the []byte when there is something to read.
>
I was thinking a better
Importing malicious code will lead to desaster.
Protecting crypto/rand.Reader somehow from being
tempered with won't help at all. It wouldn't be much
more than cosmetics and feel good security theater.
So why bother?
V.
On Monday, 26 February 2018 19:40:48 UTC+1, Fred Akalin wrote:
>
> crypto/ra
On Thursday, March 15, 2018 at 4:23:41 AM UTC+8, Bakul Shah wrote:
>
>
> You will need 10K*64KiB*2 = 1.22GiB kernel bufferspace at a
> minimum in any case. That is still one datagram's worth of
> buffering per UDP socket so you can still lose some packets.
> This is in addition to any user lev
We've been talking about this
here: https://github.com/golang/go/issues/24160
and here: https://github.com/golang/go/issues/23267
Matt
On Thursday, March 15, 2018 at 11:02:08 AM UTC-5, Volker Dobler wrote:
>
> Importing malicious code will lead to desaster.
>
> Protecting crypto/rand.Reader som
On Thu, Mar 15, 2018 at 1:34 AM, wrote:
>
> when evacuate oldbucket, go will migrate the data to a new position.
>
> and i found it used X and Y as two bucket where Xi equal the old index in
> h.oldbuckets and Yi equal Xi plus newbit
>
> suppose the length of oldbuckets is 8 ， and the hash of a k
On Thu, Mar 15, 2018 at 8:11 AM, T L wrote:
>
> On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote:
>>
>>
>> On Thu, Mar 15, 2018 at 3:29 PM T L wrote:
>>
>> > I mean "always makes 64-bit words 64-bit aligned on i386 OSes."
>>
>> AFAIK, that's not the case, ie. not always.
>>
>> --
On Thu, Mar 15, 2018 at 8:58 AM, Rio wrote:
>
> On Thursday, March 15, 2018 at 3:37:51 AM UTC+8, Ian Lance Taylor wrote:
>>
>>
>> Even for TCP, that's an interesting point. I wonder if we should have
>> a way to specify a number of bytes to read such that we only allocate
>> the []byte when there
What about: "wait, then get a buffer from a pool, and return. client uses
buffer, then restores it." The present API could be used if the input
buffer was presumed to go directly to that pool if not null, or, if a null
pool argument means what i suggest and a new
ReadWithReturnedBufferToSubmitToYou
What about something like:
type TimedReader interface {
TimedRead(out []byte,timeout int) (int,error)
}
so r.TimedRead(buf,0) becomes a non-blocking read?
On Thu, Mar 15, 2018 at 11:23 AM, Michael Jones wrote:
> What about: "wait, then get a buffer from a pool, and return. client uses
> buf
I build my Go project with the -N and -l options, but they only seem to
apply to the top-most package -- imported packages are still optimized.
>From what I can tell, this is because go build isn't propagating the
options that disable optimization as it tracks down and builds dependencies.
I *
On Wed, 14 Mar 2018 12:37:22 -0700 Ian Lance Taylor wrote:
Ian Lance Taylor writes:
> On Wed, Mar 14, 2018 at 11:58 AM, Rio wrote:
> >
> > While implementing a SOCKS proxy in Go, I ran into an issue which is better
> > explained in details by Evan Klitzke in this post
> > https://eklitzke.org/gor
On Friday, March 16, 2018 at 1:05:12 AM UTC+8, Ian Lance Taylor wrote:
>
>
> That's inherently racy, though. It's quite normal to have multiple
> goroutines reading from the same socket. That is awkward if we split
> up WaitRead and Read. Better to have a single wait-then-read
> operation,
This looks like it changed between 1.9.4 and 1.10.
Here’s the documentation:
https://github.com/golang/go/blob/release-branch.go1.10/src/cmd/go/internal/work/build.go#L113-L127
I guess the package patterns thing is new. Try this:
go build -a -x -gcflags=“all=-N -l”
Matt
On Thursday, March 15,
On Thu, Mar 15, 2018 at 12:04 PM, Rio wrote:
>
> On Friday, March 16, 2018 at 1:05:12 AM UTC+8, Ian Lance Taylor wrote:
>>
>>
>> That's inherently racy, though. It's quite normal to have multiple
>> goroutines reading from the same socket. That is awkward if we split
>> up WaitRead and Read. Be
Indeed -- that pattern made the difference.
Thank you.
On Thursday, March 15, 2018 at 2:16:37 PM UTC-5, matthe...@gmail.com wrote:
>
> This looks like it changed between 1.9.4 and 1.10.
>
> Here’s the documentation:
> https://github.com/golang/go/blob/release-branch.go1.10/src/cmd/go/internal/w
On Thursday, March 15, 2018 at 9:46:34 AM UTC-7, Ian Lance Taylor wrote:
>
> On Thu, Mar 15, 2018 at 1:34 AM, >
> wrote:
> >
> > when evacuate oldbucket, go will migrate the data to a new position.
> >
> > and i found it used X and Y as two bucket where Xi equal the old index
> in
> > h.o
https://play.golang.org/p/82Um1jSntBo
Please run with the race detector to see the race.
This race condition arises because private variables are read via reflection by
the fmt package. Is there any elegant way to avoid such a race?
--
Best,
Anmol
--
You received this message because you are
32 matches
Mail list logo
