[go-nuts] Is SizedReaderAt coming back in 1.8?

The missing inclusion stems from a misunderstanding of the intended api. The Size method should return the upper bound for the offset passed to ReadAt known ahead of time. If the upper bound cannot be detected, the SizedReaderAt will simply fail creation. When the Size changes, ReadAt will r

Re: [go-nuts] Is SizedReaderAt coming back in 1.8?

On Fri, Sep 9, 2016 at 6:40 AM, Carl Mastrangelo wrote: > A use case that I am interested in is turning a ReaderAt into a Reader, > which is currently non-trivial to convert. > Out of curiosity, what's wrong with this ? There might be some subtlety that I'm

Re: [go-nuts] Is SizedReaderAt coming back in 1.8?

The problem is that some Size methods return (int64, error) and others return int64, so the interface was removed, since it can't match all the types in the stdlib that it might be useful for. You can easily define it yourself for your own use though, and provide a shim for the types that don't qu

[go-nuts] Is SizedReaderAt coming back in 1.8?

It seems that io.SizedReaderAt was added temporarily during the 1.7 cycle, but promptly removed. I see an standing github issue for it (15822) but it doesn't seem to have much activity. I would like to express my hope that it comes back (and hopefully others will to). A use case that I am i

[go-nuts] memory leak with websocket

We have a websocket service based on go-socket.io( the socket.io golang implementation), but seems have a memory leak problem. I also have opened a same topic ,but the problem is not be resolved. I also enable the debug.FreeOSMemory, the idle heap now will be released back to OS, but the heap

[go-nuts] Dynamic json unmarshaling map[string]int and errors

Hi all, Help me please write an idiomatic golang code for api client for json rest api. In normal case api send just map[string]int and it's easy to unmarshal in map. { "string": 1, "string": 2 } But in error case it becomes: { "error": "error_string" } What is the best way to hand

[go-nuts] Re: Problems to create the JSON structure dynamically

Thank you, after a meal i found the same solution :-) -- 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,

Re: [go-nuts] Problems to create the JSON structure dynamically

Hi Jens. I hope this helps. Let me know if you have any questions. https://play.golang.org/p/Z39q1BAFFb -- 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-n

[go-nuts] Problems to create the JSON structure dynamically

Hello, I'm unable o create dynamically the given JSON structure. I need the following JSON structure for a linechart with two timeseries: [ [{ "time": 141004800, "val": 2182257289.448362 }, { "time": 141013440, "val": 1693164286.4698827 }, { "time": 141022080, "val": 0 }], [{ "time":

Re: [go-nuts] What was the rationale behind using braces for scoping?

There is ample evidence that “typographic block structure” via indenting is fragile in terms of potential error in the reality of cut-and-paste. This is not a comment on like/dislike in abstract, just on dislike when designing for high programmer productivity. -- You received this message bec

Re: [go-nuts] Pointer literal

https://github.com/golang/go/issues/9097 2016-09-07 23:42 GMT+08:00 'Mihai B' via golang-nuts < golang-nuts@googlegroups.com>: > Hi there, > > Any HTTP API with PATCH support needs to use pointers on basic types. > Therefore I'm wondering if there is any will/proposal to make pointer > initialisa

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Friday, September 9, 2016 at 12:10:50 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Sep 8, 2016 at 8:16 AM, T L > > wrote: > > > > On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor > wrote: > >> > >> On Thu, Sep 8, 2016 at 3:46 AM, T L wrote: > >> > > >> > On Thurs

[go-nuts] Re: Can't understand untyped constant behavior

On Friday, September 9, 2016 at 12:15:53 AM UTC+8, T L wrote: > > Although x and y's possible types include float32, there are two steps in > "var f float32 = x / y". > The first one is "x / y", for both default type of x and y is int, so the > result is 1. > The second step is "var f float32 =

[go-nuts] Re: Can't understand untyped constant behavior

Although x and y's possible types include float32, there are two steps in "var f float32 = x / y". The first one is "x / y", for both default type of x and y is int, so the result is 1. The second step is "var f float32 = 1". This is it. If you change 5 to 5.0, or change 3 to 3.0, then the firs

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

On Thu, Sep 8, 2016 at 8:19 AM, T L wrote: > > On Thursday, September 8, 2016 at 10:57:10 PM UTC+8, Ian Lance Taylor wrote: >> >> On Thu, Sep 8, 2016 at 7:21 AM, T L wrote: >> > >> > On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote: >> >> >> >> On Thu, Sep 8, 2016 at 3:32 PM T

[go-nuts] Can't understand untyped constant behavior

Because the infered type is a int so you're doing integer math.. So 5/2 = 2.5 but if you int 2.5 you get 2. As an example. For the infere to work correctly I believe you need to write const x,y := 5.0,2.0 the decimal place will force it to use float64 instead. -- You received this message beca

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Thu, Sep 8, 2016 at 8:16 AM, T L wrote: > > On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor wrote: >> >> On Thu, Sep 8, 2016 at 3:46 AM, T L wrote: >> > >> > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor >> > wrote: >> >> >> >> On Wed, Sep 7, 2016

Re: [go-nuts] Can't understand untyped constant behavior

On Thu, Sep 8, 2016 at 5:31 PM Ilya Kostarev wrote: > How this doesn't produce 1.6 x and y are untyped integer constants, so x/y is an untyped integer constant 1. var f is float32, so the untyped integer constant 1 is converted to float32. -- -j -- You received this message because you

[go-nuts] Can't understand untyped constant behavior

package main import "fmt" func main() { const x, y = 5, 3 var f float32 = x / y fmt.Println(f) } output 1 https://play.golang.org/p/FH1f793gWI How this doesn't produce 1.6 Would be thankful for explanation. __ Ilya Kostarev -- You received this messa

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

On Thursday, September 8, 2016 at 10:57:10 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Sep 8, 2016 at 7:21 AM, T L > > wrote: > > > > On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote: > >> > >> On Thu, Sep 8, 2016 at 3:32 PM T L wrote: > >> > >> > With the enough init

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Sep 8, 2016 at 3:46 AM, T L > > wrote: > > > > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor > wrote: > >> > >> On Wed, Sep 7, 2016 at 8:16 AM, T L wrote: > >> > > >> > On Wed

Re: [go-nuts] JPEG to RGB issues

Thanks Nigel. That explains what I'm seeing. On Wednesday, September 7, 2016 at 8:41:17 PM UTC-5, Nigel Tao wrote: > > JPEG is not a pixel-exact format, even in YCbCr color space. Different > Discrete Cosine Transformation implementations may produce slightly > different YCbCr and hence RGB val

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

On Thu, Sep 8, 2016 at 7:21 AM, T L wrote: > > On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote: >> >> On Thu, Sep 8, 2016 at 3:32 PM T L wrote: >> >> > With the enough initial size, the underlying hashtable of the new map >> > will never need to be realloced in the whole copy

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Thu, Sep 8, 2016 at 3:46 AM, T L wrote: > > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor wrote: >> >> On Wed, Sep 7, 2016 at 8:16 AM, T L wrote: >> > >> > On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote: >> >> >> >> On Wed, Sep 7, 2016 at 4:54 PM

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote: > > On Thu, Sep 8, 2016 at 3:32 PM T L > > wrote: > > > With the enough initial size, the underlying hashtable of the new map > will never need to be realloced in the whole copy process. > > For example > > dst := make

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

On Thu, Sep 8, 2016 at 3:32 PM T L wrote: > With the enough initial size, the underlying hashtable of the new map will never need to be realloced in the whole copy process. For example dst := make(map[T]U, len(src)) See also https://golang.org/ref/spec#Making_slices_maps_and_channels

[go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

With the enough initial size, the underlying hashtable of the new map will never need to be realloced in the whole copy process. -- 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, se

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

Or maybe it works the other way? Because sync/atomic is covered then by accidental extension so is unsafe. tors 8 sep. 2016 kl 15:00 skrev Jan Mercl <0xj...@gmail.com>: > On Thu, Sep 8, 2016 at 2:51 PM T L wrote: > > > Aren't the parameters of atomic.Load/Store/SwapPointer functions > (*)unsafe.

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Thu, Sep 8, 2016 at 2:51 PM T L wrote: > Aren't the parameters of atomic.Load/Store/SwapPointer functions (*)unsafe.Pointer? Yes, they are. Using any package API that involves unsafe.Pointer implies your program must "import unsafe" to use it. And that means your program is not covered by the

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Thursday, September 8, 2016 at 7:00:33 PM UTC+8, Jakob Borg wrote: > > tors 8 sep. 2016 kl 12:46 skrev T L >: > >> >> On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor >> wrote: >> >>> Perhaps you could explain what kind of compatibility risk you are >>> concerned about t

Re: [go-nuts] Re: Ideas for a Go interpeter, feedback requested

On Thu, Sep 8, 2016 at 1:29 PM, HWJ wrote: > I have semi-concrete plans for such a port after I am done with >> sparc64 and arm64 SSA. >> > That's really interesting! FYI, these semi-concrete plans were exposed here: https://github.com/go-interpreter/proposal/issues/1#issuecomment-242975215

Re: [go-nuts] Re: Ideas for a Go interpeter, feedback requested

I have semi-concrete plans for such a port after I am done with sparc64 and arm64 SSA. That's really interesting! PS: perhaps, instead of "vm" or "varch", the GOARCH should be named "dis" :) I'd suggest GOARCH=n32k. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

tors 8 sep. 2016 kl 12:46 skrev T L : > > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor > wrote: > >> Perhaps you could explain what kind of compatibility risk you are >> concerned about that is not covered by the Go 1 compatibility >> guarantee. Please give an example of

[go-nuts] Re: How to get Network speed in linux using golang

I am using CGO to get network speed. package main /* #include #include #include #include #include #include #include #include #include #include int get_interface_speed(char *ifname){ int sock; struct ifreq ifr; struct ethtool_cmd edata; int rc; sock = socket(AF_INET

Re: [go-nuts] Why don't the embedded T1 and T2 clash?

Thank all for the explanation. On Thursday, September 8, 2016 at 7:07:14 AM UTC+8, xiio...@gmail.com wrote: > > > > On Wednesday, 7 September 2016 15:59:50 UTC+1, Jan Mercl wrote: >> >> On Wed, Sep 7, 2016 at 4:42 PM T L wrote: >> >> See https://golang.org/ref/spec#Selectors and explain why do yo

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor wrote: > > On Wed, Sep 7, 2016 at 8:16 AM, T L > > wrote: > > > > On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote: > >> > >> On Wed, Sep 7, 2016 at 4:54 PM T L wrote: > >> > >> https://golang.org/d

Re: [go-nuts] interactive debugger for go ??

I use fmt.Println more than fmt.Printf when debugging, but I admit I used dlv yesterday, briefly, to look at a zillion thread stacks and within its limitations it was helpful. -rob On Thu, Sep 8, 2016 at 7:19 PM, Jan Mercl <0xj...@gmail.com> wrote: > > On Thu, Sep 8, 2016 at 10:37 AM Florin Păț

Re: [go-nuts] interactive debugger for go ??

On Thu, Sep 8, 2016 at 10:37 AM Florin Pățan wrote: > Delve is the Go debugger. fmt.Printf is the Go debugger. /ducks -- -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, s

Re: [go-nuts] interactive debugger for go ??

As a small note, you need only the plugin, we ship delve with it so you don't need to install it. Also gdb is known to be unsupported and i would not recommend it. Delve is the Go debugger. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To un