[go-nuts] Re: Is json.Marshal deterministic?
> I don't know if JSON serialization is deterministic, but I know a couple
> of cases when it is not.
> If the type or some type inside it has a custom JSON marshaller (method
> MarshalJSON), then if that function's output is not deterministic, the
> whole JSON for the type is not deterministic.
Obviously.
> Another common pitfall with JSON: nil vs empty slice. E.g. []string{} is
> encoded as "[]", while []string(nil) is encoded as "null", while they both
> mean an empty slice in Go
I'm not sure I follow. I was under the impression that the empty array
and nil are distinct values in Go, even though many functions treat them
the same.
-- 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/87ttk8qizr.fsf%40pirx.irif.fr.
[go-nuts] Is json.Marshal deterministic?
Hi, Suppose that I call json.Marshal on two structures that are deep equal, or on the same structure at different times. Are the outputs guaranteed to be bytewise identical? (The reason I'm asking is that I'm sending JSON over HTTP, and I need to know whether it is correct to send a strong ETag with my reply even though I'm generating new JSON every time.) Thanks, -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87h6gag1qk.fsf%40pirx.irif.fr.
[go-nuts] Re: Windows Go programs not running under Wine anymore.
> Apparently wine 9.0 rc2 includes bcryptprimitives.dll now (I tested on it > and it did work). Thanks for the hint, it apparently works with 8.19 (wine-development in Debian). -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87bkaozbgb.fsf%40pirx.irif.fr.
[go-nuts] Re: Windows Go programs not running under Wine anymore.
> Apparently the change below broke Windows apps when running under Wine as > it made bcryptprimitives.dll a hard requirement now and this dll is not > bundled with Wine. This is true even for programs that do not use it all > (like a simple "hello world" program). > > https://github.com/golang/go/commit/693def151adff1af707d82d28f55dba81ceb08e1 I can confirm this issue. I think it's a significant issue, since it's convenient to be able to quickly run Windows tests without the hassle of booting a Windows VM. Could you please file a bug? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87fs00zkvr.fsf%40pirx.irif.fr.
[go-nuts] Re: Upgradable RLock
>> I took some time to put this to a test. The Go program here >> https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the >> lock - but a large % of runtime holding the lock. > Thanks for the benchmark. You're right: if you have hundreds of > goroutines doing nothing but acquiring a read lock, then an RWMutex > can be faster. They key there is that there are always multiple > goroutines waiting for the lock. Could you please explain that? You previously implied that the required atomic operation is going to make the difference between the two kinds of mutex irrelevant, why does the argument not apply here? Thanks, -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87tu00b8b3.fsf%40pirx.irif.fr.
[go-nuts] Re: Which websockets implementation
> By stdlib, you presumably mean the x/net/websocket package, Careful with this library, it's not quite correct. Websocket is a frame-oriented protocol, while x/net/websocket implements a simplistic API that does not always preserve frame boundaries. Correct implementations include: https://github.com/gorilla/websocket https://github.com/nhooyr/websocket -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87sfhaajyb.fsf%40pirx.irif.fr.
[go-nuts] net/netip and UDP servers
I'm writing a simple UDP server, and I'm trying to use the new net/netip
data types. My main loop starts as follows:
for {
n, a, err := sock.ReadFrom(buf)
if err != nil {
log.Printf("ReadFrom: %v", err)
time.Sleep(100 * time.Millisecond)
continue
}
aa, ok := a.(*net.UDPAddr)
if !ok {
log.Println("not a UDP address (this shouldn't happen)")
continue
}
ip, ok := netip.AddrFromSlice(aa.IP)
if !ok {
log.Println("AddrFromSlice not ok")
continue
}
ip = ip.Unmap()
addr := netip.AddrPortFrom(ip, uint16(aa.Port))
That seems extremely verbose. Am I doing something wrong?
-- 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/878rjrbb07.fsf%40pirx.irif.fr.
[go-nuts] Re: Go routine context
> Very interesting article came out recently. > https://www.infoq.com/articles/java-virtual-threads/ Interesting article, thanks for the pointer. > it has implications for the Go context discussion and the author makes > a very good case as to why using the thread local to hold the > context - rather than coloring every method in the chain is a better > approach. I didn't read that in the article, but then I may be missing something. My takeaway is that: - with M:N threds, one must be careful to not stash too much data in thread local storage, since there may be large numbers of threads; - with M:N threads, there's no need to do use thread pools; in the absence of thread pools, thread-local storage is more useful, since there's no risk of leaking thread-local data to a different task. This implies to me that there is an interesting tradeoff, but does not by itself argue against Go's design. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87k05jpqae.fsf%40pirx.irif.fr.
[go-nuts] Re: Managing perpetually running goroutines
> I want to be able to terminate each worker independently of others
> (i.e. close on worker, wait for it to finish its tasks, but allow
> other workers to run if they haven't been signalled to stop).
The solution I use is to have each worker take two parameters:
- a channel that will be closed by the main program in order to signal
that the worker should terminate;
- a channel that will be closd by the worker when it's done.
So the worker looks like this:
func worker(terminate chan struct{}, done chan struct{}) {
defer close(done)
outer:
for {
work();
select {
case <-done: break outer
default:
}
}
}
and the main program looks like this:
terminate := make(chan struct{})
done := make(chan struct{})
go worker(terminate, done)
...
close(terminate)
<-done
The terminate channel can be replaced by a context, which is useful if
you have a tree of workers to manage:
terminate, terminateFn := context.WithCancel(context.Background())
done := make(chan struct{})
go worker(terminate, done)
...
terminateFn()
<-done
Or perhaps with a timeout in case a worker gets stuck:
terminate, terminateFn := context.WithCancel(context.Background())
done := make(chan struct{})
go worker(terminate, done)
...
terminateFn()
timeout := time.NewTimer(5 * time.Second)
select {
case <-done:
timeout.Cancel()
case <-timeout.C:
log.Println("Worker failed to terminate within 5s")
}
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/87y28jnobp.fsf%40pirx.irif.fr.
[go-nuts] How to version a module that's not providing a stable API?
Hi, I'm working on an application (a thing with a "main" function) that has a user-visible version. Since the internal modules of the project do not have any backwards compatibility between versions, I've been tagging releases with versions that the Go tools won't recognise (galene-0.3 instead of v0.3). How would I tag the versions so that people can depend on my code in their projects without implying any form of backwards compatibility when the user-visible version goes beyond 1.0? I'm thinking of shifting the user-visible version number one position to the right, e.g. galene-0.4 -> v0.0.4 galene-1.0 -> v0.1.0 Is that the recommended usage, or are there better ways to achieve 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87mtvx47dw.fsf%40pirx.irif.fr.
[go-nuts] Re: How to use atomic_int in cgo?
> For example, on the Go side write
> type chanToUse struct {
> c chan int
> }
> //export MyGoFunction
> func MyGoFunction(u unsafe.Pointer, val int) {
> cu = (*chanToUse)(u)
> cu.c <- val
> }
Why the struct? Couldn't you just pass a pointer to a chan?
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/87r1ldi96g.fsf%40pirx.irif.fr.
Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft
>> Could you please give an example of the proposed syntax?
> func F[T constraints.Integer]() {
> switch T {
> case int:
> case int8:
> }
> }
Makes perfect sense, thanks.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/877dtofltb.wl-jch%40irif.fr.
[go-nuts] Re: [ generics] Moving forward with the generics design draft
> We’re going to permit type switches on type parameters that have type > lists, without the “.(type)” syntax. The “(.type)” syntax exists to > clarify code like “switch v := x.(type)”. Could you please give an example of the proposed syntax? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87sgcdowez.fsf%40pirx.irif.fr.
Re: [go-nuts] How do you write "member" with the proposed generics draft?
Axel Wagner writes: > I feel like https://go2goplay.golang.org/p/RLn9BXjU1OR is a better > compromise than having two functions. > Prolly. Except OP specifically asked about "not that" :) Agreed on both counts. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87k0ye5mnm.wl-jch%40irif.fr.
[go-nuts] How do you write "member" with the proposed generics draft?
I'd be grateful if people could give me an example to help me understand
the generics draft. Suppose I've got these two functions:
func MemberInt(x int, a []int) bool {
for _, v := range a {
if v == x {
return true
}
}
return false
}
func MemberIP(x net.IP, a []net.IP) bool {
for _, v := range a {
if v.Equal(x) {
return true
}
}
return false
}
I can see how to write a generic "Member" function that takes an extra
equality predicate; but is there a way to write a function that
generalises both functions above without requiring the extra parameter?
Thanks.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/87v9hytrcn.fsf%40pirx.irif.fr.
[go-nuts] Re: No http.ServeStream() ?
>> Wondering why there's no http.ServeStream() API to do chunked
>> transfer-encoding (or the http2 equivalent), in addition to the nice
>> features of ServeContent()...
Uh-huh. It would be nice to be able to use the If-None-Match logic for
unseekable strings.
> Maybe because the current ServeHTTP does the chunked transfer-encoding when
> Content-Length is not set, and the Writes are more than the predefined
> buffer length?
I could be wrong, but I think that the Content-Length is always known in
ServeContent:
size, err := content.Seek(0, io.SeekEnd)
if err != nil {
return 0, errSeeker
}
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/87d05b56lb.fsf%40pirx.irif.fr.
[go-nuts] Re: Why isn't there strings.reverse("str") function?
> One reason for not implementing it in the standard library is that there > are many possible implementations. Do you want to reverse combining > character sequences for example? Unicode is a complex beast and I suspect > that reversing a string rune-by-rune may easily break important > semantics. What Roger is saying is that taking the sequence « e - combining acute » and reversing it rune-by-rune yields a sequence starting with a combining character, which doesn't make a lot of sense sense. > Is it even possible to do it correctly in general ? Depends how you define correct, obviously. If you want to ensure it's invariant with respect to compatibility equivalence, you'll need to normalise first (due to some compatibility characters normalising in weird ways, for example U+0133 normalises to (U+0069, U+006A)). I'm not sure if plain equivalence has similar pathologies. > Unicode is a complex beast Granted. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87imk6yzrt.fsf%40pirx.irif.fr.
[go-nuts] Proposed additions to maphash documentation
It would be helpful if the introduction to the maphash package immediately stated that it produces 64-bit values, and perhaps restate the fact that the value can be safely reduced using bit masking (already there at the Sum64 method). I'm not sure what is the purpose of the BlockSize method -- why is the block size relevant to the package user? At the very least, the doc should mention that Size is the value that the user wants. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87mu9rzj98.wl-jch%40irif.fr.
[go-nuts] Go-1.14 irreproducibly fails with mlock failure
The first time I ran go-1.14rc1 on a stock Debian system, I got: runtime: mlock of signal stack failed: 12 runtime: increase the mlock limit (ulimit -l) or runtime: update your kernel to 5.3.15+, 5.4.2+, or 5.5+ fatal error: mlock failed ulimit -l is at 64, which is also the hard limit. After opening a new shell, I can no longer reproduce the issue -- everything appears to be working fine. Still, I find this heisenbug somewhat disturbing. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87o8u7zjfl.wl-jch%40irif.fr.
[go-nuts] Re: why in source of go compiler, initialize a *gc.Node with the help of a temp struct x? can't we initialize it directly?
> See https://golang.org/cl/36022. There's a terrifying sort of beauty to it, like a tarantula or a snake. (And it most certainly deserves a comment in the source.) -- 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] Re: Failed iterator proposals?
>> for i:=c.Iterator();i.HasNext(); {
>> v := i.Next()
>> }
> I don't like the eyeball friction.
Could you please explain what 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.
[go-nuts] Re: Cgo: using syscall.Select
> You could also take a look > at https://godoc.org/github.com/mailru/easygo/netpoll I don't have a net.Conn, just a raw file descriptor. -- 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.
Re: [go-nuts] Cgo: using syscall.Select
> If you do this in Go, you should use golang.org/x/sys/unix package > rather than the syscall package. What's the advantage? (In this particular case, not in general.) > But since you have to call C anyhow, I would suggest just doing it in C. Yeah, I guess it's simpler. > There isn't any way to hook into Go's scheduler for this. Go's > scheduler provides no mechanism for waiting for data without reading > the data. I suppose it makes sense, the operation might be difficult to implement in a hypothetical scheduler that's layered over mainframe-style async operations. Thanks for your reply, -- 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] Cgo: using syscall.Select
I'm interfacing with a C library that expects to do its own I/O, but
wants to be called after a file descriptor is ready for read. My code
currently looks roughly like this:
var fdset syscall.FdSet
var bits = unsafe.Sizeof(fdset.Bits[0]) * 8
fdset.Bits[uintptr(fd)/bits] |= (1 << (fd % bits))
var ctv C.struct_timeval
C.gettimeout()
tv := syscall.Timeval{int64(ctv.tv_sec), int64(ctv.tv_usec)}
n, err := syscall.Select(int(fd + 1), , nil, nil, )
if n < 0 {
return err
}
rc, err := C.dostuff(fd)
if(rc < 0) {
return err
}
I'm bothered by two things:
- the way I access the syscall.FdSet feels like an unportable hack;
- I'd much rather hook into Go's scheduler then burn a thread on
sleeping in select.
Is the above the correct way to interface with the C library, or is
there a better way?
--
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: Does the CanSet and CanAddr methods of a reflect.Value always return the same result?
>> https://play.golang.org/p/f_qy1ZI56w7 > Got it, thanks. It took me a while. I think the point Ian is making is that an unexported field is not CanSet. -- 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: I don't know about callbacks in Golang
> Callbacks are rarely used in Go's ecosystem. https://golang.org/pkg/sort/#Slice https://golang.org/pkg/sync/#Map.Range -- 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: Tcp connection reset
> i need to reset the tcp connection manually , if one request come from > ipLayer.SrcIP > = 10.2.3.1 then i need to sent the reset connection packet I could be wrong, but I don't think the sockets API makes this possible -- RST segments are normally only sent by the kernel upon receiving a segment that doesn't match the current state of the connection. Since Go uses the kernel sockets support, there's probably nothing that can be done about this with Go. You'll need to work at a lower layer: - the firewall code is normally able to send RST segments; under Linux, you can achieve that with iptables ... -p tcp ... -j REJECT --reject-with tcp-reset - you could probably use raw sockets to inject RST segments, but that would require building your own TCP header and running your program as root. It's probably easier to interface with the firewall. As Jesper said, it would be helfpul if you told us what you're trying to achieve. -- 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] Re: [Question]: Are there any plans to teach the compiler to emit VEX encoded instructions ?
>> I believe using the non-destructive 3 operand form will help a lot in >> reducing the size of binaries. > We would have to make a clear decision as to the oldest amd64 > processor we wanted to support. Right now I believe we support all > amd64 processors. Are we ready to give up on old ones? I think the OP was speaking about the AVX and AVX2 instruction set extensions, which were introduced in 2011 and 2013 respectively. There's still a lot of pre-AVX hardware being used (including every single Atom processor), I think it would be way premature to require AVX. I doubt there'd be any significant benefit to be gained from the instructions introduced before AVX/AVX2 (except for crypto, which already uses cpuid detection). I'd love to be proved wrong, though. -- 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] Re: Cannot take the adress of.....
> You can't take the address of the return value of a function or a
> conversion (which is conceptually just a function) because it doesn't
> have a location in memory and thus doesn't have an address.
I've never understood the reason for this limitation. I'd expect the
compiler to box any value that I take the address of, i.e. automatically
convert
p := ()
into
x := f()
p :=
Another way to put it is that I don't understand the disymmetry between
p := {}
which works, and
p := &5
which doesn't.
-- 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] Re: Go on MIPS32
> cgo is not go. The speed of system calls is similar though -- 110 microseconds for a UDP send/receive pair over loopback. As compared to a single core of a 2.4GHz laptop, the MIPS nodes are: - 10 to 20 times slower on integer code; - 30 times slower on small UDP packets over loopback; - 30 times slower on Cgo calls; - almost 1000 times slower on floating point (softfloat). I haven't measured TCP throughput yet. While I find the benchmarks somewhat disappointing, what that means is that the MIPS nodes are more than fast enough for my use case (some simple network monitoring), so many thanks to whoever did the MIPS32 and softfloat support. Or perhaps not, now I no longer have any excuse to buy myself a bunch of Beaglebones. While I have everyone's ear -- does anyone know why 1.10 doesn't attempt to fill the delay slots? The code is there, but it's disabled. -- 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 on MIPS32
BenchmarkGoCall 29.00 ns/op BenchmarkCgoCall 100 2302 ns/op 2 microseconds to call into C. Ouch. (That's on a 680MHz 24Kc core with 32kB data cache. I'm not complaining, merely noticing.) -- 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] Okay to use mmap ?
Hi, Is it okay to use syscall.Mmap to allocate large amounts of memory, or will it conflict with Go's memory allocator? -- 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] Re: About golang.org/x/net/prox and cancellation
> unlike net.Dialer, there is no DialContext method for proxy.Dialer. That turns out to be issue #19354. -- 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] About golang.org/x/net/prox and cancellation
Hi, I'm using golang.org/x/net/proxy, and I've run into an issue: there appears to be no way to cancel a (*proxy.Dialer).Dial in progress -- unlike net.Dialer, there is no DialContext method for proxy.Dialer. Any idea for a workaround? (By the way, since net.Dial is a struct, not an interface, my code ends up pushing around parameters of type proxy.Dial, which I find weird. Not problematic, just weird.) -- 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] Re: net.Pipe doesn't support deadlines
> Which version of Go are you using? 1.9.3. > https://github.com/golang/go/blob/master/src/net/pipe.go#L224 Excellent, thanks. (In case anyone is interested -- wrapping net.Pipe in order to avoid the errors took all of five minutes.) -- 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] net.Pipe doesn't support deadlines
In net/pipe.go, there's this code:
func (p *pipe) SetReadDeadline(t time.Time) error {
return {...}
}
This breaks my code, which uses timeouts and dutifully checks for
errors.
I guess I have three solutions:
1. remove the error checking in my code;
2. wrap net.Pipe within my own struct that noops the deadline methods;
3. bother the Go developers to change net.Pipe to ignore deadlines.
Any advice?
--
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: f*ck you, golang
> I was meant to be a successful C++/Java programmer, now that is ruined > forever. [...] > My life is ruined and it's on you. You can only blame yourself. You should have studied for the exam rather than doing extra-curricular stuff. -- 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 memory usage
> It depends entirely on your program. The simplest way to think about > it is that the runtime imposes an overhead on the memory that your > program allocates for its own data structures. If you think of that > overhead as 10%, you won't be very far wrong. How does that fit with GOGC being 100% by default? -- 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] Re: Go memory usage
> It depends entirely on your program. The simplest way to think about > it is that the runtime imposes an overhead on the memory that your > program allocates for its own data structures. If you think of that > overhead as 10%, you won't be very far wrong. How does that fit with GOGC being 100% by default? -- 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] Re: Running a Go server in a chroot
> you need /usr/local/go/lib/time/zoneinfo.zip. time.LoadLocation is using > it. Also /usr/local/go/lib/time/ has a script to refresh timezones. It turns out that copying /etc/localtime into the chroot was enough. Thanks to the person who helped me by private mail (he'll know who he is). -- 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] Running a Go server in a chroot
Hi, I'm running a statically linked (CGO_ENABLED=0) Go network server in a chroot under Linux. The chroot is completely empty (except for the server's data files), yet, to my surprise, the only issue I'm seeing is that the timezone is wrong. So two questions, perhaps three: 1. Which file(s) do I copy into the chroot in order to have the correct timezone ? 2. Any other files or device nodes I should copy into the chroot? 3. Am I cargo-culting, should I use a different setup instead? I'm not too concerned about security, since the host is a VM connected to our DMZ, just reasonably paranoid. Thanks, -- 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] Sanitising a UTF-8 string
I'm probably missing something obvious, but I've looked through the standard library to no avail. How do I sanitise a []byte to make sure it's a UTF-8 string by replacing all incorrect sequences by the replacement character (or whatever)? I've found unicode/utf8.Valid, which tells me if a []byte is a UTF-8 string, but I don't see a convenient function that I can use on the string before I pass it to the frontend that requires well-formed UTF-8. Thanks, -- 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] Re: slice of pointer of struct vs slice of struct
> I have started to use non pointer slices much more as of late. > Every time I bother measuring it is always faster and it is better for the > GC (usually, caveats apply). So do I. I was just pointing out a caveat that tripped me a couple times. > It also, perhaps naively, feels safer... :) Not if your structs contain a Mutex. -- 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] Re: slice of pointer of struct vs slice of struct
>> What size of T affects is appending/inserting/deleting items to/from >> the slice. If one passes around a value of type []T, those operations >> are probably performed on the value. > On the flip side, []*T will be less cache/TLB/GC friendly than > []T, unless T is much larger than a ptr. On the edge side, []T cannot be easily ranged over in a mutable way: https://play.golang.org/p/6kpQWkLQEW -- 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] Re: Panic recovery and mutex lock question
> I guess I dont understand why you would want the lock entirely for the
> entire execution of the function until the defer.
You can get the effect of block-scoped defers by using a local anonymous
function:
func f(a *A) {
func() {
a.mu.Lock()
defer a.mu.Lock()
do_stuff_with_a_locked(a)
}()
do_stuff_with_a_unlocked(a)
}
Perhaps more convincing:
func f(as []A) {
for _, a := range as {
func() {
a.mu.Lock()
defer a.mu.Unlock()
do_stuff(a)
}()
}
}
-- 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] Re: afpacket does not get GRE tunneled packets?
This is not Go-specific, I hope I'm not breaking some unwritten rule by
replying.
> I just figured this out. I need to manually set the NIC to promiscuous
> mode.
> Now the question is, is there a way to set the NIC to promiscuous mode
> in code, like in pcap.openlive?
You want to call sysctl(SIOCGIFFLAGS), set the IFF_PROMISC flag in
ifr.ifr_flags, and pass the results back to sysctl(SIOCSIFFLAGS).
I guess one could also use rtnetlink, if one were so inclined.
If I were you, I'd cheat:
ifname := "eth0"
cmd := exec.Command("ip", "link", "set", "dev", ifname, "promisc", "on")
err := cmd.Run()
-- 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] Re: Do closures cons?
> Depends on what your profiling is telling you. The trouble is -- I have no idea what is the impact of small allocations. I've managed to eliminate most useless large allocations (the amount of data consed used to be twice the amount of data processed, it's now on the order of 103%), which has had a measurable effect on the process's RSS. But how much am I paying for large numbers of small allocations that show up in -alloc_objects? I have no idea. -- 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] Re: Do closures cons?
> A method value, on the other hand, will allocate memory in some cases, > as it may need to hold a copy of the value whose method will be > invoked. Even if the method takes a pointer receiver? -- 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] Implementing futures with channels [was: How to pass a value...]
> The answer depends on whether you have just one value or many. For a single
> value (sometimes known as a "future"), I tend to pair a chan of struct{}
> with a value to be set. To make the value available, set it, then close the
> channel. Readers wait on the channel, then read the value.
That's an interesting idea. Surprisingly enough, it turns out to be
only slightly slower than the obvious implementation with a mutex, and
(even more suprisignly) actually faster when using hardware threading.
This is on a 2-core hyperthreaded SandyBridge (4 hardware threads):
BenchmarkMutexFuture1 22.2 ns/op
BenchmarkMutexFuture-2 500039.9 ns/op
BenchmarkMutexFuture-4 200086.0 ns/op
BenchmarkAtomicFuture 27.01 ns/op
BenchmarkAtomicFuture-2 53.69 ns/op
BenchmarkAtomicFuture-4 10 2.69 ns/op
BenchmarkChannelFuture 500029.7 ns/op
BenchmarkChannelFuture-2500054.6 ns/op
BenchmarkChannelFuture-4200064.4 ns/op
Code here: https://play.golang.org/p/Wm71o50HJ8
-- 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] Do closures cons?
I was about to do something like that:
var p *P
...
otherpackage.f(func(data []byte) {
a := p.x + p.y * 42 + p.someothercomplicatedstuff
p.g(data, a)
}
(Yeah, I know. I dislike callbacks too, but I'm pretty much stuck in
this particular case since Go doesn't do mutually dependent packages.)
I then realised that I was building a closure on each iteration, and
I wasn't sure if the compiler would be smart enough to lift the creation
of the closure out of a rather complex loop, so I replaced this with :
func (p *P) gprime(data []byte {
a := p.x + p.y * 42 + p.someothercomplicatedstuff
p.g(data, a)
}
...
otherpackage.f(p.gprime)
Now this code was originally in an inner loop, but I've since restructured
it and I can no longer easily profile it. But I'm still curious:
1. is it expected that passing a function obtained from a method
doesn't cons, and is this likely to remain the case in future
versions of the compiler?
2. would the closure in my first code sample cons on every loop
iteration, or would the compiler optimise it away? The loop spans
multiple functions and involves some channel communication, so it's
not entirely trivial to do the lifting.
3. am I worrying too much?
Thanks,
-- 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] defer go [was: A few go 2 suggestions]
> 1. "defer go" extend defers to work on goroutine exit with mechanism just
> like defer, but if we say "defer go f()"
> instead of "defer f()" then we run on goroutine exit. Very big gains for
> scaling here IMHO.
If I read the language specification right, goroutines have no identity:
a goroutine is about doing something, and the something is not bound to
any particular context. For example, if you do
go func() {
f()
go g()
}()
this is completely equivalent to
go func() {
f()
g()
} ()
in the sense that there is no observable difference betwen the two, and
a Sufficiently Smart Compiler could in principle optimise the former
into the latter.
Is that an important property to have? Frankly, I don't know.
-- 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] Latency profiling
Hi, I've got a CPU-bound function that is not called very frequently, and hence doesn't appear prominently in the CPU profile, but I'm guessing that it takes a significant time to run (on the order of tens of milliseconds), and hence increases the latency of the calling goroutine. I don't see anything in pprof to give the average and maximum time spent in a given function, let alone to get the list of functions that have the highest maximum CPU time per invocation. Not a big deal, I'm going to instrument the function manually, but I'm wondering if I'm missing something. Thanks, -- 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] Re: bufio.Writer and timeouts
> Hmm maybe I misunderstood your use case. I thought you were basically > setting a fixed write duration via SetWriteDeadline() before each Write() > call, in which case the same treatment probably should be done for Flush(). I'm already doing 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.
[go-nuts] Re: bufio.Writer and timeouts
> Is extending the deadline right before flushing an option? No. Before the Flush (or the Write) times out, I don't know that this particular peer is congested, and hence I have no reason to reschedule requests queued to this peer on a different connection. -- 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] Re: bufio.Writer and timeouts
> bufio.Writer is about 200 lines, and you probably don't even need all > of them. Just copy it and modify it for your purposes. Ok, thanks. -- 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] bufio.Writer and timeouts
Hi, I've got a bufio.Writer which is wrapping a net.TCPConn. Once in a while, Flush() will trigger a write timeout (set with SetWriteDeadline on the underlying connection), in which case I'd like to reschedule some requests on a different connection, and then restart the Flush() with a more relaxed timeout. Looking at the sources of bufio.Writer.Flush(), I don't see how I can get that to work. The first timeout sets the b.err field to a non-nil value, and as far as I can tell this field will never get cleared. Is there a way to deal gracefully with timeouts without rewriting bufio.Writer from scratch? Thanks, -- 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] Re: Experience using Go for a student projet
> suggests you should move the wg.Add(1) out of the Goroutine from here: [...] > to there Thanks, that's an actual bug. > * Do you happen to know about the context package? It seems like a lot of > the closedown can happen if you recast part of the system as contexts and > cancel those 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] Re: Experience using Go for a student projet
> How did your students adjust to working with the GOPATH?
No issue at all. I told them to create a directory under ~/go/src, and
that was it.
> It seems to cause some people trouble.
In my experience, undergraduate students accept pretty much anything if
the instructions you give them are clear and deterministic ("write
`public static void main(String[] args)' at the beginning of the
program") and the reason is due to a major force ("otherwise the
compiler will reject your code"). It's the more experienced programmers
who tend to complain if the user experience differs too much from what
they're used to.
(Aside: what undergrads dislike is software that has too many different
failure modes, and which they therefore perceive as non-deterministic.
For example, some students develop a phobia against git -- "it goes
wrong differently each time, and then I have to ask for help". End of
aside.)
-- 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] Re: Experience using Go for a student projet
> I glanced at babelweb2 (https://github.com/Vivena/babelweb2/). A code > review would be useful. For example, from parser/parser.go: Thanks for the review. As I've mentioned, neither the students nor me had any significant experience with Go, so we were learning as we went along. If you happen to have another idle moment, a review of the channel structure will be welcome. 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] Experience using Go for a student projet
Dear all,
I've just finished supervising three fourth year students doing
a month-long summer project in Go. I thought some of you might be
interested in my conclusions.
The students were decent C programmers but had more experience with Java
(and I am not an experienced Go programmer myself). After a few days of
frustration, they had accepted that one does not build complex class
hierarchies in Go, and that one should just start writing code straight
away. They did attempt to write complex frameworks for channel
communication, I blame Java.
Surprisingly enough, they had no issue at all with = vs. :=.
They did find slices difficult to grasp. In particular, they thought
that slices alleviated the need for circular buffers, which obviously
caused massive memory leaks. Half an hour drawing boxes on a blackboard
solved this particular problem.
They did find the behavious of defer confusing -- they expected it to be
lexically scoped. They initially wrote code such as the following:
for {
conn, err = net.Dial(...)
defer conn.Close()
...
}
and were surprised that it caused a descriptor leak -- they were
expecting the defer to execute at the end of the enclosing block.
They did find it surprising that multiple goroutines could write to the
same channel at the same time. In order to implement a fan-in, they
initially built a slice of channels and did a reflect.Select in the
reader. They were delighted to learn that they could use a single
channel and no select was necessary.
One of them started using closures straight away, and even stored
closures in dictionaries. (They had had some exposure to Caml.)
To my surprise, they wrote a fair amount of weakly-typed code (using
interface{}). Some of it was simulating generics, so I asked them to
write it monomorphically (the collection structure they implemented is
only used at one type in this particular program). Much of it, however,
was for good reasons, so perhaps this is a consequence of the problem
being solved here.
Oh -- and I never managed to convince them that a Makefile is not needed.
In case you're interested, the code is at
https://github.com/Vivena/babelweb2
and an online demo (somewhat boring right now) is running at
http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/
-- 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] Re: bufio.Scanner and partial reads
>> Do I have a guarantee that the final \n will be passed to my custom >> scan function and the result passed to the Scan function even if the >> connection hangs just after the \n? > Yes (assuming the underlying Reader returns the final \n). >> Do similar properties hold for bufio.Reader (i.e., that the final octet >> will be passed to the client even if the connection hangs)? > Yes (assuming the underlying Reader returns the octet). Thanks, Ian, that's helpful. -- 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] bufio.Scanner and partial reads
Hi, I cannot find anything in the documentation about how bufio.Scanner behaves when the underlying io.Reader does partial reads. I'm using a Scanner to parse a stream of tokens that arrives over a TCP socket. The stream is a sequence of lines terminated by \n. Do I have a guarantee that the final \n will be passed to my custom scan function and the result passed to the Scan function even if the connection hangs just after the \n? Do similar properties hold for bufio.Reader (i.e., that the final octet will be passed to the client even if the connection hangs)? Shall I submit an issue? Thanks, -- 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.
