[go-nuts] Re: When do you recommend not using composition?

['Aaron Rubesh' via golang-nuts]

I would recommend reading up on how to implement Go interfaces.

The only requirement required to satisfy the io.Writer interface is a 
method Write([]byte)(int,error). If this method is present, Go can then 
interpret your struct as a io.Writer.

By itself, io.Writer provides no functionality only a definition. That is 
left to the struct to fulfill. 
On Friday, April 28, 2023 at 4:16:24 PM UTC-5 Nitin Muppalaneni wrote:

> Is there a reason why `http.ResponseWriter` does not include io.Writer 
> directly and instead has the `Write([]byte) (int, error)` method? Why did 
> you choose to do it this way? I can see that it adds a dependency on the io 
> package. Was that the concern?
>
> And more generally, when would you recommend not using composition of 
> interfaces?
>
> Thanks
> Nitin
>
>

-- 
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/f8b6844a-72af-460f-a29a-4bb2d9e60a96n%40googlegroups.com.

Re: [go-nuts] Underlying type constraints and pointers

['Aaron Beitch' via golang-nuts]

Thanks for your help here! You helped me realize the thing I really want 
access to is the methods of Foo and Bar, and not the struct fields (my 
example was misleading).

What I would really like to have is a constraint that the type must have an 
underlying type of Foo, but that isn't working how I want. So, what I can 
do instead is define an interface that includes the methods that Foo 
provides and use that as my constraint. https://go.dev/play/p/BwEb8Lm4pb6

Aaron

On Friday, October 21, 2022 at 10:44:57 PM UTC-7 axel.wa...@googlemail.com 
wrote:

> Actually (maybe I should stop, think, and then E-Mail) this works: 
> https://go.dev/play/p/SBDglnj8mQx
> I'm not sure if the selector X(*a).data will actually copy the value, but 
> I don't *think* it does.
> I also tried this first: https://go.dev/play/p/3qUhyOkvcVm
> The fact that this doesn't work looks like a bug to me, to be honest.
>
> On Sat, Oct 22, 2022 at 7:36 AM Axel Wagner  
> wrote:
>
>> Sorry, I literally just fell out of bed, so I jumped on the first thing I 
>> saw, which probably isn't the most helpful answer.
>> You might be interested in this sentence from the Go 1.18 release notes 
>> <https://go.dev/doc/go1.18#generics>:
>>
>> The Go compiler does not support accessing a struct field x.f where x is 
>>> of type parameter type even if all types in the type parameter's type set 
>>> have a field f. We may remove this restriction in a future release.
>>
>>  
>> So while what I said is correct - the underlying type of Bar *isnt* Foo - 
>> I think the more disappointing fact is that what you want to do just won't 
>> work for now. It might in the future, but not right now.
>>
>> On Sat, Oct 22, 2022 at 7:12 AM Axel Wagner  
>> wrote:
>>
>>> (or, for convenience, you can use a type alias `type foo = struct{ data 
>>> []string }`, which should allow you to write ~foo.
>>>
>>> On Sat, Oct 22, 2022 at 7:11 AM Axel Wagner  
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Oct 22, 2022 at 1:40 AM 'Aaron Beitch' via golang-nuts <
>>>> golan...@googlegroups.com> wrote:
>>>>
>>>>> I have types Foo and Bar. Bar's underlying type is Foo.
>>>>>
>>>>
>>>> The underlying type is defined recursively and always either a 
>>>> predeclared type (int, string…), or a type literal.
>>>> The underlying type of Bar is the underlying type of Foo, which is 
>>>> struct { data []string }. You might try using `~struct{ data []string }`.
>>>>  
>>>>
>>>>> I want a function that takes in pointers to types whose underlying 
>>>>> type is Foo, but I get a compile error when trying to call this function:
>>>>>
>>>>> *Bar does not implement ~*Foo (*Bar missing in ~*main.Foo)
>>>>>
>>>>> Should this work?
>>>>>
>>>>> My real use case is around a hash map library. It's implementation is 
>>>>> a copy of Go's built-in map, but allows the user to control the equal and 
>>>>> hash function, thus allowing keys of any type rather than just comparable 
>>>>> types. github.com/aristanetworks/gomap
>>>>>
>>>>> I would like to provide helper functions 
>>>>> <https://github.com/aristanetworks/gomap/blob/main/funcs.go> for 
>>>>> gomap.Map similar to those provided by golang.org/x/exp/maps and for 
>>>>> those helpers to work on pointers to types whose underlying type is 
>>>>> gomap.Map.
>>>>>
>>>>> Thanks,
>>>>> Aaron
>>>>>
>>>>>
>>>>> -- 
>>>>> 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.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/golang-nuts/d6c4621a-13d8-4cd2-b777-eef7a200cca2n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/golang-nuts/d6c4621a-13d8-4cd2-b777-eef7a200cca2n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>>

-- 
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/5b049c16-2dfc-43eb-bde1-e9627a08ab27n%40googlegroups.com.

[go-nuts] Underlying type constraints and pointers

['Aaron Beitch' via golang-nuts]

Hello,

I would like to provide some helper functions that work on pointer types 
and having trouble getting it to work with ~ type constraints.

Here is the problem in code: https://go.dev/play/p/z0sKEsUaL_d

I have types Foo and Bar. Bar's underlying type is Foo. I want a function 
that takes in pointers to types whose underlying type is Foo, but I get a 
compile error when trying to call this function:

*Bar does not implement ~*Foo (*Bar missing in ~*main.Foo)

Should this work?

My real use case is around a hash map library. It's implementation is a 
copy of Go's built-in map, but allows the user to control the equal and 
hash function, thus allowing keys of any type rather than just comparable 
types. github.com/aristanetworks/gomap

I would like to provide helper functions 
<https://github.com/aristanetworks/gomap/blob/main/funcs.go> for gomap.Map 
similar to those provided by golang.org/x/exp/maps and for those helpers to 
work on pointers to types whose underlying type is gomap.Map.

Thanks,
Aaron


-- 
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/d6c4621a-13d8-4cd2-b777-eef7a200cca2n%40googlegroups.com.

Re: [go-nuts] Non-mutable / readonly slices?

[Aaron Rubesh]

In general, no. Each time you pass around a []byte you are actually passing 
around a copy of a pointer to the slice. Modifications will affect the 
underlying slice. 
You can use arrays instead, which are always PBV.
Take care though, if you try to pass an array to a function accepting a 
slice via arr[:] you will still end up modifying the underlying slice 
values. 

Examples: https://go.dev/play/p/qeUebAeXZAK

On Thursday, October 20, 2022 at 8:48:01 AM UTC-5 Ian Lance Taylor wrote:

> On Thu, Oct 20, 2022 at 5:46 AM Slawomir Pryczek  
> wrote:
> >
> > Hi Guys, writing a quick K/V caching system and have a performance 
> related question.
> >
> > Will be operating on []byte, for the system to be thread safe we need to 
> create a copy of data before each SET so we're sure that the slice which 
> gets added to pool can't be modified. This shouldn't be problematic, but 
> there's a problem with GET.
> >
> > For the system to be thread-safe we need to isolate the returned slice 
> from the data pool so if we do, eg. x := Get("key_abc") we won't create 
> issues by later doing x[1]='a'. So we'll need to create a copy of whole key 
> for each GET. We will have very few SETs but millions of GETs. So is it 
> possible for the slice to be not-mutable like strings are or you can 
> suggest some other approach?
>
> What if you simply return a string? If the caller must not modify the
> returned data, a string is more or less the same as a []byte.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/78f9482a-f795-48b6-a6d3-170c1cf4f8e3n%40googlegroups.com.

[go-nuts] Is there a better way to write this?

['Aaron Spangler' via golang-nuts]

I seem to be regularly working with maps of stringsets and I have
found myself writing the same pattern over and over and I ended up
having my own utility function.  More importantly the syntax seems
clunky when a key doesn't exist in the map.  Is there a better way (go
idiomatically way) to write this?

import  "google3/third_party/golang/stringset/stringset"

var urlMap = make(map[string]*stringset.Set)

func collectStringsetMap(m map[string]*stringset.Set, key string,
value ...string) *stringset.Set {
  s, ok := m[key]
  if !ok {
newset := stringset.New()  // Why can't I just use &(stringset.New()) ?
s = 
m[key] = s
  }
  s.Add(value...)
  return s
}

If there is a way to clean up the code, let me know.

Also why can map's just take a default function to construct items
that are not yet present?
Something like:

var urlMap = make(map[string]*stringset.Set, ...func =
defaultStringsetConstructor...)

func defaultStringsetConstructor(key string) *stringset.Set {
  n := stringset.New()
  return 
}

Or perhaps some trickery in the map lookup?

 s, ok := m[key, defaultStringsetConstructor]

At the end of the day you want the map to save any new items that were
not already in the map, but I don't see any less clunky ways of doing
this.  (What am I missing?)

-- 
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/CAHP%2Bjq5zX69g5S88_G03CZyHMoC_xGPXxqZfbc%3DKg0FRi8%3DMgQ%40mail.gmail.com.

Re: [go-nuts] Taking single value from multi-return function and inlining function calls

[Aaron Rubesh]

Another option for this is if your function is always called after the call to 
the external library, you can change your function signature to match the 
return value of the external library.

Its quite common to see something like this:

`
func A() (int, error) {}

func UseA(a int, err error) (int, error) {
  if err != nil {return err}
  
}

...

UseA(A())
`

Get Outlook for Android

From: 'Axel Wagner' via golang-nuts 
Sent: Monday, August 29, 2022 3:58:38 AM
To: Tanmay Das 
Cc: golang-nuts 
Subject: Re: [go-nuts] Taking single value from multi-return function and 
inlining function calls

You could write helpers:

func Left[A, B any](a A, b B) A { return a }
func Right[A, B any](a A, b B) B { return b }

Which you can then insert

useOne(Left(returnMany())
useOne(Right(returnMany())

But TBQH, I would not consider this good style. It ultimately adds more noise 
and overhead, as people now have to figure out what Left and Right do (you 
might argue that they should be named better, but still).

The right thing to do here, in my opinion, is to just accept the extra 
statement. Yes, it's a little bit more noisy. But it's not a dramatic enough 
different to justify deviating from what the core language gives you.

On Mon, Aug 29, 2022 at 10:43 AM Tanmay Das 
mailto:tanmaymi...@gmail.com>> wrote:
Hi,

I am relatively new to the Go language, and I have always wanted to ask this 
question:

Consider the following snippet:

package main

import "fmt"

func returnMany() (int, int) {
return 4, 2
}

func useOne(value int) {
fmt.Println(value)
}

func main() {
useOne(returnMany())
}

The returnMany function returns multiple values and the useOne function accepts 
only a single value. I have often come across situations where the returnMany() 
resides in my codebase and the useOne() comes from an external library.

The code above obviously fails to build. Typically as a consumer of "useOne" 
package, I know which value it expects and I can either do this:

value, _ := returnMany()
useOne(value)

Or, this, depending on my need:

_, value := returnMany()
useOne(value)

This makes inlining function calls impossible and adds a little bit of noise to 
the codebase, IMO.

Is there a way I can inline this without introducing a temp variable? 
Pseudocode example:

useOne(returnMany()[1]) // 4
useOne(returnMany()[2]) // 2

https://go.dev/play/p/gxKsnRKUAFY


--
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/80fbcec2-0ee2-4cde-ac31-de495cb97c20n%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/CAEkBMfEvVVrHjBH8RZ7QBrHjsiqXFzqSveKsZhd7of6ZxoWCjw%40mail.gmail.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/SN6PR04MB4622548B447EFE3105B9A65CA1769%40SN6PR04MB4622.namprd04.prod.outlook.com.

Re: [go-nuts] Is Go a security malware risk?

[Aaron Rubesh]

To this day the most prevalent,  evasive and destructive malware is developed 
in C/C++... So may as well ban those languages too!!

Seriously, if your answer to 'stopping malware written in Go'  is to ban all 
applications written in Go,  your security team needs some more training budget 
or you need to get a new team altogether.

Banning a language because 'the AV we pay 10mil a year for doesn't catch it'  
is an insane thought process.

Get Outlook for Android


From: golang-nuts@googlegroups.com  on behalf of 
Robert Engels 
Sent: Tuesday, August 23, 2022, 09:49
To: Brian Candler 
Cc: golang-nuts 
Subject: Re: [go-nuts] Is Go a security malware risk?

I think what is being suggested that if the sec team bans all applications that 
exhibit dynamic code loading behavior they’d be safer - which would catch a lot 
of apps in the net.

On Aug 23, 2022, at 10:44 AM, Brian Candler  wrote:


On Tuesday, 23 August 2022 at 15:30:49 UTC+1 Gopher-Insane wrote:
The issue is not a vulnerability in the language itself but the use of that 
language to embed malware so AV signatures do not detect it. The feeling is 
that our InfoSec will be wanting to restrict obscure languages (Go, Rust 
etc...).

And how exactly does choosing not to use Go/Rust in your own organization, 
avoid you from getting infected by malware written in Go/Rust?

--
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/a465a7ff-3e13-458d-a7f8-61c0375c38a7n%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/CD882B25-875C-48BF-9AC2-C3E003B38451%40ix.netcom.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/SN6PR04MB4622C5AFD39130B92312B07DA1709%40SN6PR04MB4622.namprd04.prod.outlook.com.

[go-nuts] Parse JSON case-sensitively

['Aaron' via golang-nuts]

Hi all

Anyone know of a JSON package (or other solution) which is case-sensitive 
when decoding - and is also mature, simple, and parses into a struct?
I've looked at a few open-source packages, but the ones I've found seem to 
be focused on performance, or allowing you to access the JSON in different 
ways, or require code-generation, or something.
Really I just want a drop-in replacement for encoding/json that is case 
sensitive.
Wondering about forking the package myself... but obviously don't want to 
do that if there's an existing solution.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a3d25416-2490-4719-a38c-9f6a43008184n%40googlegroups.com.

Re: [go-nuts] Build error from pragma warnings when doing "go build -buildmode=c shared..."

[Aaron Epstein]

Removing gcc 4.1.2 from PATH so it picked up 4.9.4 which resolved this 
issue.

Still would be good to know if it is possible to know which gcc go is 
using...

On Thursday, May 20, 2021 at 9:46:34 AM UTC-4 Aaron Epstein wrote:

> gcc
>
> Is there a way to see which version go is picking up? I have both 4.9.4 
> and 4.1.2. I suspect it is picking up 4.1.2 and this is the cause, but is 
> there a way to tell?
>
> On Thursday, May 20, 2021 at 9:36:57 AM UTC-4 Ian Lance Taylor wrote:
>
>> On Thu, May 20, 2021, 4:47 AM Aaron Epstein  wrote:
>>
>>>
>>> I am seeing a compiler error when building a shared c library from a go 
>>> program. The error is:
>>>
>>> GO111MODULE=on go build -buildmode=c-shared -o mylib.so myfile.go
>>> # runtime/cgo
>>> cc1: warnings being treated as errors
>>> _cgo_export.c:6: warning: ignoring #pragma GCC diagnostic
>>> _cgo_export.c:7: warning: ignoring #pragma GCC diagnostic
>>> _cgo_export.c:8: warning: ignoring #pragma GCC diagnostic
>>>
>>> CGO_ENABLED=1 is set as well. This is using go 1.13. Any ideas?
>>>
>>
>> What C compiler are you using?  What version?
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/352236d1-1f21-4602-b250-154c44a5fc01n%40googlegroups.com.

Re: [go-nuts] Build error from pragma warnings when doing "go build -buildmode=c shared..."

[Aaron Epstein]

gcc

Is there a way to see which version go is picking up? I have both 4.9.4 and 
4.1.2. I suspect it is picking up 4.1.2 and this is the cause, but is there 
a way to tell?

On Thursday, May 20, 2021 at 9:36:57 AM UTC-4 Ian Lance Taylor wrote:

> On Thu, May 20, 2021, 4:47 AM Aaron Epstein  wrote:
>
>>
>> I am seeing a compiler error when building a shared c library from a go 
>> program. The error is:
>>
>> GO111MODULE=on go build -buildmode=c-shared -o mylib.so myfile.go
>> # runtime/cgo
>> cc1: warnings being treated as errors
>> _cgo_export.c:6: warning: ignoring #pragma GCC diagnostic
>> _cgo_export.c:7: warning: ignoring #pragma GCC diagnostic
>> _cgo_export.c:8: warning: ignoring #pragma GCC diagnostic
>>
>> CGO_ENABLED=1 is set as well. This is using go 1.13. Any ideas?
>>
>
> What C compiler are you using?  What version?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bf6644e9-6ad9-48cd-a754-40ccec1fb1ecn%40googlegroups.com.

[go-nuts] Build error from pragma warnings when doing "go build -buildmode=c shared..."

[Aaron Epstein]

Hi,

I am seeing a compiler error when building a shared c library from a go 
program. The error is:

GO111MODULE=on go build -buildmode=c-shared -o mylib.so myfile.go
# runtime/cgo
cc1: warnings being treated as errors
_cgo_export.c:6: warning: ignoring #pragma GCC diagnostic
_cgo_export.c:7: warning: ignoring #pragma GCC diagnostic
_cgo_export.c:8: warning: ignoring #pragma GCC diagnostic

CGO_ENABLED=1 is set as well. This is using go 1.13. Any ideas?

Thanks,
Aaron

-- 
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/09123e31-2032-42c0-b449-70d783ddbcecn%40googlegroups.com.

Re: [go-nuts] Referencing a library name in a cgo comment whose name is known at build time

[Aaron Epstein]

I've managed to workaround this using cgo pkg-config.

Before doing go build, I generate a .pc file that has the necessary library 
names, includes, etc.
My go files now use
// #cgo pkg-config: mylib

A little bit hacky, but it works.

On Wednesday, April 28, 2021 at 12:03:53 PM UTC-4 Ian Lance Taylor wrote:

> On Wed, Apr 28, 2021 at 8:41 AM Aaron Epstein  wrote:
> >
> > I have a C library that I am linking with from Go whose name is known at 
> build-time, and is not a constant I can write in a comment like
> > // #cgo LDFLAGS: -lmylib
> >
> > The library name is parameterized, i.e. libmy{VAR_NAME}lib.so
> >
> > Cgo doesn't seem to be able to handle environment variables, so I don't 
> think I can do
> > // #cgo LDFLAGS: -lmy{VAR_NAME}lib
> >
> > And I don't have the option of setting the library name to be constant. 
> Is there a way I can link with cgo here?
>
> Perhaps you can use "go build -ldflags=-extldflags=-lmylib". I don't
> know whether that will work for your case.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4d7f452b-a71e-444f-a8a9-3ffd506aad3fn%40googlegroups.com.

[go-nuts] Referencing a library name in a cgo comment whose name is known at build time

[Aaron Epstein]

Hi,

I have a C library that I am linking with from Go whose name is known at 
build-time, and is not a constant I can write in a comment like
// #cgo LDFLAGS: -lmylib 

The library name is parameterized, i.e. libmy{VAR_NAME}lib.so

Cgo doesn't seem to be able to handle environment variables, so I don't 
think I can do
// #cgo LDFLAGS: -lmy{VAR_NAME}lib

And I don't have the option of setting the library name to be constant. Is 
there a way I can link with cgo here?

Thanks,
Aaron


-- 
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/78bd6917-8776-4efd-9f4e-4472d895833en%40googlegroups.com.

Re: [go-nuts] Generics: More on parens

[Aaron Cannon]

Thanks Ian for the reply.

I certainly understand wanting to get more experience with the
proposed syntax, but I still don't think the trade-offs are worth it.
In particular, I remain concerned about the cognitive load of using
parens in yet another context, and the (IMHO) unnecessary breaking of
backwards compatibility, even if only in very few cases.

Moving away from parens to something like what I proposed would, I
believe, remove all the ambiguities identified in the proposal. var f
func(x(T)) would become the unambiguous var f func(x.)

x2 := []T.{} as opposed to needing yet another set of parens.

And so on for the other parsing ambiguities mentioned in the proposal.

To be clear, I don't think it has to be the syntax I propose, but I do
think it should be easily recognizable as unique by the parser and
humans alike.

The reason I favor the <> syntax is that <> is well known from C++
(and maybe other languages?) as denoting something dealing with
generics. I also like the .<> for instantiation because it resembles
type assertion .(). Type assertion is essentially collapsing a broader
type to a narrower type, which is sort of what type instantiation is
doing if you squint a bit. :)

Anyway, just my $0.02. Thanks again for all the hard work on this.

Aaron

On 6/16/20, Ian Lance Taylor  wrote:
> On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
>  wrote:
>>
>> I, like many others, am not fond of all the parenthesis, particularly at
>> call sites. I think at definition sites, it's not so bad. It seems like
>> the only objection to < and > are the complexity it adds for parsing. It
>> also seems like the only place it adds ambiguity is at call or
>> enstantiation sites. So what if we used .> Print(string)(stringSlice) we would do Print.(stringSlice) I think
>> definitions could just swap ()  for < > for generic type parameters,
>> without the dot.
>> Aside from that, and wishing that the proposal specified that generics
>> would all be resolved at compile time rather than at run time, I'm really
>> loving this!
>
> Thanks for the note.  I think we should get some experience with
> writing code using this syntax before we discard 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAERFoOjiW_uBz9jaOgT6wLN%3D_BMqp_hOAoSwsGdiSRbW%3DB%3DFNw%40mail.gmail.com.

[go-nuts] Generics: More on parens

[Aaron Cannon]

I, like many others, am not fond of all the parenthesis, particularly at call 
sites. I think at definition sites, it's not so bad. It seems like the only 
objection to < and > are the complexity it adds for parsing. It also seems like 
the only place it adds ambiguity is at call or enstantiation sites. So what if 
we used .(stringSlice) I think definitions could just swap ()  for < > for 
generic type parameters, without the dot.
Aside from that, and wishing that the proposal specified that generics would 
all be resolved at compile time rather than at run time, I'm really loving this!

Thanks for all the hard work!

Aaron

--
This message was sent from a mobile device

-- 
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/0477C783-B409-4D72-8731-F6691CC856D1%40fireantproductions.com.

[go-nuts] Question about iterator implementation of golang map

[Aaron Lau]

Question:
Where
In function mapiternext
Why
We won't update the map during the traversal process. So why use mapaccessK 
to find the k & v again ?

if (b.tophash[offi] != evacuatedX && b.tophash[offi] != evacuatedY) ||
!(t.reflexivekey() || alg.equal(k, k)) {
// This is the golden data, we can return it.
// OR
// key!=key, so the entry can't be deleted or updated, so we can just 
return it.
// That's lucky for us because when key!=key we can't look it up 
successfully.
it.key = k
if t.indirectvalue() {
v = *((*unsafe.Pointer)(v))
}
it.value = v
} else {
// The hash table has grown since the iterator was started.
// The golden data for this key is now somewhere else.
// Check the current hash table for the data.
// This code handles the case where the key
// has been deleted, updated, or deleted and reinserted.
// NOTE: we need to regrab the key as it has potentially been
// updated to an equal() but not identical key (e.g. +0.0 vs -0.0).
rk, rv := mapaccessK(t, h, k)
if rk == nil {
continue // key has been deleted
}
it.key = rk
it.value = rv
}

-- 
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/5f491cbe-cd6b-404e-a598-dd6e5f670c8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] In-Method declaration of array of struct literals vs global var?

['Aaron Spangler' via golang-nuts]

That makes so much more sense now. Thank you for the explanation!

On Thu, Jun 6, 2019 at 7:07 PM Steven Blenkinsop 
wrote:

> = is always required when you're assigning a value to the var. the
> confusion might be that you can also have a declaration like
>
> var bar []struct{a, b, c string}
>
> where you don't assign a value to bar (meaning it will be null).
>
> Really, the syntax is
>
> var variableName Type = value
>
> You can leave off either the "Type" or the "= value" but not both.
>
> var bar = []struct{a, b, c string} {
>   { "really", "long", "row"},
>   { "many", "many", "rows"},
>   ...
> }
>
> is just a special case where you've left off the "Type", and "value"
> happens to be a composite literal expression. It could also be written as
>
> var bar []struct{a, b, c string} = []struct{a, b, c string} {
>   { "really", "long", "row"},
>   { "many", "many", "rows"},
>   ...
> }
>
> On Thu, Jun 6, 2019 at 2:47 PM 'Aaron Spangler' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Thank you!  You are correct.  That was exactly my problem.  Adding the
>> equals sign (=) solved it.
>>
>> I guess I need to be more aware that sometimes an equals statement is
>> required on a 'var' line and other times it is not.  (perhaps only when it
>> has a literal)
>>
>> Thanks again!
>>
>> On Thu, Jun 6, 2019 at 11:05 AM Ian Lance Taylor  wrote:
>>
>>> On Thu, Jun 6, 2019 at 10:56 AM ajs via golang-nuts
>>>  wrote:
>>> >
>>> > I can declare literal bar inside a function like this:
>>> >
>>> > func foo() {
>>> >   bar := []struct{a, b, c string} {
>>> > { "really", "long", "row"},
>>> > { "many", "many", "rows"},
>>> > ...
>>> >   }
>>> > }
>>> >
>>> > But I really want it anchored (for code generation reason) outside of
>>> a function like this:
>>> >
>>> > func foo() {
>>> >   ...
>>> > }
>>> >
>>> > var bar []struct{a, b, c string} {
>>> >   { "really", "long", "row"},
>>> >   { "many", "many", "rows"},
>>> >   ...
>>> > }
>>> >
>>> > The problem is it gets upset on the last character of the 'var bar
>>> ...' line.  Is there a better way to write this?
>>> > Note for reasons outside of this discussion, I really want to avoid
>>> writing it by repeating the discrete field names:
>>> >
>>> > var bar []struct{a, b, c string} {
>>> >   {a: "really",b: "long",c: "row"},  // Don't want to do this
>>> >   {a: "many", b: "many", c: "rows"}, // Don't want to do this
>>> >   ...
>>> > }
>>> >
>>> > Any thoughts?  What am I missing?
>>>
>>> An important tip: when asking a question, please tell us precisely
>>> what you did and precisely what happened.  You can see what happened,
>>> but when you write "it gets upset" we have to guess.  And it's easy
>>> for us to guess wrong.
>>>
>>> When I look at
>>>
>>> var bar []struct{a, b, c string} {
>>>   { "really", "long", "row"},
>>>   { "many", "many", "rows"},
>>>   ...
>>> }
>>>
>>> what I think is that it should say
>>>
>>> var bar = []struct{...
>>>
>>> That is, you are missing the "=".  But I don't know if that was a typo
>>> in the e-mail message.  So if that doesn't help tell us exactly what
>>> you did and exactly what happened.
>>>
>>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAHP%2Bjq4-wp5EgvmK-POEHmDNa8-T9WUJqzAYJA9jRsuuo6%2Boaw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAHP%2Bjq4-wp5EgvmK-POEHmDNa8-T9WUJqzAYJA9jRsuuo6%2Boaw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHP%2Bjq4LhVzqWx%2BmehCp%2B6heeXmLvvPQbz%2B7Ofn5bm1vU%2BWufQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] In-Method declaration of array of struct literals vs global var?

['Aaron Spangler' via golang-nuts]

Thank you!  You are correct.  That was exactly my problem.  Adding the
equals sign (=) solved it.

I guess I need to be more aware that sometimes an equals statement is
required on a 'var' line and other times it is not.  (perhaps only when it
has a literal)

Thanks again!

On Thu, Jun 6, 2019 at 11:05 AM Ian Lance Taylor  wrote:

> On Thu, Jun 6, 2019 at 10:56 AM ajs via golang-nuts
>  wrote:
> >
> > I can declare literal bar inside a function like this:
> >
> > func foo() {
> >   bar := []struct{a, b, c string} {
> > { "really", "long", "row"},
> > { "many", "many", "rows"},
> > ...
> >   }
> > }
> >
> > But I really want it anchored (for code generation reason) outside of a
> function like this:
> >
> > func foo() {
> >   ...
> > }
> >
> > var bar []struct{a, b, c string} {
> >   { "really", "long", "row"},
> >   { "many", "many", "rows"},
> >   ...
> > }
> >
> > The problem is it gets upset on the last character of the 'var bar ...'
> line.  Is there a better way to write this?
> > Note for reasons outside of this discussion, I really want to avoid
> writing it by repeating the discrete field names:
> >
> > var bar []struct{a, b, c string} {
> >   {a: "really",b: "long",c: "row"},  // Don't want to do this
> >   {a: "many", b: "many", c: "rows"}, // Don't want to do this
> >   ...
> > }
> >
> > Any thoughts?  What am I missing?
>
> An important tip: when asking a question, please tell us precisely
> what you did and precisely what happened.  You can see what happened,
> but when you write "it gets upset" we have to guess.  And it's easy
> for us to guess wrong.
>
> When I look at
>
> var bar []struct{a, b, c string} {
>   { "really", "long", "row"},
>   { "many", "many", "rows"},
>   ...
> }
>
> what I think is that it should say
>
> var bar = []struct{...
>
> That is, you are missing the "=".  But I don't know if that was a typo
> in the e-mail message.  So if that doesn't help tell us exactly what
> you did and exactly what happened.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHP%2Bjq4-wp5EgvmK-POEHmDNa8-T9WUJqzAYJA9jRsuuo6%2Boaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go routines hanging

[Aaron Alpar]

Can you distill the code you've provided into something that demonstrates 
the hangs with the least code possible?

Immediately I see a possible problem on lines 131 and 148 or your code: I 
don't see specification of a timeout for the outgoing connection or sending 
the message on the outgoing connection.  

RedisWriteHandler will stall if either one of these outgoing requests hangs.

While timeouts will not fix your problem, they will allow you to further 
diagnose the problem.

- Aaron

On Friday, May 4, 2018 at 7:24:56 AM UTC-7, s...@whites.team wrote:
>
> Hi all,
>
> I'm having an issue with a messaging server I'm trying to write in Go (my 
> first real Go project). I'm having an issue that I've not come across 
> before in Go - the code executes as expected, then hangs after a second or 
> so indefinitely, no errors, no logs showing it's exited. The code is 
> available here 
> <https://gitlab.com/samisagit/go-im-server/blob/changed-redis-handler-buggy/src/main.go#L110>.
>  
> The functions of note are RedisWriteHandler and addRedisSender. In func 
> main I'm seeding a channel with the max amount of items (currently 100k) 
> then starting RedisWriteHandler, this should auto scale up and down 
> according to the length of the channel. However before it gets a chance to 
> scale down it hangs. I've checked with redis-cli and the senders are still 
> connected, but no more messages are coming though. Unfortunately I can't 
> replicate this in the go playground as it's never going to return, and it 
> will take too long and get kicked. I also asked this question here 
> <https://stackoverflow.com/questions/50129226/golang-channels-getting-stuck> 
> but it seems to have gone quiet.
>
> Based on comments from a couple other questions in this group I've killed 
> the process manually to get the stack trace which I'll attach, hopefully 
> this is helpful.
>
> Any thoughts would be greatly appreciated!
>
> Thanks,
>
> Sam
>

-- 
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] Rewriting a realtime game server from Node.js to Golang

[Aaron]

Hi I am in a process of rewriting a realtime game server from Node.js to 
Golang. It's two to three thousand lines of code in Node.js. But I have no 
previous Golang experience so it's hard to measure the workload. Do you 
think it is better for me to do some other bigger projects before I start 
rewriting my game server?

-- 
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: Simple web crawler question. How to avoid crawling visited links?

[Aaron]

Thank you Mike. I have read the book and done that exercise. The code in 
the example will not crawl into certain depth and stop at certain depth of 
the website. The requirements are a bit different. I can't just use the 
approach in the example directly or more precisely I don't know how to use 
it in my code.

On Tuesday, September 26, 2017 at 6:18:43 AM UTC+8, Michael Jones wrote:
>
> The book, The Go Programming Language discusses the web crawl task at 
> several points through the text. The simplest complete parallel version is:
>
> https://github.com/adonovan/gopl.io/blob/master/ch8/crawl3/findlinks.go
>
> which if you'll download and build works quite nicely:
>
> *$ crawl3 http://www.golang.org <http://www.golang.org>*
> http://www.golang.org
> http://www.google.com/intl/en/policies/privacy/
> https://golang.org/doc/tos.html
> https://golang.org/project/
> https://golang.org/pkg/
> https://golang.org/doc/
> http://play.golang.org/
> https://tour.golang.org/
> https://golang.org/LICENSE
> https://developers.google.com/site-policies#restrictions
> https://golang.org/dl/
> https://golang.org/blog/
> https://golang.org/help/
> https://golang.org/
> https://blog.golang.org/
> https://www.google.com/intl/en/privacy/privacy-policy.html
> https://www.google.com/intl/en/policies/terms/
> https://golang.org/LICENSE?m=text
> https://golang.org/pkg
> https://golang.org/doc/go_faq.html
> https://groups.google.com/group/golang-nuts
> https://blog.gopheracademy.com/gophers-slack-community/
> https://golang.org/wiki
> https://forum.golangbridge.org/
> irc:irc.freenode.net/go-nuts
> 2017/09/25 15:13:07 Get irc:irc.freenode.net/go-nuts: unsupported 
> protocol scheme "irc"
> https://golang.org/doc/faq
> https://groups.google.com/group/golang-announce
> https://blog.golang.org
> https://twitter.com/golang
> :
>
> On Mon, Sep 25, 2017 at 7:46 AM, Michael Jones <michae...@gmail.com 
> > wrote:
>
>> i suggest that you first make it work in the simple way and then make it 
>> concurrent.
>>
>> however, one lock-free concurrent way to think of this is as follows...
>>
>> 1. start with a list of urls (in code, on command line, etc.)
>> 2. spawn a go process that writes each of them to a channel of strings, 
>> perhaps called PENDING
>> 3. spawn a go process that reads a url string from work and if it is not 
>> in the map of already processed url's, writes it to a channel of strings, 
>> WORK, after adding the url to the map.
>> 4 spawn a set of go processes that read WORK, fetch the url, do whatever 
>> it it that you need to do, and for urls found there, writes them to PENDING
>>
>> this is enough. now as written you have the challenge to know when the 
>> workers are done and pending is empty. that's when you exit. there are 
>> other ways to do this, but the point is to state with emphasis what an 
>> earlier email said, which is to have the map in its own goroutine, the one 
>> that decides which urls should be processed.
>>
>> On Mon, Sep 25, 2017 at 5:35 AM, Aaron <gdz...@gmail.com > 
>> wrote:
>>
>>> I have come up with a fix, using Mutex. But I am not sure how to do it 
>>> with channels.
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "log"
>>> "net/http"
>>> "os"
>>> "strings"
>>> "sync"
>>>
>>> "golang.org/x/net/html"
>>> )
>>>
>>> var lock = sync.RWMutex{}
>>>
>>> func main() {
>>> if len(os.Args) != 2 {
>>> fmt.Println("Usage: crawl [URL].")
>>> }
>>>
>>> url := os.Args[1]
>>> if !strings.HasPrefix(url, "http://;) {
>>> url = "http://; + url
>>> }
>>>
>>> n := 0
>>>
>>> for link := range newCrawl(url, 1) {
>>> n++
>>> fmt.Println(link)
>>> }
>>>
>>> fmt.Printf("Total links: %d\n", n)
>>> }
>>>
>>> func newCrawl(url string, num int) chan string {
>>> visited := make(map[string]bool)
>>> ch := make(chan string, 20)
>>>
>>> go func() {
>>> crawl(url, 3, ch, )
>>> close(ch)
>>> }()
>>>
>>> return ch
>>> }
>>>
>>> func crawl(url string, n int, ch chan string, visited *map[string]bool) 
>>> {
>>> if n < 1 {
>

[go-nuts] Re: Simple web crawler question. How to avoid crawling visited links?

[Aaron]

Wow this has everything for a crawler plus many more. Is it good to put the 
code into so many files? I thought go program is simple enough to put most 
code into one file. But I think if code reuse is the main concern maybe 
this is good.

On Monday, September 25, 2017 at 10:44:45 PM UTC+8, Tim T wrote:
>
> I did something similar for an interview some months ago. If you want to 
> get some inspiration: https://github.com/TimTosi/crawlr

-- 
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 to remove a struct value from a struct slice without memory leak?

[Aaron]

Thanks I also worried that at the beginning. But when I use this code I 
find it works correctly. But if I pull it out to test the individual 
function it doesn't look good. I think you are right the best practice is 
to return the slice.

For the connInfo struct comparison I learned that comparing them is 
possible but I don't know how accurate it would be. This is just a simple 
test. I will look into this issue later.

On Tuesday, September 26, 2017 at 8:38:52 AM UTC+8, Keith Randall wrote:
>
> I see a couple of issues with your code.
>
> The code you use for removal of an element is right. You've correctly made 
> sure there is no leak.
>
> You never return the clients slice back to the caller.  Any length 
> shortening of the clients slice will be lost when the function returns.
> You might want to review 
> https://blog.golang.org/go-slices-usage-and-internals
>
> I'm skeptical of using struct equality on your connInfo struct.  My guess 
> is you just want the ipAddr and name fields to match, not the net.Conn 
> itself.  It's hard for me to know for sure without seeing the users of this 
> code, but it looks fishy.
>
> You probably want a break statement at the end of your if block. Unless 
> you expect multiple structs to match?
>
> On Monday, September 25, 2017 at 5:14:22 PM UTC-7, kortschak wrote:
>>
>> This is not nice if you want to reuse the slice, and still may leak the 
>> fields. 
>>
>> clients[i] = clients[len(clients)-1] 
>> // If the current clients[i] is deleted it becomes inaccessible 
>> // and the ipAddr, name and conn fields potentially leak, so 
>> // zero them in the last position of the slice. 
>> clients[len(clients)-1] = connInfo{} 
>> clients = clients[:len(clients)-1] 
>>
>>
>> On Mon, 2017-09-25 at 11:52 -0700, Tamás Gulácsi wrote: 
>> > https://github.com/golang/go/wiki/SliceTricks 
>> > 
>> > clients[i] = clients[0] 
>> > clients = clients[1:] 
>>
>>
>>
>>

-- 
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] How to remove a struct value from a struct slice without memory leak?

[Aaron]

Newbie here everyone.

I am trying to remove a struct value from a slice, which consists of 
elements of the same type. Let's say the type is defined as below:

type connInfo struct {
ipAddr string
name string
conn net.Conn
}


Now I have a remove function, in which there is a for loop to find out the 
struct value position in the slice, and then delete the value. But there is 
a potential memory leak according to here 
, and because I can't assign 
a "nil" value to the struct type, I need to assign a zero value to the last 
element of the slice. Am I doing it correctly? Or I need to do some smarter 
thing?

func removeClient(clients []connInfo, connClient *connInfo) {
for i := len(clients) - 1; i >= 0; i-- {
if clients[i] == *connClient {
copy(clients[i:], clients[i+1:])
clients[len(clients)-1] = connInfo{}
clients = clients[:len(clients)-1]
}
}
}

-- 
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: Simple web crawler question. How to avoid crawling visited links?

[Aaron]

I have come up with a fix, using Mutex. But I am not sure how to do it with 
channels.

package main

import (
"fmt"
"log"
"net/http"
"os"
"strings"
"sync"

"golang.org/x/net/html"
)

var lock = sync.RWMutex{}

func main() {
if len(os.Args) != 2 {
fmt.Println("Usage: crawl [URL].")
}

url := os.Args[1]
if !strings.HasPrefix(url, "http://;) {
url = "http://; + url
}

n := 0

for link := range newCrawl(url, 1) {
n++
fmt.Println(link)
}

fmt.Printf("Total links: %d\n", n)
}

func newCrawl(url string, num int) chan string {
visited := make(map[string]bool)
ch := make(chan string, 20)

go func() {
crawl(url, 3, ch, )
close(ch)
}()

return ch
}

func crawl(url string, n int, ch chan string, visited *map[string]bool) {
if n < 1 {
return
}
resp, err := http.Get(url)
if err != nil {
log.Fatalf("Can not reach the site. Error = %v\n", err)
os.Exit(1)
}

b := resp.Body
defer b.Close()

z := html.NewTokenizer(b)

nextN := n - 1
for {
token := z.Next()

switch token {
case html.ErrorToken:
return
case html.StartTagToken:
current := z.Token()
if current.Data != "a" {
continue
}
result, ok := getHrefTag(current)
if !ok {
continue
}

hasProto := strings.HasPrefix(result, "http")
if hasProto {
lock.RLock()
ok := (*visited)[result]
lock.RUnlock()
if ok {
continue
}
done := make(chan struct{})
go func() {
crawl(result, nextN, ch, visited)
close(done)
}()
<-done
lock.Lock()
(*visited)[result] = true
lock.Unlock()
ch <- result
}
}
}
}

func getHrefTag(token html.Token) (result string, ok bool) {
for _, a := range token.Attr {
if a.Key == "href" {
    result = a.Val
ok = true
break
}
}
return
}


On Sunday, September 24, 2017 at 10:13:16 PM UTC+8, Aaron wrote:
>
> Hi I am learning Golang concurrency and trying to build a simple Website 
> crawler. I managed to crawl all the links of the pages of any depth of 
> website. But I still have one problem to tackle: how to avoid crawling 
> visited links that are previously crawled?
>
> Here is my code. Hope you guys can shed some light. Thank you in advance.
>
> package main
> import (
> "fmt"
> "log"
> "net/http"
> "os"
> "strings"
>
> "golang.org/x/net/html")
>
> func main() {
> if len(os.Args) != 2 {
> fmt.Println("Usage: crawl [URL].")
> }
>
> url := os.Args[1]
> if !strings.HasPrefix(url, "http://;) {
> url = "http://; + url
> }
>
> for link := range newCrawl(url, 1) {
> fmt.Println(link)
> }}
>
> func newCrawl(url string, num int) chan string {
> ch := make(chan string, 20)
>
> go func() {
> crawl(url, 1, ch)
> close(ch)
> }()
>
> return ch}
>
> func crawl(url string, n int, ch chan string) {
> if n < 1 {
> return
> }
> resp, err := http.Get(url)
> if err != nil {
> log.Fatalf("Can not reach the site. Error = %v\n", err)
> os.Exit(1)
> }
>
> b := resp.Body
> defer b.Close()
>
> z := html.NewTokenizer(b)
>
> nextN := n - 1
> for {
> token := z.Next()
>
> switch token {
> case html.ErrorToken:
> return
> case html.StartTagToken:
> current := z.Token()
> if current.Data != "a" {
> continue
> }
> result, ok := getHrefTag(current)
> if !ok {
> continue
> }
>
> hasProto := strings.HasPrefix(result, "http")
> if hasProto {
> done := make(chan struct{})
> go func() {
> crawl(result, nextN, ch)
> close(done)
> }()
> <-done
> ch <- result
> }
> }
> }}
>
> func getHrefTag(token html.Token) (result string, ok bool) {
> for _, a := range token.Attr {
> if a.Key == "href" {
> result = a.Val
> ok = true
> break
> }
> }
> return}
>
>

-- 
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] Returning an interface using a concrete type?

[Aaron Wood]

You're right, I had omitted the implementation by accident.

Also, I realized what the issue is. In my real code that I'm working on I 
had the return type as *Config and not Config. I totally overlooked that, 
my mistake! 

On Tuesday, February 14, 2017 at 3:12:43 PM UTC-5, Chris Manghane wrote:
>
> Seems to work fine to me: https://play.golang.org/p/6DmDKQLrzd.
>
> In your snippet, the concrete type doesn't implement the interface, 
> however. What was the error you got when trying to do apply this to more 
> complicated code.
>
> Chris
>
> On Tue, Feb 14, 2017 at 12:01 PM, Aaron Wood <aaron...@gmail.com 
> > wrote:
>
>> I'm wondering why it's not possible to do something like this 
>> https://play.golang.org/p/UaRLUvhkgz
>>
>> If a type implements an interface then why can that type not be returned 
>> with the method specifying the return type as the interface that it 
>> implements?
>>
>> -- 
>> 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] Returning an interface using a concrete type?

[Aaron Wood]

I'm wondering why it's not possible to do something like 
this https://play.golang.org/p/UaRLUvhkgz

If a type implements an interface then why can that type not be returned 
with the method specifying the return type as the interface that it 
implements?

-- 
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: Dynamic select/channel causes data race

[Aaron Wood]

Thanks! I'm sure I'll never forget this experience :)

-- 
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: Dynamic select/channel causes data race

[Aaron Wood]

Sorry guys. False alarm. The real issue was that we needed to use 
covermode=atomic instead of covermode=count in our CI.

On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>
> Hi all,
>
> I'm seeing a very strange issue that I'm not quite sure how to fix:
>
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80
>
> This causes a data race, and of course we only see it when running on a 
> beefy server with many cores :) I've never dealt with handling concurrency 
> and channels/selects when they're built dynamically using reflection. I've 
> tried surrounding the access on line 25 with a mutex but that does not 
> solve anything. Looking more into reflect.ValueOf() I see that it always 
> escapes to the heap as well as works with unsafe pointers in the 
> unpackEface() method 
> https://golang.org/src/reflect/value.go?s=61558:61591#L2073
>
> What is the proper way to handle the data race here?
>

-- 
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: Dynamic select/channel causes data race

[Aaron Wood]

Oh man, it looks like you can't use covermode=count with race 
detection? https://github.com/golang/go/issues/12118

On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>
> Hi all,
>
> I'm seeing a very strange issue that I'm not quite sure how to fix:
>
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80
>
> This causes a data race, and of course we only see it when running on a 
> beefy server with many cores :) I've never dealt with handling concurrency 
> and channels/selects when they're built dynamically using reflection. I've 
> tried surrounding the access on line 25 with a mutex but that does not 
> solve anything. Looking more into reflect.ValueOf() I see that it always 
> escapes to the heap as well as works with unsafe pointers in the 
> unpackEface() method 
> https://golang.org/src/reflect/value.go?s=61558:61591#L2073
>
> What is the proper way to handle the data race here?
>

-- 
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: Dynamic select/channel causes data race

[Aaron Wood]

Okay, so what's interesting is that the races only show up when I run
go test -race -covermode=count -coverprofile=count_tmp.out

Running either
go test -race
or
go test -race -cover
does not report any races. Does something seem fishy here?

On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>
> Hi all,
>
> I'm seeing a very strange issue that I'm not quite sure how to fix:
>
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80
>
> This causes a data race, and of course we only see it when running on a 
> beefy server with many cores :) I've never dealt with handling concurrency 
> and channels/selects when they're built dynamically using reflection. I've 
> tried surrounding the access on line 25 with a mutex but that does not 
> solve anything. Looking more into reflect.ValueOf() I see that it always 
> escapes to the heap as well as works with unsafe pointers in the 
> unpackEface() method 
> https://golang.org/src/reflect/value.go?s=61558:61591#L2073
>
> What is the proper way to handle the data race here?
>

-- 
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: Dynamic select/channel causes data race

[Aaron Wood]

I am actually! I didn't realize that reporting on coverage messes with the 
output.
Let me run the tests without coverage enabled...

On Thursday, February 2, 2017 at 2:35:11 PM UTC-5, Kale B wrote:
>
> Are you running your test with coverage enabled? The coverage rewriting 
> causes the race detector to indicate the wrong lines in the source file.
>
> On Thu, Feb 2, 2017 at 11:33 AM, Aaron Wood <aaron...@gmail.com 
> > wrote:
>
>> I can't unfortunately since it's private right now :( I can show you the 
>> entire back off source file here if you'd like, I just can't link you to 
>> anything right now.
>>
>> On Thursday, February 2, 2017 at 2:29:37 PM UTC-5, James Bardin wrote:
>>>
>>> Can you point to the actual source you're using? The filenames and line 
>>> numbers in the stack traces don't line up with the file you linked 
>>> originally. 
>>>
>>>
>>>
>>> -- 
>> 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.

Re: [go-nuts] Re: Dynamic select/channel causes data race

[Aaron Wood]

I can't unfortunately since it's private right now :( I can show you the 
entire back off source file here if you'd like, I just can't link you to 
anything right now.

On Thursday, February 2, 2017 at 2:29:37 PM UTC-5, James Bardin wrote:
>
> Can you point to the actual source you're using? The filenames and line 
> numbers in the stack traces don't line up with the file you linked 
> originally. 
>
>
>
>

-- 
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: Dynamic select/channel causes data race

[Aaron Wood]

Also, the tests that trigger this case look like this:

// Verify that the burst notifier both returns correctly and provides the 
right data from its channel.
func TestBurstNotifier(t *testing.T) {
tokens := BurstNotifier(5, 5*time.Second, 5*time.Second, make(chan 
struct{}))

if reflect.TypeOf(tokens) != reflect.TypeOf(make(<-chan struct{})) {
t.Fatal("Burst notifier returns incorrect channel type")
}
if reflect.TypeOf(<-tokens) != reflect.TypeOf(*new(struct{})) {
t.Fatal("Token is of the wrong type")
}
}

// Verify that the notifier both returns correctly and provides the right 
data from its channel.
func TestNotifier(t *testing.T) {
tokens := Notifier(5*time.Second, 5*time.Second, make(chan struct{}))

if reflect.TypeOf(tokens) != reflect.TypeOf(make(<-chan struct{})) {
t.Fatal("Burst notifier returns incorrect channel type")
}
if reflect.TypeOf(<-tokens) != reflect.TypeOf(*new(struct{})) {
t.Fatal("Token is of the wrong type")
}
}




On Thursday, February 2, 2017 at 1:43:12 PM UTC-5, James Bardin wrote:
>
> Can you post the actual output from the race detector?
>
>
> On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>>
>> Hi all,
>>
>> I'm seeing a very strange issue that I'm not quite sure how to fix:
>>
>> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
>> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80
>>
>> This causes a data race, and of course we only see it when running on a 
>> beefy server with many cores :) I've never dealt with handling concurrency 
>> and channels/selects when they're built dynamically using reflection. I've 
>> tried surrounding the access on line 25 with a mutex but that does not 
>> solve anything. Looking more into reflect.ValueOf() I see that it always 
>> escapes to the heap as well as works with unsafe pointers in the 
>> unpackEface() method 
>> https://golang.org/src/reflect/value.go?s=61558:61591#L2073
>>
>> What is the proper way to handle the data race here?
>>
>

-- 
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: Dynamic select/channel causes data race

[Aaron Wood]

/atomic.LoadInt32()
  /usr/local/go/src/runtime/race_amd64.s:206 +0xb
  testing.coverReport()
  /usr/local/go/src/testing/cover.go:94 +0x291
  testing.after()
  /usr/local/go/src/testing/testing.go:879 +0x162
  testing.(*M).Run()
  /usr/local/go/src/testing/testing.go:752 +0x396
  main.main()
  mesos-go/backoff/_test/_testmain.go:106 +0x2f8

Previous write at 0x00641d28 by goroutine 13:
  mesos-go/backoff.BurstNotifier.func1()
  mesos-go/backoff/_test/_obj_test/backoff.go:44 +0x11f

Goroutine 13 (running) created at:
  mesos-go/backoff.BurstNotifier()
  mesos-go/backoff/_test/_obj_test/backoff.go:54 +0x492
  mesos-go/backoff.TestBurstNotifier()
  /go/src/mesos-go/backoff/backoff_test.go:11 +0x96
  testing.tRunner()
  /usr/local/go/src/testing/testing.go:610 +0xc9
==
==
WARNING: DATA RACE
Read at 0x00641d30 by main goroutine:
  sync/atomic.LoadInt32()
  /usr/local/go/src/runtime/race_amd64.s:206 +0xb
  testing.coverReport()
  /usr/local/go/src/testing/cover.go:94 +0x291
  testing.after()
  /usr/local/go/src/testing/testing.go:879 +0x162
  testing.(*M).Run()
  /usr/local/go/src/testing/testing.go:752 +0x396
  main.main()
  mesos-go/backoff/_test/_testmain.go:106 +0x2f8

Previous write at 0x00641d30 by goroutine 13:
  mesos-go/backoff.BurstNotifier.func1()
  mesos-go/backoff/_test/_obj_test/backoff.go:48 +0x1c0

Goroutine 13 (running) created at:
  mesos-go/backoff.BurstNotifier()
  mesos-go/backoff/_test/_obj_test/backoff.go:54 +0x492
  mesos-go/backoff.TestBurstNotifier()
  /go/src/mesos-go/backoff/backoff_test.go:11 +0x96
  testing.tRunner()
  /usr/local/go/src/testing/testing.go:610 +0xc9
==
==
WARNING: DATA RACE
Read at 0x00641d78 by main goroutine:
  sync/atomic.LoadInt32()
  /usr/local/go/src/runtime/race_amd64.s:206 +0xb
  testing.coverReport()
  /usr/local/go/src/testing/cover.go:94 +0x291
  testing.after()
  /usr/local/go/src/testing/testing.go:879 +0x162
  testing.(*M).Run()
  /usr/local/go/src/testing/testing.go:752 +0x396
  main.main()
  mesos-go/backoff/_test/_testmain.go:106 +0x2f8

Previous write at 0x00641d78 by goroutine 15:
  mesos-go/backoff.Notifier.func1()
  mesos-go/backoff/_test/_obj_test/backoff.go:102 +0x4ae

Goroutine 15 (running) created at:
  mesos-go/backoff.Notifier()
  mesos-go/backoff/_test/_obj_test/backoff.go:118 +0x1d3
  mesos-go/backoff.TestNotifier()
  /go/src/mesos-go/backoff/backoff_test.go:30 +0x8d
  testing.tRunner()
  /usr/local/go/src/testing/testing.go:610 +0xc9
==



On Thursday, February 2, 2017 at 1:43:12 PM UTC-5, James Bardin wrote:
>
> Can you post the actual output from the race detector?
>
>
> On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>>
>> Hi all,
>>
>> I'm seeing a very strange issue that I'm not quite sure how to fix:
>>
>> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
>> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80
>>
>> This causes a data race, and of course we only see it when running on a 
>> beefy server with many cores :) I've never dealt with handling concurrency 
>> and channels/selects when they're built dynamically using reflection. I've 
>> tried surrounding the access on line 25 with a mutex but that does not 
>> solve anything. Looking more into reflect.ValueOf() I see that it always 
>> escapes to the heap as well as works with unsafe pointers in the 
>> unpackEface() method 
>> https://golang.org/src/reflect/value.go?s=61558:61591#L2073
>>
>> What is the proper way to handle the data race here?
>>
>

-- 
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] Dynamic select/channel causes data race

[Aaron Wood]

Hi all,

I'm seeing a very strange issue that I'm not quite sure how to fix:

https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80

This causes a data race, and of course we only see it when running on a 
beefy server with many cores :) I've never dealt with handling concurrency 
and channels/selects when they're built dynamically using reflection. I've 
tried surrounding the access on line 25 with a mutex but that does not 
solve anything. Looking more into reflect.ValueOf() I see that it always 
escapes to the heap as well as works with unsafe pointers in the 
unpackEface() 
method https://golang.org/src/reflect/value.go?s=61558:61591#L2073

What is the proper way to handle the data race here?

-- 
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: Secure Go binaries

[Aaron Wood]

Interesting, thanks for the info Ian. Other than the OS and distro 
requirements, is there any real benefit from generating PIE binaries with 
Go? There must be some vector that it protects again, even though most 
things are already bounds-checked. The only situation I can think of is if 
you're calling C from Go. There must be other rare, obscure ways to exploit 
overflows in code generated from Go, no?

On Thursday, December 22, 2016 at 5:31:14 PM UTC-5, Ian Lance Taylor wrote:
>
> On Thu, Dec 22, 2016 at 2:09 PM, Aaron Wood <aaron...@gmail.com 
> > wrote: 
> > 
> > This is a rather old comment of yours but I was curious about a few 
> things 
> > you said. I agree that Go does take care of a lot of these problems (and 
> > most other high-level languages try to too) so I'm curious as to why Go 
> has 
> > exposed a build option for generating position independent executables 
> > (buildmode=pie). This is something I use and think it is a great feature 
> to 
> > have exposed but if the goal was to address most of this stuff at the 
> > language level then what was the reason for exposing this to users of 
> Go? I 
> > don't think most other high-level languages let you control this 
> > setting...although I guess most of them don't really compile down to a 
> > native binary in the end. 
>
> Go exposes supports generating PIE because an increasing number of 
> operating system distros require it, or at least use it by default 
> (for example, I believe that non-Java Android apps must be PIE).  The 
> distros do this because the distro maintainers feel that it addresses 
> problems with programs written in C/C++.  Since from the operating 
> system perspective Go programs are indistinguishable from C/C++ 
> programs, Go needs to be able to generate PIE just as C/C++ do. 
>
> As you say, discussing PIE is only relevant for a language that 
> compiles into a native binary. 
>
> Ian 
>
>
> > On Monday, April 30, 2012 at 10:21:06 PM UTC-4, Russ Cox wrote: 
> >> 
> >> On Mon, Apr 30, 2012 at 21:51, David  Leimbach <lei...@gmail.com> 
> wrote: 
> >> > I was just playing with pointers yesterday, trying to understand a 
> >> > memory 
> >> > issue I thought I was having (me not remembering the memory model 
> >> > mostly). 
> >> > 
> >> > I came to the conclusion that pointers were showing up at very much 
> the 
> >> > same 
> >> > memory addresses each time, and that perhaps randomizing this would 
> be a 
> >> > good idea. 
> >> 
> >> Address space randomization is an OS-level workaround for a 
> >> language-level problem, namely that simple C programs tend to be full 
> >> of exploitable buffer overflows.  Go fixes this at the language level, 
> >> with bounds-checked arrays and slices and no dangling pointers, which 
> >> makes the OS-level workaround much less important.  In return, we 
> >> receive the incredible debuggability of deterministic address space 
> >> layout.  I would not give that up lightly. 
> >> 
> >> Russ 
> > 
> > -- 
> > 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.

Re: [go-nuts] Re: Secure Go binaries

[Aaron Wood]

Hi Russ,

This is a rather old comment of yours but I was curious about a few things 
you said. I agree that Go does take care of a lot of these problems (and 
most other high-level languages try to too) so I'm curious as to why Go has 
exposed a build option for generating position independent executables 
(buildmode=pie). This is something I use and think it is a great feature to 
have exposed but if the goal was to address most of this stuff at the 
language level then what was the reason for exposing this to users of Go? I 
don't think most other high-level languages let you control this 
setting...although I guess most of them don't really compile down to a 
native binary in the end.

-Aaron

On Monday, April 30, 2012 at 10:21:06 PM UTC-4, Russ Cox wrote:
>
> On Mon, Apr 30, 2012 at 21:51, David  Leimbach <lei...@gmail.com 
> > wrote: 
> > I was just playing with pointers yesterday, trying to understand a 
> memory 
> > issue I thought I was having (me not remembering the memory model 
> mostly). 
> > 
> > I came to the conclusion that pointers were showing up at very much the 
> same 
> > memory addresses each time, and that perhaps randomizing this would be a 
> > good idea. 
>
> Address space randomization is an OS-level workaround for a 
> language-level problem, namely that simple C programs tend to be full 
> of exploitable buffer overflows.  Go fixes this at the language level, 
> with bounds-checked arrays and slices and no dangling pointers, which 
> makes the OS-level workaround much less important.  In return, we 
> receive the incredible debuggability of deterministic address space 
> layout.  I would not give that up lightly. 
>
> Russ 
>

-- 
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] converting slice of items into nested array

[aaron]

I'm pretty new to golang and struggling a bit with converting flat database 
results into a nested JSON object.  

As an example... I have 

type item struct {
raceID   string
racename string
name string
votesint32
}

type race struct {
raceID   string
racename string
racers
}

type racers []racer

type racer struct {
name  string
votes int32
}

[]item is what I get back from my db query and I want to convert it into a 
json object that matches the race struct.

basically I want to convert 
items := []item{
item{"1", "racename1", "scooby", 1000},
item{"1", "racename1", "scrappy", 9000},
item{"1", "racename1", "shaggy", 1000},
item{"2", "racename2", "shaggy", 450},
item{"2", "racename2", "fred", 550},
}

into something like

[{
"raceID": "1",
"racename": "racename1",
"racers": [{
"name": "scooby",
"votes": 1000
}, {
"name": "scrappy",
"votes": 9000
}, {
"name": "shaggy",
"votes": 1000
}]
}, {
"raceID": "2",
"racename": "racename2",
"racers": [{
"name": "shaggy",
"votes": 450
}, {
"name": "fred",
"votes": 550
}]
}]

I'm pretty sure I need to use maps and append some slices... but any 
pointing in the right direction would surely be appreciated.


-- 
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: GDB support for goroutines in core files

['Aaron Jacobs' via golang-nuts]

On Fri, Dec 2, 2016 at 7:32 PM,  <huangbaochen...@sina.cn> wrote:
> Hello Aaron, have you figure it out yet?

Sorry, I haven't done anything further here.

-- 
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] Reasons why `go get` is entirely quiet by default

[Aaron Taylor]

It's also probably worth noting that 'go get' isn't really a package manager in 
the way that yarn and npm are. Each of those tools, and their go equivalents 
[1] have somewhat more sophisticated functionality related actually managing 
the packages, controlling their versions, resolving conflicts, etc. while 'go 
get' basically retrieves a package and it's dependencies if they aren't already 
present. If you're working on anything that needs to be relied upon, it's 
probably worth checking out Go's package manager ecosystem. For what it's 
worth, we use glide where I work and it has lots of output :)

[1] https://github.com/golang/go/wiki/PackageManagementTools

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

[Aaron Cannon]

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