Re: [go-nuts] Initializing nested struct, by dynamically forming struct member path

[Nathan Kerr]

You gave two different things you want to accomplish:

1. “I am trying to read those values and store in DB”
2. “I will populate the struct and provide it the application for 
consumption”

Fortunately accomplishing either or both of these goals follows a similar 
process.

Start by figuring out what the output should be. In the case of a DB, the 
schema the data will be put into. For providing it to the application, the 
data structures you want. You mentioned using range, which means the data 
you want to range over needs to be in a slice or a map.

Then extract and transform the input into the output.

Some guesses I have made about your data:

- There are a variable number of applications and their names aren’t known 
before you get the data.
- Applications have different parameters
- Parameter types default to the contents of “parameterType”, in this case 
“common”

Assuming these guesses are correct, I would unmarshal the json into:

struct {
JsonData []struct {
DataReference []struct {
ParameterType   string `json:"parameterType"`
ApplicationType map[string]map[string]interface{}
} `json:"dataReference"`
} `json:"jsondata"`
}

This sets out the known portions and leaves the variable portions for later 
handling.

Then iterate over ApplicationType to get the different applications and 
their parameters. Populate the database or desired data structures during 
the loop.

An example of this process: https://play.golang.org/p/TNYur-Lr2Z 

-- 
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: unexpected end of JSON input while unmarshal to struct

[Nathan Kerr]

I assume you mean that you didn't know that json.Unmarshal would call 
*LimitOrder.UnmarshalJSON because *LimitOrder.UnmarshalJSON explicitly 
calls json.Unmarshal.

If so, I also had not realized the significance of the UnmarshalJSON 
 name. This is one of the 
hazards of implicit interfaces.

On Thursday, February 23, 2017 at 2:48:22 AM UTC+1, Diogo Ribeiro wrote:
>
> Thanks Nathan, it worked.
> I didn't know that *LimitOrder.UnmarshalJSON would call json.Unmarshal.
>
> Em terça-feira, 21 de fevereiro de 2017 05:24:45 UTC-3, Nathan Kerr 
> escreveu:
>>
>> I figured it out.
>>
>> First off, the posted playground had a different json string and did not 
>> use your UnmarshalJSON function. These made translating between the 
>> non-working setup described in your post and the working playground 
>> annoying. In the future, share the non-working setup.
>>
>> At the point when I figured things out, my code was: 
>> https://play.golang.org/p/aMvz_JTrjD. This won't run on playground 
>> because it uses github.com/pkg/errors to add context to the errors so I 
>> could see which error was returned along with a much needed stack trace.
>>
>> I found two problems with the implementation of UnmarshalJSON:
>>
>> 1. tmp["response_data"] and tmp2["order"] return zero values when the key 
>> is not found. This happened, first, because of the difference between the 
>> posted json and the json in the posted playground. Second, because of the 
>> second problem.
>>
>> 2. json.Unmarshal uses a type's UnmarshalJSON function if it exists to do 
>> the unmarshalling. This created a loop where *LimitOrder.UnmarshalJSON 
>> calls json.Unmarshal, which calls *LimitOrder.UnmarshalJSON, and so on. 
>> Line 71 prints out the call stack for the returned error that confirms this.
>>
>> My recommended way of doing things is 
>> https://play.golang.org/p/kRKevuX8LW, that is write out the structs you 
>> need. This will also allow you to check the status_code from the response. 
>> If your LimitOrder will outlive the response then change 
>> ResponseData.LimitOrder to be a pointer.
>>
>> Hope this helps.
>>
>> On Tuesday, February 21, 2017 at 6:25:10 AM UTC+1, Diogo Ribeiro wrote:
>>>
>>> Could you help me to understand why I'm always getting the error unexpected 
>>> end of JSON input while trying to unmarshal the following json to the 
>>> LimitOrder struct? It works if I use golang playground 
>>> https://play.golang.org/p/udPQ_TayXG but not locally running tests.
>>>
>>>
>>> P.S.: if I use map[string]json.RawMessage instead of LimitOrder struct 
>>> I'm able to execute the unmarshal.
>>>
>>>
>>> {
>>>   "response_data": {
>>> "order": {
>>>   "order_id": 3,
>>>   "coin_pair": "BRLBTC",
>>>   "order_type": 1,
>>>   "status": 4,
>>>   "has_fills": true,
>>>   "quantity": "1.",
>>>   "limit_price": "900.0",
>>>   "executed_quantity": "1.",
>>>   "executed_price_avg": "900.0",
>>>   "fee": "0.0030",
>>>   "created_timestamp": "1453835329",
>>>   "updated_timestamp": "1453835329",
>>>   "operations": [
>>> {
>>>   "operation_id": 1,
>>>   "quantity": "1.",
>>>   "price": "900.0",
>>>   "fee_rate": "0.30",
>>>   "executed_timestamp": "1453835329"
>>> }
>>>   ]
>>> }
>>>   },
>>>   "status_code": 100,
>>>   "server_unix_timestamp": "1453835329"}
>>>
>>> *LimitOrder struct*
>>>
>>>
>>> type LimitOrder struct {
>>>   OrderId int `json:"order_id"`
>>>   CoinPair string `json:"coin_pair"`
>>>   OrderType int `json:"order_type"`
>>>   Status int `json:"status"`
>>>   HasFills bool `json:"has_fills"`
>>>   Quantity float64 `json:"quantity,string"`
>>>   LimitPrice float64 `json:"limit_price,string"`
>>>   ExecutedQuantity float64 `json:"executed_quantity,string"`
>>>   ExecutedPriceAvg float64 `json:"executed_price_avg,string"`
>>>   Fee float64 `json:"fee,string"`
>>>   Operations []*Operation `json:"operations"`
>>>   CreatedTimestamp string `json:"created_timestamp"`
>>>   UpdatedTimestamp string `json:"updated_timestamp"`}
>>>
>>>
>>> and this is how I'm trying to unmarshal it
>>>
>>>
>>> func (limitOrder *LimitOrder) UnmarshalJSON(buf []byte) error {
>>>
>>>   tmp := make(map[string]json.RawMessage)
>>>   if err := json.Unmarshal(buf, &tmp); err != nil {
>>> return err
>>>   }
>>>
>>>   tmp2 := make(map[string]json.RawMessage)
>>>
>>>   if err := json.Unmarshal(tmp["response_data"], &tmp2); err != nil {
>>> return err
>>>   }
>>>
>>>   if err := json.Unmarshal(tmp2["order"], limitOrder); err != nil {
>>> return err
>>>   }
>>>
>>>   return 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/o

[go-nuts] Re: NewTicker function example

[Nathan Kerr]

NewTicker function example

The task of running functions on a periodic basis can be split into two 
parts: timing and execution.

A ticker solves the timing problem by providing a channel that get new 
input every period. Keeping the timing separate mitigates the impact of 
execution on the timing period (e.g., it won’t be execution time + sleep 
time)

Execution can be solved by ranging over the ticker channel. The contents of 
the loop will be run for each input received from the ticker channel. If 
the loop executes in less than one period, the loop will execute every 
period.

Since tickers use channels, the execution loop can be run anywhere, though 
they are frequently used in goroutines because the program is also doing 
something else.

I would simplify Rodolfo’s examples to:

package main

import (
"fmt"
"time"
)

func square(x int) int {
return x * x
}

func cube(x int) int {
return x * x * x
}

func main() {
ticker := time.NewTicker(5 * time.Second)

for range ticker.C {
fmt.Println(square(10))
fmt.Println(cube(10))
}
}

This will run square and cube every 5 seconds while the program is 
executing.

On Thursday, February 23, 2017 at 2:39:12 AM UTC+1, Keith Brown wrote:
>
> Oddly, I can't find a single example on the world wide web for what I am 
> trying to do.
>
> I have 2 functions which I want to run on a periodic basis. The functions 
> are square and cube. 
> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
> But, I am not sure how to schedule these functions.  I looked here, 
> https://gobyexample.com/tickers, but really isn't that helpful or 
> intuitive. 
>
>
>
>

-- 
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: Trying to understand := and named return values

[Nathan Kerr]

They also seem to be the only way to handle errors in defer 
 without panic or 
log.Fatal.

On Wednesday, February 22, 2017 at 6:24:41 AM UTC+1, Paul Borman wrote:
>
> Named return values are perfectly fine, and I agree, probably should not 
> be discouraged.  For example, which is easier to write documentation for?
>
> func Run(cmd string) ([]byte, []byte, error)
>
> func Run(cmd string) (stdout, stderr []byte, _ error)
>
> What is not good is the following function:
>
> func Foo() (err error) {
> if err := someFunc(); err != nil {
> return  // Why do I always get a nil error?!?!
> }
> return
> }
>
> This is a* naked return* and that is what is bad, not that you named your 
> return values.   This version is fine:
>
> func Foo() (err error) {
> if err := someFunc(); err != nil {
> return  err
> }
> return nil
> }
>
> As there is no doubt on what is being returned.  And as mentioned earlier, 
> named returns are very useful in defers:
>
> func Foo(path string) (err error) {
> w, err := os.Create(path, 0644)
> if err != nil {
> return err
> }
> defer func() {
> if cerr := w.Close(); cerr != nil && err == nil {
> err = cerr
> }
> }()
> ...
> }
>
>
> Again, named return values are fine and cause no problems, but naked 
> returns should never have been part of the language (at first they seem 
> useful and cool, but in the end, they cause more problems than they solve).
>
> On Tue, Feb 21, 2017 at 8:25 PM, > wrote:
>
>> Named returns are actually quite useful with panics :
>>
>> https://play.golang.org/p/ZdoZJBN0T1
>>
>>
>> Le mardi 21 février 2017 23:13:11 UTC+1, Ian Lance Taylor a écrit :
>>>
>>> On Tue, Feb 21, 2017 at 1:46 PM,   wrote: 
>>> > Seems like named returns + if/for/switch initializers = a shadowing 
>>> > nightmare. I wish the Go compiler emitted a loud warning on shadowing, 
>>> as 
>>> > this is a dangerously subtle problem out there. 
>>>
>>> Yes, named returns may have been a mistake.  Only use them in very 
>>> very short functions. 
>>>
>>> Ian 
>>>
>> -- 
>> 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.

[go-nuts] Re: Unsafe string/slice conversions

[T L]

On Wednesday, February 22, 2017 at 6:53:53 AM UTC+8, Caleb Spare wrote:
>
> I have a program that uses unsafe in order to coerce some slices to 
> strings for use as map keys. (Avoiding these allocations ends up being 
> an important performance optimization to this program.) 
>
> Here's some example code that shows what I'm doing: 
>
> https://play.golang.org/p/Yye1Riv0Jj


Looks ok, but sliceToStringUnsafe in m[sliceToStringUnsafe(v)] = 1 is not 
essential, for gc compiler has already made the same optimization for you.
Just use m[string(v)] = 1 is ok.
 

>
>
> Does this seem OK? I've tried to make sure I understand how all the 
> unsafe codes fits into the blessed idioms at 
> https://golang.org/pkg/unsafe/#Pointer. The part I'm most curious 
> about is the indicated line: 
>
> sh.Data = (*reflect.StringHeader)(unsafe.Pointer(&s)).Data // <--- 
>
> This is a double-application of rule 6: it's a conversion *from* a 
> reflect.StringHeader's Data field *to* a reflect.SliceHeader's Data 
> field, through an unsafe.Pointer and uintptr. 
>
> This code has been working for a long time and appears to continue to 
> work, but I've been re-reviewing all my unsafe usage after reading the 
> conversation at https://github.com/golang/go/issues/19168. 
>
> Thanks for any insights. 
> Caleb 
>
> P.S. In this particular case, I'm planning on replacing the map with a 
> custom hashtable (since it's very specialized I can do better than a 
> built-in map type) and that will eliminate the unsafe code. 
>

-- 
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] Reflection: Constructing a struct type that satisfies an interface

[Ivan Vučica]

What I want, in the end, is to send a gRPC request based on an ASCII or
JSON representation of a protobuf, receive a response and display it.

Essentially, if you take grpc_cli tool present in the repo of C
implementation of gRPC, I would like to implement its "call" functionality.

Even though trying to construct a binary protobuf /might/ be a dead end
depending on how I would have to invoke the RPC itself, building a
proto.Message out of a remote protobuf descriptor happens to be an
interesting problem in itself.

It'd be less than fun if the solution is to write yet another proto
serializer/deserializer. And I didn't even check if, when using grpc-go, I
can invoke a remote gRPC method using just its name...

Of course, if you have another shortcut that I missed in grpc-go's APIs or
in Go protobuf's APIs, that'd be great, too ☺️

On Thu, Feb 23, 2017, 02:57 Matt Harden  wrote:

> Is the intermediate Go struct necessary, or do you just want to convert a
> text proto to a binary representation?
>
> On Wed, Feb 22, 2017 at 6:10 PM  wrote:
>
> Hi,
>
> I'm fiddling with gRPC and its service reflection. I discovered a neat
> package (github.com/jhump/protoreflect) that let me quickly enumerate the
> services that are exposed by the gRPC server, the RPCs that are in those
> gRPC services, and finally the proto messages that are used as inputs and
> outputs.
>
> Later, I'll worry about how to actually send out the RPC.
>
> For now, I'm trying to unserialize a text proto message into a dynamically
> constructed Go struct, which I'd then serialize back into a binary proto.
>
> I'd like to make the generated struct satisfy the proto.Message interface.
> There are three methods required by that interface.
>
> How would one go about attaching the required methods onto the newly
> constructed type?
>
> --
> 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] Reflection: Constructing a struct type that satisfies an interface

['Axel Wagner' via golang-nuts]

>From what I know, a) with the normal protobuf package, you can not en- or
decode and then reflect messages by the proto descriptor, you need to
compile in the generated code - adding methods to a reflect-created struct
alone doesn't help, as the package also has some assumptions about the
representation of the type, from what I can tell. And b) you can not invoke
reflected RPC calls with the go grpc implementation. Related issues are
https://github.com/golang/protobuf/issues/199
https://github.com/grpc/grpc-go/issues/866

On Thu, Feb 23, 2017 at 1:16 PM, Ivan Vučica  wrote:

> What I want, in the end, is to send a gRPC request based on an ASCII or
> JSON representation of a protobuf, receive a response and display it.
>
> Essentially, if you take grpc_cli tool present in the repo of C
> implementation of gRPC, I would like to implement its "call" functionality.
>
> Even though trying to construct a binary protobuf /might/ be a dead end
> depending on how I would have to invoke the RPC itself, building a
> proto.Message out of a remote protobuf descriptor happens to be an
> interesting problem in itself.
>
> It'd be less than fun if the solution is to write yet another proto
> serializer/deserializer. And I didn't even check if, when using grpc-go, I
> can invoke a remote gRPC method using just its name...
>
> Of course, if you have another shortcut that I missed in grpc-go's APIs or
> in Go protobuf's APIs, that'd be great, too ☺️
>
> On Thu, Feb 23, 2017, 02:57 Matt Harden  wrote:
>
>> Is the intermediate Go struct necessary, or do you just want to convert a
>> text proto to a binary representation?
>>
>> On Wed, Feb 22, 2017 at 6:10 PM  wrote:
>>
>> Hi,
>>
>> I'm fiddling with gRPC and its service reflection. I discovered a neat
>> package (github.com/jhump/protoreflect) that let me quickly enumerate
>> the services that are exposed by the gRPC server, the RPCs that are in
>> those gRPC services, and finally the proto messages that are used as inputs
>> and outputs.
>>
>> Later, I'll worry about how to actually send out the RPC.
>>
>> For now, I'm trying to unserialize a text proto message into a
>> dynamically constructed Go struct, which I'd then serialize back into a
>> binary proto.
>>
>> I'd like to make the generated struct satisfy the proto.Message
>> interface. There are three methods required by that interface.
>>
>> How would one go about attaching the required methods onto the newly
>> constructed type?
>>
>> --
>> 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.
>

-- 
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] Developing Microservices

[dc0d]

How do you develop a microservice based (architecture) app? I have some 
scripts that are doing the building, starting and stopping and also running 
tests. But do you use any specific tools for developing microservices?

- Env: Apps are communicating via NATS (& some HTTP), Go 1.8, Ubuntu 14.04 
(Linux in general)

-- 
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] Using the Plugin Feature in Go 1.8

[dc0d]

Is the plugin feature in Go 1.8, production ready?

Or is it experimental? On slack Andrei Tudor Călin led me to the list of 
current issues 

 
with plugins, which is somehow daunting. BTW even providing just functions 
(by means of plugins), seems very nice to me (& kinda like it the way it 
is).

-- 
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] Developing Microservices

[Nyah Check]

This should help: https://github.com/micro

On Thu, Feb 23, 2017 at 2:17 PM, dc0d  wrote:

> How do you develop a microservice based (architecture) app? I have some
> scripts that are doing the building, starting and stopping and also running
> tests. But do you use any specific tools for developing microservices?
>
> - Env: Apps are communicating via NATS (& some HTTP), Go 1.8, Ubuntu 14.04
> (Linux in general)
>
> --
> 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.
>



-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
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: Building Go from Source / Managing my ${GOROOT}

[Steve Mynott]

Peter,

That will no longer work in go 1.8 since GOPATH is set to $HOME/go by
default and what you describe will also set GOROOT to the same
directory and the two environment variables have to point at different
directories.

("go env" is useful for debugging this)

One solution is "git clone https://go.googlesource.com/go go1.8" and
use that directory (since you will need a ~/go1.4 to build anyway)

(note you will also have to checkout the go1.8 branch explicitly if
you don't want to build from master)

S

On 19 February 2017 at 15:29, peterGo  wrote:
> Ayan,
>
> It's not idiomatic because you are setting and using GOROOT. Leave that to
> the compiler. For example, with no GOROOT,
>
> $ cd $HOME
> $ git clone https://go.googlesource.com/go
> $ cd go/src
> $ ./make.bash
>
> Peter
>
>
> On Saturday, February 18, 2017 at 5:51:09 PM UTC-5, Ayan George wrote:
>>
>> I'm somewhat new to go and I've been relying on FreeBSD and Ubuntu
>> packages for the compiler.
>>
>> I decided to try building Go from source to get go1.8 and I realized
>> it is really convenient to simply clone the repo into my
>> ${GOROOT}/src (which is now simply ${HOME}/go), build Go (I did
>> extract 1.8 binaries to bootstrap my environment), and add
>> ${HOME}/go/bin to my path.
>>
>> Now I don't have to worry about finding the latest source and I can
>> even keep up with new developments by pulling new code.
>>
>> Am I missing anything by not using the packages?  Is this idiomatic?
>>
>> -ayan
>>
> --
> 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.



-- 
4096R/EA75174B Steve Mynott 

-- 
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] Developing Microservices

[dc0d]

Thanks Nyah! But that's a framework for developing microservices and I'm 
already using one; NATS (although it's more low level).

What I'm looking for is the "development tools"/process/practices that 
helps in the "process of developing" (not designing or implementing) a 
microservices architecture.

On Thursday, February 23, 2017 at 5:00:11 PM UTC+3:30, Nyah Check wrote:
>
> This should help: https://github.com/micro
>
> On Thu, Feb 23, 2017 at 2:17 PM, dc0d 
> > wrote:
>
>> How do you develop a microservice based (architecture) app? I have some 
>> scripts that are doing the building, starting and stopping and also running 
>> tests. But do you use any specific tools for developing microservices?
>>
>> - Env: Apps are communicating via NATS (& some HTTP), Go 1.8, Ubuntu 
>> 14.04 (Linux in general)
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> "The heaviest penalty for declining to rule is to be ruled by someone 
> inferior to yourself." --*Plato* 
>

-- 
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: Unsafe string/slice conversions

[Caleb Spare]

That only applies to []byte. I have a []uint64.

On Feb 23, 2017 4:13 AM, "T L"  wrote:

>
>
> On Wednesday, February 22, 2017 at 6:53:53 AM UTC+8, Caleb Spare wrote:
>>
>> I have a program that uses unsafe in order to coerce some slices to
>> strings for use as map keys. (Avoiding these allocations ends up being
>> an important performance optimization to this program.)
>>
>> Here's some example code that shows what I'm doing:
>>
>> https://play.golang.org/p/Yye1Riv0Jj
>
>
> Looks ok, but sliceToStringUnsafe in m[sliceToStringUnsafe(v)] = 1 is not
> essential, for gc compiler has already made the same optimization for you.
> Just use m[string(v)] = 1 is ok.
>
>
>>
>>
>> Does this seem OK? I've tried to make sure I understand how all the
>> unsafe codes fits into the blessed idioms at
>> https://golang.org/pkg/unsafe/#Pointer. The part I'm most curious
>> about is the indicated line:
>>
>> sh.Data = (*reflect.StringHeader)(unsafe.Pointer(&s)).Data // <---
>>
>> This is a double-application of rule 6: it's a conversion *from* a
>> reflect.StringHeader's Data field *to* a reflect.SliceHeader's Data
>> field, through an unsafe.Pointer and uintptr.
>>
>> This code has been working for a long time and appears to continue to
>> work, but I've been re-reviewing all my unsafe usage after reading the
>> conversation at https://github.com/golang/go/issues/19168.
>>
>> Thanks for any insights.
>> Caleb
>>
>> P.S. In this particular case, I'm planning on replacing the map with a
>> custom hashtable (since it's very specialized I can do better than a
>> built-in map type) and that will eliminate the unsafe code.
>>
> --
> 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: correct/working 9p2000 library in Go?

[Kare Nuorteva]

Here's one that I found just recently: https://blog.aqwari.net/9P/

Cheers,
Kare

sunnuntai 19. helmikuuta 2017 19.39.18 UTC+2 Jason E. Aten kirjoitti:
>
> I'd like to play with the 9p protocol (plan9's "everything is a 
> filesystem" IPC protocol; I guess the updated 9p2000 version is the one 
> everyone actually uses) ...
>
> ...but the implementations I can find in Go seem 
> half-done/incomplete/unmaintained.  
>
> http://9p.cat-v.org/implementations  + other searches turned up:
>
>
> 0) https://github.com/9fans/go - Last commit 2 years ago. 2 outstanding 
> issues, 8 outstanding pull requests. Appears orphaned.
>
> 1) https://code.google.com/p/go9p/ seems to be superceeded by
> https://github.com/lionkov/go9p - 6 open issues including race conditions 
> that appear quite serious.
>
> 2) https://github.com/rminnich/go9p/  - last commit in 2015, 3 
> outstanding issues, 7 outstanding pull requests
>
> 3) https://github.com/Harvey-OS/ninep - recent activity as of 11 days ago 
> (yay), but an open issue indicates ongoing data races and experimentation 
> with the implementation that indicates it is likely not stable or usable by 
> 3rd parties.
>
> 4) https://github.com/docker/go-p9p - six open issues, some of them 
> serious and indicating that it cannot interoperate with other 9p 
> implementations
>
> 5) https://github.com/joushou/qp  - very little documentation and its 
> build is failing 
>
> So to my question...
>
> Does anyone know of, or have a pointer to, a working/solid/correct 9p 
> (9p2000) client/server library in Go?
>
>
> Perhaps the authors of the above could chime in and clarify if their 
> package *is* actually in good shape, despite appearances.
>
>
> NB the problematic licensing of any code derived from the original C 
> implementation means I'll need to locate a non-Lucent  license in order to 
> use a lib. So this rules out a straight port of the C.
>
> Thanks!
>
> -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.

Re: [go-nuts] Developing Microservices

[adrian . price]

I'm not sure there's anything go-specific other than libraries and 
frameworks; just general good practices. One of the best things I can 
recommend to keep microservices from becoming a mess is to treat every 
service like it's external:
- Have a well-defined, versioned API contract for each service
- Maintain black-box tests for each API to ensure it adheres to its contract
- Maintain support for at least the previous API version when a new version 
is released
- Have a documented schedule of when each version or API will be retired

This helps to avoid situations where microservices become tightly coupled 
and have to be deployed together, effectively behaving like monoliths. This 
is sadly very, very common in SOA; I think there was a sense that SOA was a 
cure for coupling, but there is no cure for coupling other than developer 
discipline.

On Thursday, February 23, 2017 at 9:21:37 AM UTC-5, dc0d wrote:
>
> Thanks Nyah! But that's a framework for developing microservices and I'm 
> already using one; NATS (although it's more low level).
>
> What I'm looking for is the "development tools"/process/practices that 
> helps in the "process of developing" (not designing or implementing) a 
> microservices architecture.
>
> On Thursday, February 23, 2017 at 5:00:11 PM UTC+3:30, Nyah Check wrote:
>>
>> This should help: https://github.com/micro
>>
>> On Thu, Feb 23, 2017 at 2:17 PM, dc0d  wrote:
>>
>>> How do you develop a microservice based (architecture) app? I have some 
>>> scripts that are doing the building, starting and stopping and also running 
>>> tests. But do you use any specific tools for developing microservices?
>>>
>>> - Env: Apps are communicating via NATS (& some HTTP), Go 1.8, Ubuntu 
>>> 14.04 (Linux in general)
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> "The heaviest penalty for declining to rule is to be ruled by someone 
>> inferior to yourself." --*Plato* 
>>
>

-- 
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] Why dont the Marshal & Unmarshal use same amount of arguments and return values

[Jianhua Li]

func Marshal(v interface{}) ([]byte, error)
func Unmarshal(data []byte, v interface{}) error

Why dont the Marshal & Unmarshal use same amount of arguments, and same amount 
of return values like one of these.

//1.
func Marshal(data[]byte, v interface{}) (error)
func Unmarshal(data []byte, v interface{}) error

//2.
func Marshal(v interface{}) ([]byte, error)
func Unmarshal(v interface{}) ([]byte, error)


Sent from my iPad

-- 
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] bombardier - Fast cross-platform HTTP benchmarking tool written in Go

[max . faceless . frei]

https://github.com/codesenberg/bombardier

I just released a v1.0 
 of my 
benchmarking tool.
If you have been looking for a *wrk*/*weighttp *replacement for Windows
or want something more performant than, say, *ab*/*siege*/*hey*/*vegeta*, 
you
might want to check it out.

In short, this is a list of features that I find appealing in
comparison to other benchmarking tools:

   - both *timed* and *limited by number of requests* modes;
   - nice and informative *progress bar*;
   - much *lower memory consumption* in general(compared to *hey*, *vegeta*
   );
   - pretty *high performance*. On my machine up to *265k RPS*.


-- 
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 dont the Marshal & Unmarshal use same amount of arguments and return values

[Jianhua Li]

i meant the json library


> On 23 Feb 2017, at 20:42, Jianhua Li  wrote:
> 
> func Marshal(v interface{}) ([]byte, error)
> func Unmarshal(data []byte, v interface{}) error
> 
> Why dont the Marshal & Unmarshal use same amount of arguments, and same 
> amount of return values like one of these.
> 
> //1.
> func Marshal(data[]byte, v interface{}) (error)
> func Unmarshal(data []byte, v interface{}) error
> 
> //2.
> func Marshal(v interface{}) ([]byte, error)
> func Unmarshal(v interface{}) ([]byte, error)
> 
> 
> Sent from my iPad

-- 
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] Why dont the Marshal & Unmarshal use same amount of arguments and return values

[Ian Lance Taylor]

On Thu, Feb 23, 2017 at 4:42 AM, Jianhua Li  wrote:
> func Marshal(v interface{}) ([]byte, error)
>
> func Unmarshal(data []byte, v interface{}) error
>
>
> Why dont the Marshal & Unmarshal use same amount of arguments, and same
> amount of return values like one of these.
>
>
> //1.
>
> func Marshal(data[]byte, v interface{}) (error)
>
> func Unmarshal(data []byte, v interface{}) error
>
>
> //2.
>
> func Marshal(v interface{}) ([]byte, error)
>
> func Unmarshal(v interface{}) ([]byte, error)

Because Marshal and Unmarshal do different things.

I don't see how either suggestion could possibly work.

Ian

-- 
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] Beginner Question : Reassignment of counter variable inside for loop in https://github.com/golang/mobile/tree/master/example/flappy

[Victor Kovacs]

Ah Thanks. Sorry i missed it in the FAQ. 

-- 
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] Using the Plugin Feature in Go 1.8

[Ian Lance Taylor]

On Thu, Feb 23, 2017 at 5:24 AM, dc0d  wrote:
> Is the plugin feature in Go 1.8, production ready?
>
> Or is it experimental? On slack Andrei Tudor Călin led me to the list of
> current issues with plugins, which is somehow daunting. BTW even providing
> just functions (by means of plugins), seems very nice to me (& kinda like it
> the way it is).

It's experimental.

Ian

-- 
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] Support for the race detector on ARM

[Owen Waller]

Hi Everyone,

I am assuming that the race detector is not yet supported on ARM
hardware. Having just tried to cross compile some code I am seeing:

go build: -race and -msan are only supported on linux/amd64,
freebsd/amd64, darwin/amd64 and windows/amd64.

The 1.8 docs back this up as well.

Does anybody have an idea of when (or even if) support for the race
detector on ARM will arrive? In my case specifically for ARM6/6K. If
not should I open a Github issue to at least track this?

Ideally, I'd like support via cross compiling, but I can certainly live
with it in the short term if I had to rebuild on ARM hardware.

Thanks

Owen

-- 
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] Debugging long GC pauses

[Oliver Beattie]

I am looking for some advice about how I can debug some long GC pauses I am 
observing in our production workloads under go 1.8 (the problem is not 
specific to 1.8, though). This is a very simple network server – basically 
a HTTP ping endpoint – but I regularly see tail request latencies of 
>100ms. I have enabled GODEBUG=gctrace=1, and I can see some quite long STW 
pauses amid lots of much less worrying pauses:

gc 54 @348.007s 0%: 0.061+81+0.040 ms clock, 0.12+0.39/81/81+0.081 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P
gc 55 @358.007s 0%: 0.21+83+0.019 ms clock, 0.43+80/2.7/81+0.039 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P
*gc 56 @367.507s 0%: 80+1.3+0.065 ms clock, 161+0.080/1.2/82+0.13 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P*
gc 57 @377.726s 0%: 0.054+63+0.023 ms clock, 0.10+0.68/61/0.44+0.046 ms 
cpu, 4->4->1 MB, 5 MB goal, 2 P
gc 58 @388.007s 0%: 0.033+81+0.036 ms clock, 0.067+0.32/80/81+0.072 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P
gc 59 @398.007s 0%: 0.021+82+0.019 ms clock, 0.043+0.17/80/82+0.038 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P
gc 60 @407.630s 0%: 0.012+57+0.031 ms clock, 0.025+0.25/0.64/57+0.063 ms 
cpu, 4->4->1 MB, 5 MB goal, 2 P
gc 61 @418.007s 0%: 0.19+1.0+79 ms clock, 0.38+0.28/0.69/0.98+159 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P
gc 62 @427.507s 0%: 0.21+81+0.29 ms clock, 0.42+81/0.96/81+0.58 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P
gc 63 @437.507s 0%: 0.015+81+0.053 ms clock, 0.031+0.29/0.98/80+0.10 ms 
cpu, 4->4->1 MB, 5 MB goal, 2 P
*gc 64 @443.507s 0%: 81+1.2+0.032 ms clock, 162+0.040/1.2/0.44+0.065 ms 
cpu, 4->4->1 MB, 5 MB goal, 2 P*
scvg2: inuse: 4, idle: 2, sys: 7, released: 0, consumed: 7 (MB)
gc 65 @453.507s 0%: 0.13+81+0.051 ms clock, 0.26+0.20/81/82+0.10 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

If I am reading this correctly, some of these STW pauses are 80+ 
milliseconds, in order to scan a minuscule heap. I am not experienced with 
debugging the GC in Go, so I'd appreciate any pointers as to why this could 
happening and what I can do to get to the bottom of the behaviour. Many 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Debugging long GC pauses

[Caleb Spare]

+rlh, austin

Interesting behavior. I would recommend filing a bug. It would be most
helpful if you can create a complete repro case including either the
production code or some minimization of it that demonstrates the same
pauses.

On Thu, Feb 23, 2017 at 10:46 AM, Oliver Beattie  wrote:
> I am looking for some advice about how I can debug some long GC pauses I am
> observing in our production workloads under go 1.8 (the problem is not
> specific to 1.8, though). This is a very simple network server – basically a
> HTTP ping endpoint – but I regularly see tail request latencies of >100ms. I
> have enabled GODEBUG=gctrace=1, and I can see some quite long STW pauses
> amid lots of much less worrying pauses:
>
> gc 54 @348.007s 0%: 0.061+81+0.040 ms clock, 0.12+0.39/81/81+0.081 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 55 @358.007s 0%: 0.21+83+0.019 ms clock, 0.43+80/2.7/81+0.039 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 56 @367.507s 0%: 80+1.3+0.065 ms clock, 161+0.080/1.2/82+0.13 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 57 @377.726s 0%: 0.054+63+0.023 ms clock, 0.10+0.68/61/0.44+0.046 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 58 @388.007s 0%: 0.033+81+0.036 ms clock, 0.067+0.32/80/81+0.072 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 59 @398.007s 0%: 0.021+82+0.019 ms clock, 0.043+0.17/80/82+0.038 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 60 @407.630s 0%: 0.012+57+0.031 ms clock, 0.025+0.25/0.64/57+0.063 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 61 @418.007s 0%: 0.19+1.0+79 ms clock, 0.38+0.28/0.69/0.98+159 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 62 @427.507s 0%: 0.21+81+0.29 ms clock, 0.42+81/0.96/81+0.58 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 63 @437.507s 0%: 0.015+81+0.053 ms clock, 0.031+0.29/0.98/80+0.10 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 64 @443.507s 0%: 81+1.2+0.032 ms clock, 162+0.040/1.2/0.44+0.065 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> scvg2: inuse: 4, idle: 2, sys: 7, released: 0, consumed: 7 (MB)
> gc 65 @453.507s 0%: 0.13+81+0.051 ms clock, 0.26+0.20/81/82+0.10 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
>
> If I am reading this correctly, some of these STW pauses are 80+
> milliseconds, in order to scan a minuscule heap. I am not experienced with
> debugging the GC in Go, so I'd appreciate any pointers as to why this could
> happening and what I can do to get to the bottom of the behaviour. Many
> 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.
> 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] Support for the race detector on ARM

[Ian Lance Taylor]

On Thu, Feb 23, 2017 at 9:45 AM, Owen Waller  wrote:
>
> I am assuming that the race detector is not yet supported on ARM hardware.
> Having just tried to cross compile some code I am seeing:
>
> go build: -race and -msan are only supported on linux/amd64, freebsd/amd64,
> darwin/amd64 and windows/amd64.
>
> The 1.8 docs back this up as well.
>
> Does anybody have an idea of when (or even if) support for the race detector
> on ARM will arrive? In my case specifically for ARM6/6K. If not should I
> open a Github issue to at least track this?
>
> Ideally, I'd like support via cross compiling, but I can certainly live with
> it in the short term if I had to rebuild on ARM hardware.

Go's race detector is based on and uses Thread Sanitizer, which has
only been implemented for amd64.  I'm not aware of any effort to
extend thread sanitizer to other processors.  That would have been
done before there is any likelihood of Go supporting it.

Ian

-- 
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] Debugging long GC pauses

['Austin Clements' via golang-nuts]

AFAIK, the only thing that can cause this in Go 1.8 is a non-preemptible
loop. It's not related to the heap size at all.

To test this theory, you can set GOEXPERIMENT=preemptibleloops and rebuild
your Go tree (the compiler has to be built with this, so you can't just
turn it on to build your project). I wouldn't recommend running in
production with this, but if it eliminates the long pauses, we'll at least
know that's the culprit.

Since these are quite long, the other thing you can do is run with the
execution tracer (https://godoc.org/runtime/trace). You'll be able to see
exactly what's happening at the beginning of each GC cycle. If you do have
non-preemptible loops, you should also see goroutines executing for much
longer than 10ms at a time, which is the default preemption bound.

On Thu, Feb 23, 2017 at 1:46 PM, Oliver Beattie  wrote:

> I am looking for some advice about how I can debug some long GC pauses I
> am observing in our production workloads under go 1.8 (the problem is not
> specific to 1.8, though). This is a very simple network server – basically
> a HTTP ping endpoint – but I regularly see tail request latencies of
> >100ms. I have enabled GODEBUG=gctrace=1, and I can see some quite long
> STW pauses amid lots of much less worrying pauses:
>
> gc 54 @348.007s 0%: 0.061+81+0.040 ms clock, 0.12+0.39/81/81+0.081 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 55 @358.007s 0%: 0.21+83+0.019 ms clock, 0.43+80/2.7/81+0.039 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> *gc 56 @367.507s 0%: 80+1.3+0.065 ms clock, 161+0.080/1.2/82+0.13 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P*
> gc 57 @377.726s 0%: 0.054+63+0.023 ms clock, 0.10+0.68/61/0.44+0.046 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 58 @388.007s 0%: 0.033+81+0.036 ms clock, 0.067+0.32/80/81+0.072 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 59 @398.007s 0%: 0.021+82+0.019 ms clock, 0.043+0.17/80/82+0.038 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 60 @407.630s 0%: 0.012+57+0.031 ms clock, 0.025+0.25/0.64/57+0.063 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 61 @418.007s 0%: 0.19+1.0+79 ms clock, 0.38+0.28/0.69/0.98+159 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 62 @427.507s 0%: 0.21+81+0.29 ms clock, 0.42+81/0.96/81+0.58 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 63 @437.507s 0%: 0.015+81+0.053 ms clock, 0.031+0.29/0.98/80+0.10 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> *gc 64 @443.507s 0%: 81+1.2+0.032 ms clock, 162+0.040/1.2/0.44+0.065 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P*
> scvg2: inuse: 4, idle: 2, sys: 7, released: 0, consumed: 7 (MB)
> gc 65 @453.507s 0%: 0.13+81+0.051 ms clock, 0.26+0.20/81/82+0.10 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
>
> If I am reading this correctly, some of these STW pauses are 80+
> milliseconds, in order to scan a minuscule heap. I am not experienced with
> debugging the GC in Go, so I'd appreciate any pointers as to why this could
> happening and what I can do to get to the bottom of the behaviour. Many
> 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.
> 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] offset out of range, different toolchain

[jonathan . gaillard]

I am trying to switch from a 32 bit standalone ndk android toolchain to the 
64 bit one. The only changes I have made are the toolchain and using 
GOARCH=arm64 instead of GOARCH=arm when build but I am getting a list of 
errors like:

internal/**/**.go:715: offset out of range: 782
01448 (/go/src/**/**/**/**/**/**.go:2401)MOVDR1, 
"".extractUpdateFS-2322(SP)

Anyone know what to try?

-- 
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] Adding support for session ID-based TLS session reuse

[Igor Gatis]

What is the current status? Is session ID supported?

I agree session ticket is the way to go. But it is useful for old TLS client 
implementations.

I have 10k terminals which do HTTPS requests over gprs. TLS handshake alone 
costs ~4s. With ip-based server affinity and session ID support, latency for 
these terminals could improve by impressive 50%!

-- 
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] Support for the race detector on ARM

[Owen Waller]

Hi Ian,
> 
> Go's race detector is based on and uses Thread Sanitizer, which has
> only been implemented for amd64.  I'm not aware of any effort to
> extend thread sanitizer to other processors.  That would have been
> done before there is any likelihood of Go supporting it.
> 
> Ian

Thanks for the help. 

After a little digging, the best I can come up with is that there might
be an AARCH64 port. That would cover ARM8 64-bit at least.
The reference I've found is on the thread sanitizer google group is,
here:
https://groups.google.com/forum/#!searchin/thread-sanitizer/Port$20to$2
0ARMv7|sort:relevance/thread-sanitizer/14rRfPAr8vE/dJJ1fzrYAAAJ [1]
Which leads to a discussion on llvm.org which suggests it's done(
maybe...)
https://reviews.llvm.org/D11484

What would be the best way to confirm if the AArch64 support exists, as
that seems to be a prerequisite for at least an ARM8 race detector?

I can't find any existing solution to the 32bit ARMs - v5, v6, v7.
Thread Sanitizer seems to need a whole heap of memory so there is a
very real risk out running out of RAM. But then the typical program
sizes that these cores run are much smaller. If we were talking in
terms of programs that only used 10s to 100's of Megs of RAM - you'd
have a reasonably good chance of x5-10 those amounts being free. So
maybe there would be a case to try and port it to 32 bit platforms, but
I admit that is a much bigger question.

Owen

[1] This post may also be related as it discusses getting the thread
sanitizer running on a AMD AArch64 board with a 42 bit VA space.
https://groups.google.com/forum/#!searchin/thread-sanitizer/mips$20supp
ort%7Csort:relevance/thread-sanitizer/QQ3fOtA7qcM/tycOcC1jq3AJ
[2] There also seems to be PPC64 port too
https://groups.google.com/forum/#!searchin/thread-sanitizer/ppc$20suppo
rt|sort:relevance/thread-sanitizer/D-ku2r5cDtU/BbFcY2Gf8qAJ
If this is also true then it also opens up using the race detector on
the PPC64 go ports.

-- 
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] Debugging long GC pauses

[Jesper Louis Andersen]

What would happen if you inserted a dummy function call inside the
non-preemptible loop and made an appropriate sacrifice on the altar of the
SSA dead-code-eliminator so it doesn't trigger?


On Thu, Feb 23, 2017 at 8:46 PM 'Austin Clements' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> AFAIK, the only thing that can cause this in Go 1.8 is a non-preemptible
> loop. It's not related to the heap size at all.
>
> To test this theory, you can set GOEXPERIMENT=preemptibleloops and rebuild
> your Go tree (the compiler has to be built with this, so you can't just
> turn it on to build your project). I wouldn't recommend running in
> production with this, but if it eliminates the long pauses, we'll at least
> know that's the culprit.
>
> Since these are quite long, the other thing you can do is run with the
> execution tracer (https://godoc.org/runtime/trace). You'll be able to see
> exactly what's happening at the beginning of each GC cycle. If you do have
> non-preemptible loops, you should also see goroutines executing for much
> longer than 10ms at a time, which is the default preemption bound.
>
> On Thu, Feb 23, 2017 at 1:46 PM, Oliver Beattie 
> wrote:
>
> I am looking for some advice about how I can debug some long GC pauses I
> am observing in our production workloads under go 1.8 (the problem is not
> specific to 1.8, though). This is a very simple network server – basically
> a HTTP ping endpoint – but I regularly see tail request latencies of
> >100ms. I have enabled GODEBUG=gctrace=1, and I can see some quite long
> STW pauses amid lots of much less worrying pauses:
>
> gc 54 @348.007s 0%: 0.061+81+0.040 ms clock, 0.12+0.39/81/81+0.081 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 55 @358.007s 0%: 0.21+83+0.019 ms clock, 0.43+80/2.7/81+0.039 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> *gc 56 @367.507s 0%: 80+1.3+0.065 ms clock, 161+0.080/1.2/82+0.13 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P*
> gc 57 @377.726s 0%: 0.054+63+0.023 ms clock, 0.10+0.68/61/0.44+0.046 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 58 @388.007s 0%: 0.033+81+0.036 ms clock, 0.067+0.32/80/81+0.072 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 59 @398.007s 0%: 0.021+82+0.019 ms clock, 0.043+0.17/80/82+0.038 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 60 @407.630s 0%: 0.012+57+0.031 ms clock, 0.025+0.25/0.64/57+0.063 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> gc 61 @418.007s 0%: 0.19+1.0+79 ms clock, 0.38+0.28/0.69/0.98+159 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 62 @427.507s 0%: 0.21+81+0.29 ms clock, 0.42+81/0.96/81+0.58 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
> gc 63 @437.507s 0%: 0.015+81+0.053 ms clock, 0.031+0.29/0.98/80+0.10 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P
> *gc 64 @443.507s 0%: 81+1.2+0.032 ms clock, 162+0.040/1.2/0.44+0.065 ms
> cpu, 4->4->1 MB, 5 MB goal, 2 P*
> scvg2: inuse: 4, idle: 2, sys: 7, released: 0, consumed: 7 (MB)
> gc 65 @453.507s 0%: 0.13+81+0.051 ms clock, 0.26+0.20/81/82+0.10 ms cpu,
> 4->4->1 MB, 5 MB goal, 2 P
>
> If I am reading this correctly, some of these STW pauses are 80+
> milliseconds, in order to scan a minuscule heap. I am not experienced with
> debugging the GC in Go, so I'd appreciate any pointers as to why this could
> happening and what I can do to get to the bottom of the behaviour. Many
> 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.
> 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.
>

-- 
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] Debugging long GC pauses

[John Souvestre]

Or…  Call runtime.Gosched().  I seem to recall benchmarking it a while back and 
found that it was very efficient.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Jesper Louis Andersen
Sent: 2017 February 23, Thu 16:18
To: Austin Clements; Oliver Beattie
Cc: golang-nuts
Subject: Re: [go-nuts] Debugging long GC pauses

 

What would happen if you inserted a dummy function call inside the 
non-preemptible loop and made an appropriate sacrifice on the altar of the SSA 
dead-code-eliminator so it doesn't trigger?

 

 

On Thu, Feb 23, 2017 at 8:46 PM 'Austin Clements' via golang-nuts 
 wrote:

AFAIK, the only thing that can cause this in Go 1.8 is a non-preemptible loop. 
It's not related to the heap size at all.

 

To test this theory, you can set GOEXPERIMENT=preemptibleloops and rebuild your 
Go tree (the compiler has to be built with this, so you can't just turn it on 
to build your project). I wouldn't recommend running in production with this, 
but if it eliminates the long pauses, we'll at least know that's the culprit.

 

Since these are quite long, the other thing you can do is run with the 
execution tracer (https://godoc.org/runtime/trace). You'll be able to see 
exactly what's happening at the beginning of each GC cycle. If you do have 
non-preemptible loops, you should also see goroutines executing for much longer 
than 10ms at a time, which is the default preemption bound.

 

On Thu, Feb 23, 2017 at 1:46 PM, Oliver Beattie  wrote:

I am looking for some advice about how I can debug some long GC pauses I am 
observing in our production workloads under go 1.8 (the problem is not specific 
to 1.8, though). This is a very simple network server – basically a HTTP ping 
endpoint – but I regularly see tail request latencies of >100ms. I have enabled 
GODEBUG=gctrace=1, and I can see some quite long STW pauses amid lots of much 
less worrying pauses:

 

gc 54 @348.007s 0%: 0.061+81+0.040 ms clock, 0.12+0.39/81/81+0.081 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 55 @358.007s 0%: 0.21+83+0.019 ms clock, 0.43+80/2.7/81+0.039 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 56 @367.507s 0%: 80+1.3+0.065 ms clock, 161+0.080/1.2/82+0.13 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 57 @377.726s 0%: 0.054+63+0.023 ms clock, 0.10+0.68/61/0.44+0.046 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 58 @388.007s 0%: 0.033+81+0.036 ms clock, 0.067+0.32/80/81+0.072 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 59 @398.007s 0%: 0.021+82+0.019 ms clock, 0.043+0.17/80/82+0.038 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 60 @407.630s 0%: 0.012+57+0.031 ms clock, 0.025+0.25/0.64/57+0.063 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 61 @418.007s 0%: 0.19+1.0+79 ms clock, 0.38+0.28/0.69/0.98+159 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 62 @427.507s 0%: 0.21+81+0.29 ms clock, 0.42+81/0.96/81+0.58 ms cpu, 4->4->1 
MB, 5 MB goal, 2 P

gc 63 @437.507s 0%: 0.015+81+0.053 ms clock, 0.031+0.29/0.98/80+0.10 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

gc 64 @443.507s 0%: 81+1.2+0.032 ms clock, 162+0.040/1.2/0.44+0.065 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

scvg2: inuse: 4, idle: 2, sys: 7, released: 0, consumed: 7 (MB)

gc 65 @453.507s 0%: 0.13+81+0.051 ms clock, 0.26+0.20/81/82+0.10 ms cpu, 
4->4->1 MB, 5 MB goal, 2 P

 

If I am reading this correctly, some of these STW pauses are 80+ milliseconds, 
in order to scan a minuscule heap. I am not experienced with debugging the GC 
in Go, so I'd appreciate any pointers as to why this could happening and what I 
can do to get to the bottom of the behaviour. Many 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.
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.

-- 
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: NewTicker function example

[Keith Brown]

Thank You all for the great examples!

I added a select {} at the end so the program will run forever. I am trying 
to have it as a deamon.



On Thursday, February 23, 2017 at 6:37:12 AM UTC-5, Nathan Kerr wrote:
>
> NewTicker function example
>
> The task of running functions on a periodic basis can be split into two 
> parts: timing and execution.
>
> A ticker solves the timing problem by providing a channel that get new 
> input every period. Keeping the timing separate mitigates the impact of 
> execution on the timing period (e.g., it won’t be execution time + sleep 
> time)
>
> Execution can be solved by ranging over the ticker channel. The contents 
> of the loop will be run for each input received from the ticker channel. If 
> the loop executes in less than one period, the loop will execute every 
> period.
>
> Since tickers use channels, the execution loop can be run anywhere, though 
> they are frequently used in goroutines because the program is also doing 
> something else.
>
> I would simplify Rodolfo’s examples to:
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func square(x int) int {
> return x * x
> }
>
> func cube(x int) int {
> return x * x * x
> }
>
> func main() {
> ticker := time.NewTicker(5 * time.Second)
>
> for range ticker.C {
> fmt.Println(square(10))
> fmt.Println(cube(10))
> }
> }
>
> This will run square and cube every 5 seconds while the program is 
> executing.
>
> On Thursday, February 23, 2017 at 2:39:12 AM UTC+1, Keith Brown wrote:
>>
>> Oddly, I can't find a single example on the world wide web for what I am 
>> trying to do.
>>
>> I have 2 functions which I want to run on a periodic basis. The functions 
>> are square and cube. 
>> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
>> But, I am not sure how to schedule these functions.  I looked here, 
>> https://gobyexample.com/tickers, but really isn't that helpful or 
>> intuitive. 
>>
>>
>>
>>

-- 
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] 1.8 plugins and ABI

['Tim Hockin' via golang-nuts]

Hi all,

I can't seem to find this documented, and I'm me involved in some
conversations about using plugins:

What guarantees or limitations surround plugins?  Can I compile a host
program with go-1.8.0 and have a third-party plugin compiled with 1.8.1,
and load it?

Can I call methods on plugin-specific objects?

Are there any concessions toward versioning?

What happens if I add a method to a type in the host, but don't rebuild he
plugin?

Are functions/method calling conventions guaranteed to be consistent, or do
compiler flags change that?

Thanks!

Tim

-- 
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] 1.8 plugins and ABI

[Ian Lance Taylor]

On Thu, Feb 23, 2017 at 4:45 PM, 'Tim Hockin' via golang-nuts
 wrote:
>
> I can't seem to find this documented, and I'm me involved in some
> conversations about using plugins:
>
> What guarantees or limitations surround plugins?  Can I compile a host
> program with go-1.8.0 and have a third-party plugin compiled with 1.8.1, and
> load it?
>
> Can I call methods on plugin-specific objects?
>
> Are there any concessions toward versioning?
>
> What happens if I add a method to a type in the host, but don't rebuild he
> plugin?
>
> Are functions/method calling conventions guaranteed to be consistent, or do
> compiler flags change that?

Plugins are definitely in an early stage, and there are many reported
bugs with using them in 1.8.

Plugins must be built with the exact same version of Go as is used to
build the main program.  If any package appears in both the main
program and a plugin, or in two loaded plugins, that package must be
built from the exact same source code in all cases.  There are no
current plans to lift these restrictions.  I believe these
restrictions are checked at run time, though there may be bugs.

You can call methods on types defined in a plugin, yes.  You'll
presumably be doing that using some sort of interface type.

There is nothing about versioning in the plugin package.  I don't
think anybody even knows what it would look like.

There are no compiler flags to change the calling convention.  If
there were any, they should cause a failure to load the plugin at run
time.

Ian

-- 
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] offset out of range, different toolchain

[Ian Lance Taylor]

On Thu, Feb 23, 2017 at 12:54 PM,   wrote:
> I am trying to switch from a 32 bit standalone ndk android toolchain to the
> 64 bit one. The only changes I have made are the toolchain and using
> GOARCH=arm64 instead of GOARCH=arm when build but I am getting a list of
> errors like:
>
> internal/**/**.go:715: offset out of range: 782
> 01448 (/go/src/**/**/**/**/**/**.go:2401)MOVDR1,
> "".extractUpdateFS-2322(SP)
>
> Anyone know what to try?

This could be https://golang.org/issue/19137 .

Ian

-- 
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] Support for the race detector on ARM

[Ian Lance Taylor]

[ +dvyukov ]

On Thu, Feb 23, 2017 at 1:34 PM, Owen Waller  wrote:
> Hi Ian,
>
> Go's race detector is based on and uses Thread Sanitizer, which has
> only been implemented for amd64.  I'm not aware of any effort to
> extend thread sanitizer to other processors.  That would have been
> done before there is any likelihood of Go supporting it.
>
> Ian
>
>
> Thanks for the help.
>
> After a little digging, the best I can come up with is that there might be
> an AARCH64 port. That would cover ARM8 64-bit at least.
> The reference I've found is on the thread sanitizer google group is, here:
> https://groups.google.com/forum/#!searchin/thread-sanitizer/Port$20to$20ARMv7|sort:relevance/thread-sanitizer/14rRfPAr8vE/dJJ1fzrYAAAJ
> [1]
> Which leads to a discussion on llvm.org which suggests it's done( maybe...)
> https://reviews.llvm.org/D11484
>
> What would be the best way to confirm if the AArch64 support exists, as that
> seems to be a prerequisite for at least an ARM8 race detector?
>
> I can't find any existing solution to the 32bit ARMs - v5, v6, v7. Thread
> Sanitizer seems to need a whole heap of memory so there is a very real risk
> out running out of RAM. But then the typical program sizes that these cores
> run are much smaller. If we were talking in terms of programs that only used
> 10s to 100's of Megs of RAM - you'd have a reasonably good chance of x5-10
> those amounts being free. So maybe there would be a case to try and port it
> to 32 bit platforms, but I admit that is a much bigger question.
>
> Owen
>
> [1] This post may also be related as it discusses getting the thread
> sanitizer running on a AMD AArch64 board with a 42 bit VA space.
> https://groups.google.com/forum/#!searchin/thread-sanitizer/mips$20support%7Csort:relevance/thread-sanitizer/QQ3fOtA7qcM/tycOcC1jq3AJ
> [2] There also seems to be PPC64 port too
> https://groups.google.com/forum/#!searchin/thread-sanitizer/ppc$20support|sort:relevance/thread-sanitizer/D-ku2r5cDtU/BbFcY2Gf8qAJ
> If this is also true then it also opens up using the race detector on the
> PPC64 go ports.
>

-- 
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] 1.8 plugins and ABI

['Tim Hockin' via golang-nuts]

Thanks, Ian.  Very informative if somewhat disappointing.  It more or less
rules out what we wanted to do.


On Feb 23, 2017 5:23 PM, "Ian Lance Taylor"  wrote:

On Thu, Feb 23, 2017 at 4:45 PM, 'Tim Hockin' via golang-nuts
 wrote:
>
> I can't seem to find this documented, and I'm me involved in some
> conversations about using plugins:
>
> What guarantees or limitations surround plugins?  Can I compile a host
> program with go-1.8.0 and have a third-party plugin compiled with 1.8.1,
and
> load it?
>
> Can I call methods on plugin-specific objects?
>
> Are there any concessions toward versioning?
>
> What happens if I add a method to a type in the host, but don't rebuild he
> plugin?
>
> Are functions/method calling conventions guaranteed to be consistent, or
do
> compiler flags change that?

Plugins are definitely in an early stage, and there are many reported
bugs with using them in 1.8.

Plugins must be built with the exact same version of Go as is used to
build the main program.  If any package appears in both the main
program and a plugin, or in two loaded plugins, that package must be
built from the exact same source code in all cases.  There are no
current plans to lift these restrictions.  I believe these
restrictions are checked at run time, though there may be bugs.

You can call methods on types defined in a plugin, yes.  You'll
presumably be doing that using some sort of interface type.

There is nothing about versioning in the plugin package.  I don't
think anybody even knows what it would look like.

There are no compiler flags to change the calling convention.  If
there were any, they should cause a failure to load the plugin at run
time.

Ian

-- 
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] offset out of range, different toolchain

[jonathan . gaillard]

phew thx, thought I was going crazy there.

On Thursday, February 23, 2017 at 5:27:22 PM UTC-8, Ian Lance Taylor wrote:
>
> On Thu, Feb 23, 2017 at 12:54 PM,  > 
> wrote: 
> > I am trying to switch from a 32 bit standalone ndk android toolchain to 
> the 
> > 64 bit one. The only changes I have made are the toolchain and using 
> > GOARCH=arm64 instead of GOARCH=arm when build but I am getting a list of 
> > errors like: 
> > 
> > internal/**/**.go:715: offset out of range: 782 
> > 01448 (/go/src/**/**/**/**/**/**.go:2401)MOVDR1, 
> > "".extractUpdateFS-2322(SP) 
> > 
> > Anyone know what to try? 
>
> This could be https://golang.org/issue/19137 . 
>
> Ian 
>

-- 
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] Passing Already Accepted Connection to http.Serve()

[henry . f . camacho]

I am attempting to pass an already accepted connection to http.Serve().  I 
need to preview the connection allowing inspection of type of traffic 
appearing on a single port.
The desire is to handle a number of types of connections to a single port. 
 I'll preview the traffic, determine what type it is, and then pass it off 
to the appropriate handler.

I understand that I need a net.Listener interface.

Testing code:

package main

import (
"fmt"
"net"
"net/http"
)

func main() {
loginfo.Println("startup")

listener, err := net.Listen("tcp", ":8080")
if err != nil {
loginfo.Println("unable to bind ")
return
}

conn, err := listener.Accept()
if err != nil {
loginfo.Println("unable to bind", err)
return
}

wedgeListener := &WedgeListener{conn: conn}

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
loginfo.Println("/")
})

err = http.Serve(wedgeListener, nil)
if err != nil {
loginfo.Println("Serve: ", err)
}

}

func connState(conn net.Conn, state http.ConnState) {
loginfo.Println("connState")
fmt.Println(conn, conn.LocalAddr(), conn.RemoteAddr())
fmt.Println(state)
}

//WedgeListener -- used to hand off connections to other protocols via 
Listen
type WedgeListener struct {
conn net.Conn
once sync.Once
}

//Accept --
func (s *WedgeListener) Accept() (net.Conn, error) {
var c net.Conn

loginfo.Println("Accept")

s.once.Do(func() {
loginfo.Println("Do Once")
c = s.conn
})

if c != nil {
loginfo.Println("accepted")
return c, nil
}
return nil, io.EOF
}

//Close --
func (s *WedgeListener) Close() error {
s.once.Do(func() {
loginfo.Println("close called")
s.conn.Close()
})
return nil
}

//Addr --
func (s *WedgeListener) Addr() net.Addr {
loginfo.Println("Add Called", s.conn.LocalAddr())
return s.conn.LocalAddr()
}

When I hit the listener I see the following:

INFO: main: 2017/02/23 19:44:46.339133 main.go:10: startup

INFO: main: 2017/02/23 19:45:06.887653 wedge_listener.go:56: Add Called 
192.168.1.158:8080

INFO: main: 2017/02/23 19:45:06.887668 wedge_listener.go:20: Accept

INFO: main: 2017/02/23 19:45:06.887671 wedge_listener.go:34: Do Once

INFO: main: 2017/02/23 19:45:06.887673 wedge_listener.go:39: accepted

INFO: main: 2017/02/23 19:45:06.887685 wedge_listener.go:20: Accept

INFO: main: 2017/02/23 19:45:06.887692 main.go:32: Serve:  EOF


It appears to me that http.Serve() does not like the connection I've 
provided via WedgeListener.  It dumps the 1st connection and tries to get 
another.


The WedgeListener works just fine Accepted:


wConn, err := wedgeListener.Accept()

if err != nil {

loginfo.Println("Bad accept ", err)

return

}


cnt, err := wConn.Read(buffer[0:])

if err != nil {

loginfo.Println(err)

return

}

loginfo.Println("byte read", cnt)

loginfo.Println(hex.Dump(buffer[0:cnt]))


I get data back, works great.




-- 
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: NewTicker function example

[Nathan Kerr]

The example I gave already runs forever. No need for select.

As for daemonization, I have had good luck with github.com/jpillora/overseer
.

On Friday, February 24, 2017 at 1:22:36 AM UTC+1, Keith Brown wrote:
>
> Thank You all for the great examples!
>
> I added a select {} at the end so the program will run forever. I am 
> trying to have it as a deamon.
>
>
>
> On Thursday, February 23, 2017 at 6:37:12 AM UTC-5, Nathan Kerr wrote:
>>
>> NewTicker function example
>>
>> The task of running functions on a periodic basis can be split into two 
>> parts: timing and execution.
>>
>> A ticker solves the timing problem by providing a channel that get new 
>> input every period. Keeping the timing separate mitigates the impact of 
>> execution on the timing period (e.g., it won’t be execution time + sleep 
>> time)
>>
>> Execution can be solved by ranging over the ticker channel. The contents 
>> of the loop will be run for each input received from the ticker channel. If 
>> the loop executes in less than one period, the loop will execute every 
>> period.
>>
>> Since tickers use channels, the execution loop can be run anywhere, 
>> though they are frequently used in goroutines because the program is also 
>> doing something else.
>>
>> I would simplify Rodolfo’s examples to:
>>
>> package main
>>
>> import (
>> "fmt"
>> "time"
>> )
>>
>> func square(x int) int {
>> return x * x
>> }
>>
>> func cube(x int) int {
>> return x * x * x
>> }
>>
>> func main() {
>> ticker := time.NewTicker(5 * time.Second)
>>
>> for range ticker.C {
>> fmt.Println(square(10))
>> fmt.Println(cube(10))
>> }
>> }
>>
>> This will run square and cube every 5 seconds while the program is 
>> executing.
>>
>> On Thursday, February 23, 2017 at 2:39:12 AM UTC+1, Keith Brown wrote:
>>>
>>> Oddly, I can't find a single example on the world wide web for what I am 
>>> trying to do.
>>>
>>> I have 2 functions which I want to run on a periodic basis. The 
>>> functions are square and cube. 
>>> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
>>> But, I am not sure how to schedule these functions.  I looked here, 
>>> https://gobyexample.com/tickers, but really isn't that helpful or 
>>> intuitive. 
>>>
>>>
>>>
>>>

-- 
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: NewTicker function example

[Sebastien Binet]

On Thu, Feb 23, 2017 at 12:37 PM, Nathan Kerr 
wrote:

> NewTicker function example
>
> The task of running functions on a periodic basis can be split into two
> parts: timing and execution.
>
> A ticker solves the timing problem by providing a channel that get new
> input every period. Keeping the timing separate mitigates the impact of
> execution on the timing period (e.g., it won’t be execution time + sleep
> time)
>
> Execution can be solved by ranging over the ticker channel. The contents
> of the loop will be run for each input received from the ticker channel. If
> the loop executes in less than one period, the loop will execute every
> period.
>
> Since tickers use channels, the execution loop can be run anywhere, though
> they are frequently used in goroutines because the program is also doing
> something else.
>
> I would simplify Rodolfo’s examples to:
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func square(x int) int {
> return x * x
> }
>
> func cube(x int) int {
> return x * x * x
> }
>
> func main() {
> ticker := time.NewTicker(5 * time.Second)
>
> for range ticker.C {
> fmt.Println(square(10))
> fmt.Println(cube(10))
> }
> }
>

don't forget to add a 'defer ticker.Stop()' :)
(especially in examples that might be copy-pasted)

-s


>
> This will run square and cube every 5 seconds while the program is
> executing.
>
> On Thursday, February 23, 2017 at 2:39:12 AM UTC+1, Keith Brown wrote:
>>
>> Oddly, I can't find a single example on the world wide web for what I am
>> trying to do.
>>
>> I have 2 functions which I want to run on a periodic basis. The functions
>> are square and cube.
>> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
>> But, I am not sure how to schedule these functions.  I looked here,
>> https://gobyexample.com/tickers, but really isn't that helpful or
>> intuitive.
>>
>>
>>
>> --
> 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] Re: correct/working 9p2000 library in Go?

[David Arroyo]

I'm the author of this one[1], and I hate to contribute to the OP's
initial complaint, but it is not complete. I plan to make it as easy
to use as net/http, but I can only find so much time to work on it.
I've also fixed a number of bugs that arose from my misunderstanding
of the protocol, so it would only be compliant by luck right now. I
did use it to write a toy server[2], so it's functional,  but
definitely a moving target.


Regards,

David



[1]: https://aqwari.net/net/styx

[2]: https://github.com/droyo/jsonfs (go get github.com/droyo/jsonfs)



On Thu, Feb 23, 2017, at 11:05 AM, Kare Nuorteva wrote:

> 

> Here's one that I found just recently: https://blog.aqwari.net/9P/

> 

> Cheers,

> Kare


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