Re: [go-nuts] Re: How to mock functions in Go ?

[Edward Muller]

This can also be done without an interface: 
https://play.golang.org/p/fgRX2nXIxn0

In ^ example “Thing” would be the type you are working on, with functional 
options 
(https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis 
), and 
defaults to using os.Hostname.

PS: Use whichever method works for you, this is just my opinions.

> On Aug 1, 2019, at 6:46 AM, Kyle Butz  wrote:
> 
> You'll want to look into gomock and mockgen.  To get started mocking, you'll 
> need an interface, so maybe writing a receiver function encapsulating 
> os.Hostname(), then consuming that with an interface.
> 
> type OsClient struct {}
> 
> func (o *OsClient) GetOSHostname() (string, error) { return os.Hostname() }
> 
> type HostnameGetter interface { GetOSHostname() (string, error) }
> 
> Gomock repo w/ documentation: https://github.com/golang/mock
> 
> Nice intros to gomock: 
> - https://blog.codecentric.de/en/2017/08/gomock-tutorial/
> - https://www.philosophicalhacker.com/post/getting-started-with-gomock/
> 
> Note to the mods: I accidentally posted this from the wrong, unverified 
> account first
> 
> On Thursday, August 1, 2019 at 7:09:54 AM UTC-5, Nitish Saboo wrote:
> Hi,
> 
> How can we mock a function in Go like os.Hostname() or os.Getwd() ?
> Any framework or Library that we can use for mocking the function calls ?
> 
> Thanks,
> Nitish
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2f288e99-70db-476b-8a4a-75069be9e31a%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/06D9DF57-C818-4A80-AFB2-7A53CB3ECC7B%40interlix.com.

Re: [go-nuts] How to implement a file download service in GRPC

[Edward Muller]

https://github.com/grpc-ecosystem/grpc-gateway 
 

> On Jul 30, 2019, at 4:12 PM, Rampradeep Nalluri  
> wrote:
> 
> It is easy to pipe a file reader to http.ResponseWriter object using 
> io.copy() when I implement a large file download service over REST. But how 
> do we handle similar requirement with gRPC server to REST client?
> 
> what is the standard way?
> 
> -Ram
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/903ac408-ff6c-4c0b-a4f7-801d4d6f7110%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/49B48CCF-5660-4337-A8FA-DEB56D27CE62%40interlix.com.

Re: [go-nuts] Re: Assign a string representation to an enum/const

[Edward Muller]

FWIW, I wouldn't use an "enum" (those don't exist in go) and would probably
do something like this: https://play.golang.org/p/J6_hssueao


On Wed, Apr 26, 2017 at 11:41 AM Tong Sun  wrote:

>
>
> On Tuesday, April 25, 2017 at 4:25:14 PM UTC-4, Tong Sun wrote:
>>
>>
>> On Tue, Apr 25, 2017 at 3:42 PM, Egon wrote:
>>
>> I think the extra "enum" package would reduce readability. The code you
>>> are putting into package is ~10 lines of code... so the extra package
>>> doesn't reduce much typing, but it also loses enum typing... Depending on
>>> the enum, you may want to have different properties as well...
>>> I chose the name "ciota" because of "custom-iota", in practice you would
>>> want something more descriptive such as "NewWeekday".
>>
>>
>> So the solution is easy, don't create a general purpose package for it :D
>>>
>>
>> OK.
>>
>> If going that route, and I have several enum series to define, I need to
>> define a series of almost identical functions, right? Hmm..., that'd be
>> really messy.
>>
>> Ok, I'll think of a better way on my own, which I doubt I could, :-)
>>
>
>
> Thought I need to use reflection, but after several round of wrestling, I
> managed to do without reflection at all:
>
>
> package main
>
>
> import (
>  "fmt"
>
>
>  enum "github.com/suntong/enum"
> )
>
>
> var (
>  example enum.Enum
>  Alpha   = example.Iota("Alpha")
>  Beta= example.Iota("Beta")
>
>
>  weekday enum.Enum
>  Sunday  = weekday.Iota("Sunday")
>  Monday  = weekday.Iota("Monday")
> )
>
>
> func main() {
>  fmt.Printf("%s\n", example.String(Alpha))
>  fmt.Printf("%s\n", example.String(Beta))
>
>  fmt.Println("===")
>  fmt.Printf("%d\t%d\n", Alpha, Alpha+1)
>
>  fmt.Printf("%s\t%s\n", example.String(Beta-1), example.String(Alpha+1))
>  fmt.Println("===")
>  if a, ok := example.Get("Alpha"); ok {
>  fmt.Printf("%d: %s\n", a, example.String(a))
>  }
>  if b, ok := example.Get("Beta"); ok {
>  fmt.Printf("%d: %+v\n", b, example.String(b))
>  }
>
>
>  fmt.Printf("%d:%s\n", Sunday, weekday.String(Sunday))
>  fmt.Printf("%d:%s\n", Monday, weekday.String(Monday))
> }
>
>
> The output:
>
> Alpha
> Beta
> ===
> 0   1
> Alpha   Beta
> ===
> 0: Alpha
> 1: Beta
> 0:Sunday
> 1:Monday
>
> Ref:
>
> https://github.com/suntong/lang/blob/master/lang/Go/src/ds/EnumsStr1p.go
>
> and
>
> https://github.com/suntong/enum
>
>
> --
> 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: invitation to gophers.slack.com

[Edward Muller]

Great!

On Fri, Jan 20, 2017 at 11:16 AM Jan Mercl <0xj...@gmail.com> wrote:

>
> On Fri, Jan 20, 2017 at 7:06 PM Edward Muller 
> wrote:
>
> > https://invite.slack.golangbridge.org/ instead, which is where people
> should go to signup for the slack channel.
>
> Thanks Edward, it worked.
> --
>
> -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] Re: invitation to gophers.slack.com

[Edward Muller]

The link Dave shared is some spreadsheet that is no longer used. I've
previously tried to track down the owner to ask them to take it down, but
haven't found them (If you are the owner of that spread sheet please take
it down).

If you are the owner of that bit.ly link (http://bit.ly/go-slack-signup),
please have it point to https://invite.slack.golangbridge.org/ instead,
which is where people should go to signup for the slack channel.

If anyone has a problem signing up please:
(a) Check you spam folder
(b) Contact supp...@golangbridge.org and an admin will get back to you.

Thanks!



On Fri, Jan 20, 2017 at 6:36 AM Jan Mercl <0xj...@gmail.com> wrote:

>
> On Tue, Dec 13, 2016 at 12:10 PM Damian Gryski  wrote:
>
> >  You must be a member of the Gophers Slack to see the message achive.
>
> This reminds me... In a long-ish time span, I more than once tried
> applying for membership using the link provided by Dave in this thread.
> Never got any response. Any ideas? TIA.
>
> --
>
> -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.
>

-- 
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] Is slice in golang thread-safe for appending

[Edward Muller]

Which may or may not have the same backing array.

https://play.golang.org/p/GsffpJc1cX

PS: I probably should have just said 'no. slices are not "thread-safe"'.  I
have complicated the issue to no benefit.

On Thu, Jan 19, 2017 at 2:56 PM Jason Stillwell  wrote:

> But it returns the new slice.
>
>
> On Thursday, January 19, 2017 at 2:40:30 PM UTC-8, freeformz wrote:
>
> No, it is not.*
>
> * appending can replace the underlying array, so in certain situations it
> can be, but that's more by accident IMO so just don't rely on that.
>
> On Thu, Jan 19, 2017 at 1:43 PM xiaohai dai  wrote:
>
> I know that map in golang is not thread-safe for writing.
> However, I'm not sure slice/array is thread-safe for writing. I have
> searched the related posts and blogs in google, but find no unambiguous
> statement.
>
> Thanks in advance!
>
> --
> 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.
>

-- 
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] Is slice in golang thread-safe for appending

[Edward Muller]

No, it is not.*

* appending can replace the underlying array, so in certain situations it
can be, but that's more by accident IMO so just don't rely on that.

On Thu, Jan 19, 2017 at 1:43 PM xiaohai dai  wrote:

> I know that map in golang is not thread-safe for writing.
> However, I'm not sure slice/array is thread-safe for writing. I have
> searched the related posts and blogs in google, but find no unambiguous
> statement.
>
> Thanks in advance!
>
> --
> 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] Downloading go1

[Edward Muller]

Thank You!

On Fri, Dec 2, 2016 at 5:25 PM Brad Fitzpatrick  wrote:

> Thanks!
>
>
> On Fri, Dec 2, 2016 at 4:53 PM, Will Norris  wrote:
>
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.darwin-386.pkg
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.darwin-amd64.pkg
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.freebsd-386.tar.gz
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.freebsd-amd64.tar.gz
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.linux-386.tar.gz
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.linux-amd64.tar.gz
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.src.tar.gz
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.windows-386.msi
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.windows-386.zip
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.windows-amd64.msi
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go.go1.windows-amd64.zip
>
> On Fri, Dec 2, 2016 at 4:17 PM, Brad Fitzpatrick 
> wrote:
>
> I've asked for a list of our objects under that prefix.
>
>
> On Thu, Dec 1, 2016 at 1:56 PM, Edward Muller 
> wrote:
>
> For $reasons I need to download the original linux amd64 version of go1.
>
> Older go versions are stored under
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/
>
> I have retrieved go1.0.1 (
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz)
> and later successfully.
>
> But I can't seem to find the right key for go1. I've tried:
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.linux-amd64.tar.gz
> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1-linux-amd64.tar.gz
> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.linux-amd64.tar.gz
> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0-linux-amd64.tar.gz
> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0.linux-amd64.tar.gz
> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0-linux-amd64.tar.gz
> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>
> All respond with:
>  encoding='UTF-8'?>NoSuchKeyThe specified key
> does not exist.
>
> I've also tried the getting an index (
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go
> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>/),
> like you can with https://storage.googleapis.com/golang/ (where modern go
> releases are stored), but that just returns the same error.
>
> Can anyone point me to the right https://storage.googleapis.com url for
> the go1 release?
>
> 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] Re: Downloading go1

[Edward Muller]

I could, but for other $reasons I'd rather not if I don't have to.

I will if it's lost to history though.

On Thu, Dec 1, 2016 at 2:10 PM James Bardin  wrote:

>
> Can you build it from source?
> The repo of course contains the entire history.
>
>
>
> On Thursday, December 1, 2016 at 4:57:30 PM UTC-5, freeformz wrote:
>
> For $reasons I need to download the original linux amd64 version of go1.
>
> Older go versions are stored under
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/
>
> I have retrieved go1.0.1 (
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz)
> and later successfully.
>
> But I can't seem to find the right key for go1. I've tried:
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.linux-amd64.tar.gz
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1-linux-amd64.tar.gz
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.linux-amd64.tar.gz
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0-linux-amd64.tar.gz
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0.linux-amd64.tar.gz
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0-linux-amd64.tar.gz
> 
>
> All respond with:
>  encoding='UTF-8'?>NoSuchKeyThe specified key
> does not exist.
>
> I've also tried the getting an index (
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go
> /),
> like you can with https://storage.googleapis.com/golang/ (where modern go
> releases are stored), but that just returns the same error.
>
> Can anyone point me to the right https://storage.googleapis.com url for
> the go1 release?
>
> 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] Downloading go1

[Edward Muller]

For $reasons I need to download the original linux amd64 version of go1.

Older go versions are stored under
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/

I have retrieved go1.0.1 (
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz)
and later successfully.

But I can't seem to find the right key for go1. I've tried:
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.linux-amd64.tar.gz

https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1-linux-amd64.tar.gz

https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.linux-amd64.tar.gz

https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0-linux-amd64.tar.gz

https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0.linux-amd64.tar.gz

https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0-linux-amd64.tar.gz


All respond with:
NoSuchKeyThe specified key
does not exist.

I've also tried the getting an index (
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go
/),
like you can with https://storage.googleapis.com/golang/ (where modern go
releases are stored), but that just returns the same error.

Can anyone point me to the right https://storage.googleapis.com url for the
go1 release?

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] Noob question: Pointers to interfaces

[Edward Muller]

Sounds like it's also more than a map[type]interface{} and more like either
 map[type][]interface{} or a map[type]map[uuid]interface{}. And that's
somewhat naive as well.

I'd probably implement a method to store and fetch each "type" that the ECS
could actually care about, which could probably be generated (see `go help
generate`). That may be too onerous though depending on *how* the ECS would
be used. I don't have much use for systems like that in what I normally
work on.

The actual storage of the data may also require a more sophisticated setup
than a single top level map as well.

There is probably a better way to model a system like this in Go, but I
don't know what it is.


On Mon, Nov 7, 2016 at 8:27 PM Kaylen Wheeler  wrote:

Keep in mind: at this point, I'm only playing around with a Go
implementation.

What I'm trying to do is implement an Entity-Component-System.  Each entity
consists of a collection of components, each of which may have a different
type.

The first thing I'm trying to implement is an easy way to look up
components by their type and assign them to a variable that points to that
type.

I want to avoid writing something like  foo :=
e.GetComponent(reflect.TypeOf(&Foo{}))

That seems unnecessarily verbose.

I also want to avoid explicit type-casting for the same reason.

On Monday, 7 November 2016 19:52:06 UTC-8, freeformz wrote:

Based on that example, I'm even more confused about what you are trying to
accomplish.

Can we take a step back and forget about the implementation of a solution
and describe the problem you are working on?

On Mon, Nov 7, 2016 at 19:08 Kaylen Wheeler  wrote:

Here's what I have so far: https://play.golang.org/p/X2z7Yl9UPg

I think it works for my purposes.  However, I'm confused about one thing:
 Why does reflect.Value.Set panic when passed a zero-value?



On Monday, 7 November 2016 16:56:52 UTC-8, freeformz wrote:

Then just use pointers (see lines 45+): https://play.golang.org/p/vl47WDHOdN

On Mon, Nov 7, 2016 at 4:50 PM Kaylen Wheeler  wrote:

I want pointers because I want most components to be structs, and I want
the ability to modify the fields in those structs.

On Monday, 7 November 2016 16:46:17 UTC-8, freeformz wrote:

Why do you want to use pointers?

On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler  wrote:

Thanks for the "basic pattern" example here.  There's one little
modification I'm wondering about.

Can this line:

rv.Elem().Set(m[rv.Type()])

be changed to this?

rv.Elem().Set(*&*m[rv.Type()])

If so, how can we check that the input value is a pointer to a pointer.

Or alternatively, is it better that the values in m should be pointers?


On Monday, 7 November 2016 16:01:53 UTC-8, adon...@google.com wrote:

On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote:

I'm trying to find a typesafe way to access a type-indexed map of
components.  This map can contain objects of any type, and the keys are
reflect.Type.

One strategy I thought may work would be to pass a pointer to a pointer as
an out-var.  Using reflection to determine the pointer's type, it could be
populated with a corresponding value.

For instance, if we did something like this:

c := ComponentCollection{}
c.addComponent(123) // Add an int component

var p : *int
c.getComponent(&p)


In this case, p would point to the int component of c.

That's wht the 2 levels of indirection are necessary: it's an out-var to a
pointer.

Does that make sense?


Here's the basic pattern:

var m = make(map[reflect.Type]reflect.Value)

func addComponent(x interface{}) {
   v := reflect.ValueOf(x)
   m[v.Type(x)] = v
}

func getComponent(ptr interface{}) {
   rv := reflect.ValueOf(ptr)
   if rv.Kind() != reflect.Pointer {
panic("not a pointer")
   }
   rv.Elem().Set(m[rv.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...@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...@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...@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.

Re: [go-nuts] Noob question: Pointers to interfaces

[Edward Muller]

Based on that example, I'm even more confused about what you are trying to
accomplish.

Can we take a step back and forget about the implementation of a solution
and describe the problem you are working on?
On Mon, Nov 7, 2016 at 19:08 Kaylen Wheeler  wrote:

> Here's what I have so far: https://play.golang.org/p/X2z7Yl9UPg
>
> I think it works for my purposes.  However, I'm confused about one thing:
>  Why does reflect.Value.Set panic when passed a zero-value?
>
>
>
> On Monday, 7 November 2016 16:56:52 UTC-8, freeformz wrote:
>
> Then just use pointers (see lines 45+):
> https://play.golang.org/p/vl47WDHOdN
>
> On Mon, Nov 7, 2016 at 4:50 PM Kaylen Wheeler  wrote:
>
> I want pointers because I want most components to be structs, and I want
> the ability to modify the fields in those structs.
>
> On Monday, 7 November 2016 16:46:17 UTC-8, freeformz wrote:
>
> Why do you want to use pointers?
>
> On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler  wrote:
>
> Thanks for the "basic pattern" example here.  There's one little
> modification I'm wondering about.
>
> Can this line:
>
> rv.Elem().Set(m[rv.Type()])
>
> be changed to this?
>
> rv.Elem().Set(*&*m[rv.Type()])
>
> If so, how can we check that the input value is a pointer to a pointer.
>
> Or alternatively, is it better that the values in m should be pointers?
>
>
> On Monday, 7 November 2016 16:01:53 UTC-8, adon...@google.com wrote:
>
> On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote:
>
> I'm trying to find a typesafe way to access a type-indexed map of
> components.  This map can contain objects of any type, and the keys are
> reflect.Type.
>
> One strategy I thought may work would be to pass a pointer to a pointer as
> an out-var.  Using reflection to determine the pointer's type, it could be
> populated with a corresponding value.
>
> For instance, if we did something like this:
>
> c := ComponentCollection{}
> c.addComponent(123) // Add an int component
>
> var p : *int
> c.getComponent(&p)
>
>
> In this case, p would point to the int component of c.
>
> That's wht the 2 levels of indirection are necessary: it's an out-var to a
> pointer.
>
> Does that make sense?
>
>
> Here's the basic pattern:
>
> var m = make(map[reflect.Type]reflect.Value)
>
> func addComponent(x interface{}) {
>v := reflect.ValueOf(x)
>m[v.Type(x)] = v
> }
>
> func getComponent(ptr interface{}) {
>rv := reflect.ValueOf(ptr)
>if rv.Kind() != reflect.Pointer {
> panic("not a pointer")
>}
>rv.Elem().Set(m[rv.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...@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...@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] Noob question: Pointers to interfaces

[Edward Muller]

Then just use pointers (see lines 45+): https://play.golang.org/p/vl47WDHOdN

On Mon, Nov 7, 2016 at 4:50 PM Kaylen Wheeler  wrote:

I want pointers because I want most components to be structs, and I want
the ability to modify the fields in those structs.

On Monday, 7 November 2016 16:46:17 UTC-8, freeformz wrote:

Why do you want to use pointers?

On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler  wrote:

Thanks for the "basic pattern" example here.  There's one little
modification I'm wondering about.

Can this line:

rv.Elem().Set(m[rv.Type()])

be changed to this?

rv.Elem().Set(*&*m[rv.Type()])

If so, how can we check that the input value is a pointer to a pointer.

Or alternatively, is it better that the values in m should be pointers?


On Monday, 7 November 2016 16:01:53 UTC-8, adon...@google.com wrote:

On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote:

I'm trying to find a typesafe way to access a type-indexed map of
components.  This map can contain objects of any type, and the keys are
reflect.Type.

One strategy I thought may work would be to pass a pointer to a pointer as
an out-var.  Using reflection to determine the pointer's type, it could be
populated with a corresponding value.

For instance, if we did something like this:

c := ComponentCollection{}
c.addComponent(123) // Add an int component

var p : *int
c.getComponent(&p)


In this case, p would point to the int component of c.

That's wht the 2 levels of indirection are necessary: it's an out-var to a
pointer.

Does that make sense?


Here's the basic pattern:

var m = make(map[reflect.Type]reflect.Value)

func addComponent(x interface{}) {
   v := reflect.ValueOf(x)
   m[v.Type(x)] = v
}

func getComponent(ptr interface{}) {
   rv := reflect.ValueOf(ptr)
   if rv.Kind() != reflect.Pointer {
panic("not a pointer")
   }
   rv.Elem().Set(m[rv.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...@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] Noob question: Pointers to interfaces

[Edward Muller]

Why do you want to use pointers?

On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler  wrote:

> Thanks for the "basic pattern" example here.  There's one little
> modification I'm wondering about.
>
> Can this line:
>
> rv.Elem().Set(m[rv.Type()])
>
> be changed to this?
>
> rv.Elem().Set(*&*m[rv.Type()])
>
> If so, how can we check that the input value is a pointer to a pointer.
>
> Or alternatively, is it better that the values in m should be pointers?
>
>
> On Monday, 7 November 2016 16:01:53 UTC-8, adon...@google.com wrote:
>
> On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote:
>
> I'm trying to find a typesafe way to access a type-indexed map of
> components.  This map can contain objects of any type, and the keys are
> reflect.Type.
>
> One strategy I thought may work would be to pass a pointer to a pointer as
> an out-var.  Using reflection to determine the pointer's type, it could be
> populated with a corresponding value.
>
> For instance, if we did something like this:
>
> c := ComponentCollection{}
> c.addComponent(123) // Add an int component
>
> var p : *int
> c.getComponent(&p)
>
>
> In this case, p would point to the int component of c.
>
> That's wht the 2 levels of indirection are necessary: it's an out-var to a
> pointer.
>
> Does that make sense?
>
>
> Here's the basic pattern:
>
> var m = make(map[reflect.Type]reflect.Value)
>
> func addComponent(x interface{}) {
>v := reflect.ValueOf(x)
>m[v.Type(x)] = v
> }
>
> func getComponent(ptr interface{}) {
>rv := reflect.ValueOf(ptr)
>if rv.Kind() != reflect.Pointer {
> panic("not a pointer")
>}
>rv.Elem().Set(m[rv.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] Noob question: Pointers to interfaces

[Edward Muller]

This was also my swag at an example: https://play.golang.org/p/QG7g9veKEI

PS: it's still not strictly "type safe".

On Mon, Nov 7, 2016 at 4:46 PM Edward Muller  wrote:

> Why do you want to use pointers?
>
> On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler 
> wrote:
>
> Thanks for the "basic pattern" example here.  There's one little
> modification I'm wondering about.
>
> Can this line:
>
> rv.Elem().Set(m[rv.Type()])
>
> be changed to this?
>
> rv.Elem().Set(*&*m[rv.Type()])
>
> If so, how can we check that the input value is a pointer to a pointer.
>
> Or alternatively, is it better that the values in m should be pointers?
>
>
> On Monday, 7 November 2016 16:01:53 UTC-8, adon...@google.com wrote:
>
> On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote:
>
> I'm trying to find a typesafe way to access a type-indexed map of
> components.  This map can contain objects of any type, and the keys are
> reflect.Type.
>
> One strategy I thought may work would be to pass a pointer to a pointer as
> an out-var.  Using reflection to determine the pointer's type, it could be
> populated with a corresponding value.
>
> For instance, if we did something like this:
>
> c := ComponentCollection{}
> c.addComponent(123) // Add an int component
>
> var p : *int
> c.getComponent(&p)
>
>
> In this case, p would point to the int component of c.
>
> That's wht the 2 levels of indirection are necessary: it's an out-var to a
> pointer.
>
> Does that make sense?
>
>
> Here's the basic pattern:
>
> var m = make(map[reflect.Type]reflect.Value)
>
> func addComponent(x interface{}) {
>v := reflect.ValueOf(x)
>m[v.Type(x)] = v
> }
>
> func getComponent(ptr interface{}) {
>rv := reflect.ValueOf(ptr)
>if rv.Kind() != reflect.Pointer {
> panic("not a pointer")
>}
>rv.Elem().Set(m[rv.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] Noob question: Pointers to interfaces

[Edward Muller]

FWIW: As soon as interface{} is involved you are no longer "type safe".

On Mon, Nov 7, 2016 at 2:56 PM Kaylen Wheeler  wrote:

> So, what I'm trying to accomplish is a little unusual, and may need some
> explanation.
>
> Basically, I'm trying to find a typesafe way to access a type-indexed map
> of components.  This map can contain objects of any type, and the keys are
> reflect.Type.
>
> One strategy I thought may work would be to pass a pointer to a pointer as
> an out-var.  Using reflection to determine the pointer's type, it could be
> populated with a corresponding value.
>
> For instance, if we did something like this:
>
> c := ComponentCollection{}
> c.addComponent(123) // Add an int component
>
> var p : *int
> c.getComponent(&p)
>
>
> In this case, p would point to the int component of c.
>
> That's wht the 2 levels of indirection are necessary: it's an out-var to a
> pointer.
>
> Does that make sense?
>
> --
> 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] Tooling experience feedback

[Edward Muller]

We have so many Makefiles that encode $(go list ./... | grep -v vendor) in
one way or another it IS kind of funny. A `novendor` flag of some sort to
most tools that take package specs would be so so so so nice.

On Thu, Oct 27, 2016 at 8:56 AM Russ Cox  wrote:

> FWIW 'go help all' is essentially 'go doc go'.
>
> On Fri, Oct 21, 2016 at 9:46 AM Mathieu Lonjaret <
> mathieu.lonja...@gmail.com> wrote:
>
> As you said, sometimes one is not sure in which X for "go help X" one
> might find the information they're looking for. So one can end up
> trying several of them before finding the relevant info. I can think
> of one way that would alleviate that pain a bit: something like a "go
> help all" command that would print all the topics in one go. Makes it
> easier to pipe it to grep/less and search for specific things.
>
>
> On 18 October 2016 at 20:54, 'Jaana Burcu Dogan' via golang-nuts
>  wrote:
> > Hello gophers,
> >
> > I am going to spend some time on improving the not-documented or
> hard-to-use
> > parts of the Go tools. I will mainly focus on go build and go test. The
> work
> > will consist of reorganizing manuals, proposing new subcommands or flags
> to
> > support commonly used multi-step things and so on.
> >
> > To give you some concrete examples:
> >
> > I have been in cases where users cannot find the build flags because they
> > are hidden. E.g.
> >
> > $ go test -help
> > test [build/test flags] [packages] [build/test flags & test binary
> > flags]
> > ...
> >
> > requires you to know about where the build flags are. Some tools are
> > invisible for the newcomers.
> >
> > The other example is about test coverage. It is so tedious that I need an
> > alias.
> >
> > func gocover() {
> > go test -v -coverprofile=coverage.out && go tool cover
> > -html=coverage.out
> > }
> >
> > I want to learn more about your experience, aliases, etc to propose
> > improvements and work on the most commonly suggested items. I also am
> > planning to go through this mailing list, stack overflow and other
> channels
> > to see the common complaints.
> >
> > Feel free to reply to this thread or write to me privately.
> >
> > Thanks,
> > JBD
> >
> > --
> > 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.

Re: [go-nuts] Re: Golang should have a center packages index hosting like npm, rust crates

[Edward Muller]

Yes, use that proposal's format.

Re: godoc. Great idea. if no one else is interested in doing the work I'll
be happy to take a look into it. I've been looking for an excuse to work
with gddo

On Wed, Oct 26, 2016 at 1:42 PM Dave Cheney  wrote:

> Indeed. If only there was some standard we could use
>
>
> https://github.com/golang/proposal/blob/master/design/12302-release-proposal.md#tag-format
>
> On Thu, Oct 27, 2016 at 6:08 AM, Nate Finch  wrote:
> > Listing versions on godoc is an awesome idea.  Peer pressure goes a long
> way
> > toward changing individual minds and eventually a community.  Something
> as
> > simple as sorting projects with tagged versions higher and displaying
> them
> > prominently on the project's godoc page (with the ability to look at
> godoc
> > for each version) would go a long way toward encouraging people to tag
> their
> > releases.  I know it would get me off my butt to tag my projects.
> >
> > On Wednesday, October 26, 2016 at 11:37:54 AM UTC-4, mbohu...@gmail.com
> > wrote:
> >>
> >> I was just wondering whether a simple list of available versions at the
> >> top of a package's godoc.org page wouldn't somehow force package
> authors to
> >> start tagging. There could be some kind of message if there are no
> available
> >> versions.
> >> There would obviously have to be some benefit for those who tag, or some
> >> restriction for those who don't, in order to change the current
> situation.
>
> --
> 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: Golang should have a center packages index hosting like npm, rust crates

[Edward Muller]

Please start tagging your releases with semver tags.

Start now, there is no reason to wait.
On Wed, Oct 26, 2016 at 03:13 Dave Cheney  wrote:

> I'd very much like to see that.
>
> https://github.com/golang/go/issues/12302
>
> http://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases
>
>
> On Wednesday, 26 October 2016 21:02:54 UTC+11, Haddock wrote:
>
>
> Am Mittwoch, 26. Oktober 2016 11:50:08 UTC+2 schrieb Dave Cheney:
>
> I am agreeing with Haddocks post, sorry if the groups interface did not
> respect the thread of discussion.
>
>
> What about a versioning experiment as with the vendor experiment?
>
> --
> 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] Go 1.7.3 is released

[Edward Muller]

See: https://github.com/golang/go/issues/17519 &
https://github.com/golang/go/issues/17276

On Wed, Oct 19, 2016 at 1:48 PM Tim Henderson  wrote:

> I can reproduce that error. Here is my `go env` output the test output is
> identical.
>
> $ go env
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/hendersont/stuff/code/godev"
> GORACE=""
> GOROOT="/home/hendersont/srcs/go"
> GOTOOLDIR="/home/hendersont/srcs/go/pkg/tool/linux_amd64"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build052830685=/tmp/go-build
> -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
>
> On Wednesday, October 19, 2016 at 4:10:42 PM UTC-4, Jan Mercl wrote:
>
> On Wed, Oct 19, 2016 at 9:45 PM Chris Broadfoot  wrote:
>
> > We have just released Go version 1.7.3, a minor point release.
>
> Package time fails test.
>
> [snip]
>
>
> ok   text/template/parse 0.009s
> --- FAIL: TestLoadFixed (0.00s)
> time_test.go:943: Now().In(loc).Zone() = "-01", -3600, want "GMT+1", -3600
>
>
>
> --
> 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: Reading http.Request.Body...

[Edward Muller]

There is also ReadAtLeast (https://golang.org/pkg/io/#ReadAtLeast)

On Tue, Oct 11, 2016 at 3:13 PM forfader  wrote:

> Thank you. I figured there was such a function. Just couldn't find it.
>
> Michael-
>
>
> On Tuesday, October 11, 2016 at 2:31:41 PM UTC-7, forfader wrote:
>
> I'm reading the Body of an HTTP request. In my handler I want to chunk the
> response body up into fixed size blocks. I doing this using the following
> code:
>
> b := make([]byte, config.Blocksize)
> for {
> cnt, err := r.Body.Read(b)
> if err == io.EOF {
> break
> }
> if err != nil {
> log.Error("Reading reading request stream", "name", name)
> utils.WriteError(w, http.StatusInternalServerError, "Error reading request
> stream")
> return
> }
>
> log.Info("Length read", "len", cnt)
> }
>
> What I'm seeing is various block sizes being read from the Body reader. I
> assume that is because the bytes coming over the http stream are not coming
> fast enough to keep up with my executing code, and so when r.Body.Read is
> executed I get how ever many bytes are currently available on the stream
> and not more.
>
> Is there easy way to read fixed size blocks from the request body reader
> using a built in library function? Say bytes, or bufio. I looked but could
> not see a function.
>
> I can imagine doing this myself, with multiple reads inside the for loop.
>
> Thanks
> Michael-
>
> --
> 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: [ANN] gorram: like go run for any* function in stdlib or GOPATH

[Edward Muller]

gorram -r <...>

On Mon, Oct 10, 2016 at 3:02 PM Mathieu Lonjaret 
wrote:

> Looks shiny!
> But is there some sort of cache I have to clear? I've just updated and
> rebuilt, and I still get the old behaviour.
>
>
> On 8 October 2016 at 04:05, Nate Finch  wrote:
> > ...and now it works like you'd hope :)
> >
> >
> > $ gorram net/http Get https://npf.io/gorram/run
> >  > href="https://npf.io/gorram/"/> > content="text/html; charset=utf-8" /> > content="0;url=https://npf.io/gorram/"; />
> >
> > or if you want to get fancy:
> >
> > $ gorram net/http Get https://npf.io/gorram/run | gorram
> > github.com/yosssi/gohtml Format
> > 
> > 
> >   
> > https://npf.io/gorram/"/>
> > 
> > https://npf.io/gorram/"; />
> >   
> > 
> >
> > --
> > 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] Correct use of Mutex

[Edward Muller]

type Foo struct {
  sync.RWMutex
  data map[string]bool
}

o := &Foo{}
o.Lock()
o.data[i] = true
o.Unlock()

elsewhere 
o.RLock()
v := o.data[i]
o.RUnlock()


On Mon, Oct 3, 2016 at 11:55 AM  wrote:

>
> Which is correct?
>
> o.Lock()
> o.data[i] = true
> o.Unlock()
>
> or
>
> o.Lock()
> i.RLock()
> o.data[i] = true
> i.RUnlock()
> o.Unlock()
>
> The latter actually seems to help high contention R/W operations on a very
> large map according to the guy in my team who was working on the problem,
> but I would have thought the former example is correct.
>
> Thanks for your advice.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] encode struct as JSON, and use it in http.NewRequest ( io.Writer vs. io.Reader issue )H

[Edward Muller]

See also https://golang.org/pkg/io/#Pipe

On Sat, Oct 1, 2016 at 9:13 PM Shawn Milochik  wrote:

> How about https://golang.org/pkg/bytes/#NewReader ?
>
> --
> 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] Mocking os.Open and related calls for more code coverage

[Edward Muller]

One option is to adjust the method to take an io.ReadCloser instead of a
path so you could pass in anything that supported the io.ReadCloser
interface (which is easily adapted to via ioutil.NoCloser(io.Reader)).

Another option is to generate a temporary file with data you want to test
with and pass that in.

Which one to use (or both for that matter) depend on many external factors.

On Tue, Sep 27, 2016 at 9:37 AM  wrote:

> Hello
>
> may be it is a trivial question but I could not find any usable answer to
> the following requirement therefore I thought that
> surely some of you have the answer
>
> Let's assume I have some code like follows:
>
> func (obj *myObjStruct) MyFn(fsPath string) (myRetType, error) {
> cpath := path.Join(fsPath, "subdir", "input.txt")
> fh, err := os.Open(cpath)
> if err != nil {
> log.Error(fmt.Sprintf("Got error %#v", err))
> return nil, err
> }
> defer fh.Close()
> scanner := bufio.NewScanner(fh)
> for scanner.Scan() {
> inLine := scanner.Text()
> ...
>
>
> How should I proceed to mock the os.Open and scanner.xxx calls so that I
> can exercise the remaining parts of the code (... above)
>
> May be I need to rewrite this function a little bit before being able to
> do so but I obviously would not agree to lose the benefits of defering
> fh.Close() call
>
> Thanks for any advice/pointer/...
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@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] How Golang implements slice?

[Edward Muller]

Doh. I keep forgetting about a[low : high : max], but also want to point
out that if that if the slice is modified by the func beyond cap then the
backing array will be swapped out anyway and your slice header doesn't know
about the swap or the new cap.

On Tue, Sep 13, 2016 at 5:00 AM Val  wrote:

> Hello Ding
> Actually you don't need unsafe or reflect to access the 4th element :
> https://play.golang.org/p/wZAkKtAZei
> See section "Full slice expressions"
> <https://golang.org/ref/spec#Slice_expressions> in spec about 3-index
> slicing like  a[low : high : max]
>
> You were correct in deducing that slices are descriptor values "passed
> around" by value, while the backing array contents are accessed by
> reference through the pointer contained in the slice descriptor.  This
> structure must be well understood by the programmer to avoid headaches.  My
> rules of thumb are :
> - avoid pointer to slice e.g.  *[]int
> - never call append without assigning back to the same variable
> - be careful with concurrency  e.g.  append is not safe to call
> concurrently
> - be careful about which piece of code "owns" the backing array.  This is
> important when several functions try to read, write, grow a slice.
> Problems may arise even without goroutines.
> - the result of append may use the same backing array as its argument, or
> not. You shouldn't rely on either way.
>
> Cheers
> Valentin
>
>
> On Tuesday, September 13, 2016 at 10:15:19 AM UTC+2, Fei Ding wrote:
>
>> Thanks, Edward, you make a good point.
>>
>> What's more, I wrote more code yesterday, and found that we can in fact
>> get the 4th element even if the descriptor tells us there are only 3, by
>> using package unsafe <https://golang.org/pkg/unsafe/>, and doing some
>> simple pointer calculation. It shows that function calls may modify the
>> slice in parameters under the cover, which is a bad thing if it is not on
>> purpose. I will keep this in mind.
>>
>> Thanks.
>>
>>
>>
>>
>> 2016-09-13 12:09 GMT+08:00 Edward Muller :
>>
>>>
>>>
>>> On Mon, Sep 12, 2016 at 8:17 PM Fei Ding  wrote:
>>>
>>>> Hi guys:
>>>>
>>>> I met a problem when I try to understand slice when using as function
>>>> parameters. After writing some code, I made a conclusion by myself, but
>>>> need some real check and explanation here, with your help.
>>>>
>>>> As far as I know, Golang's function parameters are passed by value, and
>>>> slice could be treated as a descriptor, which seems like *{pointer to
>>>> first element of underlying array, length of element, capacity of array}*
>>>> according to Go Slices: usage and internals
>>>> <https://blog.golang.org/go-slices-usage-and-internals>. So, can I say:
>>>>
>>>> *When passing a slice as a function parameter, it is, in fact, passing
>>>> a pointer, and two int values (or as a whole struct, or maybe more
>>>> parameters to describe the slice, whatever).*
>>>>
>>>> To make it clear using code:
>>>>
>>>> func foo(s []T) {...}
>>>> // can this function be treated as following 3-parameter function?
>>>> func foo(p Pointer, length, capa int) {...}
>>>>
>>>> // Note: type is not the point here,
>>>> //   and we just need 3 parameters, while there maybe more
>>>>
>>>> You may wonder why I have this question? Here is where everything
>>>> started:
>>>>
>>>> func foo(s []int) {
>>>>  s := []int{1,2,3}
>>>>  foo(s)
>>>>  fmt.Println(s)
>>>> }
>>>>
>>>> Everyone know it will print [1 2 3], not [1 2 3 100]. But what I am
>>>> interested in, is *whether the function call does modify the memory*
>>>> just after the tail of element 3, to an int of 100. If my assumption above
>>>> is right, then the modification may happen.
>>>>
>>>> So, I made some experiments.
>>>>
>>>> package main
>>>>
>>>> import "fmt"
>>>> import "strconv"
>>>>
>>>> type Node struct {
>>>> val int
>>>> left *Node
>>>> right *Node
>>>> }
>>>>
>>>> func (n Node) String () string {
>>>> return strconv.Itoa(n.val)
>>>> }
>>>>
>>>> func newNode(val int) *Node {
>>>> return &N

Re: [go-nuts] How Golang implements slice?

[Edward Muller]

On Mon, Sep 12, 2016 at 8:17 PM Fei Ding  wrote:

> Hi guys:
>
> I met a problem when I try to understand slice when using as function
> parameters. After writing some code, I made a conclusion by myself, but
> need some real check and explanation here, with your help.
>
> As far as I know, Golang's function parameters are passed by value, and
> slice could be treated as a descriptor, which seems like *{pointer to
> first element of underlying array, length of element, capacity of array}*
> according to Go Slices: usage and internals
> . So, can I say:
>
> *When passing a slice as a function parameter, it is, in fact, passing a
> pointer, and two int values (or as a whole struct, or maybe more parameters
> to describe the slice, whatever).*
>
> To make it clear using code:
>
> func foo(s []T) {...}
> // can this function be treated as following 3-parameter function?
> func foo(p Pointer, length, capa int) {...}
>
> // Note: type is not the point here,
> //   and we just need 3 parameters, while there maybe more
>
> You may wonder why I have this question? Here is where everything started:
>
> func foo(s []int) {
>  s := []int{1,2,3}
>  foo(s)
>  fmt.Println(s)
> }
>
> Everyone know it will print [1 2 3], not [1 2 3 100]. But what I am
> interested in, is *whether the function call does modify the memory* just
> after the tail of element 3, to an int of 100. If my assumption above is
> right, then the modification may happen.
>
> So, I made some experiments.
>
> package main
>
> import "fmt"
> import "strconv"
>
> type Node struct {
> val int
> left *Node
> right *Node
> }
>
> func (n Node) String () string {
> return strconv.Itoa(n.val)
> }
>
> func newNode(val int) *Node {
> return &Node{val, nil, nil}
> }
>
> // Given a binary tree and a target sum, find all root-to-leaf paths
> // where each path's sum equals the given sum
> func bs(root *Node, path []*Node, now int, target int, ret *[][]*Node) {
> if root == nil {
> return
> }
> path = append(path, root)
> now += root.val
> if now == target && root.left == nil && root.right == nil {
> *ret = append(*ret, path)
> return
> }
> bs(root.left, path, now, target, ret)
> bs(root.right, path, now, target, ret)
> }
>
> func main() {
> // a simple tree like:
> //0
> //   / \
> //  1   2
> root := newNode(0)
> left := newNode(1)
> right := newNode(2)
> root.left = left
> root.right = right
>
> ret := [][]*Node{}
> bs(root, make([]*Node, 0, 10), 0, 1, &ret)
> fmt.Println(ret)
> }
>
>
> As the code above, it is a function to find all root-to-leaf paths where
> each path's sum equals the given sum in a binary tree, and, I make a simple
> test case which there are only 3 nodes: one root, two children, with values
> of 0, 1 and 2.
>
> Say, I want to find the paths of sum of 1. So, I call this function as:
>
> bs(root, make([]*Node, 0, 10), 0, 1, &ret)
>
> It is petty common to make a guess that, this call will give us a final
> result of [0, 1], which is obviously the correct answer, however, it gives
> us [0, 2], try yourself if you don't believe:
>
> https://play.golang.org/p/hSKIOaVK2S
>
> The algorithm here is correct, don't worry about it. Instead, please pay
> attention to the second parameter of bs(). It makes a slice which has no
> element in it, and has a capacity of 10. What if we change this parameter
> to:
>
> bs(root, make([]*Node, 0, 1), 0, 1, &ret)
>
> Yes, just make the slice's capacity as 1. This time you will get the right
> answer, [0, 1]. Try yourself if you are interested.
>
> Here is my understanding of this strange problem, feel free to point out
> anything wrong:
>
> Still the simplest code:
>
> package main
>
> import (
> "fmt"
> )
>
> func foo(s []int) {
> fmt.Println(len(s), cap(s))   // 3 3
> s = append(s, 100)
> fmt.Println(len(s), cap(s))   // 4 8
> }
>
> func main() {
> s := []int{1,2,3}
> foo(s)
> fmt.Println(len(s), cap(s))   // 3 3
> fmt.Println(s)// [1 2 3]
> }
>
> When the function foo() called, it has 3 parameters: a pointer of the
> first element of the array, which points to the element 1, an int for array
> length: 3, an int for array capacity: 3.  In foo(), it tries to append 100
> at the tail, but there is no room for it, according to the parameter of
> capacity it receive, so, it makes a larger array, which capacity is 8, then
> do some copy-and-append job. Unfortunately, all the work it does is useless
> because all three parameters is still themselves. So, at last, it prints [1
> 2 3]
>
> But, what will happen if the slice passed into foo() is large enough
> already?
>
> package main
>
> import (
> "fmt"
> )
>
> func foo(s []int) {
> fmt.Println(len(s), cap(s))   // 3 10
> s = append(s, 100)
> fmt.Println(len(s), cap(s))   // 4 10
> }
>
> func main() {
> s := make([]int, 3, 10)
> s[0], s[1], s[2] = 1, 2, 3
> foo(s)
> fmt.Println(len(s), cap(s))   // 3 10
> fmt.Println(s)// [1 2 3]
> }
>
> Now, foo() is lucky, he do

Re: [go-nuts] Best way to extract hostname from "host" or "host:port" style?

[Edward Muller]

There is probably some code here (
https://github.com/golang/go/commit/1ff19201fd898c3e1a0ed5d3458c81c1f062570b)
you can lift until go1.8 comes out.

On Mon, Sep 12, 2016 at 8:17 PM Jonathan Yu  wrote:

> Hi,
>
> I tried searching Google, but didn't find anything. I'm probably just
> missing something obvious here, but I'm relatively new to Go - please bear
> with me :)
>
> In URLs (of the net/url variety), the Host field may be either a hostname
> or host/port combination.  In the combined host/port case, we can use
> net.SplitHostPort to isolate the host/port portions, but if a port isn't
> specified, then we'll get an error.
>
> We can use the same code as in SplitHostPort ("last" to check if the
> string contains a colon):
> https://github.com/golang/go/blob/master/src/net/ipsock.go#L119 but this
> is a bit less convenient than having SplitHostPort return the host directly
> (though I understand this may not be changeable without breaking API
> compatibility)
>
> Is there an easier way to say "give me the host/port if the input is
> host:port, or host otherwise?" Alternately, some way to check for the error
> type might be useful (similar to how os.IsNotExist(err) works) -- my way of
> doing it (simply checking for a colon) seems like it'd be problematic with
> IPv6 addresses.
>
> Thanks!
>
> Jonathan
>
> --
> 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: job queue with the ability to kill worker processes

[Edward Muller]

There is also: https://github.com/bgentry/que-go

On Tue, Sep 6, 2016 at 12:56 PM Tieson Molly  wrote:

> Thanks Jason,  I was looking for something to handle external processes.
>
>
>
> On Monday, September 5, 2016 at 11:13:59 AM UTC-4, Jason E. Aten wrote:
>>
>> On Thursday, September 1, 2016 at 4:40:50 AM UTC-7, Tieson Molly wrote:
>>>
>>> Are there any go projects that implement a queue where workers that
>>> consume the queue could be tracked and potentially killed if the end user
>>> decides to cancel the job?
>>>
>>
>> I assume you mean across multiple worker processes; possibly all on one
>> host or possibly in a distributed fashion. My goq project, pronounced "go
>> queue",
>>
>> https://github.com/glycerine/goq
>>
>> let's you cancel a job, using "goq kill ". Workers that were
>> started with "goq work" will die after oneshot at work. Workers that were
>> started with "goq work forever" will keep requesting jobs.
>>
>> If you mean within a single process, this is common and readily
>> implemented using channels. The stdlib's "net/context" has even
>> standardized an interface to such requests. I'll keep this short. Feel free
>> to let me know if you meant in-process and need more detail.
>>
> --
> 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] why this code deadlocks?

[Edward Muller]

Thanks, I should have checked the spec.

On Thu, Sep 1, 2016 at 11:14 AM Darren Hoo  wrote:

> I don't think so.
>
> see https://golang.org/ref/spec#Select_statements
>
> If one or more of the communications can proceed, a single one that can
> proceed is chosen via a uniform pseudo-random selection. Otherwise, if
> there is a default case, that case is chosen.
>
> So if the done channel has been sent, the first case will be selected and
> f will not be called anymore.
>
> On Friday, September 2, 2016 at 1:58:04 AM UTC+8, freeformz wrote:
>
>> I think you can still deadlock, but I'm not sure if the `default:` case
>> is considered for random selection of a select like other branches are. It
>> would just be less deterministic.
>>
>> On Thu, Sep 1, 2016 at 10:38 AM Darren Hoo  wrote:
>>
>>> Got it, using buffered channel works for me
>>>
>>> ints := make(chan int, 1)
>>> done := make(chan bool, 1)
>>>
>>> go func() {
>>> for i := 0; i < 100; i++ {
>>> ints <- i
>>> }
>>> close(ints)
>>> }()
>>>
>>> f := func() {
>>> j := 0
>>> for {
>>> i, ok := <-ints
>>> if !ok {
>>> done <- true
>>> return
>>> }
>>> j++
>>>
>>> fmt.Println(i)
>>>
>>> //10 ints for one batch
>>> if j == 10 {
>>> return
>>> }
>>> }
>>> }
>>>
>>> exit:
>>> for {
>>> f()
>>>
>>> select {
>>> case <-done:
>>> fmt.Println("Exiting")
>>> break exit
>>> default:
>>> //do nothing just next f()
>>> }
>>> }
>>>
>>>
>>>
>>> On Friday, September 2, 2016 at 1:30:10 AM UTC+8, freeformz wrote:
>>>
 If you execute it you are told on which lines the deadlock happens...

 fatal error: all goroutines are asleep - deadlock!

 goroutine 1 [chan send]:
 main.main.func2()
 /Users/emuller/go/src/github.com/freeformz/tt/main.go:25 +0xce
 main.main()
 /Users/emuller/go/src/github.com/freeformz/tt/main.go:37 +0x118
 exit status 2

 main.go:25 is the line that says `done <- true`.

 The `done` channel isn't buffered and the first loop through will
 select that path, but there is not another goroutine selecting from done.
 so f() never returns. Deadlock.

 On Thu, Sep 1, 2016 at 10:04 AM Darren Hoo  wrote:

>>> var wg sync.WaitGroup
>
> ints := make(chan int, 1)
> done := make(chan bool)
>
> go func() {
> for i := 0; i < 3; i++ {
> ints <- i
> }
> close(ints)
> }()
>
> f := func() {
> wg.Add(1)
> defer wg.Done()
>
> for {
> i, ok := <-ints
> if !ok {
> done <- true
> return
> }
> }
> }
>
> exit:
> for {
> select {
> case <-done:
> break exit
> default:
> f()
> }
> }
> wg.Wait()
>
>
>
> --
> 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...@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] on GOPATH

[Edward Muller]

For projects that are mostly not go (or go is a component anyway) you could
do $HOME/project/src/ and then point $GOPATH=$HOME/project.
You can use 2 different segments in $GOPATH (GOPATH=/foo/bar:/bar/foo) and
go get will place go gettable packages in the first segment of $GOPATH.

On Thu, Sep 1, 2016 at 10:57 AM Maurizio Vitale  wrote:

> hello gophers,
>
> How people do use GOPATH?
>
> having a single workspace for all my projects doesn't really work for me.
> Some project might involve more than a go portion and really shoehorning
> them into a go tree doesn't sound right.
>
> I'm completely fine with switching GOPATH every time I switch project and
> there's a benefit in having the complete environment in the same tree. but
> how people handle internal include paths? the only thing I can think of is
> symlinking from down into the project path so that you can import as if you
> were from(say) github.com/user/project.
>
> And even if switching, there're certain things I want to 'go get' and
>  share across all projects. For instance godep and the such. I could switch
> GOPATH, go get and then just add the bin directory to PATH. Is this what
> people do? or do they have a complete set of tools per project (even this
> is defendible and I'm not completely against it)
>
> please enlighten me, 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] why this code deadlocks?

[Edward Muller]

I think you can still deadlock, but I'm not sure if the `default:` case is
considered for random selection of a select like other branches are. It
would just be less deterministic.

On Thu, Sep 1, 2016 at 10:38 AM Darren Hoo  wrote:

> Got it, using buffered channel works for me
>
> ints := make(chan int, 1)
> done := make(chan bool, 1)
>
> go func() {
> for i := 0; i < 100; i++ {
> ints <- i
> }
> close(ints)
> }()
>
> f := func() {
> j := 0
> for {
> i, ok := <-ints
> if !ok {
> done <- true
> return
> }
> j++
>
> fmt.Println(i)
>
> //10 ints for one batch
> if j == 10 {
> return
> }
> }
> }
>
> exit:
> for {
> f()
>
> select {
> case <-done:
> fmt.Println("Exiting")
> break exit
> default:
> //do nothing just next f()
> }
> }
>
>
>
> On Friday, September 2, 2016 at 1:30:10 AM UTC+8, freeformz wrote:
>
>> If you execute it you are told on which lines the deadlock happens...
>>
>> fatal error: all goroutines are asleep - deadlock!
>>
>> goroutine 1 [chan send]:
>> main.main.func2()
>> /Users/emuller/go/src/github.com/freeformz/tt/main.go:25 +0xce
>> main.main()
>> /Users/emuller/go/src/github.com/freeformz/tt/main.go:37 +0x118
>> exit status 2
>>
>> main.go:25 is the line that says `done <- true`.
>>
>> The `done` channel isn't buffered and the first loop through will select
>> that path, but there is not another goroutine selecting from done. so f()
>> never returns. Deadlock.
>>
>> On Thu, Sep 1, 2016 at 10:04 AM Darren Hoo  wrote:
>>
> var wg sync.WaitGroup
>>>
>>> ints := make(chan int, 1)
>>> done := make(chan bool)
>>>
>>> go func() {
>>> for i := 0; i < 3; i++ {
>>> ints <- i
>>> }
>>> close(ints)
>>> }()
>>>
>>> f := func() {
>>> wg.Add(1)
>>> defer wg.Done()
>>>
>>> for {
>>> i, ok := <-ints
>>> if !ok {
>>> done <- true
>>> return
>>> }
>>> }
>>> }
>>>
>>> exit:
>>> for {
>>> select {
>>> case <-done:
>>> break exit
>>> default:
>>> f()
>>> }
>>> }
>>> wg.Wait()
>>>
>>>
>>>
>>> --
>>> 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.
>

-- 
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 this code deadlocks?

[Edward Muller]

If you execute it you are told on which lines the deadlock happens...

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main.func2()
/Users/emuller/go/src/github.com/freeformz/tt/main.go:25 +0xce
main.main()
/Users/emuller/go/src/github.com/freeformz/tt/main.go:37 +0x118
exit status 2

main.go:25 is the line that says `done <- true`.

The `done` channel isn't buffered and the first loop through will select
that path, but there is not another goroutine selecting from done. so f()
never returns. Deadlock.

On Thu, Sep 1, 2016 at 10:04 AM Darren Hoo  wrote:

> var wg sync.WaitGroup
>
> ints := make(chan int, 1)
> done := make(chan bool)
>
> go func() {
> for i := 0; i < 3; i++ {
> ints <- i
> }
> close(ints)
> }()
>
> f := func() {
> wg.Add(1)
> defer wg.Done()
>
> for {
> i, ok := <-ints
> if !ok {
> done <- true
> return
> }
> }
> }
>
> exit:
> for {
> select {
> case <-done:
> break exit
> default:
> f()
> }
> }
> wg.Wait()
>
>
>
> --
> 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] dynamic frequency ticker

[Edward Muller]

How about something like this? https://play.golang.org/p/U50n3cqIXg

On Tue, Aug 30, 2016 at 12:42 PM Aaron Cannon <
cann...@fireantproductions.com> wrote:

> How about creating a custom ticker that uses time.Sleep.  There might
> be some hidden caveats when using time.Sleep verses a real ticker that
> I am unaware of, but it might meet your needs.  You could then add a
> custom method, or inbound channel, which you could use to tweak its
> intervals on the fly.
>
> Aaron
>
> On 8/30/16, seb.st...@gmail.com  wrote:
> > In my application I select on a ticker channel, but sometimes need to
> have
> > the waiting time vary a bit. For not so frequent changes I could make a
> new
> >
> > ticker everytime, but I have the feeling this is not the best solution
> for
> > higher frequencies and many rate changes. Best would be if I could tell
> my
> > existing ticker "from next tick on please use an interval of x". In fact
> > what I want is that the frequency changes over time.
> >
> > Any tips how to achieve that?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to golang-nuts+unsubscr...@googlegroups.com.
> > 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] Invalid JSON document from 'go list -json std'

[Edward Muller]

`go list -json std | jq` does not complain, which is my usual "is my json
valid" test.

On Sat, Aug 20, 2016 at 12:13 PM Lars Tørnes Hansen 
wrote:

> I expected that
> go list -json std
> ... would output a valid JSON document, because
> go help list
> writes:
> The -json flag causes the package data to be printed in JSON format
> instead of using the template format.
> but ...
>
>- The JSON document is not a JSON array
>- Between 2 JSON objects of type build.Package: A comma is missing
>
> go version go1.7 linux/amd64
>
> Have I misunderstood something?
>
> --
> 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] Best practice for sets in go?

[Edward Muller]

I encourage people to use the later form because of the duality of a bool
(true or false) and the fact that it implies meaning. When you see the bool
you have to start considering the false path. I'd much prefer the extra few
bytes for the longer inclusion checks because there is no ambiguity in the
check.

On Tue, Jul 26, 2016 at 9:27 AM Tyler Compton  wrote:

> In my opinion, struct{} should always be used for placeholders. I also use
> it when sending to a channel where the data itself doesn't matter. struct{}
> looks gross but it's very expressive in this case and I think most all Go
> programmers are familiar with its meaning.
>
> map[string]bool suggests that the bool value has some kind of
> significance. Sure, the documentation you put in probably says otherwise,
> but the bool type is still unnecessary indirection.
>
> This issue is made worse if one uses the if m[key] { ... } idiom for the
> reason that Sam Whited brought up. Plus, then the bool has a meaning, but
> it's only for the purpose of slightly shortening code instead of using a
> well-known Go pattern. Why bother making the meaning of the map more
> complicated?
>
> if _, ok = m[key]; ok {
> }
>
> Is something Go programmers are used to.
>
> if m[ok] {
> }
>
> Requires that the programmer take a look at the map and its documentation
> to see what's going on unless they're already used to that pattern in the
> code base.
>
> On Tuesday, July 26, 2016 at 7:07:08 AM UTC-7, Sam Whited wrote:
>
>> On Tue, Jul 26, 2016 at 6:35 AM, Dave Cheney  wrote:
>> > If saving one byte per entry is important for your application, the
>> latter is your choice. The former has nicer properties that you can use the
>> single value form of map access,
>> >
>> > if m[key] {
>> >// found
>> > }
>> >
>> > I'd say the former is the right choice for 97.25% of general use cases.
>>
>> I'd agree with this, except that I don't trust that one guy in the
>> office not to sneak past something that somehow puts a false in the
>> map and causes bugs later. Arguably that's a review problem, but even
>> so one or two extra bytes of code (`_, ok = m[key]; ok') seems like a
>> small price to pay for safety guarantees and to save a few bytes of
>> memory.
>>
>> (though as you said, it hardly matters either way; I just prefer to
>> recommend the struct{} version to new people)
>>
>> —Sam
>>
>>
>> --
>> Sam Whited
>> pub 4096R/54083AE104EA7AD3
>>
> --
> 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] GoBridge Appreciation Breakfast @ GopherCon

[Edward Muller]

We (Heroku) are sponsoring the Gophercon 2016 kickoff breakfast of gratitude: 
http://www.meetup.com/gobridge/events/229149949/ 


Please sign up if you are interested.

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] String Split Question

[Edward Muller]

https://play.golang.org/p/fOFT2voh6l 

> On Jul 5, 2016, at 2:57 PM, Freeman Fridie  wrote:
> 
> I have a data file with records in the following format:
> 
> [field 1][field 2][field 3][field 4]...
> 
> I need to be able to split the record into fields using  [ ] as the 
> delimeter.   I assume I need to use regex, but I'm unsure how to proceed.
> 
> 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] encoding/json: any way to receive number literal "10.0" into integer field?

[Edward Muller]

AFAIK (and someone will probably provide something better) you need to do 
something like this: 

https://play.golang.org/p/riq-m6cgZu

> On Jun 17, 2016, at 2:37 PM, jg...@bitgirder.com wrote:
> 
> We have an upstream provider of JSON data which sends integer data
> types as floating point literals with a "0" decimal part. By default
> json.Decoder doesn't allow this and fails:
> 
>https://play.golang.org/p/MEJlg1n3vs
> 
> Unfortunately this provider is almost certain not to change this, and
> so we just have to deal with it as clients of their API. What are some
> ways we could handle this?
> 
> Things that come to mind:
> 
>- Submit a change to encoding/json that allows us to set some sort
>  of number processing function to customize its behavior (or to
>  set some sort of policy which allows number literals ending in
>  \.0*$ for integer targets)
> 
>- Create a custom io.Reader which wraps in input stream by reading
>  individual tokens from it using an internal json.Decoder, and
>  then emits number literals without trailing ".0". 
> 
>- Buffer all inbound decodes into a map[string]interface{} and set
>  the decoder to UseNumber(), and then replace those json.Numbers
>  with corrected ones, then serialize back and decode once more
>  into the destination (this is similar to the token-stream
>  approach above)
> 
> Are there other approaches I'm overlooking?
> 
> jonathan
> 
> -- 
> 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.