Re: [go-nuts] Re: RFC: Blog post: How to not use an HTTP router

> > Yet, you still need to work with pattern such as: > */Articles/{aid}/Comments/{cid}/likes*, which AFAIK, httprouter can't > handle (correct me if I'm wrong; one of my research point leads to here: > https://husobee.github.io/golang/url-router/2015/06/15/why-do-all-golang-url-routers-suck.h

Re: [go-nuts] Re: callback for c code wrapper around go function

On Tue, Dec 19, 2017 at 9:40 AM, wrote: > > Thanks for your response, are you referring to something like this: > /* > #include > #include > > void parse(char* err, int status) { > // do work > } > */ > > > > > func Ccomputation(address *C.char) { > > ptr := uintptr(unsafe.Pointer(C.parse)

Re: [go-nuts] bytes.Buffer Grow() doesn't always increase Cap()?

On Tue, Dec 19, 2017 at 11:08 AM, Paul Boyd wrote: > > Sorry if this is a dumb question that's been answered before, but I can't > find anything about it. > > I'm calling Grow() on a bytes.Buffer and I thought that would increase Cap() > and the size of the underlying []byte. But, it doesn't seem

Re: [go-nuts] Re: RFC: Blog post: How to not use an HTTP router

*The basic arguments, again, are a) Having a Router doesn't actually save you code in a significant way, because you are replacing a conditional with a function call and b) instead you are pulling a whole lot of unnecessary code into your program, that implements a DSL to express the routing

Re: [go-nuts] Re: [ANN] A blog post series on serving big satellite imagery with Go

Thank you, Pablo. Very helpful to have this kind of step by step example for Go developers. I have some familiarity in this area and I'd say the practical issues in large-scale, high-throughput operation tend to relate to the native filesystem. Too many small files overwhelm them and can make dire

[go-nuts] bytes.Buffer Grow() doesn't always increase Cap()?

Sorry if this is a dumb question that's been answered before, but I can't find anything about it. I'm calling Grow() on a bytes.Buffer and I thought that would increase Cap() and the size of the underlying []byte. But, it doesn't seem to: https://play.golang.org/p/3j8YCpB59s That example works

Re: [go-nuts] GC Internals Questions

Pointers that point from a Go object to somewhere outside the Go heap are perfectly fine. The Go runtime will not try to dereference them. unsafe.Pointer is ok, but so are concrete types, like *byte. One caveat: the pointer must be a real pointer. Don't store a bunch of bitfields in a Go pointer

[go-nuts] Re: [ANN] A blog post series on serving big satellite imagery with Go

Thank you Thomas for the link to the vips library. I didn't know about it and now I want to read more about its design and internals. The objective of the article was to set a baseline using the Go image library and play with several factors to see how it affects performance. In this first arti

Re: [go-nuts] Re: RFC: Blog post: How to not use an HTTP router

I also think its a bit of a false dichotomy; I use a hybrid approach, where I have a server's public interface be a http.Handler, but its internal implementation of ServeHTTP uses a router to dispatch to several methods on the server. https://play.golang.org/p/-W4tHmiUve is a stripped down exam

[go-nuts] Re: Sending C array over gob ; decoding shows wrong data

Per https://golang.org/pkg/encoding/gob/, “Structs encode and decode only exported fields.” The fields of your C struct are unexported in Go, since they start with lower-case letters. If the gob package is encoding or decoding the non-array fields of the struct, *that* is the bug. On Monday,

Re: [go-nuts] Is this a bug or am I missing something?

When you append to a slice with the append function, it just assigns the value to the len.th slot and increments len. This is only possible, if the backing array is big enough. This backing array capacity is the slice's capacity, retrieved by cap. If the capacity is not enough, a new, bigger bac

Re: [go-nuts] Is this a bug or am I missing something?

Hi Jesse Thank you very much. I guess that happens when you come to Go with a PHP background. I still have one question, why does it happen always on that iteration? Not the previous iterations? On Tuesday, December 19, 2017 at 4:32:09 PM UTC+11, Jesse McNelis wrote: > > On Tue, Dec 19, 2017 at

[go-nuts] Re: JSON decoding

Looks like I found the solution in https://golang.org/pkg/encoding/json/#Decoder.Decode Example (Stream). This should do it. On Tuesday, December 19, 2017 at 11:11:25 AM UTC-5, Tad Vizbaras wrote: > > > I have this: > > type Runner interface { > TaskName() string > Run(ctx context.Context) er

Re: [go-nuts] GC Internals Questions

I've partially remembered why I used unsafe.Pointer instead of uintptr. In cases where the tensor was built from an existing memory (i.e building a tensor with Go allocated slice backing), I wanted the slice to not be GC'd away On Wednesday, 20 December 2017 00:00:10 UTC+11, Jan Mercl wrote: >

[go-nuts] Re: callback for c code wrapper around go function

Thanks for your response, are you referring to something like this: /* #include #include void parse(char* err, int status) { // do work } */ func Ccomputation(address *C.char) { ptr := uintptr(unsafe.Pointer(C.parse)) SomeGoComputation(C.GoString(address), func(errString stri

[go-nuts] JSON decoding

I have this: type Runner interface { TaskName() string Run(ctx context.Context) error } type Job struct { Tasks []Runner } 1. I have number of structs that implement Runner interface and get added into slice of Tasks. 2. I use json.Encoder to save Job into JSON file. 3. But when I try to loa

[go-nuts] [ANN] meli - an alternative to docker-compose.

Hey guys, I'm happy to announce meli , an alternative to docker-compose written in Go. Let me know what you think. Cheers. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Re: Why is the cpu usage so high in a golang tcp server?

In addition, look at allocation. If you can keep the garbage collector constantly busy it'll use the available CPU cores in the machine. It is likely to improve the system by quite a lot. On Tue, Dec 19, 2017 at 11:36 AM Gulácsi Tamás wrote: > You don't need to use bufio, but you'll need bufferi

Re: [go-nuts] GC Internals Questions

On Tue, Dec 19, 2017 at 1:50 PM Xuanyi Chew wrote: > As such I have no idea what would happen if the GC scanner hits a unsafe.Pointer that it cannot access. Will the pointer be marked as unaccessible? Does it panic with SIGBUS? I think the GC will not try to dereference a pointer that is known t

[go-nuts] GC Internals Questions

An uintptr is not treated as a pointer, but can be converted to an unsaf.Pointer. -- 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...@googleg

[go-nuts] GC Internals Questions

Increasingly in the past year I've been writing GC-aware code. On the one hand, my machine learning related stuff has sped up quite a fair bit. On the other hand additional profiling shows me how far I've yet to go. I've been thinking of moving a bunch of stuff off-heap. But at the same time, h

Re: [go-nuts] Compiler Static Optimisation

Thanks for the prompt replies. Please read no further, PEBKAC: I was on an old compiler on the machine I was running on (I had updated the compiler on my desktop, but clearly not the Pi I was testing this on - now re-building with latest). In truth this was a problem I came across a few weeks a

Re: [go-nuts] Compiler Static Optimisation

On Tue, Dec 19, 2017 at 12:05 PM Chris Hopkins wrote: ... > was slower than: ... Without more information the conclusion that the optimization is not there cannot be established. Inspect the real produced machine code. I guess you'll find that the machine code differs in cache-line alignment o

[go-nuts] Compiler Static Optimisation

This is unexpected. Which version of Go are you using? Can you please post a benchmark, in testing.B format, that others can use to reproduce your results. Thanks Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from thi

[go-nuts] Compiler Static Optimisation

Hi, I assume this is expected behaviour to most, but it went against my expected behaviour so thought I would share. I was benchmarking some code and in the inner loop discovered that: if true { funcA() } else { funcB() } was slower than: //if true { funcA() //} else { // funcB() //} O

Re: [go-nuts] Re: Why is the cpu usage so high in a golang tcp server?

You don't need to use bufio, but you'll need buffering to decrement the count of Read calls (thus, syscalls). Reusing []byte slices: use a sync.Pool. Or several sync.Pools for different byte slices. Vasiliy Tolstov ezt írta (időpont: 2017. dec. 19., K, 11:30): > If I have something like this, bu

Re: [go-nuts] Re: Why is the cpu usage so high in a golang tcp server?

If I have something like this, but I know that client sends fixed sized message header 48 byte and variable sized body based on data in header, and want to minimize allocations. Does I need to use bufio? Now I'm use goleveldb util package for reusable byte slice. 19 Дек 2017 г. 11:22 пользователь

[go-nuts] Re: [ANN] A blog post series on serving big satellite imagery with Go

Interesting and nice pieces of code. I wonder if the performances can be compared to something like `vips` (https://jcupitt.github.io/libvips). Le lundi 18 décembre 2017 22:51:49 UTC+1, Pablo Rozas Larraondo a écrit : > > Hi, > > For those interested on serving or using satellite imagery, I've ju

Re: [go-nuts] Re: RFC: Blog post: How to not use an HTTP router

> You strip whatever prefix you chose before dispatching to pprof.Handler and > it does all the routing it needs for itself. It would be great if that was actually a viable approach in general, but unfortunately it's not, because it's not uncommon to need to know the absolute path that's being se

Re: [go-nuts] Re: Why is the cpu usage so high in a golang tcp server?

bufio.NewReader On Mon, 2017-12-18 at 05:11 -0800, Tamás Gulácsi wrote: > > n, err := sock.Read(buf) > > > > > This will be slow: TCP is a streaming protocol, so this Read can read > any  > length between 0 (! yes !) and 1024 bytes. > Use buffering (bytes.NewReader) and some kind of messag